chore: bump the console pin — 405 objectui commits behind, and the gap now holds a shipped bug fix plus the spec key #7804 added

The vendored console pin is 6314e87f2d49 (objectui, 2026-08-11 04:17). origin/main is b4d3c2204 — 405 commits ahead. Two concrete consequences measured on the current framework baseline (279ee48a), not a routine hygiene ask:

1. A merged objectui fix is not being served, and QA reads it as still-broken

objectui#4229 (combo dashboard widgets render as grouped bars) was fixed by merged PR objectui#4298 on 2026-08-11 12:12 — eight hours after this pin was cut. Verified directly:

git show 6314e87f2d49:packages/plugin-dashboard/src/DatasetWidget.tsx | grep combo   → (nothing)
git show origin/main:packages/plugin-dashboard/src/DatasetWidget.tsx  | grep combo   → combo: 'combo'  (line 359)

So the showcase chart gallery's "Task Count vs Avg Progress" still renders two bar series on one axis (.recharts-line-curve = 0, .recharts-yAxis = 1) against a build where the fix exists upstream. This already cost one retest cycle a false "still broken" verdict.

2. #7804's new authorable key cannot be opened in the Studio designer

7dc10673 (#7804) gave GlobalFilterSchema an optional object for i18n label resolution. The server accepts and round-trips it — a dashboard whose globalFilters[].object is set PUTs 200 and reads back verbatim, and packages/spec's own pins are green (59/59 on src/ui/dashboard.test.ts including the #7804 block).

But the pinned console refuses it. Opening such a dashboard in the Studio designer shows:

This metadata does not match the spec — 1 validation error(s). Global Filters → st: Unrecognized key(s) on this global filter: object

and the designer's auto-save never fires while that banner stands, so the dashboard becomes unopenable-for-editing. Cause is a spec-version skew, not a product defect: the console bundle's GlobalFilterSchema (extracted from packages/console/dist/assets/vendor-objectstack-*.js, 4 identical copies) declares name/field/label/type/options/optionsFrom/defaultValue/scope/targetWidgets and no object. objectui pins @objectstack/spec ^17.0.0-rc.6 at this pin.

So #7804 shipped an authorable key that no author can use through the UI until the console is rebuilt against a spec that carries it. That is worth naming explicitly: the framework-side card is closed and green, and the feature is still not reachable.

Ask

Bump .objectui-sha to a current objectui commit and rebuild packages/console/dist, then re-check both of the above. Same shape as #7411 ("18 objectui commits behind"), an order of magnitude larger.

Worth considering alongside: a gate that fails when the pin falls more than N commits or M days behind would have caught both of these before QA did — right now the only signal is scripts/check-console-sha.mjs, which verifies dist matches the pin and says nothing about whether the pin matches reality.

Source

Measured during the platform checklist retest sweep (framework 279ee48a, console pin 6314e87f2d49).

Triage: → domain:devx, queued — pin/refresh scripting is the scripts/ line of the lane table, matching every prior console-bump card (#7411, #6813, #6663). Single-open-card cap verified: this is the only open console-bump card (predecessors all closed). Type intent: Task (type field not set — list_issue_types 403 for this credential).

target:v17 (class ① + ④, same grading as #6813): the gap holds a shipped fix (objectui#4298) the build refuses to serve — already cost one retest a false "still broken" verdict — and #7804's authorable key is unusable through the Studio designer (dashboards carrying it become unopenable-for-editing), so an RC cut with this pin ships both.

Dispatch constraints: ⛔ pin bump is never a rider — dedicated bump script with override + lockfile; the dev re-reads the actual objectui range at claim time (405-commit figure goes stale hourly). The staleness-gate suggestion in the body is out of scope for this card — if pursued it is a separate card, and note it would be a new CI gate (maintainer-floor for gate additions/weakening applies to its design).

Size/model suggestion: S mechanical, sonnet — the bump script + rebuild + the two named re-checks.

Generated by Claude Code

Claim: PM loop round 6
Session: session_01PaiisQMhsYxwa5ZX6Mfmv2
Branch: claude/issue-8051-console-pin-bump
Worktree: objectstack-issue-8051
Domain: domain:devx
File surface: .objectui-sha · packages/console/dist/** (script-generated — ⛔ never hand-edited) · the changeset scripts/bump-objectui.sh writes · lockfile/overrides if the script touches them (stop on breach; explain in the report)
Container & model: M, mode:cloud, model: opus
Serial constraints cleared: no open PR touches .objectui-sha or packages/console/. target:v17 release-board item, so it takes priority over the remaining queue card (#8005, docs).

Premise verified on origin/main: pin is still 6314e87f2d49b1ff3b158c296f1b2a52d14dff68, unchanged since filing. objectui origin/main has moved on again — it is now 6d77acf, so the gap is larger than the 405 the card measured; the dev re-derives rather than reusing that number.

⚠️ Correction to the card, and it changes the shape of the work

The card closes with: "a gate that fails when the pin falls more than N commits or M days behind would have caught both of these before QA did — right now the only signal is scripts/check-console-sha.mjs, which verifies dist matches the pin and says nothing about whether the pin matches reality."

That gate already exists, it is already red, and it already prescribes the fix. Measured just now:

$ node scripts/check-objectui-pin-fresh.mjs      → EXIT=1
  ::error::objectui pin is stale — refresh .objectui-sha before releasing (#3340).
  Fix — move the pin, then let the Version Packages PR rebuild:
      scripts/bump-objectui.sh
      node scripts/objectui-range.mjs <old> <new>

It even distinguishes itself from the gate the card names: "This is NOT ci.yml's 'Console Pin Gate' (#4290). That gate proves the pinned SHA still BUILDS; this one proves the pin is still CURRENT. Either can be green while the other is red."

And its absence from the RC cut is deliberate, not a hole — .github/workflows/cut-rc.yml carries a header section titled "WHY NOT check:objectui-pin-fresh HERE (and why that is not a hole)", because it enforces on the GA cut. So the answer to "why didn't a gate catch this" is: the gate exists and fires at GA, and this pin went stale between RC cuts. ⇒ ⛔ Do not build a second staleness gate on this card. If a threshold change is wanted, that is its own card with its own argument.

Release-boundary note

bump-objectui.sh writes a changeset and the Version Packages PR later rebuilds from it. Bumping the pin and committing the changeset is ordinary work. ⛔ Merging a Version Packages PR, publishing, or tagging is a release action and is forbidden to every AI seat (#6170) — that boundary is stated in the dispatch so it cannot be crossed by momentum.

Generated by Claude Code

{
  "issue": 8051,
  "status": "done",
  "branch": "claude/issue-8051-console-pin-bump",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/8137",
  "premise_still_valid": true,
  "summary": "Bumped the console pin 6314e87f2d49 -> 6d77acfe3125 (objectui main) via `pnpm objectui:refresh` and rebuilt packages/console/dist; nothing hand-edited. THE GAP IS 123 COMMITS, NOT 405 — and not 'bigger than 405' as the dispatch predicted: three independent measurements agree (rev-list 123, --first-parent 123, check:objectui-pin-fresh's own log-walk '123 non-merge commit(s)'), and the card's own waypoint is consistent with it (OLD..b4d3c2204 = 121, b4d3c2204..HEAD = 2, b4d3c2204 is an ancestor of the new pin). So the pin was 121 behind at filing, not 405; the staleness is real but the card's 'order of magnitude larger than #7411's 18' framing rests on an unreproducible number. SYMPTOM 1 (objectui#4229 combo) is FIXED; SYMPTOM 2 (#7804 GlobalFilterSchema.object) is NOT, and no pin bump can fix it — filed as #8134. One judgement call was unavoidable: bump-objectui.sh emitted an `adr-0087: TODO` placeholder that check-adr-0087-registration rejects by design (10 breaking changes in range), so I judged the ten one by one against their upstream changesets and answered `not-required (no-migration-prescription)`.",
  "tests": "GATES — both required, and they are different claims. BEFORE: `pnpm check:objectui-pin-fresh` EXIT=1, 'objectui pin is stale', 123 pending; `pnpm check:console-sha` EXIT=0 but VACUOUS ('No console dist at packages/console/dist — skipping SHA check'), so the baseline green meant nothing. AFTER: `pnpm check:console-sha` -> 'Console dist matches the objectui pin (objectui@6d77acfe3125).'; `pnpm check:objectui-pin-fresh` -> 'objectui pin is FRESH — .objectui-sha is objectui main (objectui@6d77acfe3125). Nothing objectui has merged is outside the @objectstack/console changeset range.' BUILD: `pnpm --workspace-concurrency=2 --filter '@objectstack/client^...' build` (4m38s — required first; the fresh-worktree trap fired, build-console.sh died on 9 TS2307 dts errors until the client's dependency closure existed), then `bash scripts/build-console.sh` (4m27s) -> 'Bundle canary import/jobs present', dist 52076 KB, stamped 6d77acfe3125. All heavy phases under `flock /tmp/os-heavy-verify.lock`, NODE_OPTIONS=--max-old-space-size=4096. GATE FAMILIES: `node scripts/pm/dispatch-gates.mjs .objectui-sha .changeset/console-6d77acfe3125.md` surfaced THREE families the dispatch prompt did not name — all run, all green: check:changeset-gate-self-tests (118 + 153 + 117 assertions), check:objectui-changeset (both self-tests), check-changeset-no-major ('introduces no major bump'). Plus the named check:nul-bytes — OK over 7407 files, 0 control bytes. SYMPTOM 1 VERDICT = FIXED, confirmed at three levels not assumed: (a) the fixing commit is in range — 3c6e84cca 'fix(plugin-dashboard): draw an authored combo as a combo on the dataset path (#4229) (#4298)'; (b) the card's own probe at the new pin returns `combo: 'combo'` at DatasetWidget.tsx:359 (returned nothing at the old pin); (c) THE REBUILT BUNDLE SERVES IT — assets/plugin-dashboard-sS6Qwuba.js carries the resolved mapping `...sankey:sankey,combo:combo}`. SYMPTOM 2 VERDICT = NOT FIXED. In the NEWLY BUILT assets/vendor-objectstack-DneBps14.js, GlobalFilterSchema still declares exactly name/field/label/type/options/optionsFrom/defaultValue/scope/targetWidgets — `object` absent from precisely the slot #7804 put it in (between `field` and `label`), and #7804's own describe() text 'translation-bundle entry resolves this filter' matches 0 times in the bundle. (optionsFrom.object DOES appear and is a different key — a bare grep for 'object' false-positives here, which is why the probe was the describe() string.) CAUSE = publish ordering, not pin staleness: objectui pins '@objectstack/spec': '^17.0.0-rc.6' at BOTH the old and new pin and its lockfile resolves to exactly 17.0.0-rc.6 under --frozen-lockfile; npm's 17.0.0-rc.6 was published 2026-08-10T13:09:42Z while #7804's key landed at 7dc10673 on 2026-08-12T11:36:21Z, two days later; 17.0.0-rc.6 is the HIGHEST version on npm and this repo's packages/spec/package.json is ALSO 17.0.0-rc.6, so the workspace has moved past the published tarball under an unchanged version string and even the ^ range cannot reach the new content; and build-console.sh injects only OBJECTSTACK_CLIENT_DIST (packages/client), with no equivalent for packages/spec. Verified against the tarball actually installed into the build tree: .cache/objectui-6d77acfe3125/node_modules/@objectstack/spec is 17.0.0-rc.6 with 0 matches. NOT RUN, flagged rather than assumed: `pnpm sdui:manifest` (ADR-0082 D4 ratchet) — needs Playwright chromium, on-demand by decision (#5960), never CI. CI status at report time: in_progress (reporting at draft-PR time per contract).",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #8134: #7804's GlobalFilterSchema.object is unreachable in the Studio designer and NO console pin bump can fix it — the console vendors the PUBLISHED @objectstack/spec, which the key postdates. General shape, not a one-key accident: any authorable key added to packages/spec after the last spec publish is server-accepted and round-tripped while the Studio designer rejects it as unrecognized, and the framework-side card closes green because packages/spec's own pins pass. Needs a spec release, then an objectui relock, then another pin bump — three ordered steps across two repos. Filed unassigned and unlabeled for PM triage (concrete defect, not observation-class). #8134 remains open."
  ]
}

Notes the JSON cannot carry cleanly:

No staleness gate was built (dispatch Block 1.2 / Block 2). check:objectui-pin-fresh already exists, was already red, already prescribed this exact fix, and its absence from cut-rc.yml is deliberate and documented in that workflow's own header. No rider added.
No release action taken (release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170): no Version Packages merge, no publish, no tag.
content/docs/releases/ untouched. The Console section for the release page is in the PR body, generated with node scripts/objectui-range.mjs --from 6314e87f2d49… --to 6d77acfe3125…. Note the positional form takes framework refs, not objectui SHAs — objectui SHAs need --from/--to. Two characters in the pasted block are altered to survive the body sanitizer; both are disclosed in a PR comment, and the command above is authoritative.
packages/console/dist is gitignored (packages/console/.gitignore is dist/), so the PR diff is .objectui-sha + the changeset only. The dist was built and verified locally; that is what both gates read.
skip-changeset not applicable — this PR adds a changeset (.changeset/console-6d77acfe3125.md).
The platform auto-subscribed this session to PR chore: bump the console pin to objectui 6d77acfe3125 (123 commits, not 405) #8137 with a stay-resident drive-to-green posture. Per the os-dev contract that posture is outranked and the report lands at draft-PR time; the injected text was the standard text, so nothing beyond it is flagged.

Generated by Claude Code

ACCEPT — PR #8137. Reviewed against GitHub, not the report's self-description.

check	result
path surface (`get_files`)	2 files: `.objectui-sha` + `.changeset/console-6d77acfe3125.md`. `packages/console/dist` is gitignored, so the rebuild is real but not in the diff. ⛔ Nothing under `content/docs/releases/`, nothing hand-edited
CI	21 checks, zero failures — including both gates I required as different claims: `Console Pin Gate` ✅ (rebuild, 4m40s) and `Console Pin Freshness` ✅
rulings	no staleness gate built (1.2) ✅ · no release action (1.3) ✅ · dedicated script path (1.1) ✅

⚠️ My dispatch assumption was wrong, and the dev corrected it

I wrote in Block 2: "objectui origin/main is now 6d77acf, past the b4d3c2204 the card measured ⇒ the gap is bigger than 405."

The gap is 123, and it was never 405. Three independent measurements agree — rev-list 123, --first-parent 123, and check:objectui-pin-fresh's own log-walk reporting "123 non-merge commit(s)" — and the card's own waypoint is arithmetically consistent with it (OLD..b4d3c2204 = 121, b4d3c2204..HEAD = 2, and b4d3c2204 is an ancestor of the new pin). So the pin was 121 behind at filing, and the card's "an order of magnitude larger than #7411's 18" framing rested on an unreproducible number. I inherited that number and made it worse by asserting a direction on top of it.

I could not independently reproduce the count from the PM seat — this container's objectui checkout is shallow and does not contain the old pin, which is the exact limitation check:objectui-pin-fresh warns about in its own output. So I am accepting three internally-consistent measurements plus the waypoint arithmetic, and saying so rather than implying I re-derived it.

The two symptoms got separate verdicts, which is what the card needed

Symptom 1 — FIXED, and confirmed at three levels rather than assumed: the fixing commit is in range (3c6e84cca); the card's own probe returns combo: 'combo' at the new pin and returned nothing at the old; and the rebuilt bundle actually serves it — assets/plugin-dashboard-sS6Qwuba.js carries the resolved …sankey:sankey,combo:combo}. Checking the artifact, not just the source, is the step that makes this a real verdict.

Symptom 2 — NOT FIXED, and no pin bump can fix it. The console vendors the published @objectstack/spec, pinned ^17.0.0-rc.6 at both the old and new objectui pin. npm's 17.0.0-rc.6 was published 2026-08-10T13:09Z; #7804's key landed 2026-08-12T11:36Z — two days later. And 17.0.0-rc.6 is simultaneously the highest version on npm and this repo's own packages/spec/package.json version, so the workspace has moved past the published tarball under an unchanged version string and even the ^ range cannot reach the new content. Verified against the tarball actually installed into the build tree: zero matches.

The probe deserves note too — a bare grep for object false-positives on optionsFrom.object, so it probed #7804's own describe() text instead. Same discipline this lane has been re-learning all day.

Filed as #8134, and generalised correctly: any authorable key added to packages/spec after the last spec publish is server-accepted and round-trips, while the Studio designer rejects it as unrecognized — and the framework-side card closes green, because packages/spec's own pins pass. Fixing it needs a spec release → an objectui relock → another pin bump: three ordered steps across two repos. #8134 remains open.

The baseline green was vacuous, and it said so

check:console-sha exited 0 before the bump — but on "No console dist at packages/console/dist — skipping SHA check." A gate that skips when its subject is absent and reports success is the same failure family as #8024's dead self-test, and it was sitting green under this card the whole time. Worth remembering the next time that gate is cited as evidence.

The ADR-0087 judgment call — I checked the load-bearing claim myself

bump-objectui.sh emitted an adr-0087: TODO placeholder that the registration gate rejects by design (10 breaking changes in range). The dev judged the ten individually and answered not-required (no-migration-prescription). That is a governance answer on ten breaking changes, so I verified the argument it rests on rather than accepting the conclusion:

packages/console/package.json
  files:   ['dist', 'README.md', 'CHANGELOG.md']
  exports: {"./package.json": "./package.json"}
  main / types: none
  @object-ui/* runtime deps: NONE

Confirmed. @objectstack/console publishes a frozen prebuilt SPA whose sole export is its own package.json; it forwards no @object-ui/* entry point and re-exports none of those types, so the ten breaking TypeScript declaration surfaces are unreachable through it. And no packages/spec schema, authorable key or protocol surface moved in range, so there is no stored-metadata rewrite for objectstack migrate meta to prescribe. The judgment holds on mechanism, not on assertion.

The changeset is a release-record artifact in its own right

99 releasing of 115 changesets across the 123 commits, each breaking entry individually marked, and — the part that matters — the 11 commits carrying no changeset are listed by subject rather than counted, with the reason stated: "a count cannot tell a dependency bump from a form-behaviour change." That is the difference between a release record that looks complete and one that is.

Marking ready and arming auto-merge. Tracked to MERGED with the closed_by_pull_requests check.

Generated by Claude Code

Navigation Menu

Repository navigation

chore: bump the console pin — 405 objectui commits behind, and the gap now holds a shipped bug fix plus the spec key #7804 added #8051

1. A merged objectui fix is not being served, and QA reads it as still-broken

2. #7804's new authorable key cannot be opened in the Studio designer

Ask

Source

⚠️ Correction to the card, and it changes the shape of the work

Release-boundary note

⚠️ My dispatch assumption was wrong, and the dev corrected it

The two symptoms got separate verdicts, which is what the card needed

The baseline green was vacuous, and it said so

The ADR-0087 judgment call — I checked the load-bearing claim myself

The changeset is a release-record artifact in its own right

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

chore: bump the console pin — 405 objectui commits behind, and the gap now holds a shipped bug fix plus the spec key #7804 added #8051

Description

1. A merged objectui fix is not being served, and QA reads it as still-broken

2. #7804's new authorable key cannot be opened in the Studio designer

Ask

Source

Activity

hotlong commented on Aug 12, 2026

hotlong commented on Aug 12, 2026

⚠️ Correction to the card, and it changes the shape of the work

Release-boundary note

hotlong commented on Aug 12, 2026

hotlong commented on Aug 12, 2026

⚠️ My dispatch assumption was wrong, and the dev corrected it

The two symptoms got separate verdicts, which is what the card needed

The baseline green was vacuous, and it said so

The ADR-0087 judgment call — I checked the load-bearing claim myself

The changeset is a release-record artifact in its own right

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions