fix(objectql,showcase): keep the state-machine refusal's facts with an authored message, and stop the New Project wizard offering statuses it refuses

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[hotlong]

Fixes#14311

What the measurement said, and where it disagreed with the card

The triage ruling asked for two engine changes: make checkStateMachine's refusal
field-located, and put its fallback message on the built-in validation catalog.
Measured against origin/main, both were already true:

• checkStateMachine has always returned field: rule.field, and error-response.ts
  ships fields verbatim in the 400 VALIDATION_FAILED envelope. The refusal was
  field-located already.
• The fallback has gone through buildFieldError and the built-in catalog since Field validation messages are hardcoded English + API field name — penalty_amount must be ≥ 0 reaches end users verbatim #3957,
  and that catalog already ships invalid_initial_state / invalid_transition in
  zh-CN, ja-JP and es-ES.

The English sentence the dogfood saw was not a fallback. It was the showcase's own
message: 'Invalid project status transition.', and an authored message deliberately
outranks the catalog. #14253 already gave authored messages a translation address
(objects.OBJECT._validations.RULE.message); the showcase simply never populated it.
So the localisation half of this card is showcase content, not engine work.

That left one genuine engine defect, in the same code path and the same class:

Engine — an authored message cost the caller the whole envelope

checkStateMachine's emitter carried constraint and value only on the built-in
branch. The moment a rule declared a message, both were dropped. Since
ValidationRuleSchemarequiresmessage on every rule, the machine-readable half
was in practice reachable only by declaring message: '' — so a normally-authored state
machine refused writes with no way for a client to learn which states are legal.

That is exactly what "a multi-step form can jump to the owning step" needs, and both keys
are already declared on FieldValidationError (mirroring FieldErrorSchema), so nothing
in the contract widens.

Envelope for the create this card describes, before and after:

 before after
{ field: 'status', { field: 'status',
code: 'invalid_initial_state', code: 'invalid_initial_state',
message: AUTHORED, message: AUTHORED,
label: '状态' } label: '状态',
constraint: { allowed: 'planned' },
value: 'active' }

packages/spec is untouched. Which writes are refused does not change — Clause-② holds:
the refusal stays a refusal and only gains the location the ledger already declared.

Showcase — the wizard, and the message channel

• new-project-wizard.page.ts: status is dropped from the create wizard. The
  machine admits exactly one initial state (planned), so "offer only the initial
  states" degenerates to a one-option select — a question with one answer. The option
  marked default: true supplies the value server-side, and it is the declared entry
  point, so the two cannot drift. Triage ruling 1 authorises this branch explicitly.
• project.object.ts: the rule message is reworded. One authored sentence answers
  both codes this rule raises, and the old wording described only the update half —
  a create rejected for being born active was told about a "transition" it never
  attempted.
• translations/index.ts: all four showcase_project rules go onto the i18n: three authored display surfaces have no bundle key at all (bulk-action defs, custom validation messages, dataset labels) #14253
  channel in en + zh-CN.

The product half of the card (a create form deriving allowed values from the object's
stateMachine) is a console feature and is deliberately not built here, per triage
ruling 3. The sticky-toast defect belongs to objectui and is not touched by this PR.

Declared scope note

Translating end_after_start and spent_within_budget goes one step past the status
rule. It is the same defect class in the same file, and it is load-bearing rather than
tidying: this same wizard trips both from its budget/schedule step, so translating
only the status rule would have moved the single English sentence one step later instead
of removing it. The new pin is scoped to the object's whole rule set for that reason.

Verification (all on the final commit 120d1d066)

what	result
pnpm --filter @objectstack/objectql exec vitest run src/validation src/engine.test.ts src/plugin.integration.test.ts src/engine-seed-required-deferral.test.ts	12 files / 552 passed
pnpm --filter @objectstack/example-showcase test	27 files / 372 passed
pnpm --filter @objectstack/objectql typecheck	OK (check:test-typecheck verdict line)
pnpm --filter @objectstack/example-showcase typecheck	exit 0
pnpm lint (whole repo, eslint . --no-inline-config)	exit 0, 71s — not narrowed
check:test-source-alias, check:cross-package-test-inputs, check:engine-double-contract, check:where-matcher, check:error-code-casing, check:nul-bytes, check:dispatcher-error-vocabulary	all exit 0

Gate families re-derived after the edits with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack
(40 families; it takes its own change set from the merge base). The new showcase test file
is confirmed inside the app's tsc program via tsc --noEmit --listFiles (1 hit) — a
typecheck that excluded it would have said nothing about it.

End-to-end, against a real running app

Real runtime on a scratch port, seeded admin, Accept-Language: zh-CN:

A) POST /api/v1/data/showcase_project {name, account, health} -> HTTP 201, status = planned
B) POST /api/v1/data/showcase_project {name, account, status:"active"} -> HTTP 400
{"code":"VALIDATION_FAILED",
"fields":[{"field":"status","code":"invalid_initial_state",
"label":"状态",
"message":"项目的初始状态为“计划中”,此后只能按既定的状态流转变更。",
"constraint":{"allowed":"planned"},"value":"active"}]}

That is the deliverable's proof as triage worded it — creating with planned, refusing
active with a field-located, zh-CN message — and it exercises the real i18n service
resolving the new bundle key, which the unit tests (which mock translate) cannot.

Reverse verification

The engine fix was committed first, then ablated: the two constraint / value spread
lines were deleted and the mutation confirmed on disk by marker count (1 -> 0) and by
git hash-object differing from the HEAD blob.

• objectql unit tests (source-resolved): 2 failed | 184 passed — red, as predicted.
• showcase suite: objectql is not aliased to source for this app, so it resolves
  through dist/. The mutated dist/ was rebuilt before the run: 1 failed | 4 passed.

Restore leg proved rather than assumed: git checkout HEAD -- path (never a bare
git checkout --, which restores from a possibly-polluted index), restored blob hash
byte-identical to the HEAD blob, git diff HEAD empty, whole-tree git status --porcelain
clean, and dist/ rebuilt and re-verified with ablation-dist-preflight finding the
marker present in 4 executable files. (The first preflight marker I chose was a source
spelling that only survives into sourcemaps; the tool caught it and the check was redone
with a marker that survives transpilation.)

Declared narrowing — verification ran UNLOCKED

scripts/pm/os-verify-lock.sh could not take the shared verify lock on this host: no
usable flock. The shared verify lock is declared Linux-only (flock is util-linux, and
a stock macOS does not ship it), so the commands were run through the wrapper but without
the lock — a declared narrowing, not a silent one. No serialization guarantee held for
these runs, nor for any sibling agent in this container while they ran. The wrapper's own
verdict line on every run: UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them, so this run has nothing to list — not a clean bill of health. This check sees only pages that NAME a derived anchor: one that documents this change in prose, or enumerates it in an authoring dialect, names none and stays invisible to it on every run.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 16 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 — the merge of head 120d1d0662bfe290d8ffd86bc1b9f07881010007 into base a40c0f966ef71739fcaecf0c2e4d671d3e960d34, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4 && git checkout 8abe29c56edf5cd4f5bbd77c10ccacecf5c0b4a4
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin a40c0f966ef71739fcaecf0c2e4d671d3e960d34 120d1d0662bfe290d8ffd86bc1b9f07881010007 && git checkout -B drift-repro a40c0f966ef71739fcaecf0c2e4d671d3e960d34 && git merge --no-ff 120d1d0662bfe290d8ffd86bc1b9f07881010007
node scripts/docs-audit/affected-docs.mjs --json a40c0f966ef71739fcaecf0c2e4d671d3e960d34

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.