Auriga

What is Auriga?

Auriga is a standalone Node.js service that continuously monitors a Multica work board and dispatches unassigned tickets to Pantheon swarm agents. It is the PM/router of the pipeline: it decides who does what and when, without ever writing code itself.

The routing core is pure, deterministic JavaScript — given issue/run/PR shapes as inputs, it produces routing decisions as outputs. No framework, no async loops inside the decision logic, no network calls from the core. This makes every routing rule unit-testable against mocked board state without touching a live Multica instance.

What Auriga does each cycle

On every cycle (default: every 75 seconds), Auriga runs a single bounded pass:

1. Zombie recovery — finds stale or failed in-progress issues and re-queues them (up to zombieMaxAttempts).
2. Status advancement — moves in_progress → in_review when a run completes, and in_review → done when the linked PR merges. Pure board-fact derivation, no run-status trust.
3. Review dispatch — fires the review squad for in_review stories with open PRs (the "back-half" of the loop).
4. Todo dispatch — selects a capacity-capped batch of unassigned todos, routes each by capability and lane, assigns, verifies a run started.
5. Sleep — waits cycleMs before the next cycle.

A pidfile lock ensures exactly one router process is alive at a time, even if the supervisor starts multiple instances.

Pantheon role

Pantheon is a swarm of coordinated AI agents building software together. Each god owns its own repo and fills a specific orchestration role:

Consus (ideation) → Minerva (planning) → Multica board → Auriga (routing) → swarm agents → in_review → Auriga review squad → merged PR → done

Auriga sits between the Multica board and the agent swarm. Stories are planned by Minerva upstream, land on the Multica board as todo issues, and Auriga drains them to the appropriate agent lanes. When an agent completes work and opens a PR, Auriga's review dispatch fires the back-half: the review squad runs, and either ships (merges) or sends the story back with concrete feedback.

Auriga also runs as a standalone open-source tool — its adapter interface lets it work with any backlog system that implements the BacklogAdapter contract, not just Multica.

Sibling gods

Key properties

Pure decision core

The routing logic in lib/core.mjs is a pure function: given issue/run/PR shapes, it returns decisions. No I/O, no side effects, no network calls. This makes every routing rule unit-testable and auditable independently of the board it routes.

Adapter-interface boundary

Auriga never calls Multica directly from its decision core. All board access goes through the BacklogAdapter / SpawnAdapter boundary, with in-memory stubs for tests and real Multica-backed implementations for production. This seam is how Auriga stays portable and how future boards can be supported without touching the routing policy.

No force — only assign

Auriga only ever assigns and re-runs work. It never deletes issues, cancels runs, or force-merges PRs. Every routing decision is bounded by explicit caps (per-cycle, per-agent, per-runtime) so it never mass-flips the board.

Board-fact status machine

Issue status is never advanced based on run status alone. in_progress → in_review requires a completed run; in_review → done requires a merged PR. Run status is explicitly not trusted as a completion signal — a prior production incident drove this constraint.