3ed48516df
🚀 Publish Trigger.dev Docker / units (push) Failing after 1s
🚀 Publish Trigger.dev Docker / typecheck (push) Failing after 3s
🚀 Publish Trigger.dev Docker / publish-webapp (push) Has been skipped
🚀 Publish Trigger.dev Docker / publish-worker-v4 (push) Has been skipped
🚀 Publish Trigger.dev Docker / scan-webapp (push) Has been skipped
🚀 Publish Trigger.dev Docker / scan-supervisor (push) Has been skipped
🦋 Changesets PR / Create Release PR (push) Has been cancelled
🧭 Helm Chart Prerelease / lint-and-test (push) Has been cancelled
Workflow Checks / Actionlint (push) Has been cancelled
Workflow Checks / Zizmor (push) Has been cancelled
🚀 Publish Trigger.dev Docker / 📣 Dispatch main image (push) Has been cancelled
🧭 Helm Chart Prerelease / prerelease (push) Has been cancelled
## Summary PRs opened by the claude GitHub app fail both the agent instructions audit and the REVIEW.md drift audit before Claude gets a chance to run. `claude-code-action` refuses any actor whose account type is not `User` unless the actor is listed in `allowed_bots`: ``` Workflow initiated by non-human actor: claude (type: Bot). Add bot to allowed_bots list or use '*' to allow all bots. ``` So those PRs land with two permanently red checks and no audit coverage at all. Both workflows already allowlist Devin; this adds the claude app alongside it. ## Why this does not open the workflows up to outside contributors `allowed_bots` is only consulted for non-`User` actors. Humans, contributor or maintainer, take the separate write-permission path and are unaffected by what is in the list. Beyond that, both jobs are guarded by `github.event.pull_request.head.repo.full_name == github.repository`, so a fork PR skips the job entirely, and they trigger on `pull_request` rather than `pull_request_target`, so a fork-triggered run would get no API key and a read-only token anyway. The bot is named explicitly instead of using `"*"`, which would let every bot trigger these audits, dependabot's PR stream included.
96 lines
4.8 KiB
YAML
96 lines
4.8 KiB
YAML
name: 🔎 REVIEW.md Drift Audit
|
|
|
|
on:
|
|
pull_request:
|
|
types: [opened, ready_for_review, synchronize]
|
|
paths-ignore:
|
|
- "docs/**"
|
|
- ".changeset/**"
|
|
- ".server-changes/**"
|
|
|
|
concurrency:
|
|
group: review-md-drift-${{ github.event.pull_request.number }}
|
|
cancel-in-progress: true
|
|
|
|
jobs:
|
|
audit:
|
|
# Set the ENABLE_CLAUDE_CODE repository variable to 'false' to turn off Claude
|
|
# jobs; leave it unset (the default) to keep them enabled.
|
|
if: >-
|
|
vars.ENABLE_CLAUDE_CODE != 'false' &&
|
|
github.event.pull_request.draft == false &&
|
|
github.event.pull_request.head.repo.full_name == github.repository
|
|
runs-on: warp-ubuntu-latest-x64-2x
|
|
permissions:
|
|
contents: read
|
|
pull-requests: write
|
|
id-token: write
|
|
steps:
|
|
- name: Checkout repository
|
|
uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
|
|
with:
|
|
fetch-depth: 0
|
|
persist-credentials: false
|
|
|
|
- name: Run Claude Code
|
|
id: claude
|
|
uses: anthropics/claude-code-action@428971d2ecd6e3a7cb0ee0da2a3a8b33fdb3678d # v1.0.157
|
|
with:
|
|
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
|
|
use_sticky_comment: true
|
|
allowed_bots: "devin-ai-integration[bot],claude[bot]"
|
|
|
|
claude_args: |
|
|
--max-turns 30
|
|
--allowedTools "Read,Glob,Grep,Bash(git diff:*)"
|
|
|
|
prompt: |
|
|
You are auditing this PR for drift against `.claude/REVIEW.md`.
|
|
|
|
## Context
|
|
|
|
`.claude/REVIEW.md` is the repo's source of truth for what AI / agent code reviewers should treat as critical findings (rolling-deploy safety, hot-table indexes, recovery-path queries, testcontainers usage, Lua versioning, etc.). It is consumed by review agents to calibrate severity. If REVIEW.md goes stale, every future agent review degrades.
|
|
|
|
## Strategy — read this first
|
|
|
|
You have a hard turn budget. Spend it on signal, not coverage. The audit is allowed to miss things; it is NOT allowed to time out.
|
|
|
|
1. Read `.claude/REVIEW.md` once, in full.
|
|
2. Run `git diff origin/main...HEAD --name-only` to get the list of changed files. Do NOT read the diff content yet.
|
|
3. Scan the file-list for relevance to REVIEW.md scope. Relevance signals: changes to Prisma schema, Redis / queue / Lua code, hot tables, recovery / restart loops, new packages, deletions of paths REVIEW.md cites. Skim everything else.
|
|
4. Open at most **5 files** total — only the ones most likely to surface a real signal. If nothing in the file-list looks relevant to any REVIEW.md rule, do NOT read any files; go straight to the verdict.
|
|
5. Form a verdict and stop. Do not exhaust the turn budget exploring.
|
|
|
|
Large PRs (>50 files changed) are a strong signal to be MORE selective, not more thorough. Pick 3-5 files at most.
|
|
|
|
## What to look for
|
|
|
|
- **Stale references** — does any REVIEW.md rule cite a file, directory, function, table, Prisma model, or package name that has been removed or renamed in this PR (or is already gone from `main`)?
|
|
- **Contradictions** — does code in this PR clearly violate a current REVIEW.md rule? (Don't re-review the PR. Only flag if REVIEW.md and the PR plainly disagree.)
|
|
- **Missing rules** — does this PR introduce a new pattern future reviewers should know about? Examples: a new hot table, a new Lua-script versioning convention, a new safety wrapper, a new "must always check" invariant.
|
|
- **Obsolete rules** — has the repo moved past a constraint REVIEW.md still asserts? (e.g. a deprecated path is gone, a pattern is now linted, V1 code is deleted.)
|
|
|
|
## Response format
|
|
|
|
If nothing needs changing:
|
|
|
|
✅ REVIEW.md looks current for this PR.
|
|
|
|
Otherwise:
|
|
|
|
📝 **REVIEW.md updates suggested:**
|
|
|
|
- **[stale]** `<rule excerpt>` — <what's stale and why>
|
|
- **[contradiction]** `<rule excerpt>` — <what in this PR disagrees>
|
|
- **[missing]** under `## <section>` — <one-sentence draft rule>
|
|
- **[obsolete]** `<rule excerpt>` — <why this rule no longer applies>
|
|
|
|
## Rules
|
|
|
|
- Maximum 3 suggestions per audit. Pick the highest-signal ones.
|
|
- Only flag things that would actually mislead a future reviewer. Style and wording do not count.
|
|
- Do NOT review the PR itself. Do NOT propose rules outside REVIEW.md's existing sections.
|
|
- Do NOT propose rules for one-off PR specifics that don't generalize to future PRs.
|
|
- If REVIEW.md does not exist in the repo, respond with `(skip)` and stop.
|
|
- When in doubt between "one more file read" and "finish now" — finish now.
|