Skip to content

Standards, docs & one-repo pilot #825

Closed

Description

@don-petry

Story

As a maintainer,
I want document the fleet topology and validate it end-to-end on one real repo before broad rollout,
so that the rollout is proven behind both human gates instead of shipped blind to the whole fleet.

Acceptance Criteria

  1. A new standards/ci-standards.md section ('Idea→Initiative — caller stubs') plus an updated docs/initiatives/idea-to-initiative-pipeline.md diagram show the central-planner/stub split and the cross-repo token.
  2. An enrollment runbook documents: enable Discussions + Ideas category, copy the stub(s), set secrets, smoke-test in dry_run.
  3. Pilot: one fleet repo is enrolled end-to-end; an idea:approved add produces an inert epic + DAG IN THAT repo, behind both gates.
  4. A rollout checklist for the remaining repos is published.

Tasks / Subtasks

Dev Notes

  • Sequenced last: it documents and validates the finished surface, and the live pilot needs S1's credentials, S3's stub, S5's canary, and S7's board decision.
  • Keep both human gates in the pilot: idea:approved fires the planner; the epic is created inert and a human adds initiative:auto.
  • Update the pipeline diagram in docs/initiatives/idea-to-initiative-pipeline.md to show the per-repo stub and the cross-repo dispatch.

Project Structure Notes

Docs in both repos (ci-standards.md in public .github, pipeline doc in .github-private) plus a live pilot enrollment.

References

  • standards/ci-standards.md (petry-projects/.github)
  • docs/initiatives/idea-to-initiative-pipeline.md

Likely target surface

  • standards/ci-standards.md (new section — petry-projects/.github)
  • docs/initiatives/idea-to-initiative-pipeline.md

Story prepared by the BMAD Scrum Master (Bob) for epic #817. Status: ready-for-dev.

Activity

  1. github-actions commented on Jun 20, 2026

    @github-actions
    Contributor

    Thanks for the detailed story and well-structured acceptance criteria — this is a great foundation for the rollout! Since the dev notes mention this is sequenced last and depends on prerequisites from S1, S3, S5, and S7, could you confirm which of those are currently complete and, specifically, which fleet repo has been chosen for the pilot enrollment in AC #3?

  2. don-petry commented on Jun 21, 2026

    @don-petry
    CollaboratorAuthor

    ✅ S8 pilot — SUCCESS. End-to-end fleet path validated on petry-projects/.github.

    Round trip:

    1. Adopted the initiative-planner caller stub on petry-projects/.github (PR feat: enroll .github in the idea→initiative pipeline + document caller stubs .github#504, merged) using a self-host local ref (.github hosts the reusable).
    2. Added idea:approved to .github Ideas Discussion [Phase 1] Pin all callers off @main to the stable tag (consumer repos + self-review/dev duty) #497 ("enable pull request limits").
    3. Stub fired (discussion [labeled], run succeeded) → reusable dispatched the central planner in .github-private with target_repo=petry-projects/.github.
    4. Central planner (run 27892405366, success) materialized an inert epic + 5-story DAG in petry-projects/.github:
    5. Plan summary posted back to Discussion [Phase 1] Pin all callers off @main to the stable tag (consumer repos + self-review/dev duty) #497 ✓

    This proves the cross-repo path (target_repo != .github-private, writes via GH_PAT_WORKFLOWS) and the inert-epic discipline.

    One minor follow-up (board funnel): .github's add-to-project carries a required_label filter that the planner's initiative epics don't match, so #505 did not auto-add to org project #1. The hybrid rule is documented (ci-standards §, that section) and add-to-project is pointed at project #1 — only the required_label needs to accept initiative (or the planner epics need that label) to complete the auto-add. Tracking as a small wiring tweak; does not affect the pipeline.

    Docs (ci-standards §, pipeline diagram, enrollment runbook) shipped in #504 + #858. Closing S8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationDocumentation changesenhancementFeature requestsinitiativeEpic / initiative tracking issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions