how retros compound into product behavior

a retro that does not produce a durable artifact is noise. the bar for a retro inside the factory is not “the session wrote down what happened”; it is “the next session inherits at least one piece of behavior that would not have existed without this retro.” retros that clear that bar compound. retros that do not clear it are session diaries.

the kaizen loop the factory runs has four stages, each with a distinct artifact and a distinct half-life:

observation → retro entry → durable artifact → product change
   (transient)   (per-session)  (cross-session)    (permanent)

the first stage lives in retro-candidates.md, a flat append-only log. every time the same friction hits twice during a session, an entry goes in. the entry is informal — a header, a paragraph of what was observed, a paragraph of why it matters, a candidate fix. the file accumulates without ceremony. it is the kaizen capture surface between retros, not the retro itself.

### 1. Foreman commits land on wrong branch when sweeping branch switches

**Observed:** Foreman edited factory/188 files, then `git commit` landed
on local `main` (commit `505dda6`) instead of the factory branch —
because a parallel builder agent had switched the main worktree to
`main` underneath the foreman between Edit and commit.

**Candidate fix:** foreman should `git branch --show-current`
immediately before any `git commit` and abort if it doesn't match.

the second stage is the iteration retro itself. when the iteration closes, the retro cites the candidate log, clusters entries by theme, and promotes the highest-frequency patterns to one of four durable artifact types. those four types are the lever the loop pulls: each represents a different half-life of behavior change.

a feedback memory is the lever for behavioral lessons — when to take which action. the memory lives in ~/.claude/projects/<project>/memory/ and is loaded by future agent sessions automatically. iteration 12’s “when plans bounce 2+ times, direct-build using the red-team comment as spec” became feedback_direct_build_escape.md; subsequent sessions inherited the rule without re-discovering it. memories compound: each session adds zero, one, or two; the pile is the cross-session knowledge base.

a checklist artifact is the lever for procedural lessons — always do X before Y. the file is specs/retros/direct-build-checklist.md and it is read by the foreman before every direct-build invocation. iteration 12’s “rebase before opening a PR that shares files with recently-merged work” entry came from a real merge-artifact bleed-through; the checklist now prevents the same artifact on the next direct-build.

a code change is the lever for systemic lessons — the factory enabled the bug. the velocity-unlock retro produced five code PRs (#320, #322, #325, #330, #331), each of which fixed an orchestration bug that had been silently masking every PR for twenty consecutive sweeps. the retro identified the bugs; the PRs ship the fixes. once shipped, the entire class of bug disappears from future iterations.

an audit-guide entry is the lever for diagnostic lessons — a recurring class of mistake that the next debugger should know to check for. the silent-failure retro’s phase-state histogram is now run at the top of every sweep. iteration 12’s docstring-rot finding became “before committing a direct-build, grep docstrings and comments referring to the symbol you just modified.” these entries are heuristics, not rules — they bias attention toward the right inspection.

the loop produces compounding value because each artifact type has a different decay rate. memories outlive the session that wrote them; checklists outlive the iteration; code changes are permanent; audit-guide heuristics persist until the underlying class of mistake is engineered out. an iteration that produces one of each is an iteration that has translated learning into four different time scales of behavior change.

the discipline failure mode the factory has watched for is retros that produce zero durable artifacts. iteration 9 of the 2026-05-21 session shipped one PR and one retro; the retro identified no new patterns and produced no candidates for the kaizen log. that is a legitimate outcome — not every iteration produces new learning — but if three consecutive iterations produce zero artifacts, the team has stopped learning. the foreman watches that count.

a related failure mode is the candidate-without-promotion. an entry can sit in retro-candidates.md for several iterations before it earns promotion. that is fine for a while; the file is meant to capture before judging. but a candidate that has been observed across three retros and still not promoted to an artifact is a candidate the team has decided to live with — which is sometimes the right call and sometimes the sign of a blind spot. the meta-retro at the end of an iteration cluster is when those long-lived candidates get resolved one way or the other.

the second-order finding is that the corpus produced by the kaizen loop becomes content of its own. retros are commit-shaped; candidates are commit-shaped; memories are commit-shaped. all of them live in version control. when the host repo runs a documenter agent that promotes retros into devlog posts and engineering essays, the corpus becomes a publication pipeline without any additional writing labor. the retro that closed iteration 12 is the source material for at least four engineering essays — sizing rubrics, pair-pointing, the reviewer’s load-bearing role, the direct-build escape — none of which required a separate authorial pass.

the meta-lesson is that ceremonies are not overhead; they are the kaizen primitive that converts session-shaped experience into product-shaped behavior. retros without translation into artifacts are noise. artifacts without retros to feed them stop accumulating. the loop is small — four stages, four artifact types — but it is the mechanism by which a team gets sharper across sessions instead of merely shipping more code. an iteration that shipped fifty PRs and produced zero durable artifacts is an iteration that grew the codebase without sharpening the team. that is the failure mode worth catching at retro time, and it is the one the kaizen loop, run honestly, makes visible.