[melodic-automation-lanes]

Closes #8432

Summary

Opened by the work-resolve-issue lane. The run's own summary:

Per the recorded decision on ＃8432, the watch for pr-verify verdicts lost to permission denials moves from an open issue to a monthly row in .github/recurring-schedule.json, as ＃9701 did for other outside triggers. The row runs the issue's gh run list query, names both ::error::no verdict permission-denial messages and the verify:missing refusals behind them, and states the two outcomes: injected PR text keeps the refusal; benign-read denials recurring (2 or more lane PRs refused verify:missing in 30 days) get a fix issue, trying the automatic pr-require-checks rerun first, then a tighter prompt.

Not verified

• Changes left uncommitted in the working tree, per the lane's instruction that the runner turns them into a patch
• The row's first run (listing failed pr-verify runs on main and judging each denial benign or injected) is left to the schedule row or a person; this lane has no gh run history access, as decision item 3 records
• CI-only checks (actionlint, editorconfig, gitleaks, purged-em-dashes, line-citations and the other whole-repo scanners check-affected lists) are left to the PR's CI
• Note for whoever files the eventual fix issue (from the review, not verified end to end here): a github-actions rerun of pr-require-checks reaches pr-verify as a re-attempt that pr-verify trusts only through the lost-run reconciler's record (.github/scripts/maintenance-reconcile-lost-runs/reconcile.

Fix

• .github/recurring-schedule.json: added the monthly pr-verify-denial-watch row (last_checked 2026-10-26, next_due 2026-11-26) with the signal, query, threshold, the two outcomes, the person's benign-vs-injected call, and the options rejected for now

Verification

The runner ran each check from the base copy against 98f8e2a:

• scripts/check-changelog-fragments.sh --check: passed

The run reports:

• read .github/scripts/pr-verify/write-verdict.mjs:141, :153, :302: the two permission-denial messages and the ::error::no verdict: prefix the row greps for
• read .github/workflows/pr-verify.yml header and trigger: runs on main via workflow_run after pr-require-checks; the model reads only pr-verify-data
• read docs/conventions/pr-pipeline/README.md Verifier verdict and refusal list (1468-1517, 1571, 1596-1607, 1664): a denial uploads no verdict and fails the run; verify:missing, verify:fail, verify:earlier-fail and verify:repeated-fail semantics
• read .github/scripts/intake-triage/admit.mjs readSchedule/operatorConfirmation: the new row carries no precondition, so it needs no operator confirmation and parses like its siblings
• fresh-context review subagent over the diff: one confirmed finding (the rejected-option note overstated verify:earlier-fail as blocking every later head; README 1597-1607 says a later pass on a different change clears it), fixed
• check-changelog-fragments: all 2 fragments valid (no plugin changed, so no fragment owed)
• check-affected: 7 passed, 6 skipped over 1 changed file
• The lane run: https://github.com/melodic-software/claude-code-plugins/actions/runs/40284700051

Left out: the items under Not verified.

Related

#8432

[github-actions]

claude-security-review reviewed 98f8e2a692998b6a9f8b39d2eadcad7d15727f96: 0 finding(s), 0 as inline comments.

No security issues found. critical-findings: 0

The pull request adds one monthly row, pr-verify-denial-watch, to .github/recurring-schedule.json. I read the whole diff (1 file) and the PR context. I did not run anything. I did not read the schedule consumer (admit.mjs), so the claim that the row needs no operator confirmation comes from the PR text only.

• Trusted paths: the file matches none of the listed globs. It is not a trust control: it touches no trusted-actor list, token scope, kill switch, merge hold, broker config or pr-pipeline.yaml.
• Instruction surface: nothing is deleted, narrowed or softened. The row adds a person-gated watch.
• Manifests: the diff touches no plugin manifest, so no manifest <field> lines apply.
• Row contents: the notes text tells a person or schedule run to run a read-only gh run list query and read failed run logs. It adds no write action, token request or auto-merge path. It keeps the human call on whether a denial was a benign read or injected PR text. It also records that injected-text denials keep the verify:missing refusal, so the row weakens no control.
• PR context: it holds no embedded directives aimed at the lane.

Skip gate 2 applies: the change has no security-relevant surface. The change spends no money, so no cost hold applies. The recurring row costs nothing beyond subscription or prepaid usage when it runs.

[github-actions]

claude-review reviewed 98f8e2a692998b6a9f8b39d2eadcad7d15727f96: 0 finding(s), 0 as inline comments.

No findings. The PR adds one monthly row, pr-verify-denial-watch, to .github/recurring-schedule.json.

• Acceptance criterion for chore(pr-pipeline): watch pr-verify verdicts lost to permission denials #8432 (a row naming the ::error::no verdict permission-denial signal and the two outcomes): met. The row carries the issue's gh run list query, both denial messages, the verify:missing refusals behind them, the injected-text outcome (keep the refusal) and the benign-read outcome (2 or more lane PRs refused in 30 days, so file a fix issue, trying the automatic pr-require-checks rerun first, then a tighter prompt). It also records the two rejected options.
• Signal strings: I checked them against .github/scripts/pr-verify/write-verdict.mjs. Line 141 throws the run hit N permission denial(s): ..., line 153 throws the run's legs hit N permission denial(s), and line 302 prefixes ::error::no verdict:. The row's grep text matches.
• Schema: the new row has the same fields as its siblings (area: [], category: "general", triggers: [], close_previous: true). last_checked is 2026-10-26 and next_due is one month later. The JSON is valid.
• Not run: I did not run the row's gh run list query (this lane has no GitHub access). I did not check the README line citations the PR description gives (1468-1517 and others), and I did not run any tests or CI checks. Those PR-description claims are author-claimed and unverified by me.
• Spend: none. This is a scheduling-data change only, with no hold-class concern.