Empirical finding (Phase D” execution session 2026-05-24T20:54→21:20 BST):

FrameworkMulti-repo native?Evidence
BMAD METHOD v6.7.1No native federation in main README; relies on stale 3rd-party bmad-federated-knowledge@1.0.4 (last pub 2025-09-16; peer >=4.0.0; pre-v6.x)
Spec-Kit v0.8.13Issue #1026 (open, stale label) for monorepo subfolders; Issue #581 (open since Sept 2025); PR #2121 (NOT merged) for nested repo branching; community preset multi-repo-branching (sakitA) is for nested-git-repos NOT sibling-repos
OpenSpec v1.3.1Owner Repo pattern is config-only (each repo points at owner); no cross-repo orchestration tooling

TT’s structure (NOT a monorepo):

  • 7 sibling repos under ~/testatetech/ parent
  • Each repo has its own .git/ (independent histories)
  • No shared package.json workspace
  • No git submodules
  • docs-strategy = coordination hub
  • 5 v2 build repos + docs-admin = leaves
  • Parent workspace cwd = canonical session root per 2026-04-28-testatetech-parent-workspace-design.md v1.1+

TT’s coordination layer (load-bearing; framework-independent):

  • inherit-v2-architecture-state.md v4.82+ = Tier-1 single source of truth (47K-stars-equivalent internal-discipline)
  • Cross-repo amendment registry A-001..A-289+ (newest-first)
  • Per-cascade-Q file with stable Q-NNN naming
  • Active-work-log at ~/.claude/projects/-home-richardd-testatetech/memory/project_active_work.md (single workspace log)
  • Pre-commit pin-drift hook at docs-strategy/scripts/check-frontmatter-pins.py (validates companion_files: { version_pinned: } blocks across repos)
  • frontmatter-conventions.md v1.3+ §3.6 forward-traceability (phase_q_relevance + companion_files pattern)

Implication for framework choice:

The 2026-05-23T19:30 BST 10-criterion weighted scorecard had “Multi-repo / federation: 15%” as a major weight. With ALL 3 candidates failing this criterion equally, the 15% weight cancels — it does not differentiate between options.

The framework choice reduces to:

  1. Per-repo install footprint: Spec-Kit (.specify/) < OpenSpec (openspec/) < BMAD (.bmad-core/ + _bmad-output/)
  2. Agent ecosystem breadth: Spec-Kit (30+) > BMAD (built-in only) > OpenSpec (~6)
  3. Maintenance velocity: Spec-Kit (daily releases) > BMAD (daily commits) > OpenSpec (5 weeks since v1.3.1)
  4. Brownfield adoption: Spec-Kit (explicit support) ≈ OpenSpec (delta-based cycle) > BMAD (forced agile-personas fit)
  5. TT-discipline alignment: Spec-Kit constitution.md ≈ TT’s CLAUDE.md+arch-state; OpenSpec Owner-Repo ≈ existing pattern; BMAD’s 12+ agile personas don’t map to TT’s ζ-Q-lock methodology

Spec-Kit wins on the reframed scorecard. See feedback-adopt-github-spec-kit (Path E; reinstated 2026-05-24).

When to use this memory:

  • Any future framework-evaluation work for TT
  • When someone (Rich / Claude / Steven) proposes “framework X solves our multi-repo problem” — fast-counter with this empirical evidence
  • When the parent-workspace design + arch-state.md feel under-credited — they ARE the load-bearing coordination layer no framework matches
  • When evaluating new SDD frameworks in 2026+ — verify multi-repo native claims empirically (Spec-Kit #581 open since Sept 2025 = community-asking-not-getting answered)

Related: feedback-adopt-github-spec-kit (Path E lock) + feedback-adopt-bmad-plus-openspec-hybrid (Path D superseded) + feedback-verify-framework-extension-maintenance-before-lock (sister discipline) + parent-workspace design + Path E pivot SCF.