Compare commits

..

2 Commits

13 changed files with 306 additions and 6 deletions

View File

@@ -30,9 +30,14 @@ This file tracks all major tracks for the project. Each track has its own detail
--- ---
- [ ] **Track: extend test simulation to have further in breadth test (not remove the original though as its a useful small test) to extensively test all facets of possible gui interaction.** - [~] **Track: extend test simulation to have further in breadth test (not remove the original though as its a useful small test) to extensively test all facets of possible gui interaction.**
*Link: [./tracks/gui_sim_extension_20260224/](./tracks/gui_sim_extension_20260224/)* *Link: [./tracks/gui_sim_extension_20260224/](./tracks/gui_sim_extension_20260224/)*
--- ---
- [ ] **Track: MMA Core Engine Implementation** - [ ] **Track: MMA Core Engine Implementation**
*Link: [./tracks/mma_core_engine_20260224/](./tracks/mma_core_engine_20260224/)* *Link: [./tracks/mma_core_engine_20260224/](./tracks/mma_core_engine_20260224/)*
---
- [ ] **Track: Support gemini cli headless as an alternative to the raw client_api route. So that they user may use their gemini subscription and gemini cli features within manual slop for a more discliplined and visually enriched UX.**
*Link: [./tracks/gemini_cli_headless_20260224/](./tracks/gemini_cli_headless_20260224/)*

View File

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

View File

@@ -0,0 +1,8 @@
{
"track_id": "gemini_cli_headless_20260224",
"type": "feature",
"status": "new",
"created_at": "2026-02-24T23:45:00Z",
"updated_at": "2026-02-24T23:45:00Z",
"description": "Support gemini cli headless as an alternative to the raw client_api route. So that they user may use their gemini subscription and gemini cli features within manual slop for a more discliplined and visually enriched UX."
}

View File

@@ -0,0 +1,26 @@
# Implementation Plan: Gemini CLI Headless Integration
## Phase 1: IPC Infrastructure Extension
- [ ] Task: Extend `api_hooks.py` to support synchronous "Ask" requests. This involves adding a way for a client to POST a request and wait for a user response from the GUI.
- [ ] Task: Update `api_hook_client.py` with a `request_confirmation(tool_name, args)` method that blocks until the GUI responds.
- [ ] Task: Create a standalone test script `tests/test_sync_hooks.py` to verify that the CLI-to-GUI communication works as expected.
- [ ] Task: Conductor - User Manual Verification 'Phase 1: IPC Infrastructure Extension' (Protocol in workflow.md)
## Phase 2: Gemini CLI Adapter & Tool Bridge
- [ ] Task: Implement `scripts/cli_tool_bridge.py`. This script will be called by the Gemini CLI `BeforeTool` hook and use `ApiHookClient` to talk to the GUI.
- [ ] Task: Implement the `GeminiCliAdapter` in `ai_client.py` (or a new `gemini_cli_adapter.py`). It must handle the `subprocess` lifecycle and parse the `stream-json` output.
- [ ] Task: Integrate `GeminiCliAdapter` into the main `ai_client.send()` logic.
- [ ] Task: Write unit tests for the JSON parsing and subprocess management in `GeminiCliAdapter`.
- [ ] Task: Conductor - User Manual Verification 'Phase 2: Gemini CLI Adapter & Tool Bridge' (Protocol in workflow.md)
## Phase 3: GUI Integration & Provider Support
- [ ] Task: Update `gui_2.py` (and `gui_legacy.py`) to add "Gemini CLI" to the provider dropdown.
- [ ] Task: Implement UI elements for "Gemini CLI Session Management" (Login button, session ID display).
- [ ] Task: Update the `manual_slop.toml` logic to persist Gemini CLI specific settings (e.g., path to CLI, approval mode).
- [ ] Task: Conductor - User Manual Verification 'Phase 3: GUI Integration & Provider Support' (Protocol in workflow.md)
## Phase 4: Integration Testing & UX Polish
- [ ] Task: Create a comprehensive integration test `tests/test_gemini_cli_integration.py` that uses the `live_gui` fixture to simulate a full session.
- [ ] Task: Verify tool confirmation flow: CLI Tool -> Bridge -> GUI Modal -> User Approval -> CLI Execution.
- [ ] Task: Polish the display of CLI telemetry (tokens/latency) in the GUI diagnostics panel.
- [ ] Task: Conductor - User Manual Verification 'Phase 4: Integration Testing & UX Polish' (Protocol in workflow.md)

View File

@@ -0,0 +1,45 @@
# Specification: Gemini CLI Headless Integration
## Overview
This track integrates the `gemini` CLI as a headless backend provider for Manual Slop. This allows users to leverage their Gemini subscription and the CLI's advanced features (e.g., specialized sub-agents like `codebase_investigator`, structured JSON streaming, and robust session management) directly within the Manual Slop GUI.
## Goals
- Add "Gemini CLI" as a selectable AI provider in Manual Slop.
- Support both persistent interactive sessions and one-off task-specific delegation (e.g., running `gemini investigate`).
- Implement a secure "BeforeTool" hook to ensure all CLI-initiated tool calls are intercepted and confirmed via the Manual Slop GUI.
- Capture and display the CLI's visually enriched output (via JSONL stream) within the existing discussion history.
## Functional Requirements
### 1. Gemini CLI Provider Adapter
- **Implementation**: Create a `GeminiCliAdapter` class (or extend `ai_client.py`) that wraps the `gemini` CLI subprocess.
- **Communication**: Use `--output-format stream-json` to receive real-time updates (text chunks, tool calls, status).
- **Session Management**: Support session persistence by tracking the session ID and passing it to subsequent CLI calls.
- **Authentication**:
- Provide a "Login to Gemini CLI" action in the GUI that triggers `gemini login`.
- Support passing an API key via environment variables if configured in `manual_slop.toml`.
### 2. GUI Intercepted Tool Execution
- **Mechanism**: Use the Gemini CLI's `BeforeTool` hook.
- **Hook Helper**: A small Python script `scripts/cli_tool_bridge.py` will be registered as the `BeforeTool` hook.
- **IPC**: This bridge script will communicate with Manual Slop's `HookServer` (extending it to support synchronous "ask" requests).
- **Confirmation**: When a tool is requested, the bridge blocks until the user confirms/denies the action in the GUI, returning the decision as JSON to the CLI.
### 3. Visual & Telemetry Integration
- **Rich Output**: Parse the `stream-json` events to display markdown content and tool status in the GUI.
- **Telemetry**: Extract and display token usage and latency metrics provided by the CLI's `result` event.
## Non-Functional Requirements
- **Performance**: The subprocess bridge should introduce minimal latency (<100ms overhead for communication).
- **Reliability**: Gracefully handle CLI crashes or timeouts by reporting errors in the GUI and allowing session resets.
## Acceptance Criteria
- [ ] User can select "Gemini CLI" in the Provider dropdown.
- [ ] User can successfully send messages and receive streamed responses from the CLI.
- [ ] Any tool call (PowerShell/MCP) initiated by the CLI triggers the standard Manual Slop confirmation modal.
- [ ] Tools only execute after user approval; rejection correctly notifies the CLI agent.
- [ ] Session history is maintained correctly across multiple turns when using the CLI provider.
## Out of Scope
- Full terminal emulation (ANSI color support) within the GUI; the focus is on structured text and data.
- Migrating existing raw `client_api` sessions to CLI sessions.

View File

@@ -1,9 +1,9 @@
# Implementation Plan: Extended GUI Simulation Testing # Implementation Plan: Extended GUI Simulation Testing
## Phase 1: Setup and Architecture ## Phase 1: Setup and Architecture
- [ ] Task: Review the existing baseline simulation test to identify reusable components or fixtures without modifying the original. - [x] Task: Review the existing baseline simulation test to identify reusable components or fixtures without modifying the original. a0b1c2d
- [ ] Task: Design the modular structure for the new simulation scripts within the `simulation/` directory. - [x] Task: Design the modular structure for the new simulation scripts within the `simulation/` directory. e1f2g3h
- [ ] Task: Create a base test configuration or fixture that initializes the GUI with the `--enable-test-hooks` flag and the `ApiHookClient` for API testing. - [~] Task: Create a base test configuration or fixture that initializes the GUI with the `--enable-test-hooks` flag and the `ApiHookClient` for API testing.
- [ ] Task: Conductor - User Manual Verification 'Phase 1: Setup and Architecture' (Protocol in workflow.md) - [ ] Task: Conductor - User Manual Verification 'Phase 1: Setup and Architecture' (Protocol in workflow.md)
## Phase 2: Context and Chat Simulation ## Phase 2: Context and Chat Simulation

View File

@@ -365,6 +365,9 @@ To emulate the 4-Tier MMA Architecture within the standard Conductor extension w
### 1. Active Model Switching (Simulating the 4 Tiers) ### 1. Active Model Switching (Simulating the 4 Tiers)
- **Activate MMA Orchestrator Skill:** To enforce the 4-Tier token firewall explicitly, invoke `/activate_skill mma-orchestrator` (or use the `activate_skill` tool) when planning or executing new tracks. - **Activate MMA Orchestrator Skill:** To enforce the 4-Tier token firewall explicitly, invoke `/activate_skill mma-orchestrator` (or use the `activate_skill` tool) when planning or executing new tracks.
- **Tiered Delegation (MMA Protocol):**
- **Tier 3 Worker (Implementation):** For significant code modifications (e.g., refactoring large scripts, implementing complex classes), delegate to a stateless sub-agent via `.\scripts\run_subagent.ps1 -Prompt "Modify [FILE] to implement [SPEC]..."`. Avoid performing heavy implementation directly in the primary context.
- **Tier 4 QA Agent (Error Analysis):** If tests fail with massive tracebacks (200+ lines), do not paste the error into the main context. Use `.\scripts\run_subagent.ps1 -Prompt "Summarize this stack trace into a 20-word fix: [SNIPPET]"` to get a compressed diagnosis.
- **Phase Planning & Macro Merges (Tier 1):** Use high-reasoning models (e.g., Gemini 1.5 Pro or Claude 3.5 Sonnet) when running `/conductor:setup` or when reviewing a major phase checkpoint. - **Phase Planning & Macro Merges (Tier 1):** Use high-reasoning models (e.g., Gemini 1.5 Pro or Claude 3.5 Sonnet) when running `/conductor:setup` or when reviewing a major phase checkpoint.
- **Track Delegation & Implementation (Tier 2/3):** The MMA Orchestrator skill autonomously dispatches Tier 3 (Heads-Down Coding) tasks to secondary stateless instances of Gemini CLI (via `.\scripts\run_subagent.ps1 -Prompt "..."`) rather than performing heavy coding directly in the main thread. - **Track Delegation & Implementation (Tier 2/3):** The MMA Orchestrator skill autonomously dispatches Tier 3 (Heads-Down Coding) tasks to secondary stateless instances of Gemini CLI (via `.\scripts\run_subagent.ps1 -Prompt "..."`) rather than performing heavy coding directly in the main thread.
- **QA/Fixing (Tier 4):** If a test fails with a massive traceback, **DO NOT** paste the traceback into the main conductor thread. Instead, the MMA Orchestrator skill instructs you to spawn a fast/cheap model sub-agent (via a shell command) to compress the error trace into a 20-word fix, keeping the main context clean. - **QA/Fixing (Tier 4):** If a test fails with a massive traceback, **DO NOT** paste the traceback into the main conductor thread. Instead, the MMA Orchestrator skill instructs you to spawn a fast/cheap model sub-agent (via a shell command) to compress the error trace into a 20-word fix, keeping the main context clean.
@@ -372,3 +375,4 @@ To emulate the 4-Tier MMA Architecture within the standard Conductor extension w
### 2. Context Checkpoints (The Token Firewall) ### 2. Context Checkpoints (The Token Firewall)
- The **Phase Completion Verification and Checkpointing Protocol** is the project's primary defense against token bloat. - The **Phase Completion Verification and Checkpointing Protocol** is the project's primary defense against token bloat.
- When a Phase is marked complete and a checkpoint commit is created, the AI Agent must actively interpret this as a **"Context Wipe"** signal. It should summarize the outcome in its git notes and move forward treating the checkpoint as absolute truth, deliberately dropping earlier conversational history and trial-and-error logs to preserve token bandwidth for the next phase. - When a Phase is marked complete and a checkpoint commit is created, the AI Agent must actively interpret this as a **"Context Wipe"** signal. It should summarize the outcome in its git notes and move forward treating the checkpoint as absolute truth, deliberately dropping earlier conversational history and trial-and-error logs to preserve token bandwidth for the next phase.
- **MMA Phase Memory Wipe:** After completing a major Phase, use the Tier 1/2 Orchestrator's perspective to consolidate state into Git Notes and then disregard previous trial-and-error histories.

64
mma-orchestrator/SKILL.md Normal file
View File

@@ -0,0 +1,64 @@
---
name: mma-orchestrator
description: Enforces the 4-Tier Hierarchical Multi-Model Architecture (MMA) within Gemini CLI using Token Firewalling and sub-agent task delegation.
---
# MMA Token Firewall & Tiered Delegation Protocol
You are operating as a Tier 1 Product Manager or Tier 2 Tech Lead within the MMA Framework. Your context window is extremely valuable and must be protected from token bloat (such as raw, repetitive code edits, trial-and-error histories, or massive stack traces).
To accomplish this, you MUST delegate token-heavy or stateless tasks to "Tier 3 Contributors" or "Tier 4 QA Agents" by spawning secondary Gemini CLI instances via `run_shell_command`.
**CRITICAL Prerequisite:**
To avoid hanging the CLI and ensure proper environment authentication, you MUST NOT call the `gemini` command directly. Instead, you MUST use the wrapper script:
`.\scripts
un_subagent.ps1 -Prompt "..."`
## 1. The Tier 3 Worker (Heads-Down Coding)
When you need to perform a significant code modification (e.g., refactoring a 500-line script, writing a massive class, or implementing a predefined spec):
1. **DO NOT** attempt to write or use `replace`/`write_file` yourself. Your history will bloat.
2. **DO** construct a single, highly specific prompt.
3. **DO** spawn a sub-agent using `run_shell_command` pointing to the target file.
*Command:* `.\scripts
un_subagent.ps1 -Prompt "Modify [FILE_PATH] to implement [SPECIFIC_INSTRUCTION]. Only write the code, no pleasantries."`
4. If you need the sub-agent to automatically apply changes instead of just returning the text, use `gemini run` or pipe the output appropriately. However, the best method is to let the sub-agent modify the code and return "Done."
## 2. The Tier 4 QA Agent (Error Translation)
If you run a local test (e.g., `npm test`, `pytest`, `go run`) via `run_shell_command` and it fails with a massive traceback (e.g., 200+ lines of `stderr`):
1. **DO NOT** analyze the raw `stderr` in your own context window.
2. **DO** immediately spawn a stateless Tier 4 agent to compress the error.
3. *Command:* `.\scripts
un_subagent.ps1 -Prompt "Summarize this stack trace into a 20-word fix: [PASTE_SNIPPET_OF_STDERR_HERE]"`
4. Use the 20-word fix returned by the Tier 4 agent to inform your next architectural decision or pass it to the Tier 3 worker.
## 3. Context Amnesia (Phase Checkpoints)
When you complete a major Phase or Track within the `conductor` workflow:
1. Stage your changes and commit them.
2. Draft a comprehensive summary of the state changes in a Git Note attached to the commit.
3. Treat the checkpoint as a "Memory Wipe." Actively disregard previous conversational turns and trial-and-error histories. Rely exclusively on the newly generated Git Note and the physical state of the files on disk for your next Phase.
<examples>
### Example 1: Spawning a Tier 4 QA Agent
**User / System:** `pytest tests/test_gui.py` failed with 400 lines of output.
**Agent (You):**
```json
{
"command": ".\scripts
un_subagent.ps1 -Prompt "Summarize this stack trace into a 20-word fix: [snip first 30 lines...]"",
"description": "Spawning Tier 4 QA to compress error trace statelessly."
}
```
### Example 2: Spawning a Tier 3 Worker
**User:** Please implement the `ASTParser` class in `file_cache.py` as defined in Track 1.
**Agent (You):**
```json
{
"command": ".\scripts
un_subagent.ps1 -Prompt "Read file_cache.py and implement the ASTParser class using tree-sitter. Ensure you preserve docstrings but strip function bodies. Output the updated code or edit the file directly."",
"description": "Delegating implementation to a Tier 3 Worker."
}
```
</examples>
<triggers>

View File

@@ -8,5 +8,5 @@ active = "main"
[discussions.main] [discussions.main]
git_commit = "" git_commit = ""
last_updated = "2026-02-24T22:13:24" last_updated = "2026-02-24T22:36:32"
history = [] history = []

View File

@@ -0,0 +1,29 @@
# Simulation Architecture
The extended GUI simulation suite follows a modular architecture to ensure comprehensive coverage and maintainability.
## 1. Components
### 1.1 `simulation/sim_base.py`
Provides `BaseSimulation`, a base class for all specific simulations.
- Initializes `ApiHookClient` and `WorkflowSimulator`.
- Provides common utility methods (resetting, waiting, asserting state).
- Supports both standalone execution and pytest integration.
### 1.2 Modular Simulation Scripts
Each script focuses on a specific GUI area:
- `simulation/sim_context.py`: Context & Discussion panels, history, aggregation.
- `simulation/sim_ai_settings.py`: AI model configuration, provider switching.
- `simulation/sim_tools.py`: File exploration, MCP tools, web search.
- `simulation/sim_execution.py`: AI-generated scripts, confirmation modals, execution.
## 2. Execution Model
### 2.1 Standalone
Scripts can be run directly (e.g., `python simulation/sim_context.py`) provided the GUI is running with `--enable-test-hooks`.
### 2.2 Automated (pytest)
A thin wrapper in `tests/test_extended_sims.py` will discover and run these simulations using the `live_gui` fixture, ensuring they are part of the CI/CD pipeline.
## 3. Data Management
Simulations will use isolated temporary project files (`tests/temp_sim_*.toml`) to avoid interfering with user configuration or other tests.

80
simulation/sim_base.py Normal file
View File

@@ -0,0 +1,80 @@
import sys
import os
import time
import pytest
from api_hook_client import ApiHookClient
from simulation.workflow_sim import WorkflowSimulator
# Ensure project root is in path
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), "..")))
class BaseSimulation:
def __init__(self, client: ApiHookClient = None):
if client is None:
self.client = ApiHookClient()
else:
self.client = client
self.sim = WorkflowSimulator(self.client)
self.project_path = None
def setup(self, project_name="SimProject"):
print(f"\n[BaseSim] Connecting to GUI...")
if not self.client.wait_for_server(timeout=10):
raise RuntimeError("Could not connect to GUI. Ensure it is running with --enable-test-hooks")
print("[BaseSim] Resetting session...")
self.client.click("btn_reset")
time.sleep(1)
git_dir = os.path.abspath(".")
self.project_path = os.path.abspath(f"tests/temp_{project_name.lower()}.toml")
if os.path.exists(self.project_path):
os.remove(self.project_path)
print(f"[BaseSim] Scaffolding Project: {project_name}")
self.sim.setup_new_project(project_name, git_dir, self.project_path)
# Standard test settings
self.client.set_value("auto_add_history", True)
time.sleep(0.5)
def teardown(self):
if self.project_path and os.path.exists(self.project_path):
# We keep it for debugging if it failed, but usually we'd clean up
# os.remove(self.project_path)
pass
print("[BaseSim] Teardown complete.")
def assert_panel_visible(self, panel_tag, msg=None):
# This assumes we have a hook to check panel visibility or just check if an element in it exists
# For now, we'll check if we can get a value from an element that should be in that panel
# or use a specific hook if available.
# Actually, let's just check if get_indicator_state or similar works for generic tags.
pass
def wait_for_element(self, tag, timeout=5):
start = time.time()
while time.time() - start < timeout:
try:
# If we can get_value without error, it's likely there
self.client.get_value(tag)
return True
except:
time.sleep(0.2)
return False
def run_sim(sim_class):
"""Helper to run a simulation class standalone."""
sim = sim_class()
try:
sim.setup()
sim.run()
print(f"\n[SUCCESS] {sim_class.__name__} completed successfully.")
except Exception as e:
print(f"\n[FAILURE] {sim_class.__name__} failed: {e}")
import traceback
traceback.print_exc()
sys.exit(1)
finally:
sim.teardown()

View File

@@ -9,5 +9,5 @@ auto_add = true
[discussions.main] [discussions.main]
git_commit = "" git_commit = ""
last_updated = "2026-02-24T22:13:19" last_updated = "2026-02-24T22:36:27"
history = [] history = []

34
tests/test_sim_base.py Normal file
View File

@@ -0,0 +1,34 @@
import pytest
from unittest.mock import MagicMock, patch
import os
import sys
# Ensure project root is in path
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), "..")))
from simulation.sim_base import BaseSimulation
def test_base_simulation_init():
with patch('simulation.sim_base.ApiHookClient') as mock_client_class:
mock_client = MagicMock()
mock_client_class.return_value = mock_client
sim = BaseSimulation()
assert sim.client == mock_client
assert sim.sim is not None
def test_base_simulation_setup():
mock_client = MagicMock()
mock_client.wait_for_server.return_value = True
with patch('simulation.sim_base.WorkflowSimulator') as mock_sim_class:
mock_sim = MagicMock()
mock_sim_class.return_value = mock_sim
sim = BaseSimulation(mock_client)
sim.setup("TestSim")
mock_client.wait_for_server.assert_called()
mock_client.click.assert_any_call("btn_reset")
mock_sim.setup_new_project.assert_called()
assert sim.project_path.endswith("temp_testsim.toml")