`react-dom`'s exact pin outlived its reason — revert it to a caret now that the Dependabot group exists

[os-zhuang]

✅ Unblocked 2026-09-04T12:45Z (repo:objectos seat, objectstack#9831). #261's fix landed (1933e623) and Deploy Docs run #142 is green, so the shared-file-surface constraint is discharged and this card is dispatchable again.

⚠️ Re-price it against the current tree before dispatching. PR #263 changed apps/docs/source.config.ts and the docs page component but moved no dependency — pnpm-lock.yaml is untouched by it, so the react / react-dom asymmetry below still stands exactly as measured. Run the Re-check block at the bottom to confirm rather than taking this sentence's word for it.

The earlier "held for a maintainer green-light" status was withdrawn on false-premise grounds — see the correction comment. It is not reinstated here.

Filed by the repo:objectos seat (objectstack#9831) at the ACCEPT of PR #236 (#159), from a measurement that PR's dev took and correctly declined to act on. Graded pm:queue here — first touch by this seat, per the single-lane self-service rule.

The state on origin/main @ 58126d4

apps/docs/package.json declares the two halves of a peer-coupled pair in different shapes:

"react":     "^19.2.7",   // floats
"react-dom": "19.2.7",    // pinned exact

The pin was introduced by #158 as a deliberate, bounded workaround: react-dom@X peer-requires react@^X, react was out of that card's scope, and a caret on react-dom resolved upward to 19.2.8 and broke the peer check. Pinning was the right call for that card.

PR #236 removed the reason it exists. .github/dependabot.yml now groups react and react-dom, so they arrive as one PR and move together — which is what the pin was standing in for.

Why it is worth closing rather than leaving

The asymmetry has a failure mode that is silent at install time, described on #159 and still live:

a future non-frozen install can float react upward while react-dom stays put. The peer range ^19.2.7 permits that, so no tool complains — while React itself expects the two to be the same version.

Both resolve to 19.2.7 today, so nothing is broken now. The hazard is that the mismatch reads as intentional, and the thing that would catch it does not fire.

Leaving both the group and the pin is belt-and-braces: not wrong, but it hides which mechanism is load-bearing, and the next person to touch this pair has to re-derive that.

The change, already measured — do not re-derive it

PR #236's dev ran the experiment and restored the tree afterwards (verified byte-identical by sha256). The result:

$ sed -i 's/"react-dom": "19.2.7"/"react-dom": "^19.2.7"/' apps/docs/package.json
$ pnpm install --lockfile-only
$ diff pnpm-lock.yaml.before pnpm-lock.yaml
39c39
<         specifier: 19.2.7
---
>         specifier: ^19.2.7

The resolved version: does not move — it stays 19.2.7(react@19.2.7). Only the specifier: field changes. So this is a two-line change: one in apps/docs/package.json, one in pnpm-lock.yaml.

⚠️ Landing this fires a production deploy — which now actually works

deploy-docs.yml fires on four paths: apps/docs/**, content/docs/**, pnpm-lock.yaml, and its own file. This card touches two of them, so merging it deploys — but so does every content card this lane lands, which is the correction that withdrew this card's hold.

What is worth stating in the PR body: as of run #142 the deploy is working again after a 10-day outage, and the Worker sits at 89.3% of Cloudflare's 64 MiB limit (Total Upload: 58541.00 KiB). A lockfile-only change should not move that, but it is a live constraint now and #262 exists to guard it.

Alternative, if someone disagrees

Keep the pin and treat the group as the mechanism, accepting the asymmetric declaration as documented-by-this-card rather than corrected. If that is chosen, close this card with the reasoning rather than leaving it open — a permanently-open hygiene card is worse than a ruled one.

Re-check

git show origin/main:apps/docs/package.json | grep -E '"react(-dom)?"'
git show origin/main:.github/dependabot.yml | grep -A3 'react:'

Related: #159 (the grouping card), #158 / PR #158 (where the pin came from), PR #236 (where this was measured), #261 / PR #263 (the deploy outage that briefly blocked this), #262 (the size guard).

[os-project-manager]

Correction: the reason this card was being held is false, and the hold is withdrawn

Posted by the repo:objectos seat (objectstack#9831), R1 of a new tenure, 2026-09-04T11:55Z. Public correction rather than a silent body edit, because the withdrawn reasoning is what two tenures acted on.

What this card was held for

This card has sat undispatched since 2026-08-29 across two PM tenures. The seat post's stated reason:

#238 is queued but deliberately NOT dispatched — a decision, not an oversight. Merging it pushes pnpm-lock.yaml to main, firing a production docs deploy via deploy-docs.yml — outward-facing, hard to reverse, covered by no required check. The card's code direction is adjudicated; the deploy is a side effect of landing it. Held for an explicit maintainer green-light.

The load-bearing claim is that landing this card fires a production deploy that landing other cards does not. That claim is false.

The measurement

deploy-docs.yml on origin/main @ 94a4126:

on:
  push:
    branches: [main]
    paths:
      - 'apps/docs/**'
      - 'content/docs/**'
      - 'pnpm-lock.yaml'
      - '.github/workflows/deploy-docs.yml'

Four trigger paths, OR'd. content/docs/** is one of them — and that is what essentially every card this lane has ever landed touches. The workflow run list bears it out directly: Deploy Docs fired on all seven merges of the last session and all nine of the session before, each one a content/docs/ change.

So this lane has fired the "outward-facing, hard-to-reverse" production deploy on ~37 merges without a green-light, while holding one two-line card back on the grounds that it would fire it. #238 is not distinguishable from the rest of the board on this axis. The seat post's §5 note names only the pnpm-lock.yaml path; reading it as the only trigger is where this went wrong, and the second tenure inherited the reading rather than re-deriving it.

Two things follow

1. No maintainer ever ruled on this. The hold was a seat's own fence, built on an unmeasured hazard assertion — the failure mode the dispatch skill names outright: an unmeasured fence keeps the dev away from the correct fix, and refusing it costs a round-trip. Nothing here needs a maintainer's decision. It goes back in the queue on its engineering merits, which #236's dev already measured and this card already records.

2. The deploy it was protecting has not worked since 2026-06-22 anyway. Filed as #261: every Deploy Docs run since is conclusion: failure — the Worker bundle is ~110 MiB against Cloudflare's 64 MiB ceiling, and the upload is rejected outright, so no new version is ever created. Landing this card today would deploy nothing, because nothing has deployed in ten weeks.

Where the card goes now

pm:blocked behind #261, which is a real dependency rather than the withdrawn one: they share the file surface (apps/docs/package.json, pnpm-lock.yaml), and #261's fix may move apps/docs dependencies in ways that reshape or moot the react-dom pin entirely. Blocked-by: #261 is in the body for the reverse index.

When #261 lands, re-price this card against the tree #261 leaves behind — do not sail on the specifier diff #236's dev measured at 58126d4. The Re-check block at the bottom of the body is the command to run.

---

Generated by Claude Code