fix(spec,rest): declare api.enableSearch, delete the three as-any config reads (#11983)

[os-zhuang]

Fixes#11983

Charter route (triage comment 2026-08-26T01:56Z): declare the live keys with the defaults the runtime already applies, then delete the three as any reads. Clause-②: yes — stays draft for the contract-review enqueue gate; no ready-flip, no auto-merge.

Premise re-verification (issue body is a lead, not a spec)

• git grep enableSearch -- packages/spec/src at base f93df4d → zero hits; positive control enableDiscovery → hits in packages/spec/src/api/rest-server.zod.ts. Premise held for enableSearch.
• Half the card was already done on main: MetadataEndpointsConfigSchema.maskObjectFields is already declared (.default(true), ADR-0106 D8) with its own pin tests. Only the rest-side cast for it was still stale. So this PR declares one key, not two, and deletes all three casts.
• The three casts were re-verified live at base before editing (normalizeConfig: enableOpenApi / enableSearch on api, maskObjectFields on metadata).
• Runtime default for masking read from isObjectSchemaMaskingEnabled itself: default ON, configured === false opts out, OS_ALLOW_UNMASKED_OBJECT_METADATA escape hatch honoured — the declared .default(true) matches.

What changed

• packages/spec/src/api/rest-server.zod.ts: RestApiConfigSchema declares enableSearch: z.boolean().default(true) beside enableOpenApi, with a doc block stating the runtime meaning (deployment-wide search mount switch; discovery reports the conjunction) and the silent-strip history.
• packages/rest/src/rest-server.ts: all three as any reads deleted — normalizeConfig now reads typed fields for enableOpenApi, enableSearch, maskObjectFields. NormalizedRestServerConfig.api.enableSearch becomes a required boolean like its siblings, and the two read sites drop their now-dead ?? true (the discovery-capability comment updated to keep the two read sites pinned together). The assertDeclaredApiConfig doc's stale enableSearch bullet rewritten — the parse stays validation-only for the .omit()ed keys (requireAuth把 public 从"全局开关的副产品"升级为声明式能力,然后删掉 api.requireAuth 开关 #3963 posture, projectResolutionprojectResolution: 'none' is shipped by @objectstack/runtime and forwarded by os serve, but RestApiConfigSchema declares only required|optional|auto — accepted only because the schema was never executed #11999).
• packages/spec/src/api/rest-server.test.ts: three pins mirroring the landed maskObjectFields pins — materialized default; the card's flip measurement (RestApiConfigSchema.parse of enableSearch: false now RETURNS the key, hasOwnProperty asserted); cast-free authorability (compile-time).
• packages/rest/src/rest-config-parse-not-cast.test.ts: the RestApiConfigSchema constrains api.version with a regex the REST server never runs — the seam casts instead of parsing, so api.version: '' is accepted and mounts the whole API at /api// #11637 pin titled "which no schema declares" kept its assertion (opt-out reaches normalized config) but its prose now states the declared reality. Not a debt-ledger file; the ledger, its 12 listed files and rest.test.ts are untouched.
• Regenerated: packages/spec/authorable-surface/api.json, authorable-defaults/api.json (both gain the enableSearch row), content/docs/references/api/rest-server.mdx. The authorable-surface.base.json anchor was not rewritten (lags by design; check:authorable-surface green is the assertion).
• One changeset, patch for @objectstack/spec + @objectstack/rest (additive declaration + cast removal; no landed changeset precedent for the maskObjectFields declaration was findable in the grafted history — divergence flagged per dispatch, patch chosen as dispatched).

No runtime behavior changes: defaults are identical; the change moves the keys from cast-reachable to declared = enforced.

Verification (all at final head b3357c6e unless noted)

• pnpm --filter @objectstack/spec build && check:generated — all 14 artifact gates green (gate's own summary line; earlier run had proved only check:docs stale, regenerated by gen:docs).
• pnpm --filter @objectstack/spec typecheck — green incl. check:test-typecheck: OK (spec test layer compiles; ledger unchanged).
• Spec tests src/api/rest-server.test.ts: 53 passed, incl. the three new [#11983] pins (verbose reporter listing captured).
• pnpm --filter @objectstack/rest typecheck — green (check:test-typecheck: OK — 13 file(s) / 37 error(s) held, unchanged).
• Rest targeted tests (discovery-search-capability-agreement, rest-config-parse-not-cast, discovery-per-request-protocol, meta-object-fls): 4 files, 123 passed.
• Path-named gates: check:authz-resolver, check:route-envelope, check:spec-parsed-alias, check:nul-bytes green; convention gates for edited test files: check:where-matcher, check:query-options-erasure ("baseline key set verified against dfebfc8: no files added"), check:engine-double-contract green; changeset gates check-adr-0087-registration ("no declared-breaking changeset"), check-changeset-no-major, check-empty-changeset green.
• Reverse verification A (predicted direction: red): from the committed fix, the zod file reverted to origin/main (mutation confirmed on disk — enableSearch grep count 0) → exactly the two parse pins failed, 51 passed; restored via checkout from HEAD, git diff HEAD empty.
• Reverse verification B (cross-package type, predicted red): typed read mutated to enableSearchX (confirmed on disk) → tsc error TS2551 with suggestion naming enableSearch — proving rest's typecheck reads the REBUILT spec .d.ts; restored from HEAD, tree clean.
• Gate derivation: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack run from the worktree at my commit (no hand-fed paths); the families it named for this diff are the ones above. Full-farm convergence is CI's, per dispatch.

Out of scope, not touched here: sibling sub-object parses (crud/metadata/batch/routes still cast — same class, tracked by the card family that #11637 filed), projectResolution vocabulary (#11999).

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/rest, @objectstack/spec, touching 5 documentable anchor(s). ⚠️2 changed file(s) yielded no anchor (packages/spec/authorable-defaults/api.json, packages/spec/authorable-surface/api.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/releases/implementation-status.mdx(via RestServer (symbol), registerDiscoveryEndpoints (symbol))
• content/docs/releases/v12.mdx(via RestApiConfigSchema (symbol), RestServer (symbol))
• content/docs/releases/v16.mdx(via RestServer (symbol))
• content/docs/releases/v17.mdx(via normalizeConfig (symbol))

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

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

Coarse fallback — 128 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 5a22dd7622c16efed197e9c562f6543cefb11f13 → packageMentionDocs.

Which tree this was computed on

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

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