Architect First

Settle types, module shape, and boundaries before writing code. Cheaper to fix the design now than rewrite callers later.

Do NOT use when

• Single-function fix (use tdd-bugfix)
• Types are obvious and scope is narrow
• The change fits in one module with no boundary changes
• During implementation (design is already approved)

Workflow

1. Search ck_memory_search for prior decisions about the affected area.
2. Investigate existing module boundaries (use investigate skill if needed).
3. Define:

• Types/structs for key data structures
• Module boundaries: owns / exposes / depends / does-not for each module
• Data flow: trace primary use case across boundaries

1. Mark unresolved decisions as [DECISION NEEDED].
2. Record design via ck_memory_record (type: decision).
3. Submit via ck_review_submit (review_type: plan, plan_phase: design_options). Wait for approval.

Design principles

• Boundary discipline — modules own their data and invariants
• Type-system discipline — structs and typespecs, not bare maps
• Subtract before you add — can existing module absorb this?
• Minimize reader load — purpose clear from public API alone

Output

• Types and structs
• Module boundary definitions
• Data flow for primary use case
• ck_review_submit plan awaiting approval
• ck_memory_record with the design