Empirical finding (Phase D” execution session 2026-05-24T20:54→21:20 BST):
| Framework | Multi-repo native? | Evidence |
|---|---|---|
| BMAD METHOD v6.7.1 | ✗ | No 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.13 | ✗ | Issue #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.1 | ✗ | Owner 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.mdv1.1+
TT’s coordination layer (load-bearing; framework-independent):
inherit-v2-architecture-state.mdv4.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(validatescompanion_files: { version_pinned: }blocks across repos) frontmatter-conventions.mdv1.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:
- Per-repo install footprint: Spec-Kit (
.specify/) < OpenSpec (openspec/) < BMAD (.bmad-core/+_bmad-output/) - Agent ecosystem breadth: Spec-Kit (30+) > BMAD (built-in only) > OpenSpec (~6)
- Maintenance velocity: Spec-Kit (daily releases) > BMAD (daily commits) > OpenSpec (5 weeks since v1.3.1)
- Brownfield adoption: Spec-Kit (explicit support) ≈ OpenSpec (delta-based cycle) > BMAD (forced agile-personas fit)
- 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.