Nine execution prompts, one per implementation phase

Context

• T3 Trades specification §7 Forking and upstream strategy
• T3 Trades specification §8 Repository layout
• Upstream T3 Code repository at the pinned commit, license, and lockfile
• T3 Trades §20 Phase 0 acceptance gates

Inspect

• Upstream LICENSE, README, CONTRIBUTING, package.json, and pnpm-workspace.yaml
• Upstream server update and version-negotiation code paths
• Upstream desktop application identity and release workflow files
• Upstream provider, orchestration, and contracts package layouts
• Existing CI and signing configuration

Constraints

• Preserve the upstream MIT license and copyright notice verbatim
• Do not commit product work onto upstream-main; fast-forward only
• Do not reverse the upstream/origin remote meanings across machines
• Do not leave forked clients pointing at upstream update or release endpoints
• Keep divergence additive: new product-owned packages over broad upstream rewrites
• Do not combine branding rewrites with architecture changes

Tasks

• Rename origin to upstream and add the fork repository as origin
• Create branches upstream-main, main, feature/trading-*, sync/upstream-YYYY-MM-DD, and release/*
• Pin an exact upstream commit and record it in docs/upstream/BASELINE.md
• Apply fork branding: product name, app IDs, executable names, artifact names, signing identities, and update feeds
• Replace release, auto-update, and server-replacement endpoints with fork-controlled infrastructure
• Write docs/upstream/PATCH_LEDGER.md seeded with the seams already touched
• Produce an integration map of current T3 services and the narrow seams trading will extend
• Expose both productVersion and t3UpstreamCommit from the build

Steps

1. Clone and rename remotes per §7.3
2. Create the branch model from §7.4
3. Pin the upstream base and write BASELINE.md per §7.5
4. Apply branding and release/update independence per §7.12
5. Record the package-manager and exact build commands from the pinned commit
6. Walk one sync batch through SYNC_RUNBOOK.md to validate the procedure
7. Run upstream build, typecheck, lint, and tests on the fork baseline

Parallel tracks

• Remotes, branches, and baseline pinning
• Branding, identifiers, and release/update endpoints
• Patch ledger and integration map authoring
• Sync runbook dry-run

Outputs

• Initialized fork repository with correct remotes and branches
• docs/upstream/BASELINE.md with pinned commit, tag, fork version, and date
• docs/upstream/PATCH_LEDGER.md seeded with branding seams
• docs/upstream/SYNC_RUNBOOK.md validated by one batch
• Build artifact exposing productVersion and t3UpstreamCommit

Acceptance

• The fork builds without any trading code present
• Client and server emit fork-controlled version metadata
• One upstream batch is ingestible through the sync runbook
• No updater, release feed, or replacement URL points at upstream T3

Tests

• Upstream build, typecheck, lint, and unit tests pass on main
• Version metadata asserts the fork name and upstream SHA
• Grep asserts no upstream update/release hostname remains in code
• Sync runbook reproduces a clean merge commit on a throwaway sync branch

Docs

• docs/upstream/BASELINE.md
• docs/upstream/PATCH_LEDGER.md
• docs/upstream/SYNC_RUNBOOK.md
• Integration map of T3 services and trading seams

Context

• PROMPT-00 fork baseline and integration map
• T3 Trades §10 Core domain model and §11 State machines
• T3 Trades §14 Agent tool surface (mission and strategy tools)
• T3 Trades §19 Interface (workspace, status, mandate, timeline)

Inspect

• ProviderService session-start and resume seams
• Existing T3 RPC, push-channel, and projection registration points
• Existing persistence and optimistic-versioning conventions
• Mission, authority, strategy, and harness-binding contracts from §10

Constraints

• No exchange execution in this phase
• ProviderService remains the only provider runtime; do not spawn provider CLIs
• Only one active autonomous mission may exist at a time
• Provider binding is immutable for an active mission
• Do not put exchange credentials into provider prompts

Tasks

• Author packages/trading-contracts: account, authority, mission, strategy, momentum, market, watch, execution, order, position, events, and tools
• Implement TradingMissionService with mission creation, status transitions per §11.1, and the one-active-mission invariant
• Apply POC authority and risk-policy defaults from §10.4
• Wire provider selection and immutable harness binding per §10.2
• Implement trading_publish_momentum_strategy with expected-version optimistic locking and watch supersession
• Build the trading workspace UI: mandate, strategy panel, harness status, and timeline per §19
• Register trading RPC and push projections through the existing seams

Steps

1. Define and freeze the domain contracts in trading-contracts
2. Implement mission and authority persistence with optimistic versions
3. Add ProviderService-backed mission creation and provider binding
4. Expose the mission and strategy publishing tools via the shared MCP/tool surface
5. Compose the workspace React surfaces inside the existing T3 client
6. Project mission and strategy state through ServerPushBus

Parallel tracks

• Domain contracts
• Mission and authority services
• Workspace UI surfaces
• Timeline and projection rendering

Outputs

• packages/trading-contracts domain types
• TradingMissionService with one-mission invariant
• Mission composer and active-mandate UI
• Strategy publishing tool with version control
• Trading timeline projection

Acceptance

• A user creates one ETH momentum mission with a $1,000 mandate
• T3 starts the selected harness through ProviderService
• The harness publishes a valid MomentumStrategyState
• The UI renders the mandate and published strategy
• Only one active mission exists; a second is rejected

Tests

• Mission transition table unit tests per §11.1
• Authority defaults and patch validation unit tests
• Provider-binding immutability contract test
• Strategy publishing with stale version is rejected
• Workspace UI keyboard and projection parity checks

Docs

• packages/trading-contracts source
• Trading workspace component map
• Mission and strategy projection schema
• Handoff summary for PROMPT-02

Context

• PROMPT-01 mission runtime and workspace
• T3 Trades §13 Market data and §15.2–15.3 Hyperliquid gateway and precision
• Hyperliquid documented info endpoint, WebSocket subscriptions, and candle intervals
• T3 Trades §20 Phase 2 acceptance gates

Inspect

• Selected Hyperliquid SDK version and info/exchange/WebSocket transports
• Documented candle intervals and recent-candle availability
• Account-query requirements: master address versus API-wallet address
• Existing market-data freshness conventions in the workspace

Constraints

• No signing in this phase; read-only only
• Never query account state with the execution-wallet address
• Never hard-code the ETH asset index
• Direct 1m/3m/5m/15m/1h subscriptions; do not synthesize intervals locally
• One tool response is bounded to 500 bars
• All exchange shapes stay behind the HyperliquidGateway interface

Tasks

• Implement HyperliquidInfoClient and HyperliquidWebSocketClient with bounded reconnect and resubscribe
• Implement HyperliquidMarketResolver with cached symbol, asset index, szDecimals, max leverage, and availability
• Implement HyperliquidPrecision: normalize size and price, remove trailing zeroes, verify exchange minimum notional
• Implement market snapshot, candle history (1m/3m/5m/15m/1h direct), and BBO reads
• Implement account state, open orders, and position reads using the master address
• Reconcile canonical state through the Info API after reconnect; de-duplicate replayed records
• Expose market and account tools: trading_resolve_market, trading_get_market_snapshot, trading_get_market_history, trading_get_order_book, trading_get_account_state, trading_get_position, trading_get_open_orders
• Attach freshness metadata to tool results

Steps

1. Pin the SDK and create info and WebSocket transports
2. Build the market resolver and precision cache with freshness
3. Subscribe to ETH 1m/3m/5m/15m/1h candles, BBO, asset context, and account channels
4. Map exchange shapes to domain records behind the gateway interface
5. Add reconnect snapshot refresh and dedupe
6. Wire read-only tools into the shared MCP surface

Parallel tracks

• Market resolver and precision
• Market streams and history
• Account streams and reconciliation
• Read-only tool wiring

Outputs

• packages/hyperliquid read-only adapter
• Cached ETH market metadata and precision normalizer
• Live candle and BBO subscriptions with freshness
• Account, order, and position reads against the master address
• Read-only market and account tools

Acceptance

• The harness reads live ETH testnet market and account state through T3 tools
• Account state is queried with the master-wallet address
• The execution-wallet address is never used as account identity
• Reconnect restores subscriptions and refreshes canonical state
• Direct 1m, 3m, 5m, 15m, and 1h candle subscriptions are verified

Tests

• Precision normalization unit tests (szDecimals, price, trailing zeroes, min notional)
• Candle finalization tests for 1m/3m/5m/15m/1h
• Reconnect resubscribe and canonical-state refresh tests
• Account-query negative test asserting the API-wallet address is never used
• Hyperliquid testnet smoke for each direct candle interval

Docs

• packages/hyperliquid adapter source
• Market metadata and freshness guarantees
• Error taxonomy for read paths
• Handoff summary for PROMPT-03

Context

• PROMPT-02 read-only market and account ports
• T3 Trades §12 Event-driven harness lifecycle
• T3 Trades §18 Persistence and recovery (inbox and watch records)
• T3 Trades §4.4 Immutable provider binding and same-provider resume

Inspect

• ProviderService resume and session-availability APIs
• Existing T3 queue workers and runtime receipt bus
• Candle finalization and price-cross behavior from PROMPT-02 subscriptions
• Existing optimistic-versioning patterns for watches

Constraints

• Use T3's existing same-provider resume path; no provider switching or new provider runtime
• Only one run may own the mission decision lease at a time
• Watches are simple, deterministic, typed, and bound to a strategy version
• A watch firing does not itself authorize a position
• Do not generate new discretionary intent between turns

Tasks

• Implement MarketWatchRegistry with persisted watches bound to strategy version per §12.1
• Implement WatchEvaluator: candle-close and price-cross predicates, and scheduled reassessment
• Implement TradingEventInbox with deduplication keys and TradingEventCoalescer
• Implement TradingTurnCoordinator with the one-run-at-a-time decision lease per §12.3
• Wire trading-to-ProviderService resume for the selected provider through existing APIs
• Assemble the TradingHarnessWakeup payload with fresh market, account, strategy, authority, and pending events per §12.2
• Register watch tools: trading_register_watch, trading_schedule_reassessment, trading_list_watches, trading_cancel_watch

Steps

1. Persist watches and supersede obsolete watches on strategy version change
2. Build the candle-close and price-cross evaluators against the PROMPT-02 subscriptions
3. Build the event inbox with coalescing and a single decision lease
4. Connect the coordinator to ProviderService resume
5. Deliver a fresh authoritative snapshot on each wake-up
6. Verify duplicate or superseded events do not start a second run

Parallel tracks

• Watch registry and evaluators
• Event inbox and coalescer
• Turn coordinator and lease
• Provider resume wiring

Outputs

• Persisted watch registry and evaluators
• Event inbox with coalescing
• TradingTurnCoordinator with single-lease enforcement
• Provider resume wiring and wakeup payload assembly
• Watch and schedule tools

Acceptance

• The harness registers a watch and its turn ends
• T3 remains active and monitoring after the turn ends
• A final candle triggers exactly once
• T3 resumes the same provider session through ProviderService
• Fresh market and account snapshots are delivered to the resumed turn
• Duplicate or concurrent runs are prevented by the lease

Tests

• Candle finalization fires a watch exactly once for 1m/3m/5m/15m/1h
• Price-cross transition and watch supersession unit tests
• Event coalescing and deduplication tests
• Decision-lease concurrency test: a second run is queued or rejected
• Same-session resumption contract test against ProviderService

Docs

• packages/trading-core watch and coordinator source
• Wakeup payload schema
• Same-provider resume wiring notes
• Handoff summary for PROMPT-04

Context

• PROMPT-03 resume loop and trading account need
• T3 Trades §15.1 Wallet model and §10.1 Trading account
• T3 Trades §4.6 No repeated user approval and §4.7 No ERC-4337 requirement
• T3 Trades §23 Guardrails on wallet exposure

Inspect

• Privy authentication and wallet-provisioning APIs
• Hyperliquid approveAgent and API-wallet registration flow
• Existing T3 authenticated server boundary and session verification
• Wallet lifecycle states from §10.1

Constraints

• No raw private key may reach the harness, client, or provider prompt
• Account state is queried with the master-wallet address, never the execution wallet
• The execution wallet signs ordinary exchange actions only; administrative actions are excluded
• Approval is one-time; no per-order user prompt for ordinary trading
• ERC-4337 is not required for the testnet path

Tasks

• Implement PrivyUserService and PrivyMasterWalletService for login and the user-owned master wallet
• Implement PrivyExecutionWalletService for the server-controlled execution wallet
• Implement HyperliquidAgentApproval with agent name t3-trades-poc and idempotent approveAgent
• Verify approval against Hyperliquid canonical state before marking the wallet approved
• Persist TradingAccount with master and execution wallet records and lifecycle status per §10.1
• Build the wallet status UI showing onboarding, awaiting approval, approved, and error states
• Exclude administrative actions (API-wallet replacement, withdrawals, transfers, builder-fee approval, arbitrary signing, wallet export) from the autonomous tool surface

Steps

1. Define wallet lifecycle states per §10.1
2. Implement the authenticated server boundary and Privy login
3. Provision the master wallet and the separate execution wallet
4. Submit the one-time approveAgent action and verify registration on testnet
5. Apply the signing allowlist and policy isolation
6. Render wallet status in the workspace

Parallel tracks

• Auth and master wallet
• Execution wallet provisioning
• Agent approval and verification
• Wallet status UI

Outputs

• packages/privy-hyperliquid wallet services
• One-time-approved execution wallet registered as t3-trades-poc
• TradingAccount persistence with lifecycle states
• Wallet status UI
• Signing allowlist and policy isolation

Acceptance

• The user completes the one-time approval
• T3 verifies the wallet is registered on Hyperliquid
• No raw private key reaches the harness or client
• Ordinary testnet signing works without another user prompt

Tests

• Master-to-execution wallet separation contract test
• Approval verification asserts canonical Hyperliquid registration
• Negative authorization test: administrative actions are rejected
• Secret-bundle scan: no key material in harness, client, or logs
• Testnet approval and ordinary sign smoke

Docs

• packages/privy-hyperliquid source
• Wallet lifecycle and approval runbook
• Signing allowlist matrix
• Handoff summary for PROMPT-05

Context

• PROMPT-04 approved execution wallet and signing allowlist
• PROMPT-02 Hyperliquid adapter and precision
• T3 Trades §15.3–15.6 precision, market-like orders, cloid, and nonce
• T3 Trades §16 Authority and risk (reservations and loss budget)

Inspect

• HyperliquidExchangeClient submit and per-order status behavior
• Master-address account-query path for fills and positions
• Hyperliquid userFees response and fallback taker-fee reserve
• Existing reconciliation triggers from §18.2

Constraints

• No position increase without a valid stop defined and risk reserved before signing
• Market-like behavior is marketable IOC limit derived from fresh best bid/ask, never stale mark
• Persist the execution record before submission; retries reuse the same cloid and idempotency key
• All signed actions pass through one serialized nonce lane
• Local state never outranks Hyperliquid; reconcile after every submission and fill
• No assumption that a submitted order filled

Tasks

• Implement trading_preview_order with precision normalization, authority checks, BBO freshness, and stop requirement
• Implement HyperliquidNonceCoordinator: monotonic nonces, fast-forward, no duplicates, persisted recovery hint, serialized signing
• Implement HyperliquidCloid deterministic 16-byte cloid from mission, strategy version, execution sequence, and action type
• Implement HyperliquidOrderMapper for IOC and GTC orders and cancellation
• Implement HyperliquidReconciler for fills, position state, and open orders via the master address
• Wire Hyperliquid userFees lookup with the 5-bps fallback reserve
• Implement risk reservations and cumulative-loss accounting per §16.2, including paid-fee versus unpaid-fee distinction
• Enforce loss-budget exhaustion per §16.4: cancel increasing orders, block exposure, preserve protection, set blocked/cumulative_loss_limit
• Implement reduce-only close through T3 orchestration

Steps

1. Build the nonce coordinator and deterministic cloid first
2. Add preview with full validation and reservation before signing
3. Persist the execution record, then sign and submit through the serialized lane
4. Inspect per-order statuses; query canonical fills and positions via the master address
5. Compute realized loss, open risk, pending risk, and remaining budget; enforce exhaustion
6. Reconcile after rejection, cancellation, partial fill, fee update, reduction, and close

Parallel tracks

• Nonce and cloid
• Preview and precision validation
• Order mapping and submission
• Reconciliation and loss-budget accounting

Outputs

• HyperliquidExecutionService with nonce coordination and deterministic cloid
• Preview and validation path
• Fill and position reconciliation against canonical state
• Risk reservation and cumulative-loss accounting
• Loss-budget exhaustion enforcement

Acceptance

• A resumed harness requests an entry and T3 validates and signs it
• Hyperliquid accepts the order
• Fill and position state return through T3 orchestration
• A retry cannot duplicate the order
• Loss-budget exhaustion blocks further exposure while preserving protection

Tests

• Nonce monotonicity and no-duplicate unit tests
• cloid determinism and collision tests
• Precision normalization and min-notional tests
• Cumulative-loss equation property tests per §16.2
• Loss-budget exhaustion behavior test per §16.4
• Idempotent retry test: same cloid does not create a second order

Docs

• packages/hyperliquid execution source
• Nonce and cloid design notes
• Risk reservation and loss-budget accounting spec
• Handoff summary for PROMPT-06

Context

• PROMPT-05 execution, reconciliation, and reservations
• T3 Trades §17 Protective-order invariant and §5.5 deterministic buttons
• T3 Trades §20 Phase 6 acceptance matrix
• T3 Trades §23 Guardrails on grouped TP/SL and partial fills

Inspect

• Hyperliquid normalTpsl and positionTpsl grouping and per-order status behavior
• Parent-linked TP/SL partial-fill and manual-cancellation behavior
• Insufficient-margin cancellation special case
• The PROMPT-05 reservation and reconciliation services

Constraints

• No acknowledged position increase may remain without confirmed reduce-only protection beyond the bounded reconciliation window
• Never treat a grouped TP/SL response or a group's presence as proof every order is live
• Never cancel a partially filled parent before independent protection is confirmed for the filled size
• Every deterministic button must function while the harness is unavailable
• Emergency close is a deterministic safety action, not a strategy decision

Tasks

• Require a mandatory stop input on every position-increasing request
• Validate the normalTpsl request path on testnet and inspect every per-order status
• Implement partial-fill protection fallback: place or replace reduce-only stop for the actual canonical size
• Implement the position-level or explicitly sized reduce-only stop path (positionTpsl or sized trigger)
• Implement protection reconciliation and replacement after scale-in per §17.4
• Implement deterministic Pause and Cancel entries buttons (trading_control_pause, trading_control_cancel_entries)
• Implement deterministic 25/50/75/100% reduction buttons (trading_control_reduce_position)
• Implement deterministic Close, Revoke, and Close-and-revoke buttons (trading_control_close_position, trading_control_revoke, trading_control_close_and_revoke)
• Support scale-in, partial reduction, full close, and direction reversal through the same authority and execution path
• Implement bounded emergency close: cancel increasing orders, reduce-only marketable IOC, at most three attempts, reconcile partial fills

Steps

1. Validate normalTpsl and positionTpsl shapes on testnet before relying on them
2. Add the mandatory stop gate to position-increasing validation
3. Build partial-fill protection reconciliation that reads canonical size before placing protection
4. Wire the deterministic control buttons to TradingControlService using the same execution path
5. Implement protection replacement that confirms new protection before dropping the last valid stop where overlap is safe
6. Implement the bounded emergency-close procedure and its terminal blocked state

Parallel tracks

• Protection placement and reconciliation
• Partial-fill and cancellation edge handling
• Deterministic control buttons
• Emergency close procedure

Outputs

• Mandatory stop gate and validated normalTpsl path
• Partial-fill protection fallback and replacement
• Deterministic Pause, Cancel entries, Reduce, Close, Revoke, and Close-and-revoke controls
• Scale-in, reduction, full close, and reversal flows
• Bounded emergency close with at-most-three attempts

Acceptance

• A full fill receives confirmed exchange-native protection
• A partial fill receives protection for the actual canonical size
• Manual cancellation of a partially filled parent does not remove the position's only stop
• Per-order failures in a grouped request are detected
• Every deterministic risk-control button works while the harness is unavailable
• Emergency close reconciles partial fills and performs at most three bounded attempts

Tests

• Full-fill IOC with linked TP/SL testnet evidence
• Partial-fill protection fallback testnet evidence
• Resting parent partial fill and manual cancellation testnet evidence
• Insufficient-margin cancellation reconciliation testnet evidence
• Per-order rejection inside a multi-order action testnet evidence
• Stop replacement after scale-in testnet evidence
• Deterministic buttons function with harness marked unavailable
• Emergency close with partial IOC fill within three attempts

Docs

• Protection placement and reconciliation source
• Deterministic control button matrix
• Emergency close runbook
• Required testnet evidence catalogue from §17.6

Context

• PROMPT-06 deterministic control primitives and protection path
• T3 Trades §5.4 Conversational control
• T3 Trades §14.7 deterministic user-control API
• The authority and strategy versioning from PROMPT-01

Inspect

• TradingControlService and authority-patch surfaces from prior phases
• Strategy publishing and version invalidation
• Existing conversation and user-message routing in the mission runtime
• Pause, resume, and revoke deterministic paths

Constraints

• Phase 7 adds interpretation and conversation around Phase 6 primitives; it does not create a separate execution path
• Material ambiguity must be clarified before any exposure change
• Risk-reducing deterministic controls must not depend on a harness turn
• Authority patches are enforced immediately and versioned
• Do not interpret ambiguous exposure-changing instructions autonomously

Tasks

• Implement MissionModificationService for authority patches with immediate enforcement and version bump
• Map unambiguous risk-reducing instructions (for example reduce half, move stop to break-even, cancel entries) onto TradingControlService
• Route strategy instructions and ambiguous exposure changes through the bound harness turn
• Implement clarification handling before exposure changes: ask, do not guess
• Implement conversational pause, resume, and revoke over the deterministic primitives
• Surface interpreted intent and the resulting deterministic action in the timeline

Steps

1. Define the authority-patch and strategy-instruction contracts
2. Classify incoming messages into deterministic-control, harness-routed, or needs-clarification
3. Execute unambiguous risk-reducing instructions directly through TradingControlService
4. Queue ambiguous or strategy-level instructions as a harness run with the user message in the wakeup
5. Record the interpretation and the action taken in the timeline

Parallel tracks

• Authority patches
• Deterministic-control interpretation
• Harness-routed strategy instructions
• Clarification flow and timeline rendering

Outputs

• MissionModificationService with versioned authority patches
• Deterministic-control interpretation layer
• Clarification handling for ambiguous exposure changes
• Conversational pause, resume, and revoke
• Timeline entries linking interpretation to action

Acceptance

• Authority patches are enforced immediately and reflected in the next run
• Unambiguous risk-reducing instructions map onto deterministic controls without a harness turn
• Ambiguous exposure-changing messages trigger clarification before any change
• Conversational pause, resume, and revoke reuse the deterministic primitives
• Strategy instructions are routed through the bound harness

Tests

• Authority-patch immediate-enforcement contract tests
• Deterministic-control mapping table tests for the §5.4 examples
• Ambiguity clarification test: exposure change is blocked until resolved
• Conversational pause/resume/revoke parity with the deterministic buttons
• Conversation-to-timeline correlation tests

Docs

• MissionModificationService source
• Interpretation and clarification rules
• Conversation-to-control mapping catalogue
• Handoff summary for PROMPT-08

Context

• PROMPT-07 full control and conversation surface
• T3 Trades §18 Persistence and recovery and §4.5 immutable provider binding
• T3 Trades §20 Phase 8 and §21.4 harness conformance
• T3 Trades §21.5 upstream sync regression and §7.13 acceptance gates

Inspect

• Persistence records from §18 and their migration path
• Provider session start, resume, and availability behavior per provider
• Reconciliation triggers from §18.2
• The fork sync runbook and patch ledger from PROMPT-00

Constraints

• No provider failover, swapping, or cross-provider mission transfer
• A provider is exposed in the trading selector only after it passes conformance independently
• A T3 restart may restore continuity; a provider failure moves the mission to agent_unavailable
• Do not switch providers automatically on recovery
• Upstream sync acceptance gates from §7.13 must hold

Tasks

• Implement startup recovery per §18.3: restore account, mission, binding, strategy, authority, watches; reconnect; reconcile; resume timers; queue one run if material events occurred; resume the original provider
• Implement reconnection recovery that restores subscriptions and canonical state before resuming
• Implement the agent_unavailable state: preserve protection, continue monitoring, block new discretionary entry, allow retry, pause, close, or revoke
• Run Codex conformance before enabling Codex: tool discovery, strategy publishing, watch registration, turn-end-while-active, same-session resumption, mission and version preservation, rejected execution handling, partial-fill reconciliation, pause and revoke behavior, no raw wallet request
• Run Claude conformance before enabling Claude using the same matrix
• Run OpenCode conformance before enabling OpenCode using the same matrix
• Build the upstream sync regression suite per §21.5 and the §7.13 acceptance gates

Steps

1. Implement and drill startup and reconnection recovery
2. Define and verify the agent_unavailable transition and its allowed exits
3. Run each provider through the §21.4 conformance matrix one at a time
4. Gate each provider in the selector until its matrix passes
5. Assemble the upstream sync regression suite and run it against one sync batch
6. Confirm no provider substitution occurs in any recovery path

Parallel tracks

• Startup and reconnection recovery
• Agent-unavailable state
• Per-provider conformance (Codex, Claude, OpenCode)
• Upstream sync regression suite

Outputs

• Startup and reconnection recovery paths
• Agent_unavailable state and allowed user exits
• Conformance evidence for each enabled provider
• Upstream sync regression suite
• Provider gating in the trading selector

Acceptance

• Restart restores mission, watches, risk reservations, and provider binding
• Reconnection restores subscriptions and canonical state
• Provider failure moves the mission to agent_unavailable without substituting providers
• Each provider is enabled only after passing the conformance matrix independently
• One upstream sync integrates without rewriting trading modules and passes the regression suite

Tests

• Restart recovery integration test asserting full state restoration
• Reconnection reconciliation test after WebSocket loss
• Agent_unavailable transition and no-substitution test
• Codex, Claude, and OpenCode conformance matrices per §21.4
• Upstream sync regression suite per §21.5
• §7.13 acceptance-gate checklist for one sync batch

Docs

• TradingRecovery source
• Per-provider conformance reports
• Upstream sync regression suite
• Final POC acceptance evidence map against §22