Skip to content

[Phase 1] Define the consumer manifest + validator (shared-surface -> consumers map) #749

Description

@github-actions

Story

As a pr-review maintainer,
I want a committed, validated consumer-manifest that maps each provider reusable workflow to the org repos (consumers) that pin it,
so that the downstream-impact pass has a single, machine-checkable source of truth for which changes affect which consumers.

Acceptance Criteria

  1. A committed manifest file (JSON) declares: providers = [".github", ".github-private"]; consumers = a list of {repo, refs} where refs are the provider reusable-workflow paths that repo pins via uses:; and surface_sources = per reusable-workflow path, the in-provider scripts/lib/*.sh and prompts/* files it sources (exact paths).
  2. A refresh/builder script populates consumers empirically: it enumerates org repos and detects uses: references to provider reusable workflows using GH_PAT (the same token .github/workflows/pr-review.yml already uses), and writes the manifest deterministically (stable key ordering) so re-runs produce a clean diff.
  3. A validator script exits non-zero on: invalid JSON/schema, a surface_sources key that is not an existing reusable-workflow path in this repo, or a surface_sources value pointing at a scripts/lib/prompts path that does not exist in this repo.
  4. A bats test (tests/test_consumer_manifest.bats) covers: a well-formed manifest passes; a manifest referencing a non-existent local surface fails; malformed JSON fails.
  5. shellcheck passes on every new/changed shell script.

Tasks / Subtasks

Dev Notes

  • Manifest is data, not code — follow the repo convention of keeping tabular/lookup data in scripts/lib/ (cf. scripts/lib/model-pricing.tsv, scripts/lib/review-registry.tsv). JSON is appropriate here because the consumer->refs relation is nested.
  • Providers are fixed: .github and .github-private (resolved in 💡 Cross-Repo Impact-Aware Review Annotations for Downstream Breakage Detection #653). Consumers are ALL org repos that pin a provider reusable — do NOT hand-curate; build empirically. The release-strategy doc names example consumers (bmad-bgreat-suite, google-app-scripts, markets, ContentTwin) but the discussion body also names Broodly/TalkTerm — the empirical scan is authoritative, not either list.
  • Reusable workflows are the consumer-facing surface (what a consumer uses:). surface_sources captures the single documented hop from a changed lib/prompt to the reusable(s) that source it — exact path only, no recursive graph (💡 Cross-Repo Impact-Aware Review Annotations for Downstream Breakage Detection #653: exact match).
  • Use GH_PAT exactly as .github/workflows/pr-review.yml does (GH_TOKEN: ${{ secrets.DON_PETRY_BOT_GH_PAT_CLASSIC || secrets.DON_PETRY_BOT_GH_PAT }}); the org-enumeration call needs read access across consumer repos, which that token already has.
  • Testing: bats is the repo standard for script behavior (see tests/), shellcheck for lint. New bats files MUST be added to the lint.yml bats list (AGENTS.md documents this as a repo-specific exception).

Project Structure Notes

New manifest + scripts live under scripts//scripts/lib/; new test under tests/. No changes to the cascade behavior in this story — it only introduces the data + its validator.

References

  • docs/initiatives/agentic-release-strategy.md#consumers
  • .github/workflows/pr-review.yml#GH_PAT
  • scripts/lib/model-pricing.tsv
  • scripts/lib/review-registry.tsv
  • AGENTS.md#bats-test-list-exception
  • .github/workflows/lint.yml#bats

Likely target surface

  • scripts/
  • scripts/lib/
  • tests/
  • .github/workflows/lint.yml

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    dev-leadFor dev-lead agent pickupinitiativeEpic / initiative tracking issue

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions