chore(deps): bump react-dom from 19.2.6 to 19.2.7

[dependabot]

Bumps react-dom from 19.2.6 to 19.2.7.

Release notes

Sourced from react-dom's releases.

19.2.7 (June 1st, 2026)

React Server Components

• Fixed missing FormData entries in Server Actions which regressed in 19.2.6 (#36566 by @​unstubbable)

Changelog

Sourced from react-dom's changelog.

19.2.7 (June 1, 2026)

React Server Components

• Fixed missing FormData entries in Server Actions which regressed in 19.2.6 (@​unstubbable #36566)

Commits

• 6117d7c Version 19.2.7 (#36591)
• See full diff in compare view

Maintainer changes

This version was pushed to npm by GitHub Actions, a new releaser for react-dom since your current version.

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[os-project-manager]

·@·d·ependabot r·ebase

Context: this PR became conflicted when its pair, #47 (react + @types/react 19.2.6 → 19.2.7), merged as c6594ba a moment ago. Both rewrite pnpm-lock.yaml, so only one could land per lap — five open Dependabot PRs all regenerate that one file, and each merge invalidates the rest.

This is the next baton in that relay: react-dom should follow react closely, since they are one logical upgrade that Dependabot split in two. Once rebased and green it will be merged. #46 and #50 (the tailwindcss / @tailwindcss/postcss pair) queue behind it for the same reason.

Reviewed by the repo:objectos PM seat (objectstack#9831), round 1.

---

Generated by Claude Code

[os-zhuang]

·@·d·ependabot r·ebase

---

Why this is being asked twice. The rebase request on this PR from earlier today was posted with separator characters wedged into the command (·@·d·ependabot r·ebase), so Dependabot never parsed it as a command and no rebase was ever queued. The head here is still fbb7756 on a base 67 commits behind main. Not a Dependabot failure — a malformed request. Recording it so the relay's stall has a cause on the record rather than looking like the bot ignoring us.

This PR is the next baton: react-dom follows react (#47, merged as c6594ba), which is the same logical upgrade Dependabot split in two. Once rebased and green on a fresh run, it merges. Its current build check is from 2026-07-19 and predates the Node floor and Ownership & freshness gates entirely, so that green certifies nothing about today's main.

#46 and #50 (the tailwindcss / @tailwindcss/postcss pair) queue behind this one — all of these regenerate pnpm-lock.yaml, so exactly one lands per lap.

Reviewed by the repo:objectos PM seat (objectstack#9831), session session_01VFwZj1a84ZxFUcWAi5H8S5, round 1.

---

Generated by Claude Code

[os-zhuang]

Correction to my previous comment — the earlier request was not malformed by its author, and neither was mine

I attributed the stalled rebase to a mis-typed command in the 13:47Z comment. That was wrong, and the evidence is my own comment directly above it.

I typed the command correctly. It was stored as ·@·d·ependabot r·ebase — the identical mangling, including the same split inside the word rebase. Two different sessions, two different accounts, byte-identical corruption is not two people making the same typo: a sanitizer in the tooling both of us write GitHub content through defuses @dependabot mentions on write. The predecessor's request was almost certainly typed correctly too.

So the correct diagnosis is: this PR cannot be rebased by any comment I am able to post. The command channel is closed to this tooling, not mis-used by it. Two consequences worth recording:

1. The relay was never going to move on its own, and no amount of re-asking will move it. The seat post's standing note that "each needs an explicit rebase comment" describes a step this seat cannot perform — that note needs correcting, and it is going into the round report as a platform reading rather than being quietly worked around.
2. Anything that reads a ·@·d·ependabot … string in this repo's history as evidence of a careless agent is reading a tooling artefact. Worth knowing before someone files a finding about it.

What happens to this PR instead. It is not being abandoned. The three safe bumps here — react-dom 19.2.7 (this PR), tailwindcss 4.3.3 (#46) and @tailwindcss/postcss 4.3.3 (#50) — all rewrite the same pnpm-lock.yaml, which is why only one could ever land per lap even with a working rebase. Consolidating them into a single change that regenerates the lockfile once is strictly better than three sequential rebases: one CI run, one lockfile regeneration, and one production docs deploy instead of three (deploy-docs.yml fires on every pnpm-lock.yaml push to main).

This PR stays open until that lands, then closes as superseded with the commit that carries its bump — not closed on a promise. #48 is unaffected and remains held on its own separate question.

Alternatively, the maintainer can post ·@·d·ependabot r·ebase here directly, from an account whose comments are not sanitized, and the original relay resumes as designed. Either route is fine; this one does not require them.

repo:objectos seat (objectstack#9831), session session_01VFwZj1a84ZxFUcWAi5H8S5, round 1.

---

Generated by Claude Code

[os-zhuang]

Superseded — your bump is on main, verified by content

react-dom 19.2.6 → 19.2.7 landed in ee74379 ("chore(deps): consolidate react-dom, tailwindcss and @tailwindcss/postcss bumps", #158), via objectos#157. Confirmed by reading pnpm-lock.yaml on origin/main, not from the merge record: react-dom@19.2.7, alongside react@19.2.7, so the pairing gap this PR existed to close is closed.

Closing on a landed commit, not on a promise — which is why this comment came after the merge rather than before it.

Why it was consolidated rather than rebased. This PR could not be rebased by an agent: @dependabot commands are rewritten by a sanitizer in the tooling every agent here writes through (see the correction above), so the command never reached the bot. On top of that, all three open npm PRs rewrite the same pnpm-lock.yaml, so only one could ever land per lap. One regeneration replaced three sequential rebases: one CI run, one lockfile, and one production docs deploy instead of three.

One thing changed from what this PR proposed, and it is worth knowing. react-dom@19.2.8 published upstream after this PR was filed, so a caret ^19.2.7 now resolves past 19.2.7 and produces a genuine unmet peer against react@19.2.7:

apps/docs
└─┬ react-dom 19.2.8
  └── ✕ unmet peer react@^19.2.8: found 19.2.7

So react-dom is pinned exact at 19.2.7 rather than carried as a caret — matching this file's existing convention for next and the fumadocs-* packages. Bumping react to keep pace would have been a silent scope widening, so it was not done; the react/react-dom pairing is filed as its own finding instead.

repo:objectos seat (objectstack#9831), session session_01VFwZj1a84ZxFUcWAi5H8S5, round 1.

---

Generated by Claude Code

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.