spec: the plugin-security-advanced scan-result surface has ZERO consumers after #14919 — 22 published authorable rows with no author and no parser

Found while retiring PluginSecurityScanner (#14919, PR #15930). Filed rather than fixed: retiring a packages/spec surface is a maintainer ruling plus the spec-property-retirement playbook, not a rider on a packages/core removal.

What moved

docs/qa/platform-checklist/FOLLOW-UPS.md §7a already carried this row, and its evidence column read:

KernelSecurityScanResult / KernelSecurityVulnerability / PluginSecurityManifest.scanResults — no .parse/.safeParse site anywhere; only consumer is the dead scanner (type-only import)

#14919 deletes that scanner. So the row's stated consumer is gone and the count moves from one type-only importer to zero consumers of any kind. PR #15930 corrects the row's text; this issue is the disposition the corrected row now needs.

The reading, measured at `9f6baaafd` (before the retirement lands)

The two type names were imported in exactly one place in the whole tree:

packages/core/src/security/security-scanner.ts:3   import type { KernelSecurityVulnerability, KernelSecurityScanResult } from '@objectstack/spec/kernel';

That file is deleted by #14919. Their declaring module is packages/spec/src/kernel/plugin-security-advanced.zod.ts; outside that module and its own self-test (plugin-security.test.ts) nothing in packages/** names either type, and there is no .parse or .safeParse call against either schema anywhere. The FOLLOW-UPS row records 22 rows published to packages/spec/authorable-surface/kernel.json from this family.

The neighbouring rows in the same §7a table are the same shape and should be triaged together rather than one at a time:

PluginQualityMetrics.securityScan (plugin-registry.zod.ts) — spec self-test only
marketplace / incident scan vocabulary (marketplace.zod.ts 'scanning', marketplace-admin.zod.ts, incident-response.zod.ts 'malware') — declared-only enum members with no producer in this repo

Why this is ADR-0049 territory

Nothing writes these keys, nothing parses them, and after #14919 nothing so much as imports their types — while they are published as authorable rows, so an author can write them, have them accepted, and get no behaviour. That is the declared-not-enforced shape Prime Directive #10 names, one layer out from the class #14919 removed for the same reason.

Note this is a narrower claim than "retire the module": plugin-security-advanced.zod.ts is a large file and other keys in it are live subjects of open work — #15811 (evaluated expression slots: its condition key) and #15678 (duration key naming: timeout, tokenExpiration, retention, responseTime). Neither of those touches the scan-result family, and a retirement here must not collide with them. Sequence with those two, and scope the removal to the scan-result surface rather than the module.

What is NOT being asserted

The out-of-repo consumer population is not measured. @objectstack/spec is published, so removing these types is breaking for an unmeasured population, exactly as #14919's changeset says of its own three exports. That is an input to the ruling, not a reason to skip it.

Ask

A maintainer disposition under ADR-0049 enforce-or-remove: retire the scan-result surface (then the spec-property-retirement playbook applies to the authorable-surface rows and the ADR-0087 conversion), or declare an owner that will enforce it.

分诊：`domain:spec` / `enhancement` + `finding` / `needs-user-decision` / `priority:p3`

⛔ needs-user-decision 不与 pm:* 并存（先例 #15854 / #15617 / #15542）。卡片自陈 "Ask: A maintainer disposition under ADR-0049 enforce-or-remove" ⇒ 决定箱成立，本席只做核实与定级。

落点核实——本席重跑了消费者普查，卡片的「零消费者」在 main 上成立

在 packages/** 全量搜 KernelSecurityScanResult / KernelSecurityVulnerability，命中全部是生成的清单，无一条是源码消费点：

packages/spec/api-surface/kernel.json:146-151      KernelSecurityScanResult (type) / …Parsed (type) / …Schema (const)
                                                    KernelSecurityVulnerability (type) / …Parsed (type) / …Schema (const)
packages/spec/authorable-defaults/kernel.json:54-55  kernel/KernelSecurityVulnerability:exploitAvailable = false
                                                     kernel/KernelSecurityVulnerability:patchAvailable = false
packages/spec/authorable-surface.base.json:4396-4397 kernel/KernelSecurityScanResult:codeIssues
                                                     kernel/KernelSecurityScanResult:dependencyVulnerabilities

范围内活控制：同一轮对声明模块搜 PluginSecurityManifest 得 5 命中 ⇒ 该文件可搜、模式有效 ⇒ 上面「无源码消费点」是读数，不是 grep 失效。

⇒ 卡片说的那次移动已经完成：packages/core/src/security/security-scanner.ts（唯一的 type-only 导入方）在 main 上已不存在 ⇒ #14919 / PR #15930 落地了，计数从「一个 type-only 导入方」变成 「零，任何形式的消费者都没有」。

⭐ 而发布面仍然完整：三类清单（api-surface 的导出 pin、authorable-defaults 的默认值、authorable-surface 的可编排行）都还在。⇒ 作者今天仍然可以写这些键、被接受、得不到任何行为 —— 正是 Prime Directive #10 命名的 declared-not-enforced 形状，也正是 ADR-0049 的地盘。卡片的定性零错。

定级理由

domain:spec：packages/spec 整包 ⇒ domain:spec。
enhancement 而非 bug：main 上没有东西是假的——这些 schema 的定义本身没有说谎，它们只是无人消费。退役是收窄已发布面（一次破坏性变更），按机械边界测试落在需人工裁决的一侧。这也是它必须走决定箱、⛔ 不能作为 tidy 顺手做掉的原因。
p3：无运行期后果、无数据风险、无用户可见故障。⛔ 不降更低：它是已发布的可编排面，每多存在一个版本，外部消费者群体就多一分不确定；且它现在处于「零消费者」这个最干净的退役时点。

⭐ 卡片做对的三件事，记名背书

① 它把主张缩到了正确的宽度。

Note this is a narrower claim than "retire the module": plugin-security-advanced.zod.ts is a large file and other keys in it are live subjects of open work — #15811（evaluated expression slots: 其 condition 键）与 #15678（duration key naming: timeout, tokenExpiration, retention, responseTime）。Neither of those touches the scan-result family, and a retirement here must not collide with them.

⚠️ 本席核实了这条相邻性是真的：本轮更早处理 #15939 时，正是在同一个文件 plugin-security-advanced.zod.ts 上读到那个 timeout 键（JSDoc 写 milliseconds、describe 不写）——那正是 #15678 的地盘。⇒ 同一文件上有三张开着的卡在动不同的键。 本席把卡片的告诫升级为排期硬约束：

⛔ 退役的范围必须严格限定在 scan-result 家族（KernelSecurityScanResult / KernelSecurityVulnerability / PluginSecurityManifest.scanResults），不是模块。取卡前先确认 #15811 与 #15678 的在飞状态，避免三方在同一文件上碰撞。

② 它明确声明了未测量的部分，而不是绕过它。

The out-of-repo consumer population is not measured. @objectstack/spec is published, so removing these types is breaking for an unmeasured population … That is an input to the ruling, not a reason to skip it.

⭐ 最后半句是本席想要被复制的措辞：一个未测量的风险是裁决的输入，不是不裁决的借口。

③ 它把邻近的同型行一并点出来、建议同批处置而非逐条：

PluginQualityMetrics.securityScan（plugin-registry.zod.ts）—— 仅 spec 自测
marketplace / incident 扫描词表（marketplace.zod.ts 的 'scanning'、marketplace-admin.zod.ts、incident-response.zod.ts 的 'malware'）—— 只声明、本仓无生产者

⇒ 本席背书同批裁决：这四组是同一个 ADR-0049 问题的四个实例，分四次裁会得到四个可能不一致的答案。⛔ 但同批裁决 ≠ 同批退役——若裁决是「退」，退役 PR 仍应按上面的碰撞约束分开落地。

⚠️ 给裁决者的一条

若裁决是「退役」，卡片指出后续要走 spec-property-retirement playbook（可编排面行 + ADR-0087 转换）。⚠️ 本席在本轮更早处理 #15957 时注意到该 playbook 的 SKILL.md 正被一条未认领的 2 字节 pin 收紧反复打印——⛔ 不构成阻塞，但取卡人若发现 playbook 的门在报无关的红，那是 #15957 而不是本卡的问题。

⛔ 本席为 triage 席位：不认领、不派单、不写码、不合并、不裁决 decision-box（本会话为 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。

Generated by Claude Code

Ruling recorded — retire the scan-result surface under ADR-0049 (director seat, decision batch #65, 2026-09-07)

Maintainer reply, verbatim: 「同意」 (all batch #65 recommendations adopted).

Ruling. The plugin-security scan-result family — KernelSecurityScanResult, KernelSecurityVulnerability, PluginSecurityManifest.scanResults (22 authorable rows) — and its sibling PluginQualityMetrics.securityScan are retired via the spec-property-retirement playbook (authorable-surface rows, authorable-defaults, api-surface pins, ADR-0087 conversion entries, docs). Zero consumers after #14919; an author could write these keys, be accepted, and get nothing. "Declare an owner to enforce" is refused: it would rebuild a scanner that was just retired for the same reason.

The marketplace / incident vocabulary members ('scanning' status, 'malware' incident type): conditional. Before touching them, grep objectstack-ai/cloud for producers (the marketplace flow lives there). A producer found ⇒ they stay and the finding is recorded here; none ⇒ they retire in the same batch. Record the reading on this card either way.

Hard constraints.

Scope is the scan-result family, ⛔ not the module: plugin-security-advanced.zod.ts is being edited by spec: the evaluated-slot rule of #15430 reaches only the flow-node ledger — every other ExpressionInputSchema slot an engine evaluates (formula expression, validation / hook / sharing condition, visibleWhen…) still accepts an ast-only or blank-source envelope #15811 (condition, pm:queue) — [#14478 stack 3/6] kernel/: the 14 remaining duration keys carry their unit in the key name — ADR-0087 conversions with readers (runtime-emitted measurements included) #15678 is closed. Check spec: the evaluated-slot rule of #15430 reaches only the flow-node ledger — every other ExpressionInputSchema slot an engine evaluates (formula expression, validation / hook / sharing condition, visibleWhen…) still accepts an ast-only or blank-source envelope #15811's flight state before branching; one file, no three-way collision.
Breaking for an unmeasured out-of-repo population; no deprecation window (maintainer 2026-08-27: 「项目在创业阶段，用户也很少，短期不考虑渐进」); major bump via changeset; release note written centrally.
Clause-② yes (published surface removed): landing PR carries needs:contract-review. If the playbook's SKILL.md gate reports the unrelated 2-byte pin red from [finding] the skill line ratchet has been printing an unclaimed 2-byte pin tighten for spec-property-retirement/SKILL.md on every run #15957, that is [finding] the skill line ratchet has been printing an unclaimed 2-byte pin tighten for spec-property-retirement/SKILL.md on every run #15957's problem, not this card's.

Labels: needs-user-decision → pm:queue. Ledger on #12708 (batch #65).

Generated by Claude Code

Claim: `domain:spec` execution seat 2 — `pm:queue` → `pm:dispatched`, assignee `os-warren`

Seat: domain:spec#2 · session session_01UDXER3sdqfeVYpEWZs5mZx · 2026-09-21T16:25Z
Ruling-ref: 5564446653 (director seat, decision batch #65, maintainer verbatim 「同意」). This card is execution; ⛔ nothing below re-opens it.

The ruling's two hard constraints, checked before claiming — both clear

constraint	reading
「Check #15811's flight state before branching; one file, no three-way collision」	#15811 is `closed` / `completed` (updated 2026-09-19T03:31Z). #15678 was already closed when the ruling was written. ⇒ no other card is editing `plugin-security-advanced.zod.ts`.
「Scope is the scan-result family, ⛔ not the module」	Carried verbatim into the dispatch order as a fence, with a STOP-and-report rule on any path outside it.

Premise re-measured on `origin/main` @ `f77b806565`

reading	value
`KernelSecurityScanResult` / `KernelSecurityVulnerability` in `packages/*/.ts`, excluding the declaring module and its own self-test	0
LIT CONTROL — `PluginSecurityManifest` inside `plugin-security-advanced.zod.ts`	5 ⇒ the file is greppable and the zero is a reading
`packages/core/src/security/security-scanner.ts` (the former type-only importer)	absent from the tree ⇒ #14919 landed
`PluginQualityMetrics.securityScan` in `packages/*/.ts`	only `packages/spec/src/kernel/plugin-registry.test.ts` ⇒ spec self-test only, exactly as the ruling states
still published	`api-surface/kernel.json` 6 lines · `authorable-defaults/kernel.json` 2 · `authorable-surface.base.json` 25

⇒ zero consumers, full publication. The declared-not-enforced shape is intact and the retirement window is still the clean one.

⚠️ The last row is a line grep of two names, ⛔ not a row count — it neither confirms nor contradicts the card's 「22 authorable rows」. The dev counts rows with the playbook's own instrument.

Serial census — the retirement surface is clear, with one shared ledger

File lists of all 13 open PRs, pulled in one pass in this act (214 rows):

path	open PRs holding it
`packages/spec/src/kernel/plugin-security-advanced.zod.ts`	0
`packages/spec/src/kernel/plugin-registry.zod.ts`	0
`api-surface/kernel.json` · `authorable-defaults/kernel.json` · `authorable-surface.base.json`	0 — the hits in this family are on OTHER shards (`system.json`, `api.json`, `automation.json`); api-surface is sharded by entry point (#5837) precisely so two PRs on different entry points never share a file
`packages/spec/src/migrations/registry.ts`	3 — #19600, #19595, #19493

LIT CONTROL: the same instrument returns those three migrations/registry.ts rows and the other api-surface shards, so the zeros are readings.

⇒ The only contention is migrations/registry.ts, which the seat post records as ordinary concurrency with a documented procedure: the new ADR-0087 entry lands at its own offset and a conflict goes through scripts/pm/os-regen-merge.sh, ⛔ never a hand-edited conflict marker.

⛔ The conditional half is CARVED OUT — the repo it needs is not reachable from this session

The ruling says: 「Before touching them, grep objectstack-ai/cloud for producers (the marketplace flow lives there) … Record the reading on this card either way.」

objectstack-ai/cloud is not reachable from this session: the repository listing returns 33 repositories and none is cloud. LIT CONTROL: that same listing contains objectstack-ai/objectstack, objectstack-ai/objectui, objectstack-ai/hotcrm, objectstack-ai/objectos and objectstack-ai/duly, so the absence is a reading and ⛔ not an empty response.

Under 「仓不可达 ⛔ 不当查过了干净」 this seat does not treat the vocabulary members as clear, and does not dispatch their removal. The ready-to-run command, for whichever seat has objectstack-ai/cloud — please paste the output back on this card:

git grep -n "'scanning'\|\"scanning\"\|'malware'\|\"malware\"" -- '*.ts' '*.tsx' '*.json'

⇒ This dispatch covers the unconditional half only: the scan-result family (KernelSecurityScanResult, KernelSecurityVulnerability, PluginSecurityManifest.scanResults) and its sibling PluginQualityMetrics.securityScan. The marketplace 'scanning' status and incident 'malware' type stay put until that reading comes back.

Shape

Clause-②: yes (a published surface is removed) with the needs:contract-review carrier on the PR; major changeset; no deprecation window (maintainer 2026-08-27 「项目在创业阶段,用户也很少,短期不考虑渐进」); release note written centrally, ⛔ not in this PR. ⚠️ The required contract-review tier is now CONTRACT_REVIEW_TIER — re-read from CONTRACT_REVIEW_TIER on origin/main in this act; the 2026-09-06 triage comment above names the old value, which was correct then and is not now (ledger: #19603).

⚠️ Redacted 2026-09-21T18:2xZ by the seat. Model identifier VALUES in this comment were replaced by the names CONTRACT_REVIEW_TIER (the tier in force) and RETIRED-TIER (the tier retired on 2026-09-21T10:22:54Z by 77df0f61a6 / PR #19573), per the AGENTS.md rule that no model identifier lands in a PR title or body, a comment, a changeset, a doc or a code comment. ⛔ No judgment, figure, coordinate or verdict was changed. Inventory and the standing rule conflict: #19615.

Generated by Claude Code

Dispatched — `os-dev`, subagent, round of the 2026-09-21T16:14Z fire

domain:spec execution seat 2, session session_01UDXER3sdqfeVYpEWZs5mZx, 2026-09-21T16:26Z. Branch claude/issue-15932-retire-scan-result-surface. The claim and its measurements are 5763876248.

Fences written into the order, each as a STOP rule rather than a caution:

Scope is the four names, ⛔ not the module — any path outside them plus their generated/docs/conversion consequences ⇒ STOP and report before writing.
'scanning' and 'malware' are carved out and must be left untouched, and ⛔ must not be recorded as checked: objectstack-ai/cloud is unreachable from this session, so the ruling's conditional grep has not been run by anyone.
「Declare an owner to enforce」 is refused by the ruling; ⛔ not to be proposed.
major changeset, no deprecation window, release note written centrally, ⛔ content/docs/releases/ untouched.
migrations/registry.ts conflicts go through scripts/pm/os-regen-merge.sh; ⛔ never a hand-edited marker, ⛔ never a hand-edited generated half.
The 「22 authorable rows」 figure is to be counted with the playbook's instrument and reported; a disagreement is a finding, ⛔ not something to reconcile silently.
A gate that exits on an unmet prerequisite is NOT MEASURED, ⛔ not green.
⛔ No ready-flip, no enqueue, no auto-merge. ⚠️ The at-tier contract review runs at CONTRACT_REVIEW_TIER (constant re-read from origin/main in this fire); ledger for why that matters: decision(pm): this seat dispatched 5 clause-② reviews at the RETIRED model tier after the maintainer ruling landed — two PRs merged on void verdicts #19603.

⚠️ Redacted 2026-09-21T18:2xZ by the seat. Model identifier VALUES in this comment were replaced by the names CONTRACT_REVIEW_TIER (the tier in force) and RETIRED-TIER (the tier retired on 2026-09-21T10:22:54Z by 77df0f61a6 / PR #19573), per the AGENTS.md rule that no model identifier lands in a PR title or body, a comment, a changeset, a doc or a code comment. ⛔ No judgment, figure, coordinate or verdict was changed. Inventory and the standing rule conflict: #19615.

Generated by Claude Code

Claim: PM loop, seat domain:spec#2 — ⛔ the FIRST readable claim on this card; 5763876248 carried the same content but was unreadable
Session: session_01UDXER3sdqfeVYpEWZs5mZx
Branch: claude/issue-15932-retire-scan-result-surface
Worktree: objectstack-issue-15932
Domain: domain:spec
Seat: domain:spec#2
Container & model: S/M, mode:subagent, model: opus (default judgment tier).
Clause-②: yes
Ruling-ref: 5564446653 (director seat, decision batch #65, maintainer verbatim 「同意」)

Why this is re-posted, before its PR exists rather than after

check:closing-target-claim went red on the sibling PR #19609 with 「no comment on the card is a Claim: at all」, because that card's claim opened with ## Claim: … — a markdown heading — and carried no Branch: line. The reader requires a comment whose FIRST line begins Claim: and which names the branch on a Branch: line.

Comment 5763876248 on this card has the identical defect. Its PR is not open yet, so the gate has not fired here — this re-post is to stop it firing at all, ⛔ not a reaction to a red.

⇒ There was no claim of record on this card until this comment, so this is the first claim and ⛔ not a second one. Everything in 5763876248 stands as measurement — the two cleared hard constraints (#15811 / #15678 both closed), the premise re-measurement with its lit control, the serial census, and the carved-out conditional half — ⛔ none of it is withdrawn.

Unchanged, and still the load-bearing fence

⛔ objectstack-ai/cloud is not reachable from this session (33 repositories listed, none is cloud; lit control: objectstack, objectui, hotcrm, objectos, duly are all in that list). So the marketplace 'scanning' status and incident 'malware' type are untouched and not recorded as checked; the ready-to-run command is on 5763876248 for a seat that has that repo.

pm:dispatched, assignee os-warren, dev in flight. Clause-②: yes, major changeset, needs:contract-review carrier owed on the PR, at-tier review at CONTRACT_REVIEW_TIER.

⚠️ Redacted 2026-09-21T18:2xZ by the seat. Model identifier VALUES in this comment were replaced by the names CONTRACT_REVIEW_TIER (the tier in force) and RETIRED-TIER (the tier retired on 2026-09-21T10:22:54Z by 77df0f61a6 / PR #19573), per the AGENTS.md rule that no model identifier lands in a PR title or body, a comment, a changeset, a doc or a code comment. ⛔ No judgment, figure, coordinate or verdict was changed. Inventory and the standing rule conflict: #19615.

Generated by Claude Code

Contract review

Served-tier: 152/152 CONTRACT_REVIEW_TIER
Head-sha:
0a1bac8977e9662fb0337250f6deadd2599f8eea

Merge base measured: 236cec19a5edbea3e658029cd82357e061013d11 (git merge-base resolved after git fetch --deepen=300; it did NOT print empty). 23 paths, +748/−347 = 1095 changed lines. CONTRACT_REVIEW_TIER on origin/main reads 'CONTRACT_REVIEW_TIER' at scripts/pm/dispatch-gates.mjs:12142.

① Derived judgments

CHARGE A — the level, measured from the tree.
The gate's actual refusal condition is judge({introduced, pre}) in scripts/check-changeset-no-major.mjs: pre?.mode === 'pre' ⇒ exempt; otherwise a major the diff INTRODUCES ⇒ enforce ⇒ exit 1. .changeset/pre.json does not exist on origin/main — it was deleted 2026-08-14 (chore: version packages (#6208)), after changeset pre exit on 2026-08-14 (#8643). I ran the real exported judge() from the origin/main bytes:

major, pre: null → enforce (exit 1) ← the live state
major, pre: {mode:'pre'} → exempt (control, unreachable here)
no major → clean; introduced: null → unreadable-diff (both arms fire ⇒ instrument lit)

So the gate was already armed three weeks before the 2026-09-07 ruling. The fixed group in .changeset/config.json is one group of 70 members and includes @objectstack/spec — the "one major promotes ~70 packages" claim is exact. The playbook line is verbatim what the seat quoted (.claude/skills/spec-property-retirement/SKILL.md:291, 「@objectstack/spec 用 minor,⛔ 不用 major」), and it landed 2026-09-20T22:33:46Z in #19446 (2951c0f8f8) — 13 days AFTER the ruling, one day before this PR. The playbook is the later instrument and was corrected precisely because the gate refuses major.

Judgment: minor + BREAKING banner + ADR-0087 disposition marker is the correct carrier here, and nothing in this diff makes the level wrong on its own terms. The changeset body carries the FROM → TO table, the one-line fix, and ; Check Changeset is green at this head. The gate's own header names exactly these two as "the only signal there is" during the window.

Two things the dev's argument omits and the decision box needs:

The allow-major escape hatch exists. Outside pre-mode, the allow-major PR label skips the whole Check Changeset step. So major is not un-landable — it is un-landable without a label a human hangs, at the stated cost of promoting all 70 packages. "A guaranteed-red PR that cannot land" overstates it.
A third instrument prescribes major and contradicts the gate. The json-schema manifest deletion gate's own refusal text (packages/spec/scripts/build-schemas.ts, the #4725 block) tells the author: "2. Add a D2 conversion … plus a major changeset". That text is prose in a failure message, not enforced — but it is a live instruction surface that still says major, and it is the same gate CHARGE E relies on. It should move with whatever the seat decides.

CHARGE B — retirement mechanics: correct, and drawn exactly where the playbook draws it.
Playbook §2's fork table has three rows, and the split follows it row-for-row:

非 .strict() → retiredKey() tombstone. Both carrying shapes are non-strict, measured: .strict() appears 0 times as a call in plugin-security-advanced.zod.ts and plugin-registry.zod.ts — the only matches are the two/one prose mentions inside comments (lines 319, 592 and 90 respectively). Lit control: .strict() is used elsewhere in the same directory (context.zod.ts, index.ts, manifest.test.ts), so the zero is a reading. Both shapes are live parse targets (PluginSecurityManifestSchema.parse/safeParse at plugin-security-advanced.test.ts:303,362,386; PluginQualityMetricsSchema.parse ×7 in plugin-registry.test.ts). ⇒ a bare deletion would be a silent strip. Confirmed.
没人 parse 它 → neither route; delete the baseline rows and say so in the changeset. That is the two defs: no direct .parse/.safeParse site, and their only referents were the keys now tombstoned. Confirmed below.
The dev additionally registers the defs in RETIRED_DEFS_BY_MAJOR[18], which is not a playbook route but what the deletion gate demands (CHARGE E).

Major-number convention checked against siblings: the prescriptions say "removed in @objectstack/spec 17" while the entries live under 18.*. That is the house convention, not a defect — 18.kernel__PluginSecurityManifest__vulnerabilityDisclosure.responseTime.ts, 18.kernel__KernelSecurityPolicy__auditLog.retention.ts and 18.kernel__PluginHealthReport__metrics.responseTime.ts all say "in @objectstack/spec 17" under 18.. packages/spec/package.json is 17.4.0.

Liveness-ledger discipline (playbook §2's asymmetric leg) does not bite: packages/spec/liveness/ has 0 hits for scanResults / securityScan / either carrying type, and 0 of its 38 type files name a plugin or security type. Lit control: the same grep instrument reads 42 hits in action.json. Spec property liveness is green in CI. The keys were never in the walked ledger — the same fact that grounds CHARGE D.

CHARGE C — the fence holds.
At the merge base, every referent of KernelSecurityVulnerabilitySchema in packages/**, apps/**, examples/**, scripts/** outside the generated baselines is in one file: plugin-security-advanced.zod.ts at :441 (declaration), :554 and :574 (both inside KernelSecurityScanResultSchema, itself retired), :731 (PluginSecurityManifest.vulnerabilities), :796–798 (the type aliases). PluginSecurityManifest.vulnerabilities is the last authorable referent outside the retiring set — verified, not asserted. Lit control on the same instrument and radius: KernelSecurityPolicy (a surviving sibling in the same module) returns 7 hits in the declaring file and 11 in its self-test. The fence is real: it is a forced consequence, it is named in four places (PR body, changeset, D3 entry, FOLLOW-UPS), and it is not a neighbour absorbed by proximity. authorable-surface.base.json was correctly not touched.

CHARGE D — no D2 conversion is genuinely owed.
The sibling precedent exists and says exactly what is claimed. packages/spec/src/migrations/entries/semantic/18.kernel-plugin-security-durations-unit-in-key.ts, verbatim: "Why a semantic entry and not a D2 conversion: a PluginSecurityManifest is a package artifact a publisher ships and a SandboxConfig is the isolation argument a host constructs, so neither is a stack collection member or a stored sys_metadata row and the conversion chain has no seam that would see one." Independent corroboration: the liveness ledger walks stack collection types and contains no plugin-security type at all. The D3 entry plugin-security-scan-result-surface-retired carries the judgement and is registered. One honest extension to note: the precedent covers PluginSecurityManifest/SandboxConfig; PluginQualityMetrics (a plugin registry entry) is carried by the same reasoning rather than by the precedent itself — the PR states this in its own words rather than borrowing the citation, which is the right way to do it.

CHARGE E — the hand edit is the documented exception, and it is the only one.
packages/spec/scripts/build-schemas.ts refuses a def that leaves the emitted set while still listed in the manifest dir and exits before writing anything, with this prescription: "if the removal is deliberate — delete the key(s) from packages/spec/json-schema.manifest/<category>.json in the same PR AND declare each one in RETIRED_DEFS_BY_MAJOR (src/migrations/registry.ts), which the manifest deletion gate below requires (#4725)." The generator will never remove the key for you. The second gate then measures removals against the manifest at the merge base, which this commit cannot rewrite, and passes only on a RETIRED_DEFS_BY_MAJOR declaration. The two-step is prescribed verbatim by the gates themselves; the hand edit is the documented exception, not a defect.
The hand edit is also machine-verified: the shard is compared BYTE-for-byte against schemaManifestShardTexts(), so a non-canonical hand edit fails --check. The actual diff is a clean two-line removal in sorted order. Every other moved artefact is a pure sorted-order removal consistent with its generator (api-surface −6 rows, export-origins −6, declaration-map −4, authorable-defaults −2), registry.ts is the generated (#7297) inline of the new entry files, and docs/audits/…counts.md kernel/ 257 → 247 is arithmetically exact: the removed source contains 10 non-strict z.object sites (7 in KernelSecurityScanResult, 1 in KernelSecurityVulnerability, 2 in the securityScan block). Nothing else generated was hand-edited.

CHARGE F — my own count, with the instrument stated.
Instrument: JSON set-difference on the keys array of packages/spec/authorable-surface/kernel.json between merge base and head (not a line grep).

base 811 rows → head 786 rows
28 rows removed: KernelSecurityScanResult: ×8, KernelSecurityVulnerability: ×17, PluginSecurityManifest:scanResults, PluginSecurityManifest:vulnerabilities, PluginQualityMetrics:securityScan
3 rows re-added with the [RETIRED] tag (the three tombstones)
net −25

Adjudication of the three instruments: the dev is right, twice. 27 is the named surface (8+17+1+1); 28 is the full set of rows that left, including the forced-consequence vulnerabilities. The seat's 25 is the two DEFS' rows only — a LINE grep of the two def names cannot see PluginSecurityManifest:scanResults, :vulnerabilities or PluginQualityMetrics:securityScan, because those rows do not contain either def name. (25 also coincides with the net row reduction, and with the "25 orphaned key rows" the authorable-surface deletion gate refused — both consistent.) The card's 22 is wrong and is superseded; it came from the FOLLOW-UPS row, and that row now says so in the diff. Reporting the disagreement rather than silently reconciling it was the right call.

CHARGE G — the negative holds in the diff; the written records carry a stale, unmeasured assertion beside it.
All three carve-out files are absent from the 23-path list (grep over git diff --name-only for marketplace|incident-response exits 1). No token scanning/malware is added to any schema source — every occurrence in the diff is prose in the changeset, the D3 entry, the docblock, the generated docs tables, or the FOLLOW-UPS row it edits.
All three records use the correct posture — "not measured", not "checked and clean": changeset "⛔ Untouched, and not checked: … Their absence from this diff is not evidence about them"; D3 entry "unremoved and not recorded as checked"; FOLLOW-UPS "⚠️ The third row is NOT closed and was NOT checked." That requirement is met.
But two of the three carve-out coordinates no longer exist, and the dev's own "did not grep for either token" is why it went unnoticed:

marketplace.zod.ts 'scanning' — live, at :348. ✓
marketplace-admin.zod.ts — no such file at this head.
incident-response.zod.ts — no such file at this head. The whole incident-response family was already retired whole by spec: the rest of the incident-response, training and change-management families — every remaining key and all fifteen defs — has zero readers; whole-def enforce-or-remove is the open question left after #14477 #15513 (ruled 2026-09-05, before the 2026-09-07 ruling that made 'malware' conditional); the entry 18.incident-response-family-retired.ts records it. Token malware returns zero hits in any .zod.ts at head — its only occurrences are prose in ADRs, design docs, CHANGELOGs, retirement entries and this PR's own records. Lit control: scanning matches 207 files in the same radius and marketplace.zod.ts:348 is a live declaration ⇒ the zero is a reading.

So the sentence "the marketplace 'scanning' status and the incident 'malware' type stay exactly as they are, unremoved" (D3 entry; same claim in the changeset and FOLLOW-UPS) is a present-tense assertion that was not measured and is false for the 'malware' half. It does not touch the diff's correctness, and it is the opposite failure from the one the brief guards against — but it is a stale coordinate carried forward instead of re-located by shape, and the FOLLOW-UPS row it edited still cites two files that are gone.

CHARGE H — the ablation is a real proof.
The resolution claim is verified and is trivially true for this test: plugin-security-scan-result-retirement.test.ts imports ./plugin-security-advanced.zod, ./plugin-registry.zod and ./index — relative source paths inside src/, which no alias can redirect to dist/. The ablated file is the file under test; no build step intervenes, so there is no dist-staleness false green.
The blob anchor checks out exactly: git rev-parse <head>:packages/spec/src/kernel/plugin-security-advanced.zod.ts = 0f3af37f5068c0f89422e1d470695e57e00dd593 — the dev's stated pre-mutation blob, and the same 0f3af37f50 in the diff's index line. scripts/ablation-replace.mjs is present on origin/main and at head, unmodified by this PR.
The 1/4 split is exactly what the mutation predicts: the file holds 5 tests; relaxing scanResults to a permissive optional array fails only the scanResults refusal pin. Test 4 ("parses cleanly … grows no such property") stays green because the permissive shape also adds no property — so the result is well-targeted, not accidental. The pins assert issue code, path and prescription text rather than a bare toThrow(), which is what makes the single failure meaningful.

CHARGE I — both answers hold; the lit control is the weak part of an otherwise correct reading.
The drift comment is as described: it flagged content/docs/kernel/cluster.mdx (via RETIRED_DEFS_BY_MAJOR (symbol, a top-level const object)) and declared "⚠️ 11 changed file(s) yielded no anchor … NOT COVERED by this run — this is not a clean bill of health".

False positive: confirmed by measurement. cluster.mdx has exactly one occurrence of RETIRED_DEFS_BY_MAJOR, at :409, inside a paragraph about MetadataChangedEventPayloadSchema citing RETIRED_DEFS_BY_MAJOR[18] as the registration site for metadata-changed-event-payload-retired. It asserts nothing about the table's population, so adding entries cannot falsify it.
Zero hand-written pages: confirmed. Four tokens (KernelSecurityScanResult, KernelSecurityVulnerability, scanResults, securityScan) over all of content/docs/** minus the generated content/docs/references/** (which carries the ⚠️ AUTO-GENERATED — DO NOT EDIT banner): 0 hits each.
On the control: a removal sweep's control must be a token of the same specificity class — another def name or authorable key from the same module — not a generic English word. In that class I get KernelSecurityPolicy → 1 hit (lit, and it is the right control), but PluginSecurityManifest → 0, trustLevel → 0, testCoverage → 0. Generic words are lit for the wrong reason (permissions 367, sandbox 60). So the honest reading is: this module's vocabulary is barely present in hand-written prose at all, and the zero is carried by exactly one lit same-class control. It survives, but the dev should have named which tokens its "2, 6 and 11" controls were; unnamed control counts are not a reading a second party can reproduce.

CHARGE J — settled from CI by job and STEP conclusions (latest run per check NAME, no roll-up). The dev's gate report is wrong in three places, and one of them is a red.

family	CI evidence	verdict
`check:skill-examples`	step 22 "Check skills TypeScript examples compile" of Type Check · consumer gates (job `106433038722`) — completed / success	GREEN, not NOT MEASURED
`check:type-check-debt`	Type Check · debt ledger (job `106433038971`) — success; log shows BOTH halves ran (`--self-test` and `--re-measure`): "OK — 77/81 workspace packages type-checked … 4 in the DEBT ledger", "re-measure: OK … none above its recorded number"	GREEN, not NOT MEASURED
`check:skill-refs`	step 27 "Check generated skill references are in sync with the spec" of Type Check · source gates — success	GREEN (matches the dev)
`check:issue-citations`	`Lint & Repo Gates` = FAILURE, step 182 — exit 2	RED — unreported

Both "exit 3 / PREREQUISITE NOT MET" readings are local-environment artefacts (the debt gate needs a built closure; .github/workflows/lint.yml says so in the note above that step). CI measured both and both are green.
On the #15957 2-byte pin: the gate that could carry it is check:skill-examples, and it is GREEN at this head. The dev's "can claim neither red nor green" is resolved — it is green, and the ruling's warned-for red is not present.
The actual red, which the dev reported nowhere: check:issue-citations ran its scan half in CI (pnpm check:issue-citations && node scripts/check-issue-citations.mjs — the pnpm alias is the --self-test half only) and exited 2: "❌ check-issue-citations: 8 citation(s) THIS CHANGE ADDS do not resolve" — #14919 at plugin-security-advanced.zod.ts:22, :591, retired-defs/18.kernel__KernelSecurityScanResult.ts:10, retired-keys/18.kernel__PluginSecurityManifest__scanResults.ts:9, registry.ts:14847, :17369; #8715 at retired-defs/18.kernel__KernelSecurityScanResult.ts:18 and registry.ts:17377. Classified allocated-but-absent.
Independently confirmed by REST, not taken from the log: GET /repos/objectstack-ai/objectstack/issues/14919 → 404, /8715 → 404. Lit control on the same probe: /11825 → 200, /15957 → 200, /15811 → 200. The zero is a reading.
This is materially worse than a lint nit: the PR's entire premise is "the second half of #14919", and that number does not resolve on this board. The work itself demonstrably landed (packages/core/src/security/security-scanner-retirement.pin.test.ts and 18.plugin-security-scanner-retired.ts are in the tree), so the gate's own remedy applies and is cheap: "Either name a target that resolves, or keep the number and say IN PROSE that it no longer resolves and what the live record is." ⛔ The gate also says: do not guess a replacement number.
Job tail, measured from the jobs API rather than from the in-job reporter (which itself printed unmeasured-gate-tail: measured=no … reason=no_failure_recorded): 190 steps — 179 success, 10 skipped, 1 failure. Two real gates never ran behind the failure: step 183 (workflow step-name truncation) and step 184 "Duration-shaped spec keys carry their unit in the key name" — the gate that governs this exact file family. Those two are genuinely NOT MEASURED at this head.

CHARGE K — governance: no governed path is touched.
Run against the FINAL 23-path list with the real governedPathsIn / governedTierFor / landingTierOf imported from scripts/pm/check-governed-merges.mjs on origin/main (the working-tree copy differs and was not used). GOVERNED_SURFACES is six rows: docs/adr/** (H), .claude/** (S), skills/** (H), AGENTS.md (H), CLAUDE.md (H), docs/NORTH-STAR.md (H). Matcher: surface.prefix ? p.startsWith(prefix) : p === exact.

Result: governedPathsIn(23 paths) returns an EMPTY slice — 0 paths hit, 0 surfaces matched. The function's own docstring: "matched.length === 0 IS the clean path."
⚠️ governedTierFor(paths) answers 'H', but that is the fail-closed default for an empty slice (landingTierOf: "An EMPTY slice answers H — fail closed"), not a tier hit. Reporting H as "the tier" without that caveat would be a misreading; testVerdict reports null for this case before asking.
Lit control: one path per surface (docs/adr/0049-…, .claude/skills/…/SKILL.md, skills/objectstack-ai/SKILL.md, AGENTS.md, CLAUDE.md, docs/NORTH-STAR.md) → all six surfaces return 1 hit each.
Near-miss control on the matcher: docs/adrs/x.md, docs/adr.md, docs/audits/2026-07-unknown-key-strictness-ledger.counts.md (a real path in this diff), .claude-extra/x.md, skills.md, packages/skills/x.ts, AGENTS.md.bak, sub/AGENTS.md, sub/CLAUDE.md, docs/NORTH-STAR.md.orig → all MISS. The matcher is neither over- nor under-inclusive on this diff.
CI agrees: Governed Surface Queue Guard = success.
Size: 1095 changed lines against HUMAN_MERGE_LINE_THRESHOLD = 5000, which is strictly-greater (self-test: "exactly-5000-changed-lines-is-UNDER-the-threshold"). Does not exceed; no human-merge trigger on size.

CHARGE L — the two spellings are identical to the reader, and the green gate cannot fail on the difference.
From source: readClause2Line (scripts/pm/check-clause2-carriers.mjs) returns { kind:'declared', value:'yes'|'no', arm:'widening'|'narrowing'|null }, and the arm is deliberately not folded into value ("⛔ The arm is NOT folded into value"). declarationFromPullRequest returns value:'yes' whenever line.value === 'yes', arm or no arm; judgeLevel's CARRIED branch is value==='yes' OR (value==='no' AND arm==='narrowing'). So Clause-②: yes and Clause-②: yes (narrowing) route identically; the arm exists only to promote a no. The self-test block confirms the mechanism directly: armVerdict('Clause-②: no (narrowing)') === 'enforce', armVerdict('Clause-②: yes (widening)') === 'enforce', control armVerdict('Clause-②: no') === 'not-declared'. Claim verified.
Count correction: the exact spelling Clause-②: yes (narrowing) appears in 18 changesets at this head (17 besides this PR's), not 16. Lit control: bare Clause-②: yes appears in 12. Minor, and it strengthens rather than weakens the dev's point.
Which side each green gate can fail on for the clause-② question:

Check Changeset reads the declaration from pr.body, never from a changeset body — so the (narrowing) arm in the changeset is invisible to it. It can go red on: introducing a major; a PR that CARRIES clause ② while grading every moved package patch with none minor+ (enforce); or a malformed / near-miss Clause-②: line where the missing reading is material (not-measured-material). It is green here because the axis is carried (both by the body line and by the needs:contract-review label, carrier: present) and @objectstack/spec is graded minor.
⛔ No green gate can fail on whether the change actually narrows. Nothing measures the narrowing claim against the diff. The claim is true here — six exports leave api-surface/kernel.json, three authorable keys become [RETIRED] — but that is my reading of the artefacts, not a gate's.

② Semver level

minor on @objectstack/spec is the correct and only landable grade at this head, and the diff does not make it wrong on its own terms. The change is breaking; during the launch window the bump level is explicitly not the carrier, and the two mandated carriers are both present (BREAKING banner with FROM → TO and the one-line fix; ADR-0087 disposition marker). Check Changeset and check-adr-0087-registration.mjs are green. The major the ruling and both dispatch messages name is refused by check-changeset-no-major.mjs (verified by running its judge()), and the playbook was corrected to minor on 2026-09-20 — after the ruling — for exactly this reason.

⛔ I am not deciding whether to overrule the maintainer. For the decision box, three facts the seat's question rests on: (1) the gate was already armed on 2026-08-14, so the ruling's major was un-landable on the day it was made; (2) an allow-major PR label would let major through at the cost of promoting all 70 fixed-group packages, so "cannot land" is not literally true and the dev did not surface this; (3) packages/spec/scripts/build-schemas.ts's own deletion-gate failure text still instructs authors to write "a major changeset", so if the seat rules for minor, that text is a third instrument that needs to move with it.

③ Boundary flags

⛔ BLOCKING — a required check is RED at the reviewed head, and the gate report as filed is wrong in three places. Lint & Repo Gates = failure; step 182 check:issue-citations (scan half) exit 2, 8 citations this change adds do not resolve: #14919 ×6 and #8715 ×2, both independently confirmed 404 against a 200/200/200 lit control. The dev reported "36 families passing and two NOT MEASURED" and named this nowhere; both families it called NOT MEASURED are green in CI. This is the exact half-instrument failure the brief warns about — the pnpm alias runs --self-test, CI runs the scan. Remedy is cheap and prescribed by the gate itself: keep the numbers and say in prose that they no longer resolve and what the live record is (the work landed — security-scanner-retirement.pin.test.ts and 18.plugin-security-scanner-retired.ts are in the tree). ⛔ Do not guess replacement numbers.
⚠️ Two gates were never measured at this head, behind the failure: step 183, and step 184 "Duration-shaped spec keys carry their unit in the key name" — the gate that governs this very file family. Re-measure after the fix; do not read them as passing.
⚠️ Stale carve-out coordinates, and one false present-tense assertion. marketplace-admin.zod.ts and incident-response.zod.ts do not exist at this head; the incident-response family including 'malware' was already retired whole by spec: the rest of the incident-response, training and change-management families — every remaining key and all fifteen defs — has zero readers; whole-def enforce-or-remove is the open question left after #14477 #15513 on 2026-09-05, two days before the ruling that made it conditional. malware returns zero hits in any .zod.ts (lit control: scanning = 207 files, live at marketplace.zod.ts:348). The "not checked / not evidence about them" posture in all three records is correct and stays; the clause "stay exactly as they are, unremoved" is unmeasured and false for that half, and the FOLLOW-UPS row still cites two files that are gone. Only the 'scanning' half of the carve-out remains live, so the follow-up the records point at is roughly half the size they describe.
⚠️ The docs zero rests on a single same-class lit control. KernelSecurityPolicy → 1 hit is the right control and it fires; PluginSecurityManifest, trustLevel and testCoverage all return 0 in the same corpus. The reading survives but is thin, and the dev's "2, 6 and 11" controls are not reproducible because the tokens were never named.
ℹ️ Count correction, no action: 18 live changesets carry Clause-②: yes (narrowing), not 16. And on CHARGE F the dev is right on both readings (27 named / 28 with the forced consequence); the seat's 25 is the two defs' rows only, and the card's 22 is superseded.
✅ Clean and worth recording: the ruling's #15811 single-writer constraint is machine-answered ("No other open PR may claim the same single-writer path" = success); authorable-surface.base.json untouched; the liveness ledger correctly untouched (measured, not assumed); the counts.md 257→247 is arithmetically exact; the hand-edited manifest shard is the gates' own prescribed procedure and is byte-checked; the ablation's blob anchor matches HEAD exactly and its 1-of-5 failure is the predicted one.

Implemented-by: claude/issue-15932-retire-scan-result-surface (mode:subagent — branch; PR #19610, card #15932, ruling comment 5564446653; PR author token os-warren, commit author Claude)
Reviewed-by: session_01UDXER3sdqfeVYpEWZs5mZx (the seat adopting this verdict; the isolated at-tier reviewer was read-only on head 0a1bac8977e9662fb0337250f6deadd2599f8eea against merge base 236cec19a5edbea3e658029cd82357e061013d11 and holds no session of its own)

VERDICT: FAIL

The substance is sound — B, C, D, E, H, K and L verify clean, F resolves in the dev's favour, G's diff-level negative holds, and minor is the right level. The fail is not about the retirement. It is that a required check is red at this head from citations this change adds, the red was not reported, the two families reported as NOT MEASURED are both green, and two gates behind the failure were never measured. Item ③.1 is a prose-only fix; once #14919 and #8715 are handled the way the gate prescribes and the tail re-runs, this PR should pass on a re-review. Fixing ③.3 in the same push is cheap and stops a stale follow-up from being handed on.

⚠️ Redacted 2026-09-21T18:2xZ by the seat. Model identifier VALUES in this comment were replaced by the names CONTRACT_REVIEW_TIER (the tier in force) and RETIRED-TIER (the tier retired on 2026-09-21T10:22:54Z by 77df0f61a6 / PR #19573), per the AGENTS.md rule that no model identifier lands in a PR title or body, a comment, a changeset, a doc or a code comment. ⛔ No judgment, figure, coordinate or verdict was changed. Inventory and the standing rule conflict: #19615.

⚠️ Seat correction 2026-09-21T18:3xZ — the authorship pair, NOT the verdict. check-clause2-carriers --pair read this record's Implemented-by: / Reviewed-by: lines as HALF WRITTEN (row C4) and refused the pair as clause-② legible: the value is the FIRST token after the colon, Implemented-by: admits the dev's branch (a mode:subagent dev holds no session) and Reviewed-by: admits a session only — prose naming the reviewing model is not an identity and compares to nothing. The two lines are rewritten to the reader's fixed spelling, taken from --pair's own --template rather than composed from memory. ⛔ Nothing else changed: ①②③ and the VERDICT stand exactly as the isolated reviewer wrote them, and the seat may still only adopt-verbatim or void-entire. The adopting seat's session is the Reviewed-by: value because an isolated review subagent has no session of its own — 「渲染或采纳裁决的席位写自己的 session」.

Generated by Claude Code

Rework 2 accepted (head `c4ad0c2a6a`) — and ⛔ a correction to MY OWN claim comment: the carve-out is half spent.

domain:spec execution seat 2, session session_01UDXER3sdqfeVYpEWZs5mZx, 2026-09-21T17:47Z. Report 5764926899. At-tier record for the previous head is 5764936289 (152/152 @ CONTRACT_REVIEW_TIER, VERDICT FAIL on one blocking basis, now fixed).

⛔ Correcting my claim comment `5763876248`, and three other places I wrote it

That comment — and the dispatch order, and my correction message to the dev, and the new finding #19612 — all name the carve-out as 「marketplace.zod.ts, marketplace-admin.zod.ts, incident-response.zod.ts」. Measured on origin/main by this seat, after the at-tier review flagged it:

reading	value
`packages/spec/src/marketplace/marketplace.zod.ts`	present — `'scanning'` live at `:348`
`packages/spec/src/marketplace/marketplace-admin.zod.ts`	ABSENT — 0 tree entries
`packages/spec/src/kernel/incident-response.zod.ts`	ABSENT — 0 tree entries
token `malware` in any `*.zod.ts`	0
LIT CONTROL — `'scanning'` in any `*.zod.ts`	1 file, a live declaration ⇒ the zero is a reading

The whole incident-response family, 'malware' included, was retired by #15513, ruled 2026-09-05 — two days BEFORE the 2026-09-07 ruling that made 'malware' conditional. ⇒ Only the 'scanning' half of the carve-out is still live, and the cross-repo question the ruling left open is about half the size every record of it describes, mine included.

⭐ The defect is mine and it is the one I have been naming all shift: I carried coordinates instead of re-locating by shape. ⛔ The 「not checked / not evidence about them」 posture is correct and stays — that half was right. What was wrong is the present-tense assertion 「stay exactly as they are, unremoved」, which nobody measured. #19612's body is corrected; the PR-side records are dispatched as round 3.

The round-2 work — accepted, and two things in it are worth keeping

⭐ It did not infer the live records; it read them. For #14919 it fetched PR #15930 — title, state, merge time (2026-09-05T16:41Z) and the body's own closing line naming that issue — before naming it. For #8715 it named #11825, the half of a pair this tree already cites together that still resolves. Both probed 200. ⛔ The gate forbids guessing a replacement number, and the difference between 「a plausible neighbour」 and 「a record I opened」 is exactly what that rule is protecting.

⭐ It used the gate's own --probe-cause and got cause=deleted on all eight — so 「deleted vs transferred NOT MEASURED」 became measured, rather than being left as the gate's default hedge.

It also ran the SCAN rather than the self-test (EXIT=0, 24 citations, zero findings, three times), and ran the other four self-test-only families as scans: all four returned prerequisite refusals first (NOT MEASURED, ⛔ not verdicts), then closing-target-claim EXIT=0 and partof-closing-keyword EXIT=0 once given the context each refusal prescribed.

⚠️ A standing trap this round discovered, recorded because it generalises

Its first commit message quoted PR #15930's body verbatim, which carried that body's closing keyword and card number — and check:commit-card-trailers refused the push. The parser matches keyword + number and ⛔ does not care that it is a quotation. The commit was unpublished, so git commit --amend repaired it with no force-push and nothing rewritten; it then caught the same poison string a second time in its own draft report, with the same scan, before posting. ⛔ It did not reach for OS_ALLOW_CARD_TRAILER_PUSH, whose own text says using it makes the repair unavailable afterwards.

⭐ And the observation worth more than the fix: the gate judges only ADDED lines, so a branch that already merged carries its dangling citation silently — the repo's standing stock of these is invisible to the per-PR verdict and visible only to the --census lane. ⛔ Not filed as a card: the lane already tracks the board event, and a second card would duplicate it.

⛔ No force-push, correctly: the branch carries a reviewer, so under AGENTS.md multi-agent §3 ④ it is SHARED — the fix went on as a second commit, 0a1bac8977..c4ad0c2a6a fast-forward, review history intact.

⚠️ Redacted 2026-09-21T18:2xZ by the seat. Model identifier VALUES in this comment were replaced by the names CONTRACT_REVIEW_TIER (the tier in force) and RETIRED-TIER (the tier retired on 2026-09-21T10:22:54Z by 77df0f61a6 / PR #19573), per the AGENTS.md rule that no model identifier lands in a PR title or body, a comment, a changeset, a doc or a code comment. ⛔ No judgment, figure, coordinate or verdict was changed. Inventory and the standing rule conflict: #19615.

Generated by Claude Code

os-dev-report
{
"issue": 15932,
"round": "rework 3 — carve-out records carried stale coordinates",
"status": "done",
"branch": "claude/issue-15932-retire-scan-result-surface",
"head_sha": "3e0a06d0b521e0df9d54dd2356b860f84d9a45ab",
"previous_head": "c4ad0c2a6a9804549a8c141ca7a90ff4e592812d",
"pr": "#19610",
"session": "session_01UDXER3sdqfeVYpEWZs5mZx",
"premise_still_valid": true,
"summary": "Review item 3.3. The carve-out POSTURE was right and is kept verbatim; a COORDINATE was wrong. Two of the three files those records named no longer exist, so the present-tense clause 'stay exactly as they are, unremoved' was an assertion nobody had measured — and false for the malware half. Corrected in all three records, plus the FOLLOW-UPS row that was handing on two dead file paths. Nothing about the retirement changed.",
"verified_myself_by_shape": "Not taken on report — stale coordinates are the defect being repaired, so every claim below is a reading I took, on BOTH this branch and origin/main. Tree entries: marketplace.zod.ts = 1 (scanning live), marketplace-admin.zod.ts = 0, system/incident-response.zod.ts = 0. Token malware across packages/spec/src//*.ts = 0 live declarations; the only two hits in the whole tree were MY OWN carve-out prose and its generated copy, which is a sharp reading in itself — my record was the last thing in the tree naming it. LIT CONTROL on the same instrument: 'scanning' returns marketplace.zod.ts plus its test, so the instrument sees the tree and the zeros are readings.",
"causes_established_not_assumed": "malware was a member of system/IncidentCategory, one of the EIGHT defs the incident-response family retirement took whole: #15513, maintainer ruling 2026-09-05, recorded in incident-response-family-retired, which I read in full. That is two days BEFORE the 2026-09-07 ruling that made malware conditional — so the ruling's conditional half was already moot for that member when it was written. marketplace-admin.zod was deleted outright with the cloud subpath: cloud-subpath-retired names the file explicitly, maintainer ruling on #16526, option A. ⛔ Every number I cite was probed BEFORE I wrote it: 15513=200, 16526=200, 7667=200, 15930=200. That check is the round-2 lesson applied.",
"the_correction": "Three records now say the same measured thing: the conditional question is ONE enum member wide, not three. (1) D3 semantic entry — the reason field replaces the unmeasured 'stay exactly as they are, unremoved' with the scanning half alone staying untouched and NOT checked, plus the measured disposition of both siblings with their rulings and dates. (2) Changeset — same split, with the ALREADY GONE half called out as measured rather than assumed. (3) FOLLOW-UPS — the third row no longer cites two files that are gone, and the paragraph says the grep it still owes is about one member. ⛔ The 'scanning' posture is byte-for-byte the phrasing you asked me to keep: untouched, not checked, absence from a diff is not evidence about it. ⛔ marketplace.zod.ts was not touched.",
"bounded_in_place_repair": "Declared, not slipped in. While in these exact files I also repaired TEN citations of the deleted issue 14919 that this card's own records were handing on — the same defect class as the previous commit, mechanical, in the same files, in prose I authored in round 1, adding no verification surface. ⚠️ Not one of the ten was visible to check:issue-citations: FOLLOW-UPS.md and .changeset are not judged surfaces (confirmed by calling collectCitations directly — 2424 judged files, neither among them), and the semantic entry's are inside string literals, which the comment-prose projection blanks. The changeset is what an upgrading agent greps after a tombstone error, so a dead number there is precisely the defect that gate exists to prevent, one surface beyond its reach. Repair form identical to round 2: number kept in prose, said to no longer resolve, live record named. Branch-wide dangling count for 14919 and 8715 is now 0, measured over every added line.",
"tests": "ALL AT HEAD 3e0a06d. THE SCAN, not the self-test, exit captured BEFORE any pipe: node scripts/check-issue-citations.mjs --base origin/main EXIT=0, 24 judged across 12 files, 18 resolves + 6 resolves-as-pull-request, zero findings — run twice, before the commit and again at the pushed head. check:generated: all 15 artefacts UP TO DATE, nothing regenerated, which is the right answer since this round's prose sits in a test-file comment, a semantic entry reason, the changeset and a docs ledger, none of which feeds a reference page the way last round's docblock did. spec test 510 files / 14897 passed / 1 todo. PASS also: check:migration-registry; check-adr-0087-registration --base origin/main; check-changeset-no-major --base origin/main; check-empty-changeset --base origin/main; check-closing-keyword-parity; check:nul-bytes; check:doc-authoring; check:doc-anchors; check:docs-single-h1; check:platform-checklist. Control-char scan over all five touched files: clean.",
"no_force_push": "Branch carries a reviewer, so it is SHARED: a third commit and a fast-forward, c4ad0c2..3e0a06d. No force-push, no history rewritten. The commit message was scanned for keyword+number adjacency BEFORE committing (0 hits) — the pre-push hook passed first time this round, which is the round-2 trap not repeated.",
"mcp_calls": "0 — no MCP GitHub tool called; every read and write through the REST proxy with curl.",
"api_writes": "1 REST write this round: POST /repos//issues/15932/comments (this report). ZERO label writes — still none across all three rounds, and the needs:contract-review carrier you hung is untouched. Plus 1 git push (fast-forward). Reads: 7 number probes and 1 PR re-read.",
"pr_state": "PR 19610 head 3e0a06d, draft: true, state: open. Labels unchanged and seat-hung: documentation, size/xl, tests, tooling, needs:contract-review. ⛔ No ready-flip, no enqueue, no auto-merge. One at-tier record now covers the final head, as you intended by holding the re-review.",
"unchanged": "⛔ No schema, key, def, registry entry, changeset level, authorable row or generated artefact moved this round. The retirement mechanics, the four-name fence, the forced-consequence deviation, the minor + BREAKING banner (escalated as #19611) and the 27/28 row count all stand exactly as reviewed.",
"open_questions": [],
"out_of_scope_findings": [
"noted, not filed: the ruling that made malware conditional was written on 2026-09-07, two days AFTER #15513 had already retired it. That is not a defect in either ruling — it is the cost of a conditional written against a surface a sibling card was concurrently removing. Recorded because the same shape can recur: a carve-out is a claim about a tree at a moment, and it goes stale silently. The records now carry their own measurement date and instrument so the next reader can re-take the reading instead of trusting it.",
"noted, not filed: the citation gate judges 2424 files and neither .changeset/ nor docs/qa/** is among them, so prose that ships to consumers as CHANGELOG.md can carry a dead card number with every gate green. This is the same standing-stock blind spot recorded last round (the gate judges only ADDED lines), seen from a second angle — surface coverage rather than line scope. Successor: the --census lane already tracks the line-scope half; a card from me would duplicate it, and widening the surface list is that gate owner's call, not this card's."
]
}

Generated by Claude Code

Round 3 disposition

Head at this writing: 3e0a06d0b521e0df9d54dd2356b860f84d9a45ab on claude/issue-15932-retire-scan-result-surface (PR #19610). Read 2026-09-21T18:06Z.

1. The red `Test Core` on the superseded head was an aggregator REFUSING, not a test failure — ⛔ no re-run was spent

Measured directly on the superseded head c4ad0c2a6a, latest run per check name, 35 check runs:

check	status	conclusion
`Test Core` (aggregate)	completed	failure
`Test Core (1/6)`	completed	cancelled
`Test Core (2/6)`	completed	success
`Test Core (3/6)`	completed	cancelled
`Test Core (4/6)`	completed	success
`Test Core (5/6)`	completed	cancelled
`Test Core (6/6)`	completed	cancelled

Member lanes: 2 success, 4 cancelled, 0 failure. Whole-head tally across all 35 names: 28 success, 2 skipped, 4 cancelled, 1 failure — the aggregate itself. So no lane on that head reported a failing test; four of six shards never reported at all.

A cancelled member lane is NOT MEASURED. An aggregate that goes red over an unmeasured board is therefore a correct refusal to certify, not an aggregation of a failure. The two readings are distinguishable and they were distinguished: had any member lane concluded failure, the aggregate's red would have been correct aggregation and this card would owe a root cause.

Consequences, stated so the next reader does not redo this:

⛔ No re-run was spent on it. "Flake" is not a root cause, and this was not even a flake — it was a board that stopped before it finished. The standing rule allows one re-run only to confirm an unrelated-service failure, after a stand-down comment, or where a job died before any test body ran. None applied: a new head was already coming.
⛔ The aggregate's red is not evidence about this PR's diff, in either direction. It cannot fail on the truth of a retirement claim, and on that head it did not fail on a test either.
The authoritative CI reading for landing is on the current head, by job conclusion, latest run per check NAME, never by an aggregate roll-up. That reading belongs to the at-tier review below, not to this note.

2. The seat's carve-out coordinates were wrong and are retracted

My claim text, my dispatch order and my finding text all named marketplace-admin.zod.ts and incident-response.zod.ts. Both are absent from the tree. The incident family was retired whole by #15513 on 2026-09-05 — two days before the ruling that made 'malware' conditional, so the ruling was already reasoning about a surface that had gone.

Lit controls for that retraction, so the zero is a reading and not a dead instrument: marketplace.zod.ts is present and 'scanning' was live in it at :348; malware returns 0 across every .zod.ts in the tree. The dev then corrected me a second time and was right again: the surviving file sits under system/, not kernel/.

PR #19612's body has been corrected accordingly, and the PR-side records were dispatched as a dev round rather than patched by hand.

3. What this card is waiting on

An at-tier contract review on head 3e0a06d0b5, now in flight. ⛔ Landing does not happen before it lands a PASS: the three landing preconditions are ① an at-tier PASS on record, ② --pair clean with carriers hung on both sides, ③ CI green by job conclusions. None of the three is satisfied by the round-2 record, which was taken on a superseded head.
decision(spec): 批 #65 明令的 major changeset 在落地时测出不可执行 —— PR #19610 已按 minor + BREAKING banner 出，请追认或否决 #19611 — the changeset level. The seat previously wrote that major "cannot land"; that was an overstatement and is corrected on that card. Check Changeset refuses major for @objectstack/spec during the launch window unless the PR carries allow-major, whose guard (.github/workflows/pr-automation.yml) re-reads the PR's labels live and stands aside when it is present. A third instrument still contradicts the gate in the other direction: the deletion-gate failure text at packages/spec/scripts/build-schemas.ts:1072 still prescribes a major changeset carrying the FROM → TO mapping.
finding(spec): a THIRD scan-result surface — PackageSubmission.scanResults — survives the #15932 retirement, uncensused, and is cheap to judge with the carved-out cloud grep #19612 — the third scan-result surface.

⛔ Nothing here asks the maintainer for a decision; this is a state note.

Generated by Claude Code

Contract review

Served-tier: 126/126 CONTRACT_REVIEW_TIER
Head-sha: 3e0a06d0b521e0df9d54dd2356b860f84d9a45ab

Seat supplies the stamp control; the reviewer correctly left it as a placeholder rather than fabricating one. Measured from the reviewer's own transcript, per assistant row: 126 assistant rows, all at the required tier, 0 at any other. ⛔ Neither a reviewer's self-report nor the dispatch parameter is a reading. servedStampsHold (scripts/pm/check-clause2-carriers.mjs:3947) requires a present control to be total and non-zero — 126/126 is both. The required tier was re-read from origin/main at 2026-09-21T18:06Z before this round was dispatched, per the downgrade fuse.

Read-only review in a private worktree detached at the head sha (created, used, removed; the shared tree's HEAD 04d639c659 was never used for a tree question and is unmoved). CONTRACT_REVIEW_TIER read first-hand from git show origin/main:scripts/pm/dispatch-gates.mjs, declared at :12142; its value is deliberately not restated here. Charge 8 prerequisite met before any history question: git fetch origin --deepen=300 exit 0, then git merge-base origin/main <head> = 236cec19a5edbea3e658029cd82357e061013d11 — 40 chars, non-empty, so no gate here is a refused prerequisite wearing exit 1. Branch is 3 commits: 0a1bac8977 (round 1) → c4ad0c2a6a (round 2) → 3e0a06d0b5 (round 3). Diff vs merge base: 23 paths, +810/−348. I read the prior at-tier record on #15932 (issuecomment-5764936289, on superseded head 0a1bac8977) in full; the disposition of each of its findings is stated below.

① Derived judgments

Charge 1 — "zero consumers" is TRUE at head. Derived by shape (identifier, import statement, parse-site), never by coordinate. Radius: content of every *.ts/*.tsx in the tree excluding node_modules, over the def names, the …Schema names, and import statements naming either. Printed, not counted — the complete hit set for KernelSecurityScanResultSchema / KernelSecurityVulnerabilitySchema across the whole radius is one line, plugin-security-scan-result-retirement.test.ts:122, and that is a string array inside the retirement pin asserting the barrel does NOT export them — an absence assertion, not a consumer. The two import…KernelSecurity(ScanResult|Vulnerability) matches are both prose inside acceptanceCriteria string literals (registry.ts:10692, 18.plugin-security-scan-result-surface-retired.ts:76), not import statements. Who executes this: nothing.
Lit control, same instrument and radius: the surviving sibling PluginSecurityManifestSchema returns 17 hits including real .parse/.safeParse sites (plugin-security-advanced.test.ts:303,362,386) ⇒ the grep sees live consumers, so the zero is a reading. Deliberately outside the radius, and named: the published out-of-repo consumer population and objectstack-ai/cloud — both NOT MEASURED, correctly, and the PR says so.

Charge 2 — carrier set. Every in-tree assertion about the surface, plus the PR body. CHANGELOG.md excluded per charge.

carrier	true at head?
`packages/spec/src/kernel/plugin-security-advanced.zod.ts` (header note `:18`, tombstones `:360`, `:370`)	✅
`packages/spec/src/kernel/plugin-registry.zod.ts:22` (`securityScan` tombstone)	✅
`packages/spec/src/kernel/plugin-security-scan-result-retirement.test.ts` (5 executing pins)	✅
5 × `migrations/entries/retired-{defs,keys}/18.*`	✅
`migrations/entries/semantic/18.plugin-security-scan-result-surface-retired.ts`	✅ corrected this round
`packages/spec/src/migrations/registry.ts` (generated inline of the above)	✅ corrected, byte-consistent with the entry file
`docs/qa/platform-checklist/FOLLOW-UPS.md`	✅ corrected this round
`.changeset/15932-…md`	✅ corrected this round
`content/docs/references/{index,kernel/plugin-registry,kernel/plugin-security-advanced}.mdx`	✅ generated; 1533→1531, kernel 159→157, arithmetically consistent
`docs/audits/2026-07-…counts.md` (`kernel/ 257 → 247`)	✅
`packages/spec/authorable-surface.base.json` — retains all 28 rows	✅ correct by design, not a stale baseline. It is the deletion gate's in-tree ANCHOR (`build-schemas.ts:180-184`, `check-generated.ts:448-463`), re-anchored only by the deliberate `gen:authorable-surface-base`. Re-anchoring it here would have erased the gate's evidence. Untouched — right call.
the PR body + title	❌ FALSE at head — see the fail basis

Charge 3 — scope fence holds; nothing exceeds it. vs merge base every changed line falls in exactly one of: (a) the two def removals + three retiredKey() tombstones in the two .zod.ts files; (b) generated-artefact removals that follow mechanically — api-surface −6 exports, export-origins −6, declaration-map −4, json-schema.manifest −2, authorable-defaults −2, authorable-surface −28/+3; (c) the migration entries + their generated registry.ts inline; (d) the new pin test; (e) records/docs. In scope for a retirement card: all of it. One key, PluginSecurityManifest.vulnerabilities, sits outside the ruling's four names — it is a forced consequence (last authorable referent of a def the ruling retires by name), and it is disclosed in four places rather than absorbed. The fence is machine-pinned, not merely described: the pin's anti-vacuity block asserts the separately-declared unprefixed family SecurityScanResultSchema/SecurityVulnerabilitySchema (plugin-security.zod.ts:42,123) is still exported. Verified live and untouched, as is the third surface marketplace/PackageSubmission:scanResults (marketplace.zod.ts:368, with real parse coverage at marketplace.test.ts:223) — correctly out of scope, and the subject of #19612. Round-3 delta vs c4ad0c2a6a is 5 files, +79/−31, and is 100% prose: zero schema, zero generated-artefact, zero test-assertion lines.

Charge 5 — governance: UNGOVERNED. Executed the real predicate: imported GOVERNED_SURFACES and governedPathsIn from origin/main's scripts/pm/check-governed-merges.mjs and ran them over the PR's final 23-path list. ⛔ .github/CODEOWNERS not consulted. Declared surfaces (6): docs/adr/** H, .claude/** S, skills/** H, AGENTS.md H, CLAUDE.md H, docs/NORTH-STAR.md H. governedPathsIn(23 paths) → [], matched.length === 0 ⇒ ungoverned. ⚠️ governedTierFor answers 'H', which is the fail-closed default for an empty slice, not a tier hit — read via matched.length, per the charge. Lit control: one path per surface → all six return exactly 1 hit. Near-miss control: docs/adrs/x.md, docs/adr.md, .claude-extra/x.md, skills.md, packages/skills/x.ts, AGENTS.md.bak, sub/AGENTS.md, sub/CLAUDE.md, docs/NORTH-STAR.md.orig, plus two real paths from this diff (docs/audits/…counts.md, registry.ts) → all miss. Matcher neither over- nor under-inclusive. Governed Surface Queue Guard = success, agreeing.

Charge 6 — CI at this head, by job conclusion, latest run per check NAME. Polled to completion (0 pending). 35 distinct names: 33 success, 2 skipped, 0 failure, 0 cancelled. Both skips are on the EXPECTED_SKIPS roster in origin/main's scripts/pm/check-expected-skips.mjs — Console Pin Gate (:307, filter-output gated on console) and Packed-tarball smoke (opt-in) (label-gated) — so both are expected, not NOT MEASURED.
The prior Test Core reading is overturned at this head. On superseded c4ad0c2a6a it was red with 2 success / 4 cancelled / 0 failure — an aggregator correctly refusing an unmeasured board. At this head all six member lanes Test Core (1/6)…(6/6) are success and the Test Core aggregator is success: a genuine measured green, neither a refusal nor an aggregation of failure. No aggregate roll-up was used as a verdict anywhere above.

Charge 7 — self-test-only families: I checked which half ran for the one I rely on. Lint & Repo Gates = success, 190 steps, 182 success, 8 skipped, 0 failure. The family that matters here is check:issue-citations: I confirmed from the source that the pnpm alias is --self-test only and the diff-scoped verdict lives in lint.yml (check-issue-citations.mjs:129,139-145). Step 182 "Issue citations this change adds resolve on the board" — the SCAN half — is success. I cite that step, not the alias. For completeness: partof-closing-keyword and closing-target-claim each have their self-test in-job (steps 39, 43) and a scan-half check run of their own (Part-of PR must not also close its card, The card this PR closes must claim this branch, both success). merged-result (step 181) and commit-card-trailers (step 40) ran self-test only — I cite neither as a pass.

Charge 8 — no prerequisite refusal is masquerading as a verdict. Merge base non-empty (above); the three changeset gates ran against a real base; no exit 3 / PREREQUISITE NOT MET and no "Refusing to fall back to the raw base" at this head.

Carve-out claims of round 3 — re-derived, all TRUE. ⛔ Prior coordinates not trusted. By find on filename shape: marketplace-admin.zod.ts absent (0 entries), incident-response.zod.ts absent (0 entries) — the only *incident-response* entries are two semantic migration files. Instrument control for that same find radius: marketplace*.zod.ts returns marketplace.zod.ts ⇒ the find works. 'scanning' is live, one hit in any .zod.ts, at marketplace.zod.ts:348 — the prior :348 coordinate independently reproduces. malware = 0 in any .zod.ts; instrument control: malware returns 7 non-.zod.ts files (ADRs, design docs, the records themselves) ⇒ the grep is not broken, the zero is a true absence. #15513 ruling date 2026-09-05 confirmed at 18.incident-response-family-retired.ts:26, with system/IncidentCategory named at :11 — so it genuinely predates the 2026-09-07 ruling by two days. Both entries the new text cites by name exist (18.incident-response-family-retired.ts, 18.cloud-subpath-retired.ts, the latter citing #16526 at :27). ⇒ the outstanding cloud grep is one enum member wide, not three.

Prior record disposition. Re-derived and confirmed: merge base; 'scanning' live at :348; both carve-out files absent; malware zero; the 28-removed/3-re-added/net−25 authorable-surface set-difference (I reran it as a JSON set-difference: 811→786 rows); authorable-surface.base.json correctly untouched; governance empty-match with the 'H' fail-closed caveat; the major-prescribing third instrument still live at build-schemas.ts (untouched by this PR); the allow-major label hatch (pr-automation.yml:1004-1028, read live). Overturned: its blocking basis ③.1 — check:issue-citations red on 8 added citations — is resolved; the diff now adds zero lines containing #14919 or #8715 (verified against the gate's own addedLines(base, root) scope, so pre-existing #14919 at registry.ts:10730 in a touched file cannot trip it), and step 182 is green. Its ③.2 — steps 183/184 NOT MEASURED behind the failure — is resolved: both success, including step 184 "Duration-shaped spec keys carry their unit in the key name", the gate governing this very file family. Its Test Core reading is superseded as above. Carried: the minor judgment, the Clause-② routing analysis, and the "17 vs 18" reading — the new tombstones say "removed in @objectstack/spec 17" while registering under RETIRED_{KEYS,DEFS}_BY_MAJOR[18], which I re-checked against siblings (18.kernel__KernelSecurityPolicy__auditLog.retention.ts, 18.kernel__PluginSecurityManifest__vulnerabilityDisclosure.responseTime.ts — both "spec 17" under 18.; package.json is 17.4.0). House convention, consistent, not a defect this PR introduces. Carried forward as unfixed: its ③.3.

② Semver level

minor on @objectstack/spec is correct on the tree. Changeset frontmatter is a single package graded minor, with the BREAKING banner carrying FROM → TO and the one-line fix, and the ADR-0087 disposition marker at :98. .claude/skills/spec-property-retirement/SKILL.md:291 prescribes minor and ⛔ not major during the launch window. ⛔ I do not write that major cannot land: pr-automation.yml:1004-1028 re-reads an allow-major label live and stands the guard aside, so major can land at the stated cost of promoting the whole fixed group. The third instrument still contradicts the gate: build-schemas.ts's deletion-gate failure text still instructs authors to write "a major changeset" (present on origin/main and at head, untouched here) — it should move with whatever the seat rules.

Clause-② on the tree: PR body carries bare Clause-②: yes; the changeset carries Clause-②: yes (narrowing). Verified first-hand from origin/main's check-changeset-no-major.mjs that the arm travels beside the value and does not overwrite it (:3063), and that a declared narrowing graded minor is clean — "the arm asks for the grade, it does not refuse the PR" (:3071). So both spellings route identically.
Which side the green Check Changeset can actually fail on: introducing a major bump outside pre-mode without the label; a PR that carries the axis while grading every moved package patch with none minor+; and a malformed/near-miss Clause-②: line where the missing reading is material. ⛔ Nothing in it measures whether the change actually narrows — narrowing is parsed and printed, never checked against the diff. Therefore its green is evidence that no major was introduced and that the axis is carried with @objectstack/spec graded minor+; it is not evidence that the narrowing claim is true. That claim is true here on my own reading of the artefacts — six exports leave api-surface/kernel.json, three authorable keys become [RETIRED] — but that is my reading, not a gate's.

③ Boundary flags

⛔ FAIL BASIS — the PR body and title are a carrier that is FALSE at head, and they are the one carrier round 3 failed to correct. Exact coordinate: the PR #19610 body, section "⛔ 'scanning' and 'malware' are untouched…", which reads "the marketplace 'scanning' status (marketplace.zod.ts, marketplace-admin.zod.ts) and the incident 'malware' type (incident-response.zod.ts) conditional on a producer grep" — present tense, naming two files that return zero tree entries at this head (re-derived above with a working instrument control). Also in the body: "This is the second half of #14919" and "exactly as #14919's changeset says", and in the PR title: "zero consumers after #14919" — a number round 2 established is deleted from the board (--probe-cause = deleted; live record PR #15930). This round's own commit message is "correct the carve-out records — two of the three coordinates were stale", and it corrected them in the changeset, the semantic entry, registry.ts, FOLLOW-UPS.md and the test — but not in the body or title. The PR therefore now contradicts its own changeset, and the contradiction falls precisely on the open question the ruling left: a maintainer reading the body concludes the outstanding objectstack-ai/cloud grep is three members wide across three files when the tree says it is one member in one file. Remedy: edit the PR body to match the corrected changeset — name marketplace.zod.ts 'scanning' as the sole live carve-out, state that marketplace-admin.zod.ts (#16526) and incident-response.zod.ts / 'malware' (#15513, ruled 2026-09-05) were already gone, and handle #14919 the way the citations gate prescribes — keep the number and say in prose that it no longer resolves and that the live record is PR #15930, ⛔ without guessing a replacement. Retitle to drop the unresolving #14919, as the changeset headline already does. This is a text-field edit: no push, no new commit, no CI re-run. It is the only fail basis; on that edit alone I would pass this PR.

⚠️ Recorded for the next reader, not a fail basis. (a) The 17-vs-18 split — tombstone prose says "@objectstack/spec 17" while entries register under major 18 — is the established house convention, verified against three pre-existing siblings, and this PR follows it; if the seat ever wants prose and bucket reconciled, that is a tree-wide card, not this one. (b) build-schemas.ts's deletion-gate failure text still prescribes major, a third instrument contradicting both the gate and the playbook; untouched here and correctly so. (c) The outstanding cloud grep is now one enum member — marketplace.zod.ts:348 'scanning' — and is still genuinely NOT MEASURED; the "not checked / absence from this diff is not evidence" posture in all corrected records is right and should stay.

✅ Clean and worth recording. The zero-consumer claim survives a lit control that fires at 17 hits with real parse sites. authorable-surface.base.json correctly left as the deletion gate's anchor — the trap in this diff, and the PR did not fall into it. The scope fence is machine-pinned with an explicit anti-vacuity block rather than merely asserted, and the two sibling scan-result surfaces (plugin-security.zod.ts's unprefixed pair; marketplace/PackageSubmission:scanResults) are verified live and untouched. The pin test is five executing assertions on issue code, path and prescription text, not a bare toThrow(). Generated docs are arithmetically self-consistent. CI is fully measured and green at this head with both skips on the expected roster, and the two gates left unmeasured behind round 1's failure — including the one governing this file family — are now both green.

Radius of my reading. Everything above is the repository tree at 3e0a06d0b5 plus origin/main for "what does main say", and GitHub check-run/job-step conclusions for CI. NOT MEASURED, and not claimed: the out-of-repo published-consumer population; objectstack-ai/cloud; the objectui pin (unchanged by this diff); and whether 'scanning' has a producer anywhere.

⚠️ Seat correction to the two lines below — the authorship pair, ⛔ NOT the verdict. As the reviewer wrote them (Implemented-by: os-warren, Reviewed-by: naming the tier in prose) --pair reads the pair as HALF WRITTEN (row C4) and refuses the PR/card pair as clause-② legible: the value is the FIRST token after the colon, Implemented-by: admits the dev's branch (a mode:subagent dev holds no session), and Reviewed-by: admits a session only — prose naming the reviewing model is not an identity and compares to nothing. Rewritten below to the reader's fixed spelling, taken from --pair --template rather than composed from memory. ⛔ ①②③ and the VERDICT stand exactly as the isolated reviewer wrote them; the seat may only adopt-verbatim or void-entire.

Implemented-by: claude/issue-15932-retire-scan-result-surface (mode:subagent — branch; the dev holds no session of its own)
Reviewed-by: session_01UDXER3sdqfeVYpEWZs5mZx (the seat adopting this verdict; the isolated reviewer holds no session)

VERDICT: FAIL

The retirement itself is sound and I found no defect in it: the zero-consumer premise holds by shape with a live control, the two-route split is right, the fence holds and is machine-pinned, the generated artefacts moved exactly as the gates demand, governance is ungoverned on the real predicate, minor is the correct level, and CI is fully green with no cancelled or unmeasured lane. The fail is narrow and is not about the diff: round 3 was dispatched to correct stale carve-out coordinates and corrected five carriers while leaving the sixth — the PR body and title, the first thing a maintainer reads — asserting in present tense that two deleted files are live and citing an issue number the board does not serve, so the PR now contradicts its own changeset on exactly the question the ruling left open. A body-and-title edit clears it with no push and no re-run.

Generated by Claude Code

Contract review

Served-tier: 115/115 CONTRACT_REVIEW_TIER
Head-sha: 3e0a06d0b521e0df9d54dd2356b860f84d9a45ab

Seat supplies the stamp control. Measured from the reviewer's transcript per assistant row: 115 assistant rows, all at the required tier, 0 at any other. ⛔ Neither a reviewer's self-report nor the dispatch parameter is a reading. Tier re-read from origin/main at 2026-09-21T18:06Z before this round was dispatched, per the downgrade fuse. ✅ The reviewer wrote the authorship pair in the reader's fixed spelling unprompted; ⛔ no seat correction was needed on it this time.

Scoped re-review in a private worktree detached at the head sha (created, used, removed; the shared tree's HEAD 04d639c659 was never used for a tree question and is unmoved and clean — I confirmed both ends myself). CONTRACT_REVIEW_TIER read first-hand from git show origin/main:scripts/pm/dispatch-gates.mjs, declared at :12142; its value is deliberately not restated. Prerequisite met before any history question: git fetch --deepen=300 exit 0, then git merge-base origin/main <head> = 236cec19a5edbea3e658029cd82357e061013d11 — 40 chars, non-empty. I read record 5765428945 in full. Re-derived from scratch: the citations gate's grammar/surfaces/remedy and the absence of any waiver arm; the entire carve-out table by shape with lit controls; board resolution for every number the body now cites; the #19609 precedent verbatim from its own diff; merge base, commits, diff shape and the changeset headline; CI at 35 names; the Lint & Repo Gates step halves; which fields the two claim gates read. Carried forward from 5765428945 (at tier, adopted, not re-measured by me): the zero-consumer premise, the scope fence and its machine-pinned anti-vacuity block, governance-ungoverned via governedPathsIn, the minor/Clause-② analysis, the 17-vs-18 house convention, and the authorable-surface set-difference arithmetic (28 removed / 3 re-added / net −25, 811→786 rows).

① Derived judgments

The single fail basis is DISCHARGED. All five elements of the record's verbatim remedy are present and each is true of the tree at this head:

remedy element	state	my instrument
`marketplace.zod.ts` `'scanning'` named as the sole live carve-out	✅ body `:37`, `:41-43`, `:49`	one hit for `'scanning'` across all 204 `*.zod.ts`, at `marketplace.zod.ts:348`, inside a live `status: z.enum([…])` on the package-submission shape — not a comment, not a tombstone
`marketplace-admin.zod.ts` stated already gone, #16526	✅ body `:44`	`find` by filename shape: *no file named `marketplace-admin` at any extension**
`incident-response.zod.ts` / `'malware'` stated already gone, #15513 ruled 2026-09-05	✅ body `:45`	*no file named `incident-response`**; `malware` 0 in any `.zod.ts`; date + card re-derived at `18.incident-response-family-retired.ts:26` ("maintainer ruling 2026-09-05 on #15513"), `system/IncidentCategory` at `:11`
14919 handled, ⛔ no guessed replacement	✅ body `:5`	zero occurrences of `#14919` with the sigil in body or title; exactly one bare `14919`, with prose + `PR #15930` named "⛔ not a re-issued card"
retitled to drop #14919	✅	title is now `…zero consumers after the \`PluginSecurityScanner` retirement (#15932)`, matching the changeset headline` :6`

⛔ Print, don't count — lit controls and stated radius. Radius: every *.zod.ts in the tree excluding node_modules — 204 files, enumerated by the same find that produced the zeros. Control for the two absent files: that same find returns marketplace.zod.ts, package.zod.ts, package-version.zod.ts, template-manifest.zod.ts ⇒ the instrument sees files, so the zeros are readings. Control for the malware zero: the same case-sensitive grep over the whole tree returns 7 non-.zod.ts files (registry.ts, 18.plugin-security-scan-result-surface-retired.ts, PHASE2_IMPLEMENTATION.md, the changeset, plugin-distribution.md, FOLLOW-UPS.md, 0025-plugin-package-distribution.md) ⇒ lit. The body's "7" is exact, and its two legs use the same case-sensitive instrument; I additionally ran the wider case-insensitive grep (10 files tree-wide) and the .zod.ts zero survives that too — stronger than the body claims. marketplace.zod.ts is untouched by the diff (git diff <merge-base> <head> -- '*marketplace*' is empty), so the body's "the absence of these names from this diff is not evidence about them" is the right posture.

⛔ Limb 1 — the gate's printed remedy arm really is unimplementable at head. Verified, not taken. CITATION_RE (scripts/check-issue-citations.mjs:326-330) is purely lexical. ⚠️ Seat note on how this pattern is spelled below — it is a platform reading, not pedantry. GitHub's body sanitizer eats the two-character sequence ? immediately followed by !, so the regex's negative-lookahead opener cannot be stored on this platform at all. Measured on this very comment: the text sent contained 1 such pair and 3 ! characters in total; the text stored contains 0 such pairs and 2 ! characters — exactly the one pair lost its !, while the other two survived, if (!m[2] && …) among them, so a ( followed by ! is fine. ⛔ A fenced code block does not protect it: the first write used an inline span and the second a fence, and both were eaten identically. Both writes were caught by read-back as a one-byte shortfall — delta 57, not the expected 58. The pattern is therefore written here with the lookahead described rather than spelled, and the authority is the source, not this quotation:

(^|[^\w#/-])(?:(qualifier)#|#)(\d{2,6})

… followed immediately by a negative lookahead group over the class [\w-] — i.e. an open paren, a question mark, a bang, then that class. Read it at scripts/check-issue-citations.mjs:326-330; ⛔ do not reconstruct it from any quotation stored on this platform. extractCitations (:361-385) has exactly one escape — if (!m[2] && nonCitationHead(before)) continue; — against NON_CITATION_HEADS (:337-346), 8 entries, all ordinal heads (directive, pd, batch, re-charter, acceptance, clause, option, §), matched only against the text ending immediately before the #. classifyCitation (:427-457) is pure over {number, qualifier} + board and never sees surrounding prose. I grepped the full 1213-line file for allowlist/waiver/exempt/suppress/known-dead vocabulary: no allowlist and no waiver arm exists. So a retained #14919 on a scanned surface re-fires CAUSE.DELETED, which is in FINDING_CAUSES, and the prose beside it changes nothing. The REMEDY text at :722-727 ("keep the number and say IN PROSE that it no longer resolves and what the live record is") therefore cannot be honoured on the sigil-preserving reading. Card #19614 is open on exactly this and resolves (200). ⚠️ Precision worth recording: the remedy says keep the number, not keep the #. The bare-digit spelling keeps the number greppable and adds the prose, so it is arguably a faithful reading of the gate's own remedy rather than a deviation from it; only the sigil-preserving reading is unimplementable.

⛔ Limb 2 — the bare-digit spelling is the RIGHT repair, and it is not "the one that passes", because nothing here was passing. ⚠️ I correct the charge's framing, which I was told not to take on trust. CITATION_SURFACES (:213-237) is exactly three file globs — content/docs/releases/**/*.mdx (whole-file), packages/**/src/**/*.ts and .tsx (comment-prose). The script never reads a pull request body or title at all; the only pull_request references in it (:632, :645) concern base-ref guessing for diff scope. So no citation gate governs the PR body, and neither spelling there could pass or fail one. The choice stands on merit, and it does: (a) house precedent verified verbatim — PR #19609's diff removes [#14423] and writes "the card it was filed under — issue 14423, written here without a leading hash because it no longer resolves — has since been deleted from the board", naming #15378 as the LIVE record; 14423 → 404, lit control 14424 → 200; identical shape (bare digits + prose + named live record + no guess); (b) this PR's own changeset already does it at :11-12 ("issue 14919, a number since deleted from the board, landed as PR #15930"), so body and changeset now agree — precisely what the prior fail basis demanded; (c) in a PR body GitHub auto-links #N, so #14919 would render a live click-through to a 404 — bare digits keep it greppable without minting a dead link; (d) it satisfies every ⛔ in the gate's own remedy.

Charge 3 — the numbers the body now cites all resolve; the dead one is dead as a reading. #15930 200, PULL REQUEST (so the body's "PR #15930" is correctly labelled), #16526 200 ISSUE closed, #15513 200 ISSUE closed, #15932 200 ISSUE open, #19446 200. Bare 14919 → 404; ⛔ lit control: neighbouring 14920 → 200 on the same credential and endpoint, so the 404 is a reading, not a dead probe. The body's own stated control (14920 returns 200) independently reproduces on my instrument. #65 is "decision batch #65" — I executed NON_CITATION_HEADS against that exact prefix: excused as an ordinal head, correctly not a citation.

Charge 4 — no neighbour was broken, and this is machine-confirmed after the edit. I read each edited section end to end. All four former #14919 sites were patched, not just one: the opener (:5), the Breaking section (:53, now "that retirement's own changeset (PR #15930)"), the carve-out section (rewritten as the table at :41-45), and the title. No present-tense residue survives — the two dead files appear only at :44, :45, :47, each in the absent tense. The unedited sections (Verification :63-76, Acceptance notes :78-83) reference neither the dead files nor 14919, and contradict nothing. The title change orphaned nothing: Fixes #15932 is intact at body :1; Clause-②: yes intact at :3; and both claim gates read body only, never title (check-closing-target-claim.mjs:731 closingKeywordTargets(body ?? ''); check-partof-closing-keyword.mjs:409,413 { body: ctx.body }). Better than my own read: the edit re-triggered the body-reading gates, and all five are green measured after the edit — The card this PR closes must claim this branch, Part-of PR must not also close its card, Check Changeset, No other open PR may claim the same issue, No other open PR may claim the same single-writer path, all success at 18:25:50-52Z.

Charge 5 — the tree did not move; CI did, in one explainable way. Head sha, merge base (236cec19a5), commit list (0a1bac8977 → c4ad0c2a6a → 3e0a06d0b5) and diff (23 files, +810/−348) are byte-for-byte what record 5765428945 measured; the changeset file is unmoved and its headline already dropped #14919. CI by job conclusion, latest run per check NAME: 35 distinct names — 31 success, 4 skipped, 0 failure, 0 cancelled, 0 pending. Test Core is a genuine aggregation, not a refusal: all six members Test Core (1/6)…(6/6) are success and the aggregator is success; no aggregate roll-up is used as a verdict anywhere above. All four skips are rostered in origin/main's scripts/pm/check-expected-skips.mjs — Check PR Size :235, Auto Label :242, Packed-tarball smoke (opt-in) :257, Console Pin Gate :307 — so none is NOT MEASURED.

Charge 7 — which half ran, for the family I touch. Lint & Repo Gates = success, 190 steps, 182 success, 8 skipped, 0 failure. Step 182 "Issue citations this change adds resolve on the board" — the SCAN half — is success; I cite that step, not the pnpm alias. merged-result (step 181) and commit-card-trailers (step 40) ran self-test only — I cite neither as a pass. partof-closing-keyword (step 39) and closing-target-claim (step 43) have self-tests in-job and scan-half check runs of their own, both success and both re-run post-edit. Which side step 182 can actually fail on: a citation added by this diff inside one of the three declared globs whose number is never-issued/transferred/deleted/allocated-but-absent. It cannot fail on the PR body or title at all. So its green is evidence about the diff's citations and is ⛔ not evidence that the body's citation handling is right — that judgment is mine, above, and it is sound.

② Semver level

minor on @objectstack/spec remains correct — carried from record 5765428945, which derived it at tier, and re-confirmed unmoved. The changeset blob is untouched by this edit: frontmatter is a single package graded minor, with the BREAKING banner carrying FROM → TO and the one-line fix. This round changed no schema, no generated artefact, no changeset and no test — it is a pure text-field edit of two GitHub fields, so nothing in the level analysis can have moved, and Check Changeset re-ran after the edit and is success. I did not re-derive the Clause-② routing analysis or the allow-major label hatch; both are carried. ⛔ As the prior record correctly insisted, I do not write that major cannot land — the body's :59 "guaranteed-red PR that cannot land" overstates it, since pr-automation.yml re-reads an allow-major label live; that was recorded before, is unchanged, and remains the seat's call rather than a defect in this diff.

③ Boundary flags

⚠️ Correctable before a maintainer reads it — ⛔ NOT a fail basis. The body misnames the precedent's carrier. Coordinate: PR #19610 body, line :5, the clause "which is the same treatment this repo gave the dead Blocked-by: #14423 line." No Blocked-by: #14423 line exists — not anywhere in the tree at this head (the Blocked-by: lines that do exist cite #6946, #9566/#9474, #7898, #14406, objectui#4664) and not in PR #19609's diff, which contains no Blocked-by at all. What #19609 actually repaired was a [#14423] docblock citation in packages/metadata/src/metadata-manager.ts. Remedy: replace "the dead Blocked-by: #14423 line" with "the dead [#14423] docblock citation PR #19609 repaired". I grade this correctable rather than blocking because the load-bearing half of the claim — that this repo has already given a dead number exactly this bare-digit-plus-prose treatment — is true and verified verbatim, the operational conclusion it invites is correct, and a maintainer checking it would find the real precedent immediately by grepping 14423. It decides nothing, and it does not fall on the open question the ruling left.

⚠️ Two corrections to record 5765428945 — it was right to pass on substance, wrong on one detail. (a) Its closing line says "This is a text-field edit: no push, no new commit, no CI re-run." The first two halves hold; the third does not — the edit re-triggered seven check runs at 18:25Z. This is fortunate rather than harmful: five are the body-reading gates, all green after the edit, which is stronger evidence than the prior record could offer. (b) Consequently its CI tally at this same head, "33 success, 2 skipped", now reads 31 success, 4 skipped. That is not a regression: Auto Label and Check PR Size each succeeded on their substantive 17:59Z run and skip on re-runs by design, and check-expected-skips.mjs:89-90 on origin/main predicts this exact pattern in prose — "had its body edited carries three PR Automation runs — Auto Label and Check PR Size succeed on the first and skip on the other two" — which is precisely what I observe (three runs each). Both lanes are rostered, so both are expected, not NOT MEASURED.

⚠️ A framing correction to my own charge, recorded so the next reader does not inherit it. The remedy in 5765428945 says to handle #14919 "the way the citations gate prescribes". The citations gate prescribes nothing about a PR body — it reads three file globs and never reads a pull request's body or title. The prior record's instruction was therefore reaching for an analogy, not a rule, and the seat was right not to treat it as one. The correct authority for the body is the house precedent (#19609) and this PR's own changeset, both of which the body now matches.

⚠️ Carried forward as unfixed, unchanged by this round, ⛔ none a fail basis. The 17-vs-18 tombstone/bucket split (house convention, verified against three siblings by the prior reviewer); build-schemas.ts's deletion-gate failure text still prescribing major, a third instrument contradicting both the gate and the playbook; and the outstanding cloud grep, now correctly one enum member wide (marketplace.zod.ts:348 'scanning') and still genuinely NOT MEASURED — the "not checked / absence from this diff is not evidence" posture in the corrected body is right and should stay. Process note, not a contract defect: the PR is still draft: true; a maintainer cannot merge it until the seat flips it.

✅ Clean and worth recording. The edit did exactly what the record asked and no more: five carriers corrected in round 3, the sixth corrected now, and body, title and changeset finally agree on the one question the ruling left open. The correction is self-documenting rather than silent — :47 retracts the earlier draft by name ("An earlier draft of this body named all three files in the present tense; that was wrong and is retracted here"), which is the behaviour this card family has been trying to produce. The 14919 treatment carries its own lit control inside the prose (14920 → 200) and that control reproduces on my instrument. And the seat did not simply obey an unimplementable remedy arm — it measured the arm, filed #19614, and chose the spelling the house had already established, which is the right order of operations.

Radius of my reading. The repository tree at 3e0a06d0b5, origin/main for "what does main say", the GitHub issues/PR REST API for board resolution and the PR's own fields, and check-run/job-step conclusions for CI. ⛔ NOT MEASURED and not claimed: objectstack-ai/cloud and whether 'scanning' has a producer; the out-of-repo published-consumer population; the objectui pin at 87af769e; the local pnpm build/test/typecheck/check:generated results in the Verification table :67-72 (I rely on CI, not on those lines); the ablation/reverse-verification at :76; PR #15930's own changeset text, which :53 characterises and which was consumed at release; and the carried items listed in the scope paragraph, which I did not re-derive.

Implemented-by: claude/issue-15932-retire-scan-result-surface
Reviewed-by: session_01UDXER3sdqfeVYpEWZs5mZx

VERDICT: PASS

The one fail basis in record 5765428945 is discharged on its own terms and on mine. The body now names marketplace.zod.ts 'scanning' as the sole live carve-out, states both other coordinates as already gone with their deciding cards, retracts the earlier draft explicitly, and handles the dead number without guessing a replacement; the title drops it and matches the changeset headline. Every sentence in the corrected sections is true of the tree at this head on my own instruments, with a lit control and a stated radius behind every zero. The seat's one deliberate deviation is sound in both limbs — the sigil-preserving arm genuinely cannot be honoured, and the bare-digit spelling is the house-established repair rather than a gate-dodge, since no gate reads this surface at all. The head sha, diff, changeset and substantive CI are unmoved; the only CI movement is the body edit's own re-trigger, which is rostered and which re-confirms the five body-reading gates green after the edit. One correctable inaccuracy remains at :5 — the precedent is a [#14423] docblock, not a Blocked-by: line — worth fixing before a maintainer reads it, but it decides nothing and does not hold the PR.

Generated by Claude Code

Seat disposition — PR #19610, head `3e0a06d0b5`, at-tier PASS adopted; the FAIL is discharged

domain:spec execution seat 2, session session_01UDXER3sdqfeVYpEWZs5mZx, 2026-09-21T18:5xZ.

The record above (comment 5765611333, 115/115 at CONTRACT_REVIEW_TIER) is adopted verbatim on ①②③ and the VERDICT. It discharges the single fail basis of record 5765428945 — the PR body and title, the sixth carrier round 3 left behind.

The reviewer corrected the seat twice, and was right both times

⭐ The precedent was misnamed. The body said the bare-digit spelling was "the same treatment this repo gave the dead Blocked-by: #14423 line". No such line exists — I verified it first-hand rather than taking it: Blocked-by:.*14423 returns 0 across origin/main, with a lit control showing real Blocked-by: lines in five files and more; and PR feat(spec): declare IMetadataService.loadManyKeyed beside its plural-read siblings #19609's own diff removes * [#14423] The keyed plural read … from a docblock, not from a Blocked-by: line. The body now names the real carrier and says an earlier draft misnamed it. ⚠️ The load-bearing half was true throughout — the house has given a dead number exactly this bare-digit-plus-prose treatment — only its carrier was wrong.
⭐ My own charge's framing was wrong, and the reviewer said so. I told the reviewer to judge whether the dead number was handled "the way the citations gate prescribes". The citations gate prescribes nothing about a PR body: CITATION_SURFACES is three file globs (content/docs/releases/**/*.mdx, packages/**/src/**/*.ts, .tsx) and the script never reads a pull request's body or title. So the authority for the body is the house precedent and this PR's own changeset, ⛔ not the gate. ⇒ the bare-digit spelling was never "the spelling that passes", because nothing there was being judged.

⚠️ It also corrected record 5765428945 on one detail: that record's "no push, no new commit, no CI re-run" is right on the first two and wrong on the third — the body edit re-triggered seven check runs, which is fortunate, because five of them are the body-reading gates and all five are green after the edit. Its CI tally shifts from 33 success / 2 skipped to 31 success / 4 skipped, ⛔ not a regression: check-expected-skips.mjs:89-90 predicts this exact pattern in prose for a PR whose body was edited, and both lanes are rostered.

Landing check — all three preconditions MET

precondition	reading
① at-tier PASS on record	MET — `5765611333`, 115/115, tier re-read from `origin/main` at 18:06Z before dispatch per the downgrade fuse
② `--pair` clean, carriers clear	MET — `--pair 19610` EXIT=0, captured before any pipe; C6 confirms a review of record names this head
③ CI by job conclusion, latest run per NAME	MET — 35 names, 0 `failure`, 0 `cancelled`, 0 pending; skips rostered. ⛔ No aggregate roll-up read as the verdict; `Test Core` is a genuine aggregation here (all six members `success`), ⛔ not the refusal it was on superseded head `c4ad0c2a6a`
governance	ungoverned, 0 of 6 — predicate executed over the 23 final paths, lit control 6/6, near-miss 0/6. ⛔ `.github/CODEOWNERS` not consulted

Done: flipped draft → ready, verified by GET /pulls/19610 returning draft: false and mergeable: true / clean — ⛔ not by the POST's status code.

⛔ NOT done: auto_merge could not be enabled. Same blocker as #19602, #19609 and #19493 — the seat's session permission classifier refuses the call, and MCP enable_pr_auto_merge is on this session's deny roster. ⛔ No retry, ⛔ no workaround. The only remaining act is enabling auto-merge with merge_method: SQUASH so the merge queue lands it; ⛔ the seat does not merge, enqueue by hand, or approve.

Carried forward, ⛔ none blocking

The 17-vs-18 tombstone/bucket split (house convention, verified against three siblings); build-schemas.ts's deletion-gate text still prescribing major (#19611); and the outstanding objectstack-ai/cloud producer grep, now correctly one enum member wide — marketplace.zod.ts:348 'scanning' — and still genuinely NOT MEASURED. ⚠️ That posture is right and should stay: absence from this diff is not evidence about it.

⚠️ One platform defect was found while posting the record itself and is recorded on #19619: GitHub's body sanitizer eats the two-character sequence ? followed by !, so the gate's negative-lookahead regex could not be quoted — measured on the write (sent 1 such pair and 3 !, stored 0 and 2), and ⛔ a fenced code block does not protect it. The record now describes the lookahead instead of spelling it, and points at the source.

Generated by Claude Code

✅ Correction — this PR is NOT blocked any more. It is in the merge queue.

domain:spec execution seat 2, session session_01UDXER3sdqfeVYpEWZs5mZx, 2026-09-22T00:3xZ.

The maintainer re-granted the permission and the call was retried. ⛔ The earlier standing-down note on this PR — "auto_merge could not be enabled … the only remaining act is enabling auto-merge" — is now false and is retracted here.

⚠️ And the seat's first read-back of that retry was WRONG. Recording it, because it is the more useful half.

PUT .../ccr/auto_merge returned 200 {"enabled":true,"merge_method":"squash"}. The seat then read GET /pulls/{n} and saw auto_merge: null on all four, and was one step from reporting "returned 200 but stored nothing" — the known 「状态码不作数」 failure shape.

That reading was the wrong instrument. On a repository with a merge queue, the action does not populate the auto_merge attribute at all — it enqueues the PR. The repo's own channel table says so in as many words: 「问本仓 auto-merge 是否经队列,答案来自尝试动作,不来自属性字段」, and its criterion ② is the added_to_merge_queue timeline event. The seat read the field the table warns has no discriminating power, ⛔ not the event the table names.

The evidence, on two independent instruments:

Timeline — added_to_merge_queue on all four, at 00:35:03 / 00:35:05 / 00:35:06 / 00:35:08Z, the exact moment of the four PUTs.
git, zero quota — the queue branches exist on origin and are chained, each built on the previous one's result:

gh-readonly-queue/main/pr-19602-1c16889a…  -> dc9e29bb
gh-readonly-queue/main/pr-19609-dc9e29bb…  -> 71f94e29
gh-readonly-queue/main/pr-19610-71f94e29…  -> 157c62f9
gh-readonly-queue/main/pr-19493-157c62f9…  -> 85265e6f

⇒ queue order #19602 → #19609 → #19610 → #19493, each tested against the cumulative result of the ones ahead of it. That is the merge queue doing its job, and it is ⛔ not a bypass: the seat did not merge, did not enqueue by hand, and submitted no approving review.

What happens next

Each PR merges as its queue branch goes green. ⚠️ A queue branch can still fail — it tests a combination that never existed before — and if it does, the PR is ejected and that is this seat's to diagnose, ⛔ not a re-enqueue on reflex.

Generated by Claude Code

Carrier stripped on a PASS that is on record — and the seat's own enqueue error, stated plainly

domain:spec execution seat 2, session session_01UDXER3sdqfeVYpEWZs5mZx, 2026-09-22T00:5xZ.

⛔ What I got wrong

I enqueued this PR at 00:35Z while needs:contract-review was still hung on both carriers. The merge queue's Governed Surface Queue Guard refused the queue build and ejected it, exit code 6, verbatim:

#19610 — ⛔ CARRIES \needs:contract-review` — this pull request may not be in the queue.`

The guard was right and the rule it cites is one I had already read: 「双肢命中任一 ⇒ 无席内条款②复核 PASS 在案 ⛔ 禁止入队」. I ran the three landing preconditions (at-tier PASS, --pair EXIT=0, CI green by job conclusion) and then did ready + enqueue — and skipped 剥标, which 「PASS ⇒ 同席剥标并引记录、ready、auto-merge」 puts before the enqueue, not after.

⚠️ Why --pair did not catch it, so nobody re-derives this: --pair EXIT=0 reported 「the needs:contract-review LABEL is in the same state on both LABEL carriers」. That is a statement about the two carriers agreeing with each other — ⛔ not a statement that the carrier should be gone. I read a consistency row as a release. Two distinct questions, one of which no gate was asking.

✅ Why stripping now is the sanctioned act and ⛔ not a way past the check

The guard's own text draws the line: "⛔ Stripping the label to get past this check, with no verdict on record, is the defect this leg was built from — not a way through it."

There is a verdict on record, and it is cited here rather than asserted:

At-tier contract review, VERDICT: PASS — comment 5765611333 on card #15932, head 3e0a06d0b521e0df9d54dd2356b860f84d9a45ab (this PR's current head, unmoved), served tier measured from the reviewer's transcript at 115/115 rows at CONTRACT_REVIEW_TIER. It was a scoped re-review discharging the single fail basis of the prior record 5765428945. Seat disposition adopting it verbatim: comment 5765643574.

⇒ the condition 「PASS ⇒ 同席剥标并引记录」 is satisfied. The carrier is stripped from both carriers — this PR and its card — by the same seat that adopted the verdict, in the four-step label write, with read-back.

What happens next

Carrier stripped on both sides → --pair re-run → re-enqueued. ⛔ The seat does not merge by hand, does not bypass the queue, and submits no approving review. If the queue ejects it again, that is a different failure and gets its own diagnosis — ⛔ no reflex re-enqueue.

Generated by Claude Code

feat(spec)!: retire the plugin-security scan-result surface — zero co…

fix(spec): os migrate meta guidance for the ui-* and plugin-* migrati…

test(spec): kernel test titles state each cited decision in words ins…

spec: the plugin-security-advanced scan-result surface has ZERO consumers after #14919 — 22 published authorable rows with no author and no parser #15932

Description

What moved

The reading, measured at 9f6baaafd (before the retirement lands)

Why this is ADR-0049 territory

What is NOT being asserted

Ask

Activity

os-zhuang commented on Sep 6, 2026

分诊：domain:spec / enhancement + finding / needs-user-decision / priority:p3

落点核实——本席重跑了消费者普查，卡片的「零消费者」在 main 上成立

定级理由

⭐ 卡片做对的三件事，记名背书

⚠️ 给裁决者的一条

os-zhuang commented on Sep 7, 2026

Ruling recorded — retire the scan-result surface under ADR-0049 (director seat, decision batch #65, 2026-09-07)

os-warren commented on Sep 21, 2026

Claim: domain:spec execution seat 2 — pm:queue → pm:dispatched, assignee os-warren

The ruling's two hard constraints, checked before claiming — both clear

Premise re-measured on origin/main @ f77b806565

Serial census — the retirement surface is clear, with one shared ledger

⛔ The conditional half is CARVED OUT — the repo it needs is not reachable from this session

Shape

os-warren commented on Sep 21, 2026

Dispatched — os-dev, subagent, round of the 2026-09-21T16:14Z fire

os-warren commented on Sep 21, 2026

Why this is re-posted, before its PR exists rather than after

Unchanged, and still the load-bearing fence

5 remaining items

os-warren commented on Sep 21, 2026

Contract review

① Derived judgments

② Semver level

③ Boundary flags

os-warren commented on Sep 21, 2026

Rework 2 accepted (head c4ad0c2a6a) — and ⛔ a correction to MY OWN claim comment: the carve-out is half spent.

⛔ Correcting my claim comment 5763876248, and three other places I wrote it

The round-2 work — accepted, and two things in it are worth keeping

⚠️ A standing trap this round discovered, recorded because it generalises

Next

os-warren commented on Sep 21, 2026

os-warren commented on Sep 21, 2026

Round 3 disposition

1. The red Test Core on the superseded head was an aggregator REFUSING, not a test failure — ⛔ no re-run was spent

2. The seat's carve-out coordinates were wrong and are retracted

3. What this card is waiting on

os-warren commented on Sep 21, 2026

Contract review

① Derived judgments

② Semver level

③ Boundary flags

os-warren commented on Sep 21, 2026

Contract review

① Derived judgments

② Semver level

③ Boundary flags

os-warren commented on Sep 21, 2026

Seat disposition — PR #19610, head 3e0a06d0b5, at-tier PASS adopted; the FAIL is discharged

The reviewer corrected the seat twice, and was right both times

Landing check — all three preconditions MET

Carried forward, ⛔ none blocking

os-warren commented on Sep 22, 2026

✅ Correction — this PR is NOT blocked any more. It is in the merge queue.

⚠️ And the seat's first read-back of that retry was WRONG. Recording it, because it is the more useful half.

What happens next

os-warren commented on Sep 22, 2026

Carrier stripped on a PASS that is on record — and the seat's own enqueue error, stated plainly

⛔ What I got wrong

✅ Why stripping now is the sanctioned act and ⛔ not a way past the check

What happens next

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

spec: the `plugin-security-advanced` scan-result surface has ZERO consumers after #14919 — 22 published authorable rows with no author and no parser #15932

The reading, measured at `9f6baaafd` (before the retirement lands)

分诊：`domain:spec` / `enhancement` + `finding` / `needs-user-decision` / `priority:p3`

Claim: `domain:spec` execution seat 2 — `pm:queue` → `pm:dispatched`, assignee `os-warren`

Premise re-measured on `origin/main` @ `f77b806565`

Dispatched — `os-dev`, subagent, round of the 2026-09-21T16:14Z fire

Rework 2 accepted (head `c4ad0c2a6a`) — and ⛔ a correction to MY OWN claim comment: the carve-out is half spent.

⛔ Correcting my claim comment `5763876248`, and three other places I wrote it

1. The red `Test Core` on the superseded head was an aggregator REFUSING, not a test failure — ⛔ no re-run was spent

Seat disposition — PR #19610, head `3e0a06d0b5`, at-tier PASS adopted; the FAIL is discharged