✅ REINSTATED 2026-05-24T21:20 BST — Path E (Spec-Kit per-repo + TT-native coordination) restored as canonical after Phase D” execution-attempt 2026-05-24T20:54→21:20 BST surfaced the substrate-correcting findings collapsing Path D’s 96% scorecard to ~78-82%. See feedback-adopt-bmad-plus-openspec-hybrid (superseded; audit-only) and the Path E pivot SCF at docs/superpowers/specs/2026-04-29-multi-phase-audit/batch-imp-24-phase-d-double-prime-path-e-pivot-research-findings-v1.0.md for the 6 empirical findings + scorecard re-run. Content below is the original 2026-05-23T18:00 BST framing; reinforced by 2026-05-24 empirical evidence (see SCF §2). When a future session authors the Path E launch-prompt, START from this memory + SCF, NOT from the Path D launch-prompt v1.5 (superseded).

Rich-directive 2026-05-23T~18:00 BST: “i am convinced that adopting GitHub Spec Kit is a good move” — after the second SOTA research pass surfaced Spec Kit as the canonical SDD framework that:

  1. Maps cleanly to TT’s existing discipline (constitution.md ≈ CLAUDE.md/arch-state.md; spec.md ≈ cascade-Q file per decision; plan.md ≈ BUILD-PLAN.md; tasks.md ≈ Native Tasks + Linear Issues)
  2. Ships 6 slash commands as Agent Skills: /speckit.constitution + /speckit.specify + /speckit.plan + /speckit.tasks + /speckit.taskstoissues + /speckit.implement
  3. Supports brownfield adoption explicitly (TT’s case — 7 in-scope repos with existing structure)
  4. Cross-tool portable across Claude Code + Codex CLI + Cursor + GitHub Copilot + Gemini CLI + 20+ other AI agents
  5. Includes /speckit.taskstoissues which auto-creates GitHub Issues from tasks → Linear’s GitHub integration auto-mirrors to Linear Issues (may simplify Phase C scope)

Strategic implications:

  • Phase D’ scope grows from “AGENTS.md + SKILL.md alignment” to “Spec Kit adoption” — Spec Kit is a complete framework that incorporates AGENTS.md + SKILL.md + EARS-notation acceptance criteria + cross-tool config + CLI tooling. Phase D’ becomes Phase D”.
  • Steven-readiness: Spec Kit gives Codex native compatibility. When Steven onboards on his preferred Codex CLI, he’ll find .specify/ + memory/constitution.md + specs/ already populated in TT repos. No re-authoring; he works in his tool of choice immediately.
  • Phase C interaction: /speckit.taskstoissues + Linear’s native GitHub integration may cover what Phase C’s Linear MCP scope was going to build. Worth re-evaluating Phase C scope after Spec Kit adoption lands.
  • Phase B is COMPATIBLE: Phase B is migrating BUILD-PLAN.md to Shape A (step-N + depends_on + exit_criteria + checkbox). Shape A maps directly to Spec Kit’s plan.md shape. Post-Phase-B BUILD-PLAN.md files can be renamed to plan.md (or symlinked) with minimal additional work.

Spec Kit specifics to honour during adoption:

  • CLI is Python-baseduv recommended for installation (clean + reproducible per the project’s own guidance)
  • Multi-repo support is community-preset (sakitA/spec-kit-preset-multi-repo-branching), not first-class. TT has 7 in-scope repos under ~/testatetech/ parent → needs the preset OR per-repo Spec Kit installs
  • --no-git flag for monorepo cases or projects with existing git setup; Spec Kit is moving Git functionality to opt-in starting 1.0.0
  • Brownfield discipline: per EPAM’s adoption guidance — provide architectural context upfront; share API contracts; well-defined acceptance criteria (“endpoint returns 200” not “endpoint works”); spec quality drives task + implementation quality
  • Core principles in constitution.md (per EPAM example): “Code duplication is prohibited”; “Search for existing functions before creating a new one”; per-layer reuse rules. These match TT’s existing CLAUDE.md disciplines.
  • AGENTS.md stewardship: now under the Agentic AI Foundation (Linux Foundation) — stable open standard, not vendor-controlled

File-mapping decisions deferred to Phase D” authoring (Rich-lock per question at launch-prompt review):

TT artefactSpec Kit equivalentOpen question
arch-state.md (cross-repo Tier-1)memory/constitution.md (per repo)Cross-repo Tier-1 vs per-repo: how to bridge?
CLAUDE.md per repoAGENTS.md + CLAUDE.md symlinkSymlink pattern; Claude-specific bits go to .claude/ overlay
cascade-Q filesspecs/Q-NNN/spec.mdRename / symlink / leave-as-is — Rich-lock
BUILD-PLAN.md (post-Phase-B Shape A)specs//plan.mdRename after Phase B lands
Native Tasks (tt-inherit-v2)specs//tasks.md + GitHub Issues + Linear mirrorCoexistence pattern
frontmatter-conventions.mdSpec Kit metadata schemaAlign TT-specific extensions with Spec Kit conventions explicitly

Tactical decisions Rich locks at Phase D” launch-prompt review (knock-on sequence):

  1. Spec Kit scope: per-repo vs root + multi-repo preset (highest knock-on; determines all paths)
  2. arch-state.md vs memory/constitution.md mapping (cross-repo Tier-1 bridge pattern)
  3. CLI install (pip / uv) vs convention-only adoption (determines tooling footprint)
  4. Spec Kit’s /speckit.taskstoissues impact on Phase C Linear MCP scope (overlap re-evaluation)
  5. AGENTS.md content split (tool-agnostic vs Claude-specific overlay)
  6. EARS notation timing (Phase D” or Phase B trailing or separate)
  7. /speckit.implement autonomous-execution discipline (currently interactive per TT; adoption affects this)

Related: feedback-build-plan-hybrid-shape-a-narrative-plus-native-tasks (Shape A is already Spec-Kit-compatible; just needs filename alignment); feedback-prompts-comprehensive-and-fully-detailed (Phase D” launch-prompt will be comprehensive per the recent flip).