Scenario
In the autonomous pipeline (brainstorming → adversarial-design-review → writing-plans → … → post-merge-retrospective), post-merge-retrospective is supposed to score each adversarial-review finding as Prescient / Resolved-upfront / False-positive / Inconclusive. But adversarial-design-review does not persist a structured findings report. In practice the findings survive only as (a) inline design-doc revision notes or frontmatter, (b) commit messages, or (c) PR-thread comments.
So at retro time there is no scannable artifact to score against, and the retro author has to manually reconstruct findings from revision history and commit logs. Across multiple features, every retro I produced opened with a variant of: "No standalone adversarial-review report was committed; findings reconstructed from revision notes and the PR thread." That undercuts the whole point of the scored-findings table — the data it depends on was never durably emitted upstream.
Impact
- The retro's core deliverable (scored-findings table) is built from reconstruction, not record — unreliable, slow, and non-reproducible.
- No machine-checkable link between a finding and the commit/decision that resolved it.
Recommendation
- Have
adversarial-design-review write a structured report to a known path (e.g. docs/plans/<date>-<topic>-adversarial-review-<phase>.md) and commit it alongside the design/plan. Minimal schema: one row per finding with a stable finding ID, phase (design|plan), severity, summary, and a later-filled resolution (commit SHA / decision / accepted-with-reason).
- Reference that path from
post-merge-retrospective so scoring reads the report instead of reconstructing it.
- The stable finding ID lets the retro auto-correlate each finding to the commit or review comment that resolved it.
Scenario
In the autonomous pipeline (
brainstorming → adversarial-design-review → writing-plans → … → post-merge-retrospective),post-merge-retrospectiveis supposed to score each adversarial-review finding as Prescient / Resolved-upfront / False-positive / Inconclusive. Butadversarial-design-reviewdoes not persist a structured findings report. In practice the findings survive only as (a) inline design-doc revision notes or frontmatter, (b) commit messages, or (c) PR-thread comments.So at retro time there is no scannable artifact to score against, and the retro author has to manually reconstruct findings from revision history and commit logs. Across multiple features, every retro I produced opened with a variant of: "No standalone adversarial-review report was committed; findings reconstructed from revision notes and the PR thread." That undercuts the whole point of the scored-findings table — the data it depends on was never durably emitted upstream.
Impact
Recommendation
adversarial-design-reviewwrite a structured report to a known path (e.g.docs/plans/<date>-<topic>-adversarial-review-<phase>.md) and commit it alongside the design/plan. Minimal schema: one row per finding with a stable finding ID,phase(design|plan),severity,summary, and a later-filledresolution(commit SHA / decision / accepted-with-reason).post-merge-retrospectiveso scoring reads the report instead of reconstructing it.