Rule: Phase D” authoring (when Phase B lands) MUST incorporate the 11 missed opportunities below. The sweep was triggered 2026-05-23 evening after Rich’s “we nearly missed the frontmatter opportunity” prompt; Phase D” would have shipped without 2 critical workstreams (skill-coexistence policy + Phase B.1 merge) if the sweep hadn’t run.
Why: TT’s existing discipline (superpowers / GSD / cascade-Q / arch-state / pre-commit hooks) coexists with the BMAD + OpenSpec hybrid in ways that aren’t automatic. Without explicit coexistence + handoff policies, agents will encounter conflicting workflows at runtime. The frontmatter opportunity (8-field addition; separate memory feedback_frontmatter_policy_sdd_alignment.md) was the trigger; this memory captures the broader sweep.
How to apply: Phase D” launch-prompt authoring incorporates the 12-14 stages below (up from 10). Estimated effort: ~20-25h Claude (up from ~15-20h).
The 11 missed opportunities
HIGH severity (would have shipped Phase D” broken/incomplete without these)
1. Superpowers ↔ BMAD skill conflict policy (NEW Stage 5.5) — TT relies on ~30 superpowers skills (using-superpowers, brainstorming, verification-before-completion, test-driven-development, systematic-debugging, writing-plans, etc.). BMAD ships 44 skills via .claude/skills/. Both ecosystems define overlapping concerns (brainstorming, TDD, verification). Without explicit policy, agents invoke conflicting workflows at runtime.
Lock candidate (preliminary): Option C domain-split — superpowers covers TT-specific disciplines (verification-before-completion / brainstorming / honest substrate-read declarations); BMAD covers role-agent workflows (PM/architect/dev/QA handoffs which TT doesn’t currently have). Final policy: Rich-lock at Phase D” authoring.
2. Phase B.1 (3-file split) ↔ Phase D” Stage 3 (OpenSpec init) overlap — Phase B’s substrate-checkpoint commit ff13ac5 explicitly deferred the spec/plan/tasks 3-file split to a planned Phase B.1. OpenSpec’s per-spec structure (proposal.md / specs/
Lock candidate (preliminary): merge Phase B.1 into Phase D” Stage 3. Phase B.1 alone is a strange standalone scope.
MEDIUM severity (Phase D” value enhanced)
3. check-build-plan-sync.py pre-commit hook — I didn’t know this hook existed. Found at docs-strategy/scripts/check-build-plan-sync.py. Phase D” Stage 7 needs to inventory + extend this hook for the new framework_artifact_type structure (after BUILD-PLAN.md → plan.md renames).
4. BMAD MCP server (Docker; 29 tools) — Multiple BMAD MCP server implementations exist: BMAD-METHOD MCP Server (HTTP MCP; up to 29 tools); BMAD Agent (FastMCP; 25+ tools; 10 specialised AI agents); Dali1789/bmad-mcp-server (OpenRouter routing). Install alongside per-repo BMAD = ambient BMAD discipline cross-session without per-session re-invocation.
Lock candidate (preliminary): include as NEW Stage 2.5; evaluate during execution; can drop if Docker friction > benefit.
5. GSD- agent ecosystem ↔ BMAD 12+ agents coexistence* — TT has gsd-debug, gsd-plan-phase, gsd-ingest-docs, etc. (many in user-invocable skill list). BMAD has PM / architect / UX / dev / QA / SM agents. Overlapping concerns; need policy on which agent for which work-type. Likely folds into Stage 5.5 (skills policy) but worth surfacing separately.
6. TDD inversion pattern adoption (Stage 6 expansion) — SDD canonical workflow: “acceptance_criteria EARS → generate tests from criteria → implement until tests pass”. TT has test-suite repo. Phase D” should encode this as default once BMAD QA agent + acceptance_criteria field (from Stage 7 frontmatter v1.4) land.
7. bmad-federated-knowledge specific TT design — extension exists on npm (HTTP 200 verified); but no concrete Phase D” design for which TT repos federate to which + what coordination metadata. Stage 2 needs explicit federated-knowledge config block.
8. Codex ~/.codex/config.toml defaults locked — Stage 4 covers in principle; needs concrete values (subagent caps, wait-time, root/subagent hints, depth handling, MultiAgentV2 settings). Without locked defaults, Steven encounters un-configured Codex first-session.
LOWER severity (worth incorporating; not blocking)
9. Cursor .cursor/rules/*.mdc generation — If team members use Cursor, ship a .cursor/ dir per repo with auto-attached .mdc rules. Stage 4 expansion. Defer if no Cursor user planned for Phase 2 team.
10. Acquirer-DD readiness narrative paragraph — Phase D” produces highly legible artefacts (constitution / spec / plan / tasks naming + framework_artifact_type metadata + LinkML-validated frontmatter). Worth a paragraph in arch-state A-NNN amendment + acquirer-DD package §3.X confirming this. Strategic value: when Anthropic-DD eventually fires, the codebase is automatically more reviewable than typical AI-built software.
11. Skills / Tools / MCP three-layer model documented (frontmatter-conventions v1.4 §3.8) — Per industry framing: “A Skill triggers, loads its instructions, connects via MCP to external data, executes Tools for each step, then validates the output.” TT’s stack has all three layers (BMAD/OpenSpec skills; Linear/GitHub/Playwright/etc. MCPs; pre-commit hooks + custom scripts as tools). Document the layer model to prevent layer-confusion at the integration boundaries.
Updated Phase D” execution model — 12 stages (~20-25h)
| Stage | Workstream | Source |
|---|---|---|
| 1 | Clean up workspace BMAD install | Existing (DONE 2026-05-23 evening) |
| 2 | Per-repo BMAD install + federated-knowledge config (incorporating #7 specific design) | Existing + expansion |
| 2.5 NEW | Install BMAD MCP server (Docker; 29 tools) — Stage 2.5 from #4 | NEW |
| 3 | Per-repo OpenSpec init + Owner Repo pattern + Phase B.1 spec/plan/tasks 3-file split merged here (#2) | Existing + Phase B.1 merge |
| 4 | CLAUDE.md → AGENTS.md migration + tool-agnostic content split + .codex/config.toml locked defaults (#8) + optional .cursor/rules/ (#9) | Existing + expansion |
| 5 | SKILL.md audit at code-inheritkit/skills/* | Existing |
| 5.5 NEW | Superpowers ↔ BMAD skill coexistence policy (#1) + GSD ↔ BMAD agent coexistence (#5) | NEW — critical |
| 6 | EARS-notation adoption + TDD-inversion default workflow encoded (#6) | Existing + expansion |
| 7 | frontmatter-conventions v1.3 → v1.4 (8 fields per feedback_frontmatter_policy_sdd_alignment + mapping table + EARS §3.7 + check-build-plan-sync.py extension (#3) + Skills/Tools/MCP three-layer §3.8 (#11)) | Existing + expansion |
| 8 | Linear MCP smoke-test | Existing |
| 9 | Codex smoke-test (deferred until Codex installed) | Existing |
| 10 | arch-state §15 A-NNN amendment + ledger increment + acquirer-DD readiness narrative paragraph (#10) | Existing + expansion |
3 Rich-decisions to lock at Phase D” authoring time
| # | Decision | Recommended | Status post-Phase-B closure (2026-05-24) |
|---|---|---|---|
| 1 | Phase B.1 vs Phase D” Stage 3 (3-file split) | OVERRIDDEN 2026-05-23 evening per Rich-directive “i am convinced that i want to modify the existing build-plan.md files to spec.md + plan.md + tasks.md per OpenSpec convention”. Steven starts 2026-05-24; retroactive 3-file split per OpenSpec convention is IN SCOPE for Phase D” Stage 3.5 (NEW). Effort ~12-15h × 5 repos = ~60-75h sequential; parallel-Claude-dispatch via worktree-isolation pattern brings wall-clock to ~12-15h if 5-7 sessions run in parallel. Cross-repo collaborator-join trigger now empirically firing. | |
| 2 | BMAD MCP server (Stage 2.5) include? | Include with evaluation gate — drop if Docker friction > benefit during execution | Unchanged |
| 3 | Skill coexistence policy (Stage 5.5) | Option C domain-split — superpowers for TT-specific disciplines; BMAD for role-agent workflows; final map locked at authoring | Unchanged |
Phase B closure facts (incorporated 2026-05-24 post-closure)
| Fact | Implication for Phase D” |
|---|---|
| arch-state landed at v4.82 + A-288 + MQ-020 (commit e1a2fe0) | Phase D” executing session reserves A-289 + arch-state v4.83 + MQ-021; bumped from prior reservation of A-288 |
| MQ-020 retires the A-222..A-287 —no-verify bypass chain for methodology-migration batches | Phase D” Stage 10 MUST pair its arch-state amendment with MQ-021 stub authoring (~150-300 lines per MQ-019/MQ-020 template); hard precondition |
| AGENTS.md alignment ALREADY landed across all 7 repos as Phase B coda (commits 585f75d / 444fd0a / 1a7c2ea / d5cffc0 / e0d2c7e / f100e53 / 0a7a67a) | Phase D” Stage 4 shrinks substantially — the cross-tool entry-point declaration is done; what remains: optional git mv + symlink for tools requiring strict AGENTS.md filename + .codex/config.toml defaults + tool-agnostic content audit |
| Phase B.1 deferred to “first cross-repo collaborator join” trigger | Stage 3 OpenSpec init lands but per-feature 3-file split waits for collaborator (see decision #1 above) |
New memory feedback_methodology_migration_cascade_q_pairing_mandatory.md durable substrate | Phase D” launch-prompt cites it in inherits_substrate_from: block; sister memory to this one |
batch-imp-24 sister candidate: ik BUILD-PLAN.md §1.4.2/§1.4.3 SDK-generator drift hygiene (~30-45 min; non-arch-state-bumping so MQ-pairing N/A) | Small standalone batch can land between Phase B closure and Phase D” start; not blocking either |
Strategic lesson
The frontmatter opportunity was nearly missed because we were focused on framework choice + scorecard scoring. The skill-coexistence opportunity was nearly missed for the same reason — we focused on “which framework” without asking “how does this framework coexist with TT’s existing discipline ecosystem”.
Pattern for future framework-adoption decisions: after locking the framework choice, run an explicit “what existing TT discipline does this conflict with?” sweep. Document the coexistence + handoff policies before authoring the adoption launch-prompt.
Related: feedback-adopt-bmad-plus-openspec-hybrid (Path D lock this serves); feedback-frontmatter-policy-sdd-alignment (Stage 7 sub-deliverable; sister memory); feedback-build-plan-hybrid-shape-a-narrative-plus-native-tasks (Phase B Shape A includes SOTA A+C+D folded improvements per ff13ac5 commit narrative); feedback-prompts-comprehensive-and-fully-detailed (Phase D” launch-prompt will be comprehensive per the directive).