brainstorming

1# Brainstorming
2 
3## Interview before you build
4 
5- Every feature, behavior change, or bug fix goes through this workflow. Depth scales with the
6  change and never drops to zero: a small change gets one short round and a few lines of task-spec.
7- The aim is a design the user understands and has accepted, recorded in a spec-graph `task-spec`,
8  built, and then reflected in the durable specs — not a speculative implementation.
9- Do not implement until the design is accepted. An explicit design or acceptance criteria in the
10  request count as approval of what they cover; build on them and never re-ask them.
11 
12## Doc map
13 
14- `fixing-a-bug.md` — the bug branch (step 4).
15- `amending-specs.md` — bringing the durable specs in line with what was built (step 9); the tail of
16  both paths and where this workflow ends.
17 
18## The workflow
19 
201. **Orient.** Use the spec-graph skill to find the specs that govern the area; read code second to
21   confirm implementation details. Do not read unrelated specs. Note any non-obvious decision the
22   change touches whose *why* is not recorded — it becomes a question in step 6.
232. **Scope check.** If the request bundles independent product decisions or subsystems, separate
24   them rather than blending unrelated decisions into one task-spec.
253. **Open a task-spec.** `spec_create` a `task-spec` at **`.thinkrail/context/TASK-<slug>.md`** (id,
26   title, status: draft, parent: the nearest relevant module). This gitignored file is the one
27…