diff --git a/commands/conductor/implement.toml b/commands/conductor/implement.toml index 9988a6c8..0b3b4d77 100644 --- a/commands/conductor/implement.toml +++ b/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: `) and replacing it with the completed status (e.g., `## [x] Track: `). - **Commit Changes:** Stage the **Tracks Registry** file and commit with the message `chore(conductor): Mark track '' 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 ''` - - **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/`. 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 ''`. - v. **Announce Success:** Announce: "Track '' 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 '' 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 `/`. 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 ''`. + 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 '' has been permanently deleted." - **If 'no' (or anything else)**: a. **Announce Cancellation:** Announce: "Deletion cancelled. The track has not been changed." diff --git a/commands/conductor/revert.toml b/commands/conductor/revert.toml index 478b2c01..f4729a2f 100644 --- a/commands/conductor/revert.toml +++ b/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 -- ` (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: **` (new format) OR `## [ ] Track: ` (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 - > ` - ('feat: Add user profile')` + > ` - ('')` > ` - ('conductor(plan): Mark task complete')` - > * **Action:** I will run `git revert` on these commits in reverse order. + > * **Details from Project Log:** + > > `` + > + > * **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 ` 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. diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index 2f6850c3..8437bcad 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -50,21 +50,27 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re ### 2.0 Project Inception -1. **Detect Project Maturity:** +1. **VCS Discovery:** + - **Detect VCS:** You MUST first determine if a VCS is in use (e.g., Git, Mercurial, Jujutsu) and identify its type. Store this as `VCS_TYPE`. If no VCS is detected, set `VCS_TYPE` to "none". + - **Load VCS Workflow:** If `VCS_TYPE` is not "none", you MUST read and parse the commands from `templates/vcs_workflows/{VCS_TYPE}.md` into a `VCS_COMMANDS` map. This map must be persisted for subsequent operations. + +2. **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). + - A VCS repository (`VCS_TYPE` is not "none") is present. + - If `VCS_TYPE` is not "none", execute the `get_repository_status` command from `VCS_COMMANDS`. If the output is not empty, it indicates a dirty repository, which is a strong sign of a Brownfield project. - 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**. + - If ANY of the above conditions are met, 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 NONE of the "Brownfield Indicators" are found. -2. **Execute Workflow based on Maturity:** +3. **Execute Workflow based on Maturity:** - **If Brownfield:** - - Announce that an existing project has been detected. - - 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." + - Announce that an existing project has been detected. If a VCS is present, specify the `VCS_TYPE`. + - Execute `mkdir -p conductor`. + - **Initialize Metadata Log:** You MUST create `conductor/metadata.json` as an empty file. + - If `VCS_TYPE` is not "none" and the `get_repository_status` command indicated uncommitted changes, inform the user: "WARNING: You have uncommitted changes in your 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. @@ -82,11 +88,10 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re 3. **Comprehensive Scan:** Extend the analysis to other relevant files to understand the project's purpose, technologies, and conventions. - **2.1 File Size and Relevance Triage:** - 1. **Respect Ignore Files:** Before scanning any files, you MUST check for the existence of `.geminiignore` and `.gitignore` files. If either or both exist, you MUST use their combined patterns to exclude files and directories from your analysis. The patterns in `.geminiignore` should take precedence over `.gitignore` if there are conflicts. This is the primary mechanism for avoiding token-heavy, irrelevant files like `node_modules`. - 2. **Efficiently List Relevant Files:** To list the files for analysis, you MUST use a command that respects the ignore files. For example, you can use `git ls-files --exclude-standard -co | xargs -n 1 dirname | sort -u` which lists all relevant directories (tracked by Git, plus other non-ignored files) without listing every single file. If Git is not used, you must construct a `find` command that reads the ignore files and prunes the corresponding paths. - 3. **Fallback to Manual Ignores:** ONLY if neither `.geminiignore` nor `.gitignore` exist, you should fall back to manually ignoring common directories. Example command: `ls -lR -I 'node_modules' -I '.m2' -I 'build' -I 'dist' -I 'bin' -I 'target' -I '.git' -I '.idea' -I '.vscode'`. - 4. **Prioritize Key Files:** From the filtered list of files, focus your analysis on high-value, low-size files first, such as `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, and other configuration or manifest files. - 5. **Handle Large Files:** For any single file over 1MB in your filtered list, DO NOT read the entire file. Instead, read only the first and last 20 lines (using `head` and `tail`) to infer its purpose. + 1. **Efficiently List Relevant Files:** To obtain the list of files for analysis, you MUST execute the `list_relevant_files` command from the `VCS_COMMANDS` map. This command is designed to automatically respect the VCS's native ignore files (like `.gitignore`). You MUST also check for a `.geminiignore` file and ensure its patterns are respected, with `.geminiignore` taking precedence in case of conflicts. + 2. **Fallback to Manual Ignores:** ONLY if `VCS_TYPE` is "none" and no `.geminiignore` file exists, you should fall back to manually ignoring common directories. Example command: `ls -lR -I 'node_modules' -I '.m2' -I 'build' -I 'dist' -I 'bin' -I 'target' -I '.git' -I '.idea' -I '.vscode'`. + 3. **Prioritize Key Files:** From the filtered list of files, focus your analysis on high-value, low-size files first, such as `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, and other configuration or manifest files. + 4. **Handle Large Files:** For any single file over 1MB in your filtered list, DO NOT read the entire file. Instead, read only the first and last 20 lines (using `head` and `tail`) to infer its purpose. - **2.2 Extract and Infer Project Context:** 1. **Strict File Access:** DO NOT ask for more files. Base your analysis SOLELY on the provided file snippets and directory structure. @@ -99,11 +104,18 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **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. + - **Ask User for VCS Preference:** + > "Which Version Control System would you like to use for this project? + > A) Git (Recommended) + > B) Mercurial + > C) Jujutsu + > D) None" + - **Based on user's choice:** + - If the choice is not "None", set `VCS_TYPE` to the user's selection (e.g., "git"). + - **Load VCS Workflow:** Read and parse the commands from `templates/vcs_workflows/{VCS_TYPE}.md` into the `VCS_COMMANDS` map. + - **Initialize Repository:** Execute the `initialize_repository` command from `VCS_COMMANDS`. Report success to the user. - Proceed to the next step in this file. -3. **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?" - **CRITICAL: You MUST NOT execute any tool calls until the user has provided a response.** @@ -111,6 +123,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - 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": ""}` + - **Initialize Metadata Log:** Immediately after creating the state file, you MUST create `conductor/metadata.json` as an empty file. - Write the user's response into `conductor/product.md` under a header named `# Initial Concept`. 5. **Continue:** Immediately proceed to the next section. @@ -302,7 +315,6 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re 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): @@ -312,9 +324,6 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **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"}` diff --git a/templates/vcs_workflows/git.md b/templates/vcs_workflows/git.md new file mode 100644 index 00000000..9593c9ad --- /dev/null +++ b/templates/vcs_workflows/git.md @@ -0,0 +1,112 @@ +# VCS Workflow Definition: Git + +This file defines the specific shell commands and their expected behaviors for Conductor to use when operating within a Git repository. Each command includes details about its execution, expected successful exit codes, and structured error handlers for common failure scenarios. + +--- + +## Command Definitions + +### initialize_repository +# Purpose: Initializes a new, empty Git repository in the current directory. +command: git init +success_code: 0 +error_handlers: + - exit_code: 128 + stderr_contains: "already exists and is not an empty directory" + agent_action: "A Git repository already exists here. Conductor will proceed, but no new repository was initialized." + +### get_repository_status +# Purpose: Checks the status of the working tree to detect uncommitted changes. +# Expected Output: A list of modified/untracked files (one per line). Empty if clean. +command: git status --porcelain +success_code: 0 +error_handlers: [] + +### list_relevant_files +# Purpose: Lists all files tracked by Git, plus any other non-ignored files. +# Expected Output: A list of file paths (one per line). +command: git ls-files --exclude-standard -co +success_code: 0 +error_handlers: [] + +### get_latest_commit_hash +# Purpose: Retrieves the full SHA hash of the most recent commit (HEAD). +# Expected Output: A single 40-character commit SHA. +command: git log -1 --format="%H" +success_code: 0 +error_handlers: + - exit_code: 128 + stderr_contains: "does not have any commits yet" + agent_action: "The repository has no commits yet. Unable to retrieve a hash." + +### get_changed_files_since +# Purpose: Lists all files that have been changed between a specified commit and HEAD. +# Placeholders: +# - {{hash}}: The starting commit hash to compare against. +# Expected Output: A list of file paths that have changed (one per line). +command: git diff --name-only {{hash}} HEAD +success_code: 0 +error_handlers: + - exit_code: 128 + stderr_contains: "bad object" + agent_action: "The provided hash '{{hash}}' is not a valid Git object." + +### store_commit_metadata +# Purpose: Appends a JSON object containing metadata about a commit to the project's metadata log. +# Placeholders: +# - {{hash}}: The hash of the commit to log. +# - {{message}}: The detailed summary/message to associate with the commit. +command: echo "{\"hash\": \"{{hash}}\", \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\", \"message\": \"{{message}}\"}" >> conductor/metadata.json +success_code: 0 +error_handlers: + - exit_code: "*" # Catch any non-zero exit code + agent_action: "Failed to write metadata to conductor/metadata.json. This might indicate a permissions issue or file system problem." + +### get_commit_metadata +# Purpose: Searches the metadata log and retrieves the full JSON line for a specific commit hash. +# Placeholders: +# - {{hash}}: The commit hash to search for. +# Expected Output: The full JSON string corresponding to the commit if found, otherwise empty. +command: grep ""hash": "{{hash}}"" conductor/metadata.json +success_code: 0 +error_handlers: + - exit_code: 1 # grep returns 1 if no lines were selected + agent_action: "No metadata found for commit hash '{{hash}}' in conductor/metadata.json." + +### revert_commit +# Purpose: Creates a new commit that reverts the changes from a specified commit. +# Placeholders: +# - {{hash}}: The hash of the commit to revert. +command: git revert --no-edit {{hash}} +success_code: 0 +error_handlers: + - exit_code: 1 + stderr_contains: "could not revert" + agent_action: "A merge conflict occurred while reverting commit '{{hash}}'. The revert has been initiated, but you must now resolve the conflicts manually. Once resolved, use 'git commit' to finalize the revert process." + - exit_code: 128 + stderr_contains: "unknown revision" + agent_action: "The commit hash '{{hash}}' was not found in the repository history. The revert could not be started." + - exit_code: 128 + stderr_contains: "is a merge but no -m option was given" + agent_action: "The commit '{{hash}}' is a merge commit. Conductor cannot automatically revert merge commits. Please revert it manually specifying a parent number (e.g., 'git revert -m 1 {{hash}}')." + +### get_commit_history_for_file +# Purpose: Retrieves the commit history for a specific file. +# Placeholders: +# - {{file}}: The path to the file to get the history for. +# Expected Output: The standard `git log` output for the specified file. +command: git log -- {{file}} +success_code: 0 +error_handlers: + - exit_code: 128 + stderr_contains: "ambiguous argument" + agent_action: "The file path '{{file}}' is ambiguous or does not exist." + +### search_commit_history +# Purpose: Searches the entire commit history for commits whose messages match a specific pattern. +# Placeholders: +# - {{pattern}}: The regex pattern to search for in commit messages. +# Expected Output: The standard `git log` output for any matching commits. +command: git log --grep="{{pattern}}" +success_code: 0 +error_handlers: [] \ No newline at end of file diff --git a/templates/workflow.md b/templates/workflow.md index 6f9cfd8f..13ba49e9 100644 --- a/templates/workflow.md +++ b/templates/workflow.md @@ -49,13 +49,13 @@ All tasks follow a strict lifecycle: - Propose a clear, concise commit message e.g, `feat(ui): Create basic HTML structure for calculator`. - Perform the commit. -9. **Attach Task Summary with Git Notes:** - - **Step 9.1: Get Commit Hash:** Obtain the hash of the *just-completed commit* (`git log -1 --format="%H"`). - - **Step 9.2: Draft Note Content:** Create a detailed summary for the completed task. This should include the task name, a summary of changes, a list of all created/modified files, and the core "why" for the change. - - **Step 9.3: Attach Note:** Use the `git notes` command to attach the summary to the commit. +9. **Store Task Summary in Metadata Log:** + - **Step 9.1: Get Commit Hash:** Obtain the hash of the *just-completed commit* by executing the `get_latest_commit_hash` command from `VCS_COMMANDS`. + - **Step 9.2: Draft Summary:** Create a detailed summary for the completed task. This should include the task name, a summary of changes, and the core "why" for the change. + - **Step 9.3: Store Metadata:** Execute the `store_commit_metadata` command from `VCS_COMMANDS`, passing the commit hash and the summary as arguments. This will append a new JSON object on a new line to the `conductor/metadata.json` log file. ```bash - # The note content from the previous step is passed via the -m flag. - git notes add -m "" + # Conceptual example of the underlying operation: + # echo '{"hash": "", "message": ""}' >> conductor/metadata.json ``` 10. **Get and Record Task Commit SHA:** @@ -73,8 +73,8 @@ All tasks follow a strict lifecycle: 1. **Announce Protocol Start:** Inform the user that the phase is complete and the verification and checkpointing protocol has begun. 2. **Ensure Test Coverage for Phase Changes:** - - **Step 2.1: Determine Phase Scope:** To identify the files changed in this phase, you must first find the starting point. Read `plan.md` to find the Git commit SHA of the *previous* phase's checkpoint. If no previous checkpoint exists, the scope is all changes since the first commit. - - **Step 2.2: List Changed Files:** Execute `git diff --name-only HEAD` to get a precise list of all files modified during this phase. + - **Step 2.1: Determine Phase Scope:** To identify the files changed in this phase, you must first find the starting point. Read `plan.md` to find the VCS commit SHA of the *previous* phase's checkpoint. If no previous checkpoint exists, the scope is all changes since the first commit. + - **Step 2.2: List Changed Files:** Execute the `get_changed_files_since` command from `VCS_COMMANDS`, providing the previous checkpoint SHA as the argument, to get a precise list of all files modified during this phase. - **Step 2.3: Verify and Create Tests:** For each file in the list: - **CRITICAL:** First, check its extension. Exclude non-code files (e.g., `.json`, `.md`, `.yaml`). - For each remaining code file, verify a corresponding test file exists. @@ -119,12 +119,12 @@ All tasks follow a strict lifecycle: - Stage all changes. If no changes occurred in this step, proceed with an empty commit. - Perform the commit with a clear and concise message (e.g., `conductor(checkpoint): Checkpoint end of Phase X`). -7. **Attach Auditable Verification Report using Git Notes:** - - **Step 7.1: Draft Note Content:** Create a detailed verification report including the automated test command, the manual verification steps, and the user's confirmation. - - **Step 7.2: Attach Note:** Use the `git notes` command and the full commit hash from the previous step to attach the full report to the checkpoint commit. +7. **Attach Auditable Verification Report to Metadata Log:** + - **Step 7.1: Draft Report:** Create a detailed verification report including the automated test command, the manual verification steps, and the user's confirmation. + - **Step 7.2: Store Metadata:** Use the `store_commit_metadata` command from `VCS_COMMANDS` to attach the full report to the checkpoint commit's hash. This will append a new JSON object on a new line to the `conductor/metadata.json` log file. 8. **Get and Record Phase Checkpoint SHA:** - - **Step 8.1: Get Commit Hash:** Obtain the hash of the *just-created checkpoint commit* (`git log -1 --format="%H"`). + - **Step 8.1: Get Commit Hash:** Obtain the hash of the *just-created checkpoint commit* by executing `get_latest_commit_hash` from `VCS_COMMANDS`. - **Step 8.2: Update Plan:** Read `plan.md`, find the heading for the completed phase, and append the first 7 characters of the commit hash in the format `[checkpoint: ]`. - **Step 8.3: Write Plan:** Write the updated content back to `plan.md`. @@ -132,7 +132,7 @@ All tasks follow a strict lifecycle: - **Action:** Stage the modified `plan.md` file. - **Action:** Commit this change with a descriptive message following the format `conductor(plan): Mark phase '' as complete`. -10. **Announce Completion:** Inform the user that the phase is complete and the checkpoint has been created, with the detailed verification report attached as a git note. +10. **Announce Completion:** Inform the user that the phase is complete and the checkpoint has been created, with the detailed verification report stored in the project's metadata log. ### Quality Gates @@ -272,7 +272,7 @@ A task is complete when: 6. Works beautifully on mobile (if applicable) 7. Implementation notes added to `plan.md` 8. Changes committed with proper message -9. Git note with task summary attached to the commit +9. Task summary stored in the project metadata log ## Emergency Procedures