[objectstack-fleet]

Closes #24953

What

A CEL slot declared inside a page component's properties bag that overruns @objectstack/formula's DEFAULT_LIMITS (maxAstNodes 256, maxDepth, maxListElements) is now reported at os validate, os build, os lint and the page publish door (on its advisories channel). The rule is page-predicate-over-budget (validatePagePredicateBounds, a new file in packages/lint). It is a warning in 18.x under the standing ruling 「甲」 (#6015, record 6292005854). Refusing a page that saves today is a narrowing that no ADR-0087 conversion can carry, because a predicate cannot be shrunk mechanically. The 19.0 refusal text is in the report for the seat to file.

Premise, measured on origin/main f32d795

• The page:tabs item visibleWhen the card names had 98 || terms (489 AST nodes, validateExpression answers cel-too-large / maxAstNodes / 256). PageSchema.safeParse gave success. runAuthoringRules('validate' | 'build') gave 0 findings. The page door gave 0 errors, 0 advisories.
• Control: the same source on the component node visibleWhen gave visibility-predicate-over-budget, error. So the bound is already enforced as an error on the node slot, by the visibility family. The tab item is not a component, so that pass never reads its visibleWhen.
• The same gap holds for every other CEL slot a props row declares. Measured clean on main, each over the bound: an object-form section visibleWhen, an object-form inline field visibleWhen, and record:alert visible. A syntax fault on a tab item (record.x === 1) also drew nothing; see Acceptance notes.

How

• The slots come from the schema, not from a list of key names. Each walked component's properties is parsed with its ComponentPropsMap row. Every position where the parse produces a { dialect: 'cel', source } envelope (the output of EvaluatedExpressionInputSchema) is a CEL slot. A slot that a row declares later is covered with no edit here.
• The verdict is validateExpression's. Only its cel-too-large refusal is reported, with the limit and limitValue it carries. The finding names the key and the bound. It does not echo the source: validateExpression's detail quotes the author's line.
• There is no double report. Composition slots (children, footer, items[].children, from pageComponentSlotPositions()) are not descended, because walkPageComponents yields those children as components of their own. The node visibleWhen stays the visibility family's error.
• Wiring: advisory tier, all three commands, CLI_AND_RUNTIME, runtimeTypes: ['page'].
• content/docs: the author-time rule count in four CLI transcripts moves from 49 to 50 (check:docs-transcript-drift).

Tests (head cceddfcb61)

• validate-page-predicate-bounds.test.ts, 18 cases. They cover: the card's shape as a warning at each of validate, build and lint; the door's advisory equal to the build's finding; the within-bounds control drawing nothing at any door; the envelope form; maxDepth and maxListElements naming their bound; object-form section, inline field requiredWhen and record:alert visible; a boolean visible drawing nothing; nested tabs; no double report on node visibleWhen; and the wiring.
• @objectstack/lint full suite: 152 files passed. The one red was the pinned page-door rule roster, updated in runtime-gate.page-visibility-predicate-writes.test.ts, and that file is 15/15 green. @objectstack/lint typecheck green.
• dispatch-gates --ran accounts for all 94 derived families. check:generated is green. NOT MEASURED, prerequisite not met (no built dist/ for the closure; declared to CI): check:dual-build-cjs-loads, check:lean-entry-closure, @objectstack/spec check:skill-examples.

Acceptance notes

• Only bounds are judged on the props-bag slots. A syntax fault in the same slots (for example === on a page:tabs item visibleWhen) still draws nothing and fails open in the same way. Root and reference verdicts cannot be borrowed from the node surface: a tab item binds data to the row and spreads its bare fields. It is reported for the seat.
• Out of scope: objectui's fail-open on a faulting tab-item predicate (reported for objectui).
• Open PR feat(spec,lint): a bulk action's confirmText is a template slot over count and its params, judged at validate, compile and the publish gate #24947 also touches authoring-rules.ts, on a different entry. No textual overlap is expected beyond registry adjacency.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/lint, touching 15 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/lint/src/index.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/api/error-handling-server.mdx (via safeParse (symbol, a method of interface PropsSchema))
• content/docs/deployment/validating-metadata.mdx (via AUTHORING_RULES (symbol, a top-level const object), runtimeTypes (symbol, a field of const object AUTHORING_RULES))

⛔ 1 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-5.mdx (via safeParse (symbol, a method of interface PropsSchema))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/lint/src/index.ts) — pages documenting those are invisible to this run
• 1 cross-cutting symbol(s) contributed no route anchor: safeParse (5 routes)
• 8 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 4 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 4b8f597ba357ba45c7b4b4a4504c78b2a079f123 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 06b2b93cbf43c18db961c34b02f06ffec372f11b — the merge of head cceddfcb610abc5a2c377ea0ffc5e9e5275fa7d9 into base 4b8f597ba357ba45c7b4b4a4504c78b2a079f123, 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 06b2b93cbf43c18db961c34b02f06ffec372f11b && git checkout 06b2b93cbf43c18db961c34b02f06ffec372f11b
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 4b8f597ba357ba45c7b4b4a4504c78b2a079f123 cceddfcb610abc5a2c377ea0ffc5e9e5275fa7d9 && git checkout -B drift-repro 4b8f597ba357ba45c7b4b4a4504c78b2a079f123 && git merge --no-ff cceddfcb610abc5a2c377ea0ffc5e9e5275fa7d9

node scripts/docs-audit/affected-docs.mjs --json 4b8f597ba357ba45c7b4b4a4504c78b2a079f123

⚠️ 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 4b8f597ba357ba45c7b4b4a4504c78b2a079f123 → pass the list as
args.docs, on the commit named under Which tree this was computed on.