# Decide: Routing and the Acceptance Verdict

Phase 4. Turn the consolidated findings into two outputs: routed action items the human can act on, and an honest verdict on whether the epic met its acceptance criteria. This skill proposes; it does not auto-apply fixes or edit the project spec. The human decides what executes.

## Route each finding

Give every finding two independent dispositions:

- **What to do about this instance** — *fix now*, *defer*, or *accept as-is*. Fix-now findings become action items. Deferred findings carry enough context to be acted on later without re-investigation. Accepted deviations are recorded so later retros stop re-flagging them.
- **What would prevent the next one** — the upstream lesson: spec wording, story sizing, a missing convention or gate, or nothing. This is where a recurring finding becomes a process change rather than a one-off fix.

Findings from sub-agents or the team discussion are unverified reports, not established facts. Before an action item relies on one, re-check it against the primary source — reopen the file, the commit, the spec. A finding whose source does not hold up is dropped, not routed.

## Action items

Compile fix-now findings and process lessons into specific, owned action items. Each names what to change and who owns it. Two kinds are *proposed, not applied* in this version:

- **Remediation** — code fixes are written up as action items (or story-shaped work) for the normal dev loop to execute later. The retrospective does not run the dev loop itself.
- **Spec reconciliation** — where the as-built diverges from the spec, propose the reconciliation as an action item with the evidence attached. The human applies it to the project contract; an uncertain interpretation is never written into the spec automatically.

## Previous-retro follow-through

When a prior retro exists, check whether the action items it committed to were completed. Read `action_items` in `{implementation_artifacts}/sprint-status.yaml` and, for every entry belonging to an earlier epic that is not already `done`, record one line in the retrospective document's Previous-retro follow-through section:

- **How to address the item** — its `id`, exactly as the file spells it. Legacy entries written before ids existed have none; for those, record the item's `epic` (the integer in the file) plus its exact `action` text, character for character. One or the other is what Phase 5 needs to name the item at all.
- **Whether it landed** — with the source that shows it: the commit, the file and line, the test. An item you cannot point at is "no evidence found", not "not done" — the reader must be able to tell a checked item from an unchecked one.
- **The status it argues for** — `done` for a landed item, `in-progress` for one demonstrably underway, or nothing. A proposal, never a write.

That record is exactly what Phase 5's `--set-action-status` offer reads: the selector becomes the JSON, the evidence is what the user is asked to confirm, and the proposed status is written only if they confirm it. A run with no prior retro, or one whose `sprint-status.yaml` is unreadable or carries no `action_items`, records that there was nothing to follow through on — and which of those it was, so a missing file is never mistaken for "no outstanding items."

## The verdict

Judge the final state against the epic's declared acceptance criteria. If the epic declared none, profile the criteria from the diff and stories and mark the verdict as **profiled** rather than declared. Weigh verification results (the Phase 2 behavior check) and unresolved findings. Render one of:

- **Accepted** — criteria demonstrably met in the evidence, no blocking findings open, and **no unfinished stories** for this epic.
- **Accepted-with-open-items** — criteria met, but named findings remain deferred and tracked — still only when every story of this epic is `done`.
- **Rejected** — criteria not met, a blocking finding stands unresolved, **or any of this epic's stories is still not `done`**.

### Unfinished stories

`pending_stories` is authoritative for this epic's incomplete work, whichever mode produced it: sprint-status story keys in file order from `detect-epic`, or `stories.yaml` ids in list order whose artifact status is not `done`. When that list is non-empty:

- The **machine** verdict is **rejected**. Name every unfinished story key in the Acceptance verdict section as the evidence. Do not soften this to accepted-with-open-items: unfinished delivery is not an open finding about a finished epic — the epic itself is incomplete.
- Record the unfinished keys in Epic summary (interactive) or Assumptions (headless) as the Inputs section already requires.
- Headless runs have no human at the console: the document's verdict is **rejected** when `pending_stories` was non-empty. Interactive runs may still let a human override (rule 1 below) after seeing the list.

If the completeness check did not run (no readable `sprint-status.yaml`), do **not** render a rejected or accepted verdict from the absence of data — say the check was unavailable and weigh only the criteria and findings you have.

Three hard rules:

1. A human decision always overrides the machine verdict.
2. An epic that fails its criteria with **no** human decision is recorded as **not accepted** — never as silently accepted.
3. A non-empty `pending_stories` list makes the machine verdict **rejected**, including in headless mode.

The verdict and its evidence carry into the Phase 5 document.