TORCH/docs/TORCH_EVOLUTION_CONCEPT.md

TORCH Evolution: The Node-Based Future

1. The Core Concept: From "Roster" to "Workflow"

Currently, TORCH is a Round-Robin Scheduler. It loops through a static list of agents (daily/weekly). This is great for maintenance but limits complex, multi-step tasks.

The "Bigger" vision is to evolve TORCH into a Workflow Orchestrator (similar to Airflow, Prefect, or ComfyUI, but for Autonomous Agents).

The Shift

• Old: roster.json (List) -> Agent A, Agent B, Agent C.
• New: workflows/refactor.json (Graph) -> Trigger -> Planner -> [Coder, Writer] -> Reviewer.

2. The Node-Based UI

You mentioned a "concept for a node based evolution". This is the right move.

• Recommendation: Build a web-based Workflow Editor using React Flow or Svelte Flow.
• How it works:
  1. Drag & Drop Agents: Drag a "Claude Node" or "Jules Node" onto the canvas.
  2. Connect Context: Draw lines to show data flow. Output of "Planner" becomes context for "Coder".
  3. Visual Debugging: Watch nodes light up Green/Red as the scheduler executes them in real-time.

3. Tool Integrations

Here is where the tools you mentioned fit in:

A. OpenClaw (The Interface / Gateway)

• Role: The Conversational Trigger & Notification Layer.
• Why: OpenClaw excels at connecting to Discord/Slack/Telegram.
• Integration:
  • Don't make OpenClaw the scheduler. Make it the interface.
  • You text OpenClaw: "Run the 'Deep Refactor' workflow on src/auth."
  • OpenClaw triggers the TORCH backend and pipes updates back to your chat.

B. ClaudeCode CLI & Codex CLI (The Workers)

• Role: Execution Nodes.
• Why: Your local machine (Jules) can't be the only brain forever.
• Integration:
  • Create specific "Nodes" in your graph for these tools.
  • "Claude Node": Wraps the claude CLI. Best for complex reasoning/architecture.
  • "Codex Node": Wraps the codex CLI. Best for pure code generation/completion.
  • "Local Node": Runs local models or scripts (what you do now).

4. The Roadmap (How to get there)

You don't need to do this alone. Here is a phased approach:

Phase 1: The Graph Data Structure (Backend)

• Stop thinking in roster.json. Start thinking in DAGs (Directed Acyclic Graphs).
• Create a schema for a "Workflow" (e.g., inputs, steps, outputs).
• Action: I can help you draft this workflow.schema.json.

Phase 2: The "Headless" Runner

• Modify run-scheduler-cycle.mjs to accept a --workflow argument instead of just looping a roster.
• It executes the graph: runs Node A, passes output to Node B.

Phase 3: The UI (The "Face")

• Build a simple React/Next.js app that reads these JSON workflow files and renders them with React Flow.
• Allow editing and saving back to JSON.

Phase 4: The Integrations

• Add "Nodes" for OpenClaw (notifications) and External CLIs (heavy lifting).

5. Summary Opinion

Taking TORCH "node-based" transforms it from a Janitor (cleaning up code daily) into a Factory (building features on demand).

• Tools: Use React Flow for UI. Use OpenClaw for ChatOps.
• Strategy: Keep the "Core" (locking/state) but replace the "Scheduler" (loop) with a "Runner" (graph).