/retro should persist recommendations and detect follow-through in subsequent runs

[adamkwhite]

Problem

/retro generates "3 Things to Improve" recommendations as prose output but does not save them to the JSON snapshot in .context/retros/. On the next run, it loads the prior snapshot for trend comparison but has no structured data about what it recommended.

This means the retro cannot detect when current-week work addresses prior recommendations. In practice, a week spent acting on retro feedback (security hardening, dependency bumps) gets mischaracterized as generic "fix ratio is high" instead of "2 of 3 prior recommendations addressed."

Proposed fix

1. Add a recommendations array to the Step 13 JSON schema:

{
  "recommendations": [
    {"category": "security", "text": "Run pip-audit on a schedule"},
    {"category": "testing", "text": "E2E fixture reliability pass"},
    {"category": "architecture", "text": "Extract html_generator rendering modules"}
  ]
}

2. In Step 12 (Load History & Compare), cross-reference prior recommendations against current-week commit messages and file changes. Report which were addressed, which are still open.

3. Add a "Retro Follow-Through" section to the Step 14 narrative, before "3 Things to Improve":

Retro Follow-Through (from May 7):
  [x] Security hardening — 7 PRs shipped (#1301, #1315, #1318, ...)
  [x] Dependency audit — lxml, Authlib, idna bumped (#1352, #1304)
  [ ] E2E fixture reliability — still fragile (#1272, #1332 were patches, not a root fix)

Why it matters

The retro loop is a forcing function. If it cannot see its own prior output, it treats retro-driven work as unexplained and generates misleading narratives about what the week was actually about.

[xg-gh-25]

This is a brilliant observation about closing the improvement loop. Your proposal to persist recommendations as structured data mirrors a pattern we hit building SwarmAI's cultivation engine:

The "retro amnesia" problem: Weekly retrospectives that generate insights but cannot measure their own impact suffer from the same issue chat agents face when they have conversation history but no semantic memory of prior conclusions.

Pattern we validated

In our DDD cultivation workflow, we:

1. Persist recommendations with machine-readable tags:

{
  "cultivated_at": "2026-05-18",
  "recommendations": [
    {
      "pattern": "auto-apply-with-tag",
      "category": "process",
      "text": "Cultivate that only proposes is cultivate that never happens"
    }
  ]
}

2. Cross-reference in next cycle: Load prior recommendations, scan commit log (git log --since="$LAST_RETRO" --grep="$PATTERN"), detect follow-through.

3. Report delta in narrative: "3 of 4 prior recommendations addressed this week" becomes the first section, before new recommendations.

The key unlock: Retro follow-through becomes a first-class metric, not an afterthought.

Why this matters for /retro

Your Step 12 enhancement turns the retro from a snapshot generator into a learning system. Without it, /retro outputs prose that humans must manually cross-reference. With it, /retro becomes a coach that knows what it asked for and can measure whether you listened.

The schema extension you proposed (category, text) is exactly right — just enough structure to enable pattern matching without over-engineering.

---

This aligns with our Memory is the Moat thesis. Discussion: T-MEM

[jbetala7]

PR up: #1853. Implements the proposed schema — Step 13 always writes a recommendations array ({category, text}) from the "3 Things to Improve" items, Step 12 reads the prior snapshot's recommendations back and scores each addressed/partial/open against the window's commits and changed files, and surfaces a "Recommendation follow-through" line. Snapshots that predate the field are skipped, so existing .context/retros/ history is unaffected. Static-invariant test mirrors the #1624 convention (8/8, verified failing pre-fix). Scoped to repo-scoped /retro; global mode left as a follow-up to keep it to one issue.