ci(review): keep the review run log so failures are diagnosable

[adnaan]

Adds a step capturing the review run's execution log as an artifact, so the next failure can be diagnosed instead of guessed at.

Why

When the review job fails, the job log gives only the aggregate:

"is_error": true,
"num_turns": 4,
"total_cost_usd": 0.1639,
"permission_denials_count": 1

It never names the tool that was denied — and that is the one fact needed to fix it. The detail lives in the execution output file, written to the runner temp dir and thrown away with the runner.

What this rules out

Diagnosing the current failures eliminated three plausible causes, none of which held:

• Not auth. The run initializes ("model": "claude-sonnet-5") and bills real budget. (The empty ANTHROPIC_API_KEY in the env dump is a red herring — these workflows authenticate via claude_code_oauth_token, so that variable is expected to be blank.)
• Not quota. An exhausted quota fails at init or returns 429; it does not run four turns and charge $0.16.
• Not an action upgrade. All three repos pin the floating @v1 tag, but that tag last moved at 2026-07-19T02:57:33Z — hours before the last green run. Same version succeeded and failed.

What remains is the permission denial itself, which is precisely the part not recorded anywhere durable.

Note on why capture beats re-running

Re-triggering a run is cheap; reproducing a specific failure is not. Which tool the model reaches for varies per PR, so a denial not captured when it happens may simply not recur on demand. Hence if: always() rather than only-on-failure — a green run's log is also useful as the baseline to diff against.

Companion PRs apply the same step to the other two repos, since all three fail the same way and each has a differently-scoped allowlist worth comparing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ui2cwpeGkrUfRt8rh2FgGG

[adnaan]

Closing — this approach can't work.

The step captured nothing on the failing run it was built for. Two wrong assumptions, one per attempt: that a failed action step sets its outputs (it doesn't, so execution_file was empty exactly when capture mattered), and that the path the action prints during the run still holds the file afterwards (it doesn't — a search of RUNNER_TEMP on a green run found only runner scratch scripts, no claude-execution-output.json).

A step that always warns "no files found" is worse than no step, since it reads as captured on the next failure.

Superseded by livetemplate/livetemplate#510, which fixes the actual cause. This repo's bot was never the problem — it recovered on its own, and its allowlist already includes Read.