…ntext

A fresh-eyes review (before any PR comment, caught pre-push) found three bugs
that would have made policy 2A silently do nothing:

- Every `gh pr view`/`merge`/`edit` call had no repo context (no checkout in
  this workflow) and would have failed with "not a git repository". Fixed by
  setting `GH_REPO`/`GH_TOKEN` at job level.
- Dependabot's `update-type` metadata lives in the COMMIT MESSAGE, not the PR
  body -- confirmed against a real, live Dependabot PR
  (dependabot/fetch-metadata#763). The classify step now fetches
  `pulls/{n}/commits` and parses each commit's message instead, and requires
  every commit be authored by dependabot[bot].
- `ignore`-ing anthropic/google-api-python-client for patch+minor meant
  Dependabot would never open a PR for them at that level at all (the
  opposite of the intent: "a PR opens every time, a human reviews it").
  Replaced with `exclude-patterns` on the patch/minor group (so they still
  get individual PRs) plus an explicit forced-needs-review check in the
  classify step, keyed on dependency name from the commit message.

Also: listen to `tests`/`sast`/`secrets`/`data-guard` workflow_run completions
(not just `tests`), since whichever finishes last is the one that should
actually re-check everything and merge -- gating on `tests` alone could leave
a green PR "stuck" if a slower gate finished after it.

Verified the new classify logic against two REAL Dependabot commit messages
(dependabot/fetch-metadata#762 and #763, pulled live) plus synthetic fixtures
for the forced-review and no-metadata cases -- all five classify correctly,
including a real edge case (an indirect-dependency bump with no `update-type`
field at all) that only showed up by using real data instead of hand-written
fixtures.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

…d have blocked every merge

A full end-to-end rehearsal against a real, live, open Dependabot PR
(dependabot/fetch-metadata#763) -- running this workflow's actual Resolve/
Verify/Classify `run:` scripts via a PyYAML-extracted driver, not a
hand-copied approximation -- surfaced a bug none of the earlier review
rounds caught: the Verify step used `gh pr view --json author`, which goes
through GitHub's GraphQL API and reports a bot's login as `"app/dependabot"`
-- never `"dependabot[bot]"`, the REST API's string, which the Classify
step's commit-level check already (correctly) used. Every real Dependabot
PR would have failed Verify's `login != "dependabot[bot]"` check and been
skipped, meaning this workflow would silently never merge or label ANYTHING
-- the whole point of the PR, defeated by one unverified assumption about
an API response shape. Same root-cause class as the earlier PR-body-vs-
commit-message mistake: an API's output shape assumed, not exercised,
before this rehearsal.

Fixed: Verify now uses `gh api repos/.../pulls/{n}` (REST), matching
Classify's own API family. REST's `state` field is also lowercase ("open"),
unlike GraphQL's "OPEN" -- fixed that comparison too.

Re-rehearsed the full Resolve -> Verify -> Classify chain against the same
real PR (#763) after the fix: Resolve gives number=763/skip=false, Verify
now gives skip=false (previously would have been skip=true), Classify gives
major-or-other (correct -- #763 has 4 major bumps mixed into a grouped PR).
Also spot-checked Verify against a real CLOSED PR (#761) to confirm the
state check still correctly skips a non-open PR.

pytest -q: 2616 passed (unchanged -- no app code touched). actionlint:
clean.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

)

* build(deps): Dependabot config + self-gated auto-merge (policy 2A)

Staged 2026-10-14 handoff (devops-automation): patch/minor Dependabot bumps
merge themselves once `tests` passes; majors wait for Trisha. Deliberately
does NOT touch branch protection or `allow_auto_merge` -- three workflows
(findings-feed.yml, public-comment.yml, ridgewood-reverify.yml) push commits
straight to main with GITHUB_TOKEN, and `main`'s branch protection has
enforce_admins: true, so a required status check would make GitHub reject
those direct pushes too (GH006). Instead, dependabot-auto-merge.yml gates
and merges itself, triggered by the already-completed `tests` workflow_run
for the exact commit in question -- no repo-setting change needed.

- .github/dependabot.yml: pip (weekly, grouped patch+minor, majors separate;
  anthropic + google-api-python-client forced to major-only regardless of
  semver level, since their real SDK calls are fully monkeypatched out of
  the hermetic test suite) and github-actions (monthly, grouped).
- dependabot-label.yml: labels a major `needs-review` immediately on open,
  independent of test outcome (dependabot-auto-merge.yml only runs after
  `tests` succeeds, so it can't label a major whose tests fail).
- dependabot-auto-merge.yml: workflow_run-triggered (never pull_request or
  pull_request_target -- no PR code is ever checked out), re-verifies the
  PR's author/state/head-SHA against what was actually tested, confirms
  bandit/gitleaks/block-data-files also passed for that commit, classifies
  patch/minor vs major from Dependabot's own PR-body metadata block, then
  merges or labels.
- docs/devops-monthly-sweep.md: a staged (not scheduled) monthly checklist
  for Python/Actions EOL, branch/worktree hygiene, the Dependabot backlog,
  and Lotext package currency. No schedule created here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

* fix: review round 1 -- commit-msg metadata, exclude-patterns, repo context

A fresh-eyes review (before any PR comment, caught pre-push) found three bugs
that would have made policy 2A silently do nothing:

- Every `gh pr view`/`merge`/`edit` call had no repo context (no checkout in
  this workflow) and would have failed with "not a git repository". Fixed by
  setting `GH_REPO`/`GH_TOKEN` at job level.
- Dependabot's `update-type` metadata lives in the COMMIT MESSAGE, not the PR
  body -- confirmed against a real, live Dependabot PR
  (dependabot/fetch-metadata#763). The classify step now fetches
  `pulls/{n}/commits` and parses each commit's message instead, and requires
  every commit be authored by dependabot[bot].
- `ignore`-ing anthropic/google-api-python-client for patch+minor meant
  Dependabot would never open a PR for them at that level at all (the
  opposite of the intent: "a PR opens every time, a human reviews it").
  Replaced with `exclude-patterns` on the patch/minor group (so they still
  get individual PRs) plus an explicit forced-needs-review check in the
  classify step, keyed on dependency name from the commit message.

Also: listen to `tests`/`sast`/`secrets`/`data-guard` workflow_run completions
(not just `tests`), since whichever finishes last is the one that should
actually re-check everything and merge -- gating on `tests` alone could leave
a green PR "stuck" if a slower gate finished after it.

Verified the new classify logic against two REAL Dependabot commit messages
(dependabot/fetch-metadata#762 and #763, pulled live) plus synthetic fixtures
for the forced-review and no-metadata cases -- all five classify correctly,
including a real edge case (an indirect-dependency bump with no `update-type`
field at all) that only showed up by using real data instead of hand-written
fixtures.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

* fix: review round 2 -- github-actions can never auto-merge via GITHUB_TOKEN

Second independent-review pass found one more bug that would have made every
monthly github-actions Dependabot PR fail red at the merge step: GITHUB_TOKEN
can never be granted the `workflows` permission a push to .github/workflows/
requires (confirmed against the exact "refusing to allow ... without
`workflow` scope" class of error this build's own SSH push for these very
workflow files had to route around). Every github-actions ecosystem PR edits
a file under .github/workflows/, so `gh pr merge` would always fail there
regardless of update-type.

Fixed: the classify step now checks the PR's branch name first (Dependabot's
own naming convention for this ecosystem is `dependabot/github_actions/...`,
confirmed against real PRs) and routes straight to needs-review before even
looking at commit metadata. In practice, policy 2A's auto-merge is
pip-ecosystem only; github-actions bumps always wait for Trisha.

Also:
- Softened dependabot.yml's pip-compile comment: hash-regeneration mechanics
  on a version bump are plausible (sourced from dependabot-core's issue
  tracker) but not confirmed against an official GitHub doc, unlike
  pip-compile support itself (which IS documented). The real backstop is
  unchanged either way -- `pip install --require-hashes` fails CI loudly on
  a bad/stale hash.
- Added a root .python-version pinning 3.12, matching every workflow's own
  pin -- dependabot-core#14137 documents Dependabot's pip-compile ignoring
  the Python version in the lockfile's own header without one.
- Verified the embedded python3 classify logic against the ACTUAL shipped
  YAML text this time (loaded via PyYAML, extracted the real `run:` string,
  ran that exact program), not a hand-copied test file -- confirms the
  10-space indentation added to satisfy YAML's literal-block-scalar rule is
  correctly stripped back out before Python ever sees it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

* fix: review round 3 -- needs-review label doesn't auto-create

Independent diff-only review (Step 5) found: `gh pr edit --add-label
needs-review` does not auto-create a missing label (unlike Dependabot's own
`labels:` handling, which does create `dependencies`). The label didn't
exist on this repo, so the very first major-version Dependabot PR would have
failed this step (red job) and never actually gotten flagged -- silently
breaking the "majors get flagged for Trisha" path that
docs/devops-monthly-sweep.md item 4 and the morning-briefing surfacing both
depend on. Doesn't cause an unsafe merge (the classify step still correctly
withholds merge either way), but breaks discovery.

Fixed in both workflows: a preceding `gh label create needs-review --force`
step makes this idempotent (creates once, no-ops after). Needs `issues:
write` (not `pull-requests: write` -- labels are an Issues-API resource even
when applied to a PR), added to both workflows' permissions. Also created
the label directly on the repo now, so it exists immediately rather than
waiting for this workflow's first real trigger.

Also added a comment to dependabot.yml's github-actions-all group
explaining why it's safe to leave ungrouped by update-type (a major mixed
into the monthly batch is fine because the whole ecosystem already routes to
needs-review unconditionally, by branch name, before update-type is ever
read) -- closes a question the same reviewer round raised.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

* fix: Step 6 low-severity hardening -- commit-trust check, pin the merge

A /security-review pass (Step 6) flagged two possible findings on
dependabot-auto-merge.yml, routed through the skill's own two-stage
false-positive filter (a parallel sub-task per finding, same protocol the
skill itself specifies):

- Commit-author spoofing: the classify step's only check was
  `author.login == "dependabot[bot]"`, which is derived purely from matching
  the commit's author EMAIL against GitHub's noreply convention -- no
  identity proof required, forgeable by anyone who can push to the branch.
  Initially scanned as High (the scanner also claimed this would bypass a
  required PR review on main; that claim was checked directly against
  `branches/main/protection` and found FALSE -- main has no
  required_pull_request_reviews at all, so there is no such review to
  bypass). The filter sub-task re-verified independently (not relying on the
  false premise) that this repo has exactly ONE collaborator, making the
  "human with push access" attacker class hypothetical today -- confidence
  3/10, filtered out per the skill's own <8 threshold. Final verdict: no
  medium/high finding, but a real low-severity gap remained (the check's own
  comment claimed more than it verified).
- A merge-pinning TOCTOU: `gh pr merge` didn't pin the commit it merges to
  the SHA verified earlier in the same job. Filtered at confidence 2/10 (the
  window is 1-2 sequential API calls within a single job run, and the
  classify step's own author check independently re-covers it) -- also no
  medium/high finding.

Both filtered below the hard-stop threshold, but Step 6 treats a low finding
as fix-now-in-the-loop by default, and both fixes are small and verified
against real Dependabot commits (dependabot/fetch-metadata PRs #730, #762,
#763):

- Classify step now requires ALL THREE of author.login ==
  "dependabot[bot]", committer.login == "web-flow" (GitHub's own web-based
  commit identity -- only GitHub's backend can produce this, unlike the
  author email), and commit.verification.verified == true. Verified all
  three hold on three independent real commits before relying on it; a miss
  only routes to needs-review, never an unsafe state.
- `gh pr merge` now passes `--match-head-commit "$TESTED_SHA"`, making the
  earlier SHA re-verification step load-bearing at the moment that matters --
  GitHub itself refuses the merge if the PR's head moved since that check.

Also: dropped the misleading "(major)" from check_dependabot_prs.sh's
needs-review bullet text and the matching SKILL.md paragraph -- that label
now also covers the two forced-review packages, every github-actions-
ecosystem bump, and unparseable PRs, not just majors.

pytest -q: 2616 passed (unchanged -- no app code touched). actionlint:
clean.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

* fix: Verify step used GraphQL's bot-author string, not REST's -- would have blocked every merge

A full end-to-end rehearsal against a real, live, open Dependabot PR
(dependabot/fetch-metadata#763) -- running this workflow's actual Resolve/
Verify/Classify `run:` scripts via a PyYAML-extracted driver, not a
hand-copied approximation -- surfaced a bug none of the earlier review
rounds caught: the Verify step used `gh pr view --json author`, which goes
through GitHub's GraphQL API and reports a bot's login as `"app/dependabot"`
-- never `"dependabot[bot]"`, the REST API's string, which the Classify
step's commit-level check already (correctly) used. Every real Dependabot
PR would have failed Verify's `login != "dependabot[bot]"` check and been
skipped, meaning this workflow would silently never merge or label ANYTHING
-- the whole point of the PR, defeated by one unverified assumption about
an API response shape. Same root-cause class as the earlier PR-body-vs-
commit-message mistake: an API's output shape assumed, not exercised,
before this rehearsal.

Fixed: Verify now uses `gh api repos/.../pulls/{n}` (REST), matching
Classify's own API family. REST's `state` field is also lowercase ("open"),
unlike GraphQL's "OPEN" -- fixed that comparison too.

Re-rehearsed the full Resolve -> Verify -> Classify chain against the same
real PR (#763) after the fix: Resolve gives number=763/skip=false, Verify
now gives skip=false (previously would have been skip=true), Classify gives
major-or-other (correct -- #763 has 4 major bumps mixed into a grouped PR).
Also spot-checked Verify against a real CLOSED PR (#761) to confirm the
state check still correctly skips a non-open PR.

pytest -q: 2616 passed (unchanged -- no app code touched). actionlint:
clean.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

* build(deps): option B for anthropic/google-api-python-client (patch auto, minor waits) + 7-day pip cooldown

Trisha 2026-10-14: loosen the always-review list to option B and add a
7-day cooldown for all Python packages; github-actions bumps keep waiting
for review.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJGRkvcMqZiokCF6rN3dnd

---------

Co-authored-by: Trisha Kunst <13664006+tkunst@users.noreply.github.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>