dev-lead fix-review won't act on advisory-bot nitpick threads (green CI + CHANGES_REQUESTED, empty machine findings → status=no-changes → PR stalls on human)

[don-petry]

Problem

When a PR's CI is fully green but its reviewDecision is CHANGES_REQUESTED solely because an advisory bot (CodeRabbit / Gemini / qodo) left review threads that the fix-review classifies as nitpick-level with no machine "Findings to fix", dev-lead's fix-review returns status=no-changes and the PR sits BLOCKED (CHANGES_REQUESTED) indefinitely. Neither the threads get addressed nor resolved, and the PR is not even needs-human-labeled — a human must hand-fix or manually resolve the threads to unblock the merge.

This is the green-CI sibling of #888 (which covers red required checks with no finding). Same failure signature — silent no-changes that looks 'done' but is actually stuck — but the trigger here is advisory review threads on a green PR, not a self-introduced red check.

Concrete case (2026-07-23)

PR #887 (implementing #886, repo-template re-seed fix):

• CI fully green on head 73c40919 (CodeRabbit, SonarCloud, CodeQL, bats, Graphite all SUCCESS).
• Blocked only by two unresolved CodeRabbit threads, both self-labeled 🔵 Trivial / Quick win:
  • scripts/seed-repo-template.sh:74 — agent_ref: line not validated by _assert_vform_pins (a real but minor validation-symmetry gap).
  • tests/test_seed_repo_template_workflows.bats:92 — no test for the _emit_workflow name-validation guard.
• pr-review agent held at CHANGES_REQUESTED; dev-lead's last code commit was the initial implementation ~12h earlier — it never re-engaged on the CodeRabbit threads because the machine "Findings to fix" payload was empty.
• Result: PR stuck; a human hand-fixed both nitpicks + resolved the threads to unblock.

Expected

When a PR is green but CHANGES_REQUESTED, dev-lead's fix loop should either:

1. Address the advisory threads even when they carry no structured machine finding — parse the thread bodies (they contain concrete, actionable, often 'quick-win' suggestions) and fix or reply, or
2. Resolve them as acknowledged with a rationale when they're genuine no-ops, or
3. Escalate to needs-human naming the specific unresolved threads.

Silent no-changes that leaves the PR CHANGES_REQUESTED with live advisory threads is the worst outcome — it reads as 'done' but is actually blocked on human intervention.

Scope

• In the fix-review loop, treat reviewDecision == CHANGES_REQUESTED with unresolved advisory-bot threads as a first-class actionable state, even when the structured findings list is empty.
• Distinguish 'nitpick / acknowledge-and-resolve' from 'actionable-fix' from 'needs-human', and take the corresponding action rather than returning no-changes.

Related

• dev-lead fix-review ignores CI-check regressions it introduced (red bats/lint with no review finding → status=no-changes, PR stuck) #888 (red required check it introduced → no-changes) — same silent-stall class, complementary trigger.
• Part of Epic Epic: Fully-automated fleet-wide version+channel shim compliance (no manual deploy / admin-merge) #850 convergence tail (surfaced hand-landing feat: implement issue #886 — [#850] repo-template baseline re-seed pins BARE @dev-lead/stable — reverts the v<M>-stable convergence (flapping) #887).

[don-petry]

Dev-Lead Implementation Plan

Issue: #892 — dev-lead fix-review won't act on advisory-bot nitpick threads (green CI + CHANGES_REQUESTED, empty machine findings → status=no-changes → PR stalls on human)

Root cause

In scripts/dev-lead-fix-reviews.sh, the no-changes decision tree only consults per-review state == CHANGES_REQUESTED (ALL_REVIEWS_JSON), failing CI, and unresolved bot threads. It never consults the PR-level reviewDecision. So a green-CI PR whose reviewDecision == CHANGES_REQUESTED is driven purely by advisory-bot review threads (which carry no structured machine finding) can slip through to a silent status=no-changes. The fix-reviews.md prompt likewise treats advisory threads as non-actionable when there is no structured "Findings to fix" payload, so the engine returns no-changes instead of addressing / acknowledging / escalating the threads.

Scope

Make reviewDecision == CHANGES_REQUESTED a first-class blocker in the fix-review loop, and instruct the engine to treat advisory-bot threads (no structured finding) as actionable — fix, acknowledge-and-resolve, or escalate to needs-human naming the threads — never silent no-changes.

Implementation Checklist

• scripts/dev-lead-fix-reviews.sh — fetch_pr_context: fetch the PR's reviewDecision via GraphQL and export REVIEW_DECISION (fail-soft to empty).
• scripts/dev-lead-fix-reviews.sh — has_hard_blockers: additionally treat REVIEW_DECISION == CHANGES_REQUESTED as a hard Tier-1 blocker so the loop never posts a silent no-changes terminal in that state.
• scripts/dev-lead-fix-reviews.sh — export REVIEW_DECISION to the fix-reviews prompt context.
• prompts/dev-lead/fix-reviews.md — add REVIEW_DECISION to VARIABLES + context; add explicit guidance that advisory-bot threads with no machine finding are first-class actionable, with a 3-way classify (actionable-fix / acknowledge-and-resolve / needs-human escalation naming the threads) and a "never return no-changes while unresolved advisory threads remain" rule.

Tests to Write (tests/dev-lead/unit/test_fix_reviews.bats)

• Green CI + reviewDecision == CHANGES_REQUESTED + no per-review CHANGES_REQUESTED record + no bot threads + no code changes → must NOT post status=no-changes (treated as hard blocker).
• REVIEW_DECISION is fetched (GraphQL reviewDecision) and surfaced; null/absent reviewDecision does NOT create a phantom blocker (regression guard — clean PR still posts no-changes).
• fix-reviews.md prompt declares REVIEW_DECISION and contains the advisory-thread-first-class + needs-human escalation guidance.

Test Command

bats tests/dev-lead/unit/test_fix_reviews.bats (+ shellcheck --severity=warning -x scripts/dev-lead-fix-reviews.sh)

[don-petry]

dev-lead: issue #892 addressed — advisory-bot CHANGES_REQUESTED no longer stalls on silent no-changes

Problem: When a PR had green CI but reviewDecision == CHANGES_REQUESTED driven solely by advisory-bot review threads (CodeRabbit / Gemini / qodo / Copilot) classified as nitpicks with no structured machine finding, the fix-review loop posted a silent status=no-changes terminal and the PR stalled indefinitely on a human.

Root cause: has_hard_blockers() only inspected per-review CHANGES_REQUESTED records and failing CI checks. A PR can be CHANGES_REQUESTED at the PR level (blocking merge) while carrying no per-review CHANGES_REQUESTED record — so that state slipped through to the no-changes terminal.

Fix (3 files, all in .dev-lead/):

• scripts/dev-lead-fix-reviews.sh
  • fetch_pr_context() now fetches the PR-level reviewDecision via GraphQL and exports it (fail-soft to empty on transient error).
  • has_hard_blockers() now treats REVIEW_DECISION == CHANGES_REQUESTED as a first-class Tier-1 blocker, in addition to failing CI and per-review CHANGES_REQUESTED. This routes the loop to a retry marker instead of a silent stall.
• prompts/dev-lead/fix-reviews.md
  • Added REVIEW_DECISION to the VARIABLES header.
  • Phase 0 now instructs the engine to treat unresolved advisory threads as first-class actionable when reviewDecision == CHANGES_REQUESTED with an empty findings list, via exactly one of: (1) actionable-fix + reply + resolve, (2) acknowledge-and-resolve with a rationale (never silent), or (3) escalate to needs-human (apply needs-human-review label + PR comment naming the specific threads). Explicitly forbids returning no-changes while that state holds.

Tests (TDD, written first) — tests/dev-lead/unit/test_fix_reviews.bats:

• reviewDecision=CHANGES_REQUESTED blocks no-changes with green CI + no review records (fix-reviews intent)
• same, review-changes intent
• reviewDecision=APPROVED does not create a phantom blocker (regression guard — still posts no-changes)
• prompt declares REVIEW_DECISION in the VARIABLES header
• prompt instructs the engine to treat advisory threads with no machine finding as actionable

Verification:

• New tests: 5/5 pass
• Full test_fix_reviews.bats: 84 pass / 8 fail — the 8 failures are the pre-existing rate-limit baseline, unrelated to this change (no new regressions)
• shellcheck --severity=warning -x on the modified script: clean
• Repo lint (dev-lead-lint.sh): all checks passed

No commit/push performed — CI handles git operations.