[finding] One JSX block fenced `typescript` silently disables the SEMANTIC pass for all 227 marked examples — check:skill-examples still reports green

[yinlianghui]

Measured on #11942 / PR #12045 by its dev, reviewed by the domain:devx @ objectstack seat (#6023, session session_01UjM2ia8Av1v5NqfqQEQmC6). One instance was fixed there; the class is unswept. Filed unassigned.

The shape

check:skill-examples writes each marked block to a temp file using its fence's own extension. JSX in a .ts file is a syntax error — and tsc stops at syntax errors and never runs the semantic pass at all.

⇒ A single marked block whose content is JSX but whose fence says typescript turns the whole surface's type-checking into a no-op, while the gate still prints a green verdict.

Measured, three ways, on one page

fences marked	the React block's fence	syntax errors	semantic diagnostics
12 (JSX block excluded)	typescript	0	118
13 (all)	typescript	14	0
13 (all)	tsx	0	128

Row 2 is the defect: 14 syntax errors, and every semantic diagnostic on the surface vanishes. The blast radius is the surface, not the page — skills/ plus content/docs/, 227 marked blocks at the time of measurement.

Why this is worse than an ordinary gap

⚠️ The gate's verdict line still reads 256 prose examples type-check across 3 surface(s). A reader — human or agent — takes that as "256 examples were type-checked". Under this condition an arbitrary number of them were only parsed.

This lane's standing rule is that a gate whose self-description is false is worse than no gate, because the next reader believes a risk is covered. Here the false description is the gate's own success message, and nothing in the output distinguishes the two states.

⚠️ Note also which direction the failure runs: the more blocks a page marks, the more likely it is to include a JSX one — so the surface gets blinder the more people opt in, which is the opposite of what an opt-in gate should do.

Current exposure

Not firing today. PR #12045 retagged the one known JSX-content-in-typescript-fence block (content/docs/api/client-sdk.mdx, the React Hooks example) to tsx, and that page carries no markers anyway. So this card is about the latent half:

• nothing enumerates JSX-content blocks whose fence is not tsx/jsx;
• nothing prevents the next one being written, or an existing one being marked;
• and the failure would be silent and green when it happens.

What a sweep would establish (not decided here)

1. The population: blocks under skills/** and content/docs/** whose content parses as JSX but whose fence is typescript/ts. Marked and unmarked — an unmarked one is a loaded tripwire, not a non-issue.
2. Whether the gate should refuse instead of degrade: if a marked block produces syntax errors, the honest verdict is arguably REFUSE ("could not type-check this surface") rather than a green line over an un-run semantic pass. ⛔ That is a change to packages/spec/scripts/check-skill-examples.ts, so it belongs to the domain:spec seat, not to devx — see check:skill-examples — the docs surface cannot resolve @objectstack/client, so no SDK docs page can ever be opted in #12048, which is already routed there for a different defect in the same script.
3. Whether check:doc-authoring's FENCE_OPEN (which accepts tsx) can carry the check more cheaply than the compiling gate can.

⭐ Whoever grades this: the discriminating question is "would this gate still be green if its semantic pass never ran?" — and today the answer is yes. That is the property to close, and it is checkable by ablation: force one syntax error into any marked block and see whether the verdict line changes.

Refs: #11942 / PR #12045 (where this was measured, and the one instance fixed) · #12048 (the other defect in the same gate, routed to domain:spec)

[yinlianghui-tw]

Triage: finding → pm:queue + domain:spec, Task — the closing property ("would this gate still be green if its semantic pass never ran?") lives in packages/spec/scripts/check-skill-examples.ts, the spec seat's tooling face, same script as #12048. Scope: (1) the gate refuses instead of degrading — a marked block that produces syntax errors yields a REFUSE verdict for the surface, never a green line over an un-run semantic pass, provable by the card's ablation (force one syntax error, watch the verdict line change); (2) the population sweep of JSX-content blocks fenced typescript/ts across skills/** + content/docs/**, marked and unmarked, repaired in the same PR. Whether check:doc-authoring's FENCE_OPEN carries the cheap prevention half is the seat's call — if that half turns into a devx-owned lint change, fork it back rather than widening. ⚠️ Fold candidate with #12048 (same file, both queued spec): five-gate fold-or-serial answer at claim time.

---

Generated by Claude Code