wrong archive location

conductor/tracks/_archived/documentation_refresh_20260224/index.md

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

conductor/tracks/_archived/documentation_refresh_20260224/metadata.json

@@ -1,8 +0,0 @@
-{
-  "track_id": "documentation_refresh_20260224",
-  "type": "chore",
-  "status": "new",
-  "created_at": "2026-02-24T18:35:00Z",
-  "updated_at": "2026-02-24T18:35:00Z",
-  "description": "Update ./docs/* & ./Readme.md, review ./MainContext.md significance (should we keep it..)."
-}

conductor/tracks/_archived/documentation_refresh_20260224/plan.md

@@ -1,38 +0,0 @@
-# Implementation Plan: Deep Architectural Documentation Refresh
-
-## Phase 1: Context Cleanup & Research
-- [x] Task: Audit references to `MainContext.md` across the project.
-- [x] Task: Delete `MainContext.md` and update any identified references.
-- [x] Task: Execute `py_get_skeleton` and `py_get_code_outline` for `events.py`, `api_hooks.py`, `api_hook_client.py`, and `gui_2.py` to create a technical map for the guides.
-- [x] Task: Analyze the `live_gui` fixture in `tests/conftest.py` and the simulation loop in `tests/visual_sim_mma_v2.py`.
-
-## Phase 2: Core Architecture Deep Dive
-Update `docs/guide_architecture.md` with expert-level detail.
-- [x] Task: Document the Dual-Threaded App Lifetime: Main GUI loop vs. Daemon execution threads.
-- [x] Task: Detail the `AsyncEventQueue` and `EventEmitter` roles in the decoupling strategy.
-- [x] Task: Explain the `_pending_gui_tasks` synchronization mechanism for bridging the Hook Server and GUI.
-- [x] Task: Document the "Linear Execution Clutch" and its deterministic state machine.
-- [x] Task: Verify the architectural descriptions against the actual implementation.
-- [x] Task: Conductor - User Manual Verification 'Phase 2: Core Architecture Deep Dive' (Protocol in workflow.md)
-
-## Phase 3: Hook System & Tooling Technical Reference
-Update `docs/guide_tools.md` to include low-level API details.
-- [x] Task: Create a comprehensive API reference for all `HookServer` endpoints.
-- [x] Task: Document the `ApiHookClient` implementation, including retries and polling strategies.
-- [x] Task: Update the MCP toolset guide with current native tool implementations.
-- [x] Task: Document the `ask/respond` IPC flow for "Human-in-the-Loop" confirmations.
-- [x] Task: Conductor - User Manual Verification 'Phase 3: Hook System & Tooling Technical Reference' (Protocol in workflow.md)
-
-## Phase 4: Verification & Simulation Framework
-Create the new `docs/guide_simulations.md` guide.
-- [x] Task: Detail the Live GUI testing infrastructure: `--enable-test-hooks` and the `live_gui` fixture.
-- [x] Task: Breakdown the Simulation Lifecycle: Startup, Polling, Interaction, and Assertion.
-- [x] Task: Document the mock provider strategy using `tests/mock_gemini_cli.py`.
-- [x] Task: Provide examples of visual verification tests (e.g., MMA lifecycle).
-- [x] Task: Conductor - User Manual Verification 'Phase 4: Verification & Simulation Framework' (Protocol in workflow.md)
-
-## Phase 5: README & Roadmap Update
-- [x] Task: Update `Readme.md` with current setup (`uv`, `credentials.toml`) and vision.
-- [x] Task: Perform a project-wide link validation of all Markdown files.
-- [x] Task: Verify the high-density information style across all documentation.
-- [x] Task: Conductor - User Manual Verification 'Phase 5: README & Roadmap Update' (Protocol in workflow.md)

conductor/tracks/_archived/documentation_refresh_20260224/spec.md

@@ -1,45 +0,0 @@
-# Track Specification: Deep Architectural Documentation Refresh
-
-## Overview
-This track implements a high-density, expert-level documentation suite for the Manual Slop project. The documentation style is strictly modeled after the **pedagogical and narrative standards** of `gencpp` and `VEFontCache-Odin`. It moves beyond simple "User Guides" to provide a **"USA Graphics Company"** architectural reference: high information density, tactical technical transparency, and a narrative intent that guides a developer from high-level philosophy to low-level implementation.
-
-## Pedagogical Goals
-1.  **Narrative Intent:** Documentation must transition the reader through a logical learning journey: **Philosophy/Mental Model -> Architectural Boundaries -> Implementation Logic -> Verification/Simulation.**
-2.  **High Information Density:** Eliminate conversational filler and "fluff." Every sentence must provide architectural signal (state transitions, data flows, constraints).
-3.  **Technical Transparency:** Document the "How" and "Why" behind design decisions (e.g., *Why* the dual-threaded `Asyncio` loop? *How* does the "Execution Clutch" bridge the thread gap?).
-4.  **Architectural Mapping:** Use precise symbol names (`AsyncEventQueue`, `_pending_gui_tasks`, `HookServer`) to map the documentation directly to the source code.
-5.  **Multi-Layered Depth:** Each major component (Architecture, Tools, Simulations) must have its own dedicated, expert-level guide. No consolidation into single, shallow files.
-
-## Functional Requirements (Documentation Areas)
-
-### 1. Core Architecture (`docs/guide_architecture.md`)
--   **System Philosophy:** The "Decoupled State Machine" mental model.
--   **Application Lifetime:** The multi-threaded boot sequence and the "Dual-Flush" persistence model.
--   **The Task Pipeline:** Detailed producer-consumer synchronization between the GUI (Main) and AI (Daemon) threads.
--   **The Execution Clutch (HITL):** Detailed state machine for human-in-the-loop interception and payload mutation.
-
-### 2. Tooling & IPC Reference (`docs/guide_tools.md`)
--   **MCP Bridge:** Low-level security constraints and filesystem sandboxing.
--   **Hook API:** A full technical reference for the REST/IPC interface (endpoints, payloads, diagnostics).
--   **IPC Flow:** The `ask/respond` sequence for synchronous human-in-the-loop requests.
-
-### 3. Verification & Simulation Framework (`docs/guide_simulations.md`)
--   **Infrastructure:** The `--enable-test-hooks` flag and the `live_gui` pytest fixture.
--   **Lifecycle:** The "Puppeteer" pattern for driving the GUI via automated clients.
--   **Mocking Strategy:** Script-based AI provider mocking via `mock_gemini_cli.py`.
--   **Visual Assertion:** Examples of verifying the rendered state (DAG, Terminal streams) rather than just API returns.
-
-### 4. Product Vision & Roadmap (`Readme.md`)
--   **Technological Identity:** High-density experimental tool for local AI orchestration.
--   **Pedagogical Landing:** Direct links to the deep-dive guides to establish the project's expert-level tone immediately.
-
-## Acceptance Criteria for Expert Review (Claude Opus)
--   [ ] **Zero Filler:** No introductory "In this section..." or "Now we will..." conversational markers.
--   [ ] **Structural Parity:** Documentation follows the `gencpp` pattern (Philosophy -> Code Paths -> Interface).
--   [ ] **Expert-Level Detail:** Includes data structures, locking mechanisms, and thread-safety constraints.
--   [ ] **Narrative Cohesion:** The documents feel like a single, expert-authored manual for a complex graphics or systems engine.
--   [ ] **Tactile Interaction:** Explains the "Linear Execution Clutch" as a physical shift in the application's processing gears.
-
-## Out of Scope
--   Documenting legacy `gui_legacy.py` code beyond its role as a fallback.
--   Visual diagram generation (focusing on high-signal text-based architectural mapping).

conductor/tracks/_archived/robust_live_simulation_verification/index.md

@@ -1,7 +0,0 @@
-# Robust Live Simulation Verification
-
-Builds automated UI simulation testing to prevent orchestrator GUI regressions.
-
-### Navigation
-- [Specification](./spec.md)
-- [Implementation Plan](./plan.md)

conductor/tracks/_archived/robust_live_simulation_verification/metadata.json

@@ -1,6 +0,0 @@
-{
-  "id": "robust_live_simulation_verification",
-  "title": "Robust Live Simulation Verification",
-  "status": "planned",
-  "created_at": "2026-02-27T19:20:00.000000"
-}

conductor/tracks/_archived/robust_live_simulation_verification/plan.md

@@ -1,18 +0,0 @@
-# Implementation Plan: Robust Live Simulation Verification
-
-## Phase 1: Framework Foundation [checkpoint: e93e2ea]
-- [x] Task: Create `tests/visual_sim_mma_v2.py` based on existing simulation patterns. 2a30e62
-- [x] Task: Implement helper methods in `ApiHookClient` for querying specific DearPyGui item states (e.g., `get_text_value`, `get_node_status`). 2a30e62
-
-## Phase 2: Epic & Track Verification
-- [x] Task: Write the simulation routine to trigger a new Epic and verify the Track Browser updates correctly. 605dfc3
-- [x] Task: Verify that selecting a newly generated track successfully loads its initial (empty) state into the DAG visualizer.
-
-## Phase 3: DAG & Spawn Interception Verification
-- [x] Task: Simulate the "Start Track" action and verify the DAG visualizer populates with tasks.
-- [x] Task: Simulate the Auto-Queue advancing to a "Ready" task.
-- [x] Task: Verify the "Approve Worker Spawn" modal appears with the correct prompt and context.
-- [x] Task: Simulate clicking "Approve" and verify the worker's simulated output streams into the correct task detail view.
-
-## Phase: Review Fixes
-- [x] Task: Apply review suggestions 605dfc3 (already applied; superseded by event routing, loop-passing, and adapter-preservation fixes)

conductor/tracks/_archived/robust_live_simulation_verification/spec.md

@@ -1,51 +0,0 @@
-# Track Specification: Robust Live Simulation Verification
-
-## Overview
-Establish a robust, visual simulation framework to prevent regressions in the complex GUI and asynchronous orchestration layers. This track replaces manual human verification with an automated script that clicks through the GUI and verifies the rendered state.
-
-## Goals
-1.  **Simulation Framework Setup:** Build a dedicated test script (`tests/visual_sim_mma_v2.py`) utilizing `ApiHookClient` to control the live GUI.
-2.  **Simulate Epic Planning:** Automate the clicking of "New Epic", inputting a prompt, and verifying the expected Tier 1 tracks appear in the UI.
-3.  **Simulate Execution & Spawning:** Automate the selection of a track, the generation of the DAG, and the interaction with the HITL Approval modal.
-
-## Constraints
--   Must run against a live instance of the application using `--enable-test-hooks`.
--   Must fail loudly if the visual state (e.g., rendered DAG nodes, text box contents) does not match expectations.
-
-## Context & Origins
-This track was born from the "Human Verification" phase of the initial MMA Orchestrator prototype (`mma_orchestrator_integration_20260226`). We realized that while the backend API plumbing for the hierarchical MMA tiers (Tiers 1-4) was technically functional, the product lacked the necessary state management, UX visualization, and human-in-the-loop security gates to be usable. 
-
-**Key Takeaways from the Prototype Phase:**
-- The Tier 2 (Tech Lead) needs its own track-scoped discussion history, rather than polluting the global project history.
-- Tasks within a track require a DAG (Directed Acyclic Graph) engine to manage complex dependencies and blocking states.
-- The GUI must visualize this DAG and stream the output of individual workers directly to their associated tasks.
-- We must enforce tiered context subsetting so that Tier 3/4 workers don't receive the massive global context blob, and we need a pre-spawn approval modal so the user can intercept, review, and modify worker prompts/contexts before they execute.
-
-**Instructions for the Implementing Agent:**
-As you execute this track, ensure you maintain alignment with the other Phase 2 tracks. If you learn something that impacts the dependent tracks, please append a similar "Context Summary" to their `spec.md` files before concluding your run.
-
-## Execution Order & Dependencies
-This is a multi-track phase. To ensure architectural integrity, these tracks **MUST** be executed in the following strict order:
-1. **MMA Data Architecture & DAG Engine:** (Builds the state and execution foundation)
-2. **Tiered Context Scoping & HITL Approval:** (Builds the security and context subsetting on top of the state)
-3. **MMA Dashboard Visualization Overhaul:** (Builds the UI to visualize the state and subsets)
-4. **[CURRENT] Robust Live Simulation Verification:** (Builds the tests to verify the UI and state)
-
-**Prerequisites for this track:** `MMA Dashboard Visualization Overhaul` MUST be completed (`[x]`) before starting this track.
-
-## Session Compression (2026-02-28)
-**Current State & Glaring Issues:**
-1. **Brittle Interception System:** The visual simulation (`tests/visual_sim_mma_v2.py`) relies heavily on polling an `api_hooks.py` endpoint (`/api/gui/mma_status`) that aggregates several boolean flags (`pending_approval`, `pending_spawn`). This has proven extremely brittle. For example, `mock_gemini_cli.py` defaults to emitting a `read_file` tool call, which triggers the *general* tool approval popup (`_pending_ask`), freezing the test because it was expecting the *MMA spawn* popup (`_pending_mma_spawn`) or the *Track Proposal* modal.
-2. **Mock Pollution in App Domain:** Previous attempts to fix the simulation shoehorned test-specific mock JSON responses directly into `ai_client.py` and `scripts/mma_exec.py`. This conflates the test environment with the production application codebase.
-3. **Popup Handling Failures:** The GUI's state machine for closing popups (like `_show_track_proposal_modal` in `_cb_accept_tracks`) is desynchronized from the hook API. The test clicks "Accept", the tracks generate, but the UI state doesn't cleanly reset, leading to endless timeouts during test runs.
-
-**Next Steps for the Handoff:**
-- Completely rip out the hardcoded mock JSON arrays from `ai_client.py` and `scripts/mma_exec.py`.
-- Refactor `tests/mock_gemini_cli.py` to be a pure, standalone mock that perfectly simulates the expected streaming behavior of `gemini_cli` without relying on the app to intercept specific magic prompts.
-- Stabilize the hook API (`api_hooks.py`) so the test script can unambiguously distinguish between a general tool approval, an MMA step approval, and an MMA worker spawn approval, instead of relying on a fragile `pending_approval` catch-all.
-
-**Session Compression (2026-02-28, Late Session Addendum)**
-**Current Blocker:** The Tier 3 worker simulation is stuck. The orchestration loop in `multi_agent_conductor.py` correctly starts `run_worker_lifecycle`, and `ai_client.py` successfully sends a mock response back from `gemini_cli`. However, the visual test never sees this output in `mma_streams`.
-- The GUI expects `handle_ai_response` to carry the final AI response (including `stream_id` mapping to a specific Tier 3 worker string).
-- In earlier attempts, we tried manually pushing a `handle_ai_response` event back into the GUI's `event_queue` at the end of `run_worker_lifecycle`, but it seems the GUI is still looping infinitely, showing `Polling streams: ['Tier 1']`. The state machine doesn't seem to recognize that the Tier 3 task is done or correctly populate the stream dictionary for the UI to pick up.
-- **Handoff Directive:** The next agent needs to trace exactly how a successful AI response from a *subprocess/thread* (which `run_worker_lifecycle` operates in) is supposed to bubble up to `self.mma_streams` in `gui_2.py`. Is `events.emit("response_received")` or `handle_ai_response` missing? Why is the test only seeing `'Tier 1'` in the `mma_streams` keys? Focus on the handoff between `ai_client.py` completing a run and `gui_2.py` rendering the result.