fix(ci): stop Dependabot bumping generated gh-aw lock files

[groupthinking]

Canonical issue

Closes #1403

Narrow slice of the diagnosis recorded in #1398. That issue stays open and is not resolved here — it owns the gh-aw toolchain bump (four v0.82.14 assertions → v0.84.2 plus a real gh aw compile regeneration), which needs a gh CLI environment this change does not have and does not attempt.

Phrasing note: #1398 and #1171 are referenced throughout without closing keywords, deliberately. GitHub's closing-reference parser does not understand negation, so a negated closing keyword still registers a real closing link — an earlier revision of this body would have auto-closed both issues on merge. Closes #1403 above is intended to be the only closing reference in this body.

Outcome

One ignore entry in .github/dependabot.yml so Dependabot stops opening github/gh-aw-actions/* PRs that cannot go green.

.github/workflows/*.lock.yml are generated by gh aw compile, and gh-aw-validation.yml pins that compiler to one version. Dependabot rewrites the uses: pins inside the generated artifacts without rerunning the compiler, so the job's final git diff --exit-code -- *.lock.yml step regenerates them at the pinned version and fails on every such bump.

PR #1171 (github/gh-aw-actions/setup 0.82.14 → 0.84.2) is the worked example. gh aw compile itself runs clean — ✓ Compiled 2 workflow(s): 0 error(s), 0 warning(s) — and the diff step then reports both lock files reverting the bump (run 30993992684):

-        uses: github/gh-aw-actions/setup@fd783ac87efde5e0c0e05d593f1906ea25b5d92e # v0.84.2
+        uses: github/gh-aw-actions/setup@b6d1443e05b8716267fa19425b99aa4f12006b4a # v0.82.14
##[error]Process completed with exit code 1.

The compiler pin, not the lock file, owns that version — so that PR is unmergeable by construction. #1398 records that the remediation loop has re-triaged it four separate times, re-deriving the same diagnosis each run.

Scope

• Included: .github/dependabot.yml — an ignore for github/gh-aw-actions/* under the github-actions ecosystem, plus an inline comment recording the upgrade path (bump the version in gh-aw-validation.yml at the extension install, the version assert, and the actions-lock.json entry key + SHA; update .github/aw/actions-lock.json; recompile; commit the regenerated lock files in one change).
• Explicitly excluded: the toolchain bump and lock-file regeneration (ci: gh-aw toolchain pin is hard-coded to v0.82.14 in 4 places, making Dependabot bumps (#1171) structurally unmergeable #1398); the disposition of build(deps): bump github/gh-aw-actions/setup from 0.82.14 to 0.84.2 #1171 itself, which is a human call.

Why this costs no coverage

github/gh-aw-actions/setup is referenced only by the two generated lock files and by the SHA assertion inside gh-aw-validation.yml — verified with grep -rl 'gh-aw-actions/setup' .github/, which returns exactly actions-lock.json, the two .lock.yml files, and gh-aw-validation.yml. No hand-written workflow uses it.

It also does not obstruct #1398: that upgrade path is compiler-driven, so a Dependabot proposal was never a usable input to it.

Risk

• Risk level: low. One declarative ignore entry. No workflow logic, no generated file, no application code.
• Class A under MERGE_POLICY.md v2 §8 — CI config.
• Failure mode: a future genuinely-needed gh-aw-actions bump is not surfaced by Dependabot. Mitigated by the inline comment and by ci: gh-aw toolchain pin is hard-coded to v0.82.14 in 4 places, making Dependabot bumps (#1171) structurally unmergeable #1398 tracking the upgrade explicitly.
• Rollback: revert this single commit; the setting is entirely declarative.

Verification

Head e6fd66f, which merges current main into the branch. The diff against main remains exactly one file, +20/-0.

Against MERGE_POLICY.md v2:

Gate	State
1 · Binding	✅ Exactly one Closes #1403; template followed. Canonical issue and evidence success, PR Governance neutral.
2 · Required checks	✅ validate, guards, lint-python, lint-frontend, build, test, CodeQL, gitleaks (working tree), dependency-review all success.
2 · Conditional	Generate and Upload Coverage is not required here — the diff touches neither src/**, apps/**, nor tests/**. It is still in_progress, which is exactly the permanently-pending case §2 warns about. E2E Pipeline Tests skipped; Security Scan - javascript success though no JS/TS changed.
3 · Review	✅ CodeRabbit reports Review skipped: excluded by label configuration — §3: "A reviewer that skips for configuration reasons satisfies this gate." Vercel Agent Review success.
4 · Preview	N/A — no apps/web/** changes. Vercel preview is READY regardless.
5 · Provenance	✅ Declared scope is .github/dependabot.yml; the diff is that file alone.
6 · Overlap	✅ No other open PR touches .github/dependabot.yml.
7 · Freshness	✅ main merged in cleanly at e6fd66f; mergeable_state clean.

Also verified locally: .github/dependabot.yml parses under yaml.safe_load, the github-actions ecosystem resolves to exactly one ignore entry {'dependency-name': 'github/gh-aw-actions/*'}, and the other four ecosystems (npm:/, npm:/apps/web, pip:/, pip:/src/youtube_extension/backend) are unchanged.

Prior blocker — resolved, no longer applicable

This PR was previously HALTED on agent-completion/truth-gate, which returned invalid_payload because agentTaskApplicable treated any claude/* head ref as an agent dispatch and demanded an intent-snapshot comment that could not be authored retroactively.

That gate was retired in #1431, and MERGE_POLICY.md v2 records the same finding independently — the gate was "red on ~100% of pull requests for weeks, including merged ones." It no longer appears in this PR's check set. The earlier blocker note has been removed from this description rather than left to mislead.

Production evidence

Not applicable. This change alters repository dependency-update configuration only; it ships no runtime code and has no deployable surface. The Vercel preview on e6fd66f is READY and unaffected.

Agent handoff

• One canonical issue is linked (ci: Dependabot should not manage compiler-generated gh-aw lock files #1403)
• No competing PR implements the same issue
• Acceptance criteria are satisfied
• Required checks pass on the current head
• Human decision requested only for the merge itself — see below

On merging: v2 §8 classes this as A (CI config), which the policy says auto-merges on gates 1–7, and §"What is deliberately not here" states "No per-PR human merge clicks." All seven gates are met. I have not merged it: adoption step 6 ("Enable Class A auto-merge") is still unchecked, branch protection and the merge queue are not enabled, and merging to main is irreversible — so the mechanism the policy describes does not yet exist to carry it. This is ready for whoever enables it, or for a manual merge.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
v0-uvai	Ready	Preview, v0	Aug 7, 2026 8:47pm

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• [‘architecture-gap’, ‘bug’, ‘ci-cd’, ‘ci/cd’, ‘copilot-rabbit’, ‘documentation’, ‘duplicate’, ‘enhancement’, ‘frontend’, ‘github_actions’, ‘good first issue’, ‘help wanted’, ‘high-priority’, ‘invalid’, ‘javascript’, ‘ml-model’, ‘needs-triage’, ‘pipeline-critical’, ‘placeholder-code’, ‘priority:high’, ‘python’, ‘python:uv’, ‘question’, ‘styling’, ‘tests’, ‘v0’]

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Repository UI (inherited), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: d6cf1286-79a2-4a26-8e2f-d4effd0fd03c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Snapshot Warnings

⚠️: No snapshots were found for the head SHA 1ec3dd0.

Ensure that dependencies are being submitted on PR branches and consider enabling retry-on-snapshot-warnings. See the documentation for more information and troubleshooting advice.

Scanned Files

None

[github-actions]

Agent Completion Truth Gate: BLOCKED

Reasons: invalid_payload

Machine-readable verdict

{
  "details": {
    "collection_errors": [
      "incomplete_linked_issue_contract",
      "missing_intent_snapshot",
      "missing_agent_run_id",
      "missing_agent_login"
    ],
    "invalid_fields": [
      "policy.agent_login",
      "policy.run_id"
    ]
  },
  "reasons": [
    "invalid_payload"
  ],
  "verdict": "blocked"
}

Workflow evidence

[groupthinking]

@coderabbitai full review

Auto-review was skipped on this PR because it carried no labels; ci/cd and github_actions have since been added, so the label gate is satisfied. Requesting the initial pass explicitly since labelling does not retrigger it.

---

Generated by Claude Code

[coderabbitai]

@groupthinking I will perform a full review of this PR.

⚠️ Action not completed

Review rate limited.

---

Your included review limit is currently reached under our Fair Usage Limits Policy. This review may still proceed through usage-based billing if eligible. Your next included review will be available in 12 minutes.

[groupthinking]

HALTED(agent_dispatch_contract) — one decision needed

Fixed on this pass. The body originally carried three closing references, not one. Closes #1403 was intended, but negated prose around #1398 and #1171 registered as real closing links — GitHub's parser ignores negation, so merging would have auto-closed #1398 and #1171. Both are now referenced without closing keywords. The gate confirms it: multiple_closing_issues and missing_closing_issue_reference are gone from the verdict.

(One self-inflicted detour worth recording: the first correction quoted the offending phrase verbatim, which re-registered the link. The literal is now gone, not just the sentence around it.)

Remaining, and not fixable from here. Four collection_errors are left, and all four have the same root — this PR was never dispatched through the agent-lock pipeline:

Error	Why it stands
missing_intent_snapshot	Needs an agent-lock-intent-snapshot:v1 comment authored by github-actions[bot] on #1403 that strictly predates this PR (snapshotPredatesPull, pr-checks.yml:1933). Emitted by the dispatch workflow; #1403 was filed by hand. Cannot be authored under that identity, and would fail the predates-check even if it could.
missing_agent_run_id	#1403 declares no ## Agent Run ID section.
missing_agent_login	#1403 declares no ## Agent Login section.
incomplete_linked_issue_contract	Requires manifest ≡ textual ≡ authoritative issue number, which needs an agent-lock-manifest block carrying the above.

The last three are mechanically writable. I am deliberately not writing them. Declaring a run ID and login for a dispatch that never occurred would fabricate the evidence this gate exists to check — the same principle already settled on #1381, where an agent must not self-grant the approval gating its own merge. Reducing the count would make the check look closer to green without making the claim any truer, and missing_intent_snapshot is unforgeable regardless.

Why this PR is subject to the gate at all: agentTaskApplicable (pr-checks.yml:1942) keys off the head ref matching /^(?:agent|claude|codex|copilot|jules)[/-]/. This branch is claude/clever-heisenberg-pedqbz. #1381 carries the same kind of change on groupthinking-fix-upstream-error-leakage and its gate reads not_applicable — the branch name is the only difference. #1400 is on a claude/* branch and shows the identical invalid_payload, so this is a systemic condition, not something specific to this change.

The decision

The change itself is one declarative ignore entry, green on Dependency Review, with no runtime surface. Three ways forward, all requiring a human:

1. Re-land on a non-agent branch name. Cherry-pick f078b62 onto e.g. fix/dependabot-ignore-gh-aw; the gate goes not_applicable and the PR is mergeable as-is. Staged command:

   git fetch origin main && git checkout -B fix/dependabot-ignore-gh-aw origin/main
   git cherry-pick f078b6275e86ef8842c732f7752d96e1c8cddcd6
   git push -u origin fix/dependabot-ignore-gh-aw

   I have not done this — my branch assignment is claude/clever-heisenberg-pedqbz and pushing elsewhere needs your say-so.
2. Dispatch ci: Dependabot should not manage compiler-generated gh-aw lock files #1403 properly through the agent-lock pipeline so a real intent snapshot exists, then reopen.
3. Exempt hand-authored PRs on agent-named branches from the gate — the branch-name heuristic currently cannot distinguish a dispatched agent run from a human or agent working by hand on a claude/* branch. Given fix(perf): stamp each batched metric with its own timestamp #1400 hits it too, this may be the durable fix; related to agent-completion/truth-gate is permanently unsatisfiable for any PR closing an [aw] issue #1130.

Option 1 is the cheapest if you just want the Dependabot noise to stop.

---

Generated by Claude Code

[groupthinking]

The diagnosis is right; the ignore rule is too narrow to close the class

The root-cause analysis here is correct and well-evidenced — validate-gh-aw pins the compiler to v0.82.14, recompiles, and git diff --exit-codes the two generated lock files, so any hand-rewritten pin inside them is reverted and the job fails. #1171 is a clean worked example.

But the fix keys on one dependency name, and the defect is a property of the files, not of gh-aw-actions.

The generated lock files pin eight actions, not one

$ grep -ohE "uses: [a-zA-Z0-9/-]+@[a-f0-9]{40} # v[0-9.]+" .github/workflows/*.lock.yml | sort -u
actions/cache/restore@55cc834… # v6.1.0
actions/cache/save@55cc834… # v6.1.0
actions/checkout@9c091bb… # v7.0.0
actions/download-artifact@3e5f45b… # v8.0.1
actions/github-script@3a2844b… # v9.0.0
actions/setup-node@820762… # v7.0.0
actions/upload-artifact@043fb46… # v7.0.1
github/gh-aw-actions/setup@b6d1443… # v0.82.14

All eight are managed by the same github-actions ecosystem entry this PR amends. Ignoring the last one leaves the other seven able to reproduce the failure exactly.

#1000 is a live second instance, already red

PR #1000 — build(deps): bump actions/checkout from 4.2.2 to 7.0.1, open since 2026-07-25 — modifies both generated lock files:

File	Change
.github/workflows/canonical-pr-remediator.lock.yml	+4 / −4 (v7.0.0 → v7.0.1)
.github/workflows/focused-coverage-controller.lock.yml	+4 / −4 (v7.0.0 → v7.0.1)

Its validate-gh-aw is failure (job 91868487596) — same job, same mechanism, different dependency. This PR as written would not have prevented it.

Why extending the ignore list is not the fix

The PR comment's justification — "github/gh-aw-actions/setup appears only in those generated files … so ignoring it here costs no coverage on any hand-written workflow" — is accurate for that one dependency, and it is exactly what does not generalize. actions/checkout alone appears in ci.yml, security.yml, codeql-analysis.yml, coverage.yml, secret-scan.yml, verification.yml, deploy-cloud-run.yml, and more. Adding it to ignore would silently stop Dependabot from patching checkout across the entire hand-written pipeline to keep two generated files quiet — trading real supply-chain coverage for a cosmetic green.

And Dependabot's ignore is keyed on dependency name, not path, so there is no way to say "ignore these two files" while keeping coverage everywhere else. The per-dependency approach cannot express the actual invariant.

What would close the class

Two options that scope to the files rather than the names:

1. Make the validation job self-healing — on a Dependabot PR touching *.lock.yml, run gh aw compile canonical-pr-remediator focused-coverage-controller and commit the regenerated files, so the recompile becomes the fix instead of the failure.
2. Treat the lock files as compiler output, not source — upgrade gh-aw as one deliberate change (bump the version in gh-aw-validation.yml's extension install + version assert, update .github/aw/actions-lock.json's entry key and SHA, recompile, commit together), exactly as this PR's own comment already documents, and keep Dependabot out of them entirely.

Option 1 is the smaller change and closes both #1171 and #1000 without giving up any coverage.

Suggested amendment to this PR

Keep the gh-aw-actions ignore — it is correct and costs nothing. But the explanatory comment currently reads as though the class is closed. Worth narrowing that claim to the single dependency it covers, and linking #1000 as the open remainder, so the next person doesn't read a green #1171 as evidence the problem is solved.

Flagging rather than pushing a commit: which of the two options to take is a CI-ownership decision, and this is a draft I don't own.

---

Generated by Claude Code

[linear-code]

GRV-367