One cockpit, every movement.

Pages are server-rendered hono/jsx; htmx 4 submits forms and swaps result fragments; styling is a Tailwind v4 design system built at deploy time — a dark terminal default with a light "ledger paper" theme, toggled from the user menu. The assets are vendored and served same-origin — the console works with no CDN and no client framework. The seventeen command forms are not hand-written: each is generated from src/application/commands/registry.ts, the same declarative entry that mounts the JSON API route, so a new operation is one service method plus one registry entry.

Every money-moving form carries a hidden, auto-generated idempotency key. Submitting twice replays the first result instead of double-posting; after each success the key rotates so the next submission is a fresh command. Server-side validation errors come back as inline field errors; ledger rejections (insufficient funds, currency unknown, flag denied) render as red result cards with the exact reason.

Getting in

The console accepts three kinds of session. The operator token: the login form exchanges AUTH_TOKEN for an HttpOnly cookie (12 h), and scripts can send the same token as a Bearer header instead. Or Sign in with Google (better-auth), active when GOOGLE_CLIENT_ID/GOOGLE_CLIENT_SECRET are set: the account's email must be on the allowlist — seeded by OPS_ALLOWED_EMAILS / OPS_ADMIN_EMAILS, overridden by the lists saved on /ops/settings — and is re-checked on every request, so tightening the list locks existing sessions out within seconds. Admins may view and modify Controls and Settings; operators get everything else; token and Bearer sessions are always admin. Empty allowlists are open in dev but fail closed in production. The console is fully open only when neither AUTH_TOKEN nor Google OAuth is configured (local dev); the REST surface stays Bearer-gated either way.

# local
bun run dev                  # migrate + build assets + serve
open http://localhost:3000/ops

# first boot of a fresh environment (Ledger page has buttons for both)
POST /ops/ledger/rebuild-templates    # load the 18 Numscript templates
POST /ops/ledger/rebuild-coa          # seed COA + GL mappings

The operating loop

Overview first: Formance health, posted/failed counts, outbox pending age, drift and template-mismatch counters. Then Reconciliation — the four gates from chapter 03 run live on the page, with ALM views beneath. Then Payouts: anything in manual_review is yours; anything long-reserved deserves a look. Every result card echoes status, reference, walletflow tx id, Formance tx ids, and the post-command balances — read it before moving on.

A payout is stuck in manual review

The saga exhausted its requeries and parked the hold. Verify the real provider state out-of-band, then expand the hold's row on Payouts: the prefilled Settle (provider paid) or Release (provider failed) form closes it. Money is never moved on a guess — that rule survives the UI.

A reconciliation gate is red

Holds drift → compare reserved rows against ledger hold balances in the gate detail. Wallet drift → Rebuild statement read model first (projection lag is the common cause), re-run, and only then consider a Correction — credit or debit with a mandatory reason and an optional bi-temporal effectiveAt.

An offramp or GPS payout fails with INSUFFICIENT_FUND

By design: the source bank or pool isn't funded. Record the treasury wire with Bank funding (or GPS pool top-up), confirm the balance on Overview, and re-run the original command.

Freeze a merchant — or everything

Controls → Set feature flag: disable core_wallet_enabled for a merchant, currency or provider scope. With CORE_WALLET_FLAG_MODE=fail_closed only enabled scopes transact. Saga completions still record by default — set CORE_WALLET_COMPLETION_GATING=gate for a true hard freeze (chapter 03 explains why that's the exception).