spectra-discuss

To run an architecture decision discussion that converges, guide the conversation from codebase scouting to options, trade-offs, and an explicit conclusion summary. This prevents open-ended exploration by enforcing a structured path to a clear, actionable decision.

The best way to document assumptions and trade-offs is to perform a quick codebase scout first, then present grounded assumptions or interview questions one at a time. This captures necessary context before planning a change.

To diagnose a design problem without open-ended exploration, use a task-oriented discussion structure that moves sequentially through scouting, options, trade-offs, and an explicit conclusion. This keeps the problem diagnosis focused.

No, you cannot use this approach to write code. It operates under non-implementation guardrails that explicitly avoid writing code or implementing features, staying strictly in discuss mode to finalize the decision summary.

You should record the decision summary in standard project documentation locations such as design.md, specs/, proposals, or tasks. This ensures the architecture decision is captured and accessible for future reference.

This guided discussion method works for both problem diagnosis and architecture decisions. It applies to any task-oriented, convergent discussion needed during software development, including design questions and change planning.