| name | breadboarding |
| description | Transform a workflow description into affordance tables showing UI and Code affordances with their wiring. Use to map existing systems or design new ones from shaped parts. |
Breadboarding
Breadboarding transforms a workflow description into tables of affordances and their relationships. The tables are the truth. Mermaid diagrams are optional human-facing views.
Branches
Pick the branch first, then load the files it needs:
Workflow
- Classify the branch. Identify whether you are mapping an existing system, designing from shaped parts, translating a whiteboard, or slicing/chunking an existing breadboard.
- Load the branch references. Load every file named by the branch table before producing the breadboard. The root file is not enough context.
- Produce tables first. Create the Places, UI Affordances, Code Affordances, and Data Stores tables described in
TABLES.md. Diagrams come after tables, never instead of them.
- Trace wiring. Follow navigation and data wires until each affordance's outgoing and return relationships are explicit.
- Verify the board. Run the completion checks below and repair the tables before declaring the breadboard done.
Completion checks
A breadboard is complete when:
- every Place has a clear interaction boundary;
- every UI and Code affordance has a stable ID and a concrete name;
- every
Wires Out and Returns To target resolves to an existing affordance or Place;
- every UI affordance that displays data has a source;
- every navigation affordance connects to the Place it reaches;
- every side effect names the store or external system it changes;
- control flow and data flow are represented separately;
- optional Mermaid or visual output matches the tables rather than adding hidden truth.
Core rule
Never rely on memory when mapping an existing system. Check the code, product, docs, or artifact that owns the fact, and mark uncertainty explicitly when the source cannot be checked.
