91f6c41be1
* docs: radical reduction of documentation scope for v6 beta Archive and basement unreviewed content to ship a focused, minimal doc set. Changes: - Archive stale how-to workflow guides (will rewrite for v6) - Archive outdated explanation and reference content - Move unreviewed content to basement for later review - Reorganize TEA docs into dedicated /tea/ section - Add workflow-map visual reference page - Simplify getting-started tutorial and sidebar navigation - Add explanation pages: brainstorming, adversarial-review, party-mode, quick-flow, advanced-elicitation - Fix base URL handling for subdirectory deployments (GitHub Pages forks) The goal is a minimal, accurate doc set for beta rather than comprehensive but potentially misleading content. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * refactor: restructure BMM and agents documentation by consolidating and flattening index files. --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2.6 KiB
title, description
| title | description |
|---|---|
| Why Solutioning Matters | Understanding why the solutioning phase is critical for multi-epic projects |
Phase 3 (Solutioning) translates what to build (from Planning) into how to build it (technical design). This phase prevents agent conflicts in multi-epic projects by documenting architectural decisions before implementation begins.
The Problem Without Solutioning
Agent 1 implements Epic 1 using REST API
Agent 2 implements Epic 2 using GraphQL
Result: Inconsistent API design, integration nightmare
When multiple agents implement different parts of a system without shared architectural guidance, they make independent technical decisions that may conflict.
The Solution With Solutioning
architecture workflow decides: "Use GraphQL for all APIs"
All agents follow architecture decisions
Result: Consistent implementation, no conflicts
By documenting technical decisions explicitly, all agents implement consistently and integration becomes straightforward.
Solutioning vs Planning
| Aspect | Planning (Phase 2) | Solutioning (Phase 3) |
|---|---|---|
| Question | What and Why? | How? Then What units of work? |
| Output | FRs/NFRs (Requirements) | Architecture + Epics/Stories |
| Agent | PM | Architect → PM |
| Audience | Stakeholders | Developers |
| Document | PRD (FRs/NFRs) | Architecture + Epic Files |
| Level | Business logic | Technical design + Work breakdown |
Key Principle
Make technical decisions explicit and documented so all agents implement consistently.
This prevents:
- API style conflicts (REST vs GraphQL)
- Database design inconsistencies
- State management disagreements
- Naming convention mismatches
- Security approach variations
When Solutioning is Required
| Track | Solutioning Required? |
|---|---|
| Quick Flow | No - skip entirely |
| BMad Method Simple | Optional |
| BMad Method Complex | Yes |
| Enterprise | Yes |
:::tip[Rule of Thumb] If you have multiple epics that could be implemented by different agents, you need solutioning. :::
The Cost of Skipping
Skipping solutioning on complex projects leads to:
- Integration issues discovered mid-sprint
- Rework due to conflicting implementations
- Longer development time overall
- Technical debt from inconsistent patterns
:::caution[Cost Multiplier] Catching alignment issues in solutioning is 10× faster than discovering them during implementation. :::