feat: enroll .github in the idea→initiative pipeline + document caller stubs

.github/workflows/initiative-planner.yml

@@ -0,0 +1,53 @@
+# ─────────────────────────────────────────────────────────────────────────────
+# SOURCE OF TRUTH: petry-projects/.github/standards/workflows/initiative-planner.yml
+# Standard:        petry-projects/.github/standards/ci-standards.md
+# Reusable:        petry-projects/.github/.github/workflows/initiative-planner-reusable.yml
+#
+# AGENTS — READ BEFORE EDITING:
+#   • This file is a THIN CALLER STUB. All idea→initiative dispatch logic (the
+#     `idea:approved` gate, the trusted-actor check, and the cross-repo dispatch
+#     to the central BMAD Scrum Master planner) lives in the reusable above.
+#   • You MUST NOT change: the `uses:` ref — it is pinned to the
+#     `initiative-planner/stable` channel, a moving tag advanced centrally.
+#     Never repoint it to `@main`, a SHA, or a frozen `@vX` (see
+#     ci-standards.md → Reusable workflow versioning). Also do not change the
+#     trigger events or the `secrets:` block.
+#   • If you need different behaviour, open a PR against the reusable in the
+#     central repo. A new release is rolled out by moving the channel tag
+#     centrally — never by editing callers, so no fanout PR is needed.
+# ─────────────────────────────────────────────────────────────────────────────
+#
+# Initiative Planner — approval trigger, thin caller for the org-level reusable.
+#
+# When a maintainer adds `idea:approved` to an Ideas Discussion in this repo,
+# the reusable re-dispatches the CENTRAL initiative-planner (BMAD Scrum Master
+# "Bob") in petry-projects/.github-private with this repo as the target. Bob
+# reads this repo's Discussion and materializes an inert epic + sub-issue DAG
+# here (labelled `initiative`, NOT `initiative:auto`). A maintainer then adds
+# `initiative:auto` to the epic to hand it to initiative-driver. The frameworks
+# and planning logic stay vendored once, centrally.
+#
+# To adopt:
+#   1. Copy this file to .github/workflows/initiative-planner.yml in your repo.
+#   2. Ensure GitHub Discussions is enabled with an "Ideas" category.
+#   3. Ensure the `idea:approved` label exists on the repo.
+#   4. Confirm the org-level secret GH_PAT_WORKFLOWS is accessible.
+#
+# Standard: https://github.com/petry-projects/.github/blob/main/standards/ci-standards.md
+name: Initiative Planner — Approval Trigger
+
+on:
+  discussion:
+    types: [labeled]
+
+permissions: {}
+
+jobs:
+  initiative-planner:
+    # Self-host: petry-projects/.github HOSTS the reusable, so this in-repo copy
+    # uses a LOCAL ref (always current) — not the `@initiative-planner/stable`
+    # remote channel that CONSUMER repos pin (see standards/workflows/initiative-planner.yml).
+    # Mirrors add-to-project.yml / pr-review-mention.yml; local refs also avoid the
+    # SHA-pin security finding a remote tag ref raises on the hosting repo.
+    uses: ./.github/workflows/initiative-planner-reusable.yml
+    secrets: inherit

standards/ci-standards.md

@@ -970,6 +970,68 @@ customisation.
 
 ---
 
+### 10. Idea → Initiative pipeline (`initiative-planner.yml`, `idea-triage.yml`, `idea-enhancer.yml`) — BMAD Method repos
+
+**Condition:** BMAD Method-enabled repos that want approved ideas turned into
+tracked initiatives (epic + story DAG) automatically. Builds on
+[Feature Ideation](#9-feature-ideation-feature-ideationyml--bmad-method-repos) —
+ideation produces ideas; this pipeline triages, enriches, and (on human approval)
+plans them.
+
+**Prerequisite:** Discussions enabled with an "Ideas" category, and the
+`idea:approved` label present on the repo.
+
+#### Architecture: thin caller stub → dispatch reusable → central planner
+
+Unlike feature-ideation (which runs the analyst inline), the BMAD Scrum Master
+planner and the vendored BMAD frameworks live **once** in
+`petry-projects/.github-private`. `claude-code-action` aborts on `discussion`
+event contexts, so each stub's reusable **re-dispatches** the central
+`workflow_dispatch` with the host repo passed as `target_repo`, rather than
+planning inline. Three stub + reusable pairs, all pinned to their `<name>/stable`
+channel:
+
+| Stub (`standards/workflows/`) | Reusable (`.github/workflows/`) | Trigger → action |
+|---|---|---|
+| [`initiative-planner.yml`](workflows/initiative-planner.yml) | [`initiative-planner-reusable.yml`](../.github/workflows/initiative-planner-reusable.yml) | `discussion [labeled] idea:approved` (trusted actor) → central planner builds an **inert** epic + story DAG (`initiative`, **not** `initiative:auto`) in the host repo |
+| [`idea-triage.yml`](workflows/idea-triage.yml) | [`idea-triage-reusable.yml`](../.github/workflows/idea-triage-reusable.yml) | weekly + dispatch → refresh the host repo's "Idea Promotion Queue" issue |
+| [`idea-enhancer.yml`](workflows/idea-enhancer.yml) | [`idea-enhancer-reusable.yml`](../.github/workflows/idea-enhancer-reusable.yml) | new Ideas Discussion + weekly → enrich the host repo's un-enhanced ideas |
+
+Two human gates keep judgement with a maintainer: adding `idea:approved` to a
+Discussion fires the planner; adding `initiative:auto` to the resulting epic
+hands it to `initiative-driver` for auto-implementation.
+
+#### Project-board funnel (hybrid)
+
+Where a planner-created epic lands depends on the repo:
+
+- **Consumer (fleet) repos** → the repo's **own** project board. Point the repo's
+  [`add-to-project`](workflows/add-to-project.yml) at its repo-level project.
+- **`petry-projects/.github` and `petry-projects/.github-private`** → the
+  **org-level** project (`orgs/petry-projects/projects/1`, "Initiatives").
+
+#### Adopting in a new repo
+
+1. Copy [`standards/workflows/initiative-planner.yml`](workflows/initiative-planner.yml)
+   to `.github/workflows/initiative-planner.yml` (and, optionally,
+   `idea-triage.yml` / `idea-enhancer.yml`) in the target repo.
+2. Ensure Discussions is enabled with an "Ideas" category and the
+   `idea:approved` label exists.
+3. Confirm the org-level secret `GH_PAT_WORKFLOWS` is accessible **and its owner
+   has write access to the target repo** (the central planner writes the epic +
+   sub-issues cross-repo with that PAT).
+4. Point `add-to-project` per the hybrid funnel above.
+5. Approve an idea: add `idea:approved` to an Ideas Discussion. The central
+   planner materializes an inert epic + story DAG in the repo; review it and add
+   `initiative:auto` to the epic to begin auto-implementation.
+
+The cross-repo trigger is watched by the central
+`initiative-planner-canary.yml` and Fleet Monitor stub-drift checks, so a silent
+regression (e.g. the [#655](https://github.com/petry-projects/.github-private/issues/655)
+stale-base revert class) surfaces on the first approval rather than going unnoticed.
+
+---
+
 ## Workflow Patterns by Tech Stack
 
 ### TypeScript / Node.js (npm)