chore(conductor): Add language support tracks (Lua and GDScript)

conductor/tracks.md

@@ -63,7 +63,7 @@ This file tracks all major tracks for the project. Each track has its own detail
 
 ---
 
-### C/C++ Language Support
+### Additional Language Support
 
 1. [ ] **Track: Tree-Sitter C/C++ MCP Tools**
    *Link: [./tracks/ts_cpp_tree_sitter_20260308/](./tracks/ts_cpp_tree_sitter_20260308/)*
@@ -73,6 +73,14 @@ This file tracks all major tracks for the project. Each track has its own detail
    *Link: [./tracks/gencpp_python_bindings_20260308/](./tracks/gencpp_python_bindings_20260308/)*
    *Goal: Bootstrap standalone Python project with CFFI bindings for gencpp C library. Provides foundation for richer C++ AST parsing in future (beyond tree-sitter syntax).*
 
+3. [ ] **Track: Tree-Sitter Lua MCP Tools**
+   *Link: [./tracks/tree_sitter_lua_mcp_tools_20260310/](./tracks/tree_sitter_lua_mcp_tools_20260310/)*
+   *Goal: Add Tree-Sitter Lua MCP tools for structural parsing, documentation extraction, and surgical editing.*
+
+4. [ ] **Track: GDScript Language Support Tools**
+   *Link: [./tracks/gdscript_godot_script_language_support_tools_20260310/](./tracks/gdscript_godot_script_language_support_tools_20260310/)*
+   *Goal: Add Tree-Sitter GDScript MCP tools for structural parsing, documentation extraction, and surgical editing.*
+
 ---
 
 ### Path Configuration
@@ -105,6 +113,10 @@ This file tracks all major tracks for the project. Each track has its own detail
    *Link: [./tracks/agent_personas_20260309/](./tracks/agent_personas_20260309/)*
    *Goal: Consolidate model settings, prompts, and tool presets into a unified "Persona" model with granular MMA assignment.*
 
+5. [ ] **Track: Advanced Workspace Docking & Layout Profiles**
+   *Link: [./tracks/workspace_profiles_20260310/](./tracks/workspace_profiles_20260310/)*
+   *Goal: Expand layout preset logic to allow users to save and switch between named workspace configurations.*
+
 ---
 
 ### Model Providers

conductor/tracks/gdscript_godot_script_language_support_tools_20260310/index.md

@@ -0,0 +1,5 @@
+# Track gdscript_godot_script_language_support_tools_20260310 Context
+
+- [Specification](./spec.md)
+- [Implementation Plan](./plan.md)
+- [Metadata](./metadata.json)

conductor/tracks/gdscript_godot_script_language_support_tools_20260310/metadata.json

@@ -0,0 +1,8 @@
+{
+  "track_id": "gdscript_godot_script_language_support_tools_20260310",
+  "type": "feature",
+  "status": "new",
+  "created_at": "2026-03-10T01:00:00Z",
+  "updated_at": "2026-03-10T01:00:00Z",
+  "description": "GDScript (godot script) language support tools"
+}

conductor/tracks/gdscript_godot_script_language_support_tools_20260310/plan.md

@@ -0,0 +1,25 @@
+# Implementation Plan: GDScript (Godot) MCP Tools
+
+## Phase 1: Grammar Integration & Base Parser
+- [ ] Task: Update project dependencies (e.g., `requirements.txt` or `pyproject.toml`) to include the GDScript tree-sitter binding.
+- [ ] Task: Write Tests: Verify the tree-sitter parser can successfully initialize the GDScript language and parse a simple `func _ready(): pass` string.
+- [ ] Task: Implement: Create `src/gdscript_parser.py` (or extend existing AST parsers) to handle the base GDScript tree-sitter initialization and generic node walking.
+- [ ] Task: Conductor - User Manual Verification 'Phase 1: Grammar Integration & Base Parser' (Protocol in workflow.md)
+
+## Phase 2: Structural & Context Tools
+- [ ] Task: Write Tests: Verify `gd_get_skeleton` and `gd_get_code_outline` against a complex GDScript file containing classes, `@export` vars, signals, and docstrings.
+- [ ] Task: Implement: Add `gd_get_skeleton` logic to extract signatures, Godot-specific keywords, and replace bodies with `pass`.
+- [ ] Task: Implement: Add `gd_get_code_outline` and `gd_get_docstring` logic to traverse the AST and map line numbers and comments.
+- [ ] Task: Conductor - User Manual Verification 'Phase 2: Structural & Context Tools' (Protocol in workflow.md)
+
+## Phase 3: Surgical Editing Tools
+- [ ] Task: Write Tests: Verify `gd_get_definition` returns the exact source text of a targeted function, and `gd_update_definition` replaces it accurately within a larger file.
+- [ ] Task: Implement: Add `gd_get_definition` logic using AST line/byte ranges.
+- [ ] Task: Implement: Add `gd_update_definition` and `gd_set_signature` logic to perform string replacement based on strict AST node boundaries.
+- [ ] Task: Conductor - User Manual Verification 'Phase 3: Surgical Editing Tools' (Protocol in workflow.md)
+
+## Phase 4: MCP Client Integration & Polish
+- [ ] Task: Write Tests: Verify the new tools are successfully registered and invokable via the `mcp_client.py` unified interface.
+- [ ] Task: Implement: Register the new `gd_*` functions as official tools in `src/mcp_client.py`.
+- [ ] Task: Implement: Ensure the caching layer (mtime invalidation) is correctly applied to the new GDScript parsing operations.
+- [ ] Task: Conductor - User Manual Verification 'Phase 4: MCP Client Integration & Polish' (Protocol in workflow.md)

conductor/tracks/gdscript_godot_script_language_support_tools_20260310/spec.md

@@ -0,0 +1,32 @@
+# Specification: GDScript (Godot) MCP Tools
+
+## Overview
+Expand the Conductor's AI context-gathering and surgical editing capabilities by introducing full Tree-Sitter parsing support for GDScript (Godot's native scripting language). This will bring GDScript to feature-parity with the existing Python MCP tools, enabling deep AST-driven structural mapping, documentation extraction, and precise code modification.
+
+## Functional Requirements
+- **Grammar Integration:**
+  - Introduce a stable GDScript Tree-Sitter grammar (`tree-sitter-gdscript`) to the project's parsing environment via Python bindings (or the most robust available method) to generate deterministic Abstract Syntax Trees for `.gd` files.
+- **Structural Parsing Tools:**
+  - **`gd_get_skeleton`:** Extract a high-level view of a GDScript file, containing all class declarations, signals, exported variables, and function signatures with their associated docstrings, replacing function bodies with `pass` or `...`.
+  - **`gd_get_code_outline`:** Generate a hierarchical text outline showing line ranges for major structural elements (classes, functions, macros).
+- **Documentation & Context Tools:**
+  - **`gd_get_docstring`:** Extract the block comment/docstring immediately preceding a function or class definition.
+  - **`gd_find_usages`:** Locate usages of specific GDScript symbols/functions across a file or directory using AST or strict regex boundaries.
+- **Surgical Editing Tools:**
+  - **`gd_get_definition`:** Extract the full source code of a specific GDScript function or class definition.
+  - **`gd_update_definition`:** Surgically replace the implementation of a specific GDScript function without relying on generic search-and-replace strings.
+  - **`gd_set_signature`:** Update only the signature (parameters/return type) of a GDScript function.
+
+## Non-Functional Requirements
+- **Performance:** Parsing and skeleton generation should be heavily cached (using `mtime` invalidation) to ensure near-instantaneous responses, matching the current Python tool performance.
+- **Robustness:** The parser must gracefully handle malformed GDScript code, returning as much structural information as possible rather than failing entirely.
+
+## Acceptance Criteria
+- [ ] A new suite of GDScript-specific tools (`gd_get_skeleton`, `gd_get_code_outline`, `gd_get_definition`, `gd_update_definition`) is available via the MCP Client.
+- [ ] Automated tests verify that `gd_get_skeleton` correctly identifies classes, inner classes, functions, and Godot-specific keywords (like `@export`, `signal`, `onready`).
+- [ ] `gd_update_definition` can successfully replace a multi-line function body while maintaining the surrounding file structure and indentation.
+- [ ] The `tree-sitter-gdscript` grammar is successfully integrated into the build/setup pipeline.
+
+## Out of Scope
+- Full language server protocol (LSP) features like deep type inference or cross-file variable renaming.
+- Automated code formatting or linting for GDScript (formatting relies on external ecosystem tools if needed).

conductor/tracks/tree_sitter_lua_mcp_tools_20260310/index.md

@@ -0,0 +1,5 @@
+# Track tree_sitter_lua_mcp_tools_20260310 Context
+
+- [Specification](./spec.md)
+- [Implementation Plan](./plan.md)
+- [Metadata](./metadata.json)

conductor/tracks/tree_sitter_lua_mcp_tools_20260310/metadata.json

@@ -0,0 +1,8 @@
+{
+  "track_id": "tree_sitter_lua_mcp_tools_20260310",
+  "type": "feature",
+  "status": "new",
+  "created_at": "2026-03-10T00:45:00Z",
+  "updated_at": "2026-03-10T00:45:00Z",
+  "description": "Add Tree-Sitter Lua MCP tools for structural parsing, documentation extraction, and surgical editing."
+}

conductor/tracks/tree_sitter_lua_mcp_tools_20260310/plan.md

@@ -0,0 +1,25 @@
+# Implementation Plan: Tree-Sitter Lua MCP Tools
+
+## Phase 1: Grammar Integration & Base Parser
+- [ ] Task: Update project dependencies (e.g., `requirements.txt` or `pyproject.toml`) to include `tree-sitter-lua` or equivalent.
+- [ ] Task: Write Tests: Verify the tree-sitter parser can successfully initialize the Lua language and parse a simple `local function test() end` string.
+- [ ] Task: Implement: Create `src/lua_parser.py` (or extend existing AST parsers) to handle the base Lua tree-sitter initialization and generic node walking.
+- [ ] Task: Conductor - User Manual Verification 'Phase 1: Grammar Integration & Base Parser' (Protocol in workflow.md)
+
+## Phase 2: Structural & Context Tools
+- [ ] Task: Write Tests: Verify `lua_get_skeleton` and `lua_get_code_outline` against a complex Lua file containing nested functions, tables, and block comments.
+- [ ] Task: Implement: Add `lua_get_skeleton` logic to extract signatures, table assignments (e.g., `Module.func = function()`), and replace bodies with `...`.
+- [ ] Task: Implement: Add `lua_get_code_outline` and `lua_get_docstring` logic to traverse the AST and map line numbers and comments.
+- [ ] Task: Conductor - User Manual Verification 'Phase 2: Structural & Context Tools' (Protocol in workflow.md)
+
+## Phase 3: Surgical Editing Tools
+- [ ] Task: Write Tests: Verify `lua_get_definition` returns the exact source text of a targeted function, and `lua_update_definition` replaces it accurately within a larger file.
+- [ ] Task: Implement: Add `lua_get_definition` logic using AST line/byte ranges.
+- [ ] Task: Implement: Add `lua_update_definition` and `lua_set_signature` logic to perform string replacement based on strict AST node boundaries.
+- [ ] Task: Conductor - User Manual Verification 'Phase 3: Surgical Editing Tools' (Protocol in workflow.md)
+
+## Phase 4: MCP Client Integration & Polish
+- [ ] Task: Write Tests: Verify the new tools are successfully registered and invokable via the `mcp_client.py` unified interface.
+- [ ] Task: Implement: Register the new `lua_*` functions as official tools in `src/mcp_client.py`.
+- [ ] Task: Implement: Ensure the caching layer (mtime invalidation) is correctly applied to the new Lua parsing operations.
+- [ ] Task: Conductor - User Manual Verification 'Phase 4: MCP Client Integration & Polish' (Protocol in workflow.md)

conductor/tracks/tree_sitter_lua_mcp_tools_20260310/spec.md

@@ -0,0 +1,32 @@
+# Specification: Tree-Sitter Lua MCP Tools
+
+## Overview
+Expand the Conductor's AI context-gathering and surgical editing capabilities by introducing full Tree-Sitter parsing support for the Lua programming language. This will bring Lua to feature-parity with the existing Python MCP tools, enabling deep AST-driven structural mapping, documentation extraction, and precise code modification.
+
+## Functional Requirements
+- **Grammar Integration:**
+  - Introduce `tree-sitter-lua` (or a suitable native equivalent) to the project's parsing environment to generate deterministic Abstract Syntax Trees for Lua files.
+- **Structural Parsing Tools:**
+  - **`lua_get_skeleton`:** Extract a high-level view of a Lua file, containing all table/module declarations and function signatures with their associated comments, replacing function bodies with `...`.
+  - **`lua_get_code_outline`:** Generate a hierarchical text outline showing line ranges for major structural elements (functions, loops, distinct blocks).
+- **Documentation & Context Tools:**
+  - **`lua_get_docstring` (or comment block):** Extract the block comment immediately preceding a function or module definition.
+  - **`lua_find_usages`:** Locate usages of specific Lua symbols/functions across a file or directory using AST or strict regex boundaries.
+- **Surgical Editing Tools:**
+  - **`lua_get_definition`:** Extract the full source code of a specific Lua function or table definition.
+  - **`lua_update_definition`:** Surgically replace the implementation of a specific Lua function without relying on generic search-and-replace strings.
+  - **`lua_set_signature`:** Update only the signature (parameters) of a Lua function.
+
+## Non-Functional Requirements
+- **Performance:** Parsing and skeleton generation should be heavily cached (using `mtime` invalidation) to ensure near-instantaneous responses, matching the current Python tool performance.
+- **Robustness:** The parser must gracefully handle malformed Lua code, returning as much structural information as possible rather than failing entirely.
+
+## Acceptance Criteria
+- [ ] A new suite of Lua-specific tools (`lua_get_skeleton`, `lua_get_code_outline`, `lua_get_definition`, `lua_update_definition`) is available via the MCP Client.
+- [ ] Automated tests verify that `lua_get_skeleton` correctly identifies local functions, global functions, and table-assigned methods.
+- [ ] `lua_update_definition` can successfully replace a multi-line function body while maintaining the surrounding file structure and indentation.
+- [ ] The `tree-sitter-lua` grammar is successfully integrated into the build/setup pipeline.
+
+## Out of Scope
+- Full language server protocol (LSP) features like deep type inference or cross-file variable renaming.
+- Automated code formatting or linting for Lua (formatting relies on external ecosystem tools if needed).

conductor/tracks/workspace_profiles_20260310/index.md

@@ -0,0 +1,5 @@
+# Track workspace_profiles_20260310 Context
+
+- [Specification](./spec.md)
+- [Implementation Plan](./plan.md)
+- [Metadata](./metadata.json)

conductor/tracks/workspace_profiles_20260310/metadata.json

@@ -0,0 +1,8 @@
+{
+  "track_id": "workspace_profiles_20260310",
+  "type": "feature",
+  "status": "new",
+  "created_at": "2026-03-10T00:30:00Z",
+  "updated_at": "2026-03-10T00:30:00Z",
+  "description": "Expand layout preset logic to allow users to save and switch between named workspace configurations."
+}

conductor/tracks/workspace_profiles_20260310/plan.md

@@ -0,0 +1,25 @@
+# Implementation Plan: Advanced Workspace Docking & Layout Profiles
+
+## Phase 1: Data Model & Persistence Engine
+- [ ] Task: Create a `WorkspaceProfile` dataclass in `src/models.py` to store INI string, `show_windows` dict, and panel states.
+- [ ] Task: Implement `WorkspaceManager` (similar to `PresetManager`) to handle saving/loading profiles from `config.toml` and `project.toml`.
+- [ ] Task: Write Tests: Verify the manager correctly merges global and project profiles and serializes the ImGui INI string properly.
+- [ ] Task: Conductor - User Manual Verification 'Phase 1: Data Model & Persistence Engine' (Protocol in workflow.md)
+
+## Phase 2: ImGui State Extraction & Restoration
+- [ ] Task: Implement methods in `src/gui_2.py` (or a helper module) to safely capture the current ImGui layout (`imgui.save_ini_settings_to_memory()`).
+- [ ] Task: Implement methods to safely restore layout (`imgui.load_ini_settings_from_memory()`) and apply the associated `show_windows` state.
+- [ ] Task: Write Tests: Verify using `live_gui` that saving a layout and loading it back does not cause crashes or assertion failures in the ImGui render loop.
+- [ ] Task: Conductor - User Manual Verification 'Phase 2: ImGui State Extraction & Restoration' (Protocol in workflow.md)
+
+## Phase 3: GUI Menu Integration
+- [ ] Task: Add a "Layout Profiles" menu under the main "Windows" or "View" menu bar in `src/gui_2.py`.
+- [ ] Task: Implement "Save Current Layout" modal (prompting for name and scope: Global/Project).
+- [ ] Task: Populate the menu with a dynamically generated list of available profiles to load.
+- [ ] Task: Conductor - User Manual Verification 'Phase 3: GUI Menu Integration' (Protocol in workflow.md)
+
+## Phase 4: Contextual Auto-Switch (Experimental)
+- [ ] Task: Add UI in "AI Settings" or "Operations Hub" to enable "Experimental: Auto-switch layout by Tier".
+- [ ] Task: Add UI to bind specific profiles to Tiers 1 through 4.
+- [ ] Task: Implement the event hook in `AppController` so that when the `active_tier` changes, the bound profile is automatically loaded if the feature is enabled.
+- [ ] Task: Conductor - User Manual Verification 'Phase 4: Contextual Auto-Switch (Experimental)' (Protocol in workflow.md)

conductor/tracks/workspace_profiles_20260310/spec.md

@@ -0,0 +1,31 @@
+# Specification: Advanced Workspace Docking & Layout Profiles
+
+## Overview
+Expand the existing GUI window management to support named "Workspace Profiles." This will allow users to save, manage, and instantly switch between complex multi-window, multi-viewport docking arrangements.
+
+## Functional Requirements
+- **Comprehensive State Capture:**
+  - A Workspace Profile must capture:
+    - ImGui layout data (positions, sizes, docking nodes) usually stored in `imgui.ini`.
+    - Window visibility toggles (the `show_windows` dict and popout panel booleans).
+    - Relevant internal panel state (e.g., active tabs, split sizes if applicable).
+- **Storage & Scope:**
+  - Profiles follow a **Global + Project** inheritance model (similar to prompt presets). Global profiles are stored in `config.toml`, while project-specific profiles are stored in `manual_slop.toml` and can override global ones.
+  - The system starts blank (no pre-loaded templates).
+- **Trigger Mechanisms:**
+  - **Manual Menu:** A dedicated "Layout Profiles" sub-menu in the main menu bar (under "Windows" or "View") to save, load, and manage profiles.
+  - **Contextual Auto-Switch (Experimental):** An opt-in setting that automatically switches to a designated profile based on the active MMA Tier or task context (e.g., switching to a "QA" layout when a Tier 4 worker spawns).
+
+## Non-Functional Requirements
+- **ImGui INI Management:** Safely loading and saving raw ImGui INI strings using `imgui.load_ini_settings_from_memory` and `imgui.save_ini_settings_to_memory` without corrupting the active render frame.
+- **Graceful Fallback:** If a profile references a window that no longer exists, the layout engine should recover gracefully without crashing.
+
+## Acceptance Criteria
+- [ ] A user can arrange windows, dock them, and save the current state as a named Workspace Profile.
+- [ ] Selecting a saved profile instantly re-arranges windows, updates visibility toggles, and restores internal tab states.
+- [ ] Profiles can be scoped globally or to a specific project.
+- [ ] An experimental toggle allows binding profiles to specific MMA Tiers for automatic switching.
+
+## Out of Scope
+- Creating default templates (users will build their own).
+- Synchronizing layouts across different monitor resolutions (ImGui docking handles this best-effort, but pixel-perfect restoration on different hardware is out of scope).