/flame-harness-retro

name: flame-harness-retro
description: Phase 11 — score the completed pipeline against Anthropic's 9 harness principles plus game quality, and write the retrospective.
argument-hint: ""
allowed-tools: [Read, Write, Bash, Glob, Grep]

flame-harness-retro

Phase 11 (final) of the flutter-flame-harness pipeline. Scores the completed pipeline against Anthropic's 9 harness-design principles and game quality criteria, then writes the retrospective report and sets the pipeline to `completed`.

All file schemas (`config.md`, `state.md`, `build-log.md`, `pipeline-log.md`) and the phase transition table are defined in `docs/harness-protocol.md` — that document is the single source of truth (§1 `config.md`; §2 `state.md` keys; §3 `contract.md` layout; §4 handoff layout; §5 feedback layout; §6 log schemas; §7 `retro → complete → status=completed` transition). Do not redefine schemas here.

**Boundary:** This is the terminal phase. After writing `docs/harness/retro.md` and updating `state.md`, no further skill dispatch occurs. The pipeline ends.

**Prerequisites:** `flame-harness-resume` dispatched this skill with `next_role: retro`; `state.md` shows `current_phase: retro`.

---

Inputs — Read All Harness Artifacts

Before scoring, load all available evidence:

1. `docs/harness/config.md` — extract `app_slug`, `app_name`, `max_rounds`, `strict_mode`, `skip_research`, `skip_admob` (per protocol §1). 2. `docs/harness/state.md` — confirm `current_phase: retro`; read `current_round`, `resume_attempts` (per protocol §2). 3. `docs/harness/contract.md` — review the negotiated Hard Gates and Functional Criteria, and the final `Status: AGREED` line (per protocol §3). 4. `docs/harness/handoff/` — read all `round-N-gen.md` files; note what was built / fixed per round, and any self-assessment failures (per protocol §4). 5. `docs/harness/feedback/` — read all `round-N-qa.md` files; note PASS/FAIL verdicts, evidence commands run, and specific failed criteria (per protocol §5). 6. `docs/harness/build-log.md` — read the full build log table (per protocol §6). 7. `docs/harness/pipeline-log.md` — read the full pipeline event log (per protocol §6). 8. Git log: run `git log --oneline` to count commits and identify rework patterns.

---

9 Principles Scoring

Score each of the 9 harness-design principles on a **1–5 scale** with evidence drawn from the harness artifacts loaded above. Cite specific files, round numbers, or log entries as evidence.

Principle 1 — Generator-Evaluator Separation

> Generator builds; Evaluator judges. Roles must never conflate — the Generator does not approve its > own work, and the Evaluator does not write code.

**Evidence to check:** handoff files authored by generator; feedback files authored by evaluator; no code edits in QA feedback files; no self-PASS verdicts in handoff files.

**Score guidance:**

• 5 — All handoffs were authored by the Generator; all QA by the Evaluator; zero role crossover.
• 3 — One instance of the Evaluator proposing a code fix inline rather than filing a failed

criterion.

• 1 — Evaluator wrote code or Generator issued its own PASS.

The generator-evaluator separation principle is the most fundamental harness invariant. A breach here invalidates all downstream verdicts.

Principle 2 — Evaluator Skepticism

> Evaluator must run the game and observe actual behaviour before issuing any verdict; code-review- > only PASS is prohibited.

**Evidence to check:** `feedback/round-N-qa.md` Evidence tables — were `flutter analyze`, `flutter test`, cold-start iOS, cold-start Android, and FPS check all run? Were screenshots captured? Did any feedback file issue PASS without running the game?

**Score guidance:**

• 5 — Every QA round shows a complete Evidence table with run commands + actual outputs / screenshot

paths; no PASS issued without running the game.

• 3 — One round shows a partial Evidence table (e.g., FPS check omitted).
• 1 — At least one PASS was issued based on code review alone.

Principle 3 — Contract Negotiation Quality

> The contract is negotiated (not dictated) before coding begins. Hard Gates are non-negotiable; > Functional Criteria are game-specific and agreed bilaterally.

**Evidence to check:** `contract.md` — are all 8 Mandatory Hard Gates present (per protocol §3)? Were Functional Criteria added and marked AGREED? Was there back-and-forth before AGREED, or was the contract accepted without review?

**Score guidance:**

• 5 — All 8 Hard Gates present; game-specific Functional Criteria added; AGREED status set after

bilateral review.

• 3 — Hard Gates present but Functional Criteria were thin or generic.
• 1 — Contract accepted without review or Hard Gates were missing.

Principle 4 — File-Based Handoff

> Every inter-phase communication travels through a named file in `docs/harness/`. No out-of-band > instructions in chat messages or inline code comments.

**Evidence to check:** `handoff/round-N-gen.md` and `feedback/round-N-qa.md` exist for every round in `build-log.md`; pipeline-log events reference file writes; no phase-to-phase communication happened only in chat.

**Score guidance:**

• 5 — Every handoff and feedback round has a corresponding file; build-log and pipeline-log are

complete.

• 3 — One round's handoff or feedback file is missing or incomplete.
• 1 — Multiple rounds have no corresponding file.

Principle 5 — No-Sprints / Single-Build

> The Generator completes the full game in one continuous build session per round. No iterative > sprint cycles within a round; no partial deliveries labelled "Phase 1 of N".

**Evidence to check:** handoff files — does each `round-N-gen.md` claim a complete, runnable game? Build-log round count — how many generator rounds were needed? Were any partial deliveries noted?

**Score guidance:**

• 5 — Each generator round delivered a complete, runnable game; no partial deliveries.
• 3 — One round ended with a partial delivery that required a follow-up round