Retrospective for PR #710 ("fix(gates): narrow scan_retrospective_gate_drift.py's citation match with ssot.json corroboration", issue #709), merged 2026-08-03. Verified via pull_request_read: 2 commits (both pushed before the PR was opened), 0 review threads, 0 review/PR comments, 10 CI check runs (all success), no force-pushes observed. Zero repairs occurred between PR open and merge.
Refs #710, #709
ACM: not-applicable (tracking): this is a merge-retrospective issue (skills/merge-retrospective/SKILL.md), not a feature/fix/refactor -- per skills/drafting-an-acm-issue/SKILL.md's own Step 2, a tracking/umbrella issue is out of that skill's scope and carries no ACM shape; this issue's own Repairs section is its equivalent structure.
Step 0: carried-forward check
scan_retrospective_gate_drift.py mechanizes this step. Its scheduled run on main is still failing as of today (2026-07-26 through 2026-08-03, 9 consecutive failure runs per actions_list), consistent with issue #688's and #697's own prior observations of the same chronic backlog -- not re-attempted as a one-by-one audit here, per #688's already-recorded conclusion recommending a separate, dedicated backlog-reduction effort.
One update worth recording precisely, since this cycle's own PR directly changed this script's behavior: running the now-merged scanner live against origin/main (real GITHUB_TOKEN, full retrospective-labelled issue list) gives 149 total retrospective issues, 146 with no corroborated citation (threshold 20). Comparing against the bare-citation-only method this PR replaced (computed on the same live data): 116 of those 146 were already uncited under the old method -- i.e. already over threshold and part of the pre-existing chronic backlog #688/#697 already flagged, confirmed unrelated to this PR by actions_list history (the scheduled run has been red since 2026-07-26, 8 days before this PR merged). The remaining 30 are newly flagged specifically by this PR's new corroboration requirement (a commit cites the issue, but no .gitapex/ssot.json gate has a matching tracking_issue) -- by design, per issue #709's own intent: these are the same false-negative class as #314/#665, now correctly caught rather than silently cleared. Spot-checked: the 30 include issues like #191, #205, #218, #228 whose citations trace to later batch commits mentioning them incidentally, not a genuine implemented gate for that specific number.
Net effect: this PR made the reported count more accurate, not more broken -- but it does mean the already-failing scheduled job's FAIL count increases by roughly 30 rather than decreasing, which is worth the repo owner's attention given #688's and #697's recommendation for a dedicated backlog-reduction effort has not yet been picked up. Not proposing a new gate here; deferring to the existing #688 recommendation rather than filing a duplicate.
Repairs
None. Zero repairs occurred between PR open and merge: CI passed on first push for every check (10/10), no review comment required a follow-up commit, no force-pushes happened. Both commits on the branch predate the PR's creation (a bug found by a pre-merge independent adversarial-review pass, fixed and pushed before opening the PR -- not a repair within this PR's own review cycle).
Notes
This issue was auto-opened as a stub by the post-merge-auto-retro gate (issue #314, minimal slice of #140); this edit fills in the Repairs section per skills/merge-retrospective/SKILL.md as that stub's own body requested. A duplicate manually-filed issue (#715, same title, filed minutes after this stub without knowing it already existed) has been closed as a duplicate of this one. Per this skill's zero-repair fast-close path, requesting operator confirmation before closing this issue (see chat) rather than closing unilaterally.
Refs #710, #709, #688, #697, #314
Retrospective for PR #710 ("fix(gates): narrow scan_retrospective_gate_drift.py's citation match with ssot.json corroboration", issue #709), merged 2026-08-03. Verified via
pull_request_read: 2 commits (both pushed before the PR was opened), 0 review threads, 0 review/PR comments, 10 CI check runs (allsuccess), no force-pushes observed. Zero repairs occurred between PR open and merge.Refs #710, #709
ACM: not-applicable (tracking): this is a merge-retrospective issue (skills/merge-retrospective/SKILL.md), not a feature/fix/refactor -- per skills/drafting-an-acm-issue/SKILL.md's own Step 2, a tracking/umbrella issue is out of that skill's scope and carries no ACM shape; this issue's own Repairs section is its equivalent structure.
Step 0: carried-forward check
scan_retrospective_gate_drift.pymechanizes this step. Its scheduled run onmainis still failing as of today (2026-07-26 through 2026-08-03, 9 consecutivefailureruns peractions_list), consistent with issue #688's and #697's own prior observations of the same chronic backlog -- not re-attempted as a one-by-one audit here, per #688's already-recorded conclusion recommending a separate, dedicated backlog-reduction effort.One update worth recording precisely, since this cycle's own PR directly changed this script's behavior: running the now-merged scanner live against
origin/main(realGITHUB_TOKEN, fullretrospective-labelled issue list) gives 149 total retrospective issues, 146 with no corroborated citation (threshold 20). Comparing against the bare-citation-only method this PR replaced (computed on the same live data): 116 of those 146 were already uncited under the old method -- i.e. already over threshold and part of the pre-existing chronic backlog #688/#697 already flagged, confirmed unrelated to this PR byactions_listhistory (the scheduled run has been red since 2026-07-26, 8 days before this PR merged). The remaining 30 are newly flagged specifically by this PR's new corroboration requirement (a commit cites the issue, but no.gitapex/ssot.jsongate has a matchingtracking_issue) -- by design, per issue #709's own intent: these are the same false-negative class as #314/#665, now correctly caught rather than silently cleared. Spot-checked: the 30 include issues like #191, #205, #218, #228 whose citations trace to later batch commits mentioning them incidentally, not a genuine implemented gate for that specific number.Net effect: this PR made the reported count more accurate, not more broken -- but it does mean the already-failing scheduled job's FAIL count increases by roughly 30 rather than decreasing, which is worth the repo owner's attention given #688's and #697's recommendation for a dedicated backlog-reduction effort has not yet been picked up. Not proposing a new gate here; deferring to the existing #688 recommendation rather than filing a duplicate.
Repairs
None. Zero repairs occurred between PR open and merge: CI passed on first push for every check (10/10), no review comment required a follow-up commit, no force-pushes happened. Both commits on the branch predate the PR's creation (a bug found by a pre-merge independent adversarial-review pass, fixed and pushed before opening the PR -- not a repair within this PR's own review cycle).
Notes
This issue was auto-opened as a stub by the post-merge-auto-retro gate (issue #314, minimal slice of #140); this edit fills in the Repairs section per skills/merge-retrospective/SKILL.md as that stub's own body requested. A duplicate manually-filed issue (#715, same title, filed minutes after this stub without knowing it already existed) has been closed as a duplicate of this one. Per this skill's zero-repair fast-close path, requesting operator confirmation before closing this issue (see chat) rather than closing unilaterally.
Refs #710, #709, #688, #697, #314