Brummel/Aura
1
0
Fork 0
Code Issues 31 Pull Requests Actions Packages Projects Releases Wiki Activity

Live/deploy edge: cTrader Open API adapter + forward-trading recording (ground-truth currency) #149

New Issue
Open
opened 2026-06-28 11:58:27 +02:00 by Brummel · 1 comment
Brummel commented 2026-06-28 11:58:27 +02:00
Owner
Copy Link
Copy Source

Per the 2026-06-28 C10 rework (ledger commit 29cdc8c): money, a real broker, and real friction are a separate, later live/deploy-edge concern — the only reliable ("belastbare") ground truth, measured, never modelled. Historical friction is not knowable (the retired "realistic broker" was horseshoe-throwing); the research loop stays R-pure with the cost-model graph.

Scope (design-open, later):

  • A live execution adapter to a real broker (cTrader Open API) that, in forward-trading (demo or real), executes a frozen strategy's orders and records the real fills (slippage, commission, swap, spread) → real currency equity.
  • Fits C11 (record-then-replay: real fills recorded live, replayable) and C13 (frozen deploy = frozen bot + broker connection). Reconciliation with the real account is an external I/O adapter at the recording / deploy edge — not an in-graph node.
  • The position-event table (event_ts, action, position_id, instrument_id, volume) is the deploy / reconciliation record here (real volume). The account / deal model (netting vs hedging; deal = target − book − in_flight, a close sizes the actual book) is designed at this edge.
  • Compounding / fixed-fractional sizing / Kelly-f / currency P&L live here — derived post-hoc / analytically from the net-R distribution, or measured live — never in research.

CONSENT BOUNDARY: a live broker connection is an outward-facing, real-account action. cTrader has demo accounts for safe forward-testing; the user's external-service consent rule (~/.claude/CLAUDE.md) applies — no live calls without explicit per-session consent. Forward-trading takes real calendar time and yields non-stationary statistics.

Design-open: needs a brainstorm when picked up.

Per the 2026-06-28 C10 rework (ledger commit `29cdc8c`): money, a real broker, and real friction are a **separate, later live/deploy-edge** concern — the only reliable ("belastbare") ground truth, **measured, never modelled**. Historical friction is not knowable (the retired "realistic broker" was horseshoe-throwing); the research loop stays R-pure with the cost-model graph. Scope (design-open, later): - A live execution adapter to a real broker (**cTrader Open API**) that, in **forward-trading** (demo or real), executes a frozen strategy's orders and **records** the real fills (slippage, commission, swap, spread) → real currency equity. - Fits C11 (record-then-replay: real fills recorded live, replayable) and C13 (frozen deploy = frozen bot + broker connection). Reconciliation with the real account is an external I/O adapter at the recording / deploy edge — not an in-graph node. - The position-event table (`event_ts, action, position_id, instrument_id, volume`) is the deploy / reconciliation record here (real volume). The account / deal model (netting vs hedging; `deal = target − book − in_flight`, a close sizes the actual book) is designed at this edge. - Compounding / fixed-fractional sizing / Kelly-f / currency P&L live here — derived post-hoc / analytically from the net-R distribution, or measured live — never in research. CONSENT BOUNDARY: a live broker connection is an outward-facing, real-account action. cTrader has demo accounts for safe forward-testing; the user's external-service consent rule (`~/.claude/CLAUDE.md`) applies — no live calls without explicit per-session consent. Forward-trading takes real calendar time and yields non-stationary statistics. Design-open: needs a brainstorm when picked up.
Brummel added the idea label 2026-06-28 11:58:27 +02:00
claude commented 2026-07-21 10:36:42 +02:00
Collaborator
Copy Link
Copy Source

Re-anchoring note, no scope change.

This issue's design-open scope is still accurate and still unbuilt. Two structural facts have changed since it was filed (2026-06-28) that are worth recording for whoever picks it up:

  1. The design ledger now names this issue's target crate position explicitly. C28 ('Internal stratification: the trading ladder, the process column, the shell', docs/design/INDEX.md) defines a six-rung ladder and places this work at rung 6, 'execution': "money, account-term sizing, the live broker; already exiled to the deploy edge by C10/C13, existing today only as that ratified boundary." No crate exists for it yet — the c28_layering structural test (crates/aura-vocabulary/tests/c28_layering.rs) enumerates engine/market/measurement/strategy/backtest/execution as the full ladder, with 'execution' still undelivered. When this issue is brainstormed, its crate lands at that rung, importing aura-backtest (and nothing importing it back, per the C28 import rule).

  2. The prerequisite this issue names — the position-event table as the deploy/reconciliation record — has since shipped on the research side. PositionAction/PositionEvent and derive_position_events live in aura-backtest (exercised in crates/aura-engine/tests/position_event_table.rs and crates/aura-engine/tests/r_sma_e2e.rs), delivered under #114, with the sibling cost-model graph closed under #148. A future cTrader adapter consumes that existing table rather than designing it from scratch.

Separately: cycle #295 (aura-runner/aura-measurement extraction) and the decided document-first direction (#300, 'Complete the document-first migration') do not change this issue's scope — neither touches the execution rung. But per the ratified C25 amendment (control surfaces are projections over text-artifact vocabulary, never a second home for intent), any control surface this issue eventually needs for forward-trading (starting/stopping a live session, selecting demo vs real account) should be designed as document vocabulary in that pattern, not as bespoke CLI flags.

No action needed now; this is a pointer for the eventual brainstorm, not a scope change.

Re-anchoring note, no scope change. This issue's design-open scope is still accurate and still unbuilt. Two structural facts have changed since it was filed (2026-06-28) that are worth recording for whoever picks it up: 1. The design ledger now names this issue's target crate position explicitly. C28 ('Internal stratification: the trading ladder, the process column, the shell', docs/design/INDEX.md) defines a six-rung ladder and places this work at rung 6, 'execution': "money, account-term sizing, the live broker; already exiled to the deploy edge by C10/C13, existing today only as that ratified boundary." No crate exists for it yet — the c28_layering structural test (crates/aura-vocabulary/tests/c28_layering.rs) enumerates engine/market/measurement/strategy/backtest/execution as the full ladder, with 'execution' still undelivered. When this issue is brainstormed, its crate lands at that rung, importing aura-backtest (and nothing importing it back, per the C28 import rule). 2. The prerequisite this issue names — the position-event table as the deploy/reconciliation record — has since shipped on the research side. `PositionAction`/`PositionEvent` and `derive_position_events` live in aura-backtest (exercised in crates/aura-engine/tests/position_event_table.rs and crates/aura-engine/tests/r_sma_e2e.rs), delivered under #114, with the sibling cost-model graph closed under #148. A future cTrader adapter consumes that existing table rather than designing it from scratch. Separately: cycle #295 (aura-runner/aura-measurement extraction) and the decided document-first direction (#300, 'Complete the document-first migration') do not change this issue's scope — neither touches the execution rung. But per the ratified C25 amendment (control surfaces are projections over text-artifact vocabulary, never a second home for intent), any control surface this issue eventually needs for forward-trading (starting/stopping a live session, selecting demo vs real account) should be designed as document vocabulary in that pattern, not as bespoke CLI flags. No action needed now; this is a pointer for the eventual brainstorm, not a scope change.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BLOCKER
Core functionality blocked; preempts other selection
 bug
Observable misbehaviour
 feature
Substantial extension; no full spec required
 idea
Droppable; no commitment
No Label idea
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude (Claude) Brummel
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/Aura#149
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?