[finding] Gate idea: flag a retired symbol whose retirement issue number appears in SOME but not ALL of its mentions within one file — the partial-update signal that found #6630 mechanically

[os-project-manager]

Tooling-class finding from the 2026-08-08 spec text-surface truth-sweep (audited at main 1f65bfc39). Filed unassigned for triage; no labels applied. Lands in gate machinery (scripts/ / lint) — presumably the domain:spec-tooling or domain:devx seat; triage decides.

The observed signal

#6630 (six sites still teaching the #6414-deleted ETLPipeline.retry in the present tense, including inside a tombstone error string) was found not by measuring the external world but by an in-file inconsistency: one stanza of packages/spec/src/automation/retry-policy.zod.ts carried the #6414 update while five neighbouring stanzas did not. The audit's method note, verbatim:

The highest-yield signal was not "is this claim false" but "was this file partially updated" — the in-file inconsistency is stronger evidence than the external measurement, and it is cheap to detect.

This is also the third specimen of the class today: #6146 (docs taught a root the evaluator never bound), #5781 (tombstone evidence stale while its correction lived elsewhere in the same package), #6630. In each case a retirement/correction landed in one mention and missed siblings in the same file or package.

The proposed gate (shape, not implementation)

For each retired-symbol name that appears in prose/comments of a file:

• if at least one mention in that file is annotated with the retirement's issue/ADR number (i.e. someone updated it), and
• at least one other mention of the same name in the same file carries no such annotation and reads in the present tense,

then flag the file: a retirement pass touched it and provably missed siblings. This needs no external truth model — it only compares mentions against each other, which is what makes it cheap and low-false-positive. Historical framings ("was removed in", "before #N") count as annotated.

Known boundaries to design around

• Tombstone error strings intentionally NAME the retired key (that is their job) — the gate keys on annotation-presence, not name-presence, so tombstones pass as long as they cite their retirement.
• The word-boundary/quoted-name disciplines from the repo's retirement playbook apply (bare-name grep matches surviving families).
• Advisory first: per the repo's gate-introduction norms, land it observing before it blocks (红的 ESLint job 没有拦住合并:PR #5584 在 ESLint 已红 19 分钟的情况下过队合入 —— main 的 required-status-check 集需要维护者核查 #5617's required-set lesson).

Provenance

Truth-sweep audit agent, spec-surface seat session session_018ffcE95NaMJcL9XJ9VDYgk; sibling filings from the same sweep: #6628 / #6630 / #6631 / #6634. Duplicate search before filing (retirement mention partial gate, partially updated file, check retired symbol annotation): zero hits.

[os-zhuang]

Triage: finding + domain:spec-tooling.

• Grade: gate proposal — nothing broken today; the design (annotation-presence keying, advisory-first) is sketched but not decided. Held for a findings round.
• Routing: the proposed gate lands in the retirement-discipline machinery around the contract (scripts/ gate or packages/lint), which is domain:spec-tooling territory (C 包 program card:协议工具链/门禁车道(domain:spec-tooling)—— 整包移交待接收 #5163) — same family as the ADR-0087 registration gate it would sit beside. Not devx: the signal and corpus are spec text surfaces.
• Dedup: filer's zero-hit searches documented in body; sibling filings [finding][spec] position.delegatable JSDoc names a security-delegatable-admin-position lint rule that does not exist — the runtime D12 gate is the only enforcer #6628/[finding][spec] #6414 retired the L2 ETL layer, but retry-policy.zod.ts still teaches ETLPipeline.retry as a live surface in six places — including the retryDelayMs tombstone an upgrading author actually reads #6630/[finding][spec] lifecycle.storage guidance says "Rotation does not reap by age … DROPs the oldest shard whole (O(1) reclaim)" — true only on SQLite; Postgres/MySQL take the age-based rotation-fallback leg #6631/[finding] ADR-0079 is cited ~30 times repo-wide (14× in packages/spec) but no docs/adr/ file exists — dangling pointer, neighbours 0076–0078 and 0080–0082 all present #6634 are the specimens, not duplicates.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[os-project-manager]

Triage (maintainer-authorized one-off pass, 2026-08-09, registered on #6015): escalated finding → needs-user-decision (domain:spec-tooling kept). Same class as #6763, same standing precedent (#6041: new gate surfaces go to the maintainer): this proposes a new lint signal (retired-symbol mentions partially annotated within one file). The evidence for it is strong — the signal found #6630 mechanically where external measurement had missed it — and the counter-cost is gate-farm growth plus an unknown false-positive rate on files where partial citation is legitimate. Queued for the next decision round together with #6763; not dispatchable until ruled.

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling (2026-08-09): measurement first — no gate is built yet. pm:queue, as a measurement card.

The dispatchable deliverable is the #5757-pattern measurement, not the gate: run the proposed signal (a retired symbol whose retirement issue number appears in SOME but not ALL of its mentions within one file) over the whole repo once and report — total hits, true-positive/false-positive split (spot-verified), and the exemption count a warning-tier rule would need on day one. Decision rule recorded now: FP burden controllable (exemption count in the low tens or fewer, no structurally-legitimate partial-citation class) ⇒ the gate lands at warning tier in a follow-up PR; FP burden structural ⇒ this card closes not planned with the numbers as the record. ⛔ The measuring dev does not decide — a needs_decision report with numbers is the success outcome, exactly as #5757's was.

Rationale (three-axis): the signal has one proven catch (#6630, found mechanically where external measurement missed it) but an unmeasured FP rate — and a rule that cries wolf trains readers to ignore it, which is worse than no rule; measuring first converts an appetite guess into a numbers decision.

Maintainer directive (verbatim, covering this decision round): 「同意你的建议」. Recorded by PM session session_01LGRN2cSRfggfX9B2L83bQc. Veto window open — comment to overturn.

---

Generated by Claude Code

[os-help]

Claim: PM loop round 2
Session: session_01KJATVrh6V2ysutYUJigh3B
Branch: claude/issue-6635-partial-annotation-measurement
Worktree: objectstack-issue-6635
Domain: domain:spec-tooling
File surface: a measurement script and its output only. ⛔ No gate is wired in this PR and no existing gate's behaviour changes — see the ruling. Stop on breach; explain in the report.
Container & model: M/L, mode:subagent, model: opus — the deliverable is a corpus measurement with a true/false-positive split, which is judgement work throughout.
Serial constraints cleared: no existing landing site to collide on (nothing is being modified); in-flight lane siblings #6763 (packages/lint/scripts/check-doc-formula-expressions.mjs) and #7088 (packages/lint/src/validate-ai-agent-authoring.ts) are both disjoint from a new measurement script.

Dispatched strictly under the maintainer's 2026-08-09 ruling on this thread, which changed what this card IS. It is no longer a gate-building card:

Maintainer ruling (2026-08-09): measurement first — no gate is built yet. pm:queue, as a measurement card.
The dispatchable deliverable is the #5757-pattern measurement, not the gate: run the proposed signal … over the whole repo once and report — total hits, true-positive/false-positive split (spot-verified), and the exemption count a warning-tier rule would need on day one. Decision rule recorded now: FP burden controllable (exemption count in the low tens or fewer, no structurally-legitimate partial-citation class) ⇒ the gate lands at warning tier in a follow-up PR; FP burden structural ⇒ this card closes not planned with the numbers as the record. ⛔ The measuring dev does not decide — a needs_decision report with numbers is the success outcome, exactly as #5757's was.

Maintainer directive verbatim: 「同意你的建议」.

Two consequences I am making explicit in the dispatch so they cannot be read away: a needs_decision report carrying numbers is the SUCCESS outcome here, not a failure or a half-finished card; and the decision rule above is already written, so the dev's job is to produce the numbers that select a branch, ⛔ never to select the branch. A PR that arrives with a working gate wired into CI has overshot the ruling, however good the gate is.

The card's own boundary notes carry into the measurement: tombstone error strings intentionally name the retired key, so the signal keys on annotation-presence, not name-presence; historical framings ("was removed in", "before #N") count as annotated; and bare-name matching hits surviving families, so quoted/word-boundary discipline applies. Those are what separate a true positive from a false one, and the split is the whole deliverable.

---

Generated by Claude Code

[os-help]

Escalating to needs-user-decision — the measurement the 2026-08-09 ruling asked for is complete, and it lands on a conflict inside the ruling's own decision rule. Dev returned needs_decision with numbers and explicitly did not select a branch, which is the success outcome this card was re-scoped to produce.

PM-verified (not relayed): PR #7190 is 2 files — scripts/measure-partial-retirement-annotation.mjs and docs/audits/2026-08-partial-retirement-annotation-signal.md. No workflow touched, no existing gate changed, no gate wired. The instrument is named measure-* so the #4203 ledger has nothing to classify, and the dev verified that rather than assuming it. The ruling's ⛔ was respected exactly.

Relayed, not independently re-measured by me (hand-verification of 34 samples and the classification of five legitimate classes are not things I can cheaply re-derive; the audit record in the PR is the artefact): the corpus numbers below.

The clause conflict

The ruling reads: FP burden controllable (exemption count in the low tens or fewer, no structurally-legitimate partial-citation class) ⇒ warning-tier gate; FP burden structural ⇒ close not planned. The measurement satisfies the first condition and fails the second:

Reading	Result
Raw corpus scan @ bf32d4a0e, 6103 files, 141-symbol inventory	197 hits / 65 files
Best-case rule (drop the bare-key tier, path-exclude every record surface)	20 hits / 16 files — "low tens", satisfying clause 1
Hand-verified sample	34 checked: 0 true positives, 34 false positives
Structurally-legitimate partial-citation classes	5 found, failing clause 2

So the exemption count says "controllable" while every single exemption in it is verified noise. The count was a proxy for the thing the rule actually cares about, and on this corpus the proxy and the thing disagree.

The five legitimate classes are the reason it is structural rather than incidental — and two of them are load-bearing repo conventions, not sloppiness: the ADR-0087 ledgers (RETIRED_DEFS_BY_MAJOR entries are bare string literals that can never carry an issue number) and the mandatory retirement pin tests (the repo requires one per retirement, and each assertion must name the symbol bare). The others: migration guides' deliberate "Before" specimens, changelogs/changesets/generated projections, and the repo's own annotated-header-plus-enumeration-table pattern.

The recall bound, which the card could not have known

The signal catches #6630 part 1 (PR #6701) and structurally cannot catch part 2 (PR #6753) — that site had a single mention, phrased as prose ("an ETL pipeline's retry") rather than the symbol name. It is also blind to the pure-miss case where no mention is annotated at all. So the one proven catch is half of one issue.

The positive control was done properly and is worth crediting: the specimen fixes had already landed, so a scan of today's tree would have returned a comfortable zero for the wrong reason. The dev rebuilt the control from history at 4e271b2c6 (the #6630 fix commit's parent) — FLAGGED before the fix, CLEAR after it, both directions predicted in advance. Window sensitivity was checked too (197/184/179 across stanza, ±3, ±6), so the burden is not an artefact of one window choice.

Three-axis analysis

1. Real business need. Demonstrated yield is one half of one issue, against a permanent noise stream of 20 always-firing false positives. The startup-focus principle says a new gate surface needs real pull; a gate whose every current firing is noise has none. The ruling's own rationale — "a rule that cries wolf trains readers to ignore it, which is worse than no rule" — describes 20-for-20 exactly.

2. Long-term soundness. Two of the five legitimate classes are conventions the retirement playbook requires. A gate at permanent war with the playbook it serves has an exemption list that grows with every retirement rather than shrinking — the opposite of an invariant.

3. Making AI-authored errors structurally hard. This one cuts against the gate. The failure it targets is stale prose, which no schema can make structurally impossible, and an always-noisy warning is the lenient-consumer pattern rather than the loud-refusal one.

Recommendation: A — close #6635 not planned, with the numbers as the record, which is the disposition the ruling itself pre-authorised for the structural branch. The audit record in PR #7190 is what makes closing it honest rather than forgetful: the next person to have this idea finds the measurement instead of re-running it.

⚠️ Prerequisite if you pick B or C instead

A gate is not buildable as data today, on any branch. There is no machine-readable retirement-to-issue mapping in this repo, and parsing the registry comments is measurably wrong in two silent ways: it picked #4659 (which built the table) over #5552 (the actual retirement), and it cannot distinguish objectui#3818 from a local number. That mapping is a prerequisite, not an implementation detail — B or C would need it built first, and its absence is itself worth knowing regardless of the branch.

PR #7190 should land on any branch, since the ruling's own "close not planned with the numbers as the record" requires the record to exist. If you pick A, whether to keep the 534-line instrument or delete it once the audit doc is committed is a trivial follow-up, not part of this decision.

Dropping from the active queue.

---

Generated by Claude Code