💡 Cross-Repo Impact-Aware Review Annotations for Downstream Breakage Detection

[github-actions[bot]]

Summary

Extend the pr-review pipeline to detect and annotate when changes to shared reusable workflows, shell libraries, or prompt files in .github-private could break consumer repos (Broodly, TalkTerm, markets, google-app-scripts). CodeRabbit shipped multi-repo analysis in March 2026, validating this as an emerging market expectation. The project's ring-staged release strategy mitigates blast radius after deployment, but does not provide proactive visibility during review — a reviewer currently has no signal about downstream impact until the change hits a consumer ring.

Market Signal

CodeRabbit launched multi-repo analysis (March 2026): when a PR changes a shared API, type definition, or database schema, CodeRabbit checks linked repositories for downstream breakage. GitHub Copilot's agentic code review (March 2026) gathers full project context before analyzing PRs. The trend toward context-rich, ecosystem-aware review is accelerating — isolated single-repo review is becoming insufficient for platform/infrastructure repos that serve multiple consumers.

User Signal

The project deploys reusable workflows to 4+ consumer repos via ring-staged promotion. Issue #463 (PR review never reviews at green CI) and the self-host deadlock pattern (#619) demonstrate that cross-repo breakage is a real operational risk. The deploy mechanism (ring-staged via channel tags) mitigates blast radius AFTER a change lands, but provides no PROACTIVE signal during review. Merged PR #606 (oversized PR handling) shows the review pipeline already handles complex cross-cutting concerns — downstream impact is a natural extension.

Technical Opportunity

The project's architecture enables this: consumer repos are known and enumerable (documented in the ring-staged release strategy). The pr-review pipeline's review-cycle.sh already assembles context from multiple sources. A downstream-impact check would:

1. Identify which changed files map to shared surfaces (reusable workflows, shell libs in scripts/lib/, prompts/)
2. Fetch consumer repo workflow files that reference those surfaces
3. Flag potential breakage in the review output

engine.sh's triage tier (haiku 4.5) can handle the lightweight compatibility-check pass at minimal cost.

Assessment

Dimension	Score	Rationale
Feasibility	med	Requires cross-repo read access and a consumer manifest; moderate implementation effort
Impact	high	Catches breaking changes before they enter ring-0; prevents self-host deadlock scenarios
Urgency	med	Ring-staged releases mitigate blast radius, but proactive detection is a force multiplier

Adversarial Review

Strongest objection: The ring-staged release strategy already mitigates downstream breakage by validating changes in ring-0 (self-host) before promoting to consumers. Cross-repo impact checking during review is redundant with the ring gates.

Rebuttal: Rings mitigate blast radius AFTER a change lands but do not provide PROACTIVE visibility during review. A reviewer seeing "this change to ci-status.sh is consumed by 4 downstream repos' pr-review.yml" can make better-informed decisions — and catch breaking interface changes before they enter ring-0. The self-host deadlock (#619) proves that even ring-0 validation can fail when the broken agent gates its own fix. Shift-left detection during review is complementary to, not redundant with, the ring model.

Suggested Next Step

1. Map the shared surfaces between .github-private and consumer repos (reusable workflow refs, shell lib imports, prompt file paths).
2. Build a consumer-manifest.json listing each consumer repo and its dependency paths.
3. Add a downstream-impact pass to review-cycle.sh that runs at the triage tier (haiku 4.5) to flag potential breakage.

[don-petry]

Specifically, this would be implemented in our pr-review workflow.

[github-actions[bot]]

[don-petry]

1. all repos and all reusable workflows are in scope. Specifically, .github and .github-private are the providers and all repos are consumers.

2. existing workflows in .github-private have cross repo access via GH_PAT

3. exact match

[don-petry]

1. all repos and all reusable workflows are in scope. Specifically, .github and .github-private are the providers and all repos are consumers.

2. existing workflows in .github-private have cross repo access via GH_PAT

3. exact match

[github-actions[bot]]

📋 Initiative planned by the BMAD Scrum Master (Bob).

Epic #748 — Cross-repo impact-aware review annotations: proactive downstream-breakage detection in the pr-review pipeline

5 stories created (inert — labelled initiative, NOT initiative:auto):

• [Phase 1] Define the consumer manifest + validator (shared-surface -> consumers map) #749 (M) — [Phase 1] Define the consumer manifest + validator (shared-surface -> consumers map)
• [Phase 2] Pure mapping helper: changed files -> impacted shared surfaces + consumers #750 (M) — [Phase 2] Pure mapping helper: changed files -> impacted shared surfaces + consumers
• [Phase 2] Fetch consumer references + assemble the DOWNSTREAM_IMPACT context block #751 (L) — [Phase 2] Fetch consumer references + assemble the DOWNSTREAM_IMPACT context block
• [Phase 3] Wire the DOWNSTREAM_IMPACT block into the triage + deep prompts and surface it in the verdict #752 (M) — [Phase 3] Wire the DOWNSTREAM_IMPACT block into the triage + deep prompts and surface it in the verdict
• [Phase 3] Default-off feature flag + regression guard + operator docs for the downstream-impact pass #753 (M) — [Phase 3] Default-off feature flag + regression guard + operator docs for the downstream-impact pass

Open questions for review:

• Manifest maintenance cadence: the consumer set is built empirically (Story 1), but as new org repos pin provider reusables the manifest drifts until refreshed. v1 ships a manual/CI-runnable refresh script; consider a scheduled refresh later if drift proves operationally noticeable. (Advisory — does not block planning.)

---

Review the epic and its sub-issue DAG, adjust as needed, then add initiative:auto to epic #748 to hand it to initiative-driver for auto-implementation.