Found while fixing #12935 (the field-level visible key taught in three shapes that
no schema declares). Filed unassigned, recording only. This is the mechanism half of
that card: not another phantom key, but the reason phantom keys keep surviving sweeps.
Measured on origin/main @ db39dfc1c9b09681474475cea6e77537ab2c89ab.
What was measured
packages/spec/scripts/check-skill-examples.ts is the one gate that compiles doc prose
against the live spec. Two properties, both deliberate and both documented in its own
header, together mean it can never see the defect class #12935 belongs to:
- It reads only TypeScript fences. Its
FENCE_OPEN_RE recognises ts, tsx and
typescript and nothing else. A yaml fence is not in the population at all — not
as a skipped block, not as an unchecked one. It does not exist to the gate.
- It is opt-in. Even inside the TS population, only blocks carrying an explicit
os:check marker are compiled. Its last run over this tree reports
260 marked example(s) across 101 file(s), 3 surface(s).
The consequence is structural rather than incidental: metadata authoring examples are
written in YAML. That is the whole authoring surface this documentation teaches — object
definitions, view layouts, sections, fields, actions. So the format that carries almost
every example a metadata author copies is precisely the format no gate reads.
Cross-check on today's tree: content/docs/protocol/objectui/layout-dsl.mdx carries an
os:check marker at its "Visibility Rule" section over a typescript fence, which is
type-checked — while the yaml fences on the same page taught a field-level visible
breakpoint map and a section-level columns orientation map, neither of which exists on
any schema, for as long as the page has existed.
Why it is worth recording
Prior art, deliberately not duplicated
#11407 recorded a different limit of the same gate — that an os:check fence
type-checks a visibleWhen CEL string as string, so any predicate text passes. That is
about the depth of checking inside a block the gate already reads. This is about the
population the gate reads at all.
Not a decision
Recording only, and the shape of any fix is genuinely open — a YAML-fence checker keyed
to the metadata type an example declares is one option; an opt-in marker over yaml
fences mirroring os:check is another and much cheaper; declaring the whole class
unverifiable and moving authoring examples to ts fences is a third. Each has a real
cost and none of them is obviously right, so this is left for triage rather than
pre-judged.
Re-check commands:
git grep -n "FENCE_OPEN_RE" -- packages/spec/scripts/check-skill-examples.ts
pnpm --filter @objectstack/spec run check:skill-examples (reports its marked-block census)
git grep -c "os:check" -- content/docs versus the count of ```yaml fences on the same pages
Generated by Claude Code
Found while fixing #12935 (the field-level
visiblekey taught in three shapes thatno schema declares). Filed unassigned, recording only. This is the mechanism half of
that card: not another phantom key, but the reason phantom keys keep surviving sweeps.
Measured on
origin/main@db39dfc1c9b09681474475cea6e77537ab2c89ab.What was measured
packages/spec/scripts/check-skill-examples.tsis the one gate that compiles doc proseagainst the live spec. Two properties, both deliberate and both documented in its own
header, together mean it can never see the defect class #12935 belongs to:
FENCE_OPEN_RErecognisests,tsxandtypescriptand nothing else. Ayamlfence is not in the population at all — notas a skipped block, not as an unchecked one. It does not exist to the gate.
os:checkmarker are compiled. Its last run over this tree reports260 marked example(s) across 101 file(s), 3 surface(s).The consequence is structural rather than incidental: metadata authoring examples are
written in YAML. That is the whole authoring surface this documentation teaches — object
definitions, view layouts, sections, fields, actions. So the format that carries almost
every example a metadata author copies is precisely the format no gate reads.
Cross-check on today's tree:
content/docs/protocol/objectui/layout-dsl.mdxcarries anos:checkmarker at its "Visibility Rule" section over atypescriptfence, which istype-checked — while the
yamlfences on the same page taught a field-levelvisiblebreakpoint map and a section-level
columnsorientation map, neither of which exists onany schema, for as long as the page has existed.
Why it is worth recording
visiblekey in three shapes, none of which exists —FieldSchemarefuses the spelling by name #12935's own history is the argument.layout-dsl.mdxwas swept twice for exactly thisdefect family — docs: layout-dsl.mdx teaches section-level
virtualScroll/itemHeight/lazy/renderStrategykeys that exist on no schema #8251 (virtualScroll/itemHeight/lazy/renderStrategy) anddocs: layout-dsl.mdx still teaches tab-level
lazy/sourceafter #8251 removed the section-level twins — same phantom-key defect, different family #8306 — same file, same shape, different keys. Both were hand sweeps. Both missed thekeys still on the page, because a hand sweep is the only instrument there is here, and
a third one would have the same failure rate as the first two.
FieldSchema,FormFieldSchemaandFormSectionSchemaare all strict, so a documented key they do not declare is asave-blocking parse error for anyone who copies the example. The docs are the
reason a phantom spelling circulates at all: objectui#6514's census found ZERO
field-level
visiblekeys across the framework's 113*.object.*files, yet therenderer gated on the key for its whole life.
channel by which to discover that the YAML it is copying cannot parse.
Prior art, deliberately not duplicated
#11407 recorded a different limit of the same gate — that an
os:checkfencetype-checks a
visibleWhenCEL string asstring, so any predicate text passes. That isabout the depth of checking inside a block the gate already reads. This is about the
population the gate reads at all.
Not a decision
Recording only, and the shape of any fix is genuinely open — a YAML-fence checker keyed
to the metadata type an example declares is one option; an opt-in marker over
yamlfences mirroring
os:checkis another and much cheaper; declaring the whole classunverifiable and moving authoring examples to
tsfences is a third. Each has a realcost and none of them is obviously right, so this is left for triage rather than
pre-judged.
Re-check commands:
git grep -n "FENCE_OPEN_RE" -- packages/spec/scripts/check-skill-examples.tspnpm --filter @objectstack/spec run check:skill-examples(reports its marked-block census)git grep -c "os:check" -- content/docsversus the count of```yamlfences on the same pagesGenerated by Claude Code