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

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 central driver only sweeps .github-private.

The central driver (scripts/initiative-driver.sh + .github/workflows/initiative-driver.yml) is pure-bash (no claude-code-action, so no discussion-event limit) and the script already resolves every gh call against $REPO. The remaining work is a small workflow parameterization plus the fleet plumbing/observability/docs/pilot that mirror the initiative-planner fleet-enablement (#817), minus the 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 cover a non-self target_repo sweep.
2. Per-repo caller stub standards/workflows/initiative-driver.yml (in petry-projects/.github) that, on the host repo's issues:[closed,labeled] + a safety-net schedule, dispatches the central driver with target_repo=<host> via 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 the in-repo pipeline diagram + driver runbook to show initiative→implementation cross-repo (and cross-reference the ci-standards.md §10 enrollment 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.

Success metrics (how we'll know it worked)

• petry-projects/.github epic [Phase 1] Tag protection + document scoped mutable-ref exception to SHA-pin standard #505 auto-releases its full ready DAG cross-repo with zero manual dev-lead labels (the gap the pilot exposed is closed).
• ≥1 fleet repo (.github) enrolled with an aligned driver stub — Fleet Monitor reports 0 drifted driver stubs among enrolled repos.
• Cross-repo release latency: a story is released within one safety-net cron interval (≤6h) of its blockers closing — typically near-immediate via the stub's issues:[closed] event.
• The initiative-driver canary is green (cross-repo dry-run dispatch path healthy).

Cost cap / budget bound

• The driver itself is no-LLM (pure-bash gh API). The canary runs dry-run only (dry_run=true ⇒ logs decisions, labels/creates nothing ⇒ zero dev-lead/LLM cost). The only LLM spend is downstream dev-lead pickups, already bounded by MAX_IN_FLIGHT (default 2 released sub-issues per epic). The pilot is scoped to one epic ([Phase 1] Tag protection + document scoped mutable-ref exception to SHA-pin standard #505). This initiative introduces no new recurring LLM spend.

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; cutting initiative-driver/* release channels (see open question — depends on [Phase 1] Generalize cut-release.sh + the release standard to cover non-agent reusables #686 and the driver's dispatch model).

Companion to #817 (idea→initiative). The driver half is independent and ships on its own.

Untracked prerequisites

• Stories 2 and 6 are cross-repo: the per-repo caller-stub template (standards/workflows/initiative-driver.yml) and the §10 enrollment runbook land in petry-projects/.github (a separate, PUBLIC repo), and the pilot enrolls + arms an epic there. dev-lead operating on a .github-private issue cannot author files in petry-projects/.github, so these are hands_off — a maintainer raises those PRs / performs the enrollment in petry-projects/.github.
• Each enrolled fleet repo must expose GH_PAT_WORKFLOWS (with read access to petry-projects/.github-private) as an org/repo secret so its stub can dispatch the central driver — a workflow_dispatch fired with GITHUB_TOKEN is accepted but never starts a run (loop prevention).
• A fixture target repo/epic for the driver canary must be configured (repo variable, e.g. INITIATIVE_DRIVER_CANARY_TARGET / INITIATIVE_DRIVER_CANARY_EPIC, with a workflow_dispatch override) for Story 3 to exercise the cross-repo dispatch path.

Planned from idea discussion #877 by the BMAD Scrum Master initiative-planner. Inert until a maintainer adds initiative:auto.