AI Orchestration

robonet-forge — Autonomous AI Development Pipeline

Joel Johnston 2026-03-20 Pre-stroke design

robonet-forge — Autonomous AI Development Pipeline

Author: Joel Johnston Date: 2026-03-20 Domain: AI Orchestration Stroke Timeline: Pre-stroke

Abstract

robonet-forge is an autonomous AI development pipeline implementing the scan-lock-worktree-striker cycle. The system continuously processes a task queue, dispatching Claude Sonnet workers to execute isolated development tasks and validating their output before integration. 2,892 source lines, 125 tests, zero external dependencies. File-based IPC — no message broker required. The pipeline achieves 47x throughput over manual development by removing the execution bottleneck while preserving the architecture bottleneck.

The Scan-Lock-Worktree-Striker Cycle

The core execution loop:

  1. Scan — Forgemaster continuously polls the task queue for pending work
  2. Lock — When a task is found, it is atomically locked to prevent duplicate execution across workers
  3. Worktree — An isolated git worktree is created from a clean HEAD, providing the worker with a fresh working copy
  4. Striker — A Claude Sonnet worker is dispatched into the worktree to execute the task
  5. Validate — Output is validated against acceptance criteria defined in the task envelope
  6. Push — Passing output is pushed to a PR for human review

The cycle is continuous. When a striker completes, the scanner immediately looks for the next task. Parallelism is achieved by running multiple Forgemaster instances, each acquiring its own lock.

Architecture

File-Based IPC

All inter-process communication uses the filesystem. No message broker, no queue service, no external dependencies.

~/.robonet-forge/
  inbox/          # Task envelopes written here by any process
  queue/          # Active queue, Forgemaster manages state
  locks/          # Lock files, atomic creation prevents races
  worktrees/      # Isolated git worktrees per task
  output/         # Striker output before validation
  archive/        # Completed tasks

Task envelopes are JSON files with a defined schema: task_id, uc_ref, uc_path, repo, description, acceptance_criteria, striker_type. Any process with filesystem access can submit tasks — Claude Code, scripts, other forge components, shell aliases.

Forgemaster

The orchestration core. Responsible for the full scan-lock-worktree-striker cycle. Runs as a long-lived process. Designed to be restartable — picks up where it left off from queue state on restart.

Striker Types

Each striker type has specialized system prompts and validation criteria:

Type Purpose Validation
code Generate or modify source code Syntax check, imports resolve, tests pass
test Write test cases Coverage target, assertion quality check
docs Generate documentation Structure check, completeness against spec
refactor Restructure existing code Behavior preservation, test suite still passes

Interface Model

Forge is headless. No UI of its own. All visualization lives in robonet dashboard (DashboardServer).

forge → mesh WS → DashboardServer aggregator → browser (read)
browser → DashboardServer → forge (write/commands)
  • Dashboard = user control plane (view + commands)
  • CLI = Claude/automation interface
  • Inbox = external submission point (any process can write tasks)

The monitor terminal UI from early versions (forge monitor) was migrated to robonet dashboard. Forge owns execution, not visualization.

Task Construction

Use cases are the source. Tasks are never written directly to the queue.

  1. UC is authored (by Joel, via app-uclib)
  2. Forgemaster decomposes UC into thin task envelopes
  3. Each envelope carries uc_ref and uc_path as provenance
  4. Tasks enter the inbox, Forgemaster picks them up

This maintains a clean lineage from requirement to implementation. Every task can be traced back to a UC. Every UC can show which tasks it generated and whether they completed.

The 47x Throughput Claim

The 47x figure is real and auditable. Understanding what it measures:

  • Not: AI writes 47x faster than a human
  • Yes: An architect directing AI execution produces 47x the output of the same architect doing both architecture AND execution manually

The bottleneck in software development was never thinking speed. It was the gap between architectural decisions (fast) and their implementation (slow — typing, boilerplate, setup). robonet-forge eliminates that gap.

The architect conceives the task. The striker implements it. The architect validates. The loop runs continuously. The architect's thinking time is the only bottleneck — and thinking was never the slow part.

Implementation Stats

  • Source lines: 2,892
  • Tests: 125
  • External dependencies: 0 (stdlib only)
  • Lock mechanism: atomic os.open(O_CREAT | O_EXCL) — POSIX-guaranteed exclusive creation
  • Worktree management: git worktree add / git worktree remove
  • Striker interface: subprocess with structured stdin/stdout protocol

Relationship to robonet

robonet-forge is a supporting service in the platform ecosystem — not part of robonet-core or robonet-mesh. It uses the mesh for communication (striker status → mesh → dashboard) but operates independently. The forge pipeline accelerated robonet's own development — robonet-forge built robonet-mesh with robonet-forge running.