Working project status as of 2026-05-30. 9 new commits merged this morning: 5 worker-deadlock root-cause fixes, GET /status/pulse (token-free SQL health broadcast every 20min), GET /reflection/digest (rule-based weekly self-improvement digest). Verifier runtime gate queued. TUI is live at apps/tui-go/nyx-tui.
All shipped components as of today. Five-column view: triggers on the left, oversight and persistence on the right. New today (9 commits): 5 deadlock root-cause fixes (planner 0-subtask early return + 45min fanout cap, archive() SIGTERMs subprocess, 60min worker runtime cap, autopilot 1h cooldown, watchdog tool_use idle tracking at 15min), GET /status/pulse (pure-SQL health broadcast every 20min on SSE, haiku escalation on anomaly only), GET /reflection/digest (rule-based audit-log analysis, 1 haiku call per digest, fires on daily scheduler). Verifier runtime gate queued. Go TUI live at apps/tui-go/nyx-tui. Multi-moderator and concierge-uses-planner still in flight.
Target architecture when every phase ships. Green boxes are already shipped (as of 2026-05-30); blue boxes remain. What's still ahead: the multi-moderator process model with the 2-slot / 4-worker caps (in flight), concierge auto-routing big tasks through the planner (in flight), and the Verifier runtime gate + Visual Iteration items (queued). The Go TUI is live. Once the remaining items land, the operator gives intents and the system runs them across 1-2 project moderators with workers, planner, critic, auto-revise, verifier, janitor, and auto-restart all self-driving. Memory persists across all sessions; the operator becomes optional for everything except strategic conversation.
The delta is the roadmap. Blue boxes in the full vision that are not green are what the self-iteration loop will build next, in the order listed below.
Ordered smallest-and-safest first so the self-iteration loop validates itself on easy wins before touching anything load-bearing. The total is roughly 30-35 hours of subagent execution to ship every box in the "full vision" diagram above.
Self-iteration is now live (v1).
The three guardrails are shipped: (a) pnpm dev:safe runs the moderator without tsx watch so worker edits don't trigger mid-task restarts, (b) the self-iter prompt explicitly tells the worker "STOP and report if the diagnosis is unclear, do not guess", (c) every dispatch writes a kind=self_iter audit row plus a self_iter_attempts row, and every code change lands on a fresh nyx-self/<ts> branch with its own commit so it's rollbackable. Items 15-26 above are the next-iteration backlog that Nyx itself can work through.
One command, moderator on :3000 + dashboard on :5173, concurrently labeled.
cd ~/projects/agent-orchestrator pnpm dev
Visit http://localhost:5173. You should see the mac-window chrome and a green "live" indicator in the titlebar.
Click the + button in the tab bar. A new agent tab appears. It is empty (no worker spawned yet).
Type in the right-side chat panel. cmd+enter sends. This spawns a worker with your message as the prompt. The Moderator prompt template prepended automatically asks for clarification if needed, otherwise goes straight to work.
Worker output streams into the chat panel. If it spins up a localhost dev server, the middle pane iframes it (live, interactive). If it tries something gated (git push, edit ~/.env, etc.), the bottom bar lights up amber with the matched rule and layer chip.
Click approve or deny on the bottom bar. Decision is logged to audit_log and broadcast back to the worker via WS so it can continue (or handle the denial).
Click the gear icon. Edit the blacklist tab. Add patterns. Save. The loader hot-reloads, the matcher uses new patterns on the next decision.
# ~/.orchestrator/blacklist.yml bash: - "git push *" - "fly deploy *" paths: - "**/.env*" - "~/personal-notes/**"
API-only for now. UI tab coming.
curl http://localhost:3000/audit | jq curl http://localhost:3000/audit?kind=gate_decision&limit=20 | jq
Phases 1-2C give you a tool you can actually point at FBM Sniper for 30 nights. That data tells us which Phase 6 memory features matter and which Part B safety features are needed first. Building Phase 6 before the trial is guessing.
The win isn't the longest feature list. It's being the only tool where you genuinely close the laptop and trust it. Earned by Push Gate + audit log + Pending Learnings reliability, not by shipping every roadmap item.
An orchestrator modifying its own gate logic is the single feature most likely to break the trust pitch catastrophically. Phase 7 stays planned but only for non-safety code, and is not part of the public release.
Pending Learnings, skill provenance, token budgets, and the circuit breaker are all great features. They are also all more value to a tool that has lived through real incidents than to a tool that hasn't. Ship the trial, learn, then build them with that data.