Implementation Roadmap

This page tracks the remaining backend/product silos for the SQLite rewrite and Clash of Clones product loop. It is intentionally high level: detailed API shapes and table contracts live in the linked contract docs.

Related:

• Clash Of Clones Product Spec
• Backend Contract
• Product Controls

Progress Snapshot

Percent complete is approximate and should be updated as implementation scope changes.

Silo	Status	Approx. complete	Next checkpoint
Data Ingestion Pipeline	In progress	90%	Host-level alerts and deployment tuning
Clone Strategy Configuration	In progress	70%	Review Latest Data drawer and graph-editing UX against live data
Trading Runner	Started	45%	Production scheduler, locking, retry handling
Trading Engine	Started	55%	Paper fills, positions, and account mutation
Prop Trading Infrastructure	Planned	10%	Audition, Arena, race, and ticket lifecycle state machines
Personal Wallet Infrastructure	Not started	0%	Decide wallet ownership, balances, and risk separation
Auth And Ownership	Started	30%	Replace temporary x-user-id with identity mapping
Observability And Operations	Started	25%	Worker/source health, decision latency, backup checks

Core Silos

1. Data Ingestion Pipeline

Global source ingestion into shared SQLite market memory.

Status:

• Hyperliquid ingestion is mostly in place for allMids mid prices, 1-minute OHLC candles, liquidity, funding, volatility, and positioning context.
• Polymarket discovery/context ingestion is in place at the registry and summary layer.
• DefiLlama macro ingestion is in place for capital base, capital flows, and economic throughput.
• Ingestion health tracking and health API are in place.
• Manual retry/backfill commands are documented.

Remaining:

• Host-level alert wiring for failed, stale, or missing channels.
• Production cadence tuning after live observation.
• R2/archive policy for large raw payloads, if needed.

2. Clone Strategy Configuration

User-facing configuration for clone strategy building blocks.

The canonical graph is:

Data Stream Block -> Asset Block -> Trading Prompt Block -> Trading Clone Block

Status:

• Pipeline graph format exists.
• Data stream, asset, trading prompt, and clone blocks exist in the workflow UI.
• Workflow load/save now syncs the legacy clone into SQLite and persists graph edits through the backend pipeline API.
• The visual Trading Clone Block position and prompt-to-clone connection now round-trip through pipeline layout metadata.
• Asset blocks can open a Latest Data drawer backed by the same context resolver used for decisions.
• Asset blocks are simplified to asset identity, enabled/paused state, latest-data review, and exchange links.
• Prompt inclusion, retrieval depth, lookback, granularity, and datapoint controls are represented.

Remaining:

• Move strategy, risk, and execution behavior into Trading Prompt Block controls.
• Keep Basic, Custom, and Power User modes as views over the same graph.
• Remove old clone/trader labels that do not match the domain language.

3. Trading Runner

Scheduler/worker layer that decides which clone, strategy, and asset should run.

Status:

• Decision worker loop exists.
• Local run-once command exists.
• Cadence is evaluated per clone/branch/asset.
• No-op hold engine exists for safe storage testing.
• Model-backed dry-run engine can call Anthropic when configured.
• Decision run history API and workflow Trading History panel exist.
• Dry-run safety gate validates actions and writes execution audit rows.

Remaining:

• Production scheduler process.
• Lease/lock behavior so two workers do not run the same due asset.
• Retry and failure handling.
• Admin controls for pausing clones or source families.

4. Trading Engine

The deterministic decision path that converts configured data into a trading action.

SQLite market memory
-> effective context resolver
-> prompt assembly
-> model call
-> action validation
-> decision/action storage

Status:

• Effective context resolver exists.
• Pipeline preview can compile read plans and context packets.
• Decision run/action storage exists.
• Model-backed prompt assembly exists.
• Anthropic Messages API support exists behind DECISION_MODEL_PROVIDER=anthropic.
• Model responses are parsed as strict JSON actions.
• Actions are validated against candidate asset, confidence, enabled state, and compatibility execution defaults while prompt-owned execution controls are wired.
• Execution audit tables exist for accounts, orders, fills, positions, and ledger events.
• Validated executable actions create dry-run order rows; rejected actions write rejection ledger rows.
• Default local mode remains no-op hold.

Remaining:

• Stable prompt templates.
• R2 storage for full context, prompt, model response, and reasoning payloads.
• Paper fill simulation and position mutation.
• Additional safety gates for daily loss, drawdown, leverage, and account equity.

5. Prop Trading Infrastructure

Audition, Promotion Queue, Clash Arena, race cadence, ticket sales, settlement, retirement, and prop-style accounting.

Status:

• Domain language is documented.
• Product spec is documented in Clash Of Clones Product Spec.
• Decision/action rows exist, but prop accounting is not built.

Remaining:

• Audition state machine.
• Audition Fee payment flow.
• Public clone identity and moderation state.
• Profit target and pass/fail rules.
• Promotion Queue and Arena slot management.
• Race accumulation, launch, live, settling, settled, and archive lifecycle.
• Ticket purchase accounting for the single accumulating race.
• Pool split accounting: 5% protocol rake, 5% creator pool, 90% ticket-holder distribution pool.
• Weighted parimutuel payout calculation.
• Creator royalty calculation.
• Demand-based retirement strikes and Hall of Fame preservation.
• Synthetic race account, PnL, drawdown, orders, fills, positions, and ledger tables.
• Exchange order/fill/position reconciliation only for later real-wallet or live-trading boundaries.

6. Personal Wallet Infrastructure

User-owned wallet trading outside the prop/audition flow.

Status:

• Not designed yet.

Remaining:

• Decide whether this shares the same trading engine with prop trading.
• Wallet ownership and auth model.
• Deposit/withdrawal/account-linking flow.
• Personal risk limits and ledger model.
• Separation from prop trading balances and permissions.

Supporting Silos

Auth And Ownership

The target backend should own users, clone ownership, and auth identity mapping. Current development endpoints can use x-user-id, but production should resolve external identities into backend users.id.

Observability And Operations

Track ingestion health, worker health, decision latency, failed model calls, failed executions, SQLite growth, backup status, and R2 archive writes.

Frontend Migration

Move the current controls/workflow UI from local or legacy state into the new backend API without creating a second source of truth.

Suggested Build Order

1. Test the history API against real dry-run model runs locally.
2. Add paper fill simulation and position/account mutation.
3. Add production scheduler locking and retry behavior.
4. Add R2 artifact storage for full context/prompt/response payloads.
5. Add audition state and synthetic account windows.
6. Add race lifecycle and per-race synthetic account resets.
7. Add ticket accounting and settlement math.
8. Add Promotion Queue, Arena slots, retirement, and Hall of Fame.
9. Add personal wallet infrastructure after prop execution primitives are stable.