drive: cloud run a2b4fb12

[kjgbot]

Automated drive work from cloud run a2b4fb12-aa86-4d73-9b47-dd0aa82591ac.

The sandbox cannot open PRs (no remote, no GitHub token), so this was delivered
from a host that can. Verification and adversarial review ran in-run — see
ops/reviews/ in the diff. A human merges.

[coderabbitai]

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: 9fe8dec1-df9d-4bf9-a0ab-3a9817ade888

📥 Commits

Reviewing files that changed from the base of the PR and between 066ef24 and 71bf8bf.

📒 Files selected for processing (9)

• .claude/settings.json
• .github/workflows/review-swarm.yml
• .github/workflows/scripts/swarm-post.sh
• .github/workflows/scripts/swarm-prepare.sh
• .github/workflows/scripts/swarm-verdict.sh
• .gitignore
• README.md
• ops/NEXT.md
• workflows/review-swarm.yaml

💤 Files with no reviewable changes (1)

• .gitignore

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The pull request adds a gated Cloud review swarm workflow. It stages pull request data, launches and monitors an Agent Relay run, evaluates fresh lens transcripts, and updates pull request comments with lens and aggregate verdicts.

Changes

Cloud review swarm

Layer / File(s)	Summary
Gate-controlled review inputs .claude/settings.json, .github/workflows/review-swarm.yml, .github/workflows/scripts/swarm-prepare.sh, workflows/review-swarm.yaml, README.md, ops/NEXT.md	The workflow checks out the pull request and immutable gate, validates RELAY_WORKSPACE_KEY, stages pull request artifacts, and consumes staged metadata and verdict helpers. Documentation and implementation requirements describe the workflow contract.
Cloud swarm lifecycle .github/workflows/review-swarm.yml, workflows/review-swarm.yaml	The workflow launches the cloud swarm, validates its run ID, polls terminal states for up to 3,900 seconds, synchronizes evidence, and fails unless the swarm completes successfully.
Verdict evaluation and PR comments .github/workflows/scripts/swarm-verdict.sh, .github/workflows/scripts/swarm-post.sh, workflows/review-swarm.yaml	Shared helpers locate fresh transcripts and classify verdicts. Post-processing evaluates each lens, aggregates results, and upserts lens and overall PR comments.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant GitHubActions
  participant ReviewGate
  participant AgentRelayCloud
  participant GitHubPR
  GitHubActions->>ReviewGate: Prepare staged pull request artifacts
  ReviewGate->>AgentRelayCloud: Launch synchronized review swarm
  GitHubActions->>AgentRelayCloud: Poll run until terminal status
  AgentRelayCloud-->>GitHubActions: Return swarm status and evidence
  GitHubActions->>GitHubPR: Publish or update review comments

Loading

Poem

I’m a rabbit with a staged review pack,
Gate files guide the workflow track.
Cloud agents hop through every lens,
Fresh transcripts prove the evidence ends.
PR comments bloom when verdicts land.

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing.

_{Comment @coderabbitai help to get the list of available commands.}

[kjgbot]

Reviewed. The workflow is well-built; I am holding the merge on one missing prerequisite.

The design is sound — worth saying, because the risky version of this is easy to write

• pull_request, not pull_request_target. Fork PRs therefore get no secrets, and checking out the PR head is safe. The dangerous variant of this workflow is one line away and this is not it.
• The gate is checked out from main, separately from the PR head (review-gate vs review-target, sparse to workflows/review-swarm.yaml and .github/workflows/scripts). So a PR cannot edit the gate that judges it — the rule AGENTS.md states and that this stack has been bitten by.
• Minimal permissions (contents: read, pull-requests: write), concurrency with cancel-in-progress, and a documented ordering invariant (75-minute job > 65-minute poll > 60-minute swarm).
• It fails closed with a message pointing at the README, rather than skipping. Correct.

Why I am not merging it yet

RELAY_WORKSPACE_KEY does not exist:

$ gh api repos/AgentWorkforce/flows/actions/secrets --jq '.secrets[].name'
(empty — the repo has no Actions secrets at all)

so the workflow fails on its own PR:

review  fail  7s
RELAY_WORKSPACE_KEY secret not configured; see README § Cloud review swarm.

Merging this adds a required-looking red check to every future PR until that secret is added. I have spent tonight digging this repo out of exactly that situation: #153 turned CI on in a state where it could not pass, and every PR was blocked for hours across three follow-up fixes (#154, #158, #159). I am not going to recreate that shape the same day, when the fix is one secret.

To unblock

Add RELAY_WORKSPACE_KEY to the repo's Actions secrets, then re-run this PR's review check. If it goes green I will merge it — the change itself is good and I have no findings against it.

If you would rather land it now and add the secret after, say so and I will merge; it is your call, not a technical obstacle.

One note on the delivery model

The sandbox cannot open PRs (no remote, no GitHub token), so this was delivered from a host that can. Verification and adversarial review ran in-run — see ops/reviews/ in the diff. A human merges.

Worth flagging that the in-run verification could not have exercised this workflow, because the secret it requires is absent in CI too. The review that matters for this particular PR is the one its own review check would perform, and that has never run.

[kjgbot]

Superseded by #164, which is the most complete version of the same review-swarm work (it also adds workflows/review-swarm.yaml, which this one lacks).

These four drive PRs (#161, #162, #164, #165) came from separate cloud runs and three of them re-attempt the same change. Merging more than one would duplicate the workflow and its scripts. Consolidating on #164; closing this rather than leaving three near-identical PRs open.

No work is lost — #164 is a superset. If something here is not in #164, say so and I will port it.