Initiative: Fleet-enable the initiative-driver (per-repo stub → central driver, target_repo)

[don-petry]

Summary

Fleet-enable initiative-driver so any repo's initiative:auto epic auto-releases its ready stories to dev-lead cross-repo — completing the initiative→implementation half of the pipeline (the idea→initiative half shipped via #817). The .github pilot exposed the gap: epic #505's stories had to be released by hand because the driver only sweeps .github-private.

Background (verified)

• initiative-driver.yml is pure-bash (no claude-code-action) → no discussion-event limitation. REPO is hardcoded github.repository (:54); concurrency is a single global group (:50); scripts/initiative-driver.sh already accepts REPO.
• dev-lead.yml is already fleet-adopted, so a dev-lead label in any repo builds.
• Credentials: GH_PAT_WORKFLOWS (good-enough per Cross-repo write credentials for the central planner (GitHub App) #818); cross-repo dev-lead labeling already uses the PAT.
• Mirrors the initiative-planner fleet-enablement (Initiative: Fleet-enable the idea→initiative pipeline (Option A — per-repo stub → central planner) #817) but smaller — no creds/merge-guard/board stories.

Goals

1. Parameterize initiative-driver.yml on target_repo (REPO = target_repo || github.repository; concurrency rekeyed per target repo; cross-repo dev-lead labeling via GH_PAT_WORKFLOWS). Script logic unchanged. Bats for a non-self target_repo sweep.
2. Per-repo caller stub + dispatch reusable (standards/workflows/initiative-driver.yml) triggering on issues: [closed, labeled] + a safety-net schedule, dispatching the central driver with target_repo=<host>. Pure gh workflow run (no LLM), PAT-guarded.
3. Canary + Fleet Monitor coverage of the driver's cross-repo release path (mirror initiative-planner-canary.yml / Live idea:approved canary + Fleet Monitor coverage #822).
4. Docs — extend ci-standards + the pipeline diagram to show initiative→implementation cross-repo; add driver enrollment to the runbook.
5. Pilot on .github — enroll the driver stub, arm epic [Phase 1] Tag protection + document scoped mutable-ref exception to SHA-pin standard #505 with initiative:auto, confirm it auto-releases [Phase 2] Reusable workflow must run scripts at the caller's channel ref (no silent version mismatch) #506→successors cross-repo with no manual labeling.

Release / rollout

Bring the initiative-driver reusable under the existing canary/ring framework (epic #495 / cut-release.sh): cut initiative-driver/{next,ring0,ring1,stable}; repos pin their ring; promotion is health-checked per the maintainer gate.

Acceptance criteria

• initiative-driver.yml honors target_repo; concurrency keyed per repo; bats cover a non-self sweep.
• standards/workflows/initiative-driver.yml stub + dispatch reusable, PAT-guarded.
• Canary + Fleet Monitor cover the new stub.
• ci-standards + pipeline diagram + enrollment runbook updated.
• Pilot: .github epic [Phase 1] Tag protection + document scoped mutable-ref exception to SHA-pin standard #505 auto-releases its DAG cross-repo (no manual dev-lead labels).

Out of scope

• MAX_IN_FLIGHT per-repo tuning; least-privilege App (Cross-repo write credentials for the central planner (GitHub App) #818 deferred); changes to planner/triage/enhancer beyond docs.

Companion to #817 (idea→initiative). Add idea:approved to hand to the BMAD Scrum Master.

[github-actions[bot]]

📋 Initiative planned by the BMAD Scrum Master (Bob).

Epic #882 — Initiative: Fleet-enable the initiative-driver (per-repo stub → central driver, target_repo)

6 stories created (inert — labelled initiative, NOT initiative:auto):

• [Phase 1] Parameterize initiative-driver.yml on target_repo + bats for a non-self sweep #883 (M) — [Phase 1] Parameterize initiative-driver.yml on target_repo + bats for a non-self sweep
• [Phase 2] Add the per-repo initiative-driver caller-stub template (dispatch central driver with target_repo) #884 (M) — [Phase 2] Add the per-repo initiative-driver caller-stub template (dispatch central driver with target_repo)
• [Phase 3] Add an initiative-driver canary over the cross-repo release path #885 (M) — [Phase 3] Add an initiative-driver canary over the cross-repo release path
• [Phase 3] Extend Fleet Monitor stub-drift coverage to the initiative-driver stub #886 (M) — [Phase 3] Extend Fleet Monitor stub-drift coverage to the initiative-driver stub
• [Phase 4] Document the initiative→implementation cross-repo path: pipeline diagram + driver runbook #887 (S) — [Phase 4] Document the initiative→implementation cross-repo path: pipeline diagram + driver runbook
• [Phase 5] Pilot on .github: enroll the driver stub, arm epic #505, confirm cross-repo auto-release #888 (M) — [Phase 5] Pilot on .github: enroll the driver stub, arm epic [Phase 1] Tag protection + document scoped mutable-ref exception to SHA-pin standard #505, confirm cross-repo auto-release

Open questions for review:

• Release channels: should we also cut initiative-driver/{next,ring0,ring1,stable} channel tags under the Initiative: Safe Release Strategy for Agentic Workflows (versioning · rings · canary) #495 release framework? Unlike dev-lead/pr-review (pinned via workflow_call @channel), the driver stub dispatches the central workflow via gh workflow run, which always runs .github-private@main — so there is no per-caller version pin to advance. Cutting such channels also depends on [Phase 1] Generalize cut-release.sh + the release standard to cover non-agent reusables #686 (generalize cut-release.sh beyond pr-review|dev-lead — its valid_agent currently allows only those two). Confirm whether ring channels apply to the dispatch-style driver, or whether @main + canary is the intended rollout (in which case this stays out of scope, per the epic body).

---

Review the epic and its sub-issue DAG, adjust as needed, then add initiative:auto to epic #882 to hand it to initiative-driver for auto-implementation.

[github-actions[bot]]

Enhancement: Fleet-enable initiative-driver (#877)

Sharpened problem & goal

The initiative-driver.yml workflow already accepts a target_repo input for manual dispatch, and the underlying scripts/initiative-driver.sh reads REPO from the environment. The gap is automatic event-driven triggering: when an issue closes (or is labeled initiative:auto) in a fleet repo like .github or broodly, the driver in .github-private never sees the event — so the DAG re-evaluation that should kick off the next story doesn't happen until the scheduled cron fires (~6 hours later, worst case).

Clarifying question worth resolving early: should enrolled repos receive their own per-repo thin-caller stub (analogous to pr-review-trigger.yml → pr-review.yml) that emits a repository_dispatch to .github-private on issues:closed/labeled, or should .github-private poll enrolled repos on schedule (simpler, but latency ≤ cron cadence)?

Context

The initiative-planner already solved this pattern at the planning layer: it runs cross-repo and accepts target_repo from a stub dispatch. The driver is the "implementation half" of the same pipeline and needs the same fleet shape. The .github epic #505 (referenced in the discussion) exposed the manual-label workaround clearly: a story was ready but sat until a human noticed, because the driver only swept petry-projects/.github-private.

The pr-review-trigger.yml → pr-review.yml (reusable-caller) split is the established pattern: a thin per-repo stub responds to local events, calls the central reusable with target_repo set, and the reusable runs with the .github-private-hosted scripts. The driver has no reusable counterpart yet — it's a single .yml with a bash script call.

An alternative is a fleet manifest file (like scripts/lib/consumer-manifest.json already used for downstream-impact), listing enrolled repos; the schedule + close events would iterate it. This avoids per-repo stub proliferation but introduces manifest-drift risk.

Impact / Effort

Approach	Impact	Effort
Per-repo thin-caller stub → repository_dispatch to .github-private driver	HIGH	M — new stub template; needs org secret propagation
Fleet manifest + schedule sweep (no stubs)	MEDIUM	S — simpler; latency bounded by cron cadence

HIGH impact because it closes the manual-release gap that blocked an active epic; MEDIUM/S because the bash script and workflow already handle target_repo — the work is the dispatch plumbing.

Suggested acceptance criteria

• When a sub-issue closes in a fleet-enrolled repo (e.g. petry-projects/.github), the driver re-evaluates that repo's epic DAG within the schedule cron cadence or within 5 minutes via an event-driven path — whichever approach is chosen.
• A new repo variable or fleet manifest entry is the only operator action needed to enroll a new repo; no .github-private code change required.
• Existing .github-private-only driver runs (self-hosting path) are unaffected — no regression in sweep behavior or concurrency group keying.
• A dry_run end-to-end test demonstrates a story in a second repo advancing from "blocked" → "labeled dev-lead" without manual intervention, documented in the PR description.
• concurrency: group is keyed per target repo (already done for dispatch; verify the thin-caller emits a unique key for issues:closed events so per-repo sweeps don't queue behind each other).