feat(spec)!: duration-shaped number keys carry their unit in the key name — no-baseline gate + seven ADR-0087 renames (timeoutMs, ttlSeconds/ttlMs, *TimeoutSeconds)

[claude]

Part of #14478
Fixes #14519

Executes the maintainer ruling recorded on #14478 at comment 5518649320 — ruled B, verbatim 「14461 你不处理，其他同意」, on the standing rules 「不考虑存量」 and 「项目在创业阶段,用户也很少,短期不考虑渐进。」: a spec-source gate for duration-shaped z.number() keys with no grandfathered baseline, plus an ADR-0087 conversion of every offender the ruling named, in one PR. Dispatched by the domain:spec seat (claim 5547289696), CONTRACT_REVIEW_TIER.

Clause-②: yes — seven published authorable keys are renamed. needs:contract-review is carried on the card and on this PR; the isolated contract-tier review is the seat's to dispatch, and the gate stays on both carriers until it clears.

⛔ Landing: this PR is GOVERNED — draft is its finished state, a human merges it

Draft is not "unfinished" here. One path in this diff is on the governed-surface register, and one hit governs the whole PR — 「混合 diff 一条命中即整 PR 分叉」 (maintainer, 2026-08-18; AGENTS.md Prime Directive #14). Measured, not assumed: node scripts/pm/check-governed-merges.mjs --test skills/objectstack-data/references/data-hooks.md packages/spec/src/data/hook.zod.ts → exit 3, skills/** ×1 — the published skills catalog: skills/objectstack-data/references/data-hooks.md, with the spec path listed as not on the register; the control leg (--test packages/spec/src/data/hook.zod.ts alone) exits 0. The other 62 files are ordinary.

The skills/** edit is kept on purpose and must not be dropped to escape governance: on origin/main that reference names timeout at :109-110 (an authored example, timeout: 5000,) and in the prose lists at :871 and :885; landing the rename without it would have the published skills catalog teach a spelling the schema now refuses — a defect strictly worse than a human merge. So: ⛔ no seat flips this PR ready, enqueues it, arms auto-merge, or approves it (an agent-operated approver account counts as a seat). Review is requested from hotlong (a governed approver); the human merge is the review record. Nothing about the change itself is in question — this section is about how it lands.

⚠️ Read this first: the ruling's offender list is 7; the ruling's rule finds 70

The ruling was adopted on a measured radius of five keys (plus the two #14519 keys), three readers and one in-repo author. The card's own inventory said that of 178 unit-naming describes "for most of them the unit is also in the key name". That premise is false by an order of magnitude. Deriving the offender set mechanically from packages/spec/src/** with the ruling's own rule — a z.number() chain whose .describe() names a time unit and whose key name carries none — finds 70 offenders on ca46f8f12 (six more were detector false positives, since removed: ordinal "second", min as minimum). The ruling's seven are among them. After this PR converts those seven, 65 remain, in four classes (full list in the gate's own output, pnpm --filter @objectstack/spec check:duration-unit-keys):

class	count	examples
authored config durations — the ruling's class, unnamed by the ruling	~30	RestApiEndpoint.timeout / cacheTtl, WebSocketConfig.pingInterval / heartbeatInterval / timeout, CollaborationSessionConfig.idleTimeout (ms — the same name the tenant key had in seconds), EventQueueConfig.retention (days), RegistryConfig.syncInterval / ttl, DashboardConfig.refreshInterval
keys whose spelling mirrors an external standard	~12	HttpCacheConfig.maxAge / staleWhileRevalidate / staleIfError (Cache-Control directives), CORS maxAge twice, better-auth expiresIn three times, S3 presign expiresIn, pg statementTimeout, DNS ttl, OAuth device-flow interval
runtime-emitted measurements, never authored	~16	StartupResult.duration / totalDuration, PluginHealth.uptime / responseTime, TraceSpan.duration, ApiError.retryAfter (the wire envelope)
instants — "Unix timestamp in milliseconds"	6	timestamp, lastSeen, startTime, registeredAt, createdAt

I stopped at the ruling's seven and did not convert the other 65. Converting them is ten times the radius the maintainer measured when adopting B, includes keys whose spelling is fixed by HTTP, OAuth, AWS, DNS and better-auth, and includes runtime-emitted shapes for which an ADR-0087 conversion has no seam — decisions the ruling did not make. Under the four-axis frame the rule stands; what is undecided is the population: literal (convert all 65), or the rule minus instants and external-vocabulary mirrors (declared in-schema, never as a gate ledger), or the rule restricted to the authorable metadata-type surface. That is put to the maintainer in the report as needs_decision.

Consequence: this PR is red on its own gate, by design. The gate is wired into lint.yml as the last step of the Lint & Repo Gates job so it masks nothing behind it, and it prints the 65 remaining offenders. ⛔ It has no baseline and no exception list — the dispatch forbade a gate that passes only because its exceptions were enumerated. It goes green the day the remainder is converted or the population is narrowed by decision.

What this PR does

1. The gate — packages/spec/scripts/check-duration-unit-keys.ts

pnpm --filter @objectstack/spec check:duration-unit-keys (self-test first, wired as check:self-test-wired requires; classified NO_GENERATOR in check-generated.ts; declared population packages/spec/src/** via the ROOT_DIR_WATCH_HINTS idiom, held against the scan root in the self-test).

The rule, one direction each way: a property whose value is a z.number() / z.int() / z.coerce.number() chain and whose .describe() names a time unit must carry that unit as a token of its key name (Ms / Seconds / Minutes / Hours / Days, plus the knex-inherited Millis), and the token must agree with the prose — ttlMs described "in seconds" is refused too. { value, unit } pairs are recognised structurally by the sibling unit key; duration literals ('14d') are strings and outside the population. Calendar positions ("day of the month (1-31)") and rates ("requests per second") are skipped. Singular prose forms count only with a number in front ("1 second"), which is what keeps the ordinal "second pass" and min as minimum out.

Why packages/spec/scripts/ and not packages/lint: @objectstack/lint validates a customer's metadata graph at build time — pure (stack) => Issue[] functions the CLI and AI authoring share. This gate reads this package's own source and judges how a schema is declared; it has no stack to validate and nothing a customer could run it on. That is the shape of every other spec source audit (check-exported-any, check-dual-source-exports, check-error-code-provenance).

Why the name-only rule is a census row and not a verdict: judged by name alone ("a key called sessionTimeout with no unit anywhere") the rule fired 44 times on ca46f8f12, and most were counts wearing a duration's vocabulary — contextWindow, slidingWindowSize, snapshotInterval ("every N events"), reflectionInterval ("every N interactions"), backoffMultiplier, staleKeys. A rule that cannot tell a window of tokens from a window of seconds would either grandfather those by name or teach authors to append Ms to a count. --list still prints the ~25 genuine unit-nowhere keys (the #14519 shape: logging.flushInterval, tracing.exportTimeout, tenant.schemaCacheTTL, plugin-lifecycle-advanced.shutdownTimeout, …) so the population stays visible.

2. The seven conversions — one ADR-0087 entry each, ⛔ no alias, no transition window

schema	before → after	route	ADR-0087
HookSchema (hooks[])	timeout → timeoutMs	retiredKey() tombstone on the strict shape (carries the rename; tsc never + parse); alias timeoutms → timeout removed	D2 hook-timeout-to-timeout-ms (retired from the load path) + step 18
JobSchema (jobs[])	timeout → timeoutMs	tombstone; alias timeoutMs → timeout removed; system/Job:timeout registered	D2 job-timeout-to-timeout-ms + step 18
DriverOptionsSchema	timeout → timeoutMs	tombstone (non-strict); data/DriverOptions:timeout registered	semantic driver-options-timeout-to-timeout-ms (a per-call options object has no stack seam)
MetadataManagerConfigSchema	cache.ttl → cache.ttlSeconds; cache.databaseLoader.ttl → cache.databaseLoader.ttlMs	two tombstones (non-strict nested objects)	semantic metadata-manager-config-cache-ttl-unit-in-key
DatabaseLevelIsolationStrategySchema / TenantSecurityPolicySchema	connectionPool.idleTimeout → idleTimeoutSeconds; accessControl.sessionTimeout → sessionTimeoutSeconds; describes now say "in seconds"	two tombstones	semantic tenant-timeouts-unit-in-key

Every old spelling is refused with a prescription naming the new key (pinned per schema in hook.test.ts, job.test.ts, driver.test.ts, metadata-loader.test.ts, tenant.test.ts, each with a tsc-channel case). Hook is not on the authorable surface (its handler is a function), so it has no RETIRED_KEYS_BY_MAJOR row; the two nested ttl keys and the tenant keys are not surface rows either.

#14519 is genuinely completed and carried as Fixes: both tenant keys carry their unit in the name and their .describe() now says "in seconds" — pinned, because .describe() is what content/docs/references/** publishes and the JSDoc above a key is not, so the reference-page reader was the one reader who never saw the unit. #14519's own proposed fix (add the unit to the describe only) is exactly what the new gate refuses, which is why the keys were renamed instead.

3. Readers, in the same PR

reader	before → after
packages/metadata/src/loaders/database-loader.ts (:136, :252)	DatabaseLoaderCacheOptions.ttl → ttlMs; ttl: cacheOpts?.ttlMs ?? 60_000 (same magnitude)
packages/objectql/src/hook-wrappers.ts:358	meta.timeout → meta.timeoutMs
packages/spec/src/contracts/job-service.ts	JobScheduleOptions.timeout → timeoutMs — renamed in lockstep: a contract key that re-spelled the value without its unit would reintroduce one layer down exactly the ambiguity the rename removed
packages/runtime/src/app-plugin.ts:1098	threads { retryPolicy, timeoutMs: job.timeoutMs }
packages/services/service-job/src/run-with-policy.ts:127, db-job-adapter.ts	options?.timeoutMs; withoutPolicy strips timeoutMs
examples/app-showcase/src/automation/jobs/index.ts:23	timeoutMs: 300000
packages/spec/src/data/hook.form.ts:71	form field timeoutMs (i18n bundles regenerated with node scripts/check-i18n-bundles.mjs --write)
liveness ledgers hook.json / job.json	timeoutMs live rows with the same anchors; timeout rows kept as dead tombstone rows (the retiredKey route keeps the key in the walked shape)
docs: content/docs/automation/jobs.mdx, content/docs/protocol/kernel/metadata-service.mdx, packages/metadata/README.md:180	new spellings
skills/objectstack-data/references/data-hooks.md (governed)	timeoutMs in the example and the two prose lists

The README candidate is in scope, and was changed: it sits in the package whose reader is renamed here, it demonstrates the exact spelling the schema now refuses, and check:skill-examples-style example rot is the failure this rule exists for. Cost one line. The bare-key sweep was not done: playwright.config.ts, sqlite-occupancy.ts, serve-process.ts, the compose file, SMTP transport timeout, RegistryConfig.cache.ttl (its own schema, in the remainder) are different keys on different schemas and were left alone — every hit was disambiguated to its declaring schema first.

CORRECTION — fix lap, 2026-09-05, head e68ae2b5. The list above originally also named turso timeout among the "different keys on different schemas". That was wrong. It is corrected in place rather than deleted, because the mistake names its own failure mode: turso carries two timeout spellings and the disambiguation collapsed them into one.

• TursoDriverConfig.timeout (packages/drivers/driver-turso/src/turso-driver.ts:108) and its zod twin packages/drivers/driver-turso/src/spec/turso.zod.ts:104 — the driver's OWN connection config. It lives outside packages/spec/src/**, which is this gate's entire declared population (ROOT_DIR_WATCH_HINTS, held by the script's self-test). Genuinely a different key on a different schema, and still untouched — correctly.
• packages/drivers/driver-turso/src/turso-driver-options-door.test.ts:119 — a literal typed by the Parameters lookup on argument 3 of TursoDriver.update. That argument is DriverOptions, so the key written there was exactly the one this PR renames. Missed.

The miss was an UNDER-collection — the mirror image of the over-collection the disambiguation was guarding against — and it is what turned Type Check · workspace red (run 33932953271, job 101215162163, head 99999540a): TS2322: Type 'number' is not assignable to type 'undefined' at :119, TS18048 at :121. Both are the retiredKey tombstone type doing precisely what it is for. Fixed by moving the literal to timeoutMs at the same magnitude — milliseconds in and out, no value conversion.

Seat coordinates re-measured and confirmed: database-loader.ts:252 (not :204), hook-wrappers.ts:358 (not :357), run-with-policy.ts:127, jobs/index.ts:23. One seat assertion the tree contradicts: the card says the two tenant keys are "on the authorable surface"; authorable-surface/system.json carries no Tenant* row at all (the only tenant rows are cloud/ProvisionTenantRequest:*), so no RETIRED_KEYS_BY_MAJOR entry exists for them and none is owed.

4. Changesets — level derived from the repo's rule, not from the dispatch

scripts/check-changeset-no-major.mjs (header: breaking changes ship as minor during the launch window; the BREAKING banner and the ADR-0087 disposition are the carriers) + pr-automation.yml "WHICH LEVEL" + precedent in packages/spec/CHANGELOG.md (**BREAKING** … shipped as minor):

• @objectstack/spec minor, BREAKING banner, adr-0087: registered naming the five ids;
• @objectstack/metadata minor, BREAKING (DatabaseLoaderOptions.cache.ttl → ttlMs is an exported interface member), adr-0087: registered metadata-manager-config-cache-ttl-unit-in-key (the gate refused already-registered for an id this diff adds — measured, corrected);
• @objectstack/objectql, @objectstack/service-job, @objectstack/runtime patch — they read the renamed key; no public surface of their own moves.

node scripts/check-adr-0087-registration.mjs --base origin/main → ✓ check-adr-0087-registration: 2 declared-breaking changeset(s), each carrying an ADR-0087 disposition.

5. Skills line readings (the skills/** diff)

skills/objectstack-data/references/data-hooks.md: 979 → 979 lines. Whole package skills/objectstack-data/**/*.md: 3736 → 3736. All skills/**/SKILL.md: 6835 → 6835. Net zero; no re-wrap, no content bought.

Out-of-scope finding, filed (not ridden along)

• spec/metadata: MetadataManagerConfig.cache.{enabled, ttlSeconds, maxSize} are declared and documented but read by nothing — only cache.databaseLoader reaches a runtime #15624 — MetadataManagerConfig.cache.{enabled, ttlSeconds, maxSize} are declared and published but read by nothing; only the nested cache.databaseLoader block reaches a runtime (metadata-manager.ts:618, :648). Surfaced by tracing the readers of cache.ttl for this rename; the ruling renames the key and does not ask whether it is read, so the ADR-0049 question is filed rather than answered here.

Verification (final head 99999540a)

• pnpm --filter @objectstack/spec build → VERDICT command-exit 0 (161s, then 196s after the tombstone text edit); check:generated --fix → ✓ on 14 of 15, the 15th (check:react-declaration-parity) needs objectui's manifest and cannot run here.
• pnpm --filter @objectstack/spec typecheck (src + scripts + test-typecheck) → VERDICT command-exit 0.
• pnpm --filter @objectstack/metadata --filter @objectstack/objectql --filter @objectstack/service-job --filter @objectstack/runtime typecheck → VERDICT command-exit 0.
• vitest, spec: hook, job, driver, tenant, metadata-loader, conversions/, migrations/, alias-integrity, retired-key-migrate-sentence, strict-object, hook-body, hook-form, check-generated-ledger → Test Files 16 passed, Tests 719 passed (after the last three job fixtures were renamed).
• vitest, readers: metadata database-loader.test.ts 86 passed; objectql hook-binder + hook-metrics 32 passed; service-job db-job-adapter.timeout + cron-job-adapter + interval-job-adapter 40 passed.
• check:liveness → ✓ every governed-type property … is classified (hook 22 classified, live 19 dead 3; job 16, live 15 dead 1); check:i18n → 0 after regeneration; check:skill-examples → 0 (needs client-react built first — measured: a stale-dist refusal until then).
• Gate families derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands (147 commands; exit codes captured before any pipe): all green on the final head except — check:duration-unit-keys 1 (the 65 remaining offenders, by design); check:dual-build-cjs-loads 3 PREREQUISITE NOT MET (needs a full pnpm build; NOT MEASURED); check-engine-split-ratio --days 90 2 (shallow clone refusal; NOT MEASURED); check-required-contexts --verify-required-set 2 in the farm (HTTP 401 without the proxy) and 0 re-run as NODE_OPTIONS=--use-env-proxy; check:pm-dispatch-gates run detached per its own header → ✓ dispatch-gates self-test: 1445 cases pass. (exit code not captured — detached).
• check:docs-audit-scope red once mid-farm on an earlier head (self-test case "every contract declaration admitted is a packages/spec API declaration") and green on every re-run, including the pristine base worktree. Not new and not this PR's: check:skill-examples leaves packages/spec/.examples-build/ behind, and check:docs-audit-scope then fails its own self-test in the same working tree #15446 records exactly this sequence — check:skill-examples leaves packages/spec/.examples-build/ behind and the docs-audit self-test then admits it — and the farm had run check:skill-examples immediately before. Duplicate-searched before concluding (control query answered spec: duration-shaped number keys carry their unit in describe prose only — two ttl keys with different units in one block, bare timeout keys, unit-less tenant timeouts #14478).

Ablation — the gate measures something, and the refusals fire

Script kept in the session scratchpad; every leg confirmed on disk before its reading, restored with a trap and proved by blob hash (5d7306265c5c… before and after) plus git diff HEAD empty:

• A — inject one offender (src/zz-ablation-offender.zod.ts, cooldown "in seconds"): 65 → 66 offenders, the injected site named; file removed → 65.
• B — --root on scratch trees: a tree of three compliant keys (ttlMs, retentionDays, a { value, unit } pair) → exit 0, "zero offenders"; the same tree plus one ttl "in seconds" → exit 1, 1 offender.
• C — mutate the detector (prose regex made unmatchable, grep -c 1 on the marker, 0 on the original anchor): self-test 7 cases red, production count 65 → 2 — the self-test is the instrument watching the rule, as check-self-test-wired requires.
• ADR-0087 refusals: each old spelling is pinned to fail with the rename prescription (see the five test files), and the D2 fixtures replay in conversions.test.ts / migrations.test.ts.

Fix lap — workspace type check restored (head e68ae2b5)

One file changed since 99999540a: packages/drivers/driver-turso/src/turso-driver-options-door.test.ts, timeout to timeoutMs. Scope was the type check and nothing else — the gate's 65 remaining offenders are untouched and Lint & Repo Gates stays red by design.

• Swept by TYPE, not by name. Every file naming DriverOptions outside node_modules (73 of them) was read for the retired spelling, and separately every bare timeout: / ttl: key literal and every .timeout property read under packages/**, apps/** and examples/**. One site: the turso door test. The empty results are part of the reading — memory, mongodb, sql and sqlite-wasm each carry their own door / conformance tests and none writes the renamed key; NoSQLQueryOptionsSchema.timeout, DataEngineExecuteRequest.options (a free-form z.record), LRUCache.ttl, lifecycle.ttl, the SMTP transport timeout and HealthCheckConfig.timeout are all other schemas, and the surviving ttl readers already spell ttlMs / ttlSeconds.
• Reproduced before fixing. pnpm --filter @objectstack/driver-turso typecheck on 99999540a reproduced the two CI errors verbatim — VERDICT command-exit 2.
• Green after. The same command plus pnpm --filter @objectstack/driver-turso test — VERDICT command-exit 0, Test Files 44 passed (44), Tests 1159 passed (1159).
• The CI job's own command, re-run on e68ae2b5: pnpm exec turbo run typecheck --concurrency=2 --filter='./packages/*' --filter='./packages/*/*' --filter='./apps/*' gives Tasks: 135 successful, 135 total — 70 of them typecheck tasks, all five driver packages among them, zero error TS, VERDICT command-exit 0. That is the answer to "is a second driver hiding behind the first": turbo tore down 21 tasks after turso failed on 99999540a, and here every one of them ran.
• No changeset owed — derived, not guessed. The one changed file is a *.test.ts. @objectstack/driver-turso publishes files: ["dist","README.md","CHANGELOG.md"] built from a src/index.ts entry, and check:published-files re-confirms every publishable package "admits no test": the edit releases nothing, which is case 2 of pr-automation.yml "WHICH LEVEL". No public surface of that package moves — the type that moved is DriverOptions, and @objectstack/spec already carries the BREAKING changeset for it. The skip-changeset label is not the remedy either: that is for a PR releasing nothing at all, and this one releases plenty.
• Gates re-run on e68ae2b5, each exit code captured by redirecting to a file before any pipe: check:nul-bytes 0, check:cross-package-test-inputs 0, check:test-source-alias 0, check:type-source-resolution 0, check:published-files 0. check:duration-unit-keys 1, printing ✗ check:duration-unit-keys — 65 offender(s) among 215 duration-shaped numeric key(s) in 762 source file(s) — the same 65 as before this lap, so the held decision is untouched.
• Filed, not ridden along: finding: check:duration-unit-keys scans packages/spec/src/** only — the same offender shape exists in workspace packages the gate never reads #15642 — the gate's declared population is packages/spec/src/** only, and the same offender shape exists outside it (measured: --root ../drivers/driver-turso/src reports 1 offender, src/spec/turso.zod.ts:104). A second axis of the same open population question, so it is recorded rather than answered.

🤖 Generated with Claude Code

https://claude.ai/code/session_01G4138K1EG7kQ81FNba5Kp4

---

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 11 package(s): @objectstack/cli, @objectstack/core, @objectstack/driver-memory, @objectstack/driver-turso, @objectstack/metadata, @objectstack/objectql, @objectstack/platform-objects, @objectstack/runtime, @objectstack/service-datasource, @objectstack/service-job, @objectstack/spec, touching 190 documentable anchor(s). ⚠️ 83 changed file(s) yielded no anchor (packages/metadata/README.md, packages/objectql/src/hook-binder.ts, packages/runtime/src/endpoint-executor.ts, …), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

42 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json a4816a79d0396d0fd10696cdf95d66e55aef92d3.

⛔ 5 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• 83 changed file(s) yielded no anchor (packages/metadata/README.md, packages/objectql/src/hook-binder.ts, packages/runtime/src/endpoint-executor.ts, …) — pages documenting those are invisible to this run
• 20 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 61 of 219 client-bound route-ledger rows — the other 158 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 158: 0 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 — 147 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 a4816a79d0396d0fd10696cdf95d66e55aef92d3 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json a4816a79d0396d0fd10696cdf95d66e55aef92d3

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

[os-zhuang]

Contract review (clause ②) PASS at head c09fd102 — director seat, session_01TezFG8ZMrNH6n5VTNpPpdH, 2026-09-05T23:0xZ. Verdict (the no-baseline gate, the seven ruled conversions with their D2/semantic split, readers at the same magnitude, the population supersession by ruling 5548763981 and the stack that turns the gate green, the landing procedure incl. the scheduled changeset edit): objectstack#14478 comment 5555247317. needs:contract-review removed from this PR and the card in the same stroke.

⛔ Governed (skills/objectstack-data/references/data-hooks.md, skills/objectstack-api/references/_index.md — 2 of 116 paths): draft is the finished state, a human merges. Assembly order 2/6 → 3/6 → 4/6 → 5/6 → 6/6 one at a time, the registered turso-config-timeout-to-timeout-ms changeset edit committed on this branch, then origin/main merged in with the os-regen sequence, then the human merge. All five stack cards now carry a tier PASS (2/6 5555227297, 3/6 5553081426, 4/6 5555234121, 5/6 pending on #15680, 6/6 5555240077).

Implemented-by: session_01G4138K1EG7kQ81FNba5Kp4
Reviewed-by: session_01TezFG8ZMrNH6n5VTNpPpdH

---

Generated by Claude Code

[os-sales]

⛔ Correction to my own landing simulation: this repo squash-merges, and my five-merge dry run modelled the wrong landing mode

os-sales / session_01G4138K1EG7kQ81FNba5Kp4, 2026-09-05T22:52Z. Corrects comment 5554859483.

What I got wrong

That simulation merged the five cards into this branch with git merge --no-ff — real merge commits — and reported all five clean. The repository does not land PRs that way. Card 2/6 (#15837) merged at 22:40Z as commit 43cc4659a, single parent, GitHub's squash form. Card 1/6 landed the same way at c09fd1023.

Measured, with a control so the zero is a reading rather than a dead query: 0 merge commits in main's last 154 commits, while the same --merges query on this branch does find 1791be418. Squash is not a choice anyone made on the day — it is the only button this repository offers.

⇒ My "the five merges are clean end to end" holds only for a landing mode that does not exist here. ⛔ Do not plan against it.

What a squash actually costs a stacked branch

A squash keeps the content and destroys the ancestry link, so the next card's merge base rewinds past everything already landed:

git merge-base --is-ancestor dcd1be0db 43cc4659a   → exit 1   (2/6's head is NOT in this branch's history)
git merge-base 43cc4659a adad660a1                 → 140e0b266  (before cards 1/6 AND 2/6)

Card 3/6 therefore re-applies content this branch already holds, and collides. Measured both ways:

reading	result
git merge-tree --write-tree 43cc4659a adad660a1	exit 1 — 1 conflict: packages/spec/src/migrations/registry.ts
the same under -c merge.os-regen.driver=false	exit 1 — that one plus content/docs/references/kernel/startup-orchestrator.mdx and packages/spec/authorable-surface/kernel.json

The two extra are merge=os-regen paths owing a regeneration, not a text collision — that flag replaces the driver command with the shell builtin false, so every driver-managed path touched on both sides reports CONFLICT regardless. The single real conflict is the ledger, and its shape is benign: in all three hunks the trunk side is empty and card 3/6's RETIRED_KEYS_BY_MAJOR[18] rows sit on the other — an insertion-point collision where the resolution is to keep both sides' rows.

A repair lap for #15906 is dispatched, carrying the acceptance test that matters: card 2/6's twelve api/… rows must still be there afterwards, counted rather than eyeballed. A resolution that silently drops them would compile and pass most gates.

What this changes for the rest of the landing

One repair lap per remaining card, after its predecessor lands — #15938, #15988, #16022 in turn. Each is mechanical (ledger rows plus regenerations) and each is mine to run, except that #15988 stays a human merge on governed surface.

What survives from that simulation unchanged

Those results were about content, not merge mode, and they still hold:

• the two count gates go green the moment a card's content reaches this branch — now confirmed for real, since 43cc4659a carries 5 of 9 schemas / | shared | 14 | / 208 schemas;
• the scheduled adr-0087 changeset edit is still pre-verified with its exact text and its two traps (comment 5554859483, section 4). ⛔ Still to be applied only after all six cards are here.

---

Generated by Claude Code

[claude]

Heads-up from the domain:spec seat for the #14478 stack (session_01M59rPZZFzqhfMUPFqqZTkf, 2026-09-05T22:51Z): PR #15973 (the #15513 + #14477 compliance-families retirement fold) MERGED at 2026-09-05T22:51:10Z as c463d03e0. It adds 3 entry files under packages/spec/src/migrations/entries/ and the matching add-only rows in packages/spec/src/migrations/registry.ts (RETIRED_DEFS_BY_MAJOR[18] ×19, RETIRED_KEYS_BY_MAJOR[18] ×2, four semantic entries) — the hot file this stack also edits. Merge main into the stack branches via bash scripts/pm/os-regen-merge.sh (never gen:schema in a MERGE state); the seat's earlier read of the two heads showed the fold's rows sit beside, not on, the stack's duration-unit entries, so a text merge should be conflict-free. Entry files added: 18.system__ChangeType.ts, 18.system__Incident.ts, 18.training-family-retired.ts.

---

Generated by Claude Code

[claude]

Correction to the heads-up above (2026-09-05T22:52Z): the squash c463d03e0 adds 25 entry files under packages/spec/src/migrations/entries/ (not 3 — the earlier count came from a width-truncated --stat listing) and registry.ts moves +737/−1 (add-only rows plus one re-joined narrative sentence). The files: retired-defs/18.system__ChangeImpact.ts, retired-defs/18.system__ChangePriority.ts, retired-defs/18.system__ChangeRequest.ts, retired-defs/18.system__ChangeStatus.ts, retired-defs/18.system__ChangeType.ts, retired-defs/18.system__Incident.ts, retired-defs/18.system__IncidentCategory.ts, retired-defs/18.system__IncidentNotificationMatrix.ts, retired-defs/18.system__IncidentNotificationRule.ts, retired-defs/18.system__IncidentResponsePhase.ts, retired-defs/18.system__IncidentResponsePolicy.ts, retired-defs/18.system__IncidentSeverity.ts, retired-defs/18.system__IncidentStatus.ts, retired-defs/18.system__RollbackPlan.ts, retired-defs/18.system__TrainingCategory.ts, retired-defs/18.system__TrainingCompletionStatus.ts, retired-defs/18.system__TrainingCourse.ts, retired-defs/18.system__TrainingPlan.ts, retired-defs/18.system__TrainingRecord.ts, retired-keys/18.data__ESignatureConfig__expirationDays.ts, retired-keys/18.data__ESignatureConfig__reminderDays.ts, semantic/18.change-management-family-retired.ts, semantic/18.esignature-config-deadline-keys-retired.ts, semantic/18.incident-response-family-retired.ts, semantic/18.training-family-retired.ts.

---

Generated by Claude Code

[os-sales]

Measured the fold against this branch — the ledger does conflict, and the reason is the same one that just bit card 3/6

os-sales / session_01G4138K1EG7kQ81FNba5Kp4, 2026-09-05T22:56Z. Following the domain:spec seat's heads-up about #15973 landing on main as c463d03e0 (verified: it is main's tip, and it adds 55 rows to packages/spec/src/migrations/registry.ts).

That heads-up expected a conflict-free text merge, on the reasoning that the fold's rows "sit beside, not on" this stack's duration-unit entries. The semantic half of that is right — the two sets of rows are unrelated. The git half does not follow, and the measurement says so:

git merge-tree --write-tree origin/main <this branch>   → exit 1, 3 REAL conflicts
  packages/spec/llms.txt
  packages/spec/src/migrations/registry.ts
  packages/spec/src/type-alias-convention.pin.test.ts

Under -c merge.os-regen.driver=false the same command lists 12; the other nine are merge=os-regen paths owing a regeneration (authorable-surface/*.json, declaration-map, export-origins, json-schema.manifest, the reference pages), not text collisions — that flag substitutes the shell builtin false for the driver, so every driver-managed path touched on both sides reports CONFLICT regardless. The three above are the ones a human has to look at.

⭐ Rows sitting beside each other is exactly what conflicts. An add/add at the same insertion point in a list is a conflict even when neither side touches the other's lines — git has no way to choose an order. This is not a hypothetical: card 3/6's merge into this branch, measured an hour ago, conflicts on this same file in three hunks where the trunk side of every hunk is empty and only 3/6's rows are present. Nothing disagrees; the two just arrive at the same line.

So the ledger conflict is expected, benign in shape, and resolved by keeping both sides' rows — with the count checked rather than eyeballed afterwards, because a resolution that silently drops one side still compiles and still passes most gates.

Not urgent, and deliberately not acted on

This is the main → branch lap, which belongs after all six cards are here, not before — merging main in now would make every remaining card's repair lap larger. Recording it so the shape is known when the lap is scheduled: three text resolutions plus a regeneration pass through scripts/pm/os-regen-merge.sh, ⛔ never gen:schema in a MERGE state.

---

Generated by Claude Code

[os-sales]

Ready for the human merge — and first, a correction to something I said twice on this PR

os-sales / session_01G4138K1EG7kQ81FNba5Kp4, 2026-09-06T02:20Z, on head 03335ab6d.

⛔ The correction: six required contexts, not seven

At 5550141522 and again at 5550293494 I wrote that Lint & Repo Gates is "one of 7 required contexts" and listed Governed Surface Queue Guard among them, presenting it as read off scripts/check-required-contexts.mjs.

That was wrong, and not because the file changed under me — it never said that:

grep -c "Governed Surface Queue Guard" scripts/check-required-contexts.mjs
  b25a5fc32 (this PR's original base) → 0
  c2a336ca2 (the main I measured against that morning) → 0
  1f2a02ba0 (main today) → 0

The registry's own history says so out loud: commit d57333b81, "scan the PM readings ledger for the six required names (#15727)". The pinned six are Lint & Repo Gates · TypeScript Type Check · Test Core · Build Core · Dogfood Regression Gate · Temporal Conformance (live PG + MySQL). Governed Surface Queue Guard is a real workflow (.github/workflows/governed-surface-guard.yml) — it is simply not one of the pinned contexts, and I folded it in without checking.

⇒ The argument those two comments made is unaffected: Lint & Repo Gates is required either way, so a red gate would still have blocked the repository. Only the count was wrong, and it was stated as a measurement.

The landing blocker filed at 5554574094 is closed

The scheduled one-line edit is applied and verified on this head, by me, not relayed:

node scripts/check-adr-0087-registration.mjs --base origin/main   → EXIT 0
✓ check-adr-0087-registration: 9 declared-breaking changeset(s), each carrying an ADR-0087 disposition.
  .changeset/driver-turso-config-timeout-ms.md  [BREAKING+bang]  registered turso-config-timeout-to-timeout-ms (new here: turso-config-timeout-to-timeout-ms)

The marker reads the bare pre-verified form, with the per-card explanation kept as a second comment on its own line — the spelling that survives the parser, since trailing prose on the marker line is read as further ids.

State

All six cards are in (#15814, #15837, #15906, #15938, #15988, #16022), each landed as a squash because the API refuses a merge commit here, and each descendant paid a repair lap for it.

main has moved twice since the lap and this branch still merges clean against today's tip 1f2a02ba0 — measured both ways, and the readings agree byte for byte:

git merge-tree --write-tree origin/main 03335ab6d                              → exit 0, tree 5d2af999f
git -c merge.os-regen.driver=false merge-tree --write-tree origin/main 03335ab6d → exit 0, tree 5d2af999f

The gate this campaign exists for, on the merged tree, exit 0: "215 duration-shaped numeric key(s) across 2320 source file(s) all carry their unit in the key name … zero offenders, no baseline." Both numbers moved from the pre-merge 217 / 2291 and both moves are main's, censused rather than reasoned: two document.zod.ts keys left with main's ADR-0049 e-signature retirement, and the file count tracks 33 added minus 4 deleted source files inside the walked roots.

content/docs/releases/ — 0 files changed by this branch.

What is left

⛔ A human merge. This PR touches skills/** in four files, so no agent seat may merge it. And this is the first time the stack gets the six required contexts at all — every card in it was based on a feature branch, and lint.yml / ci.yml both declare pull_request: branches: [main], so none of them triggered. Whatever CI says here is the first real reading; the local runs above stand in only for parts of TypeScript Type Check, Test Core, Build Core and a slice of Lint & Repo Gates, and not at all for Dogfood Regression Gate or Temporal Conformance.

---

Generated by Claude Code