conductor-4-all 0.0.10 → 0.0.12

package/dist/index.cjs

@@ -583,5 +583,20 @@ var cli = (0, import_yargs.default)((0, import_helpers.hideBin)(process.argv)).s
   installHandler
 ).help();
 
+// src/utils/banner.ts
+var import_gradient_string = __toESM(require("gradient-string"), 1);
+var CONDUCTOR_BANNER = `
+   __________  _   ______  __  __________________  ____     __ __     ___    __    __ 
+  / ____/ __ \\/ | / / __ \\/ / / / ____/_  __/ __ \\/ __ \\   / // /    /   |  / /   / / 
+ / /   / / / /  |/ / / / / / / / /     / / / / / / /_/ /  / // /_   / /| | / /   / /  
+/ /___/ /_/ / /|  / /_/ / /_/ / /___  / / / /_/ / _, _/  /__  __/  / ___ |/ /___/ /___
+\\____/\\____/_/ |_/_____/\\____/\\____/ /_/  \\____/_/ |_|     /_/    /_/  |_/_____/_____/
+                                                                                      
+`;
+function printBanner() {
+  console.log((0, import_gradient_string.default)("green", "blue")(CONDUCTOR_BANNER));
+}
+
 // src/index.ts
+printBanner();
 cli.parse();

package/dist/index.js

@@ -556,5 +556,20 @@ var cli = yargs(hideBin(process.argv)).scriptName("conductor").usage("$0 <cmd> [
   installHandler
 ).help();
 
+// src/utils/banner.ts
+import gradient from "gradient-string";
+var CONDUCTOR_BANNER = `
+   __________  _   ______  __  __________________  ____     __ __     ___    __    __ 
+  / ____/ __ \\/ | / / __ \\/ / / / ____/_  __/ __ \\/ __ \\   / // /    /   |  / /   / / 
+ / /   / / / /  |/ / / / / / / / /     / / / / / / /_/ /  / // /_   / /| | / /   / /  
+/ /___/ /_/ / /|  / /_/ / /_/ / /___  / / / /_/ / _, _/  /__  __/  / ___ |/ /___/ /___
+\\____/\\____/_/ |_/_____/\\____/\\____/ /_/  \\____/_/ |_|     /_/    /_/  |_/_____/_____/
+                                                                                      
+`;
+function printBanner() {
+  console.log(gradient("green", "blue")(CONDUCTOR_BANNER));
+}
+
 // src/index.ts
+printBanner();
 cli.parse();

package/dist/templates/commands/implement.toml

@@ -10,15 +10,13 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 ## 1.1 SETUP CHECK
 **PROTOCOL: Verify that the Conductor environment is properly set up.**
 
-1.  **Check for Required Files:** You MUST verify the existence of the following files in the `conductor` directory:
-    -   `conductor/tech-stack.md`
-    -   `conductor/workflow.md`
-    -   `conductor/product.md`
+1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:
+    -   **Product Definition**
+    -   **Tech Stack**
+    -   **Workflow**
+
+2.  **Handle Failure:** If ANY of these are missing (or their resolved paths do not exist), Announce: "Conductor is not set up. Please run `/conductor:setup`." and HALT.
 
-2.  **Handle Missing Files:**
-    -   If ANY of these files are missing, you MUST halt the operation immediately.
-    -   Announce: "Conductor is not set up. Please run `/conductor:setup` to set up the environment."
-    -   Do NOT proceed to Track Selection.
 
 ---
 
@@ -27,7 +25,9 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 1.  **Check for User Input:** First, check if the user provided a track name as an argument (e.g., `/conductor:implement <track_description>`).
 
-2.  **Parse Tracks File:** Read and parse the tracks file at `conductor/tracks.md`. You must parse the file by splitting its content by the `---` separator to identify each track section. For each section, extract the status (`[ ]`, `[~]`, `[x]`), the track description (from the `##` heading), and the link to the track folder.
+2.  **Locate and Parse Tracks Registry:**
+    -   Resolve the **Tracks Registry**.
+    -   Read and parse this file. You must parse the file by splitting its content by the `---` separator to identify each track section. For each section, extract the status (`[ ]`, `[~]`, `[x]`), the track description (from the `##` heading), and the link to the track folder.
     -   **CRITICAL:** If no track sections are found after parsing, announce: "The tracks file is empty or malformed. No tracks to implement." and halt.
 
 3.  **Continue:** Immediately proceed to the next step to select a track.
@@ -56,27 +56,26 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 1.  **Announce Action:** Announce which track you are beginning to implement.
 
 2.  **Update Status to 'In Progress':**
-    -   Before beginning any work, you MUST update the status of the selected track in the `conductor/tracks.md` file.
-    -   This requires finding the specific heading for the track (e.g., `## [ ] Track: <Description>`) and replacing it with the updated status (e.g., `## [~] Track: <Description>`).
+    -   Before beginning any work, you MUST update the status of the selected track in the **Tracks Registry** file.
+    -   This requires finding the specific heading for the track (e.g., `## [ ] Track: <Description>`) and replacing it with the updated status (e.g., `## [~] Track: <Description>`) in the **Tracks Registry** file you identified earlier.
 
 3.  **Load Track Context:**
     a. **Identify Track Folder:** From the tracks file, identify the track's folder link to get the `<track_id>`.
-    b. **Read Files:** You MUST read the content of the following files into your context using their full, absolute paths:
-        - `conductor/tracks/<track_id>/plan.md`
-        - `conductor/tracks/<track_id>/spec.md`
-        - `conductor/workflow.md`
+    b. **Read Files:**
+        -   **Track Context:** Using the **Universal File Resolution Protocol**, resolve and read the **Specification** and **Implementation Plan** for the selected track.
+        -   **Workflow:** Resolve **Workflow** (via the **Universal File Resolution Protocol** using the project's index file).
     c. **Error Handling:** If you fail to read any of these files, you MUST stop and inform the user of the error.
 
 4.  **Execute Tasks and Update Track Plan:**
-    a. **Announce:** State that you will now execute the tasks from the track's `plan.md` by following the procedures in `workflow.md`.
-    b. **Iterate Through Tasks:** You MUST now loop through each task in the track's `plan.md` one by one.
+    a. **Announce:** State that you will now execute the tasks from the track's **Implementation Plan** by following the procedures in the **Workflow**.
+    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.md` 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.md` file you have in your context. Follow its steps for implementation, testing, and committing precisely.
+        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.
 
 5.  **Finalize Track:**
-    -   After all tasks in the track's local `plan.md` are completed, you MUST update the track's status in the tracks file.
+    -   After all tasks in the track's local **Implementation Plan** are completed, you MUST update the track's status in the **Tracks Registry**.
     -   This requires finding the specific heading for the track (e.g., `## [~] Track: <Description>`) and replacing it with the completed status (e.g., `## [x] Track: <Description>`).
-    -   **Commit Changes:** Stage `conductor/tracks.md` and commit with the message `chore(conductor): Mark track '<track_description>' as complete`.
+    -   **Commit Changes:** Stage the **Tracks Registry** file and commit with the message `chore(conductor): Mark track '<track_description>' as complete`.
     -   Announce that the track is fully complete and the tracks file has been updated.
 
 ---
@@ -88,56 +87,57 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 2.  **Announce Synchronization:** Announce that you are now synchronizing the project-level documentation with the completed track's specifications.
 
-3.  **Load Track Specification:** You MUST read the content of the completed track's `conductor/tracks/<track_id>/spec.md` file into your context.
+3.  **Load Track Specification:** Read the track's **Specification**.
 
-4.  **Load Project Documents:** You MUST read the contents of the following project-level documents into your context:
-    -   `conductor/product.md`
-    -   `conductor/product-guidelines.md`
-    -   `conductor/tech-stack.md`
+4.  **Load Project Documents:**
+    -   Resolve and read:
+        -   **Product Definition**
+        -   **Tech Stack**
+        -   **Product Guidelines**
 
 5.  **Analyze and Update:**
-    a.  **Analyze `spec.md`:** Carefully analyze the `spec.md` to identify any new features, changes in functionality, or updates to the technology stack.
-    b.  **Update `conductor/product.md`:**
+    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 `product.md`:"
+            > "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)"
-        iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the `conductor/product.md` file. Keep a record of whether this file was changed.
-    c.  **Update `conductor/tech-stack.md`:**
+        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 `tech-stack.md`:"
+            > "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)"
-        iii. **Action:** Only after receiving explicit user confirmation, perform the file edits to update the `conductor/tech-stack.md` file. Keep a record of whether this file was changed.
-    d. **Update `conductor/product-guidelines.md` (Strictly Controlled):**
+        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 `spec.md` explicitly describes a change that directly impacts branding, voice, tone, or other core product guidelines.
+        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:"
+            > "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 `product-guidelines.md`? (yes/no)"
+            > "Do you approve these critical changes to the **Product Guidelines**? (yes/no)"
         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.
     - **Construct the Message:** Based on the records of which files were changed, construct a summary message.
     - **Commit Changes:**
-        - If any files were changed (`product.md`, `tech-stack.md`, or `product-guidelines.md`), you MUST stage them and commit them.
+        - If any files were changed (**Product Definition**, **Tech Stack**, or **Product Guidelines**), you MUST stage them and commit them.
         - **Commit Message:** `docs(conductor): Synchronize docs for track '<track_description>'`
-    - **Example (if product.md was changed, but others were not):**
+    - **Example (if Product Definition was changed, but others were not):**
         > "Documentation synchronization is complete.
-        > - **Changes made to `product.md`:** The user-facing description of the product was updated to include the new feature.
-        > - **No changes needed for `tech-stack.md`:** The technology stack was not affected.
-        > - **No changes needed for `product-guidelines.md`:** Core product guidelines remain unchanged."
+        > - **Changes made to Product Definition:** The user-facing description of the product was updated to include the new feature.
+        > - **No changes needed for Tech Stack:** The technology stack was not affected.
+        > - **No changes needed for Product Guidelines:** Core product guidelines remain unchanged."
     - **Example (if no files were changed):**
-        > "Documentation synchronization is complete. No updates were necessary for `product.md`, `tech-stack.md`, or `product-guidelines.md` based on the completed track."
+        > "Documentation synchronization is complete. No updates were necessary for project documents based on the completed track."
 
 ---
 
@@ -156,18 +156,18 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 3.  **Handle User Response:**
     *   **If user chooses "A" (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 `conductor/tracks/<track_id>` to `conductor/archive/<track_id>`.
-        iii. **Remove from Tracks File:** Read the content of `conductor/tracks.md`, 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 `conductor/tracks.md` and `conductor/archive/`. Commit with the message `chore(conductor): Archive track '<track_description>'`.
+        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 "B" (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)"
         ii. **Handle Confirmation:**
             - **If 'yes'**:
-                a. **Delete Track Folder:** Permanently delete the track's folder from `conductor/tracks/<track_id>`.
-                b. **Remove from Tracks File:** Read the content of `conductor/tracks.md`, remove the entire section for the completed track, and write the modified content back to the file.
-                c. **Commit Changes:** Stage `conductor/tracks.md` and the deletion of `conductor/tracks/<track_id>`. Commit with the message `chore(conductor): Delete track '<track_description>'`.
+                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)**:
                 a. **Announce Cancellation:** Announce: "Deletion cancelled. The track has not been changed."

package/dist/templates/commands/newTrack.toml

@@ -5,15 +5,17 @@ You are an AI agent assistant for the Conductor spec-driven development framewor
 
 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.
 
+---
+
 ## 1.1 SETUP CHECK
 **PROTOCOL: Verify that the Conductor environment is properly set up.**
 
-1.  **Check for Required Files:** You MUST verify the existence of the following files in the `conductor` directory:
-    -   `conductor/tech-stack.md`
-    -   `conductor/workflow.md`
-    -   `conductor/product.md`
+1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:
+    -   **Product Definition**
+    -   **Tech Stack**
+    -   **Workflow**
 
-2.  **Handle Missing Files:**
+2.  **Handle Failure:**
     -   If ANY of these files are missing, you MUST halt the operation immediately.
     -   Announce: "Conductor is not set up. Please run `/conductor:setup` to set up the environment."
     -   Do NOT proceed to New Track Initialization.
@@ -25,7 +27,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 ### 2.1 Get Track Description and Determine Type
 
-1.  **Load Project Context:** Read and understand the content of the `conductor` directory files.
+1.  **Load Project Context:** Read and understand the content of the project documents (**Product Definition**, **Tech Stack**, etc.) resolved via the **Universal File Resolution Protocol**.
 2.  **Get Track Description:**
     *   **If `{{args}}` contains a description:** Use the content of `{{args}}`.
     *   **If `{{args}}` is empty:** Ask the user:
@@ -41,7 +43,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 2.  **Questioning Phase:** Ask a series of questions to gather details for the `spec.md`. Tailor questions based on the track type (Feature or Other).
     *   **CRITICAL:** You MUST ask these questions sequentially (one by one). Do not ask multiple questions in a single turn. Wait for the user's response after each question.
     *   **General Guidelines:**
-        *   Refer to information in `product.md`, `tech-stack.md`, etc., to ask context-aware questions.
+        *   Refer to information in **Product Definition**, **Tech Stack**, etc., to ask context-aware questions.
         *   Provide a brief explanation and clear examples for each question.
         *   **Strongly Recommendation:** Whenever possible, present 2-3 plausible options (A, B, C) for the user to choose from.
         *   **Mandatory:** The last option for every multiple-choice question MUST be "Type your own answer".
@@ -89,13 +91,13 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 2.  **Generate Plan:**
     *   Read the confirmed `spec.md` content for this track.
-    *   Read the selected workflow file from `conductor/workflow.md`.
+    *   Resolve and read the **Workflow** file (via the **Universal File Resolution Protocol** using the project's index file).
     *   Generate a `plan.md` with a hierarchical list of Phases, Tasks, and Sub-tasks.
-    *   **CRITICAL:** The plan structure MUST adhere to the methodology in the workflow file (e.g., TDD tasks for "Write Tests" and "Implement").
+    *   **CRITICAL:** The plan structure MUST adhere to the methodology in the **Workflow** file (e.g., TDD tasks for "Write Tests" and "Implement").
     *   Include status markers `[ ]` for **EVERY** task and sub-task. The format must be:
         - Parent Task: `- [ ] Task: ...`
         - Sub-task: `    - [ ] ...`
-    *   **CRITICAL: Inject Phase Completion Tasks.** Determine if a "Phase Completion Verification and Checkpointing Protocol" is defined in `conductor/workflow.md`. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`.
+    *   **CRITICAL: Inject Phase Completion Tasks.** Determine if a "Phase Completion Verification and Checkpointing Protocol" is defined in the **Workflow**. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`.
 
 3.  **User Confirmation:** Present the drafted `plan.md` to the user for review and approval.
     > "I've drafted the implementation plan. Please review the following:"
@@ -109,10 +111,10 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 ### 2.4 Create Track Artifacts and Update Main Plan
 
-1.  **Check for existing track name:** Before generating a new Track ID, list all existing track directories in `conductor/tracks/`. Extract the short names from these track IDs (e.g., ``shortname_YYYYMMDD`` -> `shortname`). If the proposed short name for the new track (derived from the initial description) matches an existing short name, halt the `newTrack` creation. Explain that a track with that name already exists and suggest choosing a different name or resuming the existing track.
+1.  **Check for existing track name:** Before generating a new Track ID, resolve the **Tracks Directory** using the **Universal File Resolution Protocol**. List all existing track directories in that resolved path. Extract the short names from these track IDs (e.g., ``shortname_YYYYMMDD`` -> `shortname`). If the proposed short name for the new track (derived from the initial description) matches an existing short name, halt the `newTrack` creation. Explain that a track with that name already exists and suggest choosing a different name or resuming the existing track.
 2.  **Generate Track ID:** Create a unique Track ID (e.g., ``shortname_YYYYMMDD``).
-3.  **Create Directory:** Create a new directory: `conductor/tracks/<track_id>/`
-4.  **Create `metadata.json`:** Create a metadata file at `conductor/tracks/<track_id>/metadata.json` with content like:
+3.  **Create Directory:** Create a new directory for the tracks: `<Tracks Directory>/<track_id>/`.
+4.  **Create `metadata.json`:** Create a metadata file at `<Tracks Directory>/<track_id>/metadata.json` with content like:
     ```json
     {
       "track_id": "<track_id>",
@@ -125,16 +127,27 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     ```
     *   Populate fields with actual values. Use the current timestamp.
 5.  **Write Files:**
-    *   Write the confirmed specification content to `conductor/tracks/<track_id>/spec.md`.
-    *   Write the confirmed plan content to `conductor/tracks/<track_id>/plan.md`.
-6.  **Update Tracks File:**
-    -   **Announce:** Inform the user you are updating the tracks file.
-    -   **Append Section:** Append a new item to the track list in `conductor/tracks.md`. The format MUST be:
+    *   Write the confirmed specification content to `<Tracks Directory>/<track_id>/spec.md`.
+    *   Write the confirmed plan content to `<Tracks Directory>/<track_id>/plan.md`.
+    *   Write the index file to `<Tracks Directory>/<track_id>/index.md` with content:
         ```markdown
+        # Track <track_id> Context
+
+        - [Specification](./spec.md)
+        - [Implementation Plan](./plan.md)
+        - [Metadata](./metadata.json)
+        ```
+6.  **Update Tracks Registry:**
+    -   **Announce:** Inform the user you are updating the **Tracks Registry**.
+    -   **Append Section:** Resolve the **Tracks Registry** via the **Universal File Resolution Protocol**. Append a new section for the track to the end of this file. The format MUST be:
+        ```markdown
+
+        ---
+
         - [ ] **Track: <Track Description>**
-          *Link: [./conductor/tracks/<track_id>/](./conductor/tracks/<track_id>/)*
+        *Link: [./<Relative Track Path>/](./<Relative Track Path>/)*
         ```
-        (Replace placeholders with actual values)
+        (Replace `<Relative Track Path>` with the path to the track directory relative to the **Tracks Registry** file location.)
 7.  **Announce Completion:** Inform the user:
     > "New track '<track_id>' has been created and added to the tracks file. You can now start implementation by running `/conductor:implement`."
 

package/dist/templates/commands/revert.toml

@@ -9,11 +9,18 @@ Your workflow MUST anticipate and handle common non-linear Git histories, such a
 
 **CRITICAL**: The user's explicit confirmation is required at multiple checkpoints. If a user denies a confirmation, the process MUST halt immediately and follow further instructions. 
 
-**CRITICAL:** Before proceeding, you should start by checking if the project has been properly set up.
-1.  **Verify Tracks File:** Check if the file `conductor/tracks.md` exists. If it does not, HALT execution and instruct the user: "The project has not been set up or conductor/tracks.md has been corrupted. Please run `/conductor:setup` to set up the plan, or restore conductor/tracks.md."
-2.  **Verify Track Exists:** Check if the file `conductor/tracks.md` is not empty. If it is empty, HALT execution and instruct the user: "The project has not been set up or conductor/tracks.md has been corrupted. Please run `/conductor:setup` to set up the plan, or restore conductor/tracks.md." 
+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**: 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.
+---
+
+## 1.1 SETUP CHECK
+**PROTOCOL: Verify that the Conductor environment is properly set up.**
+
+1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of the **Tracks Registry**.
+
+2.  **Verify Track Exists:** Check if the **Tracks Registry** is not empty.
+
+3.  **Handle Failure:** If the file is missing or empty, HALT execution and instruct the user: "The project has not been set up or the tracks file has been corrupted. Please run `/conductor:setup` to set up the plan, or restore the tracks file."
 
 ---
 
@@ -29,7 +36,7 @@ Your workflow MUST anticipate and handle common non-linear Git histories, such a
 3.  **Interaction Paths:**
 
     *   **PATH A: Direct Confirmation**
-        1.  Find the specific track, phase, or task the user referenced in the project's `tracks.md` or `plan.md` files.
+        1.  Find the specific track, phase, or task the user referenced in the **Tracks Registry** or **Implementation Plan** files (resolved via **Universal File Resolution Protocol**).
         2.  Ask the user for confirmation: "You asked to revert the [Track/Phase/Task]: '[Description]'. Is this correct?".
             - **Structure:**
                 A) Yes
@@ -38,7 +45,7 @@ Your workflow MUST anticipate and handle common non-linear Git histories, such a
 
     *   **PATH B: Guided Selection Menu**
         1.  **Identify Revert Candidates:** Your primary goal is to find relevant items for the user to revert.
-            *   **Scan All Plans:** You MUST read the main `conductor/tracks.md` and every `conductor/tracks/*/plan.md` file.
+            *   **Scan All Plans:** You MUST read the **Tracks Registry** and every track's **Implementation Plan** (resolved via **Universal File Resolution Protocol** using the track's index file).
             *   **Prioritize In-Progress:** First, find **all** Tracks, Phases, and Tasks marked as "in-progress" (`[~]`).
             *   **Fallback to Completed:** If and only if NO in-progress items are found, find the **5 most recently completed** Tasks and Phases (`[x]`).
         2.  **Present a Unified Hierarchical Menu:** You MUST present the results to the user in a clear, numbered, hierarchical list grouped by Track. The introductory text MUST change based on the context.
@@ -76,15 +83,15 @@ Your workflow MUST anticipate and handle common non-linear Git histories, such a
 **GOAL: Find ALL actual commit(s) in the Git history that correspond to the user's confirmed intent and analyze them.**
 
 1.  **Identify Implementation Commits:**
-    *   Find the primary SHA(s) for all tasks and phases recorded in the target's `plan.md`.
+    *   Find the primary SHA(s) for all tasks and phases recorded in the target's **Implementation Plan**.
     *   **Handle "Ghost" Commits (Rewritten History):** If a SHA from a plan is not found in Git, announce this. Search the Git log for a commit with a highly similar message and ask the user to confirm it as the replacement. If not confirmed, halt.
 
 2.  **Identify Associated Plan-Update Commits:**
-    *   For each validated implementation commit, use `git log` to find the corresponding plan-update commit that happened *after* it and modified the relevant `plan.md` file.
+    *   For each validated implementation commit, use `git log` to find the corresponding plan-update commit that happened *after* it and modified the relevant **Implementation Plan** file.
 
 3.  **Identify the Track Creation Commit (Track Revert Only):**
     *   **IF** the user's intent is to revert an entire track, you MUST perform this additional step.
-    *   **Method:** Use `git log -- conductor/tracks.md` and search for the commit that first introduced the track entry.
+    *   **Method:** Use `git log -- <path_to_tracks_registry>` (resolved via protocol) and search for the commit that first introduced the track entry.
         *   Look for lines matching either `- [ ] **Track: <Track Description>**` (new format) OR `## [ ] Track: <Track Description>` (legacy format).
     *   Add this "track creation" commit's SHA to the list of commits to be reverted.
 
@@ -118,7 +125,6 @@ Your workflow MUST anticipate and handle common non-linear Git histories, such a
 
 1.  **Execute Reverts:** Run `git revert --no-edit <sha>` for each commit in your final list, starting from the most recent and working backward.
 2.  **Handle Conflicts:** If any revert command fails due to a merge conflict, halt and provide the user with clear instructions for manual resolution.
-3.  **Verify Plan State:** After all reverts succeed, read the relevant `plan.md` file(s) again to ensure the reverted item has been correctly reset. If not, perform a file edit to fix it and commit the correction.
+3.  **Verify Plan State:** After all reverts succeed, read the relevant **Implementation Plan** file(s) again to ensure the reverted item has been correctly reset. If not, perform a file edit to fix it and commit the correction.
 4.  **Announce Completion:** Inform the user that the process is complete and the plan is synchronized.
-"""
-
+"""

package/dist/templates/commands/setup.toml

@@ -320,10 +320,30 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
             `{"last_successful_step": "2.5_workflow"}`
 
 ### 2.6 Finalization
-1.  **Summarize Actions:** Present a summary of all actions taken during Phase 1, including:
+1.  **Generate Index File:**
+    -   Create `conductor/index.md` with the following content:
+        ```markdown
+        # Project Context
+
+        ## Definition
+        - [Product Definition](./product.md)
+        - [Product Guidelines](./product-guidelines.md)
+        - [Tech Stack](./tech-stack.md)
+
+        ## Workflow
+        - [Workflow](./workflow.md)
+        - [Code Style Guides](./code_styleguides/)
+
+        ## Management
+        - [Tracks Registry](./tracks.md)
+        - [Tracks Directory](./tracks/)
+        ```
+    -   **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:
     -   The guide files that were copied.
     -   The workflow file that was copied.
-2.  **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.
+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.
 
 ---
 
@@ -386,8 +406,9 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
     ---
 
     - [ ] **Track: <Track Description>**
-      *Link: [./conductor/tracks/<track_id>/](./conductor/tracks/<track_id>/)*
+      *Link: [./<Tracks Directory Name>/<track_id>/](./<Tracks Directory Name>/<track_id>/)*
     ```
+    (Replace `<Tracks Directory Name>` with the actual name of the tracks folder resolved via the protocol.)
 3.  **Generate Track Artifacts:**
     a. **Define Track:** The approved title is the track description.
     b. **Generate Track-Specific Spec & Plan:**
@@ -400,7 +421,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
             - **CRITICAL: Inject Phase Completion Tasks.** You MUST read the `conductor/workflow.md` file to determine if a "Phase Completion Verification and Checkpointing Protocol" is defined. If this protocol exists, then for each **Phase** that you generate in `plan.md`, you MUST append a final meta-task to that phase. The format for this meta-task is: `- [ ] Task: Conductor - User Manual Verification '<Phase Name>' (Protocol in workflow.md)`. You MUST replace `<Phase Name>` with the actual name of the phase.
     c. **Create Track Artifacts:**
         i. **Generate and Store Track ID:** Create a unique Track ID from the track description using format `shortname_YYYYMMDD` and store it. You MUST use this exact same ID for all subsequent steps for this track.
-        ii. **Create Single Directory:** Using the stored Track ID, create a single new directory: `conductor/tracks/<track_id>/`.
+        ii. **Create Single Directory:** Resolve the **Tracks Directory** via the **Universal File Resolution Protocol** and create a single new directory: `<Tracks Directory>/<track_id>/`.
         iii. **Create `metadata.json`:** In the new directory, create a `metadata.json` file with the correct structure and content, using the stored Track ID. An example is:
             - ```json
             {
@@ -414,6 +435,14 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re
             ```
         Populate fields with actual values. Use the current timestamp.
         iv. **Write Spec and Plan Files:** In the exact same directory, write the generated `spec.md` and `plan.md` files.
+        v.  **Write Index File:** In the exact same directory, write `index.md` with content:
+            ```markdown
+            # Track <track_id> Context
+
+            - [Specification](./spec.md)
+            - [Implementation Plan](./plan.md)
+            - [Metadata](./metadata.json)
+            ```
 
     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"}`

package/dist/templates/commands/status.toml

@@ -1,11 +1,7 @@
 description = "Displays the current progress of the project"
 prompt = """
 ## 1.0 SYSTEM DIRECTIVE
-You are an AI agent. Your primary function is to provide a status overview of the current tracks file. This involves reading the `conductor/tracks.md` file, parsing its content, and summarizing the progress of tasks.
-
-**CRITICAL:** Before proceeding, you should start by checking if the project has been properly set up.
-1.  **Verify Tracks File:** Check if the file `conductor/tracks.md` exists. If it does not, HALT execution and instruct the user: "The project has not been set up or conductor/tracks.md has been corrupted. Please run `/conductor:setup` to set up the plan, or restore conductor/tracks.md."
-2.  **Verify Track Exists:** Check if the file `conductor/tracks.md` is not empty. If it is empty, HALT execution and instruct the user: "The project has not been set up or conductor/tracks.md has been corrupted. Please run `/conductor:setup` to set up the plan, or restore conductor/tracks.md."
+You are an AI agent. Your primary function is to provide a status overview of the current tracks file. This involves reading the **Tracks Registry** file, parsing its content, and summarizing the progress of tasks.
 
 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.
 
@@ -15,12 +11,13 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 ## 1.1 SETUP CHECK
 **PROTOCOL: Verify that the Conductor environment is properly set up.**
 
-1.  **Check for Required Files:** You MUST verify the existence of the following files in the `conductor` directory:
-    -   `conductor/tech-stack.md`
-    -   `conductor/workflow.md`
-    -   `conductor/product.md`
+1.  **Verify Core Context:** Using the **Universal File Resolution Protocol**, resolve and verify the existence of:
+    -   **Tracks Registry**
+    -   **Product Definition**
+    -   **Tech Stack**
+    -   **Workflow**
 
-2.  **Handle Missing Files:**
+2.  **Handle Failure:**
     -   If ANY of these files are missing, you MUST halt the operation immediately.
     -   Announce: "Conductor is not set up. Please run `/conductor:setup` to set up the environment."
     -   Do NOT proceed to Status Overview Protocol.
@@ -31,9 +28,11 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 **PROTOCOL: Follow this sequence to provide a status overview.**
 
 ### 2.1 Read Project Plan
-1.  **Locate and Read:** Read the content of the `conductor/tracks.md` file.
-2.  **Locate and Read:** List the tracks using shell command `ls conductor/tracks`. For each of the tracks, read the corresponding `conductor/tracks/<track_id>/plan.md` file.
-    *   **Parsing Logic:** When reading `conductor/tracks.md` to identify tracks, look for lines matching either the new standard format `- [ ] **Track:` or the legacy format `## [ ] Track:`.
+1.  **Locate and Read:** Read the content of the **Tracks Registry** (resolved via **Universal File Resolution Protocol**).
+2.  **Locate and Read Tracks:**
+    -   Parse the **Tracks Registry** to identify all registered tracks and their paths.
+        *   **Parsing Logic:** When reading the **Tracks Registry** to identify tracks, look for lines matching either the new standard format `- [ ] **Track:` or the legacy format `## [ ] Track:`.
+    -   For each track, resolve and read its **Implementation Plan** (using **Universal File Resolution Protocol** via the track's index file).
 
 ### 2.2 Parse and Summarize Plan
 1.  **Parse Content:**

package/dist/templates/templates/code_styleguides/go.md

@@ -45,4 +45,4 @@ This document summarizes key rules and best practices from the official "Effecti
 - **Explicit Error Handling:** Do not discard errors with the blank identifier (`_`). Check for errors explicitly.
 - **`panic`:** Reserved for truly exceptional, unrecoverable situations. Generally, libraries should not panic.
 
-*Source: [Effective Go](https://go.dev/doc/effective_go)*
+*Source: [Effective Go](https://go.dev/doc/effective_go)*

package/dist/templates/templates/code_styleguides/html-css.md

@@ -46,4 +46,4 @@ This document summarizes key rules and best practices from the Google HTML/CSS S
 
 **BE CONSISTENT.** When editing code, match the existing style.
 
-*Source: [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)*
+*Source: [Google HTML/CSS Style Guide](https://google.github.io/styleguide/htmlcssguide.html)*

package/dist/templates/templates/code_styleguides/javascript.md

@@ -48,4 +48,4 @@ This document summarizes key rules and best practices from the Google JavaScript
 - Use `@param`, `@return`, `@override`, `@deprecated`.
 - Type annotations are enclosed in braces (e.g., `/** @param {string} userName */`).
 
-*Source: [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)*
+*Source: [Google JavaScript Style Guide](https://google.github.io/styleguide/jsguide.html)*

package/dist/templates/templates/code_styleguides/python.md

@@ -34,4 +34,4 @@ This document summarizes key rules and best practices from the Google Python Sty
 
 **BE CONSISTENT.** When editing code, match the existing style.
 
-*Source: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html)*
+*Source: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html)*

package/dist/templates/templates/code_styleguides/typescript.md

@@ -40,4 +40,4 @@ This document summarizes key rules and best practices from the Google TypeScript
 - **Redundancy:** **Do not declare types in `@param` or `@return` blocks** (e.g., `/** @param {string} user */`). This is redundant in TypeScript.
 - **Add Information:** Comments must add information, not just restate the code.
 
-*Source: [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html)*
+*Source: [Google TypeScript Style Guide](https://google.github.io/styleguide/tsguide.html)*

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "conductor-4-all",
-  "version": "0.0.10",
+  "version": "0.0.12",
   "description": "Conductor spec-driven development CLI - TypeScript/Node.js version",
   "license": "Apache-2.0",
   "repository": {
@@ -31,6 +31,7 @@
   },
   "devDependencies": {
     "@types/fs-extra": "^11.0.4",
+    "@types/gradient-string": "^1.1.6",
     "@types/node": "^25.0.3",
     "@types/yargs": "^17.0.35",
     "@vitest/coverage-v8": "^2.1.8",
@@ -41,6 +42,7 @@
   "dependencies": {
     "@inquirer/select": "^5.0.3",
     "fs-extra": "^11.3.3",
+    "gradient-string": "^3.0.0",
     "smol-toml": "^1.6.0",
     "yargs": "^18.0.0"
   }