Shaping & Breadboarding

When to Use

• Exploring a new feature or product direction
• Comparing solution approaches before building
• Mapping an existing system to understand where changes land
• Breaking a selected solution into vertical implementation slices
• Any "should we build X or Y?" discussion

Entry Points

• Start from R (Requirements) — Describe the problem, pain points, constraints. Build up requirements and let shapes emerge.
• Start from S (Shapes) — Sketch a solution already in mind. Capture it as a shape and extract requirements as you go.

No required order. R and S inform each other throughout.

Core Notation

Phases

Shaping → Slicing

• Shaping: Explore problem/solution space, select and detail a shape
• Slicing: Break down for implementation into vertical slices with demo-able UI

Key Actions

• Populate R — Gather requirements as they emerge
• Sketch a shape — Propose a high-level approach
• Detail — Break shape into components or concrete affordances
• Check fit — Build decision matrix (R × S), binary ✅/❌ only
• Breadboard — Map to UI/Code affordances with wiring
• Spike — Investigate unknowns
• Slice — Break breadboarded shape into vertical increments

Detailed Reference

For the complete methodology, notation rules, examples, and procedures:

• Shaping reference: See references/shaping.md — Full shaping methodology including fit checks, parts, spikes, documents, multi-level consistency
• Breadboarding reference: See references/breadboarding.md — Complete breadboarding procedure, affordance tables, places, wiring, Mermaid conventions, chunking, slicing

Load the relevant reference when entering that phase of work.

Quick Reference: Fit Check Format

| Req | Requirement | Status | A | B | C |
|-----|-------------|--------|---|---|---|
| R0 | Full requirement text | Core goal | ✅ | ✅ | ✅ |
| R1 | Full requirement text | Must-have | ✅ | ❌ | ✅ |

• Always show full requirement text, never abbreviate
• Binary only: ✅ or ❌. No ⚠️ in fit checks
• Explanations go in Notes section below the table

Quick Reference: Affordance Tables

UI Affordances: # | Place | Component | Affordance | Control | Wires Out | Returns To Code Affordances: Same columns Controls: click, type, call, observe, write, render Wires Out (solid →): Control flow — calls, triggers, writes Returns To (dashed -.->): Data flow — return values, reads

Quick Reference: Slicing

• Every slice must end in demo-able UI
• Max 9 slices
• Each slice demonstrates a mechanism working
• Format: V1: Name — affordances, demo statement