review-feedback

Review Feedback Process

Run status gate (before reviewing content)

Every codex_execute/codex_continue/codex_review result carries schemaVersion: 1 and a status field:

• success — completion marker seen, event stream parsed cleanly: review normally.
• partial (isError false) — the stream ended without a completion marker or had parse errors: treat Codex's output as suspect. Verify from the diff field and by running the acceptance checks yourself; prefer re-running via codex_continue over reviewing an incomplete result.
• failed / aborted (isError true) — do not review; handle as a failed run (report to the user, ask before retrying).

unknownEvents and outputTruncated are informational only — they never downgrade status.

Severity levels

Level	Meaning	Action
CRITICAL	Security vulnerability, data loss, breaks existing behavior	Block — must fix this round
HIGH	Bug, unmet acceptance criterion, missing/false tests	Fix before task is done
MEDIUM	Maintainability concern, convention violation	Fix if the round is cheap; else note
LOW	Style/naming preference	Mention once; never spend a round on it alone

Improvements are non-blocking

Treat IMP-n items from review-dual as suggestions, not findings. Never let them gate task completion or receive their own codex_continue round. Append per-task items to .codex-flow/IMPROVEMENTS.md. Execute them only after user approval at the review-dual improvement decision gate.

Feedback format for codex_continue

Numbered, concrete, self-contained — Codex sees only what you send, not your reasoning:

Review findings to fix (address ALL, re-run the targeted tests for the touched files, do not change anything else):
1. [HIGH] src/api/users.ts:42 — `getUser` returns 200 with null body when the ID doesn't exist;
   acceptance criterion 2 requires 404. Fix the handler and add a test for the missing-ID case.
2. [MEDIUM] src/api/users.ts:15 — validation duplicates `validateId` from src/lib/validate.ts; use it.