Phase 3 — Solutioning

Architecture, epic + story listing, and the readiness gate before implementation. The output of this phase is a story backlog with no ambiguity left.

Owners: Architect (e11-agent-architect), PM.

Workflows in this phase

Code	Workflow	Purpose	Owner	Output
[CA]	e11-architecture	Lean architecture spine of invariants (AD-n), SDK composition alloy-first	Architect	{planning_artifacts}/architecture/architecture-<project>-<date>/ARCHITECTURE-SPINE.md
[CE]	e11-create-epics-and-stories	PRD + architecture → epics + story listing, each story SDK-stamped	PM	{planning_artifacts}/epics.md
[IR]	e11-check-implementation-readiness	Cross-artifact alignment gate — PRD ↔ UX ↔ architecture ↔ stories	Architect or PM	{planning_artifacts}/readiness-report.md

How the solutioning skills are shaped

• The architecture doc is a spine. e11-architecture replaces the long-form document of earlier releases with a numbered list of binding decisions — one test for inclusion: would drift on this break something? Create / Update / Validate are intents of the one skill; e11-create-architecture is a one-release shim. Validation runs a deterministic spine linter (lint-spine.mjs) plus rubric and reviewer lenses.
• SDK composition is inherited, not re-derived (gate: e11_platform_composition). The spine's capability enumeration starts from the PRD's Platform Capability Map; composed SDKs become [ADOPTED] ADs with alloy:// citations that later sections never re-litigate; gaps land in an explicit Gaps + alloy-follow-ups section.
• Stories carry SDK stamps (gate: e11_platform_sdk_stamp). e11-create-epics-and-stories step 3 loads both the capability map and the spine's composition table, and writes an **E11 SDKs touched:** stamp line into every story between the story statement and its ACs. Dev's pre-load and code review's alloy auditor consume these stamps downstream.
• Readiness has cross-artifact teeth (gate: e11_platform_alignment). Beyond the standard checks, step 6 verifies the three E11 threads agree: every stamped SDK maps back to the capability map/composition table (unmapped-stamp findings), every mapping shows up in stamps (unstamped-mapping findings), and "New" capabilities are consistently flagged across PRD, spine, and stories.

Standard flow

1. Architect [CA] — foundation set pre-loaded, capability map inherited, spine drafted. Coaching path is the default; load-bearing calls are shown to you.
2. PM [CE] — epics + stories with stamps. Stories don't invent scope.
3. [IR] — the gate. Either Architect or PM runs it. If it fails, do not proceed to Phase 4.

When to detour

• PRD changed after [CA]. Re-run [CA] with Update intent — the spine's memlog keeps decision history; don't hand-patch the artifact.
• Alloy doesn't cover a pattern. The Architect tries the reserved upstream-skill keys (pattern:backend-shared, …) before flagging an alloy follow-up. The spine makes the gap visible — don't paper over it.
• [IR] fails. Fix what it flags. Skipping the gate is the most common cause of bad sprints.
• UI is central. Run UX [UX] before [CA] — the spine inherits component decisions.

Hand-off

Output of Phase 3 → input to Phase 4 (Implementation). e11-sprint-planning reads epics.md and the spine; the stamps ride along into every story file.

Source

Workflow SKILL files:

• e11-agent-architect/SKILL.md (the phase's agent-skill)
• e11-architecture/SKILL.md · shim: e11-create-architecture/SKILL.md
• e11-create-epics-and-stories/SKILL.md
• e11-check-implementation-readiness/SKILL.md
• e11-generate-project-context/SKILL.md ([GPC], anytime)