From 31e5b4b07bbed3a88cc57df043e91f785b6ca502 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Tue, 20 Jan 2026 16:53:19 +0000 Subject: [PATCH 01/10] feat(vcs): Add git workflow for VCS abstraction Introduces a new workflow file, , which contains the specific Git commands required by the Conductor extension. This is the first step in decoupling the core logic from the version control system, allowing for future support of other systems like Mercurial or Jujutsu. The file defines a 'VCS contract' of abstract operations and their corresponding Git implementations. Change-Id: Ie8885b3bb58443d2736a355d0a14bb741826bc65 --- templates/vcs_workflows/git.md | 46 ++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 templates/vcs_workflows/git.md diff --git a/templates/vcs_workflows/git.md b/templates/vcs_workflows/git.md new file mode 100644 index 00000000..2e04e9a3 --- /dev/null +++ b/templates/vcs_workflows/git.md @@ -0,0 +1,46 @@ +# VCS Workflow Definition: Git + +This file defines the specific shell commands for Conductor to use when operating within a Git repository. + +## Command Definitions + +### initialize_repository +```bash +git init +``` + +### get_repository_status +```bash +# This command outputs a list of modified/untracked files. +# An empty output means the repository is clean. +git status --porcelain +``` + +### list_relevant_files +```bash +# Lists all tracked files and other non-ignored files in the repo. +git ls-files --exclude-standard -co +``` + +### get_latest_commit_hash +```bash +git log -1 --format="%H" +``` + +### get_changed_files_since +```bash +# Expects {{hash}} to be replaced with the target commit hash. +git diff --name-only {{hash}} HEAD +``` + +### store_commit_metadata +```bash +# Expects {{hash}} and {{message}} to be replaced. +git notes add -m "{{message}}" {{hash}} +``` + +### revert_commit +```bash +# Expects {{hash}} to be replaced. +git revert --no-edit {{hash}} +``` From 77dba6b31a15dc3490d606906a0cda80014b64d9 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Tue, 20 Jan 2026 16:59:30 +0000 Subject: [PATCH 02/10] refactor(setup): Decouple VCS logic from project inception Revises the project setup process to be VCS-agnostic. - Adds a VCS discovery step at the beginning to identify the version control system (Git, Mercurial, etc.) and load a corresponding workflow file. - Replaces hardcoded On branch vcs-support Changes to be committed: (use "git restore --staged ..." to unstage) modified: commands/conductor/setup.toml and Reinitialized existing Git repository in /usr/local/google/home/mshanware/conductor/.git/ commands with abstracted commands (, ) from the loaded workflow. - In Greenfield projects, prompts the user to select their preferred VCS. - Preserves existing Brownfield indicators like dependency manifests and source code directories. Change-Id: Ic849d132324997548d9856b044372d2ba9279dc0 --- commands/conductor/setup.toml | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index 2f6850c3..a1444642 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -50,21 +50,25 @@ 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`. + - 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. @@ -83,7 +87,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **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. + 2. **Efficiently List Relevant Files:** To list the files for analysis, you MUST use a command that respects the ignore files. For example, if `VCS_TYPE` is "git", you can use `git ls-files --exclude-standard -co | xargs -n 1 dirname | sort -u`. If another VCS is used, you must adapt this approach based on its commands or 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. @@ -99,11 +103,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.** From 1d9cbba7ff33d4b406ed447c6520abfae2e15e85 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Tue, 20 Jan 2026 17:02:28 +0000 Subject: [PATCH 03/10] refactor(setup): Abstract VCS-specific file listing Revises the 'File Size and Relevance Triage' section to be fully VCS-agnostic. - Removes hardcoded examples of .github/workflows/release-please.yml .gitignore .release-please-manifest.json CONTRIBUTING.md GEMINI.md LICENSE README.md commands/conductor/implement.toml commands/conductor/newTrack.toml commands/conductor/revert.toml commands/conductor/setup.toml commands/conductor/status.toml gemini-extension.json release-please-config.json templates/code_styleguides/csharp.md templates/code_styleguides/dart.md templates/code_styleguides/general.md templates/code_styleguides/go.md templates/code_styleguides/html-css.md templates/code_styleguides/javascript.md templates/code_styleguides/python.md templates/code_styleguides/typescript.md templates/vcs_workflows/git.md templates/workflow.md and specific checks for . - Instructs the agent to use the abstract command from the loaded VCS workflow. - This ensures that the core logic for listing files is decoupled from the specific VCS implementation, adhering to the new architectural pattern. Change-Id: I2d7fbfee4dd17b98df417899a0b995e97c6014c1 --- commands/conductor/setup.toml | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index a1444642..504e52cc 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -86,11 +86,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, if `VCS_TYPE` is "git", you can use `git ls-files --exclude-standard -co | xargs -n 1 dirname | sort -u`. If another VCS is used, you must adapt this approach based on its commands or 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. From 493ff82ee90e6009612e1dae4f587817f2720c09 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Tue, 20 Jan 2026 17:04:16 +0000 Subject: [PATCH 04/10] refactor(revert): Decouple revert logic from Git MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Makes the revert command fully VCS-agnostic. - Updates the workflow with new abstract commands for searching commit history (, ). - Replaces all hardcoded commit df6384ee585d29eb90a74b1d0154072afea26437 Author: Mahima Shanware Date: Tue Jan 20 17:02:28 2026 +0000 refactor(setup): Abstract VCS-specific file listing Revises the 'File Size and Relevance Triage' section to be fully VCS-agnostic. - Removes hardcoded examples of .github/workflows/release-please.yml .gitignore .release-please-manifest.json CONTRIBUTING.md GEMINI.md LICENSE README.md commands/conductor/implement.toml commands/conductor/newTrack.toml commands/conductor/revert.toml commands/conductor/setup.toml commands/conductor/status.toml gemini-extension.json release-please-config.json templates/code_styleguides/csharp.md templates/code_styleguides/dart.md templates/code_styleguides/general.md templates/code_styleguides/go.md templates/code_styleguides/html-css.md templates/code_styleguides/javascript.md templates/code_styleguides/python.md templates/code_styleguides/typescript.md templates/vcs_workflows/git.md templates/workflow.md and specific checks for . - Instructs the agent to use the abstract command from the loaded VCS workflow. - This ensures that the core logic for listing files is decoupled from the specific VCS implementation, adhering to the new architectural pattern. Change-Id: I2d7fbfee4dd17b98df417899a0b995e97c6014c1 commit 93219ebf4af39fb2cc14172b7d4ae5426dd2adb4 Author: Mahima Shanware Date: Tue Jan 20 16:59:30 2026 +0000 refactor(setup): Decouple VCS logic from project inception Revises the project setup process to be VCS-agnostic. - Adds a VCS discovery step at the beginning to identify the version control system (Git, Mercurial, etc.) and load a corresponding workflow file. - Replaces hardcoded On branch vcs-support Changes to be committed: (use "git restore --staged ..." to unstage) modified: commands/conductor/setup.toml and Reinitialized existing Git repository in /usr/local/google/home/mshanware/conductor/.git/ commands with abstracted commands (, ) from the loaded workflow. - In Greenfield projects, prompts the user to select their preferred VCS. - Preserves existing Brownfield indicators like dependency manifests and source code directories. Change-Id: Ic849d132324997548d9856b044372d2ba9279dc0 commit 8b514bca814ec4e8e94b3662bc5a296a59d2d305 Author: Mahima Shanware Date: Tue Jan 20 16:53:19 2026 +0000 feat(vcs): Add git workflow for VCS abstraction Introduces a new workflow file, , which contains the specific Git commands required by the Conductor extension. This is the first step in decoupling the core logic from the version control system, allowing for future support of other systems like Mercurial or Jujutsu. The file defines a 'VCS contract' of abstract operations and their corresponding Git implementations. Change-Id: Ie8885b3bb58443d2736a355d0a14bb741826bc65 commit d2b5c9af5401dfcd94eb6a00e598e29571f92999 Merge: 716c758 08e9b95 Author: Sherzat Aitbayev Date: Tue Jan 13 16:43:44 2026 -0500 Merge pull request #67 from nathenharvey/nathenharvey/newline-eof style(templates): add trailing newlines to styleguide templates commit 08e9b952dbbf6bf6423fe20cb91295a9268120ed Author: Nathen Harvey Date: Mon Jan 12 12:50:53 2026 -0500 style(templates): add trailing newlines to styleguide templates Ensure that styleguide templates comply with POSIX standards by ending with a newline character. This improves compatibility with command-line tools and ensures consistent formatting for generated files. Modified files: - templates/code_styleguides/go.md - templates/code_styleguides/html-css.md - templates/code_styleguides/javascript.md - templates/code_styleguides/python.md - templates/code_styleguides/typescript.md Signed-off-by: Nathen Harvey commit 716c758131b636f82e67a85173c032bda7b8af58 Merge: 92080f0 e758efe Author: Sherzat Aitbayev Date: Fri Jan 9 16:58:48 2026 -0500 Merge pull request #65 from gemini-cli-extensions/chore/bot-release-token chore(github-actions): use dedicated bot token for release-please commit e758efe6fbe89285758849646f7f0d2f0c20ebbb Author: sherzat Date: Fri Jan 9 21:54:03 2026 +0000 chore(github-actions): use dedicated bot token for release-please Change-Id: Ieb55f9aee5525f95681407ff01b4b73b2baef714 commit 92080f0508ca370373adee1addec07855506adeb Merge: f6a1522 84634e7 Author: Moisés Gana Obregón <78716364+moisgobg@users.noreply.github.com> Date: Tue Jan 6 12:21:35 2026 -0600 Merge pull request #51 from gemini-cli-extensions/fix-checkbox-issue fix: standardize Markdown checkbox format for tracks and plans commit 84634e774bc37bd3996815dfd6ed41a519b45c1d Author: Moisés Gana Obregón Date: Mon Jan 5 22:12:30 2026 +0000 fix: standardize Markdown checkbox format for tracks and plans commit f6a1522d0dea1e0ea887fcd732f1b47475dc0226 Merge: 653829b dd1cd1c Author: Moisés Gana Obregón <78716364+moisgobg@users.noreply.github.com> Date: Mon Jan 5 16:51:07 2026 -0600 Merge pull request #48 from gemini-cli-extensions/fix/issue-16-auto-commits fix(conductor): ensure track completion and doc sync are committed automatically commit dd1cd1c651a25cadadedeb2c6c78590c945aeaeb Author: Moisés Gana Obregón Date: Mon Jan 5 22:24:13 2026 +0000 chore(conductor): Update commit message templates to follow Conventional Commits commit e5815448e01b23e4a55b7f629d559f4c7bcdccf5 Author: Moisés Gana Obregón Date: Sun Jan 4 08:23:00 2026 +0000 correct step numbers commit e3630acc146a641f29fdf23f9c28d5d9cdf945b8 Author: Moisés Gana Obregón Date: Sat Jan 3 00:40:27 2026 +0000 fix(conductor): ensure track completion and doc sync are committed automatically This adds explicit commit steps to the implement command for: - Track completion status updates in tracks.md - Project documentation synchronization - Track cleanup (archiving or deleting) BUG=16 commit 653829b1a72a614839c8bbb33b6c82c830911f55 Merge: 6672f4e 830f584 Author: Sherzat Aitbayev Date: Fri Jan 2 16:04:01 2026 -0500 Merge pull request #46 from gemini-cli-extensions/ci/add-release-please ci: add release-please workflow commit 830f5847c206a9b76d58ebed0c184ff6c0c6e725 Author: sherzat Date: Fri Jan 2 20:27:32 2026 +0000 fix: build tarball outside source tree to avoid self-inclusion Change-Id: I6b19d26db85220f25bbbf9509cd083fbd159b1dd commit 3ef512c3320e7877f1c05ed34433cf28a3111b30 Author: sherzat Date: Fri Jan 2 20:18:48 2026 +0000 feat: integrate release asset packaging into release-please workflow Change-Id: I4ef04e2bfa1cd9bce8298baba041ad761eccc9d8 commit f26f1b82e16528b5432cdef632bf6b841c741bd1 Author: sherzat Date: Fri Jan 2 19:53:09 2026 +0000 ci: add release-please workflow Change-Id: I7e5df1a8b1f269488e08c0ca9b18f77a08e2f80a commit 6672f4ec2d2aa3831b164635a3e4dc0aa6f17679 Merge: aa81ce1 8bfc888 Author: Sherzat Aitbayev Date: Mon Dec 29 13:40:03 2025 -0500 Merge pull request #10 from xbotter/main feat(styleguide): Add comprehensive Google C# Style Guide summary commit aa81ce1f19651045430e713879b8552adc663b65 Merge: bcc86ab 819dcc9 Author: Moisés Gana Obregón <78716364+moisgobg@users.noreply.github.com> Date: Fri Dec 26 12:30:11 2025 -0600 Merge pull request #26 from gemini-cli-extensions/fix/clarify-track-definition commit 8bfc888b1b1a4191228f0d85e3ac89fe25fb9541 Author: xbotter Date: Wed Dec 24 02:17:30 2025 +0000 fix(styleguide): Update C# guidelines by removing async method suffix rule and adding best practices for structs, collection types, file organization, and namespaces commit 819dcc989d70d572d81655e0ac0314ede987f8b4 Author: moisgobg Date: Tue Dec 23 16:25:14 2025 -0600 fix(setup): clarify definition of 'track' in setup flow commit bcc86ab7ecd7660c7314a064233f16ecff6f5364 Merge: ab9516b ef2bcaa Author: Sherzat Aitbayev Date: Tue Dec 23 13:28:21 2025 -0500 Merge pull request #23 from jtmcdole/dart-style Add Dart Code Style commit ef2bcaaa79783885b1e071b9d2ba6d36f68a002d Author: John "codefu" McDole Date: Mon Dec 22 21:40:48 2025 -0800 Add Dart Code Style This guide summarizes key recommendations from the official Effective Dart documentation, covering style, documentation, language usage, and API design principles. Adhering to these guidelines promotes consistent, readable, and maintainable Dart code. commit 0e0991b73210f83b2b26007e813603d3cd2f0d48 Author: xbotter Date: Tue Dec 23 04:58:34 2025 +0000 fix(styleguide): Update C# guidelines for member ordering and enhance clarity on string interpolation commit eea7495194edb01f6cfa86774cf2981ed012bf73 Author: xbotter Date: Tue Dec 23 03:12:02 2025 +0000 fix(styleguide): Enhance C# guidelines with additional rules for constants, collections, and argument clarity commit a67b6c08cac15de54f01cd1e64fff3f99bc55462 Author: xbotter Date: Tue Dec 23 03:02:38 2025 +0000 fix(styleguide): Clarify usage of 'var' in C# guidelines for better readability commit 50f39abf9941ff4786e3b995d4c077bfdf07b9c9 Author: xbotter Date: Tue Dec 23 02:41:12 2025 +0000 fix(styleguide): Update C# formatting rules and guidelines for consistency commit 5e51848e5cc9b2935f3e5d96130904194b568094 Merge: e222aca ab9516b Author: xbotter Date: Tue Dec 23 10:24:25 2025 +0800 Merge branch 'gemini-cli-extensions:main' into main commit ab9516ba6dd29d0ec5ea40b2cb2abab83fc791be Merge: 916ceb2 d825c32 Author: Sherzat Aitbayev Date: Mon Dec 22 17:27:27 2025 -0500 Merge pull request #17 from Ashwinhegde19/fix/typos-and-docs fix: Correct typos, step numbering, and documentation errors commit 916ceb2a1fe3f03c0bf18ec2a24ae922e605d64a Author: Sherzat Aitbayev Date: Mon Dec 22 16:32:07 2025 -0500 Bump version from 0.1.0 to 0.1.1 commit d825c326061ab63a4d3b8928cbf32bc3f6a9c797 Author: ashwinhegde19 Date: Sun Dec 21 00:17:58 2025 +0530 fix: Correct typos, step numbering, and documentation errors - status.toml: Fix incorrect path (conductor/ -> conductor/tracks/) - workflow.md: Fix step numbering errors in Phase Completion section - newTrack.toml: Remove trailing comma in JSON example - setup.toml: Remove trailing comma in JSON example - README.md: Add missing product-guidelines.md to artifacts list commit e222aca7eb7475c07e618b410444f14090d62715 Author: xbotter Date: Fri Dec 19 09:12:02 2025 +0000 feat(styleguide): Add comprehensive Google C# Style Guide summary commit b49d77058ccd5ccedc83c1974cc36a2340b637ab Merge: 484d5f3 746b2e5 Author: Moisés Gana Obregón <78716364+moisgobg@users.noreply.github.com> Date: Thu Dec 18 13:02:25 2025 -0600 Merge pull request #3 from gemini-cli-extensions/fix/user-agent-interaction-formats fix: Replace manual text input with interactive options commit 484d5f3cf7a0c4a8cbbcaff71f74b62c0af3dd35 Merge: 1e60e8a b90a4ea Author: Moisés Gana Obregón <78716364+moisgobg@users.noreply.github.com> Date: Thu Dec 18 13:00:43 2025 -0600 Merge pull request #1 from gemini-cli-extensions/fix/typos-grammar fix: Correct typos, trailing whitespace and grammar commit b90a4ea0c0fc405a2fe3fa23634be6c0d35d1270 Author: Moisés Gana Obregón Date: Thu Dec 18 18:55:09 2025 +0000 Fix typos and trailing whitespaces commit a15eb6702521b6ade32d358a5e4160390e6c9203 Merge: 94edcbb 1e60e8a Author: Moisés Gana Obregón Date: Thu Dec 18 18:32:02 2025 +0000 Merge branch 'main' into fix/typos-grammar Resolves conflicts in conductor commands. commit 1e60e8a96e5abeab966ff8d5bd95e14e3e331cfa Author: Moisés Gana Obregón <78716364+moisgobg@users.noreply.github.com> Date: Thu Dec 18 12:13:47 2025 -0600 fix(setup): Enhance project analysis protocol to avoid excessive token consumption. (#6) * fix(setup): Enhance project analysis protocol to avoid excessive token consumption. This commit updates the setup process in setup.toml to prioritize .geminiignore and .gitignore files for excluding irrelevant content during project analysis. The primary motivation for this change is to prevent excessive token consumption. The new protocol ensures that .geminiignore takes precedence and introduces git ls-files --exclude-standard -co for efficient directory/file listing, falling back to manual ignores only when no ignore files are present. commit c2321a13b944ae53937d8eb7cf19bfb19b588b71 Merge: eaa947d 4915580 Author: Sherzat Aitbayev Date: Thu Dec 18 08:57:02 2025 -0500 Merge pull request #5 from gemini-cli-extensions/refactor/standardize-conductor-path refactor: rename project-level `plan.md` to `tracks.md` commit 49155808130e6b4ab4b5470ef373d8b85f475896 Author: sherzat Date: Wed Dec 17 22:38:44 2025 +0000 refactor: rename project-level `plan.md` to `tracks.md` and update references in documentation and command configurations Change-Id: I13ab825808fdba3cf7616d3c6e7311a5fbece600 commit eaa947decabb1dda7ff0aceab3ddc748a8477724 Merge: e4c9322 dd57f50 Author: Sherzat Aitbayev Date: Wed Dec 17 17:16:36 2025 -0500 Merge pull request #4 from gemini-cli-extensions/refactor/standardize-conductor-path refactor: standardize conductor directory path by removing leading dot. commit dd57f50da623a01db3c1656aa7bdac93cc6e37f0 Author: sherzat Date: Wed Dec 17 22:11:14 2025 +0000 refactor: standardize conductor directory path by removing leading dot. Change-Id: I1f995bbdd7ebc99a79bd49223ccb5d6fa39b35c7 commit e4c93221043539c5a5500be5a614cda6c7f5e20e Author: sherzat Date: Wed Dec 17 20:41:34 2025 +0000 docs: Simplify the development lifecycle, detail generated artifacts, and enhance the command reference in the README. Change-Id: Id185ee2ce44caa2838240c1463acbf455f1000b0 commit 746b2e5f0a5ee9fc49edf8480dad3b8afffe8064 Author: Moisés Gana Obregón Date: Wed Dec 17 18:24:12 2025 +0000 fix: Replace manual text input with interactive options commit 5e0fcb0d4d19acfd8f62b08b5f9404a1a4f53f14 Merge: f0b2783 20858c9 Author: Sherzat Aitbayev Date: Wed Dec 17 13:06:22 2025 -0500 Merge pull request #2 from gemini-cli-extensions/feat/github-actions-workflow feat: Add GitHub Actions workflow to package and upload release assets. commit 20858c90b48eabb5fe77aefab5a216269cc77c09 Author: sherzat Date: Wed Dec 17 18:02:40 2025 +0000 feat: Add GitHub Actions workflow to package and upload release assets. Change-Id: I018079742aa9eca132952f6f464c37171863cb10 commit 94edcbbd0102eb6f9d5977eebf0cc3511aff6f64 Author: Moisés Gana Obregón Date: Wed Dec 17 17:57:22 2025 +0000 fix: Correct typos, trailing whitespace and grammar commit f0b278377670ba437fe2116beccd94c732d434b1 Author: Mahima Shanware Date: Tue Dec 16 21:06:27 2025 +0000 add task clean up after finishing implement Change-Id: I3f27f41882a32396a06ab1c8a66ac1cae1d83b23 commit e9152229ab70144b9c5f856d81c9e868903bf252 Author: sherzat Date: Wed Dec 17 16:05:04 2025 +0000 Initial commit Change-Id: I3a212acf736c1a4b9a7672e5f259e92aab80a318 and commands in with their abstract counterparts from the map. - Changes the system directive to be a generic 'VCS-aware assistant' instead of a 'Git-aware assistant'. Change-Id: Ibe3d7f35cab2ab0cf8e0b077a724578a297a1571 --- commands/conductor/revert.toml | 22 +++++++++++----------- templates/vcs_workflows/git.md | 12 ++++++++++++ 2 files changed, 23 insertions(+), 11 deletions(-) diff --git a/commands/conductor/revert.toml b/commands/conductor/revert.toml index 478b2c01..90debeb8 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,19 +79,19 @@ 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 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. + * 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. 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 -- ` (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 the **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. @@ -110,7 +110,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai > * **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. + > * **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 +123,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/templates/vcs_workflows/git.md b/templates/vcs_workflows/git.md index 2e04e9a3..055ce681 100644 --- a/templates/vcs_workflows/git.md +++ b/templates/vcs_workflows/git.md @@ -44,3 +44,15 @@ git notes add -m "{{message}}" {{hash}} # Expects {{hash}} to be replaced. git revert --no-edit {{hash}} ``` + +### get_commit_history_for_file +```bash +# Expects {{file}} to be replaced. +git log -- {{file}} +``` + +### search_commit_history +```bash +# Expects {{pattern}} to be replaced. +git log --grep="{{pattern}}" +``` \ No newline at end of file From e7fcbb13c1c5e1957cbc2d3f513f2ed59b147bc9 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Tue, 20 Jan 2026 17:06:30 +0000 Subject: [PATCH 05/10] refactor(vcs): Replace git notes with VCS-agnostic metadata log Implements a generic metadata storage mechanism to replace the Git-specific feature. - The command in the workflow now appends a JSON object to a file. - The prompt no longer offers as a choice. - The main has been updated to reference the new metadata log instead of for storing task summaries and verification reports. Change-Id: Ibe3772fd5c6aa0168f944440e09ef74e1612caf3 --- commands/conductor/setup.toml | 4 ---- templates/vcs_workflows/git.md | 3 ++- templates/workflow.md | 28 ++++++++++++++-------------- 3 files changed, 16 insertions(+), 19 deletions(-) diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index 504e52cc..741deae4 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -312,7 +312,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): @@ -322,9 +321,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 index 055ce681..ddecf152 100644 --- a/templates/vcs_workflows/git.md +++ b/templates/vcs_workflows/git.md @@ -36,7 +36,8 @@ git diff --name-only {{hash}} HEAD ### store_commit_metadata ```bash # Expects {{hash}} and {{message}} to be replaced. -git notes add -m "{{message}}" {{hash}} +# Appends a JSON object to the metadata log. +echo "{\"hash\": \"{{hash}}\", \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\", \"message\": \"{{message}}\"}" >> .conductor/metadata.json ``` ### revert_commit diff --git a/templates/workflow.md b/templates/workflow.md index 6f9cfd8f..31c2b7a2 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 the information 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 "" + # Example of the underlying command being called: + # 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. 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 From d81bc79f19ff980d47f87fdd8a136fa0df7e491b Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Tue, 20 Jan 2026 19:55:21 +0000 Subject: [PATCH 06/10] feat(revert): Enhance revert plan with detailed commit summaries Change-Id: Ib3c6d193c5b5760390549b260a1020137b2e5ffc --- commands/conductor/revert.toml | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/commands/conductor/revert.toml b/commands/conductor/revert.toml index 90debeb8..0ef1b6e5 100644 --- a/commands/conductor/revert.toml +++ b/commands/conductor/revert.toml @@ -80,36 +80,47 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai --- ## 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 and analyze them.** +**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 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:** +2. **Retrieve Rich Context from Metadata Log:** + * **CRITICAL:** For each validated commit SHA, you MUST open the `.conductor/metadata.json` file. + * You MUST process this file efficiently due to its potential size. Instead of loading the entire file, you MUST read it **line by line in reverse order** (e.g., using `tac` or equivalent efficient method). + * For each line, you MUST parse it as a JSON object. + * You MUST then find the JSON entry where the `hash` value exactly matches the commit SHA. + * Once the matching entry is found, you MUST extract the value of the `message` key and store it as the `commit_summary`. + * If no matching entry is found, report an error and halt. + +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. -3. **Identify the Track Creation Commit (Track Revert Only):** +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:** Execute `get_commit_history_for_file` from `VCS_COMMANDS` with the **Tracks Registry** as the target. Search the output 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')` + > * **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)**". From 58a3617cd8f27cd72d482770c23128b4c3a89745 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Tue, 20 Jan 2026 22:27:36 +0000 Subject: [PATCH 07/10] fix(conductor): Create and update metadata log The revert command was failing because it expected a conductor/metadata.json file that was never created. This change ensures the file is created by the setup command and updated by the implement command. Change-Id: I48843ef021d0aab0c19f807b6759dc026fd3fd8d --- commands/conductor/implement.toml | 20 ++++++++++++++++++-- commands/conductor/setup.toml | 3 +++ templates/workflow.md | 10 ++++++---- 3 files changed, 27 insertions(+), 6 deletions(-) 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/setup.toml b/commands/conductor/setup.toml index 741deae4..bd1ea2f6 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -68,6 +68,8 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re 3. **Execute Workflow based on Maturity:** - **If Brownfield:** - 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 JSON file with the exact content: `[]` - 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:** @@ -121,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 JSON file with the exact content: `[]` - Write the user's response into `conductor/product.md` under a header named `# Initial Concept`. 5. **Continue:** Immediately proceed to the next section. diff --git a/templates/workflow.md b/templates/workflow.md index 31c2b7a2..c3f422b1 100644 --- a/templates/workflow.md +++ b/templates/workflow.md @@ -52,10 +52,12 @@ All tasks follow a strict lifecycle: 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 the information to the `.conductor/metadata.json` log file. + - **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 read the `conductor/metadata.json` log file, append the new entry to the JSON array, and write the updated array back to the file, ensuring the file remains a valid JSON array. ```bash - # Example of the underlying command being called: - # echo '{"hash": "", "message": ""}' >> .conductor/metadata.json + # Conceptual example of the underlying operation: + # 1. Read conductor/metadata.json -> [{"hash": "abc", "message": "msg1"}] + # 2. Add new entry -> [{"hash": "abc", "message": "msg1"}, {"hash": "def", "message": "msg2"}] + # 3. Write back to conductor/metadata.json ``` 10. **Get and Record Task Commit SHA:** @@ -121,7 +123,7 @@ All tasks follow a strict lifecycle: 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. + - **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 read the `conductor/metadata.json` log file, append the new entry to the JSON array, and write the updated array back to the file. 8. **Get and Record Phase Checkpoint SHA:** - **Step 8.1: Get Commit Hash:** Obtain the hash of the *just-created checkpoint commit* by executing `get_latest_commit_hash` from `VCS_COMMANDS`. From 66101e9e28609d6307ffec14556aed21c4762d0a Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Wed, 21 Jan 2026 00:02:02 +0000 Subject: [PATCH 08/10] fix(vcs): Implement safe JSONL logging for metadata - Adopts JSONL format for to ensure efficient, scalable appends. - Updates to initialize an empty metadata file. - Corrects to describe appending to a log file rather than read-modify-writing a JSON array. - Fixes the command in to use a safe append and corrects file path inconsistencies. - Resolves a typo in the prompt. - Adds a trailing newline to for POSIX compliance. Change-Id: Ie2873fc4bb6a560c360622f2899f303f6e81598e --- commands/conductor/revert.toml | 2 +- commands/conductor/setup.toml | 4 ++-- templates/vcs_workflows/git.md | 2 +- templates/workflow.md | 8 +++----- 4 files changed, 7 insertions(+), 9 deletions(-) diff --git a/commands/conductor/revert.toml b/commands/conductor/revert.toml index 0ef1b6e5..760a56fa 100644 --- a/commands/conductor/revert.toml +++ b/commands/conductor/revert.toml @@ -87,7 +87,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai * **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. **Retrieve Rich Context from Metadata Log:** - * **CRITICAL:** For each validated commit SHA, you MUST open the `.conductor/metadata.json` file. + * **CRITICAL:** For each validated commit SHA, you MUST open the `conductor/metadata.json` file. * You MUST process this file efficiently due to its potential size. Instead of loading the entire file, you MUST read it **line by line in reverse order** (e.g., using `tac` or equivalent efficient method). * For each line, you MUST parse it as a JSON object. * You MUST then find the JSON entry where the `hash` value exactly matches the commit SHA. diff --git a/commands/conductor/setup.toml b/commands/conductor/setup.toml index bd1ea2f6..8437bcad 100644 --- a/commands/conductor/setup.toml +++ b/commands/conductor/setup.toml @@ -69,7 +69,7 @@ CRITICAL: When determining model complexity, ALWAYS select the "flash" model, re - **If Brownfield:** - 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 JSON file with the exact content: `[]` + - **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:** @@ -123,7 +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 JSON file with the exact content: `[]` + - **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. diff --git a/templates/vcs_workflows/git.md b/templates/vcs_workflows/git.md index ddecf152..01642625 100644 --- a/templates/vcs_workflows/git.md +++ b/templates/vcs_workflows/git.md @@ -37,7 +37,7 @@ git diff --name-only {{hash}} HEAD ```bash # Expects {{hash}} and {{message}} to be replaced. # Appends a JSON object to the metadata log. -echo "{\"hash\": \"{{hash}}\", \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\", \"message\": \"{{message}}\"}" >> .conductor/metadata.json +echo "{\"hash\": \"{{hash}}\", \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\", \"message\": \"{{message}}\"}" >> conductor/metadata.json ``` ### revert_commit diff --git a/templates/workflow.md b/templates/workflow.md index c3f422b1..13ba49e9 100644 --- a/templates/workflow.md +++ b/templates/workflow.md @@ -52,12 +52,10 @@ All tasks follow a strict lifecycle: 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 read the `conductor/metadata.json` log file, append the new entry to the JSON array, and write the updated array back to the file, ensuring the file remains a valid JSON array. + - **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 # Conceptual example of the underlying operation: - # 1. Read conductor/metadata.json -> [{"hash": "abc", "message": "msg1"}] - # 2. Add new entry -> [{"hash": "abc", "message": "msg1"}, {"hash": "def", "message": "msg2"}] - # 3. Write back to conductor/metadata.json + # echo '{"hash": "", "message": ""}' >> conductor/metadata.json ``` 10. **Get and Record Task Commit SHA:** @@ -123,7 +121,7 @@ All tasks follow a strict lifecycle: 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 read the `conductor/metadata.json` log file, append the new entry to the JSON array, and write the updated array back to the file. + - **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* by executing `get_latest_commit_hash` from `VCS_COMMANDS`. From 6dffea0e720297378cd4d8b5f4611b11463ba2e5 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Wed, 21 Jan 2026 01:22:38 +0000 Subject: [PATCH 09/10] feat(vcs): Enhance git.md with structured error handling Change-Id: I09969cecad4e31db6610db8be18954c07e3a3afb --- templates/vcs_workflows/git.md | 127 +++++++++++++++++++++++---------- 1 file changed, 90 insertions(+), 37 deletions(-) diff --git a/templates/vcs_workflows/git.md b/templates/vcs_workflows/git.md index 01642625..9593c9ad 100644 --- a/templates/vcs_workflows/git.md +++ b/templates/vcs_workflows/git.md @@ -1,59 +1,112 @@ # VCS Workflow Definition: Git -This file defines the specific shell commands for Conductor to use when operating within a Git repository. +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 -```bash -git init -``` +# 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 -```bash -# This command outputs a list of modified/untracked files. -# An empty output means the repository is clean. -git status --porcelain -``` +# 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 -```bash -# Lists all tracked files and other non-ignored files in the repo. -git ls-files --exclude-standard -co -``` +# 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 -```bash -git log -1 --format="%H" -``` +# 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 -```bash -# Expects {{hash}} to be replaced with the target commit hash. -git diff --name-only {{hash}} HEAD -``` +# 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 -```bash -# Expects {{hash}} and {{message}} to be replaced. -# Appends a JSON object to the metadata log. -echo "{\"hash\": \"{{hash}}\", \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\", \"message\": \"{{message}}\"}" >> conductor/metadata.json -``` +# 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 -```bash -# Expects {{hash}} to be replaced. -git revert --no-edit {{hash}} -``` +# 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 -```bash -# Expects {{file}} to be replaced. -git log -- {{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 -```bash -# Expects {{pattern}} to be replaced. -git log --grep="{{pattern}}" -``` \ No newline at end of file +# 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 From 9dab75f126a7721bdd2d92f2c855586663adb113 Mon Sep 17 00:00:00 2001 From: Mahima Shanware Date: Wed, 21 Jan 2026 17:02:38 +0000 Subject: [PATCH 10/10] refactor(conductor): Use get_commit_metadata command Replaces the manual parsing of the metadata log with the command. This simplifies the revert workflow by abstracting away the implementation details of how commit metadata is stored and retrieved, making it more robust and easier to maintain. This change is part of the larger effort to move to a VCS-agnostic metadata log. Change-Id: Id5d3dc09ed8c6ce5e3e44876625a4d3934a5fca4 --- commands/conductor/revert.toml | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/commands/conductor/revert.toml b/commands/conductor/revert.toml index 760a56fa..f4729a2f 100644 --- a/commands/conductor/revert.toml +++ b/commands/conductor/revert.toml @@ -87,11 +87,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai * **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. **Retrieve Rich Context from Metadata Log:** - * **CRITICAL:** For each validated commit SHA, you MUST open the `conductor/metadata.json` file. - * You MUST process this file efficiently due to its potential size. Instead of loading the entire file, you MUST read it **line by line in reverse order** (e.g., using `tac` or equivalent efficient method). - * For each line, you MUST parse it as a JSON object. - * You MUST then find the JSON entry where the `hash` value exactly matches the commit SHA. - * Once the matching entry is found, you MUST extract the value of the `message` key and store it as the `commit_summary`. + * **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 Associated Plan-Update Commits:**