# WWW Project Revision / Documentation > **Canonical location since 2026-09-26:** https://docs.datasetis.info/ > > The former old-server /var/www/tredercopis/data/www/docs tree is retained as migration/archive source and must not be cleaned until the server migration and evidence-preservation audit are complete. Last revision: 2026-09-23 This directory is the root-level documentation and revision index for the domains under `/var/www/tredercopis/data/www`. Purpose: keep the project architecture, domain ownership, research decisions, important changes, safety boundaries and current work understandable without reconstructing them from chat history. ## Current mandatory handoff For a new chat/session, use `NEW_CHAT_BOOTSTRAP.md` as the startup protocol. It explicitly requires the chat to read the architecture, handoff and LAB docs through workspace tools before answering from memory. For the current CombatSolo capital-gate research, the mandatory action is AUDIT FIRST: inspect the existing LAB infrastructure before creating or extending capital-gate code. For DEMO/LIVE execution architecture and Jeffrey qualification, `DEMO_LIVE_EXECUTION_ANCHOR.md` is mandatory. Core invariant: DEMO LONG/SHORT is the primary trading/decision contour; LIVE LONG/SHORT mirrors DEMO `OPEN/CLOSE` journal events. Jeffrey currently validates DEMO first; LIVE keys are intentionally deferred until DEMO LONG, DEMO SHORT, concurrent operation, TRADE CONFIG reload and profile switching are proven stable. ## Server access / PHP runtime - Canonical project root: `/var/www/tredercopis/data/www`. - Canonical CLI PHP for project maintenance, migrations, lint and manual verification: `/opt/php84/bin/php` (PHP 8.4 runtime). Do not assume the shell-default `php` points to the project runtime; it may be an older system PHP and can produce misleading syntax errors. - Workspace/assistant access is guarded and project-relative: normal inspection is read-only until an explicit guarded mutation is requested; writes/patches/moves/deletes require their corresponding confirmation mode. Arbitrary shell execution is not exposed through the guarded workspace bridge. - When an operator must run a manual server command, provide a complete command rooted at `/var/www/tredercopis/data/www` and explicitly use `/opt/php84/bin/php` for PHP operations. ## Domain map ### datasetis.info — DATASET / data plane Central provider and owner of market/data contracts. Owns Parser0/1/2, Coin Passport, orderbook/market history, Wave/regime runtime and related normalized data. Consumers should use DATASET contracts/data rather than independently inventing equivalent source state. ### tredersolo.online — SOLO / laboratory Research and testing domain. Correct place for historical replays, profile generation, feature research, robustness/holdout studies and other heavy analysis. Guarded tasks are fixed/allowlisted; arbitrary shell/PHP execution is intentionally not exposed. ### combatsolo.info — CombatSolo / strategy consumer Trading/profile domain. Consumes DATASET information and qualified research results. Runs LONG/SHORT strategy/profile logic, SHADOW evaluation and trading-facing state. Heavy historical research should not be attached to normal trading ticks merely to obtain execution access. ### tredercopis.click — CLICK / execution-validation surface Execution/demo/validation boundary used by guarded tick/self-test and related strategy execution checks. Keep research workloads separate from the trading/execution cycle. ## Current research direction The project is moving from searching for one permanent formula to maintaining a league/pool of LONG and SHORT SHADOW profiles. Profiles may fit different recurring market regimes. All qualified SHADOW profiles continue to collect results in parallel; a selector can later choose the currently strongest profile for LIVE with minimum sample, rolling evidence and hysteresis/cooldown to avoid rapid switching. Profile quality is not defined by WR alone. Evaluate WR, Traffic, LOSS reduction/capture, WIN damage, expectancy/PnL after costs where available, sample confidence, temporal holdout, causal historical replay and rolling forward behavior. Approximate WR targets such as ~65% are references, not immutable gates. Avoid both zero-traffic overfilters and high-traffic profiles that preserve too many losses. ## Data / research flow `DATASET -> SOLO LAB -> research reports/profile candidates -> CombatSolo SHADOW -> rolling evidence/selector -> LIVE` Training and holdout alone do not silently promote a profile to LIVE. ## Current important work — profile league and DEMO selection DATASET now maintains persistent LONG/SHORT SHADOW profile leagues and immutable generated-profile Library entries. Combat Profile Generator can create a single aligned LONG+SHORT HSCAN package over 1/2/3/4/6/12/24h with AUTO formulas and COMPETE/SHADOW handling. Training metrics describe construction only; Champion selection remains governed by common-forward evidence and eligibility gates. Combat DEMO has an explicit selection mode per strategy: - `AUTO` (also the backward-compatible default when the field is absent) follows the current eligible DATASET SHADOW rank #1. - Activating a completed generated profile sets `MANUAL`, records the manual profile ID and prevents the master cron from replacing it. - `Вернуть Champion AUTO` clears the manual ID and immediately resumes rank-1 following. - These controls are DEMO-only. DEMO metadata is removed before LIVE settings hashing/publication, and the activation path does not mutate or promote LIVE. The lowercase generated-ID filename mismatch is fixed by case-insensitive profile-ID resolution in the DATASET Library fallback. PHP 8.4.3 syntax checks and an isolated real-class behavior test pass for case-insensitive lookup, MANUAL hold across a cron application, AUTO return and no LIVE mutation. The first natural post-deploy master tick completed successfully. ## 2026-09-15 — DEMO LONG generation queue repair LONG DEMO execution is operational: the natural production tick completed, the separate DEMO key and Bybit transport were healthy, LONG managed one open Buy position with a protective Sell stop, and the scan completed without errors. The actual blocker was in the shared hourly profile-generation queue: after DATASET returned terminal REJECTED for a specific LONG request, reconciliation checked a different globally latest active request, leaving the rejected LONG row locally QUEUED and selecting it repeatedly. `DatasetProfileGenerationRequest::reconcile()` now optionally reconciles an exact request ID, and `ProfileGenerationQueueWorker` passes the ID it just ticked. Existing three-argument UI callers remain backward-compatible. First post-deploy master tick: COMPLETE; the stuck LONG request changed to REJECTED, active requests decreased 1494 to 1493, and the worker advanced to the next fresh-cohort request. Trading rules and SHORT execution were not changed; LIVE was not mutated. Changed files: `combatsolo.info/engine/strategies/dataset_profile_generation_request.php`, `combatsolo.info/engine/strategies/profile_generation_queue_worker.php`. A second LONG control defect was found and repaired the same day. DEMO AUTO alternated between the DATASET rank leader and a `freshScore` override whenever the currently selected LONG profile was classified as falling, producing a `24H -> 6H -> 24H` loop on consecutive ticks. `DatasetChampionControl::leader()` is now deterministic: among eligible, execution-compatible profiles it sorts by DATASET rank, then ranking score and profile ID. Operator anti-stuck blocking remains supported. Natural post-patch ticks held `LONG_HSCAN_6H_20260909_1900_FDC29A` with `current_profile == target_profile`, `reason=SAME_PROFILE`, and no settings/profile sync required. LONG DEMO remained enabled with two managed Buy positions; SHORT logic, risk settings and LIVE state were not mutated. Changed file: `combatsolo.info/engine/strategies/dataset_champion_control.php`. ## Earlier important work — LONG_WINPROTECT_R2 `LONG_WINPROTECT_R2` is a modern PHASE_GEO_V2 SHADOW profile. Construction sample: 64 causal rows, 26 WIN / 38 LOSS; 0/26 WIN blocked and 17/38 LOSS blocked; sample Traffic ~73.44%. These are construction-sample numbers, not historical replay results. A dedicated causal historical Traffic replay is being built for 2026-08-21 through 2026-09-04. It uses historical/as-of DATASET information and must report missing coverage instead of substituting current state. Guarded task: `long_winprotect_r2_history_replay`. First server invocation proved the new SOLO allowlist/dispatch path worked but exposed an unnecessary handler include; that include was removed. Self-test then passed with LIVE submit disabled and no side effects. The next full invocation reached execution but timed out at the gateway (504); no final historical report was produced. Therefore no historical R2 Traffic claim should be made yet. Next work is to optimize or stage the replay rather than retry the same expensive implementation indefinitely. ## Safety state at this revision - Generated/HSCAN training remains descriptive and SHADOW-only; it is not a LIVE qualification claim. - Current DEMO selection defaults to Champion AUTO unless the operator explicitly activates a generated profile in MANUAL. - At the first natural post-deploy tick (2026-09-09 04:57:53 UTC), LONG remained `LONG_ROLL24H_G7_20260908_1839` and SHORT remained `SHORT_ROLL24H_G2_20260908_0709`, both `ALREADY_CHAMPION`. - The DEMO MANUAL/AUTO change did not mutate or promote LIVE; isolated verification reported `live_untouched=true`. - The master tick completed with `ok=true`, status `COMPLETE`, DATASET operational/approved and no DATASET error. ## Documentation convention from now on Every material architecture/research/runtime change should update this root documentation in the same work session. Record: date; domain; what changed; why; files/tasks involved; measured result; safety impact; next step. Do not rely on chat history as the project record. Detailed domain/research notes may remain inside each domain's own `docs/` directory, but this root directory is the revision entrypoint and should link/summarize the important state. See `REVISION_LOG.md` for chronological changes and `DOMAIN_MAP.md` for domain responsibilities.