brainstorming

Brainstorming Ideas Into Designs

Understand the requested outcome, inspect existing patterns, choose a complete solution, and continue through implementation when that is what the user asked. Authorization and stop conditions come from OPS.md §1, not the design phase. A requested local auth, schema or dependency change needs risk-appropriate checks, not redundant permission merely because of its category.

Choose the necessary design depth

• Investigation/spike: answer a feasibility question with a bounded probe. Define what the probe measures, run it, report evidence and limitations. Do not silently turn a requested investigation into a permanent feature.
• Bounded change: trace the existing flow and affected callers, resolve details from code, state the approach briefly, implement and verify.
• Architectural change: map responsibilities, interfaces, state transitions, compatibility and failure handling before code. Decompose independent capabilities with explicit integration contracts; complete every requested capability, not only the first sub-project.

Complexity determines design depth, not permission. Reclassify when new facts change the approach; no mandatory heavier-path tie-break or approval pause. Plan/design-only requests stop at their requested deliverable.

Design workflow

1. Inspect context. Read the relevant implementation, configuration and existing decisions. Reuse project conventions rather than adding a parallel design. Do not ask the user for repository-provided information.
2. Define done. Capture required behaviors, compatibility, constraints, excluded work and observable acceptance. A simpler implementation must still deliver all requested formats, paths, error behavior and quality.
3. Resolve uncertainty. Decide ordinary details from evidence and explain consequential defaults. When something non-trivial about the intent is missing, ask one open, description-first question anchored in specifics ("walk me through the last time this hurt you?", "what would make you wince if I got it wrong?") rather than a steering option menu; offer a short menu only when the user is stuck or asks what you think. Ask only when an unavailable answer would materially change the outcome or an action lacks authority. Batch related questions; continue independent authorized work when possible.
4. Compare real alternatives. Include alternatives only when they have meaningful tradeoffs. Prefer the simplest complete approach; do not invent options to fill a quota. Existing proven patterns may settle the decision.
5. Design the change. Cover components, data flow, errors, integration, migration and verification at the depth needed. Separate units by reason for change, keep concrete interfaces, avoid unrelated restructuring. Consequential platform, language, library or medium choices rest on repo defaults and existing patterns where they exist; when you choose one the user has not stated, own it as your call in plain words, never record it as something the user agreed to, and surface it early enough to correct cheaply.
6. Check the design. Resolve contradictions, placeholders, missing required paths and uncertain boundaries. Map acceptance to checks before coding. For a complex design, also run a builder-perspective ambiguity check: read the design as a builder who cannot ask you anything, and collect only the points where a wrong guess would change what gets built — skip wording nitpicks and anything the design explicitly leaves to the builder. Use an available reviewer when independent perspective is useful and host rules permit it; otherwise do the check yourself. Answer the answerable from evidence and mark those calls as yours; bring the genuinely user-owned questions in one batch, most important first. Scale this check to design complexity; a bounded change needs little or none of it.
7. Continue. Use writing-plans for complex execution, then implement and verify without asking the user to approve the same authorized work again.