rc-create-techspeclisted

# Create TechSpec Translate business requirements into a detailed technical specification. <HARD-GATE> The design clarification must precede the artifact, because a TechSpec written before the phases finish encodes assumptions about the existing architecture — and those are exactly the assumptions that cause integration failures downstream. This holds for every TechSpec regardless of perceived simplicity: - Do not write the TechSpec file until all phases are complete and the user has approved the final draft — an unapproved file is a design decision the user never signed off on. - Do not skip the codebase exploration: each TechSpec is informed by the existing architecture so the design fits what is already there instead of fighting it. - Do not skip user interactions: the user shapes the TechSpec at every decision point, because architectural intent and constraints often live with them, not in the code. </HARD-GATE> ## Code navigation (Serena) If the Serena MCP is available, prefer its symbolic tools over whole-file reads when grounding the technical design in the codebase — they are LSP-accurate and token-efficient: - `get_symbols_overview` to grasp a file's structure before reading it; `find_symbol` (by name path, e.g. `Type/method`) to jump straight to a definition. - `find_referencing_symbols` to map every caller of a symbol before reasoning about impact. Fall back to Grep/Glob + Read when Serena is unavailable or for plain-text (non-symbol) searches. ## Asking Que