Architecture

Bosun is organized as a modular Node.js application with clear component boundaries. Each module has a single responsibility and communicates through well-defined interfaces.

High-Level Flow

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  cli.mjs │────▢│  monitor.mjs │────▢│  ve-orchestrator   β”‚
β”‚  (entry) β”‚     β”‚  (supervisor)β”‚     β”‚  (task runner)     β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”˜     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                        β”‚                       β”‚
                   β”Œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”            β”Œβ”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”
                   β”‚ telegram β”‚            β”‚ ve-kanban  β”‚
                   β”‚ bot.mjs  β”‚            β”‚ .mjs       β”‚
                   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜            β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
  1. cli.mjs loads config and routes to the appropriate handler (setup, doctor, daemon, or main start)
  2. monitor.mjs is the supervisor loop β€” orchestration, smart PR flow, maintenance, fleet sync
  3. ve-orchestrator.mjs handles native task execution with parallel slots, retries, and merge checks
  4. ve-kanban.mjs wraps VK CLI operations (list, submit, rebase, archive)

Component Map

ComponentFileRole
CLI Entrycli.mjsCommand routing, config loading, daemon management
Supervisormonitor.mjsMain loop, smart PR flow, maintenance scheduling
Orchestratorve-orchestrator.mjsTask execution, parallel slots, retry logic
VK Wrapperve-kanban.mjsTask board CRUD, attempt lifecycle
Telegram Bottelegram-bot.mjsPolling, batching, live digest, command handling
Mini App Serverui-server.mjsHTTP/WS server for Telegram Mini App
Configconfig.mjsUnified config loader (CLI + env + .env + JSON + defaults)
Fleet Coordinatorfleet-coordinator.mjsMulti-workstation coordination
Shared Stateshared-state-manager.mjsDistributed task claims, heartbeats, conflict resolution
Task Claimstask-claims.mjsLocal + shared claim persistence
Sync Enginesync-engine.mjsBidirectional kanban sync with shared state
Autofixautofix.mjsError pattern detection, guarded auto-fix execution
Agent Poolagent-pool.mjsExecutor management, weighted selection, failover
Codex Shellcodex-shell.mjsPersistent Codex SDK sessions
Copilot Shellcopilot-shell.mjsPersistent Copilot SDK sessions
Claude Shellclaude-shell.mjsPersistent Claude SDK sessions
Container Runnercontainer-runner.mjsDocker/Podman/Apple Container isolation
Sentineltelegram-sentinel.mjsIndependent watchdog companion
WhatsAppwhatsapp-channel.mjsOptional WhatsApp notification channel

Execution Modes

Internal Mode (EXECUTOR_MODE=internal)

Tasks run through the internal agent pool inside the monitor process. The agent pool manages executor selection, weighted distribution, and failover.

Monitor β†’ Agent Pool β†’ [Copilot Shell | Codex Shell | Claude Shell]
                            ↓
                     Task Execution
                            ↓
                     Smart PR Flow β†’ CI Check β†’ Merge

VK Mode (EXECUTOR_MODE=vk)

Task execution is delegated to the Vibe-Kanban orchestrator scripts. The monitor handles supervision and PR lifecycle.

Hybrid Mode (EXECUTOR_MODE=hybrid)

Combines internal and VK modes. Internal handles primary execution; VK picks up overflow or specific task types.

Shared State Model

Distributed task coordination across agents and workstations uses a shared state system:

Claim Lifecycle

1. claimTaskInSharedState(taskId, ownerId, attemptToken)
2. [work...] renewSharedStateHeartbeat() periodically
3. releaseSharedState(taskId, attemptToken, 'complete'|'failed'|'abandoned')
4. sweepStaleSharedStates() β€” background cleanup

Smart PR Flow

The smartPRFlow in monitor.mjs handles the full PR lifecycle:

  1. Branch creation β€” from configured target branch
  2. PR creation β€” with conventional commit title and structured body
  3. CI monitoring β€” polls check status
  4. Auto-rebase β€” on merge conflicts with target
  5. Merge decision β€” merge when all checks pass
  6. Cleanup β€” archive task, prune worktree

Error Recovery

Bosun uses multiple layers of error recovery:

Data Persistence

State is persisted in .cache/bosun/:

FileContents
shared-task-states.jsonDistributed task claims and heartbeat state
fleet-state.jsonMulti-workstation fleet coordination data
task-store.jsonInternal kanban task database
workspaces.jsonWorkspace and worktree registry
sessions/Agent session state and history