chore: bump the objectui pin to main (9a3daf8d37ad) with the derived @objectstack/console changeset

[os-project-manager]

Fixes#10129

Re-run at a newer objectui SHA. pnpm objectui:build is now GREEN — that was the one thing blocking this card, and it is the reason this re-run exists. Kept a draft; the PM marks it ready once CI's Console Pin Gate confirms it.

The bump

old pin (on main)	82a94170c4058d451ce3ac179d99296d90554479 — objectui, 2026-08-17 21:51:40 +0000
new pin	9a3daf8d37ad973a621e5edd276fe32467f90684 — objectui, 2026-08-20 08:41:53 +0000
commits crossed	151 (non-merge: 151 — the range contains no merge commits)
resolved bump	@objectstack/console: minor

Produced by scripts/bump-objectui.sh 9a3daf8d37ad973a621e5edd276fe32467f90684, then pnpm sdui:manifest. The range is measured from the pin on origin/main, not from the superseded 0fd11444a89e — .changeset/console-0fd11444a89e.md is deleted and .changeset/console-9a3daf8d37ad.md replaces it. There is exactly one console changeset, and no file was hand-edited except the ADR-0087 disposition the script explicitly hands to a human.

The SHA was passed explicitly, deliberately. The shared ../objectui checkout is not on main — it sits on another agent's branch (claude/pm-dispatch-upgrade-jyngga), so the script's default (rev-parse HEAD) would have pinned that branch tip. 9a3daf8d37ad is origin/main at bump time, re-read after git -C ../objectui fetch origin main.

Why minor. The level is the highest level objectui itself declared across the range, never a guess off commit subjects (#4731). Measured over the range: 108 releasing changesets — 20 minor, 88 patch, 0 major. objectui declares no major inside a launch window (its own check-changeset-no-major.mjs), so the highest declared level is minor and that is what the changeset carries. Five of those entries are breaking by the author's own annotation in the changeset body rather than by declared level (#6099); each is marked **BREAKING** in the list.

Blocker — cleared upstream by objectui#5390

The previous revision of this PR was blocked, and the history is kept rather than deleted: scripts/build-console.sh could not build objectui at 0fd11444a89e, dying in generateBundle with

[plugin assert-lazy-linter-stays-lazy]
RolldownError: counter-probe failed: no eagerly loaded chunk contains an `@objectstack/spec` module.

objectui 6d5368ac8 (objectui#5323) had added that probe with a private module-id regex /@objectstack[\\/+]spec/, which our OBJECTSTACK_SPEC_DIST injection (#8134) defeats — the injection rewrites all 18 @objectstack/spec* specifiers to absolute paths in the framework tree, which carry no @objectstack segment, so zero module ids matched and the counter-probe correctly refused a verdict. Filed from this side as #10136, dispatched upstream as objectui#5388.

objectui#5390 merged that fix, and it is in this pin. Verified by content in the tree this PR actually built (.cache/objectui-9a3daf8d37ad/apps/console/vite.config.ts), not by sha ancestry:

• :98 — assertLazyLinterStaysLazy(specTest: RegExp) now takes the spec module-id test as a parameter
• :414 — specModuleTest comes from specDistInjection.specModuleTest when OBJECTSTACK_SPEC_DIST is set, and falls back to the literal otherwise
• :435 — registered as assertLazyLinterStaysLazy(specModuleTest), unconditionally, in the plugins array

So the counter-probe now reads the same producer the vendor-objectstack chunk group has always read. One consumer that did not read its producer, fixed at the producer's side of the contract.

pnpm objectui:build — green, and the probe really ran

→ Copying dist → /home/user/objectstack-issue-10129/packages/console/dist
✓ Bundle canary 'import/jobs' present — framework client is in the bundle.
✓ Console bundle carries THIS tree's @objectstack/spec, and only it.
present (injected only): "Accepted MIME types / extensions for a `file` cell's picker …"
absent (vendored only): "Additional custom metadata types"
✓ @objectstack/console dist ready (52004 KB) from objectui@9a3daf8d37ad

Exit 0. Two things make this a real green rather than a skipped probe: the plugin is registered unconditionally at line 435 of the config that built (quoted above — it has no env guard), and the build's own spec-provenance assertion fired, which is the injection being active. The failure mode being ruled out was a build that dies insidegenerateBundle; this one walked past it and wrote dist/.

Walkability — no deepening needed, and the reason is the parent walk, not the boundary dates

--check-walkable came back clean on the first ask, so git fetch --unshallow never ran and OBJECTUI_NO_DEEPEN was never set:

✓ objectui-changeset-digest: 82a94170c405..9a3daf8d37ad walks completely in /home/user/objectui.

Confirmed independently by the sound test: walking all 151 commits in the range and resolving every parent with git cat-file -e gives 0 missing.

Correcting the previous revision of this body, which argued the same conclusion from the wrong evidence: it claimed the two .git/shallow boundaries were "both older than the old pin and neither inside the range". Older by date is not the same as ancestor, and on a shallow repo merge-base --is-ancestor cannot settle it either — its own inputs are truncated. That argument is withdrawn. The reason to trust this range is the 0-missing-parents walk, and nothing else.

No ⚠️ Degraded list banner in the emitted changeset — it is derived, and the accounting line says so: 108 releasing of 125 changesets added across 151 non-merge commits, omitting 17 release-nothing changesets and 27 commits carrying no changeset.

The free correctness check still passes. objectui e7c3b3e91 (the @changesets/cli v3 migration, objectui#5307) ships an empty-frontmatter changeset and is inside the range; it is absent from the list, as it must be — the digest is reading declarations, not commit subjects.

CONSOLE_CHANGES_MAX did fire — the list is capped at 100 of 108

Left at its default 100, so the rendered list carries 100 entries and closes with the script's own honest line:

- …and 8 more releasing changesets in this range (list capped at 100; see the objectui range below).

The real count is 108 releasing changesets. The list is complete for 100 of them and must not be read as the whole range; the range itself (82a94170c405...9a3daf8d37ad) is printed in the entry for anyone recompiling it. Kept at the default rather than raised, so the artifact is reproducible by anyone running the documented command.

ADR-0087 disposition — re-derived for the grown range, not copied

The script emitted a fresh adr-0087: TODO placeholder (#6494 makes that a human's answer). It was re-derived, and the re-derivation produced a measurement worth stating plainly, because the expectation going in was that the range would grow to six breaking entries:

It is still FIVE. The range gained exactly two commits over the previous run — objectui 413629a89 (docs/skills plus one pin test) and 9a3daf8d3 (objectui#5390, build-config only) — and both ship an empty-frontmatter, release-nothing changeset. Read their frontmatter directly rather than inferring it from the subjects. So the declared-breaking set did not grow with the range, and the console list is byte-identical to the previous revision's apart from the tip SHA, the accounting line and the range line.

Each of the five was still judged again, one at a time, against its upstream changeset, and the three repo-side facts the argument leans on were re-measured at this HEAD rather than carried over:

objectui commit	what breaks	why no ledger entry
9c60144b5	NavigationRenderer drops resolveGroupLabel / resolveItemLabel	React props; the isCustomized guard made them structurally unreachable, and nav localization is already owned by the server-side /meta boundary (translateApp, re-measured present in packages/spec/src/system/i18n-resolver.ts)
f6fc565b0	ObjectMetricWidgetProps adopts I18nLabel on four members	a widening of a props interface, catching objectui up to a retirement this repo already performed at 17.0.0-rc.6 (#5055) — that retirement's ledger answer is its own
4dbcae756	dashboardComponents re-keyed to the 8 registered schema type keys	a JS export map's keys, not an authorable metadata key; zero in-tree consumers measured upstream
d2ce342fc	structured confirm object on actions becomes a ?: never tombstone	in objectui's own type. Re-measured at this HEAD: packages/spec/src/ui/action.zod.ts still declares confirm as a live alias of confirmText, so the authorable surface is unchanged and no stored action row needs rewriting
a2a974779	FieldValidationRules.pattern.value narrows to RegExp	hand-written-TypeScript-only by construction (JSON metadata cannot hold a RegExp); the upstream changeset states the metadata route is unaffected

Plus the reachability fact, re-measured against packages/console/package.json at this HEAD: @objectstack/console publishes a frozen prebuilt SPA — files is ["dist", "README.md", "CHANGELOG.md"], its sole exports entry is ./package.json — so it forwards no @object-ui/* module entry point and re-exports none of these types, props or maps. This diff is .objectui-sha plus the changeset and nothing else.

pnpm sdui:manifest — ran, green, no tracked files changed

The other half of the procedure (ADR-0082 D4, #5960), re-run because the manifest is a function of the pin and the pin moved:

✓ wrote 57 public blocks → packages/console/dist/sdui.manifest.json
Summary: 90 spec-only divergences, 0 blocks missing from the registry.
## Baseline ratchet
✓ no new DECLARATION divergence vs accepted baseline

So packages/spec/react-declaration-parity.baseline.json needs no update and is not touched by this PR; git status is clean after the run.

The Playwright revision mismatch is unchanged from the first run and is an environment fact, not a repo one: the objectui tree at this pin resolves playwright@1.62.1, which wants chromium build 1234, while /opt/pw-browsers holds 1194. Fixed exactly as docs/releases-maintenance.md prescribes — a symlink tree in the session scratchpad mimicking the newer per-browser layout, PLAYWRIGHT_BROWSERS_PATH pointed at it for that one invocation. playwright install was never run. The ENOENT on a missing packages/console/dist/ (#10138) did not bite this time, because the console build now succeeds and creates it.

How the branch was brought up to main

By merge, not rebase. The previous tip (656f413a4) was already pushed, so rebasing it would have required a force-push, which AGENTS.md §branch-hygiene 3 forbids outright. 39a3befa8 merges origin/main in; a71b20ae0 carries the re-run bump on top. The net diff against main is still exactly two files.

Verification — all at a71b20ae0

Union re-derived from the actual changed paths with node scripts/pm/dispatch-gates.mjs .objectui-sha .changeset/console-9a3daf8d37ad.md .changeset/console-0fd11444a89e.md, run after the final commit:

✓ check-empty-changeset --self-test: 118 assertions over real temp git repos
✓ check-adr-0087-registration --self-test: 212 assertions over real temp git repos
✓ check-changeset-no-major --self-test: 116 assertions
✓ objectui-changeset-digest --self-test: all checks passed
✓ objectui-range --self-test: all checks passed
✓ check-adr-0087-registration: 1 declared-breaking changeset(s), each carrying an ADR-0087 disposition
✓ This diff introduces no `major` bump.
✓ No empty-frontmatter changeset introduced by this diff (1 declaring changeset(s) added).
✓ check-nul-bytes: OK (scanned 6383 text file(s))
✓ objectui pin is FRESH — .objectui-sha is objectui `main` (objectui@9a3daf8d37ad).
✓ pnpm objectui:build — exit 0, dist ready from objectui@9a3daf8d37ad
✓ pnpm sdui:manifest — 57 public blocks, no new declaration divergence

Left to CI: the full lint farm, and Console Pin Gate — which is the one this re-run exists to turn green, and which now passes locally under the same scripts/build-console.sh it runs.

Non-goals honoured

No publish, no version tag, no release-workflow dispatch, no Version Packages PR touched. objectui#4655 untouched — the pin is a SHA, not an npm version. .github/workflows/cut-rc.yml, scripts/bump-objectui.sh and content/docs/releases/** untouched. Nothing in the objectui repo was edited.

---

Generated by Claude Code

[os-project-manager]

PM review-of-record — checked against the repos themselves, not against the dev seat's report.

Verified independently, and it holds:

• New pin 0fd11444a89e is objectui origin/main. Confirmed by git rev-parse.
• The range walks completely: 149 commits, and I walked every one checking each parent with git cat-file -e — 0 missing. So "no deepening was needed" is right, and the card's claim that the shallow trap was live here was wrong. The correction stands.
• Diff is 2 files, .objectui-sha + the changeset. Matches the declared territory exactly.

One supporting claim in the PR body is inaccurate, though the conclusion it supports is not. The body says the two .git/shallow boundaries — a5eb8271 (2026-08-13) and db8184cd (2026-08-16) — are "both older than the old pin and neither inside the range". Measured: db8184cd is an ancestor of the old pin, but a5eb8271 is not. Older by date is not the same as ancestor, and on a shallow repo merge-base --is-ancestor can't be trusted for this anyway — its own inputs are truncated.

That doesn't change the verdict, because the parent-completeness walk is the sound test and it came back clean. Worth fixing in the body so the evidence matches the claim: the reason to trust this range is the 0-missing-parents walk, not the boundary dates.

The blocker is real.#10136's diagnosis reproduces line-for-line against objectui origin/main — assertLazyLinterStaysLazy() (76–78) carries private SPEC/LINT regexes and is registered with no argument (366), while vendorObjectstackTest (345–347) is injection-aware and the chunk grouping at 442 already consumes it. One consumer of resolveSpecDistInjection doesn't read its producer. Agreed on where the fix belongs.

Dispatched upstream: objectui#5388, carrying the contract-first fix, the explicit LINT-half decision, and a reverse-verification requirement (make @objectstack/lint eager and prove the assertion still goes red — a probe that passes because it stopped looking would be a regression, which is #5323's own reasoning turned on the change that touches it).

This PR stays a draft and does not merge. The pin here is fresh but not buildable under our injection. Once objectui#5388 lands, re-run scripts/bump-objectui.sh at the fixed objectui commit and replace the changeset — do not merge this SHA.

Also noting for the record, because it nearly produced a wrong pin: the shared ../objectui checkout sits on another agent's branch, so bump-objectui.sh's default rev-parse HEAD would have pinned that branch tip. The dev seat caught it and passed the SHA explicitly. That hazard belongs in the script's help text, not in each operator's memory.

---

Generated by Claude Code

[os-project-manager]

Console Pin Gate is red on CI, and it is the predicted failure — not a second, different one. Checked the job log rather than assuming the prediction was self-fulfilling.

[plugin assert-lazy-linter-stays-lazy]
RolldownError: counter-probe failed: no eagerly loaded chunk contains an `@objectstack/spec` module.
(entry chunks: assets/index-mpVXni3j.js; eager chunks: 59/508)

Same plugin, same message, and — the part that makes it a match rather than a resemblance — the same entry chunk name and the same 59/508 eager-chunk count as the local reproduction in the PR body. The runner reproduced the local run exactly.

One incidental confirmation from the same log: @objectstack/lint@17.0.0 still resolves out of node_modules/.pnpm/ (it appears in the browser-externalisation warnings for module/fs/path). So the probe's LINT regex still matches and only the SPEC half is defeated — which is what the diagnosis says, and it is why the build fails on the counter-probe rather than on the linter assertion itself.

No fix is pushed here and none should be: the defect is not in this diff. It is in objectui, dispatched as objectui#5388. This PR stays a draft until that lands, at which point the bump gets re-run at the fixed objectui commit — merging this SHA would pin a console the release pipeline cannot build.

---

Generated by Claude Code

[os-project-manager]

Unblocked — objectui#5390 merged, and the bump is being re-run at a newer SHA.

Verified by content on objectui origin/main (9a3daf8d37ad973a, 2026-08-20 08:41:53), not by sha ancestry:

• apps/console/vite.config.ts:98 — assertLazyLinterStaysLazy(specTest: RegExp) now takes the test as a parameter
• :435 — registered as assertLazyLinterStaysLazy(specModuleTest)
• :414–415 — specModuleTest comes from the injection when OBJECTSTACK_SPEC_DIST is set
• scripts/vite-objectstack-spec-dist.ts:271 — the producer publishes specModuleTest: widen(specModuleTest) beside vendorChunkTest

So the counter-probe can now see the injected spec, which is the single condition Console Pin Gate was failing on.

This branch is not being merged as it stands. The pin it currently carries (0fd11444a89e) predates the fix, so merging it would pin a console the release pipeline still cannot build. The dev seat is re-running scripts/bump-objectui.sh at the new objectui main, replacing .changeset/console-0fd11444a89e.md rather than keeping both, and re-deriving the ADR-0087 disposition for the grown range — an answer argued for five breaking changesets is not automatically right for six.

The one thing this re-run must actually demonstrate, and the reason it exists: pnpm objectui:build succeeding locally before the push. Last time it died on counter-probe failed: no eagerly loaded chunk contains an @objectstack/spec module; a re-run that doesn't show that command going green is not evidence of anything.

Staying a draft until Console Pin Gate is green on CI.

---

Generated by Claude Code