Overview
Restructure Mini Cursor from a monolithic agent architecture with nested subgraphs to a clean, workflow-based modular design. This will eliminate state bloat, clarify boundaries between workflows, and make the codebase easier to scale and maintain.
Current complexity: Agent state has 10+ fields, multiple overlapping routers, unclear node-to-service mapping, subgraph nesting ambiguity.
Target state: Each workflow (editing, debugging, analysis) is self-contained with its own state, routers, nodes, and prompts.
Problems to Solve
1. State Bloat
AgentState contains fields for all workflow types (debug_attempts, approved, requires_changes, task_reasoning)
- Nodes only use a subset of fields; unclear which fields belong to which workflow
- No type safety across different workflow contexts
2. Subgraph Nesting Ambiguity
editing_subgraph exists at top-level AND nested in debugging_subgraph
- Unclear if nested version runs with different tools/context
- Hard to understand execution flow
3. Router Proliferation
- Multiple routers scattered across
app/graph/router.py: supervisor_router, editing_tools_router, editing_approval_router, editing_review_router
- Full workflow flow not visible in one place
- Hard to trace decision logic
4. Unclear Node-to-Service Separation
- Unclear whether logic should live in nodes or services
supervisor_node is thin wrapper around app/services/supervisor.py
- No consistent pattern for this separation
5. Prompt Architecture Governance
debugging_subgraph_prompts.py and editing_subgraph_prompts.py work but inconsistent
- Adding new workflows requires new prompt files with no pattern
- Prompts scattered across
app/prompts/ with no clear organization
Proposed Solution
New Structure
app/
├── workflows/ # Each workflow is self-contained
│ ├── __init__.py
│ ├── base.py # Shared workflow interface
│ ├── editing/
│ │ ├── __init__.py
│ │ ├── graph.py # StateGraph definition
│ │ ├── nodes.py # All node implementations
│ │ ├── router.py # All routing logic
│ │ ├── state.py # EditingState (typed, specific)
│ │ ├── prompts.py # All editing prompts
│ │ └── tools.py # Editing-specific tools
│ ├── debugging/
│ │ ├── __init__.py
│ │ ├── graph.py
│ │ ├── nodes.py
│ │ ├── router.py
│ │ ├── state.py
│ │ ├── prompts.py
│ │ └── tools.py
│ ├── analysis/
│ │ ├── __init__.py
│ │ ├── graph.py
│ │ ├── nodes.py
│ │ ├── router.py
│ │ ├── state.py
│ │ ├── prompts.py
│ │ └── tools.py
│ └── composition.py # Orchestrator (replaces agent.py)
│
├── core/
│ ├── llm.py # LLM client (unchanged)
│ ├── supervisor.py # Task classification (moved from services/)
│ └── base_nodes.py # Shared node utilities (optional)
│
├── services/ # Shared utilities ONLY
│ ├── codebase_indexer.py
│ ├── retrieval.py
│ └── tool_executor.py # Centralized tool execution
│
└── [other files unchanged]
Key Benefits
- ✅ Isolation: Each workflow is independent—changes to editing don't risk debugging
- ✅ Type Safety: Workflow-specific states with IDE autocomplete
- ✅ Scalability: Add new workflows without touching existing code
- ✅ Clarity: Full workflow logic visible in one folder
- ✅ Testability: Unit test each workflow in isolation
- ✅ Onboarding: New developers can understand one workflow at a time
Acceptance Criteria
Implementation Checklist
Phase 1: Setup
Phase 2: Editing Workflow
Phase 3: Debugging Workflow
Phase 4: Analysis Workflow
Phase 5: Orchestration & Composition
Phase 6: Cleanup
Phase 7: Testing & Validation
Additional Context
Why This Refactoring Matters
This project is at an inflection point:
- Current architecture works for 3 workflows
- Adding a 4th workflow requires modifying 5+ files
- New developers struggle to understand the flow
- State contract is implicit, not explicit
- Testing individual workflows is difficult
The proposed structure scales to N workflows without this friction.
Notes
- This is a breaking refactor—consider doing it on a feature branch
- Commit phase-by-phase to keep git history clean
- Consider adding
app/core/base_nodes.py if shared node patterns emerge
app/schemas/ folder stays as-is (state types now in workflows)
app/tools/ stays as-is (shared by all workflows)
main.py should not change—composition handles routing transparently
Labels
refactoring
architecture
enhancement
breaking-change
Overview
Restructure Mini Cursor from a monolithic agent architecture with nested subgraphs to a clean, workflow-based modular design. This will eliminate state bloat, clarify boundaries between workflows, and make the codebase easier to scale and maintain.
Current complexity: Agent state has 10+ fields, multiple overlapping routers, unclear node-to-service mapping, subgraph nesting ambiguity.
Target state: Each workflow (editing, debugging, analysis) is self-contained with its own state, routers, nodes, and prompts.
Problems to Solve
1. State Bloat
AgentStatecontains fields for all workflow types (debug_attempts,approved,requires_changes,task_reasoning)2. Subgraph Nesting Ambiguity
editing_subgraphexists at top-level AND nested indebugging_subgraph3. Router Proliferation
app/graph/router.py:supervisor_router,editing_tools_router,editing_approval_router,editing_review_router4. Unclear Node-to-Service Separation
supervisor_nodeis thin wrapper aroundapp/services/supervisor.py5. Prompt Architecture Governance
debugging_subgraph_prompts.pyandediting_subgraph_prompts.pywork but inconsistentapp/prompts/with no clear organizationProposed Solution
New Structure
Key Benefits
Acceptance Criteria
app/workflows/graph.py,state.py,nodes.py,router.py,prompts.py,tools.pyAgentStateapp/workflows/composition.pyorchestrates all workflowsapp/core/supervisor.pyhandles task classification onlyapp/services/tool_executor.pycentralizes tool executionapp/graph/subgraphs/,app/prompts/, and unused files deletedmain.pyunchanged and workingImplementation Checklist
Phase 1: Setup
app/workflows/folder structureapp/workflows/__init__.pyapp/workflows/base.pywith shared workflow interfaceapp/core/supervisor.py(extract from services if needed)Phase 2: Editing Workflow
app/workflows/editing/folderapp/workflows/editing/__init__.pyapp/graph/subgraphs/editing_subgraph.py→app/workflows/editing/graph.pyapp/workflows/editing/state.py(extract from AgentState)app/workflows/editing/nodes.py(import fromapp/graph/nodes/)app/workflows/editing/router.py(move fromapp/graph/router.py)app/workflows/editing/prompts.py(move fromapp/prompts/editing_subgraph_prompts.py)app/workflows/editing/tools.py(organize editing tools)Phase 3: Debugging Workflow
app/workflows/debugging/folderapp/workflows/debugging/__init__.pyapp/workflows/debugging/state.pyediting_workflow(no nesting)Phase 4: Analysis Workflow
app/workflows/analysis/folderapp/workflows/analysis/__init__.pyapp/workflows/analysis/state.pyapp/workflows/analysis/prompts.pyapp/workflows/analysis/nodes.py,router.py,graph.pyPhase 5: Orchestration & Composition
app/workflows/composition.pywith orchestrator routerapp/graph/agent.pyto use composition (or replace entirely)main.pyunchangedPhase 6: Cleanup
app/graph/subgraphs/(moved to workflows)app/prompts/(moved to workflows)app/graph/nodes/(keep only shared utilities)app/graph/router.py(moved to workflows)app/graph/entirely if emptyPhase 7: Testing & Validation
main.pyAdditional Context
Why This Refactoring Matters
This project is at an inflection point:
The proposed structure scales to N workflows without this friction.
Notes
app/core/base_nodes.pyif shared node patterns emergeapp/schemas/folder stays as-is (state types now in workflows)app/tools/stays as-is (shared by all workflows)main.pyshould not change—composition handles routing transparentlyLabels
refactoringarchitectureenhancementbreaking-change