Refactor interactive flows to use the AskUser tool

commands/conductor/implement.toml

@@ -35,13 +35,29 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 4.  **Select Track:**
     -   **If a track name was provided:**
         1.  Perform an exact, case-insensitive match for the provided name against the track descriptions you parsed.
-        2.  If a unique match is found, confirm the selection with the user: "I found track '<track_description>'. Is this correct?"
-        3.  If no match is found, or if the match is ambiguous, inform the user and ask for clarification. Suggest the next available track as below.
+        2.  If a unique match is found, immediately call the `ask_user` tool to confirm the selection (do not repeat the question in the chat):
+            - **questions:**
+                - **header:** "Confirm"
+                - **question:** "I found track '<track_description>'. Is this correct?"
+                - **type:** "yesno"
+        3.  If no match is found, or if the match is ambiguous, immediately call the `ask_user` tool to inform the user and request the correct track name (do not repeat the question in the chat):
+            - **questions:**
+                - **header:** "Clarify"
+                - **question:** "I couldn't find a unique track matching the name you provided. Did you mean '<next_available_track>'? Or please type the exact track name."
+                - **type:** "text"
     -   **If no track name was provided (or if the previous step failed):**
         1.  **Identify Next Track:** Find the first track in the parsed tracks file that is NOT marked as `[x] Completed`.
         2.  **If a next track is found:**
-            -   Announce: "No track name provided. Automatically selecting the next incomplete track: '<track_description>'."
-            -   Proceed with this track.
+            -   Immediately call the `ask_user` tool to confirm the selection (do not repeat the question in the chat):
+                - **questions:**
+                    - **header:** "Next Track"
+                    - **question:** "No track name provided. Would you like to proceed with the next incomplete track: '<track_description>'?"
+                    - **type:** "yesno"
+            -   If confirmed, proceed with this track. Otherwise, immediately call the `ask_user` tool to request the correct track name (do not repeat the question in the chat):
+                - **questions:**
+                    - **header:** "Clarify"
+                    - **question:** "Please type the exact name of the track you would like to implement."
+                    - **type:** "text"
         3.  **If no incomplete tracks are found:**
             -   Announce: "No incomplete tracks found in the tracks file. All tasks are completed!"
             -   Halt the process and await further user instructions.
@@ -71,6 +87,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     b. **Iterate Through Tasks:** You MUST now loop through each task in the track's **Implementation Plan** one by one.
     c. **For Each Task, You MUST:**
         i. **Defer to Workflow:** The **Workflow** file is the **single source of truth** for the entire task lifecycle. You MUST now read and execute the procedures defined in the "Task Workflow" section of the **Workflow** file you have in your context. Follow its steps for implementation, testing, and committing precisely.
+           - **CRITICAL:** Every human-in-the-loop interaction, confirmation, or request for feedback mentioned in the **Workflow** (e.g., manual verification plans or guidance on persistent failures) MUST be conducted using the `ask_user` tool.
 
 5.  **Finalize Track:**
     -   After all tasks in the track's local **Implementation Plan** are completed, you MUST update the track's status in the **Tracks Registry**.
@@ -99,31 +116,34 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     a.  **Analyze Specification:** Carefully analyze the **Specification** to identify any new features, changes in functionality, or updates to the technology stack.
     b.  **Update Product Definition:**
         i. **Condition for Update:** Based on your analysis, you MUST determine if the completed feature or bug fix significantly impacts the description of the product itself.
-        ii. **Propose and Confirm Changes:** If an update is needed, generate the proposed changes. Then, present them to the user for confirmation:
-            > "Based on the completed track, I propose the following updates to the **Product Definition**:"
-            > ```diff
-            > [Proposed changes here, ideally in a diff format]
-            > ```
-            > "Do you approve these changes? (yes/no)"
+        ii. **Propose and Confirm Changes:** If an update is needed:
+            - **Present Content:** First, display the proposed updates to the **Product Definition** (ideally in a diff format) to the user in the chat.
+            - **Ask for Approval:** Then, use the `ask_user` tool to request confirmation:
+                - **questions:**
+                    - **header:** "Prod Definition"
+                    - **question:** "Do you approve these changes to the Product Definition?"
+                    - **type:** "yesno"
         iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the **Product Definition** file. Keep a record of whether this file was changed.
     c.  **Update Tech Stack:**
         i. **Condition for Update:** Similarly, you MUST determine if significant changes in the technology stack are detected as a result of the completed track.
-        ii. **Propose and Confirm Changes:** If an update is needed, generate the proposed changes. Then, present them to the user for confirmation:
-            > "Based on the completed track, I propose the following updates to the **Tech Stack**:"
-            > ```diff
-            > [Proposed changes here, ideally in a diff format]
-            > ```
-            > "Do you approve these changes? (yes/no)"
+        ii. **Propose and Confirm Changes:** If an update is needed:
+            - **Present Content:** First, display the proposed updates to the **Tech Stack** (ideally in a diff format) to the user in the chat.
+            - **Ask for Approval:** Then, use the `ask_user` tool to request confirmation:
+                - **questions:**
+                    - **header:** "Tech Stack"
+                    - **question:** "Do you approve these changes to the Tech Stack?"
+                    - **type:** "yesno"
         iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the **Tech Stack** file. Keep a record of whether this file was changed.
     d. **Update Product Guidelines (Strictly Controlled):**
         i. **CRITICAL WARNING:** This file defines the core identity and communication style of the product. It should be modified with extreme caution and ONLY in cases of significant strategic shifts, such as a product rebrand or a fundamental change in user engagement philosophy. Routine feature updates or bug fixes should NOT trigger changes to this file.
         ii. **Condition for Update:** You may ONLY propose an update to this file if the track's **Specification** explicitly describes a change that directly impacts branding, voice, tone, or other core product guidelines.
-        iii. **Propose and Confirm Changes:** If the conditions are met, you MUST generate the proposed changes and present them to the user with a clear warning:
-            > "WARNING: The completed track suggests a change to the core **Product Guidelines**. This is an unusual step. Please review carefully:"
-            > ```diff
-            > [Proposed changes here, ideally in a diff format]
-            > ```
-            > "Do you approve these critical changes to the **Product Guidelines**? (yes/no)"
+        iii. **Propose and Confirm Changes:** If the conditions are met:
+            - **Present Content:** First, display the proposed changes to the **Product Guidelines** (ideally in a diff format) to the user in the chat, including a clear warning.
+            - **Ask for Approval:** Then, use the `ask_user` tool to request confirmation:
+                - **questions:**
+                    - **header:** "Prod Guidelines"
+                    - **question:** "WARNING: This is an unusual step. Do you approve these critical changes to the Product Guidelines?"
+                    - **type:** "yesno"
         iv. **Action:** Only after receiving explicit user confirmation, perform the file edits. Keep a record of whether this file was changed.
 
 6.  **Final Report:** Announce the completion of the synchronization process and provide a summary of the actions taken.
@@ -146,34 +166,41 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 1.  **Execution Trigger:** This protocol MUST only be executed after the current track has been successfully implemented and the `SYNCHRONIZE PROJECT DOCUMENTATION` step is complete.
 
-2.  **Ask for User Choice:** You MUST prompt the user with the available options for the completed track.
-    > "Track '<track_description>' is now complete. What would you like to do?
-    > A.  **Review (Recommended):** Run the review command to verify changes before finalizing.
-    > B.  **Archive:** Move the track's folder to `conductor/archive/` and remove it from the tracks file.
-    > C.  **Delete:** Permanently delete the track's folder and remove it from the tracks file.
-    > D.  **Skip:** Do nothing and leave it in the tracks file.
-    > Please enter the option of your choice (A, B, C, or D)."
+2.  **Ask for User Choice:** Immediately call the `ask_user` tool to prompt the user (do not repeat the question in the chat):
+    - **questions:**
+        - **header:** "Track Cleanup"
+        - **question:** "Track '<track_description>' is now complete. What would you like to do?"
+        - **type:** "choice"
+        - **multiSelect:** false
+        - **options:**
+            - Label: "Review", Description: "Run the review command to verify changes before finalizing."
+            - Label: "Archive", Description: "Move the track's folder to `conductor/archive/` and remove it from the tracks file."
+            - Label: "Delete", Description: "Permanently delete the track's folder and remove it from the tracks file."
+            - Label: "Skip", Description: "Do nothing and leave it in the tracks file."
 
 3.  **Handle User Response:**
-    *   **If user chooses "A" (Review):**
+    *   **If user chooses "Review":**
         *   Announce: "Please run `/conductor:review` to verify your changes. You will be able to archive or delete the track after the review."
-    *   **If user chooses "B" (Archive):**
+    *   **If user chooses "Archive":**
         i.   **Create Archive Directory:** Check for the existence of `conductor/archive/`. If it does not exist, create it.
         ii.  **Archive Track Folder:** Move the track's folder from its current location (resolved via the **Tracks Directory**) to `conductor/archive/<track_id>`.
         iii. **Remove from Tracks File:** Read the content of the **Tracks Registry** file, remove the entire section for the completed track (the part that starts with `---` and contains the track description), and write the modified content back to the file.
         iv.  **Commit Changes:** Stage the **Tracks Registry** file and `conductor/archive/`. Commit with the message `chore(conductor): Archive track '<track_description>'`.
         v.   **Announce Success:** Announce: "Track '<track_description>' has been successfully archived."
-    *   **If user chooses "C" (Delete):**
-        i. **CRITICAL WARNING:** Before proceeding, you MUST ask for a final confirmation due to the irreversible nature of the action.
-            > "WARNING: This will permanently delete the track folder and all its contents. This action cannot be undone. Are you sure you want to proceed? (yes/no)"
+    *   **If user chooses "Delete":**
+        i. **CRITICAL WARNING:** Before proceeding, immediately call the `ask_user` tool to ask for final confirmation (do not repeat the warning in the chat):
+            - **questions:**
+                - **header:** "Confirm"
+                - **question:** "WARNING: This will permanently delete the track folder and all its contents. This action cannot be undone. Are you sure?"
+                - **type:** "yesno"
         ii. **Handle Confirmation:**
             - **If 'yes'**:
                 a. **Delete Track Folder:** Resolve the **Tracks Directory** and permanently delete the track's folder from `<Tracks Directory>/<track_id>`.
                 b. **Remove from Tracks File:** Read the content of the **Tracks Registry** file, remove the entire section for the completed track, and write the modified content back to the file.
                 c. **Commit Changes:** Stage the **Tracks Registry** file and the deletion of the track directory. Commit with the message `chore(conductor): Delete track '<track_description>'`.
                 d. **Announce Success:** Announce: "Track '<track_description>' has been permanently deleted."
-            - **If 'no' (or anything else)**:
+            - **If 'no'**:
                 a. **Announce Cancellation:** Announce: "Deletion cancelled. The track has not been changed."
-    *   **If user chooses "D" (Skip) or provides any other input:**
+    *   **If user chooses "Skip":**
         *   Announce: "Okay, the completed track will remain in your tracks file for now."
-"""
+"""