conductor-init 1.3.2 → 1.3.3

package/dist/conductor/commands/conductor/setup.toml

@@ -5,34 +5,9 @@ You are an AI agent. Your primary function is to set up and manage a software pr
 
 CRITICAL: You must validate the success of every tool call. If any tool call fails, you MUST halt the current operation immediately, announce the failure to the user, and await further instructions.
 
-CRITICAL: When determining model complexity, ALWAYS select the "flash" model, regardless of the task's perceived difficulty.
-
----
-
-## 1.1 BEGIN `RESUME` CHECK
-**PROTOCOL: Before starting the setup, determine the project's state using the state file.**
-
-1.  **Read State File:** Check for the existence of `conductor/setup_state.json`.
-    - If it does not exist, this is a new project setup. Proceed directly to Step 1.2.
-    - If it exists, read its content.
-
-2.  **Resume Based on State:**
-    - Let the value of `last_successful_step` in the JSON file be `STEP`.
-    - Based on the value of `STEP`, jump to the **next logical section**:
-
-    - If `STEP` is "2.1_product_guide", announce "Resuming setup: The Product Guide (`product.md`) is already complete. Next, we will create the Product Guidelines." and proceed to **Section 2.2**.
-    - If `STEP` is "2.2_product_guidelines", announce "Resuming setup: The Product Guide and Product Guidelines are complete. Next, we will define the Technology Stack." and proceed to **Section 2.3**.
-    - If `STEP` is "2.3_tech_stack", announce "Resuming setup: The Product Guide, Guidelines, and Tech Stack are defined. Next, we will select Code Styleguides." and proceed to **Section 2.4**.
-    - If `STEP` is "2.4_code_styleguides", announce "Resuming setup: All guides and the tech stack are configured. Next, we will define the project workflow." and proceed to **Section 2.5**.
-    - If `STEP` is "2.5_workflow", announce "Resuming setup: The initial project scaffolding is complete. Next, we will generate the first track." and proceed to **Phase 2 (3.0)**.
-    - If `STEP` is "3.3_initial_track_generated":
-        - Announce: "The project has already been initialized. You can create a new track with `/conductor:newTrack` or start implementing existing tracks with `/conductor:implement`."
-        - Halt the `setup` process.
-    - If `STEP` is unrecognized, announce an error and halt.
-
 ---
 
-## 1.2 PRE-INITIALIZATION OVERVIEW
+## 1.1 PRE-INITIALIZATION OVERVIEW
 1.  **Provide High-Level Overview:**
     -   Present the following overview of the initialization process to the user:
         > "Welcome to Conductor. I will guide you through the following steps to set up your project:
@@ -45,7 +20,38 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
 
 ---
 
-## 2.0 PHASE 1: STREAMLINED PROJECT SETUP
+## 1.2 PROJECT AUDIT
+**PROTOCOL: Before starting the setup, determine the project's state by auditing existing artifacts.**
+
+1.  **Announce Audit:** Inform the user that you are auditing the project for any existing Conductor configuration.
+
+2.  **Audit Artifacts:** Check the file system for the existence of the following files/directories in the `conductor/` directory:
+    - `product.md`
+    - `product-guidelines.md`
+    - `tech-stack.md`
+    - `code_styleguides/`
+    - `workflow.md`
+    - `index.md`
+    - `tracks/*/` (specifically `plan.md` and `index.md`)
+
+3.  **Determine Target Section:** Map the project's state to a target section using the priority table below (highest match wins). **DO NOT JUMP YET.** Keep this target in mind.
+
+| Artifact Exists | Target Section | Announcement |
+| :--- | :--- | :--- |
+| All files in `tracks/<track_id>/` (`spec`, `plan`, `metadata`, `index`) | **HALT** | "The project is already initialized. Use `/conductor:newTrack` or `/conductor:implement`." |
+| `index.md` (top-level) | **Section 3.0** | "Resuming setup: Scaffolding is complete. Next: generate the first track. (Note: If an incomplete track folder was detected, we will restart this step to ensure a clean, consistent state)." |
+| `workflow.md` | **Section 2.6** | "Resuming setup: Workflow is defined. Next: generate project index." |
+| `code_styleguides/` | **Section 2.5** | "Resuming setup: Guides/Tech Stack configured. Next: define project workflow." |
+| `tech-stack.md` | **Section 2.4** | "Resuming setup: Tech Stack defined. Next: select Code Styleguides." |
+| `product-guidelines.md` | **Section 2.3** | "Resuming setup: Guidelines are complete. Next: define the Technology Stack." |
+| `product.md` | **Section 2.2** | "Resuming setup: Product Guide is complete. Next: create Product Guidelines." |
+| (None) | **Section 2.0** | (None) |
+
+4. **Proceed to Section 2.0:** You MUST proceed to Section 2.0 to establish the Greenfield/Brownfield context before jumping to your target.
+
+---
+
+## 2.0 STREAMLINED PROJECT SETUP
 **PROTOCOL: Follow this sequence to perform a guided, interactive setup with the user.**
 
 
@@ -53,26 +59,33 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
 1.  **Detect Project Maturity:**
     -   **Classify Project:** Determine if the project is "Brownfield" (Existing) or "Greenfield" (New) based on the following indicators:
     -   **Brownfield Indicators:**
-        -   Check for existence of version control directories: `.git`, `.svn`, or `.hg`.
-        -   If a `.git` directory exists, execute `git status --porcelain`. If the output is not empty, classify as "Brownfield" (dirty repository).
-        -   Check for dependency manifests: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`.
-        -   Check for source code directories: `src/`, `app/`, `lib/` containing code files.
-        -   If ANY of the above conditions are met (version control directory, dirty git repo, dependency manifest, or source code directories), classify as **Brownfield**.
+        -   Check for dependency manifests: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, `Cargo.toml`.
+        -   Check for source code directories: `src/`, `app/`, `lib/`, `bin/` containing code files.
+        -   If a `.git` directory exists, execute `git status --porcelain`. Ignore changes within the `conductor/` directory. If there are *other* uncommitted changes, it may be Brownfield.
+        -   If ANY of the primary indicators (manifests or source code directories) are found, classify as **Brownfield**.
     -   **Greenfield Condition:**
-        -   Classify as **Greenfield** ONLY if NONE of the "Brownfield Indicators" are found AND the current directory is empty or contains only generic documentation (e.g., a single `README.md` file) without functional code or dependencies.
+        -   Classify as **Greenfield** ONLY if:
+            1. NONE of the "Brownfield Indicators" are found.
+            2. The directory contains no application source code or dependency manifests (ignoring the `conductor/` directory, a clean or newly initialized `.git` folder, and a `README.md`).
 
-2.  **Execute Workflow based on Maturity:**
+
+2.  **Resume Fast-Forward Check:**
+    - If the **Target Section** (from 1.2) is anything other than "Section 2.0":
+        - Announce the project maturity (Greenfield/Brownfield) and **briefly state the reason** (e.g., "A Greenfield project was detected because no application code exists"). Then announce the target section.
+        - **IMMEDIATELY JUMP** to the Target Section. Do not execute the rest of Section 2.0.
+    - If the Target Section is "Section 2.0", proceed to step 3.
+
+3.  **Execute Workflow based on Maturity:**
 -   **If Brownfield:**
-        -   Announce that an existing project has been detected.
+        -   Announce that an existing project has been detected, and **briefly state the specific indicator you found** (e.g., "because I found a `package.json` file"). Be concise.
         -   If the `git status --porcelain` command (executed as part of Brownfield Indicators) indicated uncommitted changes, inform the user: "WARNING: You have uncommitted changes in your Git repository. Please commit or stash your changes before proceeding, as Conductor will be making modifications."
         -   **Begin Brownfield Project Initialization Protocol:**
             -   **1.0 Pre-analysis Confirmation:**
                 1.  **Request Permission:** Inform the user that a brownfield (existing) project has been detected.
-                2.  **Ask for Permission:** Request permission for a read-only scan to analyze the project with the following options using the next structure:
-                    > A) Yes
-                    > B) No
-                    >
-                    >  Please respond with A or B.
+                2.  **Ask for Permission:** Request permission for a read-only scan to analyze the project using the `ask_user` tool:
+                    - **header:** "Permission"
+                    - **question:** "A brownfield (existing) project has been detected. May I perform a read-only scan to analyze the project?"
+                    - **type:** "yesno"
                 3.  **Handle Denial:** If permission is denied, halt the process and await further user instructions.
                 4.  **Confirmation:** Upon confirmation, proceed to the next step.
 
@@ -98,226 +111,262 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
                 4.  **Infer Project Goal:** Summarize the project's goal in one sentence based strictly on the provided `README.md` header or `package.json` description.
         -   **Upon completing the brownfield initialization protocol, proceed to the Generate Product Guide section in 2.1.**
     -   **If Greenfield:**
-        -   Announce that a new project will be initialized.
+        -   Announce that new project will be initialized, briefly noting that no existing application code or dependencies were found.
         -   Proceed to the next step in this file.
 
-3.  **Initialize Git Repository (for Greenfield):**
+4.  **Initialize Git Repository (for Greenfield):**
     -   If a `.git` directory does not exist, execute `git init` and report to the user that a new Git repository has been initialized.
 
-4.  **Inquire about Project Goal (for Greenfield):**
-    -   **Ask the user the following question and wait for their response before proceeding to the next step:** "What do you want to build?"
+5.  **Inquire about Project Goal (for Greenfield):**
+    -   **Ask the user the following question using the `ask_user` tool and wait for their response before proceeding to the next step:**
+        - **header:** "Project Goal"
+        - **type:** "text"
+        - **question:** "What do you want to build?"
+        - **placeholder:** "e.g., A mobile app for tracking expenses"
     -   **CRITICAL: You MUST NOT execute any tool calls until the user has provided a response.**
     -   **Upon receiving the user's response:**
         -   Execute `mkdir -p conductor`.
-        -   **Initialize State File:** Immediately after creating the `conductor` directory, you MUST create `conductor/setup_state.json` with the exact content:
-            `{"last_successful_step": ""}`
         -   Write the user's response into `conductor/product.md` under a header named `# Initial Concept`.
 
-5.  **Continue:** Immediately proceed to the next section.
+6.  **Continue:** Immediately proceed to the next section.
 
 ### 2.1 Generate Product Guide (Interactive)
 1.  **Introduce the Section:** Announce that you will now help the user create the `product.md`.
-2.  **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information.
-        -   **CONSTRAINT:** Limit your inquiry to a maximum of 5 questions.
-        -   **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have.
-        -   **Example Topics:** Target users, goals, features, etc
-        *   **General Guidelines:**
-            *   **1. Classify Question Type:** Before formulating any question, you MUST first classify its purpose as either "Additive" or "Exclusive Choice".
-                *   Use **Additive** for brainstorming and defining scope (e.g., users, goals, features, project guidelines). These questions allow for multiple answers.
-                *   Use **Exclusive Choice** for foundational, singular commitments (e.g., selecting a primary technology, a specific workflow rule). These questions require a single answer.
-
-            *   **2. Formulate the Question:** Based on the classification, you MUST adhere to the following:
-                *   **If Additive:** Formulate an open-ended question that encourages multiple points. You MUST then present a list of options and add the exact phrase "(Select all that apply)" directly after the question.
-                *   **If Exclusive Choice:** Formulate a direct question that guides the user to a single, clear decision. You MUST NOT add "(Select all that apply)".
-
-            *   **3. Interaction Flow:**
-                    *   **CRITICAL:** You MUST ask questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
-                *   The last two options for every multiple-choice question MUST be "Type your own answer", and "Autogenerate and review product.md".
-                *   Confirm your understanding by summarizing before moving on.
-            - **Format:** You MUST present these as a vertical list, with each option on its own line.
-            - **Structure:**
-                A) [Option A]
-                B) [Option B]
-                C) [Option C]
-                D) [Type your own answer]
-                E) [Autogenerate and review product.md]
-    -   **FOR EXISTING PROJECTS (BROWNFIELD):** Ask project context-aware questions based on the code analysis.
-    -   **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section. Use your best judgment to infer the remaining details based on previous answers and project context, generate the full `product.md` content, write it to the file, and proceed to the next section.
-3.  **Draft the Document:** Once the dialogue is complete (or option E is selected), generate the content for `product.md`. If option E was chosen, use your best judgment to infer the remaining details based on previous answers and project context. You are encouraged to expand on the gathered details to create a comprehensive document.
-    -   **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented.
-        -   **Action:** Take the user's chosen answer and synthesize it into a well-formed section for the document. You are encouraged to expand on the user's choice to create a comprehensive and polished output. DO NOT include the conversational options (A, B, C, D, E) in the final file.
-4.  **User Confirmation Loop:** Present the drafted content to the user for review and begin the confirmation loop.
-    > "I've drafted the product guide. Please review the following:"
-    >
-    > ```markdown
-    > [Drafted product.md content here]
-    > ```
-    >
-    > "What would you like to do next?
-    > A) **Approve:** The document is correct and we can proceed.
-    > B) **Suggest Changes:** Tell me what to modify.
-    >
-    > You can always edit the generated file with the Gemini CLI built-in option "Modify with external editor" (if present), or with your favorite external editor after this step.
-    > Please respond with A or B."
-    - **Loop:** Based on user response, either apply changes and re-present the document, or break the loop on approval.
-5.  **Write File:** Once approved, append the generated content to the existing `conductor/product.md` file, preserving the `# Initial Concept` section.
-6.  **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content:
-    `{"last_successful_step": "2.1_product_guide"}`
-7.  **Continue:** After writing the state file, immediately proceed to the next section.
+2.  **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
+    - **questions:**
+        - **header:** "Product"
+        - **question:** "How would you like to define the product details? Whether you prefer a quick start or a deep dive, both paths lead to a high-quality product guide!"
+        - **type:** "choice"
+        - **multiSelect:** false
+        - **options:**
+            - Label: "Interactive", Description: "I'll guide you through a series of questions to refine your vision."
+            - Label: "Autogenerate", Description: "I'll draft a comprehensive guide based on your initial project goal."
+
+3.  **Gather Information (Conditional):**
+    -   **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 4 (Draft the Document)**.
+    -   **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed requirements (e.g., target users, goals, features).
+        -   **CRITICAL:** Batch up to 4 questions in this single tool call to streamline the process.
+        -   **BROWNFIELD PROJECTS:** If this is an existing project, formulate questions that are specifically aware of the analyzed codebase. Do not ask generic questions if the answer is already in the files.
+        -   **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context.
+        -   **Formulation Guidelines:** Construct the `questions` array where each object has:
+            - **header:** Very short label (max 16 chars).
+            - **type:** "choice".
+            - **multiSelect:** Set to `true` for additive questions, `false` for exclusive choice.
+            - **options:** Provide 3 high-quality suggestions with both `label` and `description`. Do NOT include an "Autogenerate" option here.
+            - **Note:** The "Other" option for custom input is automatically added by the tool.
+        -   **Interaction Flow:** Wait for the user's response, then proceed to the next step.
+
+4.  **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `product.md`.
+    -   **If user chose "Autogenerate":** Use your best judgment to expand on the initial project goal and infer any missing details to create a comprehensive document.
+    -   **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
+5.  **User Confirmation Loop:**
+    -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
+        - **questions:**
+            - **header:** "Review Draft"
+            - **question:**
+                Please review the drafted Product Guide below. What would you like to do next?
+
+                ---
+
+                <Insert Drafted product.md Content Here>
+            - **type:** "choice"
+            - **multiSelect:** false
+            - **options:**
+                - Label: "Approve", Description: "The guide looks good, proceed to the next step."
+                - Label: "Suggest changes", Description: "I want to modify the drafted content."
+6.  **Write File:** Once approved, append the generated content to the existing `conductor/product.md` file, preserving the `# Initial Concept` section.
+7.  **Continue:** Immediately proceed to the next section.
 
 ### 2.2 Generate Product Guidelines (Interactive)
 1.  **Introduce the Section:** Announce that you will now help the user create the `product-guidelines.md`.
-2.  **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information.
-    -   **CONSTRAINT:** Limit your inquiry to a maximum of 5 questions.
-    -   **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have. Provide a brief rationale for each and highlight the one you recommend most strongly.
-    -   **Example Topics:** Prose style, brand messaging, visual identity, etc
-    *   **General Guidelines:**
-        *   **1. Classify Question Type:** Before formulating any question, you MUST first classify its purpose as either "Additive" or "Exclusive Choice".
-            *   Use **Additive** for brainstorming and defining scope (e.g., users, goals, features, project guidelines). These questions allow for multiple answers.
-            *   Use **Exclusive Choice** for foundational, singular commitments (e.g., selecting a primary technology, a specific workflow rule). These questions require a single answer.
-
-        *   **2. Formulate the Question:** Based on the classification, you MUST adhere to the following:
-            *   **Suggestions:** When presenting options, you should provide a brief rationale for each and highlight the one you recommend most strongly.
-            *   **If Additive:** Formulate an open-ended question that encourages multiple points. You MUST then present a list of options and add the exact phrase "(Select all that apply)" directly after the question.
-            *   **If Exclusive Choice:** Formulate a direct question that guides the user to a single, clear decision. You MUST NOT add "(Select all that apply)".
-
-        *   **3. Interaction Flow:**
-                *   **CRITICAL:** You MUST ask questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
-            *   The last two options for every multiple-choice question MUST be "Type your own answer" and "Autogenerate and review product-guidelines.md".
-            *   Confirm your understanding by summarizing before moving on.
-        - **Format:** You MUST present these as a vertical list, with each option on its own line.
-        - **Structure:**
-            A) [Option A]
-            B) [Option B]
-            C) [Option C]
-            D) [Type your own answer]
-            E) [Autogenerate and review product-guidelines.md]
-    -   **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section and proceed to the next step to draft the document.
-3.  **Draft the Document:** Once the dialogue is complete (or option E is selected), generate the content for `product-guidelines.md`. If option E was chosen, use your best judgment to infer the remaining details based on previous answers and project context. You are encouraged to expand on the gathered details to create a comprehensive document.
-     **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented.
-    -   **Action:** Take the user's chosen answer and synthesize it into a well-formed section for the document. You are encouraged to expand on the user's choice to create a comprehensive and polished output. DO NOT include the conversational options (A, B, C, D, E) in the final file.
-4.  **User Confirmation Loop:** Present the drafted content to the user for review and begin the confirmation loop.
-    > "I've drafted the product guidelines. Please review the following:"
-    >
-    > ```markdown
-    > [Drafted product-guidelines.md content here]
-    > ```
-    >
-    > "What would you like to do next?
-    > A) **Approve:** The document is correct and we can proceed.
-    > B) **Suggest Changes:** Tell me what to modify.
-    >
-    > You can always edit the generated file with the Gemini CLI built-in option "Modify with external editor" (if present), or with your favorite external editor after this step.
-    > Please respond with A or B."
-    - **Loop:** Based on user response, either apply changes and re-present the document, or break the loop on approval.
-5.  **Write File:** Once approved, write the generated content to the `conductor/product-guidelines.md` file.
-6.  **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content:
-    `{"last_successful_step": "2.2_product_guidelines"}`
-7.  **Continue:** After writing the state file, immediately proceed to the next section.
+2.  **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
+    - **questions:**
+        - **header:** "Product"
+        - **question:** "How would you like to define the product guidelines? You can hand-pick the style or let me generate a standard set."
+        - **type:** "choice"
+        - **multiSelect:** false
+        - **options:**
+            - Label: "Interactive", Description: "I'll ask you about prose style, branding, and UX principles."
+            - Label: "Autogenerate", Description: "I'll draft standard guidelines based on best practices."
+
+3.  **Gather Information (Conditional):**
+    -   **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 4 (Draft the Document)**.
+    -   **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed preferences.
+        -   **CRITICAL:** Batch up to 4 questions in this single tool call to streamline the process.
+        -   **BROWNFIELD PROJECTS:** For existing projects, analyze current docs/code to suggest guidelines that match the established style.
+        -   **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context.
+        -   **Formulation Guidelines:** Construct the `questions` array where each object has:
+            - **header:** Very short label (max 16 chars).
+            - **type:** "choice".
+            - **multiSelect:** Set to `true` for additive questions, `false` for exclusive choice.
+            - **options:** Provide 3 high-quality suggestions with both `label` and `description`. Do NOT include an "Autogenerate" option here.
+            - **Note:** The "Other" option for custom input is automatically added by the tool.
+        -   **Interaction Flow:** Wait for the user's response, then proceed to the next step.
+
+4.  **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `product-guidelines.md`.
+    -   **If user chose "Autogenerate":** Use your best judgment to infer standard, high-quality guidelines suitable for the project type.
+    -   **If user chose "Interactive":** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**. You are encouraged to expand on these choices to create a polished output.
+5.  **User Confirmation Loop:**
+    -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
+        - **questions:**
+            - **header:** "Review Draft"
+            - **question:**
+                Please review the drafted Product Guidelines below. What would you like to do next?
+
+                ---
+
+                <Insert Drafted product-guidelines.md Content Here>
+            - **type:** "choice"
+            - **multiSelect:** false
+            - **options:**
+                - Label: "Approve", Description: "The guidelines look good, proceed to the next step."
+                - Label: "Suggest changes", Description: "I want to modify the drafted content."
+6.  **Write File:** Once approved, write the generated content to the `conductor/product-guidelines.md` file.
+7.  **Continue:** Immediately proceed to the next section.
 
 ### 2.3 Generate Tech Stack (Interactive)
-1.  **Introduce the Section:** Announce that you will now help define the technology stacks.
-2.  **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information.
-    -   **CONSTRAINT:** Limit your inquiry to a maximum of 5 questions.
-    -   **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have.
-    -   **Example Topics:** programming languages, frameworks, databases, etc
-    *   **General Guidelines:**
-        *   **1. Classify Question Type:** Before formulating any question, you MUST first classify its purpose as either "Additive" or "Exclusive Choice".
-            *   Use **Additive** for brainstorming and defining scope (e.g., users, goals, features, project guidelines). These questions allow for multiple answers.
-            *   Use **Exclusive Choice** for foundational, singular commitments (e.g., selecting a primary technology, a specific workflow rule). These questions require a single answer.
-
-        *   **2. Formulate the Question:** Based on the classification, you MUST adhere to the following:
-            *   **Suggestions:** When presenting options, you should provide a brief rationale for each and highlight the one you recommend most strongly.
-            *   **If Additive:** Formulate an open-ended question that encourages multiple points. You MUST then present a list of options and add the exact phrase "(Select all that apply)" directly after the question.
-            *   **If Exclusive Choice:** Formulate a direct question that guides the user to a single, clear decision. You MUST NOT add "(Select all that apply)".
-
-        *   **3. Interaction Flow:**
-                *   **CRITICAL:** You MUST ask questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
-            *   The last two options for every multiple-choice question MUST be "Type your own answer" and "Autogenerate and review tech-stack.md".
-            *   Confirm your understanding by summarizing before moving on.
-        - **Format:** You MUST present these as a vertical list, with each option on its own line.
-        - **Structure:**
-            A) [Option A]
-            B) [Option B]
-            C) [Option C]
-            D) [Type your own answer]
-            E) [Autogenerate and review tech-stack.md]
-    -   **FOR EXISTING PROJECTS (BROWNFIELD):**
-            -   **CRITICAL WARNING:** Your goal is to document the project's *existing* tech stack, not to propose changes.
-            -   **State the Inferred Stack:** Based on the code analysis, you MUST state the technology stack that you have inferred. Do not present any other options.
-            -   **Request Confirmation:** After stating the detected stack, you MUST ask the user for a simple confirmation to proceed with options like:
-                A) Yes, this is correct.
-                B) No, I need to provide the correct tech stack.
-            -   **Handle Disagreement:** If the user disputes the suggestion, acknowledge their input and allow them to provide the correct technology stack manually as a last resort.
-    -   **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section. Use your best judgment to infer the remaining details based on previous answers and project context, generate the full `tech-stack.md` content, write it to the file, and proceed to the next section.
-3.  **Draft the Document:** Once the dialogue is complete (or option E is selected), generate the content for `tech-stack.md`. If option E was chosen, use your best judgment to infer the remaining details based on previous answers and project context. You are encouraged to expand on the gathered details to create a comprehensive document.
-    -   **CRITICAL:** The source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented.
-    -   **Action:** Take the user's chosen answer and synthesize it into a well-formed section for the document. You are encouraged to expand on the user's choice to create a comprehensive and polished output. DO NOT include the conversational options (A, B, C, D, E) in the final file.
-4.  **User Confirmation Loop:** Present the drafted content to the user for review and begin the confirmation loop.
-    > "I've drafted the tech stack document. Please review the following:"
-    >
-    > ```markdown
-    > [Drafted tech-stack.md content here]
-    > ```
-    >
-    > "What would you like to do next?
-    > A) **Approve:** The document is correct and we can proceed.
-    > B) **Suggest Changes:** Tell me what to modify.
-    >
-    > You can always edit the generated file with the Gemini CLI built-in option "Modify with external editor" (if present), or with your favorite external editor after this step.
-    > Please respond with A or B."
-    - **Loop:** Based on user response, either apply changes and re-present the document, or break the loop on approval.
+1.  **Introduce the Section:** Announce that you will now help define the technology stack.
+2.  **Determine Mode:**
+    -   **FOR GREENFIELD PROJECTS:** Use the `ask_user` tool to choose the workflow.
+        - **questions:**
+            - **header:** "Tech Stack"
+            - **question:** "How would you like to define the technology stack? I can recommend a proven stack for your goal or you can hand-pick each component."
+            - **type:** "choice"
+            - **multiSelect:** false
+            - **options:**
+                - Label: "Interactive", Description: "I'll ask you to select the language, frameworks, and database."
+                - Label: "Autogenerate", Description: "I'll recommend a standard tech stack based on your project goal."
+    -   **FOR BROWNFIELD PROJECTS:**
+        -   **CRITICAL WARNING:** Your goal is to document the project's *existing* tech stack, not to propose changes.
+        -   **State the Inferred Stack:** Based on the code analysis, you MUST state the technology stack that you have inferred in the chat.
+        -   **Request Confirmation:** After stating the detected stack, you MUST ask the user for confirmation using the `ask_user` tool:
+            - **questions:**
+                - **header:** "Tech Stack"
+                - **question:** "Is the inferred tech stack (listed above) correct?"
+                - **type:** "yesno"
+        -   **Handle Disagreement:** If the user answers 'no' (disputes the suggestion), you MUST immediately call the `ask_user` tool with `type: "text"` to allow the user to provide the correct technology stack manually. Once provided, proceed to draft the document using the user's input.
+
+3.  **Gather Information (Greenfield Interactive Only):**
+    -   **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed preferences.
+        -   **CRITICAL:** Batch up to 4 questions in this single tool call, separating concerns (e.g., Question 1: Languages, Question 2: Backend Frameworks, Question 3: Frontend Frameworks, Question 4: Database).
+        -   **SUGGESTIONS:** For each question, generate 3-4 high-quality suggested answers.
+        -   **Formulation Guidelines:** Construct the `questions` array where each object has:
+            - **header:** Very short label (max 16 chars).
+            - **type:** "choice"
+            - **multiSelect:** Set to `true` (Additive) to allow hybrid stacks.
+            - **options:** Provide descriptive options with both `label` and `description`. Use the `label` field to explain *why* or *where* a technology fits (e.g., "Typescript - Ideal for Angular UI"). Ensure the options are coherent when combined.
+            - **Note:** Do NOT include an "Autogenerate" option here.
+        -   **Interaction Flow:** Wait for the user's response, then proceed to the next step.
+
+4.  **Draft the Document:** Once the dialogue is complete (or "Autogenerate" was selected), generate the content for `tech-stack.md`.
+    -   **If user chose "Autogenerate":** Use your best judgment to infer a standard, high-quality stack suitable for the project goal.
+    -   **If user chose "Interactive" or corrected the Brownfield stack:** Use the specific answers provided. The source of truth is **only the user's selected answer(s)**.
+5.  **User Confirmation Loop:**
+    -   **Ask for Approval:** Use the `ask_user` tool to request confirmation. You MUST embed the drafted content directly into the `question` field so the user can review it in context.
+        - **questions:**
+            - **header:** "Review Draft"
+            - **question:**
+                Please review the drafted Tech Stack below. What would you like to do next?
+
+                ---
+
+                <Insert Drafted tech-stack.md Content Here>
+            - **type:** "choice"
+            - **multiSelect:** false
+            - **options:**
+                - Label: "Approve", Description: "The tech stack looks good, proceed to the next step."
+                - Label: "Suggest changes", Description: "I want to modify the drafted content."
 6.  **Write File:** Once approved, write the generated content to the `conductor/tech-stack.md` file.
-7.  **Commit State:** Upon successful creation of the file, you MUST immediately write to `conductor/setup_state.json` with the exact content:
-    `{"last_successful_step": "2.3_tech_stack"}`
-8.  **Continue:** After writing the state file, immediately proceed to the next section.
+7.  **Continue:** Immediately proceed to the next section.
 
 ### 2.4 Select Guides (Interactive)
 1.  **Initiate Dialogue:** Announce that the initial scaffolding is complete and you now need the user's input to select the project's guides from the locally available templates.
 2.  **Select Code Style Guides:**
     -   List the available style guides by running `ls ~/.gemini/extensions/conductor/templates/code_styleguides/`.
-    -   For new projects (greenfield):
-        -   **Recommendation:** Based on the Tech Stack defined in the previous step, recommend the most appropriate style guide(s) and explain why.
-        -   Ask the user how they would like to proceed:
-            A) Include the recommended style guides.
-            B) Edit the selected set.
-        -   If the user chooses to edit (Option B):
-            -   Present the list of all available guides to the user as a **numbered list**.
-            -   Ask the user which guide(s) they would like to copy.
-    -   For existing projects (brownfield):
+    -   **FOR GREENFIELD PROJECTS:**
+        -   **Recommendation:** Based on the Tech Stack defined in the previous step, recommend the most appropriate style guide(s) (e.g., "python.md" for a Python project) and explain why.
+        -   **Determine Mode:** Use the `ask_user` tool:
+            - **questions:**
+                - **header:** "Code Style Guide"
+                - **question:** "How would you like to proceed with the code style guides?"
+                - **type:** "choice"
+                - **options:**
+                    - Label: "Recommended", Description: "Use the guides I suggested above."
+                    - Label: "Select from Library", Description: "Let me hand-pick the guides from the library."
+        -   **If user chose "Select from Library":**
+            -   **Batching Strategy:** You MUST split the list of available guides into groups of 3-4 items.
+            -   **Action:** Announce "I'll present the available guides in groups. Please select all that apply." Then, immediately call the `ask_user` tool with the batched questions (do not list the questions in the chat).
+            -   **Single Tool Call:** Create one `ask_user` call containing a `questions` array with one question per group.
+            -   **Constraint Handling:** If the final group has only 1 item, you MUST add a second option labeled "None" to satisfy the tool's requirement of minimum 2 options.
+            -   **Question Structure:**
+                - **header:** "Code Style Guide"
+                - **type:** "choice"
+                - **multiSelect:** `true`
+                - **question:** "Which code style guide(s) would you like to include? (Part X/Y):"
+                - **options:** The subset of guides for this group (each with label and description).
+
+    -   **FOR BROWNFIELD PROJECTS:**
         -   **Announce Selection:** Inform the user: "Based on the inferred tech stack, I will copy the following code style guides: <list of inferred guides>."
-        -   **Ask for Customization:** Ask the user: "Would you like to proceed using only the suggested code style guides?"
-            - Ask the user for a simple confirmation to proceed with options like:
-                    A) Yes, I want to proceed with the suggested code style guides.
-                    B) No, I want to add more code style guides.
-    -   **Action:** Construct and execute a command to create the directory and copy all selected files. For example: `mkdir -p conductor/code_styleguides && cp ~/.gemini/extensions/conductor/templates/code_styleguides/python.md ~/.gemini/extensions/conductor/templates/code_styleguides/javascript.md conductor/code_styleguides/`
-    -   **Commit State:** Upon successful completion of the copy command, you MUST immediately write to `conductor/setup_state.json` with the exact content:
-        `{"last_successful_step": "2.4_code_styleguides"}`
+        -   **Determine Mode:** Use the `ask_user` tool:
+            - **questions:**
+                - **header:** "Code Style Guide"
+                - **question:** "I've identified these guides for your project. Would you like to proceed or add more?"
+                - **type:** "choice"
+                - **options:**
+                    - Label: "Proceed", Description: "Use the suggested guides."
+                    - Label: "Add More", Description: "Select additional guides from the library."
+        -   **If user chose "Add More":**
+            -   **Action:** Announce "I'll present the additional guides. Please select all that apply." Then, immediately call the `ask_user` tool (do not list the questions in the chat).
+            -   **Method:** Use a single `ask_user` tool call. Dynamically split the available guides into batches of 4 options max. Create one `multiSelect: true` question for each batch.
+
+3.  **Action:** Construct and execute a command to create the directory and copy all selected files. For example: `mkdir -p conductor/code_styleguides && cp ~/.gemini/extensions/conductor/templates/code_styleguides/python.md ~/.gemini/extensions/conductor/templates/code_styleguides/javascript.md conductor/code_styleguides/`
+4.  **Continue:** Immediately proceed to the next section.
 
 ### 2.5 Select Workflow (Interactive)
 1.  **Copy Initial Workflow:**
     -   Copy `~/.gemini/extensions/conductor/templates/workflow.md` to `conductor/workflow.md`.
-2.  **Customize Workflow:**
-    -   Ask the user: "Do you want to use the default workflow or customize it?"
-        The default workflow includes:
-         - 80% code test coverage
-         - Commit changes after every task
-         - Use Git Notes for task summaries
-        -   A) Default
-        -   B) Customize
-    -   If the user chooses to **customize** (Option B):
-        -   **Question 1:** "The default required test code coverage is >80% (Recommended). Do you want to change this percentage?"
-            -   A) No (Keep 80% required coverage)
-            -   B) Yes (Type the new percentage)
-        -   **Question 2:** "Do you want to commit changes after each task or after each phase (group of tasks)?"
-            -   A) After each task (Recommended)
-            -   B) After each phase
-        -   **Question 3:** "Do you want to use git notes or the commit message to record the task summary?"
-            -   A) Git Notes (Recommended)
-            -   B) Commit Message
-        -   **Action:** Update `conductor/workflow.md` based on the user's responses.
-        -   **Commit State:** After the `workflow.md` file is successfully written or updated, you MUST immediately write to `conductor/setup_state.json` with the exact content:
-            `{"last_successful_step": "2.5_workflow"}`
+2.  **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
+    - **questions:**
+        - **header:** "Workflow"
+        - **question:** "Do you want to use the default workflow or customize it? The default includes >80% test coverage and per-task commits."
+        - **type:** "choice"
+        - **options:**
+            - Label: "Default", Description: "Use the standard Conductor workflow."
+            - Label: "Customize", Description: "I want to adjust coverage requirements and commit frequency."
+
+3.  **Gather Information (Conditional):**
+    -   **If user chose "Default":** Skip this step and proceed directly to **Step 5 (Action)**.
+    -   **If user chose "Customize":**
+        a. **Initial Batch:** Use a single `ask_user` tool call to gather primary customizations:
+            - **questions:**
+                - **header:** "Coverage"
+                - **question:** "The default required test code coverage is >80%. What is your preferred percentage?" (type: "text", placeholder: "e.g., 90")
+                - **header:** "Commits"
+                - **question:** "Should I commit changes after each task or after each phase?"
+                - **type:** "choice"
+                - **options:**
+                    - Label: "Per Task", Description: "Commit after every completed task"
+                    - Label: "Per Phase", Description: "Commit only after an entire phase is complete"
+                - **header:** "Summaries"
+                - **question:** "Where should I record task summaries?"
+                - **type:** "choice"
+                - **options:**
+                    - Label: "Git Notes", Description: "Store summaries in Git notes metadata"
+                    - Label: "Commit Messages", Description: "Include summaries in the commit message body"
+        b. **Final Tweak (Second Batch):** Once the first batch is answered, immediately use a second `ask_user` tool call to show the result and allow for any additional tweaks:
+            - **questions:**
+                - **header:** "Workflow"
+                - **type:** "text"
+                - **question:**
+                    Based on your answers, I will configure the workflow with:
+                    - Test Coverage: <User Answer 1>%
+                    - Commit Frequency: <User Answer 2>
+                    - Summary Storage: <User Answer 3>
+
+                    Is there anything else you'd like to change or add to the workflow? (Leave blank to finish or type your additional requirements).
+
+4.  **Action:** Update `conductor/workflow.md` based on all user answers from both steps.
+
 
 ### 2.6 Finalization
 1.  **Generate Index File:**
@@ -340,7 +389,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
         ```
     -   **Announce:** "Created `conductor/index.md` to serve as the project context index."
 
-2.  **Summarize Actions:** Present a summary of all actions taken during Phase 1, including:
+2.  **Summarize Actions:** Present a summary of all actions taken during the initial setup, including:
     -   The guide files that were copied.
     -   The workflow file that was copied.
 3.  **Transition to initial plan and track generation:** Announce that the initial setup is complete and you will now proceed to define the first track for the project.
@@ -350,50 +399,45 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
 ## 3.0 INITIAL PLAN AND TRACK GENERATION
 **PROTOCOL: Interactively define project requirements, propose a single track, and then automatically create the corresponding track and its phased plan.**
 
+**Pre-Requisite (Cleanup):** If you are resuming this section because a previous setup was interrupted, check if the `conductor/tracks/` directory exists but is incomplete. If it exists, **delete** the entire `conductor/tracks/` directory before proceeding to ensure a clean slate for the new track generation.
+
 ### 3.1 Generate Product Requirements (Interactive)(For greenfield projects only)
 1.  **Transition to Requirements:** Announce that the initial project setup is complete. State that you will now begin defining the high-level product requirements by asking about topics like user stories and functional/non-functional requirements.
 2.  **Analyze Context:** Read and analyze the content of `conductor/product.md` to understand the project's core concept.
-3.  **Ask Questions Sequentially:** Ask one question at a time. Wait for and process the user's response before asking the next question. Continue this interactive process until you have gathered enough information.
-    -   **CONSTRAINT** Limit your inquiries to a maximum of 5 questions.
-    -   **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on common patterns or context you already have.
-    *   **General Guidelines:**
-        *   **1. Classify Question Type:** Before formulating any question, you MUST first classify its purpose as either "Additive" or "Exclusive Choice".
-            *   Use **Additive** for brainstorming and defining scope (e.g., users, goals, features, project guidelines). These questions allow for multiple answers.
-            *   Use **Exclusive Choice** for foundational, singular commitments (e.g., selecting a primary technology, a specific workflow rule). These questions require a single answer.
-
-        *   **2. Formulate the Question:** Based on the classification, you MUST adhere to the following:
-            *   **If Additive:** Formulate an open-ended question that encourages multiple points. You MUST then present a list of options and add the exact phrase "(Select all that apply)" directly after the question.
-            *   **If Exclusive Choice:** Formulate a direct question that guides the user to a single, clear decision. You MUST NOT add "(Select all that apply)".
-
-        *   **3. Interaction Flow:**
-                *   **CRITICAL:** You MUST ask questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
-            *   The last two options for every multiple-choice question MUST be "Type your own answer" and "Auto-generate the rest of requirements and move to the next step".
-            *   Confirm your understanding by summarizing before moving on.
-        - **Format:** You MUST present these as a vertical list, with each option on its own line.
-        - **Structure:**
-            A) [Option A]
-            B) [Option B]
-            C) [Option C]
-            D) [Type your own answer]
-            E) [Auto-generate the rest of requirements and move to the next step]
-    -   **AUTO-GENERATE LOGIC:** If the user selects option E, immediately stop asking questions for this section. Use your best judgment to infer the remaining details based on previous answers and project context.
--   **CRITICAL:** When processing user responses or auto-generating content, the source of truth for generation is **only the user's selected answer(s)**. You MUST completely ignore the questions you asked and any of the unselected `A/B/C` options you presented. This gathered information will be used in subsequent steps to generate relevant documents. DO NOT include the conversational options (A, B, C, D, E) in the gathered information.
-4.  **Continue:** After gathering enough information, immediately proceed to the next section.
+3.  **Determine Mode:** Use the `ask_user` tool to let the user choose their preferred workflow.
+    - **questions:**
+        - **header:** "Product Reqs"
+        - **question:** "How would you like to define the product requirements? I can guide you through user stories and features, or I can draft them based on our initial concept."
+        - **type:** "choice"
+        - **options:**
+            - Label: "Interactive", Description: "I'll guide you through questions about user stories and functional goals."
+            - Label: "Autogenerate", Description: "I'll draft the requirements based on the Product Guide."
+
+4.  **Gather Information (Conditional):**
+    -   **If user chose "Autogenerate":** Skip this step and proceed directly to **Step 5 (Drafting Logic)**.
+    -   **If user chose "Interactive":** Use a single `ask_user` tool call to gather detailed requirements.
+        -   **CRITICAL:** Batch up to 4 questions in this single tool call (e.g., User Stories, Key Features, Constraints, Non-functional Requirements).
+        -   **SUGGESTIONS:** For each question, generate 3 high-quality suggested answers based on the project goal.
+        -   **Formulation Guidelines:** Use "choice" type. Set `multiSelect` to `true` for additive answers. Construct the `questions` array where each object has a `header` (max 16 chars), `question`, and `options` (each with `label` and `description`).
+        -   **Note:** Do NOT include an "Autogenerate" option here.
+        -   **Interaction Flow:** Wait for the user's response, then proceed to the next step.
+
+5.  **Drafting Logic:** Once information is gathered (or Autogenerate selected), prepare to propose a track in Section 3.2.
+    -   **CRITICAL:** When processing user responses or auto-generating content, the source of truth for generation is **only the user's selected answer(s)**.
+6.  **Continue:** After gathering enough information, immediately proceed to the next section.
 
 ### 3.2 Propose a Single Initial Track (Automated + Approval)
 1.  **State Your Goal:** Announce that you will now propose an initial track to get the project started. Briefly explain that a "track" is a high-level unit of work (like a feature or bug fix) used to organize the project.
-2.  **Generate Track Title:** Analyze the project context (`product.md`, `tech-stack.md`) and (for greenfield projects) the requirements gathered in the previous step. Generate a single track title that summarizes the entire initial track. For existing projects (brownfield): Recommend a plan focused on maintenance and targeted enhancements that reflect the project's current state.
-    - Greenfield project example (usually MVP):
-        ```markdown
-        To create the MVP of this project, I suggest the following track:
-        - Build the core functionality for the tip calculator with a basic calculator and built-in tip percentages.
-        ```
-    - Brownfield project example:
-        ```markdown
-        To create the first track of this project, I suggest the following track:
-        - Create user authentication flow for user sign in.
-        ```
-3.  **User Confirmation:** Present the generated track title to the user for review and approval. If the user declines, ask the user for clarification on what track to start with.
+2.  **Generate Track Title:** Analyze the project context (`product.md`, `tech-stack.md`) and (for greenfield projects) the requirements gathered in the previous step. Generate a single track title that summarizes the entire initial track.
+    - **Greenfield:** Focus on the MVP core (e.g., "Build core tip calculator functionality").
+    - **Brownfield:** Focus on maintenance or targeted enhancements (e.g., "Implement user authentication flow").
+3.  **Confirm Proposal:** Use the `ask_user` tool to validate and/or refine the proposal in a single step:
+    - **questions:**
+        - **header:** "Confirm Track"
+        - **type:** "text"
+        - **question:** "To get the project started, I suggest the following track: '<Track Title>'. If you approve, please type 'ok' (or leave blank). Otherwise, type your preferred track description."
+        - **placeholder:** "e.g., Setup CI/CD pipeline"
+4.  **Action:** Use the user's response as the source of truth. If the user types 'ok' or leaves it blank, use the suggested '<Track Title>'. If they provide a new description, use that instead. Proceed to **Section 3.3**.
 
 ### 3.3 Convert the Initial Track into Artifacts (Automated)
 1.  **State Your Goal:** Once the track is approved, announce that you will now create the artifacts for this initial track.
@@ -443,11 +487,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
             - [Implementation Plan](./plan.md)
             - [Metadata](./metadata.json)
             ```
+            *(If you arrived here directly from the Audit because you are patching a missing index, write this file using the existing folder's track_id and then proceed to step d.)*
 
-    d. **Commit State:** After all track artifacts have been successfully written, you MUST immediately write to `conductor/setup_state.json` with the exact content:
-       `{"last_successful_step": "3.3_initial_track_generated"}`
-
-    e. **Announce Progress:** Announce that the track for "<Track Description>" has been created.
+    d. **Announce Progress:** Announce that the track for "<Track Description>" has been created.
 
 ### 3.4 Final Announcement
 1.  **Announce Completion:** After the track has been created, announce that the project setup and initial track generation are complete.