# NEXT CHAT HANDOFF — READ THIS FIRST

> **Canonical documentation root:** https://docs.datasetis.info/ (migrated from the old server www/docs on 2026-09-26).
> The old www/docs remains a read-only migration/archive source until cleanup is explicitly audited.


Date: 2026-09-25
Scope: CombatSolo / Jeffrey DEMO qualification + DATASET capital-gate research
Status: Jeffrey DEMO qualification active; LIVE keys intentionally deferred until DEMO LONG+SHORT+switching pass

## Mandatory first step

Before proposing or writing any capital-gate module, audit the existing LAB infrastructure and current code/data. New-host migration target: systematize LABs under the same `SOLO Research Plane` (`tredersolo.online`) while preserving research evidence. Cleanup may reorganize/deduplicate topology, but must not silently lose experiment tools, manifests, frozen datasets, reports, conclusions, negative results or provenance.

Jeffrey portability was rechecked in current code. `DatasetRuntimeClient` uses authenticated HTTPS/API to a configurable `dataset_control.base_url` (default `https://datasetis.info`) for runtime passports/profiles, so Jeffrey is architecturally a portable user engine and may live on a different server from DATASET. One current `DatasetShadowLeagueConsumer` path still tries a sibling `../datasetis.info` filesystem tree first and falls back to HTTPS; treat that as a same-host shortcut/legacy optimization and remove/disable it in the clean 2.1.0 baseline so DATASET access is network-contract only.

New-host bootstrap bridge status (2026-09-26): server side is live and verified at `https://tesh.combatsolo.info/bridge/`, proxied by ISPmanager/nginx to `127.0.0.1:8765`, service `jeffrey-bridge.service`. Bearer token remains only on the new host at `/etc/jeffrey-bridge/token` and must never be copied into docs/chat. Authenticated `/health` returns HTTP 200; unauthenticated public access returns 401.

A separate MCP sidecar is live at `https://tesh.combatsolo.info/mcp`, proxied to `127.0.0.1:8766`, service `jeffrey-mcp.service`, using MCP Streamable HTTP. Initial no-auth bootstrap exposed `bridge_ping`; OAuth 2.1 protection was then added and verified end-to-end on 2026-09-26. The server publishes protected-resource metadata and OAuth authorization-server metadata, supports DCR, authorization-code + PKCE S256, refresh tokens, and rejects unauthenticated `/mcp` with HTTP 401 + `WWW-Authenticate`. A compatibility bug with `mcp==1.26.0` was fixed: `AuthorizationCode`/`RefreshToken` do not expose `.subject`, so the single-owner provider now uses the fixed owner identity instead. After that fix, ChatGPT successfully authenticated and invoked `bridge_ping`, receiving `{ok:true, service:"jeffrey-server-bridge", mode:"oauth-bootstrap-readonly", version:"0.2-mcp"}`. That mode label is now stale/misleading: `root_exec` has subsequently been exported and verified from ChatGPT, executing successfully with `uid=0(root)`, user `root`, cwd `/opt/jeffrey-mcp`, rc=0. Therefore the MCP-enabled chat now has real temporary root bootstrap capability and should continue with the non-destructive Phase A server audit before any migration. This old chat remains the historical/context source.

Next migration work in the MCP-enabled chat: OAuth and temporary root bootstrap are already complete and verified. Use `docs/NEW_SERVER_BOOTSTRAP_ROOT_MCP_RUNBOOK.md` as the canonical control runbook and `docs/NEW_SERVER_STORAGE_AUDIT_2026-09-26.md` as the current storage source of truth. The storage audit classifies both Samsung PM981a 1 TB NVMe devices as `WARNING / endurance exceeded, drive still operational`, NOT `replacement required`; both report Available Spare=100%, Media/Data Integrity Errors=0, no read-only bit, normal temperatures, no PCIe errors, and md0/md1/md2 are clean `[UU]` with failed=0, degraded=0, mismatch_cnt=0. Therefore keep the existing RAID/layout unchanged and use this host as a temporary migration/production host with enhanced monitoring/off-host backups and reduced unnecessary write-heavy backfill. IMPORTANT CURRENT PLATFORM STATE: only the ISPmanager `Web server (WWW)` stack has been installed so far. Do NOT begin DATASET migration yet. First finish the complete base-server build and application runtime preparation: verify/update Debian, required utilities, storage/monitoring, firewall/access model, users/directories/ownership, nginx/ISPmanager layout, PHP/PHP-FPM versions and exact extensions actually required by current DATASET/SOLO/Jeffrey code, Composer only if required, systemd/cron runner model, logging/logrotate, backup/restore path, TLS/Cloudflare origin behavior, and service/resource limits. Only after the base host is declared READY FOR APPLICATIONS should migration begin, with DATASET first, then SOLO Research Plane/LAB, then Jeffrey clean 2.1.0 with LIVE OFF / NO KEY. Keep migration documentation updated after each material change/domain cutover and preserve checksums, source/destination paths, freeze/delta timing, rollback state, and verification evidence.

Source-of-truth order:
1. ACTIVE CODE
2. CURRENT RUNTIME / DATA
3. CURRENT DOCS
4. PRIOR RESEARCH / CHAT
5. INFERENCE

Do not reconstruct architecture from memory when code/data/docs already exist.

## Safety boundary

- 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 project code/runtime snapshots historically associated with `combatsolo.info` are historical reference only and must never override current Jeffrey evidence.
- Do not use stale historical `combatsolo.info` snapshots as staging/scratch space or as active migration state.
- Do not modify trading logic during the audit unless explicitly requested.
- Jeffrey is the only Combat implementation currently being built/tested; client patches must be staged separately and targeted to the intended engine.

## Current Jeffrey execution state — do not make the owner re-explain this

Read `docs/DEMO_LIVE_EXECUTION_ANCHOR.md` before discussing execution behavior.

Authoritative model:

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

DEMO is the primary trading contour. LIVE is its execution mirror/follower. DEMO does not mirror LIVE.

Current Jeffrey engine: `live_51d8719f3b4dd6849d031842`.

As of client `2.0.75`:
- DEMO LONG and DEMO SHORT are both present and under qualification;
- LIVE remains intentionally OFF/NO KEY, so no LIVE mirror trade is expected yet;
- safe TRADE CONFIG reload is being exercised for both directions;
- during the current test SHORT reached FLAT and moved into requalification while LONG remained in `DRAINING` because old-config DEMO positions were still open/owned;
- per-position DEMO manual close is now verified through the normal page POST path and returns `CLOSE_SUBMITTED` when accepted;
- do not diagnose `NO KEY`, LIVE OFF, or absence of LIVE positions as a trading failure during this DEMO-only phase.

Required validation order before enabling LIVE:
1. DEMO LONG repeated `SCAN -> OPEN -> manage -> CLOSE` cycles.
2. DEMO SHORT repeated full cycles.
3. DEMO LONG + SHORT concurrently without key/state/profile collision.
4. Repeated safe TRADE CONFIG reload for both directions: `STOP NEW -> WAIT NATURAL FLAT -> APPLY -> REQUALIFY -> RESUME`.
5. AUTO/profile switching for LONG and SHORT separately and together.
6. Only then connect LIVE LONG/LIVE SHORT keys and verify `DEMO journal OPEN/CLOSE -> matching LIVE OPEN/CLOSE`.

Do not modify the original DEMO/LIVE trading contour merely to test reload behavior. Config maintenance may block NEW entries, but existing positions must continue normal old-config management until natural FLAT.

Operational close rule during prolonged `DRAINING`:
- natural FLAT is still the default;
- operator may use the existing per-position DEMO `Закрыть` action when waiting becomes operationally excessive;
- accepted manual close returns `CLOSE_SUBMITTED` and is finalized by later tick/reconcile; a short UI delay/stale row is expected and is not a reason to resubmit immediately;
- manual per-position close is distinct from `RESET DEMO` and must not reset the whole strategy/statistics;
- once all blocking ownership positions are terminal/FLAT, TRADE CONFIG continues through APPLY -> REQUALIFY -> RESUME.

LIVE is a conditional mirror of DEMO signals, not a one-for-one inventory guarantee. LIVE may skip DEMO OPENs because of key/mode, margin, max-position limits, capital/config gates, bans, etc. A DEMO CLOSE must act on LIVE only when the matching DEMO trade actually has an active LIVE mirror/ownership; no blind symbol-level LIVE close.

LIVE execution architecture is pinned separately in `docs/LIVE_EXECUTION_SHADOW_ANCHOR.md`: current Jeffrey implementation remains the source of truth; historical `combatsolo.info` confirms the earlier separation between real Bybit LIVE execution and a separate `live_sim` chain simulator. Target architecture for Jeffrey is explicit `LIVE REAL` + separate `LIVE SHADOW/LIVE_SIM` ownership linked to DEMO by stable mirror/trade ids. Shadow must never be stored as real ownership. Full MAINTENANCE implementation should wait until LIVE REAL + LIVE SHADOW ownership/FLAT semantics are verified sufficiently to avoid DEMO-only FLAT assumptions.

Jeffrey 2.1.0 LIVE coin-profitability filtering is pinned in `docs/LIVE_COIN_FILTER_ANCHOR.md`: LONG and SHORT eligibility are independent; DEMO remains the sensor; weak/near-zero DEMO symbol-side performance may block only the corresponding REAL LIVE mirror while DEMO keeps collecting evidence for recovery/unban. Profitability filtering is distinct from manual/safety/technical bans, and the old ambiguous single `Общий ban монет` model must not be treated as the target architecture.

Jeffrey 2.1.0 UI/information architecture is pinned in `docs/UI_INFORMATION_ARCHITECTURE_ANCHOR.md`. The current `/combatsolo/strategies/` page is the canonical design reference. A 2026-09-25 generated mockup, `Jeffrey 2.1.0 · Разнос UI-компонентов (план)`, is accepted as a probable candidate / NOT FINAL visual reference for the likely component split: Strategies home, simplified strategy detail, separate Symbol Ban/Coin Filter, separate Profile Generator, dedicated LIVE Control, and simplified Events/Logs. Exact cards/metrics remain adjustable after LIVE qualification. Strategy detail pages are currently overloaded with independent modules; 2.1.0 should eventually promote Symbol Ban/Coin Filter, Profile Generator and LIVE Control to first-class navigation/components and keep strategy pages focused on strategy-local state/actions. Avoid duplicate hidden layouts and duplicated data surfaces.

IMPORTANT IMPLEMENTATION PRIORITY: after the clean 2.1.0 baseline is up, LIVE REAL + LIVE SHADOW must be implemented/qualified FIRST. UI/component moves and information-architecture cleanup come AFTER LIVE is working and observable. Do not delay LIVE qualification in order to move existing modules around the UI.

Full current Jeffrey backup audit is pinned in `docs/JEFFREY_BACKUP_AUDIT_2026-09-25.md`. The supplied ISPmanager backup confirms the active outer tree is Jeffrey 2.0.76; a stale nested `combatsolo/combatsolo` copy, release backups, runtime/telemetry/history, old installers/hotfix bundles and real secret-bearing state are present in the source backup. A sanitized clean seed and separate no-secrets evidence layer were produced. Canonical clean-seed identity is persisted in `docs/assets/JEFFREY_CLEAN_SEED_2.0.76.manifest.json`: artifact `jeffrey-clean-seed-2.0.76.tar.gz`, size `320278` bytes, SHA256 `bdfd98d1c1e2bbd37fca3772ee240db460257ea6feedfee7da363a9613ee267d`; source backup `aziku043 (4).tar.gz`, SHA256 `0c7ed7e59a00aa78720473f3d0a7052c242f099f9288a12823ec581d7f119b95`. The current project bridge could not ingest the binary archive directly from the ChatGPT sandbox, so during new-host bootstrap copy that generated artifact through the new bridge if available, or regenerate it from the verified source backup and revalidate against the documented cleanup rules. The backup snapshot itself was mid-TRADE-CONFIG DRAINING (LONG demo_open_remaining=3, SHORT=1), so snapshot ownership/positions/pending transition must remain evidence only and must not be activated on the new host. Bybit keys/bindings are excluded and will be re-entered manually; DATASET system auth must be securely re-provisioned bridge-to-bridge or re-registered.

Version/migration boundary is now pinned:
- current production/testing line remains `Jeffrey 2.0.x` and is treated as the stable DEMO/migration baseline;
- only critical bugfixes should be added to 2.0.x before migration;
- the clean engine on the new host starts as `Jeffrey 2.1.0`;
- 2.1.0 starts without migrated API keys/secrets and without old active runtime/telemetry clutter;
- keys are re-entered manually after migration to validate the fresh key-storage/validation path;
- LIVE remains OFF/NO KEY at initial 2.1.0 boot;
- LIVE REAL + LIVE SHADOW development/qualification begins on the new host after the clean 2.1.0 baseline is verified.

System-wide MAINTENANCE design is pinned in `docs/MAINTENANCE_CONTROL_ANCHOR.md`:
- MAINTENANCE means safe stop of the whole system plus active DEMO stat/runtime/telemetry cleanup after FLAT;
- STOP blocks all new DEMO entries and switches LIVE OFF for future entries;
- existing DEMO and LIVE positions continue normal management even while LIVE is OFF for new entries;
- wait for real ownership FLAT, then archive historical evidence and clean active-epoch DEMO statistics/runtime/diagnostic telemetry;
- introduce a new telemetry epoch so old reject/order-calc markers cannot repopulate as current state;
- after cleanup remain READY/stopped until explicit `START DEMO SYSTEM`;
- START DEMO may re-enable DEMO only; LIVE must remain OFF until explicitly enabled by the user;
- this is separate from per-strategy TRADE CONFIG reload and from RESET DEMO.

## Current research question

We want a separate top-level capital permission mechanism:

`DEMO equity -> ACTIVE / SLEEP / WAKE -> permission for NEW LIVE entries`

Read `docs/CAPITAL_GATE_RESEARCH_ANCHOR.md` before analysis.

## Non-negotiable model

- DATASET passport + profiles + filters + bans + shadow logic already interpret market conditions.
- DEMO stays always on and continues adapting/testing.
- Capital gate does NOT re-analyze the market.
- Capital gate does NOT rank or switch individual profiles.
- Gate observes resulting DEMO equity/system output.
- SLEEP blocks only NEW LIVE entries.
- Existing LIVE positions keep normal stop/trailing/floor/protection lifecycle unless a separate explicit policy is created.
- Technical discontinuities must not be treated as strategy degradation.
- Parser2 may validate data continuity, but is not the gate trading signal.
- Replay decisions must be causal and use only information available BEFORE a candidate LIVE entry.

## Audit task for the next chat

Do not create a third research framework first.

At minimum inspect:
- `lab.combatsolo.info`
- research LAB modules under `tredersolo.online/modules/*lab*`
- `docs/LAB_INDEX.md`
- `docs/LAB_HISTORY_FINGERPRINT.md`
- existing replay/state-machine/equity/failover research and datasets

Then determine:
1. Purpose and data sources of both LAB families.
2. Existing equity/regime/switching/failover/state-machine work.
3. Existing replay engines and historical datasets relevant to DEMO equity.
4. Whether ACTIVE/SLEEP/WAKE or equivalent capital permission already exists under another name.
5. Which existing LAB should own this research.
6. Duplicated, obsolete, dead, or conflicting mechanisms.
7. Reuse/extension versus genuinely missing code.

Do not mutate code during the audit unless the user explicitly asks for implementation after reviewing the audit.

## Prototype warning

A provisional research probe exists:
- `datasetis.info/tools/research_equity_capital_gate.php`

Treat it as disposable research code, not canonical architecture or production logic. Do not expand/promote it until the LAB audit is complete.

A previous replay mistake filtered by state at trade CLOSE time and overstated performance. That result is invalid. Correct evaluation decides permission at ENTRY time only.

## Current useful finding

The broad idea remains plausible: allow LIVE only while the resulting DEMO system curve is healthy, and sleep during sustained deterioration. Naive fixed high-watermark thresholds are not yet proven sufficient. Research should focus on robust curve-shape deterioration/recovery and stability across windows, not one optimized PnL point.

## Required response style

Report evidence from existing code/data first, with concrete paths. Clearly separate:
- what already exists;
- what is active;
- what is historical/dead;
- what is inference;
- what is actually missing.

Do not make the user re-explain the capital-gate concept before beginning the audit.