Canary blocker: pr-review-mention ring1->stable (cum_fail=1, REGRESSION)

[petry-projects-release-manager]

Automated canary-rollout blocker. The release gate is holding pr-review-mention and will not promote it until this clears. Filed + maintained by the Canary Rollout workflow (gate standard: .github#548); this issue is regenerated each run and auto-closes when the gate passes — do not edit the table below by hand.

field	value
agent	pr-review-mention
transition	ring1->stable
candidate	59197352a583
host repo	petry-projects/.github
cumulative failures	1 (startup_failures: 0)
triage	REGRESSION

⛔ REGRESSION — the candidate changed the reusable and a run failed since its cut. HALT + hold; investigate and roll back rather than --override. (labelled needs-human)

Failing runs in the per-candidate window

• petry-projects/.github-private — run 36552470138; failed steps: unknown

---

Whole-fleet status is in the Canary Rollout workflow run's job summary (Actions → Canary Rollout → latest run → Summary).

[don-petry]

Dev-Lead: Triage — no autonomous code change (needs-human REGRESSION)

I picked this up via the dev-lead label, but this is an auto-generated
canary-rollout REGRESSION blocker (needs-human + canary-blocker), not an
implementable feature/bug spec. Per the gate standard (.github#548) and this
issue's own body — "HALT + hold; investigate and roll back rather than
--override" — the correct response is human investigation + rollback, not
an autonomous dev-lead code change. I have made no source changes and have
not edited the table above.

What I verified (read-only)

• Failing run 36552470138
  (.github-private, caller .github/workflows/pr-review-mention.yml, PR #1976):
  conclusion: failure, jobs: [] — zero jobs ran — with GitHub's
  "This run likely failed because of a workflow file issue." That is a
  workflow-file / reusable-interface failure: the uses: call never
  validated into a job. This is the channel-skew / interface-mismatch signature
  (Codify the off-peak scheduling standard and offset this repo's 11 minute-0 crons #1052) the dev-lead guardrail warns about.
• The caller pins pr-review-mention-reusable.yml@pr-review-mention/v2-next;
  v2-next resolves to the candidate 59197352a583.
• Candidate 59197352a583 is not present in this repo's tree (not fetchable;
  no ref contains it). I cannot see, run, or fix the exact reusable version that
  is failing.
• The current main HEAD reusable is valid YAML; its workflow_call declares
  only secrets (GH_PAT_DON_PETRY optional, GH_PAT_WORKFLOWS +
  DON_PETRY_BOT_GH_PAT required), and the caller forwards a matching set — so
  the skew is between the caller and the candidate at the channel tag, not HEAD.

Why no dev-lead code change is appropriate

1. The failing artifact (candidate reusable + the .github-private caller) is
   outside this .github workspace — a fix can't be reproduced or verified here.
2. Any fix committed to main becomes a new candidate that must re-soak
   next→ring0→ring1; it cannot clear this blocker, which is bound to
   candidate 59197352a583 and auto-closes only when the gate passes for that frontier.
3. Define the release soak standard (ring-promotion gate): time floor + traffic-scaled sample + health #548 + this issue mandate rollback, not --override, for a REGRESSION —
   a release-ops decision that is explicitly needs-human.
4. The guardrail forbids the tempting "fix" (adding/altering with:/secret
   forwards across the channel pin) — that would itself be the Codify the off-peak scheduling standard and offset this repo's 11 minute-0 crons #1052 defect.

Recommended human next steps

• Investigate the candidate: diff the candidate reusable at
  pr-review-mention/v2-next (59197352a583) against the prior stable channel
  (pr-review-mention/v2-stable) to find the workflow_call interface change
  (renamed/removed/newly-required secret or input) that makes the caller fail to
  validate. The jobs: [] + "workflow file issue" symptom points at an
  interface break, not a runtime logic bug.
• Roll back, don't override: re-point the affected channel to the last-good
  candidate via scripts/cut-standards-release.sh / the release tooling per
  .github#548, rather than promote --override.
• Land the correct interface fix on the reusable first, then re-cut/advance the
  channel through the rings (the three-step sequencing in AGENTS.md → "Caller-stub
  input forwarding across channel pins"). Only then will a healthy candidate clear
  this gate and auto-close this issue.

No PR will follow from me for this issue — there is no in-repo change to make.

[petry-projects-release-manager]

✅ Gate cleared — pr-review-mention is now PROMOTE. Closed automatically by canary-rollout.