Decouple git from conductor and create git-workflow.md

commands/conductor/implement.toml

@@ -76,6 +76,10 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     -   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 the **Tracks Registry** file and commit with the message `chore(conductor): Mark track '<track_description>' as complete`.
+    -   **Store Metadata:**
+        -   **Get Commit Hash:** Obtain the hash of the commit by executing the `get_latest_commit_hash` command from `VCS_COMMANDS`.
+        -   **Draft Summary:** Create a summary for the commit.
+        -   **Store:** Execute the `store_commit_metadata` command from `VCS_COMMANDS`, passing the commit hash and the summary.
     -   Announce that the track is fully complete and the tracks file has been updated.
 
 ---
@@ -131,7 +135,11 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
     - **Commit Changes:**
         - 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 Definition was changed, but others were not):**
+    - **Store Metadata:**
+        -   **Get Commit Hash:** Obtain the hash of the commit by executing the `get_latest_commit_hash` command from `VCS_COMMANDS`.
+        -   **Draft Summary:** Create a summary for the commit.
+        -   **Store:** Execute the `store_commit_metadata` command from `VCS_COMMANDS`, passing the commit hash and the summary.
+    - **Example (if **Product Definition** was changed, but others were not):**
         > "Documentation synchronization is complete.
         > - **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.
@@ -159,7 +167,11 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
         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."
+        v.   **Store Metadata:**
+            -   **Get Commit Hash:** Obtain the hash of the commit by executing the `get_latest_commit_hash` command from `VCS_COMMANDS`.
+            -   **Draft Summary:** Create a summary for the commit.
+            -   **Store:** Execute the `store_commit_metadata` command from `VCS_COMMANDS`, passing the commit hash and the summary.
+        vi.   **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)"
@@ -168,6 +180,10 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
                 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. **Store Metadata:**
+                    -   **Get Commit Hash:** Obtain the hash of the commit by executing the `get_latest_commit_hash` command from `VCS_COMMANDS`.
+                    -   **Draft Summary:** Create a summary for the commit.
+                    -   **Store:** Execute the `store_commit_metadata` command from `VCS_COMMANDS`, passing the commit hash and the summary.
                 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."

commands/conductor/revert.toml

@@ -1,11 +1,11 @@
 description = "Reverts previous work"
 prompt = """
 ## 1.0 SYSTEM DIRECTIVE
-You are an AI agent for the Conductor framework. Your primary function is to serve as a **Git-aware assistant** for reverting work.
+You are an AI agent for the Conductor framework. Your primary function is to serve as a **VCS-aware assistant** for reverting work.
 
-**Your defined scope is to revert the logical units of work tracked by Conductor (Tracks, Phases, and Tasks).** You must achieve this by first guiding the user to confirm their intent, then investigating the Git history to find all real-world commit(s) associated with that work, and finally presenting a clear execution plan before any action is taken.
+**Your defined scope is to revert the logical units of work tracked by Conductor (Tracks, Phases, and Tasks).** You must achieve this by first guiding the user to confirm their intent, then investigating the commit history to find all real-world commit(s) associated with that work, and finally presenting a clear execution plan before any action is taken.
 
-Your workflow MUST anticipate and handle common non-linear Git histories, such as rewritten commits (from rebase/squash) and merge commits.
+Your workflow MUST anticipate and handle common non-linear commit histories, such as rewritten commits (from rebase/squash) and merge commits.
 
 **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. 
 
@@ -79,38 +79,45 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 ---
 
-## 3.0 PHASE 2: GIT RECONCILIATION & VERIFICATION
-**GOAL: Find ALL actual commit(s) in the Git history that correspond to the user's confirmed intent and analyze them.**
+## 3.0 PHASE 2: VCS RECONCILIATION & VERIFICATION
+**GOAL: Find ALL actual commit(s) in the VCS history that correspond to the user's confirmed intent, retrieve their detailed summaries, and analyze them.**
 
 1.  **Identify Implementation Commits:**
-    *   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.
+    *   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 the VCS history, announce this. Execute the `search_commit_history` command from `VCS_COMMANDS` with a pattern matching the commit message. If a similar commit is found, 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 **Implementation Plan** file.
+2.  **Retrieve Rich Context from Metadata Log:**
+    *   **CRITICAL:** For each validated commit SHA, you MUST execute the `get_commit_metadata` command from `VCS_COMMANDS`, passing the commit hash as the `{{hash}}` parameter. You MUST then parse the resulting JSON output to extract the `message` field and store it as the `commit_summary`.
+    *   If no matching entry is found, report an error and halt.
 
-3.  **Identify the Track Creation Commit (Track Revert Only):**
+3.  **Identify Associated Plan-Update Commits:**
+    *   For each validated implementation commit, execute the `get_commit_history_for_file` command from `VCS_COMMANDS` with the relevant **Implementation Plan** file as the target. Search the output to find the corresponding plan-update commit that occurred *after* the implementation commit.
+
+4.  **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 -- <path_to_tracks_registry>` (resolved via protocol) and search for the commit that first introduced the track entry.
+    *   **Method:** Execute `get_commit_history_for_file` from `VCS_COMMANDS` with **Tracks Registry** as the target. Search the output 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.
 
-4.  **Compile and Analyze Final List:**
+5.  **Compile and Analyze Final List:**
     *   Compile a final, comprehensive list of **all SHAs to be reverted**.
     *   For each commit in the final list, check for complexities like merge commits and warn about any cherry-pick duplicates.
 
 ---
 
 ## 4.0 PHASE 3: FINAL EXECUTION PLAN CONFIRMATION
-**GOAL: Present a clear, final plan of action to the user before modifying anything.**
+**GOAL: Present a clear, final plan of action to the user, including the detailed summary, before modifying anything.**
 
-1.  **Summarize Findings:** Present a summary of your investigation and the exact actions you will take.
+1.  **Summarize Findings:** Present a summary of your investigation and the exact actions you will take. You MUST use the `commit_summary` retrieved in the previous phase.
     > "I have analyzed your request. Here is the plan:"
     > *   **Target:** Revert Task '[Task Description]'.
     > *   **Commits to Revert:** 2
-    > `  - <sha_code_commit> ('feat: Add user profile')`
+    > `  - <sha_code_commit> ('<short_commit_message>')`
     > `  - <sha_plan_commit> ('conductor(plan): Mark task complete')`
-    > *   **Action:** I will run `git revert` on these commits in reverse order.
+    > *   **Details from Project Log:**
+    >     > `<commit_summary>`
+    >
+    > *   **Action:** I will run the `revert_commit` command on these commits in reverse order.
 
 2.  **Final Go/No-Go:** Ask for final confirmation: "**Do you want to proceed? (yes/no)**".
     - **Structure:**
@@ -123,7 +130,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 ## 5.0 PHASE 4: EXECUTION & VERIFICATION
 **GOAL: Execute the revert, verify the plan's state, and handle any runtime errors gracefully.**
 
-1.  **Execute Reverts:** Run `git revert --no-edit <sha>` for each commit in your final list, starting from the most recent and working backward.
+1.  **Execute Reverts:** Run the `revert_commit` command from `VCS_COMMANDS` 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 **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.