fix(initiative-driver): auto-drive every initiative:auto epic, not just #495

[don-petry]

Why

While monitoring the auto-implementation of epic #676, I found it had silently stalled. Adding initiative:auto to #676 flipped the safety gate but started nothing, and on its own it never would, because of two gaps in the driver:

1. Nothing triggered the driver from arming an epic. initiative-driver.yml only ran on issues:closed, a 6-hourly schedule, and workflow_dispatch. No trigger fired when initiative:auto was added — so the documented hand-off (★ human adds initiative:auto → initiative-driver → dev-lead) had no edge.
2. The automatic paths were pinned to epic Initiative: Safe Release Strategy for Agentic Workflows (versioning · rings · canary) #495. EPIC: ${{ github.event.inputs.epic || '495' }} — on schedule/issues:closed there are no inputs, so EPIC always resolved to 495. The cron and every issue-close drove only Initiative: Safe Release Strategy for Agentic Workflows (versioning · rings · canary) #495; MCP-powered review enrichment for the self-hosted Claude review engine (engine.sh) #676 (and any future epic) could never be picked up automatically.

This is the exact follow-up the design doc already flagged: "Generalize EPIC beyond the hard-coded 495 default if a second initiative adopts the driver."

(Adding the label did fire dev-lead.yml via issues:[labeled], but dev-lead acts only on the dev-lead label, so that run was a harmless no-op.)

What changed

• scripts/initiative-driver.sh — add sweep mode: when EPIC is empty, discover every open issue carrying initiative:auto and drive each. Per-epic logic is extracted into drive_epic(); single-epic mode (explicit dispatch) is byte-for-byte unchanged.
• .github/workflows/initiative-driver.yml —
  • trigger on issues:[labeled] so arming an epic starts it immediately (job if filters to the initiative:auto label so unrelated label changes don't sweep);
  • stop defaulting EPIC to 495 — automatic triggers run blank ⇒ sweep all armed epics; workflow_dispatch still accepts an optional epic to target one;
  • only pass CLOSED_ISSUE on actual close events (avoids mistaking a labeled epic's own number for a closed sub-issue);
  • single global concurrency lane so sweeps/close events serialize on label application.
• tests/test_initiative_driver.bats — add sweep-mode coverage (multi-epic discovery + empty no-op). All 10 tests pass.
• docs — document the labeled trigger + sweep behavior; resolve both listed follow-ups.

Verification

• shellcheck --severity=warning -x scripts/initiative-driver.sh — clean
• bats tests/test_initiative_driver.bats — 10/10 pass (8 existing + 2 new)

Note on #676

This PR fixes the mechanism but does not itself kick off #676 (that spends agent budget and opens PRs). Once merged, arming any epic — or re-arming #676 — will start it automatically. If you'd rather start #676 now without waiting for the merge, I can dispatch initiative-driver.yml with epic=676.

https://claude.ai/code/session_01RfwDpKTkNEBHjEMDcGkTY3

---

Generated by Claude Code

Summary by CodeRabbit

• New Features

  • Initiative-driver workflow now supports sweep mode to process multiple epics automatically, in addition to targeting specific epics via manual dispatch.

• Documentation

  • Updated operational runbook with explicit commands for arming and managing the initiative automation process.
  • Clarified workflow trigger behavior and epic selection modes.

• Tests

  • Added comprehensive test coverage for multi-epic sweep functionality and edge cases.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Warning

Review limit reached

@don-petry, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 54 minutes and 36 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: ad816fc2-411e-42e7-8cd7-0fdbb16d87c4

📥 Commits

Reviewing files that changed from the base of the PR and between 96026cb and 07763f7.

📒 Files selected for processing (2)

• scripts/initiative-driver.sh
• tests/test_initiative_driver.bats

📝 Walkthrough

Walkthrough

scripts/initiative-driver.sh is refactored from a single-epic script into a drive_epic() function plus a two-mode entrypoint: single-epic when EPIC is set, sweep across all open initiative:auto-labeled epics when blank. The workflow gains a labeled trigger (guarded to initiative:auto), a blank-default epic dispatch input, a global concurrency group, and conditional CLOSED_ISSUE population. Two new bats sweep-mode tests and updated documentation accompany the changes.

Changes

Initiative Driver Sweep Mode

Layer / File(s)	Summary
drive_epic() function and sweep entrypoint scripts/initiative-driver.sh	EPIC defaults to empty; validation accepts empty or positive integer; all single-epic logic moves into drive_epic() using return-based control flow; the entrypoint either calls drive_epic once or discovers all open gated epics and iterates with an aggregate exit code.
Workflow triggers, env, and concurrency .github/workflows/initiative-driver.yml	issues trigger gains labeled event; workflow_dispatch epic input defaults to blank; EPIC env is blank unless dispatched; CLOSED_ISSUE is populated only on close events; concurrency group changed to global initiative-driver; job-level if condition filters labeled events to initiative:auto only.
Bats sweep-mode tests tests/test_initiative_driver.bats	Two new tests cover sweep mode: one with two mocked gated epics asserting "Found 2 gated epic(s)" and per-epic "Driving epic" output with no issue edit calls, and one with no matching epics asserting the no-op message and no issue edit.
Documentation and runbook updates docs/initiatives/agentic-release-strategy-orchestration.md	Trigger description updated to list all event sources; new bullets explain immediate arming via initiative:auto label and sweep-mode behavior; runbook adds explicit gh issue edit <epic> --add-label initiative:auto arm command; follow-ups checklist marks bats test and sweep generalization as completed.

Sequence Diagram(s)

sequenceDiagram
    participant GH as GitHub Events
    participant WF as initiative-driver.yml
    participant SH as initiative-driver.sh
    participant API as gh CLI / Issues API

    GH->>WF: issues.labeled (initiative:auto) OR issues.closed OR workflow_dispatch
    WF->>WF: if labeled event, guard: label == initiative:auto?
    WF->>SH: run with EPIC (blank or number), CLOSED_ISSUE (close events only)
    alt EPIC is set
        SH->>SH: drive_epic(EPIC)
    else EPIC is blank (sweep)
        SH->>API: gh search: open issues with GATE_LABEL
        API-->>SH: list of epic numbers
        loop for each epic
            SH->>SH: drive_epic(epic)
        end
    end
    SH->>SH: gate check, sub-issue filter, blocker check, in-flight cap
    SH->>API: gh issue edit --add-label DEV_LEAD_LABEL (or DRY_RUN log)

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• petry-projects/.github-private#507: Implements the original single-epic initiative-driver with dependency-aware dev-lead labeling that this PR generalizes into drive_epic() and sweep mode.

Suggested labels

documentation, enhancement, initiative

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: enabling the initiative-driver to handle multiple epics with the initiative:auto label instead of just epic #495.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/monitor-automation-676-goz2q6

---

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 and usage tips.}

[don-petry]

Dev-Lead — waiting on PR blockers (intent: review-changes)

PR: #683
No changes were committed, but the PR still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews). The retry cron will re-attempt automatically. Next attempt after: 2026-06-14T03:11:16Z

[don-petry]

Note

@don-petry I reviewed this PR and no code changes were needed, but it still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews), so I cannot mark it done yet. I'll re-check automatically.
Next attempt after: 2026-06-14T03:11:16Z

[gemini-code-assist]

Code Review

This pull request introduces a 'sweep' mode to the initiative driver script, allowing it to automatically discover and drive all open epics carrying the 'initiative:auto' label when no specific epic is provided. It refactors the core logic into a reusable 'drive_epic' function, updates the documentation, and adds BATS tests to verify the new sweep behavior. The review feedback highlights a critical Bash issue where 'set -e' is disabled inside the function when executed as part of an OR list, which could silently mask API failures. Additionally, the feedback recommends declaring the loop variable 'n' as local to prevent scope leakage and removing a redundant associative array re-initialization that could cause errors in older Bash versions.

[don-petry]

Dev-Lead — fix-bot-comment (no-changes)

Agent reasoning

Issues addressed: 0
Files changed: none
Skipped (informational): 0
Status: PR is in good shape — quality gate passed with no issues detected.
```

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@scripts/initiative-driver.sh`:
- Around line 66-68: The regex pattern `^[0-9]+$` in the EPIC validation check
(line 66) currently allows "0" as a valid value, but the error message correctly
states that EPIC must be a "positive integer," which excludes zero. Fix this by
replacing the regex pattern with one that rejects zero while accepting all
positive integers, such as `^[1-9][0-9]*$`, which ensures the first digit is 1-9
followed by any number of digits 0-9, thereby excluding zero and matching the
positive-integer contract stated in the error message.

In `@tests/test_initiative_driver.bats`:
- Around line 171-194: The test "sweep: drives every open epic carrying
initiative:auto when EPIC is empty" verifies that the script logs discovery and
driving messages correctly, but lacks an explicit assertion that no label
mutations occur when both epics have no sub-issues. Add a GH_LOG check after the
existing output assertions to verify that the gh command log contains only the
discovery query and no mutation commands (no edits to labels), similar to the
pattern used in the empty-sweep test.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4917eb78-2b75-46cc-bb7a-9b68a08b646b

📥 Commits

Reviewing files that changed from the base of the PR and between 9227d26 and 96026cb.

📒 Files selected for processing (4)

• .github/workflows/initiative-driver.yml
• docs/initiatives/agentic-release-strategy-orchestration.md
• scripts/initiative-driver.sh
• tests/test_initiative_driver.bats

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[don-petry]

Dev-Lead — waiting on PR blockers (intent: fix-reviews)

PR: #683
No changes were committed, but the PR still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews). The retry cron will re-attempt automatically. Next attempt after: 2026-06-14T03:20:41Z

[don-petry]

Dev-Lead — fix-reviews (no-changes)

Agent reasoning

Addressed 0 threads:
(no open review threads exist)
Test verification: pass — CI shows bats, shellcheck, unit-tests, and all other required checks succeeded on HEAD (96026cb)
Files changed: none
```
The PR is clean: no open threads, no CI failures, no CHANGES_REQUESTED reviews. It is ready for merge.

[donpetry-bot]

Automated review — APPROVED ✓

Risk: MEDIUM
Reviewed commit: 07763f78a4725014f9d4a53ef6b06e608a9f9560
Cascade: triage → deep (triage: haiku 4.5 → deep: opus 4.8 + duck: o4-mini → audit: fable 5)

Summary

Adds sweep mode to initiative-driver so automatic triggers drive every initiative:auto epic instead of the hard-coded #495, plus an issues:[labeled] trigger gated to the gate label. The triage's escalation signal (Gemini 'n not local') is already resolved at head, and the errexit OR-list trap is correctly avoided with a per-epic subshell. Both CodeRabbit findings (EPIC regex accepting '0'; missing mutation assertion in sweep test) are fixed and CodeRabbit re-approved; functional CI gates (shellcheck, bats/unit-tests, CodeQL, SonarCloud, gitleaks) are green.

Findings

• INFO: Gemini's escalated finding ('n' leaking to global scope in drive_epic) is already addressed at head: 'n' is in the local declaration list (scripts/initiative-driver.sh:95). Triage's signal was stale.
• INFO: Errexit handling for the sweep is correct: each epic runs in a standalone 'set -e' subshell '( set -e; drive_epic "$e" )' rather than an OR-list, so a gh API failure aborts that epic (surfaced as ::error:: and rc=1) instead of being silently masked as a false 'no sub-issues'. The single-epic dispatch path calls drive_epic as a simple command, keeping errexit active.
• INFO: No security regression: workflow permissions remain 'contents: read' (mutations use the PAT); the issues:[labeled] trigger is gated by job-level if to the 'initiative:auto' label; EPIC/CLOSED_ISSUE flow through env vars (not ${{ }} run-shell interpolation) and are regex-validated in the script; discovery/sweep values are integer issue numbers from jq.
• INFO: EPIC validation tightened per CodeRabbit: now '^[1-9][0-9]*$' (rejects '0' and empty-vs-number ambiguity) with empty permitted for sweep mode.

---

Reviewed by the PR-review cascade (triage: haiku 4.5 → deep: opus 4.8 + duck: o4-mini → audit: fable 5). Reply if you need a human review.