Watch

History

Repository files (latest commit first)
Filename	Latest commit message	Latest commit date
AnimateDread 652bf81112 fix(db): per-side pattern journaling + versioned journaling semantics The labelMatchesVote gate compared a single last-writer-wins label (LongCondition then ShortCondition) against the net vote sign, which structurally censored the pattern tables: a long event co-occurring with any short-side state model lost its label to the later writer and was dropped, while the mirrored short event journaled fine. Ichimoku models 0/3 and MA model 1 could not produce a row at all by construction (MA model 1 was "revived" in `8710240` yet still could never journal - its weight-10 vote is exactly cancelled by the opposing Pattern_0 state), and every pattern's win rate was measured on a with-trend-only subset - the exact statistic UpdateSignalsWeights() feeds back into the weights, self-sealing: no rows -> no win rate -> default weight -> still censored. - Direction() now evaluates the two ladders separately and snapshots each ladder's matched pattern into its own side slot; each side that matched journals its own row. The flat-vote poisoning the old gate fixed stays fixed: a label can no longer contradict its side. - The filter's net vote (raw pattern-weight units) is stored as a new netVote column - data, never a drop filter. Snapshot is keyed on the ladder setting a label, not on its weight, so a 0%-win-rate pattern keeps journaling and can recover. - SIGNAL_DB_SEMANTICS_VERSION is folded unconditionally into the DB filename fingerprint: pattern-definition changes (`b2069bc`, `8710240`) re-key the database instead of blending incompatible Pattern_N populations under one key, which the input-hash fingerprint cannot see. 7 months of mixed-semantics rows shared one file because of it. - dbVersion 2.0 -> 3.0: schema changed, and inserts carry the new column, so the version-mismatch folder wipe is the migration. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>		2026-08-12 10:37:57 -04:00
..
README.md	feat: Enhance README and documentation for Warrior_EA project	2026-04-20 19:28:34 -04:00
signalInfoStructure.mqh	fix(db): per-side pattern journaling + versioned journaling semantics	2026-08-12 10:37:57 -04:00
TradeRecordStructure.mqh	fix(db): per-side pattern journaling + versioned journaling semantics	2026-08-12 10:37:57 -04:00

README.md

Structures Subsystem (Structures/)

Overview

The Structures/ directory contains data structure definitions used throughout the Warrior EA for organizing and passing trading-related information. These structures are essential for maintaining clean, modular, and testable code, especially as the system evolves toward AI/ML-driven logic.

Key Components

signalInfoStructure.mqh

Struct: SignalInfo
Purpose: Encapsulates all relevant information about a generated trading signal.
Fields:
- year, month, day, DOW, hour, minutes: Timestamp of the signal.
- tableName: Source or context table for the signal.
- pattern: Name or type of the detected pattern.
- direction: Trade direction (e.g., buy/sell).
- entryPrice: Price at which the signal was generated.

TradeRecordStructure.mqh

Struct: TradeRecord
Purpose: Stores all relevant information about a completed trade.
Fields:
- year, month, day, day_of_week, hour, minutes: Timestamp of the trade.
- pattern: Pattern or strategy used for the trade.
- direction: Trade direction (buy/sell).
- entryPrice: Entry price for the trade.
- exitPrice: Exit price for the trade.
- result: Outcome/result of the trade (e.g., win/loss).

Integration Notes

These structures are used for logging, analytics, and passing data between subsystems (signals, database, AI/ML modules).
Consistent use of well-defined structures improves maintainability and supports future AI/ML integration.

Documented April 2026. For further details, see the main project documentation and AI_NETWORK.md.