T3 TradesSpec · prototype space

18–21 · Persistence, recovery & testing

T3 Trades durability runs through the existing T3 persistence and event conventions

The trading extension adds logical records and event-inbox semantics on top of T3's persistence layer, reconciles local state with Hyperliquid on a fixed trigger list, restores mission continuity on restart, and is verified by a layered testing strategy spanning unit, contract, simulated-exchange, harness-conformance, and upstream-sync regression suites.

§18 · Logical records

Persistence reuses T3's existing conventions and adds thirteen trading records

The trading domain persists durable mission, authority, strategy, watch, run, event, execution, order, fill, position, risk, and account state. Mission, authority, strategy, and watch updates use optimistic versioning so a stale harness run cannot overwrite a newer published version.

Platform · T3 server

Required logical records

trading_accounts
trading_missions
trading_authority_versions
momentum_strategy_versions
trading_watches
trading_harness_runs
trading_event_inbox
trading_execution_records
trading_orders
trading_fills
trading_position_snapshots
trading_risk_reservations
trading_account_snapshots
Optimistic versioning. Updates to trading_missions, trading_authority_versions, momentum_strategy_versions, and trading_watches must carry an expected version. A run that holds a stale strategy or authority version is rejected before it can mutate durable state, so a superseded wake-up cannot overwrite a newer published conclusion.

§18.1 · Mission event inbox

A typed inbox coalesces market, exchange, timer, user, and system events into harness runs

Observed facts are persisted as inbox events keyed for deduplication, then coalesced before a run consumes them. The run receives an authoritative mission snapshot rather than a raw stream, and only one run at a time may own the decision lease for a mission.

Platform · T3 server

MissionInboxEvent

type MissionInboxEvent = {
  id: string;
  missionId: string;
  category: "market" | "exchange" | "timer" | "user" | "system";
  deduplicationKey: string;
  payload: unknown;
  status: "pending" | "included_in_run" | "consumed";
  occurredAt: number;
};

Category

Routes the event through the right evaluator: market for price/candle watches, exchange for order/fill/position updates, timer for scheduled reassessment, user for conversational input, and system for recovery and lifecycle signals.

Deduplication

deduplicationKey lets reconnects and replays drop duplicate snapshots or repeated watch firings before they generate a second wake-up or a duplicate order.

Status

An event moves pending → included_in_run → consumed, so a queued event is never silently lost and a run always sees the coalesced set it was started with.

§18.2 · Reconciliation triggers

Local records are reconciled against Hyperliquid at fixed, exchange-driven moments

Hyperliquid is the canonical source of market and account truth. Reconciliation is not optional housekeeping; it runs on a fixed list of triggers so local order, fill, position, and reservation state can never drift past the exchange for long.

Exchange · Hyperliquid

Run reconciliation

  • At server startup
  • After WebSocket reconnect
  • Before execution
  • After submission
  • After each fill
  • After position updates
  • Before resuming a paused mission
  • Periodically while a position is open
Local state never outranks Hyperliquid. A grouped TP/SL response, a cancellation reason, or a locally cached fill is treated as a hint until canonical account, order, and position state confirms it. The protection invariant and loss-budget accounting both depend on reconciled truth.

§18.3 · Restart recovery

A T3 restart restores mission continuity without switching providers

On restart the T3 server rehydrates the active mission, its provider binding, the current strategy/authority/watches, and the Hyperliquid streams, then reconciles against canonical exchange state before deciding whether to wake the harness. Provider identity is preserved; no restart ever performs automatic provider substitution.

Platform · T3 server

On restart

  1. Restore trading account and active mission.
  2. Restore provider binding and resume cursor.
  3. Restore current strategy, authority, and watches.
  4. Reconnect Hyperliquid streams.
  5. Query canonical account, order, fill, and position state.
  6. Reconcile local records.
  7. Resume timers.
  8. Queue one run if material events occurred while offline.
  9. Resume the original provider when possible.
  10. Do not switch providers automatically.
Continuity versus availability. A T3 restart may restore mission continuity, including watches, risk reservations, and the bound provider session. A provider-session failure may still move the mission to agent_unavailable; recovery restores monitoring and deterministic controls, it does not silently hand the mission to another harness.

§21 · Testing strategy

Five layered suites verify authority math, tool contracts, exchange edge cases, harness behavior, and upstream sync

The trading extension is verified by five complementary suites. Unit tests pin the deterministic math and state machines; contract tests exercise every tool against the full accept/reject case list; simulated-exchange tests cover Hyperliquid's partial-fill and protection edge cases; harness conformance gates each provider before it appears in the trading selector; and upstream sync regression ensures every integrated batch leaves the fork's contracts, RPC, persistence, and update endpoints intact.

§21.1 · Unit tests

Pure functions and state machines are pinned before integration

Authority · Risk

Coverage

  • Authority defaults and patches
  • Price and size precision
  • cloid generation
  • Nonce monotonicity
  • Risk reservations
  • Paid-fee versus unpaid-fee accounting
  • Cumulative loss-budget equations
  • Loss-budget exhaustion behavior
  • Candle finalization for 1m, 3m, 5m, 15m, and 1h
  • Price-cross transitions
  • Watch supersession
  • Event coalescing
  • Mission transitions
  • Position-reduction calculations
  • Provider-binding immutability

These cover the deterministic core that every later suite depends on: the authority ceilings, the cumulative-loss equations, nonce and cloid correctness, candle-finalization for each POC timeframe, and the immutability of the provider binding for an active mission.

§21.2 · Contract tests

Every tool is tested against the full accept and reject case list

Authority · Risk

Test every tool against

  • Valid input
  • Missing input
  • Stale strategy version
  • Stale authority version
  • Expired preview
  • Invalid direction
  • Excess leverage
  • Excess notional
  • Excess planned risk
  • Exhausted cumulative-loss budget
  • Direct reduction without a harness lease
  • Attempted position increase without a harness lease
  • Paused mission
  • Revoked mission
  • Stale market data
  • Conflicting execution
  • Harness run without lease

The same authority, precision, freshness, lease, and loss-budget checks back both harness tools and deterministic user controls, so the case list applies uniformly across the tool surface.

§21.3 · Simulated exchange tests

A fake Hyperliquid adapter must reproduce the exchange's awkward protection and fill edge cases

Exchange · Hyperliquid

The fake Hyperliquid adapter must support

  • Full fill
  • Partial fill
  • IOC cancellation
  • Parent-linked child orders remaining untriggered
  • Manual parent cancellation after a partial fill
  • Insufficient-margin parent cancellation
  • Mixed per-order statuses in one grouped action
  • Rejection
  • Tick-size rejection
  • Insufficient margin
  • Stop placement failure
  • Stop replacement failure
  • Partial emergency-close fill
  • WebSocket disconnect during the protection window
  • Duplicate snapshot
  • Out-of-order update
  • External position change

These cases let the protection invariant, emergency-close procedure, and reconciliation triggers be exercised deterministically, including the moments that most often break naive integrations: grouped actions with mixed per-order statuses, parent-linked children that never go live, and disconnects during the bounded protection window.

§21.4 · Harness conformance

Each provider is gated before it is exposed in the trading selector

Harness · Model

Each provider must pass before that provider is exposed in the trading selector

  • Tool discovery
  • Strategy publishing
  • Watch registration
  • Turn completion while mission remains active
  • Same-session resumption
  • Mission and version preservation
  • Rejected execution handling
  • Partial-fill reconciliation
  • Pause and revoke behavior
  • No raw wallet request
Verified independently. Each provider — Codex, Claude, and OpenCode — is verified independently against the same T3 trading contracts. A provider that has not passed this verification remains disabled in the trading provider selector; the central event-driven loop may be proven with one provider first, but the complete POC release requires all three to pass before all three are exposed. No mission moves between them.

§21.5 · Upstream sync regression

Every upstream batch must pass the fork's integration regression suite

Platform · T3 server

Every upstream batch must test

  • Provider session start and recovery
  • MCP session provisioning
  • Orchestration event ingestion
  • Queue worker drainage
  • Ordered push delivery
  • Trading RPC decoding
  • Trading projection hydration
  • Persistence migration
  • Fork version negotiation
  • Update endpoint isolation
No silent upstream capture. The regression suite guards the seams that an upstream batch is most likely to disturb: provider sessions, MCP provisioning, orchestration ingestion, ordered pushes, trading RPC/projection wiring, persistence migrations, and the fork-owned version and update endpoints. A batch that breaks any of these is not accepted, and no updater is left pointing at upstream T3 release or update endpoints.