---
key: docs.tracker-comment-retrofit
title: 2026-07-21 — Check the worked issue before the decision corpus; a closed tracker's comments need no retrofit (#524)
status: active
since: '2026-07-21'
supersedes: none
superseded-by: none
rule: 'When the knowledge exporter flags an over-cap tracker issue and excludes it from ingestion, triage its comments instead of assuming a retrofit is owed — and for each decision-shaped item check the **worked issue first**, because a tracker session comment is by construction a précis of the fuller closing record posted on the issue it narrates. Applied to #237 (111 comments) this yielded **zero** records, so server-management#642''s "a fact found only in a #237 comment" retrieval row has no valid subject and its interim target (an already-migrated record) is permanent.'
signals: 'tracker retrofit, over-cap issue exclusion, worked-issue-first, tracker-is-not-a-knowledge-store, #237 comment history · paths: `docs/tracker-retrofit-triage-237.md` · issues: #524, #237, #520, #521, server-management#642'
mechanics: '`docs/tracker-retrofit-triage-237.md` — method, per-comment classification table, totals, and the one candidate that was raised and disproved'
---

**Why the worked-issue-first ordering is the load-bearing part.** The session protocol that produced
#237's log required each session to post its full closing record on the issue it actually worked, and
*then* summarize across issues on the tracker. The tracker entry is therefore the lossy copy. A
comment that looks like a unique source is nearly always a précis of a primary the exporter already
indexes — so the instinct "the tracker is excluded, therefore its knowledge is orphaned" inverts the
real dependency. Checking the corpus first and the worked issue second wastes the effort; the reverse
order settles most items in one lookup.

**Worked example.** Comment [106/111] recorded that #497's music-video metadata reconcile deliberately
excludes Guids (not eager-loaded by `GetOrAdd`, so reconciling would duplicate-insert every scan) and
Directors (not add-persisted for `MusicVideoMetadata`). Genuinely decision-shaped, and genuinely
absent from the decision corpus — it survives a corpus-only check and looks like a retrofit target.
Issue #497's own closing comment states both exclusions with fuller reasoning, and the exporter
ingests it as `497.md`. One worked-issue lookup disposes of it.

**Scope of the claim — deliberately narrow.** The coverage test was applied to **decision-shaped
items only**. Items classified as cross-cutting lore were classified but *not* coverage-checked, and
that bucket is **not** empty: two facts from comment [109/111] were found to have no home anywhere —
`scripts/e2e-local.sh`'s readiness probe hanging on a reused config dir, and the troubleshooting
playback API's inability to exercise channel branding. Both were swept into the handoff lore by this
PR. So the correct statement is "no *decision-shaped* orphans," not "no orphans"; a tracker triage
that skips the lore bucket will leave real knowledge on the floor.

**A zero result is a legitimate outcome**, not evidence the triage was done wrong. What would change
the answer is a tracker whose sessions did *not* also write per-issue closing records — one where the
tracker genuinely was the primary rather than the narration layer.
