fix(setup): optimize project discovery and file triage to prevent hangs

README.md

@@ -43,6 +43,7 @@ When you run `/conductor:setup`, Conductor helps you define the core components
 - **Workflow**: Set team preferences (e.g. TDD, commit strategy). Uses [workflow.md](templates/workflow.md) as a customizable template.
 
 **Generated Artifacts:**
+- `conductor/index.md`
 - `conductor/product.md`
 - `conductor/product-guidelines.md`
 - `conductor/tech-stack.md`

commands/conductor/implement.toml

@@ -27,7 +27,11 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 2.  **Locate and Parse Tracks Registry:**
     -   Resolve the **Tracks Registry**.
-    -   Read and parse this file. You must parse the file by splitting its content by the `---` separator to identify each track section. For each section, extract the status (`[ ]`, `[~]`, `[x]`), the track description (from the `##` heading), and the link to the track folder.
+    -   Read and parse this file. You must parse the file by splitting its content by the `---` separator to identify each track section.
+    -   **For each section, extract:**
+        -   **Status:** Identify the status (`[ ]`, `[~]`, `[x]`) from the track entry.
+        -   **Track Description:** Identify the description. Look for lines matching either the standard format `- [ ] **Track: <Description>**` OR the heading format `## [ ] Track: <Description>`.
+        -   **Link:** Extract the link to the track folder (e.g., `[./path/](./path/)` or similar).
     -   **CRITICAL:** If no track sections are found after parsing, announce: "The tracks file is empty or malformed. No tracks to implement." and halt.
 
 3.  **Continue:** Immediately proceed to the next step to select a track.
@@ -73,7 +77,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 2.  **Update Status to 'In Progress':**
     -   Before beginning any work, you MUST update the status of the selected track in the **Tracks Registry** file.
-    -   This requires finding the specific heading for the track (e.g., `## [ ] Track: <Description>`) and replacing it with the updated status (e.g., `## [~] Track: <Description>`) in the **Tracks Registry** file you identified earlier.
+    -   This requires finding the specific entry for the track (e.g., `## [ ] Track: <Description>` or `- [ ] **Track: <Description>**`) and replacing it with the updated status (e.g., `## [~] Track: <Description>` or `- [~] **Track: <Description>**`) in the **Tracks Registry** file you identified earlier.
 
 3.  **Load Track Context:**
     a. **Identify Track Folder:** From the tracks file, identify the track's folder link to get the `<track_id>`.
@@ -91,7 +95,7 @@ CRITICAL: You must validate the success of every tool call. If any tool call fai
 
 5.  **Finalize Track:**
     -   After all tasks in the track's local **Implementation Plan** are completed, you MUST update the track's status in the **Tracks Registry**.
-    -   This requires finding the specific heading for the track (e.g., `## [~] Track: <Description>`) and replacing it with the completed status (e.g., `## [x] Track: <Description>`).
+    -   This requires finding the specific entry for the track (e.g., `## [~] Track: <Description>` or `- [~] **Track: <Description>**`) and replacing it with the completed status (e.g., `## [x] Track: <Description>` or `- [x] **Track: <Description>**`).
     -   **Commit Changes:** Stage the **Tracks Registry** file and commit with the message `chore(conductor): Mark track '<track_description>' as complete`.
     -   Announce that the track is fully complete and the tracks file has been updated.
 

commands/conductor/setup.toml

@@ -60,10 +60,10 @@ PLAN MODE PROTOCOL: This setup process runs entirely within Plan Mode. While in
 
 ### 2.0 Project Inception
 1.  **Detect Project Maturity:**
-    -   **Classify Project:** Determine if the project is "Brownfield" (Existing) or "Greenfield" (New) based on the following indicators:
+    -   **Classify Project:** Determine if the project is "Brownfield" (Existing) or "Greenfield" (New) based on the following indicators. **CRITICAL: Limit your search to the root and one level deep (maxdepth 2) to avoid performance issues in large repositories.**
     -   **Brownfield Indicators:**
-        -   Check for dependency manifests: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, `Cargo.toml`.
-        -   Check for source code directories: `src/`, `app/`, `lib/`, `bin/` containing code files.
+        -   Check for dependency manifests at the root or one level deep: `package.json`, `pom.xml`, `requirements.txt`, `go.mod`, `Cargo.toml`.
+        -   Check for common source code directories at the root: `src/`, `app/`, `lib/`, `bin/`.
         -   If a `.git` directory exists, execute `git status --porcelain`. Ignore changes within the `conductor/` directory. If there are *other* uncommitted changes, it may be Brownfield.
         -   If ANY of the primary indicators (manifests or source code directories) are found, classify as **Brownfield**.
     -   **Greenfield Condition:**
@@ -99,10 +99,10 @@ PLAN MODE PROTOCOL: This setup process runs entirely within Plan Mode. While in
 
             -   **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'`.
+                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 an efficient `find` command that reads the ignore files and prunes the corresponding paths (limit depth to 3).
+                3.  **Fallback to Manual Ignores:** ONLY if neither `.geminiignore` nor `.gitignore` exist, you should fall back to manually ignoring common directories using an efficient, depth-limited command. **CRITICAL: Avoid recursive listings like `ls -R` or `Get-ChildItem -Recurse` without strict depth limits or pruning in large projects.** Example (PowerShell): `Get-ChildItem -Path . -Depth 2 -Exclude "node_modules", ".git", "build", "dist", "bin", "target", ".idea", ".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.
+                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` or PowerShell equivalents) 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.

templates/code_styleguides/cpp.md

@@ -102,9 +102,8 @@
 - **Sizeof:** Prefer `sizeof(varname)` over `sizeof(type)`.
 - **Friends:** Allowed, usually defined in the same file.
 - **Boost:** Use only approved libraries (e.g., Call Traits, Compressed Pair, BGL, Property Map, Iterator, etc.).
-- **Aliases:** Use `using` instead of `typedef`. Public aliases must be documented.
+- **Aliases:** Use `using` instead of `typedef`. Public aliases must be documented, and intent should be clear. Do not use in public API solely for convenience.
 - **Ownership:** Single fixed owner. Transfer via smart pointers.
-- **Aliases:** Document intent. Don't use in public API for convenience. `using` > `typedef`.
 - **Switch:** Always include `default`. Use `[[fallthrough]]` for explicit fallthrough.
 - **Comments:** Document File, Class, Function (params/return). Use `//` or `/* */`. Implementation comments for tricky code. `TODO(user):` format.