← Back to Projects
🔄

Multi-Worker System

Active

Coordination system for running multiple Claude Code instances in parallel. Features lock management, shared state, and policy-based automation.

Bash Docker Coordination

Worker Workflow

1

Startup

Worker reads all status files, policies, and backlog

2

Claim Lock

Worker updates their status file with project name

3

Work

Worker completes tasks following policies

4

Update

Worker logs changes to CHANGELOG.md

5

Release

Worker sets project to "-" when done

Features

Project Locking

Prevents multiple workers from editing the same project simultaneously. Workers claim locks via their status files.

Shared State

Common files for policies, backlog, and environment settings that all workers can read and follow.

Status Tracking

Each worker maintains a status file with current project, task, scratchpad for complex work, and resume triggers for context recovery.

Policy System

Pre-approved actions that workers can take without asking. Boundaries that require explicit approval. Decision queue for async approvals.

Model Tiering

Workers use the cheapest capable model: Ollama (free) → Haiku (cheap) → Opus (full price). Tracked and enforced.

Memory System

Three-tier persistent memory (hot/warm/cold) preserving context across sessions. Failure journal captures mistakes to prevent recurrence.

Heartbeat Monitoring

Automated health checks every 30 minutes — backups, cache drive, container policies, stale locks. Push alerts on issues.

Deploy Pipelines

One-command deploys for website, Nova, apps, and HA config. Automated QA gates for apps (8 checks) and containers (6 checks).

Case Study: Building 48 Android Apps in Parallel

The Challenge

Ship dozens of production-quality Android apps simultaneously without conflicts, context loss, or duplicate work — while maintaining consistent code quality and documentation across all projects.

The Solution

  • Designed file-based locking system preventing workers from editing same project
  • Created shared BACKLOG.md for task queue visible to all workers
  • Implemented POLICIES.md defining pre-approved actions and boundaries
  • Built 3-tier memory system (hot/warm/cold) preserving context across sessions
  • Established model tiering: Ollama (free) → Haiku (cheap) → Opus (complex tasks)
  • Added automated 8-gate QA pipeline catching broken builds before distribution
  • Built failure journal and learning system — mistakes are logged and referenced

The Results

48
Apps built
4
Concurrent workers
0
Merge conflicts
~60%
Cost reduction via tiering

Key Files

WORKER1-4.md Individual worker status, current task, scratchpad, and resume triggers
POLICIES.md Pre-approved actions, boundaries, and standing decisions
BACKLOG.md Shared task queue and ideas
CLAUDE.md Master instructions — startup sequence, ISC framework, metacognition checks
FAILURES.md Failure journal — structured log of what went wrong and why
MEMORY/ Three-tier persistent memory (hot/warm/cold) across sessions