fix(cli): os generate scaffolds object, view, action and app in the shapes os validate accepts

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[os-trump]

Fixes#14336

Four of the seven os generate templates wrote artifacts the platform's own validator refuses. The generator is the path the docs point at, and a .strict() refusal enumerates what is allowed rather than saying where a key moved to — so an author following the documented path got a file their own os validate rejected, with an error that did not say where to put the key instead.

#14087 fixed flow and recorded these four in KNOWN_UNVALIDATED_SCAFFOLDS, a shrink-only ledger with an anti-staleness assertion: a ledgered kind must still FAIL. This PR repairs all four templates and deletes all four entries, which empties the ledger.

The four ledger deletions

All four lines are removed from KNOWN_UNVALIDATED_SCAFFOLDS in packages/cli/test/generate-scaffold-validates.test.ts, leaving the table empty. ⛔ No kind was added to it.

deleted entry	repaired by
object — "parses, then fails the author-time rules: security-owd-unset (no sharingModel authored)."	an authored sharingModel: 'private'
view — "unrecognized pageSize on the list view, and type / objectName on the view container."	a view CONTAINER, pageSize under pagination
action — "type: 'custom' is not an Action type, and handler is not an Action key."	type: 'flow' + target
app — "navigation takes an array of nav items; the scaffold writes a { type, items } object."	navigation as an array of nav items

Because the table is empty, the harness's clean pin now ranges over the whole roster: every generator must write a stack os validate accepts, and a template that stops validating is red on the day it lands.

Per kind — the refusal before, the shape after

Refusals re-measured on this branch's base through the #14087 harness (schema parse after normalizeStackInput and the unknown-key lints, then runAuthoringRules('validate')), not copied from the card.

object — the one that is not shape drift

Before:

security-owd-unset at objects[0].sharingModel: custom object "probe_thing" declares no
sharingModel (OWD). The runtime fails CLOSED to 'private' (ADR-0090 D1), but the baseline
must be an authored decision, not an accident — this is the exact shape of the
leave_request incident (objectui#2348).

The object parses fine and is refused one layer later, by an error-severity author-time rule asking for a security decision. Per triage, this is not a new authoring decision: #9666 already took it for the os init templates. Measured on this base, both os init sites emit sharingModel: 'private' — so this emits the same value, with the same comment block naming ADR-0090 and the sharing-rules doc, and the two doors an author can arrive through agree. (Had that template emitted none, or a different value, the disagreement would have been reported instead of a third answer invented.)

After:

// Org-wide default (OWD): who can see records they don't own. 'private' is// owner-only until access is widened by a permission grant or a sharing// rule. ...sharingModel: 'private',

view — a container, not a flat list view

Before:

views.0.list: Unrecognized key(s) on this list view: `pageSize`.
views.0: Unrecognized key(s) on this view container: `type`, `objectName`.
• `type` belongs to a single VIEW, not to the container. Wrap it:
`defineView({ list: { type, data, columns, … } })` ... The container's own keys are
`list`, `form`, `listViews`, `formViews`.

The template wrote both spellings at once — a flat list view's keys on the container and a list block. That mattered past the refusal: a flat view parses to an empty container, so zero views register and the Console renders nothing (which is why defineView has carried a bespoke guard for it). pageSize is PaginationConfigSchema's key, reached through the list view's pagination. The object binding is object — the key getViewsByObject() reads; objectName is the spelling on the query surface.

After: name / label / object on the container, one list holding type / columns / sort / pagination: { pageSize: 25 }. The const is renamed to NAMEViews and its JSDoc follows, because the artifact is a container now, not "a list view".

action — a declared type and the single target slot

Before:

actions.0.type: Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"
actions.0: Unrecognized key(s) on this action: `handler`.

custom is not an ActionType, and handler is not an Action key — the second handler slot was removed in protocol 17 precisely so no consumer has two places to disagree about. What the old handler: { type: 'flow', target: 'NAME_flow' } block was trying to express is exactly type: 'flow' with target naming the flow, so that is what it now says. ActionSchema's own refinement makes target required for every type but script, so this cannot drift back to an action bound to nothing.

After: type: 'flow', target: 'NAME_flow' — the name os g flow NAME writes.

app — navigation is an array

Before:

apps.0.navigation: Invalid input: expected array, received object

AppSchema.navigation is z.array(NavigationItemSchema).optional(). There is no sidebar wrapper on the authoring surface: the array is the sidebar tree, and it nests through type: 'group' items carrying children.

After: one real type: 'object' entry (id / type / label / objectName) rather than an empty array — the entry shape is the thing an author copies to add the second one, and an app with no navigation renders a shell with nothing in it. It points at the object os g object NAME writes.

The action and app repairs deliberately target the names the sibling generators write, so the scaffolds compose instead of each standing alone.

Scope

packages/spec was read but not changed — none of the four needed a spec change; each repair moves the scaffold onto a shape the schema already documents. dashboard and skill were clean and stay clean; the flow template (#14087) is untouched, and the harness still asserts flow is absent from the ledger. The migration codegen region of generate.ts is untouched.

Verification

All runs serialized through this container's shared verify lock. Every exit code captured with the redirect-then-capture form, and each gate's verdict read from the line the gate itself prints — never from a bare $? behind a pipe.

Red-first, then green (the ledger is the instrument, so it was emptied before any template was touched — first commit on the branch):

red-first (ledger emptied, templates untouched) Tests 4 failed | 14 passed (18)
x os g 'object' / 'view' / 'action' / 'app' writes a stack os validate accepts
after repairs Tests 18 passed (18)

The four reds printed exactly the refusals quoted per kind above — re-measured here, not copied from the card.

Ablation — one refused shape re-introduced on disk (type: 'custom' back into the action template), predicted direction stated before running: red for action only.

HEAD_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e
MUTATION ON DISK: injected(type:'custom')=1 remaining(type:'flow')=0
MUT_BLOB=4cd7d698d7af8efe1831d9959c11aadc72dc44b4 (differs from HEAD blob)
ABLATION RESULT: Tests 1 failed | 17 passed (18) -- the failure is `os g 'action'`
RES_BLOB=7a93d0f64124640be59b2d95c2718504c73f309e (byte-identical to HEAD)
RESTORE PROVEN: hash==HEAD_BLOB, git diff HEAD empty, type:'flow' back=1, type:'custom' gone=0

The mutation was proven on disk by grep counts of both the injected and the removed text plus a blob-hash comparison — not by the editor's exit code — and the restore leg got the same treatment. The script carried trap ... EXIT INT TERM with absolute paths throughout. No rebuild leg was needed and none was skipped: the harness reaches the template through a relative ../src/commands/generate.js import that vitest transpiles from source, so no dist/ sits between the edit and the measurement.

Gate union — re-derived AFTER the final commit with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (the first derivation printed STALE TREE, so origin/main was merged in and it was derived again; the second run printed no staleness warning and the union was unchanged). It reports the change set as exactly the three files this PR touches. All 37 were run:

32 passed
5 NOT MEASURED - each printing its own prerequisite verdict, none a finding:
exit 3 node scripts/check-test-completeness.mjs
exit 3 node scripts/pm/check-half-states.mjs
exit 3 pnpm check:dual-build-cjs-loads
exit 1 pnpm check:i18n
exit 1 pnpm check:i18n-coverage

The five are all "nothing was measured" by the gate's own words, and all name the same missing prerequisite — a whole-repo build, or a saved turbo run test log, i.e. inputs CI has and a single dev container does not:

• check:dual-build-cjs-loads — "PREREQUISITE NOT MET — this gate reads built output, and some package has no dist/ ... ⛔ This is NOT a pass: nothing was measured."
• check:test-completeness — "Nothing was measured: this gate exited before parsing a single summary line ... ⛔ It is NOT a finding."
• pm/check-half-states — "Treat this exit as an unread instrument, never as a quiet board."
• check:i18n / check:i18n-coverage — "Nothing was checked / Nothing was measured", both naming the same ten-package build closure. Neither can be moved by this diff: it adds no label to any authored artifact and touches no translation bundle — the scaffold labels live inside a template string, not in metadata any extract config loads.

⛔ Reported as NOT MEASURED, never folded into the green count. Notably green and directly relevant to the test-file edit: check:type-check-debt, check:type-check-coverage, check:type-source-resolution and check:test-source-alias all pass, so emptying the ledger moved no type-check debt.

Package-level, on the final tree 467e26e9cd:

pnpm --filter @objectstack/cli exec vitest run test/generate-scaffold-validates.test.ts
-> Test Files 1 passed, Tests 18 passed (18)
pnpm --filter @objectstack/cli typecheck -> exit 0
pnpm check:nul-bytes -> OK (7922 text files scanned, no raw control bytes)
pnpm --filter @objectstack/cli test -> exit 0; Test Files 228 passed, Tests 2621 passed
pnpm lint (whole repo, eslint . --no-inline-config)
-> exit 0; 5709 files linted, 0 errors, 0 warnings

⚠️ One honest caveat on the typecheck, so it is not read as covering more than it does: packages/cli/tsconfig.json has include: ["src"], so pnpm --filter @objectstack/cli typecheck type-checks the repaired generator but not the edited test file. What covers the test tree here is the type-check debt/coverage gate family, and those pass unchanged (above). Recorded as a boundary, not as coverage.

Notes for review

• The object repair was the one place a wrong answer would have been invented rather than measured. Triage's stop-and-report condition — os init emitting no sharingModel, or a different one — did not fire: both sites emit 'private', so this PR emits 'private' and copies their comment block verbatim rather than writing a new rationale.
• ⛔ Nothing was added to KNOWN_UNVALIDATED_SCAFFOLDS; it is now empty. The anti-staleness assertion and the flow-absent assertion are both retained.
• packages/spec/** is unchanged. No scaffold needed a spec change; if one had, this would have stopped and reported instead.

🤖 Generated with Claude Code

https://claude.ai/code/session_016yfqQh2dBgPAymYd7xipza

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/cli, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/api/data-flow.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/deployment/cli.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))
• content/docs/protocol/kernel/lifecycle.mdx(via os generate (command, read off packages/cli/src/commands/generate.ts))

What this run could not see

• 2 anchor(s) matched too much of the corpus to be a work list: objectName (symbol, 34 pages), sharingModel (symbol, 39 pages)
• 3 name(s) were too generic to anchor anything (single lowercase words)
• 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 — 22 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 4a378701156050de0608f728d479c0be038ea836 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 100d0cf12fb102526c31f8e8db5e67461485a754 — the merge of head 467e26e9cdb5735f15101bdace858dd5b860fcc5 into base 4a378701156050de0608f728d479c0be038ea836, 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 100d0cf12fb102526c31f8e8db5e67461485a754 && git checkout 100d0cf12fb102526c31f8e8db5e67461485a754
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4a378701156050de0608f728d479c0be038ea836 467e26e9cdb5735f15101bdace858dd5b860fcc5 && git checkout -B drift-repro 4a378701156050de0608f728d479c0be038ea836 && git merge --no-ff 467e26e9cdb5735f15101bdace858dd5b860fcc5
node scripts/docs-audit/affected-docs.mjs --json 4a378701156050de0608f728d479c0be038ea836

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 4a378701156050de0608f728d479c0be038ea836 → pass the list as
args.docs, on the commit named under Which tree this was computed on.