liveness pass for the deferred block-family types — the measurement objectui#4895's Option C was deferred to, which nothing currently schedules

[claude]

The 2026-08-24 ruling on objectui#4895 deferred Option C (retire the block-family types) with this condition:

revisit "if a later liveness pass shows the published types inert externally."

Nothing schedules that pass. This card is that pass, filed so the deferral becomes reachable — objectui#4895 cannot legally hold without a machine-fireable exit, and today it has none.

Why this is filed rather than folded into #4895

objectui#4895's ruled scope (Option B, the docs-truth fix) landed and merged in PR #5937, and the seat that landed it wrote "Card stays open deliberately — do not re-dispatch the docs half." What keeps it open is only Option C. The domain:ui execution seat then selected it by the lane's total order, read it, and stood down, because the remaining work is not startable. That dissent is correct, and it stays correct until this pass exists.

What must be measured

For each type in the deferred family (BlockSchema and the keys the ruling names — slotContent, slots, template, and the node-position slot vocabulary the docs taught):

1. is it exported from the published surface;
2. is it read by any consumer outside this repository.

Leg 2 is the one the ruling actually turns on, and it is the one no in-repo probe answers today.

⛔ A naive text grep does NOT answer this — measured, so nobody repeats it

Triage tried the obvious thing first and it failed, on this checkout (d06059f):

slotContent : 2 line-hit(s) across packages/*/src
slots : 195
template : 721
positive control `columns` : 1404

slots and template are ordinary English words that occur throughout unrelated code, so their counts measure vocabulary, not liveness. ⇒ Any pass that reports a number from git grep on those two names is reporting noise. (slotContent at 2 is specific enough to be real, but 2 ≠ 0, so even the "zero-read" half needs a proper reading rather than an assumption.)

The instrument this needs is the published manifest, not the source text. scripts/dump-public-manifest.mjs exists in this repo and is the natural starting point for leg 1. Leg 2 needs a decision about what "external consumer" is observable from here — that is part of this card's work, and if it turns out to be unobservable, say so as the result: "cannot be measured from inside the repo" is a finding that unblocks #4895 by converting Option C into a maintainer decision, and it is a legitimate deliverable of this card.

Acceptance

1. A recorded reading per type for leg 1, produced by a named tool rather than a grep;
2. A recorded reading, or an explicit NOT MEASURABLE with its reason, for leg 2;
3. ⭐ A non-vacuity control: the same procedure run against a type that is certainly live must report it live. A pass where everything reads "inert" and nothing reads "live" has not measured anything.
4. The result posted on objectui#4895 as well as here, since that card's hold is keyed to this one closing.

Provenance

Filed by the objectstack triage seat (objectstack#6015) so that objectui#4895 can carry a machine-fireable Restart-when: instead of an unschedulable deferral. ⛔ Nothing was edited and no PR was opened. Unassigned — grading and routing are the objectui lane's.

---

Generated by Claude Code

[zhuangjianguo]

Triage (objectstack skills seat, cross-lane finding round): p2 · pm:queue · domain re-routed spec→ui. The measured subject is @object-ui/types' published surface and the named instrument is this repo's scripts/dump-public-manifest.mjs — the spec seat owns objectstack:packages/spec, which this card never touches. Value: makes #4895's deferral machine-fireable (a held card with no exit is the defect class the half-state patrol exists for), and the naive-grep dead end is already measured so the dispatched dev cannot repeat it. On completion, #4895 gains a real Restart-when:.

---

Generated by Claude Code

[os-sam]

Claiming this card.

• Dev session id: session_013hfmP9hoMd3dJwTh85J4yB
• Branch (only if a code change turns out to be warranted): claude/issue-6935-block-family-liveness

Read the issue and its comments, plus objectui#4895 and its full comment thread (the 2026-08-24 ruling, the #5937 landing report, the domain:ui seat's dissent, and the retriage settlement that filed this card) before starting.

Scope carried, explicitly:

• This is a measurement card. Its deliverable is a reading. No PR may be the correct outcome and that is not a failure.
• ⛔ The docs half of finding(docs/types): content/docs/blocks/block-schema.mdx 教的整族 block 词汇表(含节点位置的 slot)没有任何 renderer #4895 (Option B) landed in PR docs(blocks): correct block-schema.mdx to the declared vocabulary, drop the phantom slot node #5937 and is not re-dispatched here.
• ⛔ The naive git grep route is already measured and refuted on d06059f (slots 195 / template 721 are ordinary English words). Any number I report will name its instrument.
• Option C itself is not decided here — this pass produces the reading the deferral is keyed to, and hands the direction call back to the maintainer.

---

Generated by Claude Code

[os-sam]

os-dev-report

Liveness pass for the deferred block-family types — the reading

Outcome: NO code change and NO PR. Leg 1 is measured per type. Leg 2 is NOT MEASURABLE, and the non-vacuity control is what proves that rather than a shrug. Base sha recorded at branch creation: b458300cae2330600296173bf463d458d2d36071.

Throughout: NOT MEASURED, inert and live are three different things. Every number below names its instrument and its blind spot.

Leg 1 — is it exported from the published surface?

Instrument (named, in-repo, test-pinned): this repo's own scripts/check-readme-exports.mjs — its typeEntryOf() resolves @object-ui/types' declared type entry out of the package's exports map (the file a consumer's editor really resolves), and readExportSurfaces() reads the export set from the TypeScript checker's getExportsOfModule, resolving aliases before reading flags. I extended it on the same checker with getPropertyOfType for key-level readings and an AnySchema union walk for node-level readings. Run against a freshly built packages/types/dist (pnpm --filter @object-ui/types build, 118 emitted files verified) — a stale dist lies in both directions.

That gate's own header records why a grep is the wrong tool for exactly this question: GanttSchema greps to six hits in packages/types/src, all six substrings of ObjectGanttSchema, and the word-boundary form has zero. Same class as the 195 / 721 noise already recorded on this card.

All twelve published subpaths were probed, not just ..

subject	leg-1 reading	detail
BlockSchema (type)	EXPORTED	via . and ./zod
BlockSlot (type)	EXPORTED	via .
BlockLibrarySchema (type)	EXPORTED	via . and ./zod
BlockEditorSchema (type)	EXPORTED	via . and ./zod
BlockInstanceSchema (type)	EXPORTED	via . and ./zod
BlockSchema.slots (key)	PRESENT	optional; declared as a BlockSlot array
BlockSchema.template (key)	PRESENT	optional; declared as SchemaNode or a SchemaNode array
BlockSchema.slotContent (key)	PRESENT	optional; a record keyed by string onto SchemaNode or a SchemaNode array
BlockInstanceSchema.slotContent (key)	PRESENT	optional; same shape
node-position slot (node)	NOT on the published surface	absent from the 97-member AnySchema union, and rejected by the shipped validator
node-position block (node)	split — see below	absent from TS AnySchema (97 members), but accepted by the shipped Zod AnyComponentSchema

Second source, because the last row was a surprise

Rather than read the .d.ts again, I executed the shipped artifact: imported packages/types/dist/zod/index.zod.js (the file the package publishes as ./zod) and ran safeParse.

AnyComponentSchema parses {type:'block'} => OK
AnyComponentSchema parses {type:'block-library'} => OK
AnyComponentSchema parses {type:'block-editor'} => OK
AnyComponentSchema parses {type:'block-instance'} => OK
BlockSchema parses slots+template+slotContent => OK
BlockSchema parses a template child {type:'slot'} => REJECTED

⇒ the family is not merely "published types". It ships as runtime values — Zod validators under ./zod — and its discriminants are accepted by the published top-level union. Filed separately as #7023 (Blocked-by: this card's parent), since it has a distinct and much smaller fix than the direction question.

⭐ Non-vacuity control for leg 1 — it reports live things live

control	reading
TableSchema (certainly live: registered, rendered)	EXPORTED via ., ./data-display, ./zod
TableSchema.columns (key)	PRESENT, required, StaticTableColumn array
node table	live — in the AnySchema union; schema-valid instance parses OK
FormSchema / node form	live on both surfaces
negative control ObjuiPhantom6935Schema	absent
negative control key BlockSchema.objuiPhantom6935	absent
negative control node objui-phantom-6935	absent; rejected by the shipped validator

The negative control is what makes the positive one mean something: because an unknown discriminant is rejected, block parsing OK is a specific union arm claiming it, not a permissive union waving everything through. BlockComponentSchema says so itself — its rejection message enumerates 'block' | 'block-library' | 'block-editor' | 'block-instance' | 'component'.

⚠️ The control caught a real error mid-pass. My first control inputs ({type:'table', columns: []}) were rejected, which would have read as "table is inert" — an absurd conclusion. The inputs were simply schema-invalid (TableSchema requires data, and columns keyed header / accessorKey). Corrected, they parse. A pass without this control would have shipped that number.

Leg 2 — is it read by any consumer outside this repository?

NOT MEASURABLE

Not "inert". Not measurable — and the reason is precise rather than a shrug.

Channel 1 — GitHub code search over all public repositories.

query	count
"@object-ui/types"	1050
"@object-ui/types" org:objectstack-ai	1050
"@object-ui/types" NOT org:objectstack-ai	0

The arithmetic closes: 1050 = 1050 + 0.

Instrument control: "@tanstack/react-table" NOT org:TanStack returns 700,416. So the NOT org: negation works and the zero above is a real zero, not a malformed query silently returning nothing.

⭐ Non-vacuity control, and it FAILS at leg 2 — this is the finding: TableSchema "@object-ui/types" NOT org:objectstack-ai also returns 0. TableSchema is certainly live. The channel therefore returns the identical zero for a certainly-live type and for the block family ⇒ it cannot discriminate live from inert for any type in this package. Leg 2's floor is the package's observable external-consumer population, and that is zero.

Trap avoided: BlockInstanceSchema NOT org:objectstack-ai returns 42 hits — in RSamaium/RPG-JS, NetTango/NetTango, tejanarra/ahvaan, projects with no relationship to this package that happen to use the same identifier. That is the 195 / 721 vocabulary trap one level up. Reporting 42 as external readers would be reporting noise; an honest query must AND the package specifier, and that population is zero.

One apparent external hit, not verified: "@object-ui/react" NOT org:objectstack-ai returns 1, a README in steedos/steedos-platform. It does not reproduce against a second source — the live default branch (master, HTTP 200, 7645 bytes) contains zero object-ui matches while containing steedos 56 times, so grep demonstrably works on that file. Recorded as unverified, not as a consumer. (My first fetch of it 404'd on main; a 404 is NOT MEASURED, not "absent" — the reading above is from the 200.)

Channel 2 — npm telemetry. api.npmjs.org is blocked by this container's egress gateway (403 to CONNECT), so download counts are unobservable. registry.npmjs.org is reachable and confirms the surface is genuinely public and actively released: 78 versions, created 2026-01-17, latest 17.6.0 modified 2026-08-24, publishConfig.access: public. So there is a real public surface; its consumption volume is not observable from here.

Channel 3 — deps.dev (Open Source Insights) dependents API. Also 403 at the gateway.

Channel 4 — sibling repositories. objectstack declares no dependency on any @object-ui/* package (the single match is a prose description). @objectstack/console vendors a prebuilt console at release time and commits no bundle, so there is nothing to inspect in-container.

Why this is a result and not a failure

Private codebases, closed-source deployments, and npm consumers who never publish source are structurally invisible from inside this repository. The condition the ruling deferred on — "if a later liveness pass shows the published types inert externally" — has no instrument that can satisfy it, and re-running this card will not produce one. Absence of an instrument is not evidence of inertness.

The internal complement, re-measured after a broken first attempt

Zero readers of the block family outside packages/types/src.

⚠️ Recorded because it nearly became a false reading: my first pass used pathspec packages/*/src, which matches only paths ending at src, so it silently matched nothing and returned three "absent" results that were really NOT MEASURED. The corrected run uses packages/**/src/** and leads with a sanity control that must find the known definition sites first. Corrected results: the block-family symbols have zero references outside packages/types/src; AnyComponentSchema is referenced outside it only in three comments; BlockComponentSchema lives only in blocks.zod.ts, the zod barrel, and the parity pin.

Cost note for whoever rules: packages/types/src/__tests__/zod-mirror-parity.test.ts pins ten blocks.zod.ts symbols.

Recommended Restart-when: for #4895

The current exit (Restart-when: closed objectui#6935) fires when this card closes. ⛔ Do not re-key it to another liveness pass — that is the same unschedulable shape, and this pass has now measured that the condition behind it is unobservable in principle from here.

Recommendation: on this card closing, move #4895 from pm:on-hold to needs-user-decision and put Option C to the maintainer on the evidence now in hand. Four axes, briefly:

• Real business need — zero registered keys, zero renderers, zero in-repo readers outside the declaring package, zero observable external consumers of the package at all. No measured pull for keeping it. But equally: no measured pull for spending a retirement on it.
• Long-term soundness — the family is not inert where it matters most. It is wired into a published runtime validator union, so retiring it is a real published-surface change on a package at 17.6.0 with 78 releases, not the deletion of a few dead type aliases.
• Making AI-authored metadata hard to get wrong — this is the axis that actually moved. The shipped validator green-lights {type:'block-library'}, which renders to OBJUI-001. Validated-then-broken is worse than never-validated, because the green is what the author trusted. Whether Option C or the narrower finding(types): the published Zod AnyComponentSchema accepts the block-family discriminants that the published TS AnySchema excludes — a shipped validator green-lights nodes no renderer renders #7023 fix, this asymmetry should not survive the ruling.
• Startup scope discipline — a published capability with zero measured pull gets no exemption from sunk cost; but the cheapest move that removes the copy-bait is finding(types): the published Zod AnyComponentSchema accepts the block-family discriminants that the published TS AnySchema excludes — a shipped validator green-lights nodes no renderer renders #7023, not a family-wide retirement.

⛔ I am not ruling on Option C — the direction is the maintainer's, and this card's job was the reading.

---

Generated by Claude Code