IR-003 — findings retrofit scope: fix forward from the convention date, no mandated bulk retrofit

Date: 2026-09-14 Status: closed Supersedes: none Superseded-by: none — current

Context

docs/decisions/2026-09-11-findings-status-line-convention.md ratified the Status:/Closed-by: convention for findings (mirroring decisions) and the walkFindings/extractStatus code change that reads it, but explicitly left the retrofit question open: what happens to every finding written before the convention existed, all of which are unstamped by construction. irina/tickets/IR-003-findings-retrofit-scope-decision.xml names three candidates and requires a dated ruling before any code changes — this doc is that ruling.

Measured, not estimated, before proposing an approach: every finding in this repo’s own docs/findings/ is unstamped — 75 of 75, checked directly (grep -L for a Status line), not assumed from the convention doc’s “likely hundreds+” guess. This repo is one of ~9 registered consumer repos; the real fleet-wide count is almost certainly in the low hundreds, unmeasured beyond this one repo. That number is the load-bearing fact for which of the three candidates is realistic today.

A second, real gap found while drafting this doc, not yet fixed: cli/src/verbs/diagnose.ts’s recent_findings mapping (line ~108-110) strips status/closed_by before they ever reach diagnose --json — walkFindings() computes both per the ratified convention, but the verb that exposes it to irina/compute-drain-time.mjs silently drops them. Confirmed live: diagnose petrova-codes --scope findings --json returns status: undefined for every entry, regardless of what’s actually in the file. This is a mechanical fix, not a policy question — noted here so C2’s implementation isn’t a surprise, not decided here.

Decision

Option (c): accept-unparseable-as-baseline, fix forward from the convention’s own date (2026-09-11).

• A finding dated on or after 2026-09-11 (this repo’s own filename-timestamp convention, same proxy decisions already use) is read for its status/closed_by and counted in the findings axis of the drain-time metric exactly like a decision is today: open/closed count, unparseable (present but unrecognized) is excluded and reported separately, same fail-closed rule as decisions.
• A finding dated before 2026-09-11 is excluded from the findings axis entirely — not counted as open, not counted as unparseable, not silently defaulted to anything. It is out of scope by design, not an error the metric should keep surfacing forever.
• No bulk-pass retrofit is mandated by this doc. At 75/75 unstamped in this repo alone, a fleet-wide bulk pass today means making an open/ closed/superseded judgment call on what is almost certainly several hundred findings across every registered repo, written over months by different sessions with no shared memory of each one’s real current state — exactly the “manufacturing governance rather than recording it” failure mode host/src/estate/domains.ts’s own generator already refuses to commit for a different artefact. That is real, judgment- heavy, cross-repo work an agent should not do unsupervised in one pass, and a human doing it by hand at this volume is its own multi-week project this doc does not schedule.
• Lazy stamp-as-touched is not ruled out, just not mandated. Nothing here prevents a human or a future agent from adding a Status line to an old finding the next time it’s genuinely touched (cited, superseded, closed by a real act) — that’s just normal authoring discipline, not a scheduled retrofit project.

Why not the other two candidates:

• Lazy stamp-as-touched alone doesn’t unblock the metric on any useful timescale — most of the 75 unstamped findings in this repo will never be “touched” again; the metric would stay artificially incomplete indefinitely with no visible mechanism moving it forward.
• Bulk pass now is the real “manufacturing governance” risk named above, at a fleet-wide scale this doc has no evidence is even bounded, let alone tractable in one act.

Consequences

• irina/compute-drain-time.mjs gains a findings axis, gated on --since 2026-09-11 semantics for findings specifically (decisions keep their existing unrestricted --since) — a mechanical follow-up PR, not decided further here.
• cli/src/verbs/diagnose.ts’s recent_findings mapping must be fixed to include status/closed_by before that follow-up can do anything real — noted above, fixed as part of the same mechanical PR.
• The drain-time metric’s findings axis will read as thin (few or zero findings counted) for a while after this ships, simply because so few findings postdate the convention yet. That is the expected, accepted shape of “fix forward” — not a bug in the implementation.
• A future decision doc, made once real post-convention volume exists to judge by, can revisit whether a scoped bulk-pass (e.g. only this repo, only findings still actually relevant) is worth doing. Not scheduled or implied by this doc.

Alternatives considered

See “Why not the other two candidates” above — kept together with the decision rather than duplicated, since the reasoning is the same evidence (the measured 75/75 backlog) read two ways.

References

• irina/tickets/IR-003-findings-retrofit-scope-decision.xml
• docs/decisions/2026-09-11-findings-status-line-convention.md
• docs/findings/20260911-1205-finding-status-not-modeled-in-repo-walker.md
• cli/src/repo-walker.ts (walkFindings, extractStatus)
• cli/src/verbs/diagnose.ts (the recent_findings gap found while drafting this doc)
• irina/compute-drain-time.mjs

Sign-off

• Subagent: claude-sonnet-5 (session_01JkTN6nZ3ZN8RquREgLesY2)
• Human: alex@devarno.com

Countersigned by human:alex@devarno.com on 2026-09-14 — commit 092bd06c (this file’s creation commit) is authored by the human directly, per docs/decisions/2026-09-05-proxy-countersign-retired.md’s post-retirement definition. Line added retroactively by the agent as scribe.