Extend the self-hosted pr-review pipeline so a reviewer sees, during review, when a PR changes a shared surface (a first-party reusable workflow, a scripts/lib/ shell library, or a prompts/ file) that downstream consumer repos depend on — flagging potential breakage before the change enters ring-0.
Why now. The ring-staged release strategy (docs/initiatives/agentic-release-strategy.md) mitigates blast radius after a change lands, but gives no proactive signal during review. The self-host deadlock (#619) and clean-PR stalls (#463) show ring-0 validation can itself fail when the broken agent gates its own fix; shift-left detection during review is complementary to the ring model, not redundant with it. CodeRabbit's multi-repo analysis (Mar 2026) validates this as an emerging expectation for platform repos serving multiple consumers. Scope is the pr-review workflow only (confirmed by don-petry on the discussion).
Architecture (grounded). The triage tier runs haiku 4.5 with no tools — it cannot fetch cross-repo data itself. So the detection follows the existing ADVISORY_BOT_FEEDBACK pattern in scripts/review-one-pr.sh: the shell computes impacted surfaces from a committed manifest, best-effort fetches consumer references via gh api, assembles a capped context block, and inlines it into the prompts. The whole pass is opt-in and degrades to a no-op (byte-for-byte unchanged behavior) when the manifest is absent or cross-repo reads fail — mirroring the REVIEW_MCP_CONFIG convention.
Shape: Phase 1 lays the data foundation (consumer manifest + validator). Phase 2 builds a pure changed-files->consumers mapping helper, then the cross-repo fetch + context assembly. Phase 3 wires the block into the triage/cascade prompts with advisory semantics and adds the end-to-end default-off regression guard + docs.
Not a duplicate of #610 (context-adaptive review artifact contract), #676 (MCP enrichment), or #690 (repinning consumers to channel tags) — this is a new, complementary downstream-impact signal. Source: discussion #653.
Planned from idea discussion #653 by the BMAD Scrum Master initiative-planner. Inert until a maintainer adds initiative:auto.
Extend the self-hosted pr-review pipeline so a reviewer sees, during review, when a PR changes a shared surface (a first-party reusable workflow, a
scripts/lib/shell library, or aprompts/file) that downstream consumer repos depend on — flagging potential breakage before the change enters ring-0.Why now. The ring-staged release strategy (
docs/initiatives/agentic-release-strategy.md) mitigates blast radius after a change lands, but gives no proactive signal during review. The self-host deadlock (#619) and clean-PR stalls (#463) show ring-0 validation can itself fail when the broken agent gates its own fix; shift-left detection during review is complementary to the ring model, not redundant with it. CodeRabbit's multi-repo analysis (Mar 2026) validates this as an emerging expectation for platform repos serving multiple consumers. Scope is the pr-review workflow only (confirmed by don-petry on the discussion).Architecture (grounded). The triage tier runs haiku 4.5 with no tools — it cannot fetch cross-repo data itself. So the detection follows the existing
ADVISORY_BOT_FEEDBACKpattern inscripts/review-one-pr.sh: the shell computes impacted surfaces from a committed manifest, best-effort fetches consumer references viagh api, assembles a capped context block, and inlines it into the prompts. The whole pass is opt-in and degrades to a no-op (byte-for-byte unchanged behavior) when the manifest is absent or cross-repo reads fail — mirroring theREVIEW_MCP_CONFIGconvention.Shape: Phase 1 lays the data foundation (consumer manifest + validator). Phase 2 builds a pure changed-files->consumers mapping helper, then the cross-repo fetch + context assembly. Phase 3 wires the block into the triage/cascade prompts with advisory semantics and adds the end-to-end default-off regression guard + docs.
Not a duplicate of #610 (context-adaptive review artifact contract), #676 (MCP enrichment), or #690 (repinning consumers to channel tags) — this is a new, complementary downstream-impact signal. Source: discussion #653.
Planned from idea discussion #653 by the BMAD Scrum Master initiative-planner. Inert until a maintainer adds
initiative:auto.