feat(service-settings,platform-objects)!: the settings cascade's global rung moves to the tenant-less sys_platform_setting (ADR-0131 D7)

[objectstack-fleet]

Part of #15207

Clause-②: yes (widening: a new platform object sys_platform_setting, and a new name if packages/spec exports one; the global rung's storage narrows on sys_setting. The dev measures the built declaration closure.)

The line above is the claim's (6049595369), copied verbatim. The measured arm is in the changeset: Clause-②: yes (narrowing) — the diff widens (a new object, SysPlatformSetting and CONFIG_CHANGE_GLOBAL_OBJECT_NAME exported, a new name in PLATFORM_OBJECTS_BY_PACKAGE) AND narrows (the global option of sys_setting.scope retires, and the global rung's storage leaves sys_setting). @objectstack/spec's exported TYPE surface does not move: the name list is data, and the new ADR-0087 entry and rationale fragment live in the generated registry.

Scope: item (3) only

This PR builds scope item (3) of #15207: the scope: 'global' rung of sys_setting leaves the tenant-scoped object (ADR-0131 D7, §6 Q3) for a tenant-less sys_platform_setting, and the settings cascade reads the new source. Item (1) landed as PR #22107. Items (2) and (4) are not here, so #15207 remains open. No stored row moves in this PR: existing global rows move in the v18 operator ceremony (C7, #15211), per ADR-0131 D14.

What changes

• sys_platform_setting (packages/platform-objects/src/system/sys-platform-setting.object.ts), registered by the settings service beside sys_setting:
  • one row per (namespace, key) for the deployment: unique: 'global' on (namespace, key);
  • the value and encryption columns of a sys_setting row: value, value_enc (read-only), encrypted, locked, locked_reason, updated_by (read-only);
  • no scope, no user_id, and no organization column (systemFields: { tenant: false });
  • governed by object permission (D7): requiredPermissions: ['manage_platform_settings']; generic API get / list only.
• SettingsService (settings-service.ts):
  • a write at a key declared scope: 'global' lands in sys_platform_setting, keyed (namespace, key), never in sys_setting;
  • the cascade's global rung is read from sys_platform_setting alone. Every sys_setting read now names its rungs ($or over tenant / user, or user_id / tenant), so a scope = 'global' row a pre-v18 database still holds there is not a second source. There is no fallback read and no boot-time move (D14);
  • the rank table, the lock check, SpecifierScope and source: 'global' are unchanged;
  • the global rung does not depend on the user, so getMany reads it once per call: sys_setting keeps its resolveLocalizationContext reads the same sys_setting namespace three times per request #10826 bound (at most two reads), plus one sys_platform_setting read.
• config_change audit row: a global-scope change now names sys_platform_setting (CONFIG_CHANGE_GLOBAL_OBJECT_NAME, exported beside CONFIG_CHANGE_OBJECT_NAME). A tenant- or user-scope change still names sys_setting. Without this, the row would name a table the value is not in.
• sys_setting.scope no longer declares global (H6). sys_setting_audit.scope keeps it, because the audit writer records the changed key's scope and a global change is still a change. The translation bundles drop the retired leaf, and the es-ES echo ledger drops its row (47 to 46 echoes).
• os secret orphans / os secret rewrap (packages/cli/src/utils/secret-reference-union.ts): the settings family of the sys_secret reference union reads BOTH holders, sys_setting.value_enc and sys_platform_setting.value_enc. If either cannot be read, the whole family gaps (H3).
• ADR-0087: one D3 semantic entry, sys-setting-global-rung-moved, and one step-18 rationale fragment. The registry is regenerated. spec-changes.json and the upgrade guide do not move, because step 18 is not projected yet.
• Regenerated census artefacts:
  • platform-object tenancy census: 83 to 84 registered objects, out of reach 33 to 34, systemFields.tenant: false 8 to 9;
  • tenant-audit census: two sites moved from unreadable options to readable, because the as any spread of bypass is gone (171 to 173 threading a tenant context);
  • query-options erasure baseline: settings-service.ts 2 to 1, a ratchet down.

Readings (measured at 51290bca2c, re-checked after merging main)

H1 holds: nothing moves to configuration. A census of every registered manifest (the built builtinSettingsManifests plus objectql's lifecycleSettingsManifest) found 109 keys at the global rung in seven namespaces: auth 29, ai 35, storage 11, mail 10, sms 10, knowledge 10 and lifecycle 4. lifecycle.retention_overrides is the one tenant key in a global manifest. Every one of the seven requires manage_platform_settings to read and to write through the door, so every one is edited live in Setup. Their in-tree consumers re-read on change:

• plugin-auth and organizations use getNamespace('auth'), and plugin-auth re-applies on subscribe('auth');
• plugin-email (mail), service-sms (sms) and service-storage (storage) each re-apply on subscribe;
• lifecycle is read on every sweep;
• ai and knowledge have no in-tree value reader beyond their test actions, which runAction resolves live.

No key is boot-read only, so there is no open_questions entry for a configuration move.

No writer attributes a global row to an organization (the stop condition did not fire).

• SettingsService.setMany is the only writer of a settings row. It writes under { isSystem: true }, with no tenantId and a row that names no organization.
• sys_setting is unclassified in the platform-object tenancy inventory, so resolveSystemInsertOrganization derives nothing.
• The new pin writes a global key with a writer context of tenantId: 'org_1', and the stored row carries no organization.
• Two organization signals do sit on the global WRITE PATH, but neither attributes the settings ROW:
  • the CryptoContext passed to encrypt carries tenantId: ctx.tenantId for every rung. The only in-tree provider (LocalCryptoProvider) binds no tenant into the AAD, and materialiseRow decrypts with no tenantId at all;
  • the config_change audit row stamps the writer's organization (item (2)'s object).

H2: global-rung readers outside the service. Census of every non-test source naming sys_setting. The procedure fires: it flags the union and the orphan command.

reader	reads the global rung?	disposition
cli/src/utils/secret-reference-union.ts (settings collector)	yes: every row, no scope filter	fixed here (reads both holders)
cli/src/commands/secret/orphans.ts, lines 300 to 309 (legacy-inline guard rows)	yes: every row	outside the claim's surface, not edited (see Acceptance notes)
cli/src/utils/sys-secret-orphan-sweep.ts	no read: pure, consumes the rows orphans.ts hands it	none
core/src/security/resolve-authz-context.ts, line 1696	no: the direct read pins scope: 'tenant'; the service leg goes through getMany	none
metadata-protocol/src/migrations/sys-setting-identity-index.ts	index maintenance over all rows, pre-v18 global rows included; it reads no value	none (see Acceptance notes)
mcp/src/plugin.ts, plugin-hono-server/src/current-user-endpoints.ts	no: comments only; they read through resolveLocalizationContext	none
service-settings/src/sys-secret-orphan-report.ts	no read: a pure classifier over caller-supplied rows, with no in-tree caller	none

H3 holds, and is closed here. Before the union fix, a credential held only in sys_platform_setting.value_enc is attributable (its (namespace, key) is a declared encrypted specifier) and unreferenced by sys_setting. That is exactly the deletable shape, so the sweep would delete the credential in force. Ablation B below turns the three pins red, including the sweep's referenced → deletable.

H4: the AAD binds no holder object and no organization. LocalCryptoProvider's version-2 AAD is the 0xFF lead byte, a version label, then lp(scope) || lp(namespace) || lp(key). scope is the producer vocabulary (settings). It binds no object name, no organization and no tenant (aadForVersion2, local-crypto-provider.ts). So C7's row move needs no re-encryption: copy value_enc (the sys_secret handle) unchanged into the new row with the same (namespace, key). The sys_secret row does not move. A pin seals a handle with an organization in the context, places it in a sys_platform_setting row, and resolves it.

H5: object permission holds, and the settings door is unaffected. This was measured with a scratch harness, not committed: the real SecurityPlugin middleware, the registry-processed sys_platform_setting and the shipped permission sets, running a find.

posture	organization admin	platform admin	member	system context (the service)
none registered	403 PERMISSION_DENIED	admitted, no filter	403	admitted
single	403 PERMISSION_DENIED	admitted, no filter	403	admitted
isolated	403 PERMISSION_DENIED	admitted, no filter	403	admitted
control: same object without requiredPermissions, any posture	admitted, no filter	admitted	403	admitted

The control row is why the gate ships with the object: with no column there is no wall. The settings door is unchanged. settings-admission-tenancy-posture.test.ts and config-change-audit.test.ts drive the plugin's own routes over a real ObjectQL with a scope: 'global' manifest, and the row lands in sys_platform_setting (200).

H6: half holds. After this PR no writer writes scope: 'global' into sys_setting, so its global option is retired, with the ADR-0087 entry. The sys_setting_audit.scope mirror is still written (the audit writer records entry.scope), so it stays. The parity pin now reads: sys_setting.scope = SpecifierScopeSchema minus global, and sys_setting_audit.scope = SpecifierScopeSchema.

Zone 3's suggested pin "a tenant and a user value still override it" is falsified by the unchanged rank table. scopeRank gives global rank 1 and resolveKeyFromRows takes the first non-null rung, so a global value OUTRANKS the tenant and user rungs. It did before this PR and does after it. The pin asserts what the rulings keep: global from the new store outranks both, and the tenant and user rungs answer once it is empty.

What C7 (#15211) must do with the rows (recorded, not built)

• For every sys_setting row at scope = 'global', write one sys_platform_setting row with the same namespace and key, and copy value, value_enc, encrypted, locked, locked_reason and updated_by. Then remove the source row.
• value_enc is copied verbatim: re-encryption is neither needed nor wanted (H4). The sys_secret row stays where it is, and its handle id is unchanged.
• A (namespace, key) with more than one global row is possible on a pre-sys_setting's declared row identity is unenforced on every tenant and global row — user_id is NULL there and SQL UNIQUE is NULL-distinct #8629 database, because NULL-distinct unique let duplicates in. The ceremony has to pick one. sys_platform_setting's (namespace, key) unique refuses the second.
• Until the ceremony runs, a moved key answers from its next rung or the manifest default. The v18 boot refusal (D10) is what stops a deployment from running in that state.

Tests

All suite counts below were read at the merged head d0477879af, unless a line says otherwise.

• pnpm --filter @objectstack/service-settings exec vitest run: 37 files, 638 tests passed. This includes the new settings-global-rung.test.ts (8 cases, a real ObjectQL) and the fixtures re-premised so global rows sit in sys_platform_setting.
• pnpm --filter @objectstack/platform-objects exec vitest run: 65 files, 1036 tests passed. Before the echo-ledger fix, the run had 4 red, all in objects-es-es-echo-decisions.test.ts, for the retired leaf.
• pnpm --filter @objectstack/spec exec vitest run src/system src/migrations src/data/api-methods-batch-conformance.test.ts: 55 files, 1980 tests passed.
• pnpm --filter @objectstack/cli exec vitest run --project integration over the touched files (union, sweep, rewrap, src/commands/secret): 7 files, 91 tests passed. The unit layer: 263 files, 3874 tests passed, at the pre-merge head 1137107352.
• Typecheck green for service-settings, platform-objects, spec and cli, at 1137107352.
• Ablations were one-off, through scripts/ablation-replace.mjs in WRAP mode. Each anchor hit 1 → 0 and the blob changed. Each restore read blob == HEAD with git diff HEAD empty, and git status --porcelain read 0 lines after all four. The subjects are imported by relative source path, so no dist/ is in the resolution path.
  • A, the null-user sys_setting read readmits scope: 'global': red, a global-scope key never consults sys_setting at all.
  • A2, the user-keyed read readmits scope: 'global': red, a scope=global row still in sys_setting is NOT read.
  • D, the global rung read from sys_setting: 7 of 8 red.
  • B, the union reads sys_setting alone: red, names a handle held ONLY by sys_platform_setting.value_enc, an unreadable sys_platform_setting gaps the WHOLE settings family, and the sweep's REFERENCED, never deletable.

Gates

• Derivation. node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at d0477879af derived 125 families. All 125 were run, each exit code captured before any pipe, and all 125 exited 0. --ran reconciles 125 derived, 125 run, 0 NOT-MEASURED, 0 UNRUN.
• What the battery covers. It includes the claim-time list. It adds check:engine-double-contract, check:objectql-double-limit, check:where-matcher, check:i18n-coverage, check:i18n-walk-parity, check:type-check-coverage, check:type-check-debt and check:empty-changeset, which the diff touches.
• The generated-artifact gates are green: check:api-surface ("unchanged"), check:migration-registry, check:spec-changes, check:upgrade-guide, check:platform-object-tenancy-census, check-tenant-audit-census, check:query-options-erasure, check:i18n and check:nul-bytes.
• The merge. main was merged twice, the second time through scripts/pm/os-regen-merge.sh, because PR feat(spec)!: refuse bare unique: true on a declared index at protocol 18 — stated scope, zero-drift conversion (ADR-0120 D2/D5a/D7) #22103 also writes packages/spec/src/migrations/registry.ts. After gen:migration-registry, the regenerated registry is byte-identical to the merge, and it holds both this PR's entry and feat(spec)!: refuse bare unique: true on a declared index at protocol 18 — stated scope, zero-drift conversion (ADR-0120 D2/D5a/D7) #22103's declared-index-bare-unique-true-retired.
• Lint, a proven narrowing. eslint --no-inline-config --format json at d0477879af read 37 results, the 37 changed .ts files: 0 errors and 0 warnings, so none was ignored by the config. eslint.config.mjs enables no type-aware linting (no parserOptions.project, per its own comment), so this diff cannot move the verdict on any untouched file. The full pnpm lint is CI's.

Acceptance notes (observed, not changed here)

• cli/src/commands/secret/orphans.ts, lines 300 to 309, builds the sweep's legacy-inline guard from sys_setting rows only. Today nothing writes legacy inline ciphertext into sys_platform_setting: the plugin always wires LocalCryptoProvider plus the sys_secret store. After C7 moves pre-Phase-3 global rows, though, an inline value could sit there. The guard is withhold-only, and the union, which decides deletion, already reads both holders. Natural carrier: C7 (feat(objectql,cli): inventory + migration — four fates per object, mirrors deleted only after the id→name rewrite is verified, per-table boot report (ADR-0131 D10) #15211).
• metadata-protocol/src/migrations/sys-setting-identity-index.ts: two operator texts on its degraded arms still say global-scope settings rows "can still be created" in sys_setting. No writer creates one after this PR. The text goes fully stale when C7 empties the layer. Carrier: C7 (feat(objectql,cli): inventory + migration — four fates per object, mirrors deleted only after the id→name rewrite is verified, per-table boot report (ADR-0131 D10) #15211).
• packages/spec/src/system/settings-manifest.zod.ts: the module TSDoc says values persist in sys_setting, and its resolution list was already missing the global rung. No .describe() names the store, so it is left untouched per the claim.
• SettingsService.setMany passes tenantId: ctx.tenantId into the CryptoContext on every rung, while materialiseRow decrypts with none. No in-tree provider reads tenantId, so this pulls nothing today. A per-tenant-key KMS provider would seal and open under different keys on every rung.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 4 package(s): @objectstack/cli, @objectstack/platform-objects, @objectstack/service-settings, @objectstack/spec, touching 40 documentable anchor(s). ⚠️ 2 changed file(s) yielded no anchor (packages/platform-objects/src/system/index.ts, packages/services/service-settings/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.

64 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 7d7943dd0dfba6c98afa2200a08983ec85f9849a.

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

What this run could not see

• 2 changed file(s) yielded no anchor (packages/platform-objects/src/system/index.ts, packages/services/service-settings/src/index.ts) — pages documenting those are invisible to this run
• 1 cross-cutting symbol(s) contributed no route anchor: isSystem (5 routes)
• 1 anchor(s) matched too much of the corpus to be a work list: sys_user (literal, 38 pages)
• 11 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 — 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 7d7943dd0dfba6c98afa2200a08983ec85f9849a → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 7d7943dd0dfba6c98afa2200a08983ec85f9849a

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

[objectstack-fleet]

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: d0477879af76f89370d19f7b587917a13510d23a
Local-runs: none

Reviewed at 2026-10-08T03:58Z by an isolated at-tier subagent of the claiming seat (6049595369, revised 6051733303). Read-only: the card and its ten comments, the PR body, its 42-file list, the net diff against main (merge-base ef1fcb26a2, +1338 / -246, equal to the PR's file list), the head's check-runs, ADR-0131 D7 / D10 / D14 / §6 / §8 and ADR-0087 D3 plus the disposition addendum, all on origin/main. Nothing built, run or re-run. The dispatch order and the dispatching seat's ACCEPT were not inputs to the judgments below.

Check-runs on the head, as read at this stamp: 34 runs — 30 success, 2 skipped (Console Pin Gate, which the diff's unchanged .objectui-sha does not trigger, and the opt-in Packed-tarball smoke), 2 in_progress (Lint & Repo Gates, Test Core (1/6)). No run has failed. Green and recorded: Check Changeset, Governed Surface Queue Guard (no governed path in the file list), Spec property liveness, Temporal Conformance (live PG + MySQL), every Dogfood Regression Gate shard and Dogfood Verify CLI (a real kernel booting the real security stack over the settings objects), all four Type Check jobs, Build Core, Test Core shards 2 to 6. The two in-flight runs are the gate verdicts for lint and the repo gates (i18n, censuses, api-surface among them) and the last test shard; landing waits on them per the seat's own hold, and this record does not pre-judge them.

① Derived judgments

1. sys_platform_setting — right. packages/platform-objects/src/system/sys-platform-setting.object.ts declares systemFields: { tenant: false } and requiredPermissions: ['manage_platform_settings'], exactly ADR-0131 D7's shape for deployment-level runtime settings ("a tenant-less object holds only values an operator must change without a restart … governed by object permission, not by the wall"). The column absence is pinned through resolveInjectedSystemColumns (the derivation applySystemFields consumes) with a per-object control that re-adds the column when the opt-out is removed, and sys_setting is pinned as keeping its column. The row identity is (namespace, key) with unique: 'global' spelled explicitly (ADR-0120 D1; both key parts NOT NULL, so the NULL-distinct hole sys_setting needed a runtime index for does not exist here). No scope, no user_id. The value and encryption columns mirror sys_setting's with the same read-only posture (value_enc, updated_by), pinned column by column. managedBy: 'engine-owned', apiMethods: ['get', 'list']: the generic API reads, the settings door writes. The capability it names is platform-scoped in PLATFORM_CAPABILITIES (pinned), so no organization administrator holds it by role — the H5 control row (no gate ⇒ a walled deployment's organization_admin reads every row with no filter) is why the gate ships with the object, as item (1) already established for the seven plumbing objects.
2. Registration and the name — right. settingsObjects is [SysSetting, SysPlatformSetting, SysSettingAudit] (pinned); the service reads both stores on every resolution, so a kernel registering one without the other fails loudly rather than answering with a rung missing. SysPlatformSetting is exported from @objectstack/platform-objects/system; PLATFORM_OBJECTS_BY_PACKAGE gains 'sys_platform_setting' in sorted position (a data constant — the type surface of @objectstack/spec does not move, and check:api-surface is one of the in-flight repo gates). The tenancy census records the object out of reach (83 → 84 registered, 33 → 34 out of reach, systemFields.tenant: false 8 → 9), as the gate binds.
3. The global option of sys_setting.scope retires — right. After this diff no code path writes a global row there: rowIdentity sends a scope: 'global' row to the platform object, and the three consumers of the identity (upsertRow's probe, insert and update; readStoredHandle's re-read; and through them reapRotatedSecret) use the identity's object. The service has no delete verb at all (grep of the head: find, insert, update only). SpecifierScopeSchema is unchanged and must stay: a manifest author still writes scope: 'global', and source: 'global' is still the cascade's resolution value, so there is no authorable key to tombstone and no RETIRED_KEYS_BY_MAJOR row owed — the retirement is of a storage object's select option, declared through the D3 entry. sys_setting_audit.scope keeps global because buildSettingAuditWriter still records entry.scope for a global change; the parity pin is re-premised on both sides (sys_setting.scope = spec enum minus global; the audit object = the full enum, pinned against SpecifierScopeSchema.options rather than a literal), and the es-ES echo ledger drops the retired leaf (47 → 46, pinned). The generated bundles for the four locales drop the leaf and carry the corrected locked help text. The new object's own labels are not in the generated bundles; neither are sys_metadata_activation's nor sys_presence's, the other tenant-less system objects, so the bundle population is not "every system object" — the i18n gates are the in-flight repo-gates verdict.
4. Exported constants — right. CONFIG_CHANGE_GLOBAL_OBJECT_NAME = 'sys_platform_setting' is exported from @objectstack/service-settings beside CONFIG_CHANGE_OBJECT_NAME, and the config_change sink picks by entry.scope === 'global'; both directions are pinned over the plugin's own routes and a real ObjectQL (a global change names the platform object and leaves sys_setting empty; a tenant change names sys_setting and leaves the platform object empty). Without this the ledger would name a table the value is not in. PLATFORM_SETTING_OBJECT stays module-private to the service, unlike the configurable opts.objectName for sys_setting — one store, no second knob; right.
5. The cascade's read and write path — right, and D14 holds. loadRowSets is one loadGlobalRows (find('sys_platform_setting', { where: { namespace } }) under SETTINGS_SYSTEM_CONTEXT, no tenant-audit bypass because the object has no tenant field) plus one loadScopedRows per grouping argument (sys_setting, $or naming the rungs in the query: [{ user_id }, { scope: 'tenant' }] user-keyed, [{ scope: 'tenant' }, { scope: 'user' }] null-keyed), each row tagged with the rung its store says it is (toSettingsRow). There is no fallback read of sys_setting at scope = 'global' and no boot-time move: the exclusion is in the predicate, and ADR-0131 D14's "never a fallback read, never an automatic boot step" is honoured in code and in the service's docblock. The in-memory branch stays one scope-tagged store, which is the engine-less fallback and not a dual read. scopeRank (global = 1), the first-non-null walk, the lock check (finds the global row by its tag) and source: 'global' are untouched. getMany's resolveLocalizationContext reads the same sys_setting namespace three times per request #10826 bound holds: at most two sys_setting finds per call plus one platform find (pinned by object: 2 + 1 for mixed scopes). The write side: a global row is inserted and updated without scope / user_id (the object declares neither) and without the former bypassTenantAudit / as any erasures (the erasure baseline ratchets 2 → 1); assertUserReferenceResolves is skipped only for the platform object, which has no user column. Pinned over a real ObjectQL with the real objects and the real adapter: a global write lands one platform row and no sys_setting row, with a tenant context in the writer and no organization on the row (the stop condition did not fire); the rung resolves from the platform store with source: 'global'; a global lock still refuses a lower-rung write; a global value outranks tenant and user, which answer once it is empty.
6. What an existing database answers before C7 (feat(objectql,cli): inventory + migration — four fates per object, mirrors deleted only after the id→name rewrite is verified, per-table boot report (ADR-0131 D10) #15211) — right. A sys_setting row still at scope = 'global' is not a rung: pinned with a control (the identical row one rung down at scope = 'tenant' IS read by the same query, so the silence is the exclusion and not an empty read), and a global-scope key never consults sys_setting at all. Until the v18 ceremony moves the row, the key answers from its next rung or the manifest default; the v18 boot refusal (D10 point 5) is what keeps a deployment from running in that state, and the card's records hold C6(3) and C7 to one release. The changeset says so to consumers under "Existing databases — nothing moves automatically". The sys_setting identity index keeps covering those rows (its NULL-safe bucket now described as holding tenant/user rows with no organization plus the pre-v18 global rows until the ceremony). The move recipe (same (namespace, key); copy value, value_enc, encrypted, locked, locked_reason, updated_by; remove the source; the platform unique refuses a pre-sys_setting's declared row identity is unenforced on every tenant and global row — user_id is NULL there and SQL UNIQUE is NULL-distinct #8629 duplicate, so the ceremony picks one) is recorded for C7, not built — right, since C7 owns the ceremony.
7. No re-encryption on the move — right. LocalCryptoProvider's AAD binds scope || namespace || key of the producer and neither the holder object nor an organization; pinned by sealing with tenantId: 'org_1' in the context, placing the handle in a platform row, and resolving it. A sys_secret handle copied verbatim opens.
8. The CLI secret-reference union — right, and the H3 hazard is closed in the same diff. SETTINGS_HOLDER_OBJECTS = ['sys_setting', 'sys_platform_setting']; both are read on every run with the fields each holder has; a missing driver or a throwing read on either gaps the whole settings family, which refuses deletion. Pinned: a handle held only by sys_platform_setting.value_enc is enumerated by the union (holder string names the object) and decided referenced, never deletable, by the sweep, with the genuine orphan still deleted as the positive control; an unreadable platform object gaps the family; the rewrap guards and the rewrap fixture register the second holder. Before this, every provider credential at the global rung would have read as unreferenced and been swept in force — this was the one accept-set change that had to ship with the move, and it does.
9. Readers outside the service (H2 census) — accepted. The direct sys_setting readers on main are the union (fixed here) and orphans.ts:300-309 (the sweep's legacy-inline guard, withhold-only; see ③). resolve-authz-context.ts pins scope: 'tenant'; sys-setting-identity-index.ts maintains an index and reads no value; sys-secret-orphan-report.ts is a pure classifier with no in-tree caller (grep: only re-exported from the package index).
10. H1 — nothing moves to configuration — accepted on the dev's census. 109 global-rung keys in seven namespaces, every manifest requiring manage_platform_settings to read and write through the door and so edited live in Setup, with consumers re-reading on subscribe or per sweep; the semantic entry's reason records the census and its commit. That is D7's and §6 Q3's test ("values an operator must change without a restart") applied, with no open_questions entry because no key is boot-read only.
11. Governed surfaces — none. The file list touches no docs/adr/**, .claude/**, skills/**, AGENTS.md or CLAUDE.md; Governed Surface Queue Guard is green. This review is owed by the claim's path limb (packages/spec/src/**) and its Clause-②: yes.

② Semver level

• The changeset matches the diff. .changeset/15207-settings-global-rung-platform-setting.md bumps @objectstack/platform-objects, @objectstack/service-settings, @objectstack/spec and @objectstack/cli at minor, carries the BREAKING banner, and the ADR-0087 marker adr-0087: registered sys-setting-global-rung-moved. .changeset/pre.json is absent on origin/main, so the launch-window convention (triage 6038050559: minor + BREAKING + ADR-0087 disposition until pre mode is in) applies; ADR-0087's addendum keeps the protocol step and the npm level on separate axes, and the D3 entry is what the exemption requires. registered names an id that resolves at the head (the D3 entry in 18.sys-setting-global-rung-moved.ts, mirrored into the regenerated registry.ts with a step-18 rationale fragment at order 87) and is new in the diff — the right category; already-registered or no-migration-prescription would both be false. The body states the FROM → TO mapping for every authored reference (scope = 'global' filters, list-view columns and seeds; kernels registering the settings objects by hand; generic reads of global values needing manage_platform_settings), which is what AGENTS.md asks of a breaking changeset. Check Changeset is green.
• The levels per package are right. platform-objects: a new exported object (widening) and a narrowed select domain (breaking, BREAKING-bannered). service-settings: a new exported constant and a storage move its consumers see only through the documented reads. spec: a new name in a data constant and a new migration entry. cli: the union reads a second holder and gaps on it. None is a patch; none needs major while pre mode is off.
• The Clause-② line. The PR body's line 2 is the claim's Clause-②: yes (widening: …) verbatim, as the claim form requires, with the measured arm declared beneath it; the changeset carries Clause-②: yes (narrowing), which is where check:adr-0087-registration reads the arm (AGENTS.md Post-Task Checklist §3). Per scripts/pm/clause2-line.mjs, yes (narrowing) is the one spelling for "a diff that widens one surface and narrows another; both facts are true and both are read" — and both are true here: it widens (sys_platform_setting, SysPlatformSetting, CONFIG_CHANGE_GLOBAL_OBJECT_NAME, the name in PLATFORM_OBJECTS_BY_PACKAGE) and narrows (sys_setting.scope loses global; the global rung's storage leaves sys_setting). The value agrees across both carriers (yes); the arm differs because the claim predicted and the dev measured, and the measured arm is the one the gate reads. Right.

③ Boundary flags

The report 6051681390 carries no open_questions; its six deviations and five out-of-scope findings are the flags. Each is answered here, none is escalated.

1. Files outside the claim's surface (config-change-audit.ts, index.ts, manifest.ts; the CLI fixtures rewrap.guards.test.ts, sys-secret-rewrap.test.ts, sys-secret-orphan-sweep.test.ts; the four translation bundles, the es-ES hash ledger and echo-decisions test; tenant-audit-census.mdx and the audit counts; the tenancy census; the erasure baseline) — answered. The seat's revision 6051733303 amended the claim with each. Every one is a consequence the diff cannot land without: the object's registration, the ledger naming the store a value changed in, the generated fallout of a retired option, and three gate-bound counts (the tenant-audit census moved because the as any spread of bypass is gone: 171 → 173 threading a tenant context, 54 → 52 unreadable). No scope expansion.
2. orphans.ts:300-309 left unedited — answered, carrier C7. That read builds the sweep's legacy-inline withhold guard from sys_setting alone. Today nothing writes inline ciphertext into sys_platform_setting (the plugin always wires LocalCryptoProvider with the sys_secret store, so a new global row holds a handle or nothing); only C7's move of a pre-Phase-3 global row could put inline ciphertext there. The guard only withholds; the decision to delete is the union's, which now reads both holders and is pinned to do so. The seat's revision records the pointer 6051723395 on feat(objectql,cli): inventory + migration — four fates per object, mirrors deleted only after the id→name rewrite is verified, per-table boot report (ADR-0131 D10) #15211 with the move recipe. Leaving it is the narrower, correct cut; the hazard the file could carry does not exist before the ceremony that would create it.
3. The changeset's arm yes (narrowing) against the claim's yes (widening …) — answered in ②. Measured, both arms are true, and the changeset is where the gate reads it.
4. The falsified Zone 3 pin ("a tenant and a user value still override it") — answered; the dispatch was wrong and the PR is right. scopeRank gives global rank 1 (head line 820) and resolveKeyFromRows takes the first non-null rung, so a global value outranks tenant and user before and after this diff. The committed pin asserts the order the rulings keep: global from the new store outranks both; tenant then user answer once it is empty. A pin asserting the dispatch's sentence would have been red against unchanged behaviour. The seat already owns the correction in 6051733303.
5. The 403 matrix measured by a scratch harness, not committed — answered, carried by precedent; not a blocker. What is committed: the gate declared on the object and its capability's platform scope (pinned); the row placement and the door's 200 over the plugin's own routes and a real ObjectQL (settings-admission-tenancy-posture, config-change-audit); the system-context opt-in on every platform-object verb (settings-system-context.pin). What is not committed: the admit / PERMISSION_DENIED table per posture, which would need plugin-security's middleware and shipped sets — outside this claim's surface, exactly as item (1) landed its seven objects (6043540291 Decision 2, PASS 6045154038). The D3 entry's acceptanceCriteria asserts the 403; the dogfood gates on this head, green, boot the real security stack over these objects, and the H5 reading is recorded in the PR body. If the seat wants the matrix held by CI, that is a plugin-security pin card to file, not a change to this diff.
6. The CryptoContext.tenantId asymmetry (encrypt passes ctx.tenantId on every rung; materialiseRow decrypts with none) — answered; an acceptance note, no reach. Pre-existing on every rung, not introduced here. The only in-tree provider binds no tenant into the AAD (H4, pinned by the sealed-with-org_1, opened-from-the-platform-row case), so it pulls nothing today, and C7's verbatim copy of value_enc is safe for the shipped provider. A per-tenant-key KMS provider would have to resolve the asymmetry before it could seal and open the same row — that is a design question for whoever adds such a provider, filed by them, not a defect in this diff.
7. The sys-setting-identity-index.ts operator texts ("global-scope settings rows can still be created") and the settings-manifest.zod.ts module TSDoc — answered, carrier C7 / none. The texts go fully stale when C7 empties the layer; no .describe() names the store, so the TSDoc stays per the claim. Neither changes behaviour.
8. The user-scoped key resolved with no userId reads every user's rows — pre-existing, read not measured, not in this diff's reach; the seat filed finding(service-settings): a user-scoped settings key resolved with no userId answers with whichever user row the namespace load returns first — measure who reaches it #22168 under the leak exception. Right disposition.
9. The stray /build1.pid at the container's filesystem root and the commit-trailer spelling — container hygiene and a trailer form, neither in the repository nor in the diff; noted, no review consequence.

Implemented-by: claude/issue-15207-platform-setting-global-rung
Reviewed-by: session_01LAi5BVvQNiYzepSAcsoFLK

VERDICT: PASS

The move is one source per rung with the exclusion in the predicate (D7, D14), the accept-set changes it implies are each pinned over real objects and a real engine, the one deletion hazard it created (the sweep) is closed in the same diff, the changeset's grade, marker and arm match what the diff publishes, and the stored-row move is correctly left to C7 behind the v18 boot refusal. Landing stays held on the seat's own conditions: the four in-flight runs completing green.

---

Generated by Claude Code

[objectstack-fleet]

Regen-provenance: 6051891742 · d047787 → 92f3370 · comm -23 <(git diff --name-only d0477879af 92f33709c8 | sort) <(git diff --name-only ef1fcb26a2 7ef50a4fbb | sort) minus the regenerated outputs → (empty)

domain:spec seat 1 (#6017) · os-litant · session session_01LAi5BVvQNiYzepSAcsoFLK · 2026-10-08T04:24Z. A pointer, not evidence: the queue guard re-runs the test on the committed trees.

• 92f33709c8 is one merge commit with parents d0477879af (the head contract review PASS 6051891742 judged) and 7ef50a4fbb (origin/main). It was made by os-regen-merge.sh.
• The regeneration chain (gen:migration-registry, gen:spec-changes, gen:upgrade-guide, then check:generated against a freshly built dist) wrote zero bytes on the committed merge, so there is no regeneration commit. The dev's report is 6052173703 on feat(spec,services): deployment-level state has no organization column — settings global rung, plumbing objects, the audit ledger, #12699 made total (ADR-0131 D7) #15207.
• Re-run by this seat: the files that differ between the two heads, minus those main changed (ef1fcb26a2..7ef50a4fbb), minus the regenerated outputs, are empty. The PR's net diff is unchanged: 42 files, +1338 / −246. 41 of them are blob-equal across the hop; registry.ts also carries main's two new step-18 entries.
• The rationale fragment at order 87 ties with main's flow-script-subflow-config-undeclared-keys-refused and renders after it in id order. Ties are documented and already exist at nine other orders, so it is not renumbered.
• Since 7ef50a4fbb, main gained four commits that touch no generated path.

[objectstack-fleet]

Regen-provenance: 6051891742 · 92f3370 → c3f5925 · comm -23 <(git diff --name-only 92f33709c8 c3f59255c5 | sort) <(git diff --name-only 7ef50a4fbb 6ed0c0f3e5 | sort) → (empty)

domain:spec seat 1 (#6017) · os-litant · session session_01LAi5BVvQNiYzepSAcsoFLK · 2026-10-08T05:40Z. The second hop on the same record. A pointer, not evidence: the queue guard re-runs the test.

• The hop: 61edbced61 merges origin/main 6ed0c0f3e5 into 92f33709c8, made by os-regen-merge.sh. c3f59255c5 is node scripts/tenant-audit-census.mjs --write on the merged tree. The dev's report is 6053162737 on feat(spec,services): deployment-level state has no organization column — settings global rung, plumbing objects, the audit ledger, #12699 made total (ADR-0131 D7) #15207.
• Re-run by this seat: the files that differ across the hop, minus those main changed (7ef50a4fbb..6ed0c0f3e5), are empty, before any regenerated output is subtracted. The PR's net diff is unchanged: 42 files, +1338 / −246.
• ⚠️ One hand edit, read by this seat and judged to carry the PASS: content/docs/permissions/tenant-audit-census.mdx :125, "54 of the 232 sites" became "52 of the 232 sites". The census gate refused 54 and computes 52. That is the same −2 this PR carried at 92f33709c8 (two settings-service sites became readable), restated on main's new total of 232. It is gate-bound documentation prose outside --write's region. It is not a contract-review face (content/docs/** is excluded there), and it moves no accept set, export or behaviour.
• The other figures on the page, read sentence by sentence: "60 sites … 8 said so and 52 were simply unread" (:153–:154), the table rows 172 / 52, and the measured-at line. Each is the census's output on the merged tree, and check-tenant-audit-census holds all 23 prose figures.
• The four translation bundles main also touched: the PR's own delta in each is byte-identical across the hop.

[objectstack-fleet]

Regen-provenance: 6051891742 · c3f5925 → 2d4170f · comm -23 <(git diff --name-only c3f59255c5 2d4170f619 | sort) <(git diff --name-only 6ed0c0f3e5 7d7943dd0d | sort) → (empty)

domain:spec seat 1 (#6017) · os-litant · session session_01LAi5BVvQNiYzepSAcsoFLK · 2026-10-08T06:29Z. The third hop on the same record. A pointer, not evidence: the queue guard re-runs the test. The merge queue removed this PR at 06:16Z (MERGE_CONFLICT): 7d7943dd0d had moved the tenant-audit census again.

• The hop:
  • 0328884e56 merges origin/main 7d7943dd0d into c3f59255c5, made by os-regen-merge.sh. The two census files took main's side.
  • 2d4170f619 is node scripts/tenant-audit-census.mjs --write on the merged tree.
  • The other regenerators wrote nothing.
  • The dev's report is 6053846190 on feat(spec,services): deployment-level state has no organization column — settings global rung, plumbing objects, the audit ledger, #12699 made total (ADR-0131 D7) #15207.
• Re-run by this seat:
  • The files that differ across the hop, minus the files main changed (6ed0c0f3e5..7d7943dd0d), are empty, before any regenerated output is subtracted.
  • The PR's net diff is unchanged: 42 files, +1338 / −246.
  • 40 of the 42 have the same blob before and after the hop. The other 2 are the census page and docs/audits/2026-08-tenant-audit-write-call-sites.counts.md.
• ⚠️ One hand edit, the same shape as the second hop, read by this seat and judged to carry the PASS:
  • Where: content/docs/permissions/tenant-audit-census.mdx :125.
  • The change: "54 of the 234 sites" became "52 of the 234 sites".
  • Why: the census gate refused 54 and computes 52. That is the PR's −2 (two settings-service sites became readable), restated on main's new total of 234.
  • Why it carries: it is gate-bound documentation prose outside --write's region. It is not a contract-review face (content/docs/** is excluded). It moves no accept set, export or behaviour.
• The rest of the page's diff across the hop is --write's own output: "threading a tenant context" 172 → 174, sources scanned 615 → 617, declared objects 116 → 117, and the measured-at line. check-tenant-audit-census holds all 23 prose figures on the new head (the dev's run; CI re-runs it).
• git merge-tree origin/main 2d4170f619 is clean.