# DEMO / LIVE EXECUTION ANCHOR

Date: 2026-09-25
Status: CURRENT ARCHITECTURE / TESTING RULE

## Core rule

There are only two trading strategies: LONG and SHORT.

DEMO and LIVE are execution modes, not separate strategies.

The authoritative execution relationship is:

`DEMO LONG/SHORT -> trading decision + position lifecycle -> DemoSignalJournal OPEN/CLOSE -> LIVE LONG/SHORT mirrors those signals`

LIVE is the mirror/follower of DEMO. DEMO is NOT a mirror of LIVE.

Do not reverse this relationship in future analysis or documentation.

## DEMO responsibilities

DEMO is the primary trading/decision contour for each strategy direction. It must:

- scan/evaluate entries;
- open DEMO positions;
- manage already-open DEMO positions;
- apply the strategy risk lifecycle (hard stop, profit floor/lock, trailing and normal close logic as implemented);
- write authoritative strategy OPEN/CLOSE events to `DemoSignalJournal`;
- continue collecting strategy/runtime evidence used by profile/shadow logic.

A DEMO `OFF`/maintenance state for NEW entries must not abandon already-open positions. During safe maintenance, existing positions continue their old-config lifecycle until natural FLAT.

## LIVE responsibilities

LIVE is an execution follower of DEMO signals. It must:

- consume DEMO `OPEN/CLOSE` journal events;
- mirror those actions on the LIVE account when the corresponding LIVE key/mode is available and enabled;
- keep execution/reconciliation and emergency protection required by the LIVE runner;
- not invent an independent strategy decision path that diverges from DEMO.

Capital-gate or config-maintenance logic may block NEW LIVE OPEN actions, but must not prevent required management/CLOSE of already-open LIVE positions.

## Key model

The intended production key layout is four separate roles per client:

- DEMO LONG
- DEMO SHORT
- LIVE LONG
- LIVE SHORT

One key has one role. LONG and SHORT must not collide/net through the same role/account unintentionally.

## Jeffrey current test state — 2026-09-23

Jeffrey engine id:

`live_51d8719f3b4dd6849d031842`

Current testing state after client version `2.0.75`:

- Jeffrey is the only Combat implementation currently being built/tested;
- DEMO LONG and DEMO SHORT are both present; LIVE keys/modes remain intentionally OFF during qualification;
- safe TRADE CONFIG reload is under active qualification for both directions;
- SHORT has already reached FLAT and moved into requalification during the current test;
- LONG drain can remain in `DRAINING` while old-config DEMO positions are still owned/open;
- operator manual DEMO close is available per position and is a valid way to finish an abnormally long drain without using `RESET DEMO`;
- absence of LIVE orders/positions while LIVE is intentionally OFF/NO KEY is EXPECTED and is not a mirror failure.

Do not treat `NO KEY`, LIVE OFF, or absence of LIVE positions as an error while Jeffrey is in DEMO-only qualification.

## Qualification order before enabling LIVE

LIVE must remain out of scope until DEMO qualification is complete.

Required order:

1. DEMO LONG: verify repeated full cycles `SCAN -> OPEN -> manage -> CLOSE`.
2. DEMO SHORT: install/enable and verify repeated full cycles independently.
3. DEMO LONG + DEMO SHORT together: verify no role/key/profile/state collision and correct concurrent behavior.
4. TRADE CONFIG safe reload: verify several times for both directions:
   `STOP NEW -> WAIT NATURAL FLAT -> APPLY -> REQUALIFY -> RESUME`.
5. Verify AUTO/profile switching for LONG and SHORT separately and together.
6. Only after stable DEMO qualification, connect LIVE LONG/LIVE SHORT keys.
7. Then verify end-to-end mirroring:
   `DEMO OPEN -> journal OPEN -> LIVE OPEN`
   and
   `DEMO CLOSE -> journal CLOSE -> LIVE CLOSE`.

Do not enable LIVE early merely to test whether DEMO works. DEMO must be proven first because LIVE follows DEMO.

## TRADE CONFIG maintenance rule

Changing TRADE CONFIG is a safe strategy/system reload, not a forced liquidation command.

Intended flow:

`CONFIG REQUEST -> stop NEW decisions/orders -> keep existing DEMO/LIVE positions managed on old config -> natural FLAT -> flat-only reset -> apply new config -> requalify compatible profiles when risk changed -> restore previous mode -> resume`

Important:

- do not force-close positions merely because TRADE CONFIG changed;
- while maintenance is pending, block only NEW entries where appropriate;
- existing DEMO/LIVE positions continue their normal old-config lifecycle until natural FLAT;
- after risk changes, old incompatible profiles remain immutable history but must not be selected as compatible current profiles;
- when requalification completes, restore the pre-change DEMO/LIVE enabled state automatically.

### Operator close during prolonged drain

Natural FLAT remains the default behavior. However, an operator may manually close an individual DEMO position when `DRAINING` has become operationally too long.

Rules:

- use the existing per-position `Закрыть` action; it submits the normal DEMO reduce-only market close through `StrategyManualPositionControl`;
- successful submission returns `CLOSE_SUBMITTED`; final position removal/PnL/ownership completion occurs on subsequent tick/reconcile, so the UI may lag briefly after the command is accepted;
- while close is pending, do not repeatedly submit the same position merely because a stale table row is still visible;
- manual close is NOT `RESET DEMO`: it does not mean reset all positions/statistics and must not be documented as a reset path;
- after the last blocking ownership position reaches terminal/FLAT state, TRADE CONFIG transition proceeds normally to APPLY/REQUALIFY/RESUME;
- a brief mismatch such as KPI/open-count already decreased while the positions table still shows the old row is a UI freshness issue, not proof that the close failed.

LIVE remains a conditional mirror, not a requirement that every DEMO position exists in LIVE. A DEMO `OPEN` may be skipped in LIVE because of key/mode, margin, limits, gate or other execution conditions. Therefore a DEMO `CLOSE` must affect LIVE only when the corresponding DEMO trade has an actual active LIVE mirror/ownership; absence of a LIVE mirror must not trigger a blind close by symbol.

## System-wide MAINTENANCE

System-wide service stop/cleanup is defined separately in `docs/MAINTENANCE_CONTROL_ANCHOR.md`.

Pinned semantics:

- `MAINTENANCE STOP` blocks all new DEMO entries and switches LIVE OFF for future entries;
- already-open DEMO and LIVE ownership continues normal management until terminal/FLAT;
- LIVE OFF during maintenance must not stop management of already-open LIVE positions;
- after full system FLAT, archive historical evidence, reset active DEMO statistics/runtime/diagnostic telemetry, and start a new telemetry epoch;
- after cleanup the system remains READY/stopped until explicit `START DEMO SYSTEM`;
- `START DEMO SYSTEM` may restart DEMO only; LIVE remains OFF until explicitly enabled by the user;
- MAINTENANCE is distinct from TRADE CONFIG reload and from RESET DEMO.

## Testing interpretation

When validating Jeffrey DEMO-only state, prove the DEMO chain itself:

`SCAN -> signal -> DEMO OPEN -> position management -> DEMO CLOSE`

Do not require a LIVE mirror observation until LIVE keys are intentionally enabled.

When LIVE testing begins later, the proof target changes to:

`DEMO journal event -> LIVE executor consumes same event -> matching LIVE execution/reconciliation result`.

A reject on one symbol is not automatically a system-wide trading failure. Distinguish an instrument/order reject from failure of the DEMO/LIVE architecture.

## Implementation source-of-truth safety

Jeffrey current code/runtime is the canonical source for active Combat behavior.

The DOMAIN `combatsolo.info` is currently free/reserved and may later host a clean Jeffrey copy/instance. Old code/runtime snapshots historically associated with `combatsolo.info` are reference-only; they must not override current Jeffrey code/runtime conclusions and must not be reused as active staging/runtime state.

## Anti-confusion rules for future chats

- Never say DEMO mirrors LIVE.
- Never describe LIVE as an independent strategy generator unless current code explicitly changes that architecture.
- Never call absence of LIVE trades an error when no LIVE key is installed/enabled.
- Never infer SHORT state from LONG state; verify each direction independently.
- During Jeffrey DEMO qualification, focus on DEMO behavior first.
- Before changing execution logic, verify current Jeffrey code/runtime first; consult `combatsolo.info` only as historical reference when needed.
- If current code contradicts this document, code wins and this document must be updated in the same work session.