review

Review the current implementation changes with this focus: $ARGUMENTS

Phase 0: Parse arguments and plan test execution

Extract flags from $ARGUMENTS before treating the rest as the review scope:

• --timeout <seconds> — override the default test timeout (default 300). Strip from scope.
• --skip-tests — do not run tests. Strip from scope. The review must still emit a # Test results section marked SKIPPED: --skip-tests flag.

Phase 1: Gather context

1. Check if .codex-handoff/latest.md exists. If it does, read it and use whatever context is available (acceptance criteria, constraints, scope boundaries, review focus, and especially any How to test / 如何测试 section) as a cross-reference when evaluating the implementation.
2. Inspect the current git state with read-only commands.
3. Review the relevant diff, changed files, and nearby code for context.
4. Do not modify the target repository's source code.

Phase 2: Discover and run tests

Unless --skip-tests was specified, run the project's test suite to ground the verdict in real signal.

Discovery order (use the first that succeeds):

1. A How to test / 如何测试 section in .codex-handoff/latest.md — extract the command(s) verbatim.
2. Repo-shape detection:
   • package.json with a test script → npm test
   • pyproject.toml or pytest.ini or setup.cfg with [tool:pytest] → pytest -q
   • go.mod → go test ./...
   • Cargo.toml → cargo test
   • Makefile with a test target → make test
3. Nothing detected → mark the test step SKIPPED (command unknown) and continue.

Execution rules:

• Run the command via Bash with a timeout of --timeout <sec> (default 300s).
• Capture exit code, wall-clock duration, and the last ~200 lines of combined output.
• Save the full log to .codex-handoff/history/YYYY-MM-DD-HHMMSS-validation.log. Create the directory if needed.
• Do not start servers, watch modes, or interactive commands. If the discovered command looks interactive or long-running, mark SKIPPED (not safe to auto-run) and note why.

Phase 3: Form the verdict

Combine the test outcome with the code review findings.

Test outcome	Code findings	Allowed verdict
FAIL (non-zero exit)	any	REWORK (hard rule — never APPROVE or MINOR_FIX on red tests)
PASS	no substantive issues	APPROVE
PASS	small fixable issues	MINOR_FIX
PASS	significant issues	REWORK
SKIPPED	any	any verdict, but the # Test results section must state why tests did not run, and the Next step must recommend running them before shipping

Prioritize bug-finding, regression risks, missing tests, and incorrect assumptions over style commentary. Match the user's language.

Phase 4: Write the review

The review must provide:

• A verdict: exactly one of APPROVE, MINOR_FIX, or REWORK
• A concise summary of what was implemented and how well it matches intent
• A # Test results section containing, at minimum:
  • Command: — the exact command run, or SKIPPED: <reason>
  • Exit code: — numeric exit code, or N/A when skipped
  • Duration: — wall-clock time, or N/A when skipped
  • Summary: — brief outcome line (e.g. 42 passed, 0 failed, or key failing test names); N/A when skipped
  • Log: — path to the saved validation log, when tests ran
• Concrete findings when issues exist; refer to file paths and symbols precisely
• Regression risks, if any
• Missing tests, if any
• A next step aligned with the verdict: APPROVE → ship or merge, MINOR_FIX → small follow-up changes, REWORK → revise before approval

If .codex-handoff/latest.md is available and contains acceptance criteria, include a handoff coverage assessment that marks each criterion as MET, NOT_MET, or UNTESTED.

If a category has no substantive content, say so briefly rather than inventing filler. Organize the review in whatever structure is clearest, but keep the verdict and # Test results prominent near the top so they are easy to find.

After generating the review, save it to .codex-handoff/history/YYYY-MM-DD-HHMMSS-review.md. Create the directory if needed.