fix(service-settings): the settings audit trail records secret-valued settings with the keyed digest

[objectstack-fleet]

Fixes #21792

Clause-②: no

What changes

The settings audit trail now records secret-valued settings (encrypted keys) with the platform's keyed digest (ICryptoProvider.keyedDigest), never the unkeyed digest. This follows the maintainer ruling recorded on the card. Non-secret settings are unchanged.

• packages/services/service-settings/src/settings-service.ts: one private helper, secretAuditDigest, supplies the fingerprint for a secret-valued write on both write branches (the sys_secret path and the legacy inline-adapter path). Both ledgers take it: the sys_audit_log config_change row (valueDigest, now spelled with an hmac-sha256: digest inside the existing encrypted marker) and the sys_setting_audit row (newHash).
• No keyed digest available. This happens when no crypto provider is wired (a host that builds the service with only a CryptoAdapter) or when the provider refuses. The rows then record the write with no fingerprint: valueDigest is the bare encrypted marker and newHash is null. A warn is logged once per key. The write itself is never refused, matching the existing rule that a ledger never fails a settings save. The unkeyed digest is never used as a fallback.
• packages/spec/src/contracts/crypto-provider.ts: the contract text is revised as the ruling asks. digest is the audit fingerprint of non-secret values only. keyedDigest requirement 3 now says a secret's audit fingerprint comes from it and never from digest, and that with no keyed digest the trail records none. Comment-only: no type, export or schema change.
• Changeset: @objectstack/service-settings patch and @objectstack/spec patch (the doc text ships in the .d.ts).

Consumers that compare these digests

No non-test code reads or compares valueDigest / new_hash / old_hash: git grep over packages/** returned only the writers, the object definition and comments. Equal-value detection still works for a reader, because the keyed digest is stable for equal input under one key. Three existing tests pinned the old unkeyed spelling for a secret. They were updated, not deleted: two now expect the keyed shape, and one (the legacy adapter, no provider) now expects no fingerprint.

Tests (at f34f69594c; test code is unchanged since fc5c86e1c6)

• New settings-audit-secret-digest.test.ts (7 cases). For a secret, both ledgers carry provider.keyedDigest(value), which is neither provider.digest(value) nor the plain SHA-256 of the value. The fingerprint is stable for equal values and distinct for different ones. A reset records null. The legacy branch with a provider records the keyed digest. The legacy branch with no provider records no fingerprint, warns once, and the write still lands. A provider that refuses still lets the write land. For a non-secret value, both ledgers keep the adapter digest of the canonical JSON, unchanged.
• pnpm --filter @objectstack/service-settings test: 34 files, 612 tests passed. typecheck (tsc --noEmit, include: ["src"], so it covers the tests) passed.
• Ablation, two legs, done with scripts/ablation-replace.mjs. The tests import src, so no dist rebuild was involved. Leg 1 put back the unkeyed digest on the sys_secret branch: 2 of 7 failed (the keyed-digest case and the refusing-provider case). Leg 2 put back the adapter digest on the legacy branch: 2 of 7 failed (both legacy cases). Each leg restored to the HEAD blob (a148f503e350) with git diff HEAD empty.
• Derived gate families (dispatch-gates.mjs --commands, 87): 85 exit 0. check:dual-build-cjs-loads exited 3 (PREREQUISITE NOT MET: it needs a whole-repo build). check:type-check-debt was killed twice by the foreground cap. Both are NOT MEASURED and left to CI. --ran reconciliation: 87 accounted, 0 unrun.
• Lint, narrowed to the 5 touched .ts files: eslint --no-inline-config --format json reported 5 files, 0 errors, 0 warnings. The config's TS block matches **/*.{ts,…}, and type-aware linting is not enabled (no parserOptions.project), so this diff cannot change any verdict on an untouched file.

Acceptance notes

• Optional oldHash (not done). The sys_setting_audit writer still hard-codes oldHash: null. Recording the previous fingerprint of a secret would mean decrypting the prior ciphertext on every write, so it is not the small rider the dispatch allowed. It is left for a follow-up.
• The sys_setting_audit object's old_hash / new_hash field descriptions in platform-objects still say "SHA-256 of the … value". That was already inexact for the default adapter, and it is outside this card's file surface. Carrier: none named.
• Audit rows written before this release keep their old fingerprint. Rotating the data key changes every later secret fingerprint.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/service-settings, @objectstack/spec, touching 5 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/services/service-settings/src/sys-secret-orphan-report.ts), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

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

• content/docs/data-modeling/drivers.mdx (via SettingsService (symbol, a top-level class))
• content/docs/data-modeling/external-datasources.mdx (via ICryptoProvider (symbol, a top-level interface))
• content/docs/data-modeling/validation-rules.mdx (via ICryptoProvider (symbol, a top-level interface))
• content/docs/kernel/runtime-services/settings-service.mdx (via setMany (symbol, a method of class SettingsService))
• content/docs/protocol/kernel/config-resolution.mdx (via ICryptoProvider (symbol, a top-level interface), SettingsService (symbol, a top-level class), setMany (symbol, a method of class SettingsService))
• content/docs/protocol/kernel/index.mdx (via SettingsService (symbol, a top-level class))

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

• content/docs/releases/implementation-status.mdx (via ICryptoProvider (symbol, a top-level interface))
• content/docs/releases/v14.mdx (via setMany (symbol, a method of class SettingsService))

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

What this run could not see

• 1 changed file(s) yielded no anchor (packages/services/service-settings/src/sys-secret-orphan-report.ts) — pages documenting those are invisible to this run
• 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 — 140 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 75ddcd1b41e74823b7bb9f3fe9e159a189fa2a91 → packageMentionDocs.

Which tree this was computed on

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

node scripts/docs-audit/affected-docs.mjs --json 75ddcd1b41e74823b7bb9f3fe9e159a189fa2a91

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