You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filed by the repo:objectos execution seat (objectstack#9831), session session_01VFwZj1a84ZxFUcWAi5H8S5, round 1, on the maintainer's instruction to clear the open PR list ("这个清单需要合并的也要合并", 2026-08-22), who then chose this route over the alternative when both were put to them.
Why this card exists rather than three merges
Three Dependabot PRs are open, all safe patch/minor bumps, all stalled:
They cannot be merged as they stand and cannot be rebased by this seat:
All three are ~67 commits behind and conflicted. Their only check is a build from 2026-07-19, which predates both the Node floor and Ownership & freshness gates — that green certifies nothing about today's main.
All three rewrite pnpm-lock.yaml, so exactly one could land per lap even with working rebases; each merge invalidates the rest.
@dependabot commands cannot be issued from this tooling. A sanitizer rewrites the mention on write — two separate sessions posted the command and both were stored as ·@·d·ependabot r·ebase. This is recorded on chore(deps): bump react-dom from 19.2.6 to 19.2.7 #49; it is a tooling artefact, not a mis-typed command, and no amount of re-asking will move the bot.
One 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.
Scope
apps/docs/package.json (dependencies / devDependencies only) and pnpm-lock.yaml.
Because all three declared ranges are carets that already permit their targets, the manifest edit is the small half — the substantive change is the regenerated lockfile.
⚠️ The interaction that makes this more than a version bump
main now carries a blockingunsupported rule (landed this round as ca34d36, #137/#138): every declaration's floor — >=22.12.0 — must itself satisfy everyengines.node range in pnpm-lock.yaml. A regenerated lockfile can introduce a range with a hole at 22.12.0, and that now fails CI rather than passing quietly.
Before this rule existed, a dependency bump could not redden the Node floor gate. It can now. Re-running node .github/scripts/check-node-floor.mjs after the regeneration is not optional, and a red there is a real finding, not a flake.
Definition of done
The three packages resolve to their target versions in pnpm-lock.yaml.
engines blocks are untouched in every package.json.
node .github/scripts/check-node-floor.mjs exits 0 on the regenerated lockfile.
The required build job passes.
react is already ^19.2.7 on main while react-dom sits at ^19.2.6; #49 closes that pairing gap, which is the one item here with a correctness argument behind it rather than just currency.
Once landed, #46, #49 and #50 close as superseded against the commit that carries their bumps — not on a promise. #48 (@opennextjs/cloudflare) is not in scope: it upgrades the deploy adapter itself and is held on a separate question with the maintainer.
Filed by the
repo:objectosexecution seat (objectstack#9831), sessionsession_01VFwZj1a84ZxFUcWAi5H8S5, round 1, on the maintainer's instruction to clear the open PR list ("这个清单需要合并的也要合并", 2026-08-22), who then chose this route over the alternative when both were put to them.Why this card exists rather than three merges
Three Dependabot PRs are open, all safe patch/minor bumps, all stalled:
react-dom19.2.6 → 19.2.7^19.2.6tailwindcss4.3.0 → 4.3.3^4.3.0@tailwindcss/postcss4.3.0 → 4.3.3^4.3.0They cannot be merged as they stand and cannot be rebased by this seat:
buildfrom 2026-07-19, which predates both theNode floorandOwnership & freshnessgates — that green certifies nothing about today'smain.pnpm-lock.yaml, so exactly one could land per lap even with working rebases; each merge invalidates the rest.@dependabotcommands cannot be issued from this tooling. A sanitizer rewrites the mention on write — two separate sessions posted the command and both were stored as·@·d·ependabot r·ebase. This is recorded on chore(deps): bump react-dom from 19.2.6 to 19.2.7 #49; it is a tooling artefact, not a mis-typed command, and no amount of re-asking will move the bot.One 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.ymlfires on everypnpm-lock.yamlpush tomain.Scope
apps/docs/package.json(dependencies/devDependenciesonly) andpnpm-lock.yaml.Because all three declared ranges are carets that already permit their targets, the manifest edit is the small half — the substantive change is the regenerated lockfile.
mainnow carries a blockingunsupportedrule (landed this round asca34d36, #137/#138): every declaration's floor —>=22.12.0— must itself satisfy everyengines.noderange inpnpm-lock.yaml. A regenerated lockfile can introduce a range with a hole at 22.12.0, and that now fails CI rather than passing quietly.Before this rule existed, a dependency bump could not redden the Node floor gate. It can now. Re-running
node .github/scripts/check-node-floor.mjsafter the regeneration is not optional, and a red there is a real finding, not a flake.Definition of done
pnpm-lock.yaml.enginesblocks are untouched in everypackage.json.node .github/scripts/check-node-floor.mjsexits 0 on the regenerated lockfile.buildjob passes.reactis already^19.2.7onmainwhilereact-domsits at^19.2.6; #49 closes that pairing gap, which is the one item here with a correctness argument behind it rather than just currency.Once landed, #46, #49 and #50 close as superseded against the commit that carries their bumps — not on a promise. #48 (
@opennextjs/cloudflare) is not in scope: it upgrades the deploy adapter itself and is held on a separate question with the maintainer.