refactor: enhance TECH_STACK_PROMPT with clearer phase structure and rules

templates/prompts/TECH_STACK_PROMPT.txt

@@ -1,31 +1,51 @@
-Generate TECH_STACK.md.
+Generate TECH_STACK.md in two phases.
 
 INPUTS
 - PRODUCT_SPEC.md: correct and final. Source of product requirements.
-- TECH_DECISIONS: correct and final. Sole source of technology names and versions.
+- TECH_DECISIONS: correct and final. Highest-priority source of technology names and versions.
 - ARCHITECTURE.md does not exist yet. It will be written AFTER this document, using it as input.
 
 SOURCE RULES
-- Every technology, tool, library, version, file name, and env var name MUST come from TECH_DECISIONS.
-- MUST NOT infer, invent, evaluate, or recommend technologies.
-- MUST NOT restate product behavior from PRODUCT_SPEC (commands, options, sorting, error cases).
-- If TECH_DECISIONS conflicts with PRODUCT_SPEC, stop and list the conflicts.
-
-REQUIRED DECISIONS CHECK
-Verify TECH_DECISIONS defines all of the following. For each missing item, ask one question.
-- runtime + version
-- language + compile/run method
-- module system
-- package manager + lockfile
-- web framework + version
-- libraries (name + version): config parser, CLI argument parser, YouTube API client/HTTP
-- test tool + coverage threshold
-- linter, formatter
-- CI system
-- deployment target + release/distribution method
-- license
-- config file format, env var names, secret storage
-If any item is missing or conflicting: output ONLY the numbered question list. Nothing else.
+- Final TECH_STACK.md MUST contain only technologies from: (a) TECH_DECISIONS, (b) proposals approved by the user in Phase 1.
+- MUST NOT put an unapproved technology in TECH_STACK.md.
+- MUST NOT contradict TECH_DECISIONS. If a proposal would conflict with it, drop the proposal.
+- MUST NOT restate product behavior from PRODUCT_SPEC.
+- If TECH_DECISIONS conflicts with PRODUCT_SPEC, stop and list the conflicts. Nothing else.
+
+PHASE 1: GAP FILL AND PROPOSAL
+
+Step 1. Determine project type from PRODUCT_SPEC and TECH_DECISIONS.
+Examples: web service, web app, CLI tool, library/package, desktop app, mobile app, game, batch/data pipeline, browser extension, other.
+If the type is unclear, include it as a BLOCKED question.
+
+Step 2. Derive the decision categories this project type needs.
+- Always required: runtime/platform + version; language + build/run method; package/dependency manager + lockfile (if the ecosystem has one); test tool + coverage threshold; linter; formatter; CI system; distribution/release method and target; license.
+- Configuration, only if the project is configurable: config format, setting/env var names, secret storage.
+- Type-specific categories: derive them from the project type and the capabilities PRODUCT_SPEC requires (e.g. entry-point framework, argument parsing, persistence, networking/HTTP client, external service clients, auth, background work, UI toolkit, rendering/graphics, packaging/installer, update mechanism).
+- Use PRODUCT_SPEC only to decide whether a category applies, never to choose a technology.
+- MUST NOT ask about a category the project type does not need.
+
+Step 3. For every category not defined in TECH_DECISIONS, decide it yourself and propose a value. Do NOT ask open questions for gaps you can fill.
+
+Classify each proposal:
+- OBVIOUS: mandated or defaulted by an already-decided runtime, framework, or tool (e.g. its official package manager, lockfile, config format, test runner, linter). Decide it. Do not ask.
+- CHOICE: real alternatives exist. Pick one recommended option, name the one main alternative, give a one-line reason.
+- BLOCKED: no defensible default without information only the user has (e.g. release target, license intent, project type). Ask one question, with your best guess attached.
+
+Versions: propose a version constraint matching the ecosystem's syntax. Mark any version you are not certain is current with "(verify)".
+
+Phase 1 output format (and NOTHING else):
+1. Project type: one line.
+2. OBVIOUS list: one line each — item: value.
+3. CHOICE list: one line each — item: recommended (alt: X) — reason.
+4. BLOCKED list: numbered questions, each with a best-guess default.
+5. Final line: "Reply `approve all`, or list changes by item."
+
+Do NOT output TECH_STACK.md in Phase 1.
+If there are no gaps, skip Phase 1 and go to Phase 2.
+
+PHASE 2: GENERATE
+Run after the user approves or edits the Phase 1 list. Treat the approved list as part of TECH_DECISIONS. Do NOT re-ask approved items. If the user's edits create a conflict, list the conflict and stop.
 
 SCOPE BOUNDARY
 - Cover only technology choices and the rules that follow from them.
@@ -34,14 +54,14 @@ SCOPE BOUNDARY
 - MUST NOT include process rules (change control), product non-goals, or architectural invariants.
 - State each rule once. MUST NOT repeat a rule across sections.
 
-OUTPUT FORMAT
+OUTPUT FORMAT (Phase 2)
 - Exactly these 8 sections, in this order, numbered headings, no other sections:
   1. Languages / runtimes / frameworks / libraries (name + version constraint)
   2. Framework- or tool-mandated paths and file names only
   3. Coding conventions specific to the chosen stack
   4. Testing rules (tools, naming, required coverage)
-  5. Configuration rules (env vars, config files, secrets handling)
-  6. Deployment rules (targets, build, release steps)
+  5. Configuration rules (settings, config files, secrets handling; write "None" if not configurable)
+  6. Build, packaging, and release rules (targets, build, distribution steps)
   7. Security rules tied to the chosen stack
   8. Non-goals (technologies and tools explicitly excluded)
 - Flat terse bullets. "MUST / MUST NOT" phrasing. No prose, no explanations, no "why".