Repository navigation
Standards, docs & one-repo pilot #825
Copy link
Copy link
Closed
Labels
documentationDocumentation changesDocumentation changesenhancementFeature requestsFeature requestsinitiativeEpic / initiative tracking issueEpic / initiative tracking issue
Description
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
- 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.
- An enrollment runbook documents: enable Discussions + Ideas category, copy the stub(s), set secrets, smoke-test in dry_run.
- Pilot: one fleet repo is enrolled end-to-end; an idea:approved add produces an inert epic + DAG IN THAT repo, behind both gates.
- A rollout checklist for the remaining repos is published.
Tasks / Subtasks
- Write the ci-standards.md section and update the pipeline doc diagram. (AC: test issue from agent #1)
- Write the enrollment runbook. (AC: Go-live improvements for PR review agent #2)
- Enroll one pilot repo and validate an idea:approved → inert-epic round trip. (AC: Add @claude delegation, auto-merge, and rebase handling #3)
- Publish the rollout checklist. (AC: Optimize review: small-PR and incremental fast paths #4)
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.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
documentationDocumentation changesDocumentation changesenhancementFeature requestsFeature requestsinitiativeEpic / initiative tracking issueEpic / initiative tracking issue
Activity
github-actions commentedon Jun 20, 2026
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?
feat: S6 stale-base guards — test-deletion CI signal + fleet pipeline…
don-petry commentedon Jun 21, 2026
✅ S8 pilot — SUCCESS. End-to-end fleet path validated on
petry-projects/.github.Round trip:
initiative-plannercaller stub onpetry-projects/.github(PR feat: enroll .github in the idea→initiative pipeline + document caller stubs .github#504, merged) using a self-host local ref (.githubhosts the reusable).idea:approvedto.githubIdeas Discussion [Phase 1] Pin all callers off @main to the stable tag (consumer repos + self-review/dev duty) #497 ("enable pull request limits").discussion [labeled], run succeeded) → reusable dispatched the central planner in.github-privatewithtarget_repo=petry-projects/.github.petry-projects/.github:initiativeonly (NOTinitiative:auto) ✓blocked_byedges (verified: feat(initiative): dependency-aware driver to deliver epics agentically #507 blocked_by [Phase 2] Reusable workflow must run scripts at the caller's channel ref (no silent version mismatch) #506) ✓This proves the cross-repo path (
target_repo != .github-private, writes viaGH_PAT_WORKFLOWS) and the inert-epic discipline.One minor follow-up (board funnel):
.github'sadd-to-projectcarries arequired_labelfilter that the planner'sinitiativeepics 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 therequired_labelneeds to acceptinitiative(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.