ci: improve Claude PR review workflow + document branch strategy

[drappi-ai]

Summary

• CLAUDE.md: Document that PRs target seismic (production), not main (upstream tracking)
• claude.yml: Overhaul the Claude PR review workflow:
  • Use Claude GitHub App (claude[bot]) instead of GITHUB_TOKEN
  • Enable use_sticky_comment for single-comment edit-in-place (no comment spam)
  • Add synchronize/reopened triggers so reviews re-run on every push
  • Split into two steps with separate prompts and read-only tool permissions:
    initial review (full analysis) vs re-review (incremental diff)
  • cancel-in-progress ensures only the latest push gets reviewed

Test plan

• Verify initial review posts a sticky comment on PR open
• Verify re-review edits the same comment on subsequent push
• Verify @claude comment triggers a re-review
• Verify concurrent pushes cancel stale runs

[github-actions]

PR Review Summary

Reviewed commit: 4f5cf39cb5c48bfe3b509ad1d6e3f4e710bbbaa5

Changes

This PR makes two changes:

1. .github/workflows/claude.yml: Adds reopened/synchronize triggers, enables use_sticky_comment, moves model from action input to claude_args, and sets IS_REREVIEW for synchronize events.
2. CLAUDE.md: Documents the branch strategy (seismic = production, main = upstream tracking).

Blocking Issues

1. use_sticky_comment: true conflicts with gh pr comment in the prompt (.github/workflows/claude.yml:53 + lines 75-76, 120-121)

   The use_sticky_comment: true parameter tells the action to maintain a single, edit-in-place comment with Claude text output. However, the prompt still instructs Claude to post findings via gh pr comment, which creates separate PR comments.

   This creates two problems:

   • Duplicate comments: Each review produces both a sticky comment (from the action) and a separate gh pr comment (from the tool call), defeating the no-comment-spam goal.
   • Re-review confusion: The re-review logic (line 107-109) searches for the most recent github-actions[bot] comment containing "Reviewed commit". Both the sticky comment and the gh pr comment are authored by github-actions[bot]. If the sticky comment includes review content from Claude text output, the re-review could match the wrong comment.

   Fix -- choose one approach:

   • Option A (sticky comment): Keep use_sticky_comment: true and update the prompt to tell Claude to output the review as plain text (not via gh pr comment). The action will automatically post/update the sticky comment. Also remove Bash(gh pr comment:*) from allowedTools.
   • Option B (explicit comments): Remove use_sticky_comment: true and keep the current gh pr comment approach. This preserves the existing comment-per-review behavior.

Suggestions

1. PR description is slightly misleading -- The description says "Remove explicit github_token (Claude app handles auth)" but the diff retains github_token (line 52). Consider updating the PR description to reflect the actual changes, since github_token is still needed for gh CLI tool calls.

2. Consider reopened re-review semantics -- Currently, reopening a previously-reviewed PR triggers a fresh initial review (IS_REREVIEW is false for reopened events). If the PR was already reviewed before being closed, a re-review might be more efficient. This is minor -- the current behavior (fresh review on reopen) is a reasonable default, but worth a conscious decision.

3. --model in claude_args multi-line block -- The claude_args value uses a YAML multi-line string. Verify that the claude-code-action parses --model claude-opus-4-6 correctly when passed this way (vs. the previous dedicated model: input). If the action splits on newlines, this should work, but it depends on the action argument parsing implementation.

Positive Notes

• Adding synchronize trigger so reviews auto-run on each push is a solid improvement for developer workflow.
• cancel-in-progress concurrency group correctly prevents stale reviews from completing.
• The branch strategy documentation in CLAUDE.md is clear and concise.
• The IS_REREVIEW logic correctly distinguishes between fresh PR events and push updates.
• Good security practices maintained: read-only tool permissions, supply-chain-safe SHA pinning for the action.

To request a re-review after pushing fixes, comment @claude on this PR.