ainb-fleetatclisted

ATC (Air Traffic Control) — the single operator-visible fleet supervisor, in exactly one mode: `lite` (no LLM: deterministic scan, known-transient retry policy, safety caps, evidence) or `full` (the persistent orchestrating brain). Full mode is a plain `ainb` session (Claude or Codex) running a generated policy, woken on a heartbeat (default 15 min) built from the LLM-free `fleet needs` read — which is itself HOOKS-PRIMARY (event-sourced): ATC learns ASK/WAIT/IDLE from the materialized `current_state` table, not by scraping panes, with a tmux fallback for non-Claude agents. `atc setup` installs the global Claude Code hooks into ~/.claude/settings.json. It auto-clears the safe/blocked sessions via the fleet verbs (confident ASK → broadcast; ERR → continue within a retry cap) and escalates the uncertain ones to the phone bridge. Supersedes the `daemon` skill for managed fleets. Use to provision / inspect / tear down an ATC instance, or to switch which controller owns the fleet.
stevengonsalvez/agents-in-a-box · ★ 22 · AI & Automation · score 78

Install: claude install-skill stevengonsalvez/agents-in-a-box

# ainb fleet:atc — Air Traffic Control ATC is the orchestrating brain that ties the fleet verbs together on a schedule with a policy. It is a real `ainb run` Claude session reading a generated `CLAUDE.md`, woken every N minutes by an OS timer. On each heartbeat it pulls the **LLM-free** `ainb fleet needs --format json` read, auto-clears the safe cases itself, and pages you (via the phone bridge) only for the calls that genuinely need a human. ``` hooks ─▶ events.jsonl ─▶ notifyd ─▶ current_state (ASK/ERR/WAIT/IDLE/RUNNING/DONE) │ (materialized per session) OS timer ──[HEARTBEAT]──▶ ATC session ──reads──▶ ainb fleet needs --format json │ (hooks-primary, tmux fallback) ├─ auto-clear ─▶ ainb fleet broadcast (answer / continue) └─ escalate ───▶ phone bridge ─▶ your phone ``` ## How ATC learns a session is blocked — HOOKS-PRIMARY The `fleet needs` read ATC runs each heartbeat is **event-sourced**, not pane- scraped. Claude Code hooks append lifecycle events to `events.jsonl`; notifyd ingests them into a SQLite `current_state` table that materializes the latest stage per session (ASK / ERR / WAIT / IDLE / RUNNING / DONE). ATC reads that materialized state as the PRIMARY source — so it learns ASK/WAIT/IDLE/ERR from hooks, the instant they fire, **without scraping panes**. The tmux pane scan is only the **fallback** for sessions the hook