[objectstack-fleet]

Requested by Leehom · project thread

Fixes #26603

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么: 设置审计表 sys_setting_audit 与平台孪生表 sys_platform_setting_audit 的 old_hash / new_hash 字段说明（TSDoc 与 description），改为同时写明两种摘要格式；四个语言的翻译包随之更新。只改说明文字。
• 为什么改: 原说明写「SHA-256」，但机密值的行实际写的是带密钥的 hmac-sha256: 摘要。按说明核对审计行的运维或 AI 会把每条机密行判成格式错误，甚至拿机密的 SHA-256 去比对，这正是带密钥摘要要防的离线猜测。
• 风险与回滚: 极低。不改写入内容、列类型、长度或列名，不碰 packages/services/**；回滚即还原本 PR。
• 先看: ① packages/platform-objects/src/system/sys-setting-audit.object.ts（两段说明）；② sys-platform-setting-audit.object.ts（孪生表对齐）；③ zh-CN.objects.generated.ts 的两条重译。
• 两分钟验证: git grep -n "SHA-256 of the previous value" -- packages/platform-objects 应无输出；pnpm check:i18n 应打印 all bundles in sync。
• 需要你做的: 无，席位落地。

What changes

• sys_setting_audit (packages/platform-objects/src/system/sys-setting-audit.object.ts): the old_hash / new_hash TSDoc and description now state both formats the settings audit writer records:
  • a non-secret value: sha256: + hex SHA-256 of its canonical JSON (settingAuditDigest);
  • a secret value (encrypted: true): the crypto provider's keyed digest, hmac-sha256:…, never an unkeyed hash;
  • null as before (unset for old_hash, reset for new_hash), and null for a secret when no keyed digest is available;
  • the TSDoc adds that rows written before the sha256: digest may carry fnv32:, and that only same-prefix values compare.
• sys_platform_setting_audit (the global rung, same writer and row shape): the same two descriptions, plus TSDoc that points at the tenant table's format text.
• Translation bundles: pnpm i18n:extract (the generator the config's docstring and the root package.json name) refreshed the en leaves. The zh-CN, ja-JP and es-ES leaves were re-translated in place (see Acceptance notes); a second pnpm i18n:extract leaves every bundle file, the source-hash tables included, byte-unchanged.
• Changeset: @objectstack/platform-objects patch.

Description text only: no column type, length or name changes, and nothing about what is written.

Why

A secret row's new_hash has been the keyed digest since the keyed-digest work, and its old_hash is too since #26534 (PR #26600). The column metadata still said SHA-256. /meta serves these descriptions to Studio and agents, so a reader who checks a row against them is told a format secret rows never carry.

Tests

• pnpm --filter @objectstack/platform-objects test: Test Files 96 passed (96), Tests 1361 passed (1361), lock VERDICT command-exit 0.
• pnpm --filter @objectstack/platform-objects typecheck: VERDICT command-exit 0, check:test-typecheck: OK.
• eslint packages/platform-objects --no-inline-config: exit 0.
• No behaviour moved, so no new test and no ablation: the change is field description text and its translations.

Acceptance notes

• Non-English leaves. os i18n extract --merge only fills gaps, so it kept the zh-CN, ja-JP and es-ES translations of the old "SHA-256 of the … value" wording. They had no entry in the generated *.source-hashes.generated.ts tables (a translation, not a byte copy of the source), so they are legacy-trusted: measured after the regenerate and before the re-translation, pnpm check:i18n and pnpm check:i18n-coverage both exited 0 while the three locales still served the SHA-256 text. No gate catches it. The bundle headers state the repo's rule for this case ("Re-translate it by hand when its source changes"; "Re-translate the leaf in the objects bundle and the next extract drops its entry by itself"), so the six leaves (old_hash.help, new_hash.help × three locales) were re-translated in place, leaf values only, and the second extract confirmed the structure is untouched.
• sys_platform_setting_audit has no bundle entry. The platform-objects extract config does not list that object, so its descriptions ship in English only. That was already true before this change, and it is not touched here.
• Other prose that still says SHA-256 (not edited, outside this card's file surface): packages/services/service-settings/src/crypto-adapter.ts:22 and settings-audit-old-hash.test.ts:8-9 describe the declaration as SHA-256, and the pending .changeset/26465-settings-audit-old-hash.md does too. Each speaks of the non-secret digest, which is still SHA-256, so none is wrong; packages/services/** is outside this card's ruling.

Verification

All readings at head a32e5507.

• Derived gate families: node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 53 commands; each was run with its exit code captured before any pipe, and --ran reconciles "53 derived, 53 run, 0 NOT-MEASURED, 0 UNRUN". 52 exited 0 on the first pass. check-plugin-teardown-shape.mjs --self-test exited 3 (shallow clone: it could not read its pinned positive control 621a4876); after git fetch origin 621a4876… it exited 0 ("48 cases pass").
• i18n: pnpm check:i18n "OK (10 package(s), all bundles in sync, no undeclared authoring keys)"; pnpm check:i18n-stale-fill "OK (11 bundle set(s), no new stale fills, 0 baselined)"; pnpm check:i18n-coverage "OK (14 config(s), 527 baselined untranslated string(s), none new)".
• Declaration lines: node scripts/check-changeset-no-major.mjs --base origin/main --event (this body as the event) reads Clause-②: no and Metadata-protocol: none, "a non-protocol change at patch", and "moves no metadata-protocol baseline".
• Acceptance grep: git grep -n "SHA-256 of the previous value" -- packages/platform-objects exits 1 (no match).
• Full build (pnpm build, 116 tasks) under the verify lock: VERDICT command-exit 0.

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic.
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint passes.
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset.
• 6. packages/spec touched: its generated artifacts are regenerated and committed. (Not touched.)
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English.
• The Before Submitting list in CONTRIBUTING.md is done.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FEkQ5mfZPv35uwM4wiMZZt

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/platform-objects, touching 3 documentable anchor(s).

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

• content/docs/permissions/system-context.mdx (via sys_setting_audit (symbol, a field of const object enObjects; a field of const object esESObjects; a field of const object jaJPObjects; a field of const object zhCNObjects))

What this run could not see

• the SDK route bridge reached 55 of 207 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 — 3 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 dbf7e04adff66aba72e634c65aae754440a8d89d → packageMentionDocs.

Which tree this was computed on

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

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

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

[objectstack-fleet]

席位核对

ACCEPT · domain:server seat 2 · os-project-manager · session_0186vfjHHMsRXC9EUT9hTFMo · 2026-10-27T11:56Z · head a32e5507 · #26603

The maintainer's standing authorisation for landing reviewed PRs, verbatim: 「按照 pm-dispatch 规则复核过的都授权」.

1. Shape: a draft against main, assignee os-project-manager. The body carries Fixes #26603, Clause-②: no and Metadata-protocol: none, all line-initial; the dev reports check-changeset-no-major accepts them. The changeset is an @objectstack/platform-objects patch. check-governed-merges --pr 26652 reads NOT governed, 65 changed lines. A field description is not an accepted or emitted value, so no at-tier review is owed. The card's newest claim (6440230671) names this PR's branch.

2. Diff against the ruling (the seat read the whole diff): only old_hash / new_hash TSDoc and description change, on both objects.

   • Each states both formats: sha256: hex for a plain value, and the provider's keyed hmac-sha256: for a secret, never unkeyed.
   • Each states both null cases, including a secret with no keyed digest.
   • The TSDoc carries the fnv32: history note.

   No column type, length or name changes, and nothing under packages/services/**. The acceptance grep for "SHA-256 of the previous value" now finds nothing in packages/platform-objects.

3. Translations: en was regenerated by the generator. The generator does not refresh a leaf that already holds a translation, so the zh-CN, ja-JP and es-ES leaves kept the stale "SHA-256" text with every gate green. The bundle header's own rule is: "Re-translate it by hand when its source changes … only the leaf string values." The dev followed it: six leaf values re-translated in place, structure untouched, and a second extract byte-identical. That is the repo rule the order deferred to, so it is accepted.

4. Overlap: none. No other open PR touches the two object files or the four bundles (seat's read at this stamp).

5. Gates: at this stamp every check-run on the head reads success or skipped; none reads failed or in progress. Locally the dev reports:

   • 53 of 53 derived gates run and exit 0, with 0 not measured;
   • platform-objects 1,361 / 1,361, typecheck and lint 0;
   • check:i18n, i18n coverage and stale-fill all 0.

6. Out of scope: none found.

---

Generated by Claude Code