docs(guide): write schema-overview's action excerpt as the live condition gate

[yinlianghui-tw]

Fixes#5980

content/docs/guide/schema-overview.md was a third teaching site still writing the retired condition: { expression, then } branch shape, outside the fence of #3917 (PR #5981, merged). One page, three lines.

Re-derived on origin/main @ a1c41c516

The site was still there, and genuinely outside #5981's fence — that PR touched content/docs/core/enhanced-actions.mdx and content/docs/api/schema-reference.md, not this page. (Line 76 is an HTML comment; angle brackets are written as entities below because GitHub's body sanitizer eats short <…> fragments even inside a code fence.)

76 <!-- doc-snippet: fragment — a shape excerpt: `chain`, `condition`, `onSuccess` and
`tracking` are written as literal `[...]` / `{...}` ellipses so the section can list
the action keys without a worked example of each -->
78 ```typescript
79 const action: ActionSchema = {
…
84 condition: { expression: '${...}', then: {...} },
…
97 - Conditional execution (if/then/else)

Line 311 (- ✅ Conditional execution with the \condition` property) stays true — condition` survives as a predicate gate — and is untouched.

What changed, and why it is #5981's pattern rather than a second one

Line	Before	After
84	condition: { expression: '${...}', then: {...} },	condition: '${...}',
97	- Conditional execution (if/then/else)	- Conditional execution (a `condition` predicate gates whether an action runs)
76	marker reason names condition among the ellipsis keys	marker reason no longer names it

Line 84 is the same edit #5981 made at api/schema-reference.md:637 ("condition": { "expression": … } → "condition": "${data.items.length > 0}"). Line 97 is the same sentence #5981 rewrote at core/enhanced-actions.mdx:17 — - **Conditional logic**: If/then/else execution based on data → - **Conditional execution**: a \condition` predicate gates whether an action runs`; the wording is inherited verbatim, re-punctuated only to match this list's terse parenthetical style.

Line 76 is the marker question the card asked to look at. The fragment declaration must say why the block cannot compile; after the correction condition: '${...}' is an ordinary string literal that compiles fine, so it is no longer one of those reasons and naming it would make the declaration false. chain: [...], onSuccess: {...} and tracking: {...} still are, so the block stays a declared fragment. This is not a re-fence — the fence language, the marker kind and the page's coverage state are all unchanged (#5867 / #5997's lane is untouched).

Verification — the doc is pinned to the code, not to #5981's prose

Two-way compile probe against the builtpackages/types/dist (@object-ui/types built first, so this reads the shipped .d.ts, not a stale one):

LIVE const a: ActionSchema = { …, condition: '${...}' } → tsc exit 0
RETIRED const a: ActionSchema = { …, condition: { expression: …, then: … } } → tsc exit 2
retired.ts(9,16): error TS2353: Object literal may only specify known
properties, and 'expression' does not exist in type
'{ dialect?: string | undefined; source: string; }'.

The shipped zod schema agrees, pinned to the condition key:

doc corrected shape -> success: true
doc previous shape -> success: false | issue: invalid_union

Gates, each quoting its own verdict line (measured at 5d4e5bb43):

• check-doc-snippet-types — exit 0. Covered blocks: 274 — 157 to compile, 117 declared fragment(s). / Semantic phase: 157 of 157 block(s) judged, 0 failed.Identical to the same run with this file at a1c41c516 (274 / 157 / 117, 157 of 157, 0 failed) — the block was and remains a declared fragment, so the covered and diagnostic counts do not move.
• check-doc-links — exit 0, Links are valid across 15 scan roots.
• check-doc-component-types — exit 0, ✅ Every documented component type is registered.
• check-control-bytes — exit 0, ✅ check-control-bytes: OK (scanned 5015 tracked text file(s)); plus a control-byte grep -naP on the changed file: no match.
• check-changeset-presence — exit 0, No source of a released package changed in this range, so no changeset is owed. Docs-only; no changeset, per this repo's "src of a released package" criterion.
• Docs build: pnpm turbo run build → 44 successful, 44 total; @object-ui/site✓ Compiled successfully, ✓ Generating static pages (556/556). The rendered page carries condition: '${...}' and zero occurrences of expression: or if/then/else.

What is not verified: nothing runtime. A prose correction has no runtime consequence — the retired shape was a silent no-op before #5981 and is a type error plus a zod refusal after it, and this PR changes neither. The whole of the evidence is that the shape the page now documents is the shape ActionSchema accepts, and the shape it used to document is the one ActionSchema refuses.

Sweep for a fourth site

Repo-wide over *.md / *.mdx, excluding node_modules and CHANGELOGs: then: near condition matches only this page, and expression: matches only this page plus skills/objectui/guides/schema-expressions.md:312 and AGENTS.md:79 — both false positives (the skills line documents the legacy { expression: "${…}" } CEL-translation form for conditionalFormatting predicates, a different surface with no then; the AGENTS.md line is a comment on hidden). No fourth site to file.

Scope held to this one page: the ActionSchema type, #5981's fence, the doc-snippet gate and the ledger are all untouched.

---

Generated by Claude Code

[yinlianghui-tw]

PM: ACCEPT

Scope verified: 1 file, +3 / −3, content/docs/guide/schema-overview.md only. The ActionSchema type, #5981's fence, the gate and the ledger are all untouched — exactly the boundary the order drew.

You caught a broken instrument mid-verification, and that is the most important line in the report

The first two-way probe returned exit 1 on both legs — a TS5112 config-loading failure. Both legs agreeing is not a result; it is the instrument failing to run, and it would have read as "no difference between the shapes" to anyone not looking. You noticed, diagnosed it, re-ran with --ignoreConfig --skipLibCheck, and reported the false run rather than quietly replacing it with the good one. That is the discipline this lane runs on: identical readings on both legs means the instrument is broken until proven otherwise.

Pinned to the code, not to another document

The order required proving the corrected shape is the live one against the shipped type rather than against #5981's prose, so the doc is anchored to the code. You built @object-ui/types first so the probe read the shipped dist/, confirmed condition?: boolean | string | { dialect?: string; source: string } in dist/crud.d.ts:197, then ran both directions:

leg	result
live shape condition: '${...}'	tsc exit 0
retired shape { expression, then }	exit 2 — TS2353: … 'expression' does not exist in type '{ dialect?: string; source: string; }'

The refusal is pinned to the condition key's own type, not to a general error, and the shipped zod schema agrees independently (success: true vs success: false with invalid_union on path condition). Two independent oracles pointing the same way.

The fragment-marker edit is the detail that shows you understood the ledger

Correcting line 76 to stop naming condition among the ellipsised keys was not asked for, and it is right: after the fix that key is a plain string literal that compiles, so it is no longer a reason the block cannot compile, and naming it would have left a false declaration behind. That is invariant 3 — surviving reasons stay measured — applied without being told. A stale reason in a ledger is precisely the debt that never gets discharged, because nothing fails to prompt it.

And the coverage state is genuinely unmoved: the block stays a declared fragment (typescript fence + marker), counted and never compiled, before and after. Counts identical on both sides — 274 / 157 / 117, 157 of 157 judged, 0 failed — measured by running the gate with the file restored, not by assuming.

The fence boundary held

No re-fence: fence language, marker kind and coverage state all unchanged. That keeps #5867's population and #5997's just-landed lane untouched, which is what the order fenced off. Line 311 correctly left alone because it is still true — checking whether a neighbouring claim survives the correction, rather than sweeping the whole page, is the right instinct on a card scoped to one shape.

Premise re-derivation was solid too: PR #5981 touched only enhanced-actions.mdx and api/schema-reference.md, so this page is genuinely outside the fence — established by reading what #5981 actually landed rather than trusting the card's claim that it was outside.

Honest limit, correctly stated

"A prose correction has no runtime consequence." Right, and worth the sentence: the retired shape was a silent no-op before #5981 and is a type error plus a zod refusal after it, and this PR changes neither. The whole evidence is that the documented shape is the one ActionSchema accepts and the previous one is the one it refuses. Nothing more is claimed.

Process note

The report marker was eaten by GitHub's sanitizer again — fifth occurrence this round, across five different devs. Confirmed lane-wide tooling behaviour, not individual slips. Noted with the rest.

Landing

⏳ 18 of 19 checks green, Build Docs still running. The self check-in verifies every-check-green and lands it.

---

Generated by Claude Code