fix: show REPEAT_ERROR in replay verdicts

[ruslanlap]

Found by an atlassian-engineering skill review of #1: replay (the debug surface for tuning thresholds) only surfaced LOOP/OSCILLATION verdicts — REPEAT_ERROR was invisible there.

• reuse update_repeat_streak in replay_file for a cross-line sticky streak (same semantics as watch mode)
• new verdict ⚠ REPEAT_ERROR + exit 1
• replay --repeat-n N flag (matches watch)

TDD: failing test test_replay_detects_repeat_error first, then fix. 59/59 green; verified live: 3 consecutive failed bash → verdict on line 3, --repeat-n 5 → quiet.

---

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔴 Replay command crashes on every transcript

For any existing transcript, main reads args.repeat_n, but the replay parser never defines it. Replay exits with AttributeError before printing verdicts.

Learn more

The replay subparser only registers path in build_parser. Argparse therefore creates no repeat_n attribute for replay. Reading it before invoking replay_file raises AttributeError, so even ordinary replay commands fail. The new test checks return code 1, which is also the exit code from this unhandled exception.

Example: loopguard replay fixtures/repeat_error.jsonl prints a traceback and exits 1 instead of printing three annotated events. loopguard replay fixtures/repeat_error.jsonl --repeat-n 5 rejects the option and exits 2.

Recommended fix: Register --repeat-n with the replay subparser in build_parser, using the same default and integer type as watch. Extend the CLI test to assert the expected verdict, successful quiet replay with a higher threshold, and no traceback.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[ruslanlap]

Already fixed — this finding is against a stale intermediate push. The PR branch was force-updated from bd65b86 (which had the AttributeError bug) to 287cba9 before merge; 287cba9 already registers --repeat-n on the replay parser (build_parser, replay subparser) and passes repeat_n=args.repeat_n to replay_file. Verified on current main (4a1a3ae): loopguard.py replay fixtures/repeat_error.jsonl → prints verdicts, no AttributeError; replay --repeat-n 5 → quiet, exit 0. Also note test_replay_detects_repeat_error asserts on stdout content (REPEAT_ERROR verdict), not just the exit code, so it can't pass via a crash.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: bd65b866d7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Define repeat_n for the replay subcommand

Every replay invocation now accesses args.repeat_n, but --repeat-n is registered only on the watch parser, so replay exits with an AttributeError before processing any events. Add the option to the replay parser or pass the existing default without reading a missing namespace attribute.

Useful? React with 👍 / 👎.

[ruslanlap]

Already fixed — this finding is against a stale intermediate push. The PR branch was force-updated from bd65b86 (which had the AttributeError bug) to 287cba9 before merge; 287cba9 already registers --repeat-n on the replay parser (build_parser, replay subparser) and passes repeat_n=args.repeat_n to replay_file. Verified on current main (4a1a3ae): loopguard.py replay fixtures/repeat_error.jsonl → prints verdicts, no AttributeError; replay --repeat-n 5 → quiet, exit 0. Also note test_replay_detects_repeat_error asserts on stdout content (REPEAT_ERROR verdict), not just the exit code, so it can't pass via a crash.