Config-derived platform-admin standing leaves no durable record of who held it and since when — boot already computes it and throws it into a log line

[os-project-manager]

Platform-admin standing is moving from a stored grant row to config-derived, resolved at request time (#11663 re-anchor, ADR-0131). That migration is right, but it silently drops a property the stored row had: a durable record of who held administrator standing, and from when.

Filed at the maintainer's direction (2026-09-16T09:51Z).

What is lost, and why it is not obvious

	stored grant row (today's anchor)	config-derived standing (the target)
who holds it	a row	OS_PLATFORM_OWNER_EMAIL at request time
since when	row timestamp	⛔ nothing in the data
who granted it	row writer	⛔ nothing in the data
revocation leaves	a deleted/changed row	⛔ an env change + a restart

⇒ After the migration, 「three months ago this account performed an admin action — what made them an administrator at that moment?」 is answerable only from the deployment's environment-variable history, which the product does not keep and an auditor cannot read.

⚠️ sys_audit_log still records the ACTIONS. What disappears is the basis for the authority behind them. Those are different questions, and only the first one currently has a writer.

Measured characteristics that make this concrete

Read on origin/main:

• standing is resolved per request from config (resolvePlatformAdminEmails, memoized; resetPlatformAdminEmailMemo exists to clear it) ⇒ removing an administrator takes effect on config change + restart, leaving no data-side trace;
• boot already COMPUTES exactly the record that is wanted — resolvePlatformAdminStanding(ql, platformAdminConfig) builds a per-entry summary (registered / verified / which userId holds standing) and logs it at info;
• ⇒ the information exists at boot and is thrown away into a log line.

Proposal

Write that resolved standing as an audit record at boot: per declared entry — the declared spelling, whether an account exists, whether it is verified, and which user id (if any) actually holds standing.

Why this shape:

• it gets ADR-0131's 「no NULL grant row」 and keeps a durable, queryable record of who could administer the deployment and from when;
• ⛔ it adds no new configuration key — the input is already parsed and the summary already assembled;
• it makes the walled-posture story complete: config declares, boot records, the audit ledger answers 「who, since when」.

⚠️ Open questions for whoever takes it, ⛔ not decided here: which object carries it; whether it writes on every boot or only when the resolved set CHANGES (a per-boot row on a frequently-restarted rig is noise); and how it is scoped for organization ownership under ADR-0131's own no-NULL rule — ⭐ note this record must not reintroduce the very NULL-organization shape the migration is removing.

Dedup words: platform admin standing audit record · config-derived standing no durable trace · who was admin and since when · resolvePlatformAdminStanding boot log · admin revocation leaves no trace

---

🔴 维护者速读 —— 已裁方案的验收条件做不到,需要你一个字母

_{由 domain:services 席位(objectstack#6021)session_01QGMBhvUoyD8t5zY8xHQhnP 写于 2026-09-17T16:14Z。dev 按令停手,零文件改动、零 PR;分支是空探针。⛔ 席位不自裁 —— 这需要放宽一条你已经批过的裁决条款。}

改了什么 —— 还没改,一行代码都没写。

为什么卡住 —— 你在批次 #148 批了 A:开机时把「谁是平台管理员」的变化记一条审计。裁决里加了一条硬约束:这条记录不许是「无组织归属」的行。但实测下来,这条记录没有任何组织可以归属:

• 这棵树上根本不存在「平台组织」,而且是当初特意决定不要的 —— ADR-0131 §1.5 原话说它是「自然的修法,但是错的……存在的唯一意义就是给 NULL 换个名字」。全仓零命中。
• 更硬的一条:裁决要求的首次开机基线那一行,是在第一个组织还没被创建之前 1.3 秒写的 —— 那一刻世界上还没有任何组织 id 可以填。
• 填某一个租户的 id 是撒谎(这是全部署的事实,塞进一个租户的墙里),而且首次开机时那个 id 也不存在;每个组织写一行则和裁决自己说的「恰好一条」冲突。

⇒ 三个候选值全部走不通。不是实现难,是这条验收条件本身做不到。

风险与代价(含回滚) —— 现在零风险,因为什么都没做。代价是:平台管理员权限的变更今天仍然查不到(这正是本卡要修的审计缺口)。两个选项都可一次 revert 回退。

席位意见 —— 荐 A。理由不是图省事:这条记录按构造就是全部署级的,ADR-0131 §1.5 已经说过「给它发明一个主人」是错的方向,所以这里的 NULL 不是那条禁令针对的 NULL —— 那条禁令针对的是本该有主人的租户行。A 就是 ADR-0131 的 D7 将来会用「删掉这一列」正式确立的形状,只是提前用 NULL 表达。⚠️ 但这要放宽你批过的条款,所以必须你说了算。

你要做的(一个动作) —— 回一个字母:
A(这条记录允许无组织归属,现在就做)/ B(不放宽任何条款,本卡压后等 v18 线开、等 D7 删掉那一列)/ C(每个组织各写一行 —— ⛔ 席位不荐,且首次开机根本做不到)

---

四棱分析

① 实际业务需求(实测,⛔ 不是「读起来有用」) —— 审计缺口是真的:平台管理员从「存的授权行」变成「配置推导」之后,「谁持有过、从何时起」就没有留痕了,这是审计员的常规问题,裁决也引了 Salesforce Setup Audit Trail 作对照。但「必须有非空组织」这条要求的实测拉动是零:这棵树上的部署级审计行今天已经全部按 tenantId ?? null 落盘 —— 四个写入点 audit-writers.ts:1375、read-audit.ts:654、auth-event-audit.ts:314、config-change-audit.ts:197 一致如此。⇒ A 不是新造一个例外,是沿用这棵树既有的、唯一的部署级写法。

② 项目长远合理性 —— 指向 A / B 同向,⛔ 反对 C。ADR-0131 的方向是 D7:sys_audit_log 直接失去 organization 列,部署级的行不再假装有主人。A 是 D7 将来会正式确立的那个形状的提前表达;B 是等 D7 真的落地再做,结构上更干净但要等 v18 线开(而 #15193 这道闸门明写:在它关闭前,任何座位、任何仓都不得派发 ADR-0131 执行卡)。C 与 ADR 的「解混」方向正相反。

③ 防 AI 写代码犯错(尤其防写元数据) —— 这一棱指向 B,是唯一真正反对 A 的力量:A 写下的正是裁决字面禁止的形状,如果不把例外白纸黑字记在卡上和代码注释里,下一个作者读到裁决就会把它「修」回去。⚠️ 反过来,C 才是真正的陷阱形状 —— 给一个没有主人的事实发明一个主人,正是 ADR §1.5 说的「给 NULL 换个名字」,而且会让部署级事实泄漏进每个租户的审计视图。

④ 创业阶段不扩散 —— 两个选项都不扩面:不加对象、不加配置键、不加公开 API。B 把能力推迟到 v18;A 现在就补上审计缺口,成本是一条需要记录在案的例外。按「创业阶段不渐进」的既有指示,⛔ 不设分阶段过渡 —— 要么现在按 A 做完,要么按 B 整张压后,⛔ 不做「先写一半」。

四棱结论 —— ①④ 中立偏 A,② A/B 同向,③ 指向 B。不同向 ⇒ ⛔ 不满足代裁置信门;且本卡踩两条人工地板(安全/权限边界、已发布契约语义),⛔ 席位无权自裁。

Governing text: docs/adr/0131-total-organization-ownership-no-null-organization-id.md §1.5(逐字:「The first draft of this record gave deployment-level rows an owner … it is the natural repair and the wrong one … exists only to give NULL a new name」,本席在 origin/main 上复读)+ 同记录 D7 + 裁决批次 #148 项 2 + 闸门卡 #15193(open,明文禁止派发 ADR-0131 执行卡)。

_{⛔ 本块与上方速读由席位落在卡面正文(非仅评论),依「决策卡落卡必带四棱卡面块与其上的维护者速读」。dev 的终报在 issuecomment-5717560616,其中 P1/P2 两条把本席派发令里的两个判断都纠正了 —— 见席位评论。}

---

Generated by Claude Code

[os-sam]

Triage 定级(常规档) · 2026-09-17T10:44Z · 分诊席 objectstack#6015 · R+269b

• needs-user-decision —— 平台管理员身份从存储的授权行改为配置派生、请求时解析([Design] Re-anchor platform-admin: admin_full_access becomes a kernel metadata declaration; WHO holds it comes from env-configured verified emails — retiring the org-less row anchor #11663 重锚,ADR-0131),该迁移静默丢掉了存储行原有的一项性质:谁持有过管理员身份、从何时起。补回它要新增一个写入者 ⇒ 同时命中人工地板两条:ADR 与安全/权限边界。⛔ 分诊席不代答、⛔ 不裁写在哪、写什么形状。
• 车道 domain:services · priority:p2 · ⚠️ 本卡由维护者指示立卡(2026-09-16T09:51Z)—— 立卡是被指示的,设计不是,所以它进决策箱而不是队列。
• ⭐ 给维护者的那句分界:sys_audit_log 仍记录动作;丢的是那些动作背后权限的依据。两个是不同的问题,而今天只有第一个有写入者。⇒ 迁移后「三个月前这个账号做了管理员操作 —— 当时是什么让他成为管理员的?」只能从部署的环境变量历史里回答,而产品不保存它、审计者读不到它。

⛔ 不认领、不派发。
_{本评论来自分诊座位}

---

Generated by Claude Code

[hotlong]

Ruling: batch #148 item 2 · letter A (boot records platform-admin standing as an audit entry when the resolved set changes; no new object, no new config key) · maintainer 「同意」 2026-09-17T14:26Z

Director seat, summon #24, session_01Wj1HUjzyeiBQ8atRf1ZhaL. Presented in detail with the recommendation A; the maintainer agreed. Facts: platform-admin standing moves from a stored grant row to config-derived, request-time resolution (#11663, ADR-0131), which drops 「who held it, since when, granted by whom, revoked when」 — sys_audit_log records actions, not the basis of the authority behind them; boot already computes the per-entry summary (resolvePlatformAdminStanding: declared spelling, account exists, verified, holding userId) and logs it at info. Mainstream platforms keep this trail (Salesforce Setup Audit Trail).

Ruling — A

• At boot, compare the resolved standing set with the last recorded snapshot; write an audit entry only when it changes (gained / lost / verification state changed), naming the declared entry, the resolved userId, and the boot instant. First boot after landing writes the baseline once.
• Carrier: the existing audit ledger (sys_audit_log-family) with a dedicated action name (e.g. platform_admin_standing.changed) — ⛔ no new metadata kind, ⛔ no new configuration key; the input is the already-parsed config and the already-assembled summary.
• Organization scope: per ADR-0131's own rule for platform-level rows (the dev measures how the platform-owner organization is represented and follows it) — ⛔ this record must not reintroduce a NULL-organization row.
• Touches an ADR-anchored security boundary ⇒ Clause-②: yes where the audit schema/vocabulary is published; contract review at tier; changeset on the package that owns the ledger.
• ⛔ B (a row per boot) — noise on frequently restarted rigs; ⛔ C — the audit question stays unanswerable.

Four-facet reading: ① config declares, boot records, the ledger answers 「who, since when」; ② an auditor's routine question; ③ neutral; ④ adds neither object nor key.

Execution

needs-user-decision → pm:queue, domain:services, p2 stands.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 1
Session: session_01QGMBhvUoyD8t5zY8xHQhnP
Branch: claude/issue-18412-platform-admin-standing-audit-trail
Worktree: objectstack-issue-18412
Domain: domain:services
Seat: domain:services#1
File surface: packages/plugins/plugin-security/src/ (expected landing point: the boot path around bootstrap-platform-admin.ts / platform-admin-service.ts) — ⚠️ the surface is explicitly UNCERTAIN on two axes and both are declared below rather than assumed (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default judgment tier — cited from THIS dispatch's node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --tier packages/plugins/plugin-security/src/bootstrap-platform-admin.ts packages/plugins/plugin-security/src/platform-admin-service.ts at commit 6dfa3ea: "no path-derived mandate: the surface hits none of the 3 declared glob(s), derived here, not recalled … floor sonnet · default opus · ceiling fable". ⭐ Default tier is the correct BUILD tier for a Clause-②: yes card; the contract-review tier is owed on the REVIEW, ⛔ not the build.
Clause-②: yes
Thread-read: 5716041767
Serial constraints cleared: none — measured at 2026-09-17T15:57Z, ⛔ not recalled. (a) This lane's other pm:dispatched cards: #18368 (service-settings, delivered, in review — PR #18703, file face read and disjoint), #18110 + #18555 (service-automation), #18153 (plugin-approvals), and #16506 (assignee zhuangjianguo, plugin-email, ⛔ not this seat's). All disjoint from plugin-security. (b) All open PRs intersected file-by-file: 0 hits on plugin-security. (c) ⭐ H17 rider check, and this one was close enough to be worth naming: the patrol anchor's restart-trigger index names packages/plugins/plugin-security/src/security-plugin.ts (for #7401) and packages/plugins/plugin-auth/src/objectql-adapter.ts (for #7881). Same package, different files ⇒ no intersection today — but if this diff reaches either of those two files the rider fires, so the dispatch order tells the dev to stop and report rather than to touch them.

⚠️ Two declared surface uncertainties — ⛔ NOT resolved by this claim, and deliberately so

1. packages/core is a DIFFERENT LANE. resolvePlatformAdminStanding is defined in packages/core/src/security/platform-admin.ts, and packages/core belongs to domain:engine under the charter's package table, ⛔ not to this lane. The ruled change should only need to read that resolver from the boot path in plugin-security, but ⛔ this seat has not proved that. If the fix requires editing packages/core, that is a cross-domain surface and the dev stops and reports — ⛔ the card does not move lane (an already-dispatched card ⛔ does not change seats), and ⛔ the dev does not edit another lane's package on its own initiative.
2. The published-vocabulary axis may or may not reach packages/spec. The ruling makes the card Clause-②: yes 「where the audit schema/vocabulary is published」 — the hedge is the ruling's own. ⭐ Measured by this seat and handed over as a premise to falsify, not as a finding: packages/spec/src/migrations/entries/semantic/17.audit-log-action-enum-retired.ts exists, i.e. the audit-log action enum was RETIRED from spec, which suggests a new action name needs no spec change at all. ⛔ If that reading is wrong and spec must change, this lane's red line applies: stop and report, route to the domain:spec seat.

_{Dispatched by the domain:services PM seat (objectstack#6021) at 2026-09-17T15:57Z. needs:contract-review hung on this card in the same claim act (dual-carrier rule; the PR half follows the moment the PR exists). ⛔ The dev leaves no second claim — this comment is the identity.}

---

Generated by Claude Code

[huangyiirene]

os-dev-report
{
"issue": 18412,
"status": "needs_decision",
"branch": "claude/issue-18412-platform-admin-standing-audit-trail",
"pr": null,
"session": "session_01QGMBhvUoyD8t5zY8xHQhnP",
"premise_still_valid": false,
"summary": "The issue's OWN premise holds and is verified: resolvePlatformAdminStanding builds the per-entry summary (declaredSpelling / registered / verified / holding userId) and bootstrap-platform-admin.ts:756-772 throws it into an info log. P5 confirmed. What falls is the RULING's organization premise. The ruling says 'measure how the platform-owner organization is represented and follow it' plus 'must not reintroduce a NULL-organization row'; the acceptance turns that into 'the entry carries a non-NULL organization'. Measured: there IS no platform-owner organization on this tree, by decision -- ADR-0131 section 1.5 rejected it ('The rejected middle: a platform organization') and section 3 lists 'A platform organization in any form' as a non-goal; zero occurrences repo-wide. ADR-0131's own answer for a deployment-level audit row is D7: sys_audit_log LOSES the organization column and the organization an audit row is ABOUT becomes the plain attribution field tenant_id, never the tenancy anchor. D7 is an ADR-0131 EXECUTION step and #15193 is open, which forbids dispatching any ADR-0131 execution card by any seat in any repo. Meanwhile organization_id is injected on sys_audit_log on EVERY deployment (injected-system-columns.ts:163 -- injected unless systemFields.tenant:false or tenancy.enabled:false; sys_audit_log declares neither), so the ruled carrier always carries the anchor. The decisive kill on any 'just stamp a tenant' option: the ruling's mandatory FIRST-BOOT baseline entry is written by bootstrapPlatformAdmin, which per-organization-catalog.ts:45-53 measured on a fresh walled rig runs 1.3 s AHEAD of the first sys_organization row -- there is literally no organization id in existence to stamp at the moment the baseline must be written. So every candidate value is NULL (explicitly forbidden), a tenant id (a lie that files a deployment-level fact behind one tenant's wall, and non-existent at first boot), or N rows one per organization (the per-organization-catalog.ts doctrine, which contradicts the acceptance's 'exactly one audit entry'). No speculative row shape was written. P1 and P2 both settled below and neither blocks.",
"gates": "NOT MEASURED -- no diff to gate. node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands with no paths, exit code captured to disk before reading, EXIT=2: 'this branch changes nothing against origin/main (merge base f8eaf67) -- nothing to derive.' It also printed a STALE TREE warning (HEAD f8eaf67 is 3 commits behind origin/main 72dd95f; scripts/pm/post-stamped.mjs changed across that range) -- irrelevant to an empty changed set, reported because the script flagged it. No build, test, typecheck or check:* family was run: with zero changed files none is owed, and running any would have been a measurement of nothing.",
"line_budget": "n/a -- no skills/** path in the diff; the diff is empty.",
"deviations": "None taken. Specifically NOT taken: no packages/core edit (P1 does not fire -- see below), no packages/spec edit (P2 does not fire), no touch of plugin-security/src/security-plugin.ts or plugin-auth/src/objectql-adapter.ts (H17 rider untouched), no label write, no assignee write, no PATCH, no MCP write tool, no second claim comment. The empty probe branch was pushed before any edit per the worktree protocol and carries no commits.",
"files_changed": [],
"mcp_calls": "0 -- no MCP GitHub tool was called, read or write.",
"api_writes": "1 -- POST /repos//issues/18412/comments (this report). The second budgeted endpoint, POST /repos/.../pulls, was NOT spent: there is no PR. Reads were single-card GETs on issues/18412, issues/18412/comments and issues/15193.",
"open_questions": [
{
"question": "Which organization does the platform-admin standing audit row carry, given that sys_audit_log always has the organization_id tenancy anchor, the record is deployment-level, no platform organization exists by ADR decision, and the first-boot baseline is written before any sys_organization row exists?",
"options": [
"A -- write organization_id NULL on this row and relax the ruling's no-NULL clause FOR THIS OBJECT, on the ground that the clause's own source (ADR-0131) already classifies sys_audit_log as deployment-level in D7, and that every other deployment-level audit row on this tree already lands this way (audit-writers.ts:1375, read-audit.ts:654, auth-event-audit.ts:314, service-settings/config-change-audit.ts:197 all stamp tenantId ?? null). Cost: writes the literal shape the ruling forbade, so it needs the maintainer's word, not mine. Benefit: implementable today, exactly one row as ruled, semantically honest (the record is about the deployment), no new object and no new key, and it is precisely the shape D7 will later formalize by deleting the column.",
"B -- park this card behind #15193 and let ADR-0131 D7 remove the organization column from sys_audit_log first; afterwards the record has no tenancy anchor at all and the ruling's no-NULL clause is satisfied STRUCTURALLY rather than by exception. Cost: the card waits on the v18 development line opening, and the audit gap the issue names stays open until then. Benefit: zero contradiction with any standing decision, and no clause has to be relaxed.",
"C -- materialize one row per organization, following per-organization-catalog.ts's doctrine for walled platform writes ('upsert by (name, organization_id), one pass per organization, so the answer is never NULL and never shared'). Cost: contradicts the acceptance's 'exactly one audit entry', multiplies ledger noise by organization count (a cousin of the option-B-per-boot noise the ruling rejected), leaks a deployment-level fact into every tenant's audit view, and is IMPOSSIBLE for the mandatory first-boot baseline, which runs before any organization exists. Benefit: it is the only option that yields a literally non-NULL organization_id."
],
"recommendation": "A, with B as the clean alternative if the maintainer would rather not relax the clause at all. A is the only option that delivers the ruled record now while staying honest about what the record is: platform-admin standing is deployment-wide by construction, so no organization authored it, and ADR-0131 D3's 'a row exists only when an organization authored it' argues AGAINST inventing an owner rather than for one. C is not recommended and is in any case unreachable at first boot. I am NOT treating the choice as mine: the ruling named this the sharpest correctness constraint on the card, it sits on an ADR-anchored security boundary carrying Clause-2 yes, and the three readings lead to three different architectures."
},
{
"question": "Procedural: the four-axis decision framework was not carried in this dispatch order, and my role file says the dev must not substitute axes of its own.",
"options": [
"PM pastes the framework verbatim from pm-dispatch SKILL.md and I re-analyse the options along those axes",
"PM applies the axes itself when escalating, using the measured options and costs above"
],
"recommendation": "Either is fine, but the analysis above is deliberately NOT axis-structured, and should not be read as if it were. The ruling comment's own 'Four-facet reading' shows the axes exist; I did not reconstruct them from that."
}
],
"out_of_scope_findings": [
"noted, not filed: four sys_audit_log writers (plugin-audit/src/audit-writers.ts:1366-1374, read-audit.ts:652-654, auth-event-audit.ts:312-314, service-settings/src/config-change-audit.ts:93-108) all comment that organization_id 'only exists in multi-tenant deployments (the SchemaRegistry auto-injects it conditionally)'. Measured against spec/src/data/injected-system-columns.ts:163 and platform-object-tenancy.ts's own header ('applySystemFields provisions the tenant COLUMN unconditionally'), that is stale: the column is injected on every deployment unless the object declares systemFields.tenant:false or tenancy.enabled:false. Behaviour is unaffected because every one of those writers probes the schema before stamping, so this is a wrong comment rather than a defect, and it is not copy-into-failure material. Successor who will read it: the ADR-0131 D7 execution card for sys_audit_log, which is blocked on #15193.",
"noted, not filed: the wall-bypass emit site (plugin-security/src/security-plugin.ts:6349-6353) justifies not using sys_audit_log with 'plugin-audit is not wired into plugin-security (no dependency in either direction)'. Measured, that reason does not hold as stated: service-settings has no plugin-audit dependency either and writes sys_audit_log directly by object name through engine.insert. The carrier is reachable from plugin-security without a new dependency, which is why the carrier is NOT the blocker on this card. Successor: whoever settles this card's carrier question.",
"noted, not filed: sys_audit_log is unclassified by absence in the #13491 inventory (platform-object-tenancy.ts), so resolveSystemInsertOrganization never fires on it and a NULL-organization audit row is written today with no refusal and no warning -- on an object whose own writer comment says 'audit rows must never be written with organization_id = NULL'. This is already a declared-open state by construction (unclassified means pending adjudication, never guessed), so it is not a new finding; it is folded into the decision above because it is why option A costs nothing mechanically today. Successor: the same adjudication batch the inventory already routes to."
],
"premise_findings": {
"P1_packages_core_lane": "FALSIFIED, favourably -- no lane crossing needed. resolvePlatformAdminStanding is NOT in packages/core: it is defined at packages/plugins/plugin-security/src/platform-admin-service.ts:102, in THIS lane's own package. packages/core owns only resolvePlatformAdminEmails / normalizePlatformAdminEmail / matchesConfiguredPlatformAdmin, which this work would READ and never edit. The dispatch's file-surface expectation was right; its reason for doubting it was not.",
"P2_packages_spec_axis": "CONFIRMED -- no packages/spec change is needed, but the PM's reasoning does not hold and the right reason is stronger. The audit-log action enum was never IN spec: it is a Field.select literal in plugin-audit/src/objects/sys-audit-log.object.ts:182. The spec file 17.audit-log-action-enum-retired.ts is a MIGRATION RECORD of two values leaving that plugin-owned enum, and it says so itself: 'nothing lands in RETIRED_KEYS_BY_MAJOR (no authorable KEY changed) and the four surface ratchets are expected to be byte-identical (no def changed) ... Nobody authors an audit row and nobody authors this enum.' So the published vocabulary the ruling's Clause-2 hedge points at lives in plugin-audit, which is the SAME lane (domain:services, identity side, per references/lanes/services.md:10). Zero packages/spec in any diff this card would produce.",
"P3_H17_rider": "Not fired and structurally avoidable. bootstrapPlatformAdmin is already invoked from security-plugin.ts, so the new write hangs off bootstrap-platform-admin.ts with NO edit to security-plugin.ts, and plugin-auth/src/objectql-adapter.ts is nowhere near this work.",
"P4_landing_point": "CONFIRMED by reading the boot path, not by symbol grep. The seam is bootstrap-platform-admin.ts:756-772, inside the if (walled) branch -- which is also the semantically right place: under single the first-user promotion still writes a durable grant row, so the durability loss the card names is walled-posture-specific.",
"P5_summary_already_assembled": "CONFIRMED. PlatformAdminStandingEntry (platform-admin-service.ts:46-60) carries email, declaredSpelling, registered, verified and the holding userId -- exactly the four things the ruling names. The card's 'the input is already assembled' premise is true.",
"P6_history": "Left UNREAD as instructed; nothing in this report rests on git history.",
"carrier_reachability": "Settled and NOT a blocker. plugin-security does not depend on plugin-audit and does not need to: service-settings writes sys_audit_log by object name through engine.insert with no plugin-audit dependency, and bootstrap-platform-admin.ts already holds ql. A deployment with no ledger mounted degrades by the same swallow-and-report posture config-change-audit.ts uses, which is the state PR #18703 makes explicit.",
"action_name_spelling": "Open but minor, and NOT the blocker. The ruling's example spelling platform_admin_standing.changed carries a dot, while Prime Directive #3 requires snake_case for machine names and the field's own description says 'Action type (snake_case)'; every incumbent value (config_change, import) is dotless snake_case. The ruling wrote 'e.g.', so the spelling is open. I would have used platform_admin_standing_change and said so in the PR body. Adding the value also moves plugin-audit's four generated translation bundles plus source-hashes, which are regenerated and never hand-edited, and requires a WRITER-FIRST row in sys-audit-log-retired-actions.test.ts's ACTIONS_WITH_WRITERS list."
},
"tests": "None run, and none owed: the diff is empty. No ablation and no reverse verification were performed, because nothing was implemented -- recording that explicitly rather than leaving the field to imply a measurement happened."
}

---

Generated by Claude Code