§19.4 · Mission timeline prototype
One mission iteration, step by step
A T3-managed Claude harness ran an ETH momentum mission with $1,000 of allocated capital. This prototype steps through a single iteration of the §3 architectural loop — the path from a registered watch firing to a confirmed, protected fill — using the verbatim §19.4 timeline. Pick a loop phase to see where the mission sits, which node of the loop is current, and how the execution lifecycle reads. Static UI · mock data · no network calls.
Static UI · mock data · no network calls. Switch the loop phase above to advance the narrative and update the highlighted loop node and lifecycle row.
§3 · The architectural loop
The loop the POC must prove
- 1 · User instruction“Execute a momentum strategy on ETH with $1,000.”
- 2 · T3 starts harnessProviderService starts the bound Claude session
- 3 · Harness publishes strategy + watchesStrategy v1, candle watches registered
- 4 · Turn ends · T3 activeMonitoring armed; no discretionary action
- 5 · Watch / timer fires5m candle closes above threshold
- 6 · T3 resumes harnessSame provider, fresh mission snapshot
- 7 · Harness decidesenter · decline · revise
- 8 · Typed execution$150 long IOC · stop defined
- 9 · T3 validates · signs · reconcilesauthority · nonce · execution wallet
- 10 · Persist + next watchesprotection confirmed · loop repeats
Nodes are coloured by the authority that owns that step: human (User), platform (T3), model (Harness), exchange (Hyperliquid), risk (Authority/execution). The highlighted step tracks the selected loop phase.
15:27 entry · execution lifecycle
Accepted → Order → Fill → Reconciled
- 1 · Acceptedauthority + wallet approved
- 2 · Order$150 long IOC submitted, risk reserved
- 3 · Fill0.041 ETH @ $3,601.0
- 3 · Fill0.041 ETH @ $3,601.0
- 3 · Fillpending
- 4 · Reconciledreduce-only protection confirmed
- 4 · Reconciledpending
The lifecycle row reflects the selected loop phase. Fill is current while T3 is executing; Reconciled completes once exchange-native reduce-only protection is confirmed.
§19.4 · Full mission timeline
ETH momentum mission · 14:05 → 15:42
-
user
User authorized $1,000 ETH momentum mission.
-
t3
Claude session started (provider binding locked to this mission).
-
harness
Strategy v1 published.
-
harness
Two candle watches registered.
-
harness
Harness turn completed; monitoring active.
-
hyperliquid
Bullish watch triggered (5m candle closed above threshold).
-
t3
Resumed Claude session (same provider, via ProviderService).
-
harness
Declined entry because volume was weak.
-
harness
Strategy v2 and revised watches published.
-
hyperliquid
Momentum watch triggered.
-
t3
$150 long IOC submitted (validated, signed by execution wallet).
-
hyperliquid
Entry filled.
-
t3
Stop and take-profit confirmed (reduce-only, exchange-native).
-
user
User disabled future short entries.
-
t3
Authority updated and harness reassessed.
Verbatim from spec §19.4. Tag colour marks the owning authority: cyan = model/harness, green = Hyperliquid, red = authority/controls, amber = user. A watch firing never authorizes a position on its own.
Step-through narrative · §12.4 between turns
What each phase means
loop_waiting
The harness turn ended at 14:07. T3 keeps the mission alive: registered candle watches and timers stay armed, market and account subscriptions remain open, and exchange-native protection (if any position were open) would keep working. No discretionary action occurs until an event fires.
loop_triggered
At 14:42 a 5m candle closed above threshold. WatchEvaluator marked the watch triggered and TradingEventInbox persisted the event. T3 has not yet decided anything — it has only observed a fact and queued a wake-up.
loop_deciding
TradingTurnCoordinator acquired the decision lease and ProviderService resumed the same Claude session with a fresh mission snapshot (market, account, strategy, authority, pending events). The harness decides enter, decline, or revise — here it declined at 14:43 for weak volume and published v2.
loop_executing
On the second trigger (15:26) the harness requested a $150 long IOC with a stop. T3 validated authority, reserved risk against the cumulative-loss budget, signed through the execution wallet, and submitted to Hyperliquid. The harness does not sign; T3 is the execution boundary.
loop_protected
Hyperliquid filled the entry at 15:27. T3 reconciled the canonical position, confirmed exchange-native reduce-only stop and take-profit for the actual filled size, and marked the execution protected. Only then does the loop persist state and publish the next watches.