The locked `@objectstack/spec@17.0.0` does not carry the spec keys already merged upstream — `GanttConfigSchema.viewMode` (#5074) is the first card measurably stalled on it

[os-support-ai]

Filed by the repo:objectui execution seat (PM round 17, session session_01RV6yuVCxymHYE16PL9vQkE) as the machine-readable unlock for #5074 and the cards chained behind it. Filed unassigned, not claiming. ⛔ This card does not authorise anyone to publish a release — that is a maintainer action.

Restart-when: a published @objectstack/spec version resolvable under this repo's ^17.0.0 range carries viewMode on GanttConfigSchema — check with: node -e "const s=require('@objectstack/spec/ui'); console.log(Object.keys(s.GanttConfigSchema.shape ?? {}).includes('viewMode'))" after a lockfile refresh

What was measured, and when

origin/main of both repos, 2026-08-19, during the dispatch-precondition check that #5074's ruling explicitly requires:

reading	value
objectui package.json / pnpm-lock.yaml	@objectstack/spec at ^17.0.0, lockfile-exact 17.0.0
objectstack packages/spec/src/ui/view.zod.ts, GanttConfigSchema	carries viewMode: z.enum(['day','week','month','quarter','year']).optional()
the commit that added it	870f710e7 — "feat(spec): declare viewMode on GanttConfigSchema (#9463) (#9489)", ancestor of objectstack main ✅
objectstack packages/spec/package.json version on main	still 17.0.0
.changeset/gantt-viewmode-declared.md on objectstack main	still present — unreleased
unreleased changesets in objectstack .changeset/	303

Counter-probe on the schema read (a zero is not a reading): the same sed window shows resourceView present at the expected offset, so the file and range are the right ones — viewMode is genuinely there in source.

Conclusion: the source half has landed; the published half has not. The version objectui installs is the same 17.0.0 that predates the commit, so the key is not in node_modules here and any objectui-side declaration of it today would publish a key the save gate refuses — the preview-works / save-refuses trap.

Why this is its own card rather than a line in #5074

#5074's maintainer ruling names the precondition and its two exits: "verify the .objectstack-sha spec pin covers 870f710e7 (REST compare, not local merge-base); if not yet covered, wait or document the fork window per protocol." Two corrections to that instruction, both measured:

1. objectui has no .objectstack-sha. That file is the cloud repo's mechanism. objectui consumes the spec as a published npm package, so the pin is package.json + pnpm-lock.yaml and the covering event is a release, not a commit.
2. Because the covering event is a release, "wait" has no issue to wait on — which is what this card supplies. pm:blocked needs a Blocked-by: #N; plugin-gantt: schema 上的 viewMode 只被 ResourceWorkload 分支读,时间轴静默忽略 —— 且该键在 ObjectGanttSchema 与 spec 的 GanttConfigSchema 都未声明 #5074 now has one.

Known dependants

• plugin-gantt: schema 上的 viewMode 只被 ResourceWorkload 分支读,时间轴静默忽略 —— 且该键在 ObjectGanttSchema 与 spec 的 GanttConfigSchema 都未声明 #5074 — ObjectGanttSchema declares viewMode, timeline branch wires it, (schema as any) cast retired. Ruled and ready; blocked only by this.
• plugin-gantt README 教的整片 schema 键面渲染器一个都不读 —— tasks / viewMode / object / startField 全零命中,照抄即空图 #5057 — the plugin-gantt README half; chains behind plugin-gantt: schema 上的 viewMode 只被 ResourceWorkload 分支读,时间轴静默忽略 —— 且该键在 ObjectGanttSchema 与 spec 的 GanttConfigSchema 都未声明 #5074 by its own note.
• skills/objectui/guides/schema-expressions.md 的「Data binding with bind」示例用 data-table + bind,而 data-table 全篇不读 bind —— 照抄即空表 #5126 — already pm:blocked behind the same chain.

Any other objectui card that needs a spec key merged upstream after 17.0.0's publication belongs behind this one too. ⛔ Do not work around it by declaring the key objectui-side only.

[os-support-ai]

Second dependant found, independently, within the hour: #5042. PM round 17.

ListMapConfigSchema landed on objectstack main via objectstack#9370 (2026-08-17, MERGED) — after the 17.0.0 GA cut — so a consumer pinned to ^17.0.0 cannot see it, exactly as with GanttConfigSchema.viewMode (#5074). #5042 is now pm:blocked behind this card.

That makes the pattern worth stating plainly, because it is the reason this card exists rather than a note on one issue:

merged upstream ≠ published ≠ pinned here. Three distinct states. Blocked-by: <objectstack card> closing only proves the first.

#5042's own history is the cautionary version: it was probed on 2026-08-18 08:06Z and stopped ("the pin is rc.2, which predates the landing"), then the pin moved to GA 17.0.0 — and it still failed, for the second of the three states. A card that reads "the pin moved past the blocker" is not the same statement as "the published build carries the key".

Running list of dependants

card	key it needs	upstream landing
#5074	GanttConfigSchema.viewMode	objectstack#9463 / PR#9489 (870f710e7)
#5042	ListMapConfigSchema	objectstack#9370
#5057, #5126	—	chained behind #5074

Both keys are in the same unreleased changeset backlog, so one release discharges both. Any further objectui card needing a post-GA spec key belongs here too — ⛔ and none of them should be worked around by declaring the key objectui-side only, which would publish a key the save gate refuses.

---

Generated by Claude Code

[os-support-ai]

Third instance, and this one is a different shape — worth recording because it shows the gap is not only about missing keys. PM round 17, found while implementing #5216 (PR5354).

The first two dependants need a key that is merged-but-unpublished. This one needed nothing: ObjectNavItemSchema.runAction merged pre-GA and is present in the pinned 17.0.0 (measured, counter-probed — runAction true, recordId true, objectName true, zzNotAKey false, all through the same import, so the true is a reading rather than a wrong-path artefact).

What is missing from the pin is a refinement, not a key. The card #5216 was written against describes a parse-level exclusivity — runAction cannot be combined with recordId — and the installed 17.0.0 accepts both together. The superRefine that enforces it does exist on objectstack main (packages/spec/src/ui/app.zod.ts, message "runAction cannot be combined with recordId"), so this is the same merged-but-unpublished state, arriving through a rule rather than a field.

Nothing filed as a defect, correctly — it is this card, not a new one.

Why the distinction matters for whoever unblocks this

A missing key announces itself: the consumer cannot compile, or safeParse rejects, and the dev stops. A missing refinement does not — the pinned schema accepts the input and the consumer proceeds, so the gap is only visible if someone thinks to check that a documented constraint is enforced by the pin rather than assuming it. #5216's dev checked, and the consequence was concrete: it made that PR's list-surface-only precedence load-bearing rather than defensive, because the schema will not refuse the combination for it.

So the running rule gets a clause: merged upstream ≠ published ≠ pinned here applies to refinements and error messages as well as to fields, and the refinement case fails silent.

Running list of dependants

card	what it needs	upstream landing	shape
#5074	GanttConfigSchema.viewMode	objectstack#9463 / PR#9489	missing key
#5042	ListMapConfigSchema	objectstack#9370	missing key
#5216 (landed anyway)	the runAction × recordId exclusivity refinement	on main, unreleased	missing refinement — fails silent
#5057, #5126	—	—	chained behind #5074

#5216 is not blocked by this — its key is in the pin and its PR compensates in the consumer — so it is listed for the record, not as a dependant. One release still discharges all of it.

---

Generated by Claude Code

[os-support-ai]

Restart-when: has fired — releasing this card from hold

Unlock scan by the spec@objectui seat (session_01BisYvhR7yZ7ggXAwthTZH5), 2026-08-21T05:0xZ. Measured against this card's own criterion, not by inference from the upstream card's state.

@objectstack/spec@17.1.0 is published and is npm latest. ^17.0.0 resolves to it. The release that this card said was the covering event has happened.

The card's own check, run

Installed the published 17.1.0 in a scratch dir and ran the body's criterion verbatim:

reading	value
GanttConfigSchema present	true
viewMode on GanttConfigSchema	true ← the Restart-when: criterion
ListMapConfigSchema present (#5042)	true

Counter-probe on the same import, because a bare true is not a reading: resourceView → true (known-present), zzNotAKey → false (known-absent). Both behave, so the path is right and the true is genuine.

A third dependant discharged by the same release

element:filter is absent from the published PageComponentType (34 members), counter-probed: element:form true, element:text true, zzNotAType false. That retirement (objectstack#9220 / PR#9250) shipped on the 17.x line exactly as its tombstone said it would — "v17.0.0 was cut before this landed, so the tombstones ship on the 17.x line". So objectui#4935 unblocks on this same bump, and its stale Blocked-by: objectstack#9220 is the misleading half — noted on that card.

Release discipline, both checks

1. Most-recent-condition check. The operative condition is the Restart-when: in this card's body. The two later comments add dependants; neither states a new or narrower condition. Released against the body's line only — no earlier blocker on the thread was used.
2. Newer-merged-PR check. This card has no linked PRs (closed_by_pull_requests: 0), so nothing indicates the card moved on after the hold was written. No refusal trigger.

State change

pm:on-hold → pm:queue. pm:blocking stays — the dependants below are still open, so this card is still gating them until the bump lands.

What this card now is

Dispatchable work, and it is a pin bump, which is never a rider: a dedicated lockfile refresh moving @objectstack/spec from lockfile-exact 17.0.0 to 17.1.0 (the package.json caret ^17.0.0 already admits it and needs no edit), with whatever green-keeping adaptations the newly-arrived keys and the element:filter enum removal force. Measured on origin/main today: the lockfile is still exact 17.0.0.

⛔ Unchanged: this card still does not authorise anyone to publish a release. It no longer needs to — the release already happened.

Dependants, all discharged by the one bump

card	what it needs	now in 17.1.0
#5074	GanttConfigSchema.viewMode	✅ measured
#5042	ListMapConfigSchema	✅ measured
#4935	element:filter gone from PageComponentType	✅ measured
#5057, #5126	chained behind #5074	✅ transitively

⛔ None of them should be returned to the queue until the bump has actually landed — merged upstream ≠ published ≠ pinned here, and only the third state has changed today.

---

Generated by Claude Code