# Track Specification: MMA Data Architecture & DAG Engine

## Overview
Restructure how `manual_slop` stores and executes work. The current implementation relies on global state and linear execution, which does not support the complexity of multi-agent, task-based workflows. This track establishes a robust, data-oriented foundation using track-scoped state and a native Python Directed Acyclic Graph (DAG) engine.

## Goals
1.  **Track-Scoped State:** Transition away from a single global `manual_slop_history.toml` to a per-track state structure (e.g., `tracks/<track_id>/state.toml`) to manage specific discussion history and context.
2.  **Task DAG Engine:** Implement a topological sorter and DAG execution engine in Python to manage dependencies between tasks.
3.  **Execution State Machine:** Build an internal state machine that governs whether the DAG auto-advances or waits for manual user intervention to spawn the next worker.

## Constraints
-   Must integrate seamlessly with the existing project TOML structure.
-   Avoid external complex dependencies (like Steve Yegge's Beads) for now; rely on standard Python libraries or lightweight custom implementations to ensure tight coupling with the DearPyGui stack.

## 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. **[CURRENT] 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. **Robust Live Simulation Verification:** (Builds the tests to verify the UI and state)

**Prerequisites for this track:** None. This must be executed FIRST.