The Relay.
Mechanical loops out.
Decision loops in.

Subcommands

relay start <service-id>     # Begin new cycle. Returns UUID.
relay status                # Show all in-flight cycles.
relay show <uuid>            # Detailed view of one cycle.
relay review <uuid>          # Open plan in $EDITOR.
relay continue <uuid>        # Approve plan, run revision.
relay accept <uuid>          # Final accept after revision.
relay iterate <uuid>         # Revision incomplete, audit again.
relay abort <uuid>           # Stop cycle, clean state.
relay rotate <service-id>    # Manually flip revision rotation.
relay cost                  # Token usage and $ to date.
relay logs [--tail]          # Activity log, optionally follow.

Exit codes

• 0 — operation completed.
• 1 — operation paused, waiting on operator (after audit, after revision).
• 2 — error, operator should investigate.
• 3 — config or environment problem (missing API key, missing repo).

Exit codes matter for tmux scripting and for integration with other tools. relay status; if [ $? -eq 1 ]; then ... patterns let the operator wire the relay into their existing terminal flow.

Configuration resolution order

• Built-in defaults.
• config/default.yaml.
• config/services/<service-id>.yaml.
• Per-cycle overrides (e.g., --model claude-opus-4-7 on the start command).

Logging

Every API call, state transition, and operator command logs to .relay/logs/YYYY-MM-DD.log with timestamps and cycle UUIDs. Logs are append-only, plain text, grep-friendly. No structured logging library. If something went wrong at 2 AM the previous day, grep <uuid> logs/2026-04-28.log reconstructs the story.

# prompts/audit.md

You are conducting an in-depth technical audit of the code below
against the reference materials provided. Your role is auditor only.

Hard rules:
- Do not gloss over flaws. Flaws unaddressed in the audit will reach
  production unaddressed.
- Do not change the code. Do not propose code. Produce an action plan
  that another model will execute.
- Indicate ambiguity. Where the spec is unclear or the code's intent is
  uncertain, say so explicitly with [AMBIGUOUS].
- Be specific. Quote line numbers and code excerpts.
- Do not propose features beyond the spec. The spec is the contract.

Reference materials:
{{ references }}

Service specification:
{{ spec }}

Code to audit:
{{ code }}

Produce output in this exact structure. Do not add or remove sections.

## Critical issues
[bugs, security flaws, spec violations - must fix before merge]

## Significant concerns
[design problems, robustness issues - should fix]

## Ambiguities
[places the spec is unclear or code intent is uncertain]

## Style and convention notes
[lower priority improvements]

## Action plan
[ordered list of specific imperative changes,
 each item references which section above it addresses]

# prompts/refine.md

Two independent audits of the same code are below. Your role is to
consolidate them into a single action plan. Your role is editorial,
not creative.

Hard rules:
- Do not add new items. If neither audit raised it, it stays out.
- Do not propose new directions. Do not editorialize.
- Tighten existing items for accuracy and explicitness.
- Mark items unclear with [AMBIGUOUS].
- Mark items present in both audits with [DUPLICATE — consolidate].
- Mark items where the two audits conflict with [CONFLICT — operator decides].

Audit A (Claude):
{{ audit_a }}

Audit B (Codex):
{{ audit_b }}

Produce a single consolidated action plan in the same structure as the
input audits. Preserve attribution where it matters; otherwise merge
silently.

# prompts/revise.md

Revise the code below to address the action plan. The plan has been
reviewed and approved by the operator. Your role is to execute the plan
as written.

Hard rules:
- Do not deviate from the plan. Items the plan doesn't mention stay
  unchanged.
- Do not add features. The plan is the contract.
- If a plan item is impossible to address as written, stop and report
  the conflict in a section called "## Plan conflicts" rather than
  improvising a workaround.
- Preserve existing tests. Add tests only for new behavior the plan
  introduces.

Reference materials:
{{ references }}

Service specification:
{{ spec }}

Original code:
{{ code }}

Approved action plan:
{{ plan }}

Produce the revised code as a single artifact. Use proper file structure
with file path headers (e.g., # path: src/verifier/lib.rs) before each
file's contents.

Notification mechanisms (in priority order)

• WSLg notify-send — desktop toast via Windows 11 native integration. Default. Works without setup on Win11 + WSL2 with WSLg enabled.
• Terminal bell (\a) — fallback if notify-send unavailable. Configurable on/off per operator preference.
• Status file (.relay/queue.md) — always written. Watch with watch -n 5 cat .relay/queue.md in a tmux pane for live status without polling the API.
• tmux status line — optional. The relay tmux-status subcommand emits a single-line summary suitable for status-right.

Plan review interface

relay review <uuid> opens the consolidated plan file in $EDITOR. Operator edits in place — adding, removing, sharpening items. Saves and exits. The orchestrator reads the modified file as the approved plan.

Editor selection follows standard convention:

• $EDITOR environment variable if set.
• git config --get core.editor if set.
• vi as last fallback.

For VS Code users: export EDITOR="code --wait". For nvim users: standard. For terminal-only operators (vim, micro): standard.

Status display

$ relay status

CYCLES IN FLIGHT
────────────────────────────────────────────────────────
A-202  bf3c91   AUDIT-RUNNING        2m ago     claude+codex
A-204  1a8d72   AWAITING-REVIEW      14m ago    plan ready
A-201  7e0c45   REVISION-RUNNING     38s ago    claude
A-205  9b2317   AWAITING-ACCEPTANCE  1h ago     tests passed

COSTS THIS SESSION
────────────────────────────────────────────────────────
Anthropic   $4.21    18,402 input  /  6,108 output tokens
OpenAI      $3.86    21,209 input  /  4,892 output tokens
Google      $0.42     8,103 input  /    718 output tokens
                                          TOTAL  $8.49

3 cycle(s) need your attention. Run `relay queue`.

tmux pane recipe (optional)

$ tmux new-session -d -s paxiom
$ tmux send-keys -t paxiom 'cd ~/projects/paxiom' C-m
$ tmux split-window -h -t paxiom 'watch -n 10 relay status'
$ tmux split-window -v -t paxiom:0.1 'tail -f .relay/logs/$(date +%Y-%m-%d).log'
$ tmux attach -t paxiom

Cycle states

• INITIALIZED — UUID created, branch checked out, ready to dispatch.
• AUDIT_RUNNING — API calls in flight to audit models.
• AUDIT_COMPLETE — both audits captured, refinement (if enabled) pending or done.
• AWAITING_REVIEW — operator gate. Notification fired.
• PLAN_APPROVED — operator ran continue.
• REVISION_RUNNING — coding model has the revision prompt.
• TESTING — revision applied, tests executing.
• AWAITING_ACCEPTANCE — operator gate. Notification fired.
• COMPLETE — operator accepted. Branch ready for merge.
• ITERATING — operator chose to re-audit. Loops back to AUDIT_RUNNING.
• ABORTED — operator killed cycle. State preserved for review.

State file

// .relay/cycles/<uuid>/state.json
{
  "uuid": "bf3c91a4-...",
  "service_id": "A-202",
  "state": "AWAITING_REVIEW",
  "branch": "feat/svc-202-bf3c91",
  "iteration": 1,
  "started_at": "2026-04-29T22:14:03Z",
  "transitions": [
    { "to": "AUDIT_RUNNING",   "at": "..." },
    { "to": "AUDIT_COMPLETE",  "at": "..." },
    { "to": "AWAITING_REVIEW", "at": "..." }
  ],
  "config_snapshot": { ... },
  "tokens": { "anthropic_in": 8421, ... },
  "cost_usd": 0.34
}

Crash recovery

If the orchestrator dies mid-cycle (network fail, system reboot, Ctrl+C), state is preserved. relay status shows the last known state. relay resume <uuid> picks up from the last persisted transition. API calls that were in flight at crash time may have completed server-side; the orchestrator checks for cached results before re-issuing.

Parallel cycle coordination

• Branch isolation. Each cycle owns a unique branch. Concurrent cycles on different services don't conflict.
• Per-service lock file. A file at .relay/locks/<service-id> prevents two cycles against the same service from running simultaneously. Operator can override with --force if they understand the risk.
• Shared rate limiting. A token bucket per provider shared across all cycles. Prevents one cycle from starving another for API quota.
• Cost tracking aggregated. Per-cycle costs and session totals computed from token usage. relay cost surfaces both views.

Git integration

Each state transition with a code change produces a commit on the cycle branch. Commit messages follow a structured format:

[<cycle-uuid>] <state-transition>: <summary>

Cycle:    bf3c91a4
Service:  A-202 (Sync Committee Verification)
Iteration: 1
State:    REVISION_COMPLETE

Plan items addressed:
  - Critical #1: Add bounds check on signature aggregation
  - Significant #3: Refactor witness loading for evidence path
  - Ambiguity resolved: Decision was <X>, see plan v2

Models:
  audit_a:  claude-opus-4-7
  audit_b:  gpt-5
  refine:   gemini-2.5-pro
  revise:   claude-opus-4-7

Tokens:   in 24,213  out 8,047
Cost:     $0.71