# Autodev: gate Step-9 entry on previous-cycle retro existence

**Task**: AZ-900_autodev_retro_existence_gate
**Name**: Codify the LESSONS rule — autodev must block cycle-N+1 Step 9 entry if `retro_<YYYY-MM-DD>.md` for cycle N is absent
**Description**: Cycle-3 retro Top-3 Improvement Action #2 and 2026-05-26 LESSONS entry both call for codifying a Re-Entry After Completion gate that verifies the previous cycle's retro file exists before incrementing the cycle counter. Cycle-2 retro was never filed; the orchestrator silently advanced to cycle 3 and all cycle-1 retro Top-3 actions sat invisible. This ticket codifies the gate in `.cursor/skills/autodev/flows/existing-code.md` § Re-Entry After Completion.
**Complexity**: 1 SP
**Dependencies**: None
**Component**: `.cursor/skills/autodev/flows/existing-code.md` (workflow doc only)
**Tracker**: AZ-900 (https://denyspopov.atlassian.net/browse/AZ-900)
**Epic**: (none — cycle-4 process housekeeping)

## Problem

LESSONS 2026-05-26 [process] entry:

> Cycle-2 retro was never filed. The autodev orchestrator silently auto-chained from cycle-2 Step 17 (if it ran at all) straight into cycle-3 Step 9 without producing `retro_<cycle2-date>.md`. As a result, cycle-1 retro's Top-3 Improvement Actions sat invisible across cycle 2 and were re-discovered, all three still undelivered, only at cycle-3 close.

Cycle-3 retro Top-3 #2 echoes the same recommendation.

The fix is a one-line check in the flow file that BLOCKS Step 9 entry for cycle N+1 unless `_docs/06_metrics/retro_<YYYY-MM-DD>.md` for cycle N exists.

## Outcome

- Future cycle-N → cycle-(N+1) transitions are gated: the autodev orchestrator refuses to enter Step 9 of cycle N+1 if no retro file exists for cycle N.
- Missing retros are surfaced at the session boundary, not 6 weeks later at the next cycle's close.

## Scope

### Included

- Edit `.cursor/skills/autodev/flows/existing-code.md` § "Re-Entry After Completion" to add a gate: before incrementing `cycle`, glob `_docs/06_metrics/retro_*.md` and verify a file dated after the cycle-N start exists.
- Define the BLOCK behavior: if absent, present a Choose A/B/C block:
  - **A)** Author the missing retro now (invoke `.cursor/skills/retrospective/SKILL.md` in cycle-end mode)
  - **B)** Stub a backfilled retro and proceed (with a leftover entry filed for proper backfill)
  - **C)** Abort and ask the user
- Add a corresponding bullet to `.cursor/skills/autodev/state.md` § "Session Boundaries" pointing at the new gate.

### Excluded

- Retroactively writing cycle-2 retro (separate ticket if user wants it; cycle-3 retro already covers cycle-2 trend deltas where data is on disk).
- Adding similar gates to greenfield or meta-repo flows (only `existing-code` has the cycle counter).
- Per-step retro check inside cycles (this gate fires only at the cycle boundary).

## Acceptance Criteria

**AC-1: Flow file gate exists**
Given `.cursor/skills/autodev/flows/existing-code.md`
When the "Re-Entry After Completion" section is read
Then it contains a step `Verify previous cycle's retro exists` BEFORE the cycle increment

**AC-2: Choose A/B/C block specified**
Given the gate triggers (no retro file found)
When the documented behavior is consulted
Then it specifies the three options (A: author now, B: stub + leftover, C: abort) with the standard Choose format

**AC-3: state.md cross-reference**
Given `.cursor/skills/autodev/state.md`
When the "Session Boundaries" section is read
Then it mentions the new retro-existence gate or links to the flow file's gate

**AC-4: Discovery rule**
Given the gate
When the file pattern is documented
Then the glob is unambiguous: `_docs/06_metrics/retro_*.md` with a date matching cycle-N's date range; the date-range derivation is explicit (cycle N start = last `implementation_report_*_cycle{N-1}.md` date; cycle N end = today)

## Constraints

- Pure workflow doc change — no source code, no tests.
- Must not break the existing greenfield-Done → existing-code Phase-B transition (greenfield → existing-code is a one-shot flow change with no retro requirement on first entry, since there is no previous cycle).

## Risks & Mitigation

**Risk 1: False positive on greenfield→existing-code transition**
- *Risk*: First cycle of an existing-code flow shouldn't require a previous-cycle retro.
- *Mitigation*: Gate condition includes `state.cycle > 1` — cycle 1 has no previous cycle.

## References

- LESSONS 2026-05-26 [process] entry: `_docs/LESSONS.md` § 2026-05-26 [process]
- Cycle-3 retro Top-3 #2: `_docs/06_metrics/retro_2026-05-26.md`
- Flow file: `.cursor/skills/autodev/flows/existing-code.md` § "Re-Entry After Completion"
- State management: `.cursor/skills/autodev/state.md` § "Session Boundaries"
