Author	SHA1	Message	Date
AnimateDread	97f0631e28	feat(baselines): combining-weight fit, MLP cross-validation, all-lags correlation ... Three ALGLIB additions, all measurement-only and all under the existing Run_Alglib_Baselines switch. MinBLEIC COMBINING WEIGHTS. The live ensemble weights each member by its own pooled holdout win rate - a defensible prior, but not a fit, and nothing has ever asked what mixture minimises error on the bars the members disagreed about. Two individually-mediocre members wrong in different places can beat one individually better, and a per-member win rate cannot express that because it never looks at them jointly. Solved on the simplex (w >= 0, sum w = 1), which is exactly what MinBLEIC is for. Non-negative because a negative weight asserts "trade the opposite of this member", a claim ~60 effective observations cannot support. Least squares on the signed outcome rather than precision: precision is a STEP function of the threshold that no gradient method can walk, and optimising a smooth proxy for a step decision is how c3daded put every operating point 14pp underwater - so the result is reported in BOTH currencies, the SSE it minimised and the directional hit rate the mixture would actually have scored against the equal mix. If the second does not improve, the first is noise. This needed data that did not exist: g_ensVoteSum accumulates member contributions and the sum destroys the decomposition, while g_ensVoteVoterMask records only WHETHER a member voted, never what. g_ensVoteMember[] keeps them unsummed. The live arithmetic is untouched. ENS_MAX_MEMBERS is 8 and deliberately larger than MAX_AI_SIGNALS (5): independent caps, over-allocating is free, and matching them would make this array silently short the day the registry grows - a cap that has already dropped a member once without saying so. MLPKFoldCVLBFGS. Every baseline row carries a binomial SE, which is the sampling error of SCORING a fixed model and says nothing about how much the FIT moves. One LBFGS run from one random start can land anywhere, and a baseline that cleared or missed the bar on luck of initialisation reads exactly like one that did it on merit. 3 folds, because each is a full retrain. LBFGS not LM - LM builds a Hessian over ~7,700 weights. CCorr ALL-LAGS PROFILE. Added BESIDE the MI lag profile, not instead: MI catches nonlinear dependence and is the stronger negative, which is why it settled the verdict - but its per-lag permutation null limits it to ~20 lags. FFT correlation gets every lag in one O(n log n) pass, so linear structure parked at lag 300 would surface for free. Different question, not a replacement. Walks CONTIGUOUS bars, unlike everything else in this file, because a lag index is meaningless otherwise; both series are mean-centred first since CorrR1D is a raw sum of products; and the max over columns x lags is judged against a Sidak family of exactly that size, not a bare 2-sigma line. fasttransforms.mqh needed its own include - verified that none of ap/optimization/statistics/solvers/linalg reaches it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 07:44:36 -04:00
AnimateDread	19e3595e20	fix(build): g_eta - the learning rate global no longer shadows a stdlib local ... MetaEditor: "declaration of 'eta' hides global variable" (Math.mqh:792 vs Network.mqh:80). The standard library's Math\Stat\Math.mqh declares a local `double eta` in its incomplete-gamma branch, and our bare global of the same name is in scope there. Same fault as the b1/b2/lr/momentum macros retired in ea2552e: a single-token global name living in a header that library code gets compiled beside. The library cannot move, so ours does - 112 references across 13 files, whole-word only. Named g_eta rather than g_learningRate to stay inside the vocabulary already around it (ETA_DECAY_FACTOR, ETA_MIN, m_etaCeiling, etaBefore), all of which are untouched and none of which shadow anything. One log line said "continuing to explore without decaying eta", where the word was prose rather than a symbol reference; that reads "the learning rate" now instead of naming a variable at the trader. Scanned for the next occurrence rather than waiting for it: the only other bare lowercase globals in the tree are eaName and tableschema, both distinctive enough not to collide with a library local. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 07:00:09 -04:00
AnimateDread	561c88e6d4	feat(baselines): geometry-drift check on the derived stop ... DeriveBarrierGeometry() reads the stop off a quantile of the adverse excursions in the IS region ONLY - correctly, since a geometry chosen with the holdout in view has used the holdout for selection and it stops being a holdout. The cost of that correct choice is that nothing ever checked whether the distribution it measured still holds on the bars the model actually trades. If adverse excursions run wider in the OOS window than in the IS region, the derived stop is too tight for the market it is used in, every label was cut on the wrong geometry, and the deploy gate certified a game the trade is not playing - the 2026-08-09 geometry mismatch arriving through drift rather than through a config error. Reported in TWO currencies deliberately. A rank-test p says whether the distributions differ; it does not say whether anyone should care. The stop each half's own quantile would derive says exactly that, in ATR multiples - the units the order is placed in. A significant p with both stops on the same ladder rung is a curiosity; half an ATR of movement is a problem whether or not it clears 0.05. Declustered first, same as the regime test: overlapping labels are not independent draws. Harvest guards are copied from the deriver's own so the two describe the same sample - and the split is verified identical (totalIter == bars - historyBars, so Train's oosCutoff and the deriver's are the same number). Runs before the two model fits and needs only the excursion caches: a chart too thin to fit a forest can still have drifted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 00:34:55 -04:00
AnimateDread	90c6e26e94	feat(rng): ALGLIB's L'Ecuyer generator replaces MathRand, and a seed collision goes with it ... MQL5's MathRand() is the 15-bit MSVC LCG - 32768 distinct values and the lattice structure that shape of generator has. Two places here actually lean on randomness and both were hurt by it: WEIGHT INIT. Six He/LeCun-uniform sites drew ((MathRand()+1)/32768.0 - 0.5) * 2 * scale, so a first dense layer of ~250k weights had only 32768 possible values and thousands of connections started byte-identical. Breaking that symmetry is the whole job of random init. SHUFFLING. ShuffleRandomIndex() already had to splice TWO MathRand() draws to reach 30 bits, and its own comment documented the residual modulo bias it still carried. HQRndUniformI() is rejection-sampled and exactly uniform, so the splice and the bias note both go. CHighQualityRand is L'Ecuyer's combined multiplicative congruential generator - two differenced streams, 31-bit output, period ~2.3e18 - and it ships with the terminal. AND A BUG THE MIGRATION EXPOSED. The three MathSrand(GetTickCount()) calls sit immediately before "build a fresh topology", once per model. GetTickCount() steps in ~15.6 ms on Windows and an ensemble builds every member inside one OnInit, so members could be handed the SAME seed and draw the SAME weights wherever their shapes coincide - and members that start identical are not an ensemble. WarriorRandSeed() takes a salt (the model id) plus a never-reset call counter, so a collision is impossible rather than merely unlikely, while the tick keeps the run itself genuinely unrepeatable the way those call sites asked for. Seeds are masked positive rather than trusted: HQRndSeed computes s % (M-1) + 1 and MQL5's % keeps the sign, so a negative seed leaves the generator in a state its own assertions reject. GetTickCount() is a uint and goes negative as an int after ~24 days of uptime - a fault that would surface as "training is broken" on a long-running terminal and nowhere else. The indicator tuner's 52 draws move across too: its random search is where sample quality earns its keep. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 00:29:12 -04:00
AnimateDread	36254dcd55	feat(baselines): matrix redundancy and a declustered regime test ... Two ALGLIB diagnostics on the pass that already builds the matrix, under the same Run_Alglib_Baselines switch, so they cost nothing by default and share one walk of the feature pipeline. REDUNDANCY (CBaseStat::PearsonCorrM + CPCAnalysis::PCABuildBasis). The alt-data block already produced this finding once, by hand: 13 features x 16 window slots = 208 inputs spanning ~11.5 effective dimensions, and the cost was not wasted parameters but a gradient weighting bias, since batch norm rescales collinear copies without decorrelating them. This generalises that measurement to every column instead of the one block someone thought to check. Run on the ANCHOR BAR'S ROW, not the full window. The window is m_historyBars near-copies of the same columns at different lags, so per-bar redundancy is the question worth asking - the lag structure is what the conv/LSTM stage exists to exploit - and it keeps the eigensolve at ~60x60 rather than ~960x960. REGIME STABILITY (CMannWhitneyU::CMannWhitneyUTest) on the net's own signed margin: its conviction, signed by whether the conviction paid, older half of the OOS window against newer. DECLUSTERED FIRST, which is the whole reason this is not a one-line call. Triple-barrier labels overlap, so consecutive scored bars share the price action that resolved them and are not independent draws. Feeding all of them to a rank test yields a p computed on an n it does not have - the same error label overlap invalidated everywhere else here. One sample per label horizon costs most of the rows and buys a p that means something; when too few survive, it says so and declines. Both report and neither acts. Wiring the regime flag to position sizing is the obvious next step and the one to take only after watching the number: run every era on ~60 effective observations, a 0.05 test crosses by chance regularly, and an auto-derisk on that is a random position size generator. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 00:01:34 -04:00
AnimateDread	5cf706dfd6	refactor(kiss): lift the model fingerprint out of InitNeuralNetwork ... InitNeuralNetwork() was 673 lines and the fingerprint assembly - the single most audited block in the file, since its hash decides when a trained model may be resumed and when it starts again from era 0 - sat in the middle of it with no name of its own. BuildModelFingerprint() is now that block, moved line for line. Its header states the two rules the per-field notes have been repeating one at a time for months: measured quantities never enter (the .cfg carries those, adopt-don't-compare), and new fields append conditionally so shipping one does not re-key models that never use the feature. The assembly is byte-identical - verified by diffing every `fp =`/`fp +=` line against HEAD, which differ only by the new call site. So no existing .nnw/.cfg re-keys and nothing retrains. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 23:50:30 -04:00
AnimateDread	ce2c324527	feat(baselines): Alglib forest + linear on the NN's own matrix ... Every direction verdict so far was measured through one architecture family, so "flat" has two readings that no topology tuning can separate: the net is the wrong learner, or the matrix carries no directional information. Two learners with completely different inductive biases - Alglib's random decision forest and an ordinary least-squares fit - now train on the SAME feature windows (BuildFeatureWindow, the net's own function, so there is no second feature implementation to drift), the SAME labels, the SAME IS/OOS split with both purges, and are scored through the SAME precision-against-always-one-direction comparison and the same Sidak family-wise arithmetic the deploy gate uses. If both also land at chance, the matrix is the limit. Deliberate choices, each of which could have made the comparison a different question wearing this one's name: - LRBuild, not LRBuildZ: the intercept absorbs the class imbalance, and a baseline handicapped by a forced zero intercept would flatter the net for the wrong reason. - Raw call counts in the SE, matching the live gate's known-permissive test rather than correcting it here - both sides must face the same bar. - No threshold sweep on the linear fit: a threshold fitted on the slice being scored is the calibration leak the purged band exists to avoid. - Uniform stride when a cap bites, not the newest N rows, so a score difference cannot be a regime difference. What was dropped is logged. Ships off (Run_Alglib_Baselines = false): it is a measurement, not a trading feature, nothing trades on the answer and no model is saved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 23:45:03 -04:00
AnimateDread	77594ef5fb	refactor(stdlib): one quantile definition, from Math\Stat ... The codebase had THREE conventions for the same statistic. AltData took a true median; the barrier horizon and the derived input window took the upper of the two middle values; the MI terciles and the barrier stop ladder used nearest-rank indexing. All four now go through MathMedian / MathQuantile, which is R's type 7 and the library's one answer. System\AltData.mqh column median -> MathMedian (exact, no change) AIBase\Labels.mqh swing median -> MathMedian leg-range med -> MathMedian stop ladder -> MathQuantile, read in one call AIBase\Topology.mqh window median -> MathMedian AIBase\AutoTune.mqh MI terciles -> MathQuantile + MathMin/MathMax Signals\SignalSessionFilter DST last Sunday-> CDateTime::DaysInMonth() gaps[]/legs[] change from int to double so MathMedian can read them; the values are bar counts either way. VALUES MOVE. Even-sample medians shift by half a bin and the quantile reads interpolate, so the barrier geometry and the derived input window can land on different rungs - re-keying fingerprints and forcing a retrain. Accepted deliberately: stdlib consistency was the ask, and three private conventions for one statistic is what it buys out. Two YAGNI finds fell out of the ladder rewrite. MathQuantile sorts its own copy, so DeriveBarrierGeometry no longer sorts up[]/dn[] in place - which means upUnsorted[], a full array copy kept only to undo that sort, is gone. ArraySort(up) had no consumer needing order at all; it was pure work. The library call also gets a failure guard the hand-rolled indexing never needed but the ladder read does. Verified while here: Math\Stat\Math.mqh's MathAbs/MathMax/MathSqrt/MathPow and friends are ARRAY overloads, not scalar redefinitions, so pulling it into the translation unit shadows no builtin. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 20:16:03 -04:00
AnimateDread	29c82ad50b	refactor(dry): one binomial arithmetic for every "is this edge real" test ... The formula p(1-p)/n was transcribed nine times across six files - the two deploy gates, the two edge floors, the collapse recall floor, the barrier rung ladder, the inference bin SE, the pooled inverse-variance weights and both detectability reports. System\BinomialStats.mqh now holds it once, as free functions with no class dependency, so the god-class declaration does not grow to host pure math. BinomialVar(p, n) p(1-p)/n BinomialSEPct(p, n) 100*sqrt(p(1-p)/n) BinomialCallsForEdge(p, edge, sigmas) the same, solved for n NormalUpperTailQ(z) Q(z), via Math\Stat\Normal.mqh SidakFamilyP(z, N) 1-(1-Q(z))^N Value-preserving by construction: rates go in as probabilities so no call site gained a *100/100 round-trip, and BinomialSEPct is written through BinomialVar so the multiply order is the one it replaced. Every degenerate guard each site carried (p<=0, p>=1, n<=0) now lives in one place and returns the 0 those sites already treated as "no bar to clear". CExpertSignalAIBase::NormalUpperTail is gone; NormalUpperTailQ replaces it. What consolidating SURFACED, and is deliberately NOT changed here: the two Sidak selection gates compute their SE on the RAW call count, while every other SE in the project deflates by EffectiveSampleSize() for triple- barrier label overlap. That makes them the most permissive test in the codebase, by ~sqrt(mean label lifespan). Correcting it tightens a live deploy bar, which is a policy decision, not a refactor - flagged in the code at both sites. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 19:50:24 -04:00
AnimateDread	ea2552efe2	refactor(stdlib): adopt Math\Stat for the deploy gate's normal tail; retire the b1/b2/lr/momentum macros ... The gate's NormalUpperTail was a hand-rolled Abramowitz & Stegun 26.2.17 approximation. Its own comment gave the reason - "drags a chain of headers behind it" - and that turned out to be one file: Math\Stat\Normal.mqh includes only Math.mqh, which includes nothing. Swapped for Cody's rational approximation in the library (~18 significant digits vs |error| < 7.5e-8). No past verdict changes: at the z the gate operates on, the difference is orders of magnitude below DEPLOY_FAMILY_WISE_ALPHA. Adopting it needed the four bare macros in AI\Network.mqh gone first. "#define b1 AdamBeta1" collides with an identifier in Math.mqh, so the include would have macro-expanded the library's own local and failed to compile - the same landmine that made the original author rename the approximation's coefficients to ntB1..ntB5 rather than use the reference's b1..b5. lr, b2 and momentum are the same class of hazard: single-token global macros in a 52k-line codebase. All four now resolve to the input names they always aliased, which is a pure textual identity - verified zero bare occurrences remain. Also: - SelectionSort over the buffered signals was O(n^2) with an O(n^2) count of StructToTime calls, because the comparison rebuilt both datetimes from the six int date fields every time. Now materialises the keys once and does an insertion sort; ArraySort cannot permute a struct array. IsEarlier goes with it, MakeDateTime becomes SignalTime. - Seven FileOpen sites lacked FILE_SHARE_READ|FILE_SHARE_WRITE, including AtomicWriteBegin, which stages every model save. All 43 sites now carry them - an exclusive open fails outright when another process holds the path, which here has meant a silently skipped save. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 19:31:36 -04:00
AnimateDread	61c0d19ca9	feat(indicators): run the built-in iMA and MetaTrader's ZigZag; add a classic-vote shift ... MA: CustomIndicators\ADMovingAverage is replaced by the built-in iMA (CiMA) on both consumers - the classic vote and the NN MA input feature. This drops the five advanced types ALMA/DEMA/ZLEMA/T3/Kalman, which have no iMA equivalent; MA_TYPE_PRESETS is now ENUM_MA_METHOD's own codes and the tuner searches all four. It also removes a documented failure mode: a custom indicator's depth is bounded by TERMINAL_MAXBARS, and m_MA was the one whose feature block REJECTS the bar on a short read - the "feature 25 fails on every bar" incident of 2026-08-17. A built-in is served at any depth. MIGRATION. SMA moves from code 5 to 0, so persisted type codes change meaning. SanitizeMaType() is the single validity rule; TunedPeriods records now carry a version field and a v1 record remaps 5..8 -> 0..3, falling back to SMA for a stored advanced type (unrecoverable - old 0..4 are indistinguishable from valid new codes). Existing .nnw files re-key on their own, because MA_Type is hashed into the topology fingerprint, so models retrain rather than silently running on different MA values. EXPECT A FULL RETRAIN. ZigZag: ADZigZag was a byte-identical rename of MetaQuotes' Examples\ZigZag - verified by normalising identifiers and stripping comments, 233 significant lines each with only renamed symbols differing. It now loads the stock one, so nothing is bundled and MetaQuotes' fixes arrive without a rebuild here. Both #resource entries are gone. Classic_Shift: a new input, the BAR the four classic votes evaluate on (0 = forming, 1 = last closed, default 1). One implementation on CExpertSignalCustom, inherited by all four rather than repeated per module. Defaults to a sentinel meaning "unset", so the AI signals and the aggregate keep the stock every_tick rule and their feature/label alignment is untouched. The META corpus sweep still takes precedence. CExpertBase::StartIndex turns out to be virtual, so this is a real override, not the name-hiding the old comment claimed. Not compiled - MetaEditor compile pending. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 19:09:58 -04:00
AnimateDread	552edb5fb1	refactor(yagni): drop 13 accessors nothing called; unify the ATR trailing pair ... Verified dead by grep across all first-party sources (references/, Scripts/, research/ excluded): EraCount, HiddenLayersCount, LstmHiddenSize, ConvFilterCount, HistoryBars and MinTrainYear setters, PendingBatchSamples, getPrevOutIndex, BaseCurrency, QuoteCurrency, CurrencyCount, IsLoaded, LastFiredDirection, DBConfidence, SpecIndex, and the conv Step/WindowOut shape accessors. Every backing member stays - each is still read internally and several are pinned by the positional .cfg layout - so this removes surface, not behaviour. Two comments were asserting the opposite of the code and are now true: the "No setter: the taper's endpoints are derived" note was directly above three setters, and the conv shape block claimed EnforceTopologyContract reads all three accessors when CNet::FirstConvWindow only ever calls Window(). CTrailingATR::CheckTrailingStopLong/Short were byte-identical but for Bid vs Ask and the isLong flag; both now delegate to one CheckTrailingStop body. Deliberately NOT removed: the fractal-target branch (TrainTargetFractal, IsFractalTarget and their label machinery). It reads as dead because the TrainingTarget input was withdrawn, but Warrior_EA.mq5:836 documents it as a parked option with a three-line restore path - that is a product call, not a refactor. Not compiled - MetaEditor compile pending. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 18:55:36 -04:00
AnimateDread	2be2970434	fix(topology): the capacity budget counted overlapping bars as independent examples ... EstimatedInSampleBars() returned raw bars (11372 on SP500 H4) and every derived capacity decision spent that: first-layer width, conv filters, LSTM hidden size. But triple-barrier labels overlap - mean lifespan 9.4 bars - so the label cache line on the same run already reports those bars are worth ~1210 independent observations. Sizing a network against RAW bars while grading it against EFFECTIVE ones is two subsystems disagreeing about one sample, and it disagreed in the dangerous direction because the capacity side was the optimistic one: the warning's "roughly 1.1 weights per training bar" is nearer 11 per independent observation. EffectiveSampleSize() has existed since 2026-08-17 and is applied at eight sites, all of them statistics. This adds the ninth, in the one place that decides how many parameters get fitted. Applied inside EstimatedInSampleBars() rather than at the call sites, because that function exists precisely so the three stages spend one budget. SELF-ENABLING AND THEREFORE INERT WHERE IT MATTERS MOST, which is why this is two changes and not one. MeanLabelLifespan() is 1.0 until a label cache has measured something, so on a model's first build - before any label exists - the deflation is correctly the identity: an unmeasured overlap must not invent a shrink. A fresh attach constructs a fresh object, so its counters are zero too; only a mid-session weights reset carries real evidence into a rebuild. That is deliberately safe (no attach can now re-derive a narrower topology and discard trained weights) but it would have left the first build - the case you most want the truth for - quoting the flattering figure. So ReportDetectability now restates capacity against the effective sample at the first moment L is real, for the topology already pinned. It re-sizes nothing; it reports what was bought. Placed ABOVE that function's break-even guard on purpose - a degenerate geometry is exactly when you want to know the net is over-parameterised, and "it only fires for sane configs" is how the 2026-08-18 IS-error stop managed never to fire at all. The warning also names its basis now (independent observations and L, or an explicit "overlap NOT YET MEASURED, this is an UPPER BOUND"), so a flattering number can never again read as a measured one. Also factors FirstLayerFanIn() out of ComputeFirstLayerWidth so the capacity REPORT charges for exactly what the capacity DECISION charged for - same reason RequiredHorizonBars was factored out after the 2026-08-17 divergence - and makes MeanLabelLifespan()/EffectiveSampleSize() const so the const budget path can call them. Verified: no recursion (EstimatedInSampleBars -> EffectiveSampleSize -> EstimatedInSampleBarsRaw, which computes from Bars() alone); both new StringFormat sites hand-counted (basis 3/3 and 1/1, CAPACITY 10 specifiers / 10 arguments). NOT COMPILED - user compiles in MetaEditor.	2026-08-19 18:43:48 -04:00
AnimateDread	caad156464	fix(geometry): the ratio raise was reported against reachability, not bounded by it ... First clean derivation after 6f2def0 produced stop 1.22 / target 4.86 = 1:4 on SP500 H4, and the labels came out Buy 4.3% / Sell 6.1% / Neutral 89.6% - a 20.7:1 imbalance, against 3.4:1 at 1:2 and 1.5:1 at 1:1 on the identical 10601 excursions. That is the class-collapse regime, not a geometry. c3daded proposed ONE leg-implied ratio per rung and left the reachability floor to REJECT the rung, with a comment claiming the raise was "bounded" by it. Rejection is not a bound. The 5.09*ATR median leg proposed 1:4 at every stop, all seven rungs then missed their own floor (0.7%-9.6% against 12-20%), the no-rung-clears fallback fired and re-proposed the same 1:4 at the tightest rung - and printed a WARNING predicting exactly the rare positive class that followed. The system diagnosed itself correctly and had no authority to act on it: the same shape as the scan-vs-deriver split c3daded fixed one layer up, reintroduced one layer down. Why the full leg overshoots: a ZigZag leg is pivot-to-pivot travel and an entry is not a pivot - it lands inside the leg, with roughly half of it left on average. Sizing the target at the whole median leg asks the market to deliver, from an arbitrary bar, the entire move it usually makes between extremes. Rather than assume the half and hard-code a factor, the raise now steps DOWN the snap ladder (5 -> 4 -> 3 -> 2.5 -> 2) until the first-passage ladder says the target is actually reached, stopping at the 1:2 policy floor because that is risk policy and not a measurement. The legs still raise the ratio wherever the travel supports it; the market decides how far. Applied in BOTH the rung loop and the fallback branch - omitting the fallback is what actually shipped the 20.7:1 labels, since that branch runs precisely when no rung was reachable. Rung rows now print "[legs proposed 1:R, unreached]" so a walked-back raise is visible as one. Verified: BarrierStepDownRr is strictly decreasing and bottoms at the floor, so both loops terminate; rung-row StringFormat re-counted at 18 specifiers / 18 arguments. NOT COMPILED - user compiles in MetaEditor.	2026-08-19 17:04:32 -04:00
AnimateDread	6f2def0605	fix(geometry): a weights reset could never change the barrier - the pair laundered itself through the wipe ... Reported as "it still seems leaned towards 2x atr" after a full Delete && Reset Weights on SP500 H4. It was not the .cfg pin, and it was not the new ratio floor failing to take: the geometry is held in members ResetWeights never cleared, so a reset wiped the .cfg, built a fresh net, restarted at era 0 - and then relabelled under the PREVIOUS model's pair, before SaveTopologyConfiguration wrote that stale pair back into the brand new .cfg. Reset, re-derive, re-pin, with the middle step missing. No number of resets could ever have moved it. Evidence in the 2026-08-19 journal: RESET WIPE at 16:23:38.699 (.cfg=deleted), "rebuilt a fresh topology" at .790, and a label cache at .890 with a distribution byte-identical to the pre-reset 2.00/2.00 one (Buy 3221 / Sell 3303 / Neutral 4837, mean lifespan 6.4 bars) - 100 ms later, with no DeriveBarrierGeometry between them. The member that actually blocked it is m_geometryDerivePasses. LoadAndCompareTopologyConfiguration pins it to BARRIER_DERIVE_MAX_PASSES to block the fixed-point iteration, which is correct for a LOAD - an existing model must never re-derive or the target moves under fitted weights - and exactly wrong for a RESET, which is the act of declaring there are no fitted weights left to protect. State that is correctly sticky for one lifecycle event, silently inherited by another; the same shape as the .cfg pin sitting beside it. ResetWeights now returns the whole derivation to its constructor state: the three latches, the pair, the horizon and its flags, the swing/lifespan measurements, the scan's own outputs, and m_spreadAtr - that last one matters because the cost filter is deliberately inert on pass 1 (m_spreadAtr <= 0.0) and an inherited spread makes a reset model walk a different ladder than a genuinely new one. m_sl_mode/m_tp_mode go back to the SL_Mode/TP_Mode inputs, since the adopt path overwrites them in place with no copy of what was configured. NOT COMPILED - user compiles in MetaEditor.	2026-08-19 16:31:18 -04:00
AnimateDread	c3daded397	feat(geometry): 1:2 becomes a FLOOR the swing legs may raise, and the scan can no longer undercut it ... Two coupled changes, both from measurements in today's SP500 H4 log. 1. THE SCAN WAS OVERRIDING THE DERIVER ON THE WRONG OBJECTIVE. At 13:37:47 DeriveBarrierGeometry produced stop 1.21*ATR / target 2.41*ATR - break-even 33.3%. Thirty-seven seconds later the barrier-geometry scan adopted 2:2 - break-even 50.9% - because it carried 0.0143 nats of entry-time information against the configured pair's 0.0075, and cleared its family-wise gate. Information is not expectancy, and the scan says so itself; nothing checked what the adoption did to the operating point. It did this: the fitted thresholds immediately after read 38.8% win vs 50.9% break-even (-12.2pp) and 48.3% vs 50.9% (-2.6pp), where the earlier model on this instrument at a 1:2 geometry had fitted +1.8pp. The deriver applies the ratio as user RISK POLICY; a scan that can crown 1:1 makes two subsystems disagree about one geometry - the same split this file already fixed once for the clamped-horizon rule. The scan now enrols and crowns only pairings at or above the floor; sub-floor pairs are still scored and printed (marked 'r') so the choice stays auditable. This is NOT the min-RR rule removed on 2026-08-09 - that one guarded a rejection filter that no longer exists. 2. THE RATIO IS A FLOOR, NOT A CAP (user: "the ratio of 1:2 is a minimum that I want, but it should not cap to that if the average zigzag moves gives more room"). BARRIER_TARGET_RR -> BARRIER_TARGET_RR_MIN. ComputeBarrierHorizonBars already scanned ZigZag pivots for leg DURATION; it now harvests leg RANGE in the same pass - two properties of one object, so the horizon and the target describe the same legs instead of two windows. The per-rung ratio is the floor raised toward median-leg/stop, snapped DOWN to a coarse ladder (2.0/2.5/3.0/4.0/5.0). The ladder is coarse on purpose: PooledGate pools only instruments whose structural break-even matches, and continuous per-instrument ratios would never match and would silently empty the pool. A leg is the right yardstick precisely because it owes NOTHING to the barrier - sizing a target off travel measured over the barrier's own horizon is the circular loop that ran EURUSD/USDCAD away to 14-31*ATR in 2026-08-07. The raise stays bounded by the three tests already in the ladder: reachability, the horizon ceiling (first-passage time grows with stop x target), and the cost fraction. Consequential fixes: the reachability floor was a macro keyed to the fixed ratio and is now BarrierMinReachPct(rr) evaluated per rung (a raised ratio has a lower break-even, so a fixed floor would be the wrong strictness); the detectability break-even likewise; PooledGate now writes and matches the ACTUAL ratio (TargetRR()) rather than the floor. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 16:16:33 -04:00
AnimateDread	888f32d21c	fix(gate): the plateau shortcut re-ran the deploy test every era, raising its own bar ... User report: 'eras since best' in the ensemble line is always 0 (era 147, best at era 90, '0 eras ago'). That is a control-flow bug wearing a display symptom. Once every member's in-sample error had plateaued, the shortcut forced the ladder to its DEPLOY stage on EVERY era. The failed-gate branch resets the stage to 0 so the ladder can climb again - so the shortcut raised it, the branch cleared it, forever. Three consequences, only the first of which was visible: - g_ensErasSinceBest was reset every era, pinning the counter at 0. - The stage-1/2 boosted warm restarts were never reached, so the one mechanism that can un-plateau a stuck member never ran. The models sat at a WORSE error than their best (0.2408 -> 0.3015 on PAI) with no escape. - Every repetition ran EnsembleSurvivesSelection against an unchanged best and incremented the candidate-era count the family-wise correction divides by. The run spent its time RAISING ITS OWN SIDAK BAR - the same waste as the 2026-08-18 inert IS-error stop, one layer up, and the reason a gate that needed >47.8% saw its bar climb era after era. Fix: the shortcut fires ONCE PER BEST-ERA (g_ensGateTestedEra, stamped before the outcome branches because it is the re-running that inflates the family, pass or fail). A refused gate now falls back to the normal counter-driven ladder - warm restart, anneal, then a fresh deploy test - which is the escape the shortcut was skipping. Also, per user: the signal marks were too small to see. Span doubled (2.6 bar widths, so the overhang either side of the candle is ~0.8 bars) and both layers thickened - 1px dotted was invisible on a candle chart at any realistic zoom. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 15:40:52 -04:00
AnimateDread	5e0317f09d	feat(chart): signal marks become price LEVELS at the trigger, not arrows beside the candle ... User request: 'move from arrows on lows and highs to small horizontal lines at the actual prices the entry/exit would trigger, just a bit larger than the candles. dark green for buy, dark red for sell.' Every mark is now an OBJ_TREND segment with both anchors at one price and both rays off, spanning 1.3 bar widths, drawn at the bar's CLOSE - the price a market order actually fires at, and the exact entry TripleBarrierLabel assumes. It used to sit on the candle's LOW for a Buy and its HIGH for a Sell: prices the trade never touches, picked so an arrow glyph would clear the candle. The tooltip now carries that price too. COLOUR NOW MEANS DIRECTION AND ONLY DIRECTION on every layer (dark green / dark red). Layer moves to width+style - the traded vote is solid and thick and drawn in front, a single model's raw opinion is thin, dotted and behind the candles - which keeps the distinction the old palette existed to draw (a model's opinion must never read as a trade) while freeing colour to say one thing consistently. Consequences handled, all of them the same 'a typed scan went blind' failure: - SaveChartSignals filtered OBJPROP_TYPE == OBJ_ARROW and read OBJPROP_ARROWCODE. It now filters OBJ_TREND and recovers direction from the colour. The sidecar keeps the old 217/218 numbers as its buy/sell token deliberately, so existing .arrows files still load. - AdvanceChartSignalRestore now rebuilds through the SAME creation point the live path uses, so a restored mark and a fresh one are identical objects. - The rescan-scoped delete enumerated ObjectsTotal(OBJ_ARROW) - retyped, or it silently deletes nothing. - ApplySignalsVisibility enumerated OBJ_ARROW with NO prefix filter. Under the new type that would have hidden and shown THE USER'S OWN trend lines on every Hide/Show click; it is now prefix-scoped. The old type was uncommon enough on a real chart to mask the missing check - trend lines are the most hand-drawn object there is. - DrawObject's high/low parameters are gone (6 call sites pass m_Close instead), so no caller can hand it a price it no longer draws at. - Fixed a pre-existing stale comment that still described the purge sweep as OBJ_ARROW-only three lines above the note explaining it had been widened to every type. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 14:11:49 -04:00
AnimateDread	6717509c8b	fix(build): four compile faults - one was a SILENT enum collision that inverted the direction policy ... Reported by the user's MetaEditor compile of f64e0f8 (26 errors, 4 warnings). The four warnings mattered more than the errors. 1. INTELLIGENT WAS TWO ENUMS. MONEY_MANAGEMENT_STRATEGY::INTELLIGENT (=1) is declared BEFORE TRADING_DIRECTION::INTELLIGENT (=3) in InputEnums.mqh, so MQL5 resolved every 'tradingdirection == INTELLIGENT' to the MM member and converted it to value 1 = TRADING_DIRECTION::LONG_ONLY. Wrong in both directions at once: selecting Intelligent (3) matched NOTHING and silently traded both sides, while selecting Long only (1) matched and handed the decision to the measured drift verdict - which can answer SHORT_ONLY, so the one setting that must never go short could have. Reported by the compiler as a WARNING only, never an error. Renamed to DIRECTION_INTELLIGENT; the VALUE stays 3, so saved .set files are unaffected. Swept every enum in the repo for sibling collisions (38 enums, detector validated against the pre-fix source, which it flags): none remain. 2. g_warriorMetaGate sits above the class it points at - added the forward declaration, the same pattern g_warriorEnsemble already uses in ExpertSignalAIBase.mqh. 3. The broker-time rename (b63e39f) never reached BufferNewTickSignal's PARAMETER or its two call sites: the local became brokerTime, the parameter stayed gmtTime, and the body was rewritten to read brokerTime. All five sites now agree. 4. ConfigureAISignal calls IsMetaTarget() from a free function - moved it to the public section (identity, not an implementation seam); the other meta seams stay protected. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 13:16:45 -04:00
AnimateDread	f64e0f8b67	feat(ensemble): per-NN inputs replace the preset selector - the meta head becomes the vote's gate ... User design (2026-08-19): 'remove the enum menu that selects neural networks... individual inputs for every NN just like classic signals... the META NN should be integrated into the voting decision pipeline when enabled... as a bonus meta labelling is applied to enabled NNs.' - AI_CHOICE is GONE (tombstoned per the stale-.set doctrine). Use_MLP/Use_CONV/Use_LSTM/ Use_CONVLSTM are ordinary bools like the classic votes; the ensemble arithmetic adapts to any subset because the consensus divisor is the enabled capable weight. Two or more enabled = ensemble (|ENS1 token + joint gate, exactly the old AI_HYBRID fingerprints, so existing weight files keep loading); one = the old solo preset; none = classic-only. - Use_MetaLabeling un-couples META from the direction NNs (the old selector made them mutually exclusive). S3 ships: CSignalMETA::LiveMetaGate scores each vote-cleared entry (shared window at bar 1 + proposal descriptor: side, net vote, live geometry, spread/ATR; pattern one-hot ZEROED - ranking, not calibrated probability, documented in the body) and vetoes below the cost-adjusted break-even. Entries only; fail-open everywhere, loudly. - COEXISTENCE HAZARDS closed: VoteCapableWeight()=0 and ProspectiveVote()=false for the meta target - solo-only until today, a trained META would otherwise sit in the consensus divisor as a permanent abstainer and shrink every vote by its module weight. - CERTIFIED == TRADED: the ensemble era verdict replays the identical veto through the same g_warriorMetaGate pointer over its OOS fired bars (bar re-resolved from the row's own time; fail-open counted as fires and reported: 'metaGate: N approved, M vetoed, K unscored'). The overlay deliberately does NOT replay it (veto-filter-in-replay class, calendar-cliff precedent) - documented at the sweep site. Solo charts' own gate does not model the veto - the standing solo-gate caveat, documented at the input. - DB continuity: the pattern/journal DB fingerprint's first slot was (int)AIType; DbLegacyAiSlot() maps every legacy-expressible config to its OLD value (new 2-3 member subsets get 100+bitmask, outside the legacy range) so no existing database re-keys. filterID becomes the enabled roster via one EnabledNNSummary(). - HUD: the meta line shows the gate (armed/(trn), last P vs BE, ok/veto tally); the armed/disarmed announcement fires on state change via one latch (MetaGateArmedNow), not only when an entry happens to be proposed. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 13:01:02 -04:00
AnimateDread	1445f175ce	feat(consistency): the five review flaws fixed - training wears the live constraints, the gate wears the policy ... 1. Labels and the exit simulator go through the broker's stop-distance check: risk/reward widen to SYMBOL_TRADE_STOPS_LEVEL exactly as TCAdjustStops does at order time - the M5/tight-ATR case where live trades ran wider geometry than training measured. Current stops level stands in for history (like the spread); measured quantity, so it does not key the fingerprint. 2. The Intelligent drift verdict moved into RefreshDriftVerdict(), which RESCANS the label cache and now runs at every era end beside RankTiersFromOos - era-cadence instead of waiting for rare full rebuilds. Prints only on change. 3. Session filter is any-broker: sessions defined on their financial centres' civil clocks (London 08-16 Europe/London, NY 08-17 America/New_York, Tokyo 09-18 Asia/Tokyo), converted to UTC by each centre's own computed DST rule (EU last-Sun-Mar/Oct, US 2nd-Sun-Mar/1st-Sun-Nov), then to broker time by the MEASURED server-vs-GMT offset (half-hour brokers included). Windows may wrap midnight in broker time - the interval test handles it. Replaces the EET-hardcoded anchors, which were correct on exactly one broker and got Tokyo wrong by an hour each European summer. 4. The current-session-table-for-history caveat resolved by analysis: the bars bound the error - a too-late assumed close meets no bars (zero error), a too-early one truncates conservatively (<=1h, never optimistic, cannot manufacture edge). Documented at the site. 5. The ensemble deploy gate mirrors the direction policy: blocked-side fires are not fired bars (certified == traded), the zero-skill reference uses only ACHIEVABLE baselines (always-short is not a strategy a long-only book can run), and one-sidedness BY POLICY is not degeneracy - the two-sided requirement applies only when both sides are allowed. Sell predictions keep their other jobs (exit triggers, consensus dilution) untouched. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 12:14:01 -04:00
AnimateDread	3e467f92e9	feat(labels): the scheduled close-all is now a vertical barrier in the label walk ... User report: "I exit everything on Friday close to avoid weekend swap... if the NN training thinks I hold over the weekend it could produce inaccurate results" - it thought exactly that. TripleBarrierLabel walked its full horizon (64 bars, mean lifespan ~18 H4 bars ~ 3 days) straight through the scheduled flat, scoring trades the deployed EA is guaranteed to have closed on Friday 23:45. SQX applies this rule when building strategies; the EA's own labels did not. NextScheduledCloseAll() mirrors CExpertCustom::OnTick's live check exactly (same three inputs, same -1 disabled sentinels, same CLOSE_EVERYDAY semantics, same server clock). The walk stops at the first bar that does not END by the cutoff - OHLC cannot order the tradable fraction of a partial bar, and ties go to the refusal, as everywhere in this file. An unresolved trade at the cutoff times out to Neutral, exactly as live would flatten it. Excursions, the first-passage ladder and the label lifespan truncate with the walk, so the DERIVED geometry is automatically sized to the tradable window - a target the flat rule never lets price reach stops counting as reachable. The prebuild census now splits timeouts: "horizon too short?" vs "ended by the scheduled close-all" - different questions, different fixes. Schedule disabled = no cutoff, exactly like live. Models trained under weekend-blind labels are fitted to a different target; charts with the close-all enabled (the default) should be reset to retrain under the honest labels. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 11:17:14 -04:00
AnimateDread	f30e342a1d	feat(logs): throttle the settled per-era diagnostics - measured 22MB/9.5h of confirmed-working systems ... Measured from the journal (2026-08-19): the era deep-dive line (~2KB) plus the excursion verdict, tier re-rank, calibration move, barrier hold and selection-regressed note each printed EVERY era for EVERY member - ~940 eras/member/day - long after the systems they watch were confirmed working. Yesterday's file was 1.3GB (70% of it the news-filter calendar spam the sweep fix already removed). VerboseMode returns as an INPUT (demoted 2026-08-01 for the marketplace; that track is dead since the 2026-08-16 pivot) and gains a second job: false throttles each settled per-era print to eras 0-3 plus every TRAIN_LOG_EVERY_ERAS-th (25 ~= one deep-dive per ~15min per member); true restores the per-era firehose, flippable live. Never throttled: anything that marks a CHANGE - new bests, restores + eta decays, plateau stage transitions, deploy approvals, warnings, errors, the label-cache/adoption one-shots, and the combined-vote gate line (the active system's primary telemetry, still every era). Semantic fixes over blanket gating: - barrier hold now ARMS silently and prints only when the hold outlasts the 2-min report interval - a brief hold every era is the design, the long hold is the watchdog case the line exists for; - the ensemble deploy REFUSAL prints immediately when its reason changes (that is a finding), on cadence when unchanged; - the filtered-view census prints when its RESULT moves (drawn count, or strongest vote by >=2pp) and at least every 10th sweep. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 09:36:15 -04:00
AnimateDread	83ae56cc9e	feat(hud): per-member neuron lines + a vote label that moves as the nets learn ... Both 2026-08-19 reports were the same staleness: every source behind the label was an ERA artifact (live cache refills at pass-3 completion, the snapshot copies once per era, dPrevSignal is the frozen purge-band edge bar) - so the readout stepped at era cadence at best, stayed glued to one direction, and lagged the era counter. DisplayInference(): throttled (4s, 1s across an era boundary), SIDE-EFFECT-FREE forward of the current decision bar (window ending on bar 1, same question the live path asks) through the LEARNER net. Batch-norm running stats are bracketed frozen/RESTORED via the new CNet::GetBatchNormFrozen() + CNeuronBatchNormOCL::StatsFrozen() - restore, not unfreeze, because a display tick can land between pass-3 chunks whose whole scan holds them frozen. Writes nothing a trading or training path reads (dPrevSignal, NMS state, tallies, watermarks all untouched; RefreshLatestSignal is not reusable here precisely because it writes all of them). LSTM safe by construction: h/c zeroed per forward. ProspectiveVote() reads the fresh forward as its FIRST source; the era-artifact chain becomes the fallback (meta head, warm-up, window holes). DisplayHudLine(): the reference library's training label, per ensemble member - name, output activations (softmax probs or raw scalar), the decision, its weighted vote (the exact consensus numerator term), era, recent average error, "(trn)" while not vote-capable. Rendered under the vote line in RefreshVoteReadout BEFORE the live-vote defer (member lines are telemetry, not tradable readings), coloured by the member's own direction in muted tones - the vote line's strict green-only-when-it-would-trade rule is untouched. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-19 08:48:34 -04:00
AnimateDread	1a900a0a35	feat(vote): CONSENSUS arithmetic - agreement is now what the threshold dials ... Era-680 report, all three observations one equation: "peak 29, no arrows at threshold 30" / "at 20, arrows on EVERY bar" / "label at 12 while arrows everywhere". Under the voters-only divisor, any bar with at least one directional voter read the weighted mean of the firing tiers' weights - and once the tiers self-ranked to each model's pooled win rate (~28-31), that mean was NEAR-CONSTANT regardless of headcount. One member alone: ~29. Four unanimous: ~29. Min_Vote_Open was a step function around that constant - above it nothing ever fired, below it everything did - and the label's 12 was a 3v1 split netting through the same divisor. Not three display bugs: one arithmetic that could not express agreement. The divisor is now the CAPABLE weight - every filter that could vote, whether it did or not: * live (Direction): VoteCapableWeight() - classic pattern ladders always, veto filters never, AI members once past the same readiness test LongCondition gates on. A model still training must not dilute an ensemble it cannot join: four trainees + one deployed model is a solo chart wearing an ensemble label, and the solo vote reads full strength. * gate (EnsembleEraVerdict): g_ensVoteWeightSum accumulates for every member that EVALUATED the bar, Neutral included. * overlay sweep + prospective readout: weight counts whenever the member has data; a snapshotted Neutral dilutes. One arithmetic, four sites, same numbers everywhere. What the numbers become (four members, w~0.29, tiers~29): unanimous ~29 - the CEILING, which is the pooled win rate and is what the peak displays; 3-of-4 ~22; 2-of-4 ~14.5; 3v1 ~14.5. Min_Vote_Open 20 now means "roughly three-quarters of the ensemble's trust agrees, net". It MUST sit below the ceiling to ever fire - the census/peak states the ceiling. This is the ensemble the user specified in the original design discussion ("if the perceptron also votes, both together reach the threshold; if another NN votes the other side, the threshold is not reached") - union semantics was the pre-ensemble behaviour, kept until measurement showed its vote magnitude was a constant. Plus overlay DECLUSTERING, the other half of "arrows on every bar": the same three NMS rules as the per-member arrows (same-direction runs collapse to their first bar, cross-direction flicker keeps the stronger side), online over the sweep's strictly oldest->newest walk. Suppression is a verdict and deletes a standing arrow; the den==0 no-data skip still never does. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-19 06:58:03 -04:00
AnimateDread	c393497fd6	fix(chart): display now reads era-end SNAPSHOTS - the live cache is wiped mid-era ... Full-pipeline analysis after "threshold 30, attained often, nothing drawn, still glued to buy". The log falsified the premise before any code did: 21:40:43 swept 4999, 794 voters, drew 491. Strongest 43.0% vs 30.0% 21:42:07 swept 4999, 0 voters, drew 0 21:51:30 swept 4999, 0 voters, drew 0 21:56:30 swept 4999, 922 voters, drew 382. Strongest 44.0% vs 30.0% The arrows WERE drawn - 491 of them, then 382 - and then erased. ONE root cause, three symptoms: every display path read m_arrowSignalCache, which is wiped to sentinel at each era start and only complete again when pass 3 finishes. With eras at ~30s and a sweep at ~17s: * ARROW FLICKER: a sweep landing mid-era found no voters anywhere, and its else-branch deleted the arrow on every voteless bar - erasing the previous sweep's entire output. The chart cycled populated -> blank -> populated; the user kept catching the blank phase. * READOUT GLUE: the newest-cache walk found only sentinel for ~90% of every era and fell through to dPrevSignal - the frozen purge-band edge bar that reads Buy. 659638e fixed which bar was frozen, not the freezing. * VOTER FLAP: 1299 -> 257 -> 1113 across back-to-back sweeps - each saw a different fraction of half-rebuilt caches. THE FIX, structural rather than another patch: 1. Era-end snapshots. RankTiersFromOos() runs at pass-3 completion - the one moment the cache is complete - and now copies it (raw signals, newest LOOKBACK+16 bars) into member-owned snapshot state, unconditionally, BEFORE its early return: an all-Neutral era is a snapshot worth showing, not an absence of one. Raw signals rather than votes, so a tier re-rank between eras reprices them at read time via LiveVoteContribution for free. 2. The sweep (SnapshotVoteAt) and the prospective readout both read snapshots; the readout's fallback chain is live-cache -> snapshot -> dPrevSignal, and the snapshot leg is the one that fires most of the time. 3. NO DATA IS NOT A VERDICT: a den==0 bar no longer deletes - only an actual sub-threshold vote takes an arrow down. This alone ends the wipe half of the flicker even where snapshots are missing (before the first era). 4. Arming moved from an era-counter diff (which fires at era BOUNDARIES, i.e. precisely when caches are about to be wiped) to g_warriorOverlayArmRequest, set by each RankTiersFromOos - "a member's snapshot just got fresher", the only event a redraw can act on. 60s rate limit collapses the four members' burst into one sweep. Classic-only charts arm once at start. 5. Census now reports the direction split - "922 had a voter (610 buy / 312 sell)" - so "the vote leans buy" is checkable from the log instead of inferred from arrow colours. Also visible in the log and worth knowing: the threshold flip-flopped 30 -> 40 -> 30 across the evening's re-inits (census lines at 21:42-21:51 ran at 40), so part of the observed blankness was configuration, not code. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 22:03:20 -04:00
AnimateDread	659638e072	fix(chart): the prospective vote was four models' opinion of ONE frozen bar ... "Still glued to buy." Verified in the pass structure rather than guessed: dPrevSignal is written ONLY by pass 1 (Training.mqh 1439/1442 - the sole assignment sites), and pass 1 SKIPS the feedForward for any bar a later pass will forward anyway (laterPassForwards) - which is the whole OOS window and the calibration band. Pass 3 forwards the newest bars every era but never writes dPrevSignal. Net effect: after every era, dPrevSignal holds the model's opinion of the newest PURGE-BAND EDGE BAR pass 1 happened to forward - one fixed mid-history bar, re-evaluated era after era. The readout was therefore showing four models' verdict on the same frozen bar, and that bar reads Buy. Glued to Buy, with flashes of Sell only while pass 1 was actively walking (the one window where dPrevSignal moves). ProspectiveVote() now reads the newest ARROW-CACHE entry first (walking back from the decision bar, bounded at 16), falling back to dPrevSignal only when the cache holds nothing. Pass 3 writes the adjusted decision for the newest (OOS) bars each era, so the cache's first non-sentinel entry is the model's most recent verdict on near-current data - and it is the same value the filtered overlay draws from, so the label and the reconstruction stay one quantity. A cached Neutral stops the walk: that is a real decision (vote 0, abstain -> shows in the "flat" count), not a missing one. Early in an era the cache is wiped to sentinel and everything falls through to dPrevSignal exactly as before, until pass 3 refills the newest rows. Expect the label to change per era now (as each pass 3 re-scores the newest bars under that era's weights), with the vote/flat split moving as members genuinely flip between direction and Neutral on recent data. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 21:47:51 -04:00
AnimateDread	a042cb4359	feat(chart): show the PROSPECTIVE vote while the models are still training ... The readout sat at "VOTE 0.0%, 0 voters" constantly. Correct, and useless. LongCondition()/ShortCondition() return 0 behind the readiness gate for the entire training run - a model that is not deployed does not vote - so the LIVE vote is structurally zero for hours, which is exactly the period the readout is being watched. Worse, it was the same display whether the models were silent, undeployed, or the filter list was empty: three different situations, one number. When no filter casts a real vote, the readout now shows the PROSPECTIVE one - what these models are saying right now, through the identical tier/weight arithmetic, minus the readiness gate. That is the same quantity the historical overlay reconstructs on cached bars, deliberately, so the live line and the reconstructed arrows are the same measure and can be read against each other. It can never be mistaken for a decision: labelled "-> training, not tradable yet", drawn dimmer than "no trade", and `fires` is forced false regardless of magnitude, because saying "-> TRADE" about a number that cannot place an order is the precise overstatement this readout exists to prevent. m_direction is untouched - display only, no trading path reads it. Confirms the sweep fix from 155f56e is live and working: "Filtered view: swept 4999 bar(s), 767 had a voter, drew 0 arrow(s). Strongest vote 36.0% against a 40.0% threshold." 4,999 bars against the previous 0. The remaining emptiness is the models, not the plumbing - see the reply for why lowering the threshold further is the wrong response to it. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 18:29:27 -04:00
AnimateDread	8ab8cf6b92	feat(chart): on-chart vote readout, and Min_Vote_Open 50 -> 40 ... THRESHOLD. 40 is a measured correction, not a preference. Once RankTiersFromOos() replaced the designed tier priors with each model's real held-out win rate, the vote converges on that win rate - logged 2026-08-18 as pooled 23-36% across four members on three symbols - so a 50% bar could not be reached by anything on offer and the ensemble gate fired on 0 of 4,865 OOS bars. 40 clears the ~34% break-even those same lines report without being unreachable. The comment says plainly not to copy the number: break-even is a function of the barrier geometry, so read the gate's own "needs >N%" for the config in front of you. READOUT. One line, top-right: VOTE SELL 37.2% peak 44.1% need 40% 3 voter(s) -> no trade Every other number on the chart is downstream of the weighted mean the open threshold is compared against, and that was the one quantity never displayed. A chart with no arrows could mean the models abstained, the vote was diluted, or the threshold is unreachable - and telling those apart meant waiting for an era to end and reading the gate line, which is how the last two sessions went. PEAK is the part that earns its space. A threshold above what the vote ever attains can never fire, and that is not knowable from a single bar - it is precisely the "unreachable gate vs merely unmet gate" confusion this project has paid for twice. Colour carries the verdict rather than the direction: green/red ONLY when the vote would actually place an order, grey otherwise. Green-for-buy would make a below-threshold buy look like a trade, which is the specific misreading the display exists to prevent. Guarded on `total > 0` for the same reason the normalization is: Direction() is inherited as-is by every leaf filter, so without it each filter would write its own opinion into the one shared label and the last to run would win - the reader would be looking at an arbitrary member's number believing it was the vote. Drawn after the +-100 range check, so it shows what the threshold is actually tested against. CORNER_RIGHT_UPPER: the status lines, control panel and ensemble panel all live on the left. Registered in WarriorChartPrefixes() explicitly even though the "Warrior" catch-all already reaches it - that catch-all exists because the list has drifted twice, not to make entries optional. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 18:22:45 -04:00
AnimateDread	e59dc1629f	fix(deinit): vote arrows survived the cheap sweep, and 5 long loops ignored the stop ... Leftover chart objects on long-history charts. Two causes, one of them introduced by 07aa017. THE ONE I ADDED. The filtered view's overlay draws up to SIGNAL_RESCAN_LOOKBACK_BARS vote arrows. OnDeinit's EARLY VISIBLE-UI SWEEP runs with skipArrows=true, which skips any prefix equal to SIG_ARROW_PREFIX - and "WarSig_VOTE_..." starts with "WarSig_", so every one of them was skipped by the one sweep that is cheap enough to always complete. They then sat in the object list while the two expensive scans that follow walked it: a per-member SaveChartSignals O(total) scan, then the by-name rescan. On a chart with years of history that is thousands of extra objects walked twice, inside a teardown budget measured from the stop REQUEST rather than from OnDeinit's first line. skipArrows exists because the per-model arrows' sidecar is rebuilt by SCANNING them off the chart, so they cannot be deleted before that write. Vote arrows have no sidecar - they are a reconstruction, rebuilt on the next attach - so nothing is preserving them and they now get their own prefix slot, deleted by one native call in the first few milliseconds. THE FIVE LOOPS. A time budget bounds THROUGHPUT, not latency to an unload, and OnDeinit cannot begin until whatever is in flight returns. These all scaled with history and none of them checked: * Training passes 2, 2.5 and 3 yielded only on TRAIN_TIME_BUDGET_MS. Pass 1 has checked IsStopped() all along; the other three never have, and they are the ones that grow with the bar count. Free to fix - the resume state is written either way, so a stopped chunk simply is not re-entered. * PruneDirectionalClusters: the one UNCHUNKED sweep left, once per era over every bar, with its own header noting that raising the training budget cannot help its cost. Now bails outright. * AdvanceChartSignalRestore / AdvanceChartSignalRescan: chunked, but the rescan runs a full feedForward per bar over up to 5000 bars and the restore can hold MAX_RESTORED_ARROWS entries. Checked on the same 64-object stride as the clock read, since the check is not free either. * AdvanceFilteredOverlay (mine, 07aa017) replays Direction() on every classic filter per bar and had no check at all. Now per bar. ChartUI.mqh had ZERO shutdown checks across six loops before this. Nothing was added to the purge path itself: that is the work that must complete, and an IsStopped() check inside it would abort unconditionally - IsStopped() is already true by the time OnDeinit runs. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 17:13:50 -04:00
AnimateDread	07aa01777c	feat(chart): reconstruct the filtered view behind the handover point ... Completes the filtered view from 282b535, which only reached forward of attach. On a multi-hour training run that is the entire time you are looking at the chart, so the answer to "how would the whole bot have traded" was blank exactly when it was wanted. The sweep lives on the AGGREGATE signal, which is the only object holding every filter. AI members contribute their CACHED per-bar decision from the era scan - no inference re-runs, the cache already spans the chart - and the classic ladders are replayed with EvalShift(i), the same mechanism CSignalMETA's candidate sweep uses and exact because every classic pattern condition anchors on StartIndex(). Combination is the live one: weighted mean over voting filters, abstentions out of both sums, against Min_Vote_Open. THE REPLAY CORRUPTS LIVE JOURNALING IF LEFT UNGUARDED, and this is the part that is not obvious. Live journaling reads m_active_pattern_long/short from the PREVIOUS Direction() call. Replaying hundreds of past bars between two live bars leaves those slots holding whichever bar the sweep stopped on, so the next live bar journals that pattern under the current timestamp - a corrupted row in the very table pattern win rates are computed from, which is now also where vote weights come from. Save/RestoreVoteState() brackets every replayed call. CSignalMETA gets away without it only because its sweep runs once, at the first era, before any of that state matters. TWO SOURCES OF TRUTH, KEPT APART. A reconstruction cannot know the broker rejected an order - it has no stops level, ATR warm-up or swing-history sync as they were at that moment - so it is an upper bound: honest about the vote, optimistic about placement. It therefore stops dead at the handover bar, which is latched ONCE so later rebuilds cannot creep it forward and start overwriting real decisions with guesses, and its arrows say "reconstructed (vote only - order validation not replayed)" in the tooltip. Someone comparing two arrows either side of that line has to be able to tell which is a record and which is a replay, and the chart is the only place they look. Re-armed on any era boundary (summed era counters), because that is when the answer changes - RankTiersFromOos has just re-derived every tier's vote weight - and only between sweeps, so a restart cannot leave the previous pass's tail undrawn. Chunked at 150 bars per timer slice: each bar replays Direction() on every classic filter, which is real indicator work on the chart thread, and an unchunked sweep here is the 2026-07-26 arrow-restore freeze waiting to happen. SIGNAL_RESCAN_LOOKBACK_BARS moves to ExpertSignalCustom.mqh alongside SIG_ARROW_PREFIX - same include-order reason, and the two rebuilds should reach the same distance or the raw and filtered views are not comparable. Known gap: on a classic-only chart the reconstruction is built once and not refreshed when the hourly DB ranking moves the classic weights. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 16:05:13 -04:00
AnimateDread	b28c81eb78	feat(rank): AI models rank their own confidence tiers from held-out outcomes ... Closes the caveat 4858507 shipped with: the vote is a confidence percentage, but only to the extent the pattern weights are measured. AI tier weights sat at their designed defaults (25/50/75/100) because AI rows only ever arrive from LIVE journaling, of which a training run produces almost none. AND A STALE-TIER BUG THAT MADE THE EVIDENCE MEANINGLESS. The OOS scan bucketed every scanned bar by ConfidenceTier(), which reads dPrevSignal - and dPrevSignal is assigned in PASS 1 only, never anywhere in the OOS scan. So an entire era's fires were bucketed by one stale, unrelated bar's confidence and landed in a SINGLE tier. That is the "tier prec T0:72%(828) T1:n/a(0) T2:n/a(0) T3:n/a(0)" symptom recorded on 2026-08-16 and attributed to the calibration clamp. The clamp was real and was fixed then; this is a second, independent cause of the identical output that survived that fix untouched - which is why the log kept reading the same afterwards. Two causes, one symptom. Now ConfidenceTierFor(adjSig): the bar this iteration actually scored. WHY THIS DOES NOT WRITE ROWS TO THE SIGNAL DB, which was the obvious reading of "fill the database during training". The user's own observation is the reason: a classic Pattern_2 is a fixed geometric condition, so its win rate is legitimately accumulated over years, but an AI Pattern_2 means "confidence landed in tier 2" and tier 2 under era 100's weights is a different statement from tier 2 under era 500's. The DB's value is ACCUMULATION, and accumulation is exactly what is wrong here - it would average together models that no longer exist, while colliding with the per-table row cap and mixing measured-on-holdout outcomes into the live ledger's own tables. What the DB actually supplies is a measured win rate per pattern, and pass 3 already computes that on held-out bars, thousands at a time. So the model ranks itself once per era, REPLACING rather than accumulating, which makes the weights describe the current weights by construction. ESTIMATOR. Not WinRateFromCounts(): it returns NO_DATA below 100 raw trades BEFORE shrinking, which here would fire on every tier every era and hand all four the pooled rate - the tiers could never separate and the mechanism would be inert. Shrinkage is the answer to a small sample; a floor in front of it means the shrinkage never runs. Instead: a Beta prior of TIER_PRIOR_EFF_N pseudo-observations centred on the model's pooled holdout rate, counted in EFFECTIVE observations, because overlapping triple-barrier labels mean 800 raw fires can be worth ~12 independent ones. Rounded to the integer, not to the decade NormalizeWinRate() uses, which would collapse the shrunk tiers back into one number. NO SAME-ERA CIRCULARITY, and it falls out of the ordering rather than a guard: weights are computed at the END of era N, so the vote scored during era N was cast with era N-1's weights. The deploy gate never grades a vote whose weights were fitted on the bars it is scoring. Residual leakage remains - the same OOS bars each era under a different model - and is stated in the code rather than papered over. Both DB clobber paths are closed: ApplyPatternWeight() declines once self-ranked, and UpdateSignalsWeights()' filter.Weight() call is guarded by SelfRanked() - guarding only the tiers would have let the hourly ranking pass undo half the self-ranking. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 16:00:32 -04:00
AnimateDread	4858507146	feat(vote): thresholds become confidence percentages, on ONE scale everywhere ... User request: "the entry/exit thresholds are manual numbers, I would like them to be confidence percentages, so the current 20 would be only 20% confidence in a profitable trade." WHY 20 WAS EVER SENSIBLE. Under UseDatabaseRanking both factors of a filter's contribution are win rates: the pattern weight is that pattern's measured win rate (UpdateSignalsWeights -> ApplyPatternWeight) and m_weight is the filter's average win rate over its patterns, /100. Dividing the sum by the VOTER COUNT therefore produced a mean of PRODUCTS of two win rates - a genuinely 60%-accurate filter firing a 60% pattern scored 0.60 x 60 = 36. The number was never on a probability scale, so its magnitude meant nothing on its own. Dividing by Sum(m_weight) instead makes it a weighted MEAN of win rates, which is a win rate: result = Sum(w_i*p_i)/Sum(w_i). Every voter at 60% now reads 60; MACD's double-divergence pattern (weight 100) voting alone reads 100. m_weight stops being a discount on the probability and becomes how much a filter's opinion COUNTS - which is what a module weight should always have been. Default Min_Vote_Open 20 -> 50: not a tightening, the same bar re-expressed. ONE SCALE, EVERYWHERE - the part that made this bigger than a rescale. Three other places compared against a 0..1 softmax confidence and would each have become a fresh currency mismatch the moment the input changed meaning: * the AI early-exit route (LiveSignedConfidence vs m_ai_exit_threshold) now reads m_lastAiVote - the AI filters' own weighted mean, undiluted by the classic side, which is the only reason that route exists - against the same m_threshold_close the averaged vote uses. m_ai_exit_threshold is retired rather than left dangling. * m_oosDecisionSeries now carries the vote, not the confidence, so the exit SIMULATION stops modelling a close rule the EA does not run. * ExitPolicy() clamped anything > 1.0 to zero. Passing the unscaled input through that would have silently switched vote exits off in the simulation while live went on running them - found before it shipped; the bound now tracks the scale. LiveSignedConfidence() is deliberately untouched and still 0..1: MM sizing, SL/TP scaling and the intelligent trailing want a model confidence, not a win rate. CALIBRATION CAVEAT, stated in the code where the claim is made: this is only a real probability to the extent the pattern weights are. A pattern with fewer than MIN_TRADES_FOR_WIN_RATE journaled trades keeps its DEFAULT weight - a designed prior (25/50/75/100 for the AI tiers), not a measurement. Until the signal DB fills, "60" means "the designed conviction of the patterns that fired". Closing that gap is the next commit. Also corrects VOTE_CLOSE_PRESETS' comment, which documented the two scales this removes. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 15:52:08 -04:00
AnimateDread	282b535037	feat(chart): filtered view - one arrow per trade the bot would actually take ... Adds DrawUnfilteredSignals (default OFF) and, with it off, replaces the per-model arrow layer with the decision the EA would really have made. THE FILTERED ARROW IS DRAWN AT THE ORDER, NOT AT THE THRESHOLD. Clearing Min_Vote_Open is not the same as trading: a setup can pass the vote and still never reach the broker (invalid SL/TP, stops-level, ATR warm-up, unsynced swing history), and every one of those lands in OpenParams' failure branch. So DrawVoteArrow() fires only after the order parameters validate, and the failure branch withdraws any arrow already standing on that bar. One arrow is one entry the EA would have placed - carrying the vote, the threshold it cleared, and the SL/TP the order would have had. Classic signals now draw too, under their own name and weight, so a chart running MA/RSI/MACD/Ichimoku alongside the nets reads the same way an ensemble chart does. They can only be drawn from the aggregate's once-per-bar pass, because unlike the AI members they have no cached per-bar scan. Two subtleties that would each have produced a quietly wrong chart: - The raw classic draw sits AFTER filter.Direction(), not beside the journaling block. GetActivePattern*() are CONSUMING reads holding the PREVIOUS evaluation - "one tick later", which at Expert_EveryTick=false is one BAR later. Keyed off those and placed at StartIndex(), every classic arrow would have been drawn one bar early, which on a chart is indistinguishable from a model that genuinely leads. Peek*() accessors (non-consuming) let pattern, weight and bar come from one evaluation. - CExpertSignalAIBase::DrawObject() early-returns instead of gating its five call sites, so the switch cannot be honoured in three passes and missed in the fourth. Its delete counterparts stay ungated so flipping the input off and rescanning clears the raw layer rather than stranding it. SIG_ARROW_PREFIX and g_signalsVisible move from ExpertSignalAIBase.mqh down to ExpertSignalCustom.mqh - the nearest common ancestor - because the classic signals cannot see the AI header (it is included later in Warrior_EA.mq5). The vote layer gets SIG_VOTE_PREFIX under the same bare prefix, so WarriorChartPrefixes()' purge still reaches every arrow without knowing they exist. NOT YET BUILT: the reconstructed history behind attach. Filtered arrows currently start where the EA starts. See the next commit. NOT COMPILED - user compiles in MetaEditor. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 15:41:28 -04:00
AnimateDread	2c443ba3ad	fix(gate): the ensemble gate certified a vote the EA never casts ... g_ensembleVoteThreshold's comment claims the combined-vote scorer "fires on the same criterion the live trade does". It did not. Two independent mismatches, both silent: CURRENCY. Each member contributed its raw signed confidence x100 - a 33..100 number straight off the softmax head. Live contributes m_weight x the tier's pattern weight, and BOTH of those are rewritten from the signal DB by UpdateSignalsWeights(). A head output and a DB-ranked win-rate weight share an axis and nothing relates them, so the same bar was one number to the gate and a different one to the order path. Same shape as the 2026-08-09 geometry incident: certified on one game, paid on another. DENOMINATOR. The gate divided by the member count, so an abstaining member pulled the average toward zero. CExpertSignalCustom::Direction() skips a zero contribution in BOTH the sum and the count (`if(direction == 0) continue;` before `number++`) - live is a mean over VOTERS. The gate was therefore scoring a strictly more agreement-heavy set of bars than the EA trades. The contribution hook's own comment asserted the opposite ("abstentions dilute the average exactly as they do in the live vote"), while the AI_CHOICE enum 20 lines away correctly documented union semantics. LiveVoteContribution() is now the single definition of "what this member votes", called from the gate; the live path reaches the same arithmetic through LongCondition/ShortCondition. g_ensVoteVoterMask records who actually voted, separately from who evaluated the bar, because those are the divisor and the shared-population test respectively. ConfidenceTier() is split into ConfidenceTierFor(signal) plus a thin live-bar wrapper - the OOS scan holds the scanned bar's decision in a local, and dPrevSignal is a different bar. NOT changed, deliberately: the gate still does not model live NMS declustering, and the per-member solo gate still scores every directional call rather than threshold-clearing ones. Both are selection-metric changes and this codebase has twice been bitten by switching one blind. Also corrects a stale paragraph in m_pattern_0's declaration block quoting 80/87/93/100 as the tier defaults. The constructor is 25/50/75/100 and has been since the confidence floor and alternation gate were removed; the block carried both tables at once, and the dead one was quoted back as fact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 15:23:33 -04:00
AnimateDread	525e92ecb2	fix(plateau): the IS-error early stop was inert for every ensemble member ... 15 hours of training, and the stop that exists to END a run announced itself 1,299 consecutive times without ending anything: SP500 ConvLSTM IN-SAMPLE ERROR PLATEAU - not improved in 1297 / 1298 / 1299 eras (best 0.2689, now 0.3269) ... era 1396, 1397, 1398 SP500 LSTM 536 eras SP500 CONV 442 eras SP500 PAI 150 eras XAUUSD HYB 478 eras XAUUSD LSTM 296 eras XAUUSD CONV 366 eras CAUSE: it wrote its decision into m_plateauStage, and EnsembleEraVerdict mirrors the shared ladder onto every member - `mm.m_plateauStage = g_ensPlateauStage` - on EVERY era, purely so each member's status line shows the collective stage. A display mirror was silently overwriting a decision, so the stop re-armed and re-fired the next era, forever. This is the worst possible direction for this particular bug. Every one of those 1,299 eras was scored out of sample and joined the family the deploy gate corrects over (Sidak, g_ensCandidateEras). The stop's entire purpose is to make that family SMALLER; instead the run spent fifteen hours raising its own bar. - m_isErrorPlateaued: a one-way per-member latch, cleared only by a fresh run. Nothing in the ladder may reset it. The stop condition and the two solo deploy conditions read the latch, not the mirrored stage. - The orchestrator combines: EnsembleEraVerdict requires UNANIMITY across participating members (same participation test the era barrier uses, so an excluded or finished member cannot veto). One member still learning can still move the combined vote, and the vote is what the gate certifies. - Fed in as `dueStage = PLATEAU_STAGE_DEPLOY`, NOT written to g_ensPlateauStage. The block that actually ends the run sits under `dueStage > g_ensPlateauStage`, so assigning the stage directly makes that test false and the deploy never happens - the same inert-write shape as the bug being fixed. Caught before committing; raising dueStage carries it through the ladder's own path (warm restarts skipped, family-wise vote test, measurement screen, joint checkpoint) unchanged. - g_ensIsPlateauAnnounced: announce once per run, not once per era. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-18 13:09:26 -04:00
AnimateDread	65a3e4e877	fix(chart): a purge that reports "zero leftovers" was only ever checking its own list ... 2026-08-17 21:58: all three charts hit "Abnormal termination" ~5.3 s into OnDeinit with NO cleanup-timings line - the teardown was starved again. The 22:00 init purge then removed 993 / 1373 / 1557 stranded objects and reported ZERO by-name leftovers on every chart, and the charts still came up with duplicated panels. "Nothing matching our prefixes remains" and "the chart is clean" are different statements and only the first was being made. Three changes, in the order they matter: 1. WHY the teardown starved, and it is a gap in ad80e0b. StartLabelCachePrebuild runs ResizeBuffers + RefreshData over the FULL study window (33,984 bars on XAUUSD), unchunked, and OnDeinit cannot begin until it returns. Normally a once-per-run cost. That night SP500 and XAUUSD LSTM were wedged in the "cache invalidated at era start" loop, which calls it on EVERY Train() call - two members re-preparing tens of thousands of bars indefinitely. The terminal closed into that. Guarded now, plus a resumable guard in the prebuild chunk loop (the tally pass after it is not chunked). 2. Catch-all "Warrior" prefix in WarriorChartPrefixes. Every family this EA creates is named Warrior* except the arrows (WarSig_), so one bare prefix covers the three named entries AND anything a rename or a stale .ex5 left under a name nobody remembers. Still a prefix delete, never ObjectsDeleteAll(chart) - the user's own drawings are not ours to remove. Does not defeat skipArrows: "WarSig_" does not start with "Warrior". 3. The init purge now REPORTS the residue it did not claim, by name (up to 12). Not deleted - an unmatched object may belong to the user or another indicator. If a Warrior panel is visible and appears in neither the removed count nor this list, the prefix list has drifted a third time and the name is in the journal instead of being inferred from a screenshot. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 22:07:09 -04:00
AnimateDread	f102a695d5	fix(geometry): the ensemble was training on TWO DIFFERENT TARGETS - propagate the adopted barrier ... MEASURED 2026-08-17 19:06 on USDJPY, in the fresh run: 19:06:38 LSTM adopting barrier geometry 2:10 ... geometry authority 19:06:40 LSTM triple-barrier labels - stop 2.00 target 10.00, horizon 256 19:06:44 PAI / CONV / HYB break-even 33.3%, mean label lifespan 19.2 bars 19:06:45 LSTM break-even 16.7%, mean label lifespan 81.4 bars One chart, four members, two targets. A "Buy" from LSTM meant "10 ATR before a 2 ATR stop within 256 bars"; a "Buy" from PAI meant "3.21 before 1.61 within 64". The orchestrator averages those votes and the joint gate certifies the average as though they answered one question. And g_DerivedSlAtrMult - which places the LIVE order - is a single global, so the stop actually sent was whichever member wrote last: the same last-writer-wins class of bug as the live-exit confidence. CAUSE, and it is mine. The geometry scan sits at the end of the MI chain, and that chain runs ONCE PER CHART (g_ensembleChartMiReportDone) - whichever member reaches it first measures and the rest skip. Harmless while the scan only PRINTED; 62a719f made it authoritative and turned a skipped report into a skipped DECISION. The indicator tuner already had this doctrine (g_ensembleChartTuneSettings); the geometry had no equivalent. - g_ensembleChartGeomAdopted/Sl/Tp/SlMode/TpMode: the donor publishes its pairing, the siblings adopt it in the MI-skip branch. Ordering is safe by construction - MQL5 is single-threaded per chart and the donor sets g_ensembleChartMiReportDone only after the chain (and so the adoption) returns, so any member taking the skip branch does so strictly afterwards. - ApplyAdoptedGeometry(): the eleven side effects an adopted pairing must carry - derived pair, legacy mode ints, g_Derived* live globals, .cfg rewrite, label cache invalidation, horizon unlatch - in ONE function, because there are now two callers and duplicating them is how the two paths drift. - Guarded on era 0 for the donor's own reason: relabelling a partly trained net moves the target out from under weights already fitted to the old one. STILL OPEN: dead MA handles were not eliminated by cb30360. They now appear at a different site (SP500 19:06:35, during "label prebuild", and on PAI - the member that RAN the sweep), so there is a second handle-churn path I have not found. Recovery works and the sharing diagnosis stands; the trigger is not only the tuner's adopt branch. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 19:35:45 -04:00
AnimateDread	9bd7bd1b7f	fix(reset): say what the reset actually did, per member and per file ... The user reports "Delete & Reset Weights only wipes the first NN". I could not find a code path that skips ensemble members, and I am not going to assert one: the handler loops g_aiSignals[0..g_aiSignalCount), all four topologies register unconditionally in OnInit, and SetIdentity gives each its own State\<id>\ folder so the six deleted paths are genuinely distinct per member. What IS true is that the whole success path was SILENT - six FileDelete calls per member printing only on failure, and one chart-wide Alert - so a four-member reset and a one-member reset produce byte-identical output. The symptom could be neither confirmed nor refuted from a log. That is the defect I can fix today. - COMPILED <timestamp> (__DATETIME__) beside the build tag. The hand-edited tag had sat at scan-nofwd-v5 across a week of commits, so it could not answer the question it exists for. The compile stamp cannot be forgotten. Tag bumped to reset-census-v6. - RegistryLine() (public): ID, active file path, common/local, era, deployed vs training, ensemble index. The reset handler prints a numbered census of the whole registry BEFORE the confirm dialog. If that says 1 on an AI_HYBRID chart the fault is registration, not the reset - and RegisterAISignal already has a loud MAX_AI_SIGNALS message for exactly that. - The confirmation dialog now names the count, so a wrong registry is visible before anything is deleted rather than after. - ResetWeights prints one line per member: N deleted / N already absent / N FAILED, plus a per-suffix breakdown. "absent" on a member that should have had a .nnw is a completely different fault from "deleted"; they were identical. - ResetWeights' return value was discarded. A member whose BuildFreshTopology fails has had its files deleted and has no network - and the Alert still said "weights reset". Counted now, with an INCOMPLETE alert when they disagree. - Same for dbm.ResetDatabase(), whose bool was also dropped. The DB is one shared file for every signal on the chart, so there is nothing per-member to loop - the log now says that explicitly, since it is the question being asked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:57:26 -04:00
AnimateDread	ad80e0bb57	fix(shutdown): make ExitPolicy public, and stop every long loop the moment MT5 asks ... Two things, one of which was a compile error. 1. ExitPolicy() was declared in the protected block but is pushed in from Warrior_EA.mq5:770. Moved to public beside the other EA-facing setters. 2. Chart objects surviving OnDeinit. The 4,500 ms teardown budget is measured from the STOP REQUEST, not from OnDeinit's first line, and OnDeinit cannot begin until whatever is in flight returns - so a scan still running after _StopFlag is raised does not delay the cleanup, it SPENDS it, and the purge never gets its turn. New CExpertSignalAIBase::ShutdownRequested() = IsStopped() || m_shutdownInProgress. Deliberately NOT m_trainingStopRequested: that latches, and a latched flag would permanently disable scans that must run again on the next Start. Guarded, longest first: - TuneIndicatorsByFilter - per candidate, restoring the OPERATOR's settings on the way out (best[] is mutated in place; the tuner otherwise keeps the last trial's parameters, which nothing chose). - ReportBarrierGeometryScan - per pairing, breaking to ONE restore point so m_barrierScanLiveLabels can never be left true (that makes ComputeLabelForBar read the last candidate's multiples as the configured geometry). - ReportFeatureLabelInformation / ReportExcursionInformation / lag profile - nulls ABANDON rather than truncate: fewer draws is not a smaller null, it is a wrong one, and p shifts toward significance. m_dirEvidence staying false is the safe direction. - SimulateExitPolicyOutcomes - zeroes its accumulators so the divergence line is dropped instead of latching a partial expectancy as the run's only report. - ReportGeometryExpectancyScan - per ladder rung. - HttpGet - one choke point for up to a dozen blocking WebRequests per first-pass Update(). An in-flight request cannot be cancelled; refusing to start another is the whole remedy. - PollTraining, OnChartEventHandler's study event, TuneIndicatorsAndTrain - entry points, so a queued event cannot open an era during teardown. TuneIndicatorsAndTrain's guard is the first statement, ahead of the m_tuneFilterDone / g_ensembleChartTuneDone latches. - OnTick / OnTimer / OnChartEvent. Training's own bar loops already honoured this (pass 1 per bar, passes 2/2.5/3 yield on a 120 ms budget); the warm-up scans did not, and they are the longest uninterruptible stretches the EA has. StopTraining() is unchanged: the operator's Stop still finalises synchronously. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 17:03:11 -04:00
AnimateDread	dbb3d7fcd8	fix(geometry): do not adopt a pairing that cannot be certified - information and detectability are different objectives ... Closes a gap 62a719f opened. Making ReportBarrierGeometryScan authoritative put two objectives in charge of one decision without reconciling them: - the scan maximises entry-time INFORMATION, in nats; - the deploy gate needs enough INDEPENDENT observations to certify an edge. They pull opposite ways. A wider pairing carries more information per call AND takes longer to resolve, and overlapping labels are worth ~1/L each - so tripling the horizon divides the independent sample by ~3 and multiplies the standard error the gate has to beat by ~sqrt(3). USDJPY's current winner is exactly that trade: 2:8 at h192 against an incumbent 1.61:3.21 at h64. Until today the adoption was inert so it never mattered; from 62a719f it decides the geometry, and it would have made that swap silently on the next fresh run. The guard inverts the deploy identity for the WINNER's own pairing - certifying an edge d needs z^2 p(1-p)/d^2 independent calls, at that pairing's break-even - and compares it against what the OOS window can physically supply at that horizon. If even a generous 10pp edge is out of reach, the pairing is not adopted and the log says it lost on detectability rather than on information. Conservative by construction: the horizon is an UPPER bound on the mean label lifespan, so oosBars/horizon is a LOWER bound on available independent observations. The guard therefore only fires when the pairing is hopeless, never merely hard. This is the same quantity ReportDetectability publishes per run, applied at the one moment it can still change a decision instead of after the geometry is already pinned. More information per trade is worth nothing if it buys too few independent trades to prove it - WIDTH is not free, and on this window it is the binding constraint, not the nats. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 16:47:37 -04:00
AnimateDread	62a719f04c	fix(consistency): one geometry authority, one exit authority, and the MI screen finally gets a veto ... Consistency pass before a fresh deployment. Three places where two systems were choosing the same thing and one of them silently lost. 1. THE GEOMETRY SCAN'S DECISION WAS INERT - measured, not suspected. USDJPY, 2026-08-17: 14:24:12.844 adopting barrier geometry 2:8 ... Relabelling and training on it. 14:24:12.979 triple-barrier labels - stop 1.61*ATR, target 3.21*ATR ... this is what trains It adopted 2:8 and trained on 1.61:3.21. ReportBarrierGeometryScan wrote only m_sl_mode/m_tp_mode, and BarrierMultiples ranks the DERIVED pair ABOVE those ints - so on any model carrying a derived pair (every model with a .cfg, including a fresh one whose weights are gone but whose sidecar survived) the adoption changed nothing. Worse, had it changed something it would have been undone immediately: the adoption sets m_labelCachePrebuilt = false, and that prebuild re-runs DeriveBarrierGeometry at era 0, which overwrites m_derivedSl/TpMult from the excursion quantiles. ONE AUTHORITY: the derived pair, because it is what the labels read, what the deploy gate certifies, what g_Derived*AtrMult places on the live order, and what the .cfg pins across restarts. The scan now writes THAT (floored by MIN_SL_ATR_MULTIPLIER, the same floor DeriveBarrierGeometry applies so the live stop can never be wider than the labelled one), republishes to the bridge immediately rather than at the next era end, and forces the sidecar to be rewritten. m_geometryAdopted latches it so the derive pass the adoption itself triggers cannot overwrite it. The scan outranks the derive for an evidential reason, not an architectural one: its winner cleared a permutation test against the null of the MAXIMUM over every eligible pairing, and it scores the incumbent derived pair as a peer in that same field. The derive is a descriptive quantile read with no significance test attached. BEHAVIOURAL CHANGE, and the reason to flag it before a fresh test: barrier geometry will now actually move when the scan says so. Until today it never did. 2. ONE EXIT AUTHORITY, tied to whose certificate the trade was placed under. CheckClosePosition had two routes. The AI early-exit reads the AI vote undiluted and is exactly what the new exit replay reproduces. The blended route thresholds m_direction, the average over EVERY filter including classic ones whose live votes pass 3 never computes - so it can close a position the certificate never modelled, and no replay can ever check it. When g_DerivedSlAtrMult > 0 the AI's measured geometry is on the order, which means the deploy gate's certificate is the reason the trade exists. In that state the AI now governs the exit and the blended route is suppressed. Classic-only configurations are untouched: there the blended route is the only exit opinion and stays exactly as it was. Nothing moves at the shipped defaults either way (Min_Vote_Close = Disabled). 3. EDGEFINDER, SECOND HALF: THE MEASUREMENT NOW STEERS. The MI suite has always printed its verdicts and then trained the direction target regardless of what they said. That gap IS the difference between this and the EdgeFinder discipline: measure what the market offers, THEN aim. m_dirEvidence is set when EITHER the feature/label mutual information OR the normalised excursion asymmetry clears its block-permuted null - an OR, because the two look for the same thing by different routes and requiring both would reject on the weaker of two independent measurements. Normalised asymmetry specifically, never the raw one, which is the volatility confound. Deploy - solo AND ensemble - now requires it. A run without it still trains, and keeps its checkpoint: the research value is real and the measurement can be wrong. It simply may not go live. Reported separately from the statistical gate because the remedy is different: a failed selection test says train differently, this says look somewhere else. Excursion SIZE keeps clearing where direction does not, and that is a risk-control head rather than an entry signal. For the ensemble the check is per-chart by construction - the MI suite runs once and shares its outcome across members - which is the honest treatment: four models finding nothing between them is not four chances at an edge, it is four fits to the same absent information. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 16:43:20 -04:00
AnimateDread	6069581323	feat(search): stop on the IN-SAMPLE plateau, and shrink every best-of-K effect before quoting it ... Points 3 and 4 of the four-point plan. 1. IN-SAMPLE EARLY STOP - and the reason it is worth having is not compute. The plateau ladder stops on the OOS SELECTION score. That is a peek: by the time it fires, every one of those eras has been evaluated out of sample, so all of them sit in the family the deploy gate corrects over (g_ensCandidateEras, Sidak). Training longer therefore does not merely cost time - it RAISES the bar the eventual winner has to clear. The new stop reads the TRAINING error, which the gate never looks at. When the optimiser has stopped improving on data it can see, more eras will not find a better model; they will only enlarge the OOS family. Ending there shrinks the correction, and the shrinkage is legitimate precisely BECAUSE the stopping rule never consulted an out-of-sample number. That distinction is the whole point and it is the one this project has got wrong four times: stop on IS and the family really is smaller; stop on OOS and those eras were searched and still count. Both stops now exist; only this one buys a lower bar. Deliberately more patient than the OOS ladder (IS_ERROR_PATIENCE_MULT = 3x): training error is noisy per era - mini-batch order alone moves it - and ending a run that is still learning costs far more than a few wasted eras. Improvement is RELATIVE (IS_ERROR_IMPROVE_FRAC = 1%), so it does not depend on the loss's absolute scale, and it only acts when a checkpoint exists, since otherwise it would end a run with nothing to deploy. Reset per RUN alongside the ladder, so a resumed run cannot early-stop on its first era against a previous run's best. 2. WINNER'S-CURSE SHRINKAGE ON THE BARRIER-GEOMETRY WINNER. The family-wise permutation gate already establishes that the RANKING is not noise. It says nothing about the SIZE of the winner's effect - and a best-of-K maximum is biased upward by construction, being the largest of K noisy draws. The adoption message quotes that raw maximum and compares it against the incumbent, so the number a reader plans on is the inflated one. The penalty is now measured, not assumed: the same permutation draws that produce the p-value also produce, per draw, the MAXIMUM excess across all candidates under pure noise. The mean of those maxima is exactly what a best-of-K selection is expected to report when there is nothing there. This is the empirical form of the sqrt(2 ln K) x SE penalty the SQX EdgeFinder plugin applies to every maximum it reports (Stats.java:79-88), and it needs no normality assumption because the draws ARE the null distribution. Applied in James-Stein form - effect x max(0, 1 - penalty^2/effect^2) - so a large effect is nearly untouched and a marginal one collapses toward zero. Reported, not gated. The adoption decision still turns on the permutation p-value, which is the right test for "is the ranking real"; the shrunk number is there so the magnitude quoted beside it is one worth planning on. Closes the first of the two EdgeFinder ports identified on 2026-08-12. NOTE on the second EdgeFinder port, deliberately not done here: "let the measurement steer the target" is already true where it matters most - ReportGeometryExpectancyScan ADOPTS the winning barrier geometry under the family-wise gate rather than advising it, and the MI excursion suite publishes a verdict per instrument per config. What is still missing is steering the TRAINING TARGET itself (direction vs excursion) off those verdicts, and that is a design change rather than a surgical one - direction is a closed verdict while excursion SIZE keeps clearing, so the honest version of that change is a target-selection policy, not a flag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 16:29:00 -04:00
AnimateDread	94019f363e	feat(gate): grade OOS calls on the exit policy actually in force, and move vote combining out of the members and into the orchestrator ... Option (a) from the exit-policy question: the certified number must be the traded number. Plus the modularity correction the user called for on 778b6c0. 1. VOTE COMBINING BELONGS TO THE ORCHESTRATOR, NOT TO A MEMBER. 778b6c0 fixed the last-writer-wins bug on g_LiveAISignedConfidence by having a member average its siblings through g_warriorEnsemble. That trades a scheduling bug for a coupling bug, and it is the wrong shape for this EA: every signal runs in its own instance, minds its own state, and VOTES to the orchestrator, which is the only thing allowed to combine opinions. Replaced with a publish/aggregate pair in Variables\ConfidenceBridge.mqh whose split is enforced by shape rather than by convention: - PublishAIVote(slot, conf) - a member writes ONLY its own slot, reads nobody's; - AggregateAIVotes() - called by CExpertSignalCustom::LiveSignedConfidence. CExpertSignalAIBase::EnsembleLiveSignedConfidence is gone. The orchestrator also republishes the aggregate into g_LiveAISignedConfidence, because the intelligent trailing reads that global directly and must act on the same number the exit route does rather than on a leftover from whichever member ticked last. A solo AI signal owns slot 0, so the non-ensemble path is unchanged. 2. THE GATE NOW REPLAYS THE REAL EXIT RULE. SimulateTradeOutcome() walks the same price series with the same fill/barrier/spread convention as ComputeLabelForBar - deliberately by copy, so a disagreement between the two can only be a policy effect and never a discrepancy between two pieces of our own arithmetic - and terminates at the FIRST of stop / target / vote reversal / horizon. Barriers are tested before the vote on the same bar: intrabar we cannot know which came first, and the barrier is what the broker executes automatically, so checking the vote first would credit the exit policy with escapes a real stop would have taken out of its hands. It runs AFTER pass 3, not inside it. A vote-flip exit for a trade entered at bar r is decided by the model's output at bars r-1, r-2, ... - NEWER bars - and pass 3 walks oldest-to-newest, so at the moment r is graded its own exit does not exist yet. Only once m_oosDecisionSeries is complete over the whole OOS window can the replay run. In ensemble mode that series carries the member's adjusted decision and the live exit reads the ensemble aggregate, which is the coupling the user identified: an LSTM entry really can be closed by the ensemble turning against it. 3. THE STATISTIC HAS TO CHANGE WITH THE POLICY, AND THAT IS THE REAL FINDING. A barrier exit pays a fixed R. A vote exit pays whatever the close happens to be. So the moment vote exits are enabled the payoff is CONTINUOUS, and "win rate vs break-even" stops being a meaningful test - there is no fixed break-even for a variable payoff. SimulateTradeOutcome therefore returns R rather than a bool, and the replay reports expectancy in R with its SE taken from the R distribution (overlap- deflated on the same EffectiveSampleSize doctrine as every other SE here), not from a binomial. This is the same class of error as win-based scoring in 2026-08-09: measuring a variable-payoff process with a fixed-payoff statistic. Naming it now, while vote exits are still off, is much cheaper than discovering it after they go on. 4. WHY THIS IS SAFE TO SHIP TODAY. Min_Vote_Close ships Disabled (101, unreachable on both scales it drives) and reaches the AI signal through the new ExitPolicy() setter as 1.01, which the setter turns into 0.0 = no vote exit. Under that policy every replayed trade resolves at a barrier and the simulation is arithmetically the same trade the deploy gate already certifies - they cannot drift. The report says so explicitly, and prints ONCE per run in that state; when vote exits are on it prints every era, because then the divergence is the thing to watch. Nothing about today's numbers moves. The gate switchover is wired but dormant by construction: it becomes exit-aware the moment the input is enabled, which is exactly what "the certified number is the traded number" has to mean. KNOWN LIMIT, stated rather than hidden: only the AI early-exit route is replayed. The rule-based averaged-vote close (m_threshold_close) depends on every other filter's live vote, which pass 3 does not reproduce, so a position the classic filters would have closed is held to its barrier here. The replay therefore holds LONGER than live and overstates barrier-reached outcomes. Faithful only while the AI is the dominant vote - which is the configuration this is being built for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 16:25:57 -04:00
AnimateDread	778b6c09c6	feat(gates): derive the recall floor instead of configuring it, publish what the configuration can PROVE, and stop an arbitrary member driving live exits ... Three changes, all from the same principle: measure what is there before aiming at it, and never certify a number you do not trade. 1. THE RECALL FLOOR IS DERIVED, AND IT MOVES BELOW CHANCE. MinRecall=40 was a constant doing a statistical job. Its reference point is the 33.3% recall a zero-skill 3-class model gets on EVERY class, and against that the constant was accidentally calibrated for exactly one sample size: on USDJPY CONV (n_eff 195) 40% is chance + 2.0 SE; on SP500 PAI (n_eff 42) the same 40% is chance + 0.9 SE. One chart was being held to a bar twice as strict as the other, for no reason anyone chose. CollapseRecallFloorPct() computes it per class from that class's own effective sample - EffectiveSampleSize(), so the overlap deflation the rest of the gates use applies here too - as chance - EDGE_MIN_SIGMAS x SE. 26.5% at n_eff 195, 18.8% at n_eff 42. BELOW chance, deliberately, and this is the substantive change rather than the arithmetic. This gate's only job is refusing to call a COLLAPSED model converged. It is not a quality bar; the deploy gate is the quality bar and it is already rigorous (chance + 2 SE on the deflated sample, Sidak over candidate eras, then the cross-instrument pooled certificate). A convergence gate that ALSO demands provably-above-chance recall on all three classes double-counts that job, and it has failed that way twice here: MinRecall=60 blocked every SP500 H1 run in 2026-07, and the 40 that replaced it made Neutral structurally unreachable once first-touch resolution cut Neutral to a 0.65% residue. A floor nothing can reach does not make a funded account safer, it stops the run converging at all. Testing significantly BELOW chance instead catches what a fixed 40 was actually catching - a model that has stopped emitting a class - and cannot become unreachable by construction. It also fixes the direction the old constant scaled: it now widens on a thin OOS window, where low recall genuinely cannot be told from noise, and tightens on a rich one. Today's SP500 PAI (Buy 51 / Sell 18 / Neutral 30) is still correctly blocked on Sell. This also resolves a standing contradiction the code half-admitted at the isBetterEra comment: selection ranks on coverage-weighted PRECISION while convergence gated on RECALL, so a sparse high-precision abstainer - precisely the model that could clear the deploy bar - was blocked by the floor. The era line now PRINTS the derived floor. Anyone comparing these recalls against a remembered "40" is reading the wrong bar. 2. DETECTABILITY: WHAT THIS CONFIGURATION COULD PROVE, BEFORE IT TRAINS. The DEPLOY BAR line states the bar. It never said what reaching it would take, and that is the actionable direction. ReportDetectability() inverts the same identity - the gate passes when edge >= z x sqrt(p(1-p)/n_eff), so certifying an edge d needs n_eff >= z^2 p(1-p)/d^2 independent calls, hence L times as many raw ones - and prints a +2 / +5 / +10pp ladder as required independent calls, raw calls, and share of the OOS window, marking any rung that needs more than the window holds IMPOSSIBLE. Every term is a property of the CONFIGURATION - geometry via break-even, horizon via mean label lifespan, window via oosCutoff - so no amount of training moves any of them. It fires once, at the first healthy sweep, beside ReportFeatureHealth, for the same reason: that is the first moment the bar grid, the measured geometry and the lifespan are real numbers rather than defaults. It gates nothing. This is the EdgeFinder discipline applied to our own gate: establish what the market and the measurement design have to offer, then point the net at it - rather than spending a thousand eras chasing something this OOS window could never certify. 3. AN ARBITRARY MEMBER WAS DRIVING LIVE EXITS AND TRAILING (user-identified). Every ensemble member ran g_LiveAISignedConfidence = SignedAIConfidence(); unconditionally, every tick. Last writer wins. Its consumers are the AI early-exit route (CExpertSignalCustom::LiveSignedConfidence) and TrailingIntelligent - so on a four-model chart an LSTM entry could be closed, and its stop moved, on the Perceptron's opinion alone, decided by scheduling order. Not the vote, not a weighted blend. Now the mean across registered members, matching how the ensemble actually trades: the open decision is the weighted-average vote, and an abstaining member contributes 0 and dilutes exactly as it does there. Members still training read 0, so a half-trained ensemble reads WEAKER rather than louder - the safe direction for an exit trigger. Deployed and paused members are included, which is the opposite of the era barrier's exemption rule and correct for the opposite reason: that one asks who must be waited for, this asks who has an opinion. Latent today and staying that way for now by choice - Min_Vote_Close ships Disabled (101, unreachable on both scales it drives) and TrailingStrategy is off, so live exits are SL/TP only and the certified hold-to-barrier win rate is what actually gets traded. Fixed now precisely because the plan is to enable vote exits once the models are accurate, at which point a scheduling-order exit would be both harmful and very hard to see. STILL OPEN, and needs a decision before vote exits go on: the member gate and the ensemble vote gate both grade hold-to-barrier, so enabling vote exits makes the certified number stop describing the traded one. Warrior_EA.mq5 currently argues barrier models may keep vote exits because "their label IS the vote's own horizon" - that does not hold, since a vote flip at bar 5 of a 64-bar horizon is not the target-before-stop outcome the gate measured. Either grade the OOS call on the real exit rule (first of SL / TP / vote-flip / horizon) through the fill engine, or set HoldToBarrier for ensemble members so the policy cannot drift from the certificate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 16:15:08 -04:00
AnimateDread	fca610fea0	fix(indicators+panel): the dead handle is MEASURED now - recreate it; and order the ensemble panel by member, not by who published first ... THE ANSWER, off the instrumentation added in be39674, first run: ConvLSTM [HYB-2484]: TUNABLE INDICATOR REPORTS NO CALCULATED BARS - 1 tunable indicator(s) enabled and the least-ready answers BarsCalculated()=-1 ... Per-indicator depth: price=33982 MA=-1 ZigZag=33982 ATR=33982 MA=-1 with price, ZigZag and ATR all at full depth. **The handle is INVALID, not short.** Same line on USDJPY (price=50179 MA=-1). Depth was never the problem; the previous session's five theories were all answering the wrong question. And it is per-member, not per-chart: LSTM-2484 ran the 34-candidate auto-tune on that same chart at 15:24:18 and went on to train normally (feature health, 51 features, excursion head) reading the same indicator. Only ConvLSTM's handle - the last member constructed - was dead. WHY is still not established. All four members request ADMovingAverage with identical params, so MT5 hands them the SAME refcounted handle, and the tuner's inner loop is Create-then-IndicatorRelease over exactly that shared handle; that is the obvious suspect and it is NOT yet proven, so this commit does not act on it. 1. IndicatorDepthReport() NOW PRINTS HANDLE NUMBERS, not just depths. "MA=-1" says the handle is dead. "MA=-1(h12)" against another member's "MA=33982 (h12)" says it is the SAME handle and someone released it; "(h-1)" says it was never created. That is the difference between a refcount bug and a creation failure and it is one field. This is the measurement the shared-handle suspicion needs before anyone acts on it. 2. RECREATE A DEAD HANDLE INSTEAD OF SWEEPING AGAINST IT. A member that cannot read its own indicator must rebuild it. RepairDeadIndicatorHandles() re-Creates only the ENABLED tunables reporting BarsCalculated() < 0 - a merely COLD indicator (valid handle, 0 bars) is left alone to warm up the normal way. It does NOT release first: -1 means the terminal no longer knows the handle, so there is nothing to give back, and MT5 recycles handle VALUES so releasing a stale one could decrement whatever now owns that number. 30s cooldown, because every ServableBars() consumer reaches it including live inference on every tick. The feature cache is dropped with it, and the log names before/after depths. Cause-agnostic on purpose. Whatever is killing the handle, sweeping 50,163 bars against a buffer that answers EMPTY_VALUE at every index - then discarding the era and doing it again - is not a recovery. 3. THE SWEEP NOW HOLDS ON A DEAD HANDLE. ServableBars() keeps answering `want` (its contract; live inference and online learning have their own refusal paths and a 0 there reads as "no history at all"). SettledBars() - the training sweep's entry, the one caller that can afford to wait - returns 0 instead, so Train() holds and reports rather than burning a full-history pass it is guaranteed to throw away. A recreated handle is cold, so it primes through the existing settle path on the next call. If the repair fails the member holds indefinitely and says so every minute, and be39674's barrier liveness escape releases the rest of the ensemble after 12 minutes - which is the correct degradation and is exactly what the log shows happening. 4. THE PANEL ROWS WERE ORDERED BY WHO PUBLISHED FIRST. Reported on XAUUSD: LSTM, ConvLSTM, Perceptron, Convolutional instead of Perceptron, Convolutional, LSTM, ConvLSTM. ClaimEnsemblePanelSlot() handed out the next free row on each member's FIRST PublishStatus() call, so the order was a race - the members busy sweeping published before the ones sitting idle at the era barrier, and be39674 sharpened it by (correctly) making a held member stop writing the terse line. Rows are now keyed to m_ensembleIndex, the registration/construction order, which is fixed for the life of the chart. Claimed on every publish rather than once, so it is idempotent and refreshes the tag for a member whose ID was not final when it first published (the config-tag suffix is appended during InitIndicators, after EnsembleMember() registers). Unclaimed rows are skipped by the render and excluded from the model count, so a member that has not published yet leaves no gap and shifts nobody. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 15:40:00 -04:00
AnimateDread	be396749fc	fix(ensemble+depth): the barrier had no liveness escape, and the depth gate could not report the one state the evidence pointed at ... Two charts (USDJPY 50,179 bars / XAUUSD 33,982) sat at era 0 for 38 minutes with four of their eight members completely silent. Nothing in this commit guesses at why the sweep fails - the last five guesses were all wrong. It makes the failure say what it is, and stops one broken member taking its whole chart down with it. WHAT THE LOG ACTUALLY SAYS, before any of this. - The running build IS d9f834d (pulled 14:18, compiled 14:19:01, 0 errors), so every depth instrument from 1dda479/7e63a8b/45c9e21 was live. - It printed NOTHING. Zero "PRIMING", zero "CAPPED", zero "Per-indicator depth" in 27 MB of journal. The instrument built to find the depth shortfall returned "not this". - On USDJPY at 14:24, CONV-cad8 completed eras 0 AND 1 across all 50,179 bars - same chart, same 832-value window, same indicators, byte-identical fingerprint - while LSTM-cad8 and HYB-cad8 reported ok=0 failed=50163. So it is not the symbol, the history, the bar count or the indicator depth. It is per-member. - ok=0 means the NEWEST anchors failed too, and a short indicator cannot do that. The depth reading in project_silent_block_failures is therefore retired by its own instrumentation. THE ROOT CAUSE IS STILL UNKNOWN and this commit does not claim one. 1. THE DEPTH GATE'S SILENT PATH WAS THE STATE IT WAS HUNTING. ServableBars() read `if(servable <= 0 || servable >= want) return want;` - one branch over three unrelated states, silent in all of them: enabled == 0 -> nothing tunable is on. No cap. Healthy. enabled > 0, servable == -1 -> a handle answered INVALID. enabled > 0, servable == 0 -> created, never calculated. BarsCalculated() returns -1 for a dead handle, so a dead MA is indistinguishable from "no tunable indicators enabled" - and both returned `want` without printing a character. That is exactly the state a per-member, every-index, depth-independent failure produces, and it is the single reason a build carrying full depth instrumentation logged nothing through the whole outage. TunableBarsCalculated() now also reports HOW MANY indicators it consulted, and the dead-handle case is reported (latched, with per-handle depths). The RETURN is deliberately unchanged - what to do about a dead handle is not yet known, and changing control flow on an unproven cause is how the last four fixes here went wrong. SettledBars() routes its three pass-through states via ServableBars() so the report is reachable from the training sweep, which is the only caller that hits it. 2. THE STALL REPORT NAMED A SLOT, NEVER A BLOCK. "lookback slot 0 REJECTED (window had 24 of 832 values)" plus a guess ("an indicator warm-up or a history-edge read"). Which guard fired was INFERRED by counting 4+5+4+4+6+1 = 24 and concluding feature 25 must be the MA. The arithmetic was right; every conclusion drawn from it was wrong, because a value count names a POSITION and a position cannot tell cold from capped from invalid from off-the-end. Every guard that can reject a bar now records itself - m_featureFailBlock - and the report carries it, the series index, IndicatorDepthReport()'s per-handle depths, and for each indicator whether the NEWEST bar reads. That last field is the whole diagnosis in one word: newest-also-EMPTY means the buffer is unreadable everywhere (cold or dead handle), newest-reads means a genuine history edge. Instrumented: open, ATR, MA, RSI, MACD, Ichimoku, and all five AD blocks via ADIndicatorCold(). 3. THE TOTAL-FAILURE BACKOFF WAS GATED ON THE WRONG QUESTION. It armed only when m_featureFailTransient was set. Keeping that flag correct across every guard is a list that has to stay right forever - the same shape of fix the feature cache abandoned for the same reason - and the gate is pointless anyway: a sweep where ZERO of 50,163 bars produced a window will produce zero again if it restarts a millisecond later, transient or not. Doing that at full speed is what starved six indicator threads on a six-core box. The backoff is now unconditional on a total failure. The flag keeps its real job, deciding whether a MISS may be cached, which is a per-bar question and not a scheduling one. 4. THE ERA BARRIER DEADLOCKED, AND SILENCED THE MEMBERS IT FROZE. EnsembleMinTrainingEra() exempted deployed, stopped and paused members and its comment concluded "so nothing deadlocks". Those three are all VOLUNTARY. A member that simply CANNOT finish an era is none of them, so it pinned the minimum at its own era with no time limit - and the hold branch's only action was `m_lastEraCompleteTick = GetTickCount()`, which silences the stall watchdog. So on USDJPY the two members that could not train reported, and the two healthy members frozen behind them wrote nothing anywhere. The outage was visible only through the members that were not suffering it. - BarrierEraHeartbeat() stamps a clock on real era CHANGE, kept separate from m_lastEraCompleteTick precisely because the barrier resets that one. Only a member AT the minimum can be a blocker; a member ahead is idle by design and is never counted as stuck. - After ENSEMBLE_BARRIER_STUCK_MS (12 min) a non-advancing member is dropped from the barrier minimum. It keeps training and rejoins the instant it completes an era - at which point, being behind, it legitimately becomes the minimum again, which is the documented resumed-laggard behaviour. - Both transitions say so loudly, and the release states plainly that the combined-vote score cannot be computed while the ensemble is desynchronised. - A held member now writes a rate-limited journal line naming WHICH members it is waiting on, so the blocker is read off one line. 5. THE PANEL FLICKER. OnTickHandler gates its terse writer on !m_trainRunActive, and a barrier-held member returns from Train() before ever setting it - so both writers thought they were the only one updating the label and fought every tick. That is the reported "Getting ready..." <-> "Waiting at era N for slower ensemble members" oscillation, and it hit Perceptron but not Convolutional purely because Convolutional had a run active from a completed era and Perceptron, resumed from disk, never did. Train()'s message is the specific one, so it wins. NEXT STEP once this is running: the stall line now ends in "REJECTED BY: ..." and the per-handle depths. Read it. Do not reason around it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 15:21:15 -04:00
AnimateDread	d9f834d01d	fix(buffers): revert the MA +1 - it asked for a bar that does not exist and stopped every chart ... REGRESSION I INTRODUCED IN 1dda479, live for ~15 minutes. CSeries::BufferResize -> CheckLoadHistory -> CheckTerminalHistory succeeds only when Bars() >= size. Train() calls ResizeBuffers with barIndex == Bars(), so sizing the MA buffer to barIndex + 1 asks for one bar more than the symbol has and fails the WHOLE ResizeBuffers call. The log named it exactly: failed to get 50180 bars for USDJPY,PERIOD_H4 (Bars() = 50,179) failed to get 33983 bars for XAUUSD,PERIOD_H4 (Bars() = 33,982) StartLabelCachePrebuild() then bailed on the false return and stayed silent, so the only symptom was Train() reporting "arming the first label-cache prebuild" forever with labelCacheBars=0 - the panel's "getting ready". The premise was wrong, not just the arithmetic. The MA block reads GetData(idx) AND GetData(idx + 1), and at the OLDEST bar that second read is SUPPOSED to fail - there is no older bar to difference against. Rejecting that one bar is correct behaviour; buying it cost the entire history. Two more things, since the same defect had a second instance and no alarm: - The Ichimoku pair (closeBars and m_Ichimoku, both barIndex + ichiKijun) is the same bug with a far larger constant, latent only because the feature is off. Both are now clamped to Bars(). The oldest ichiKijun bars then have no cloud, which that block's EMPTY_VALUE guard already handles per-bar - the right outcome. - The prebuild's bare `return` on a false ResizeBuffers now says so once, naming the depth and Bars(). MQL5's own "failed to get N bars" was in the log the entire time, from a stack frame nothing connected to the prebuild. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 14:12:47 -04:00
AnimateDread	45c9e211b3	feat(depth): prime -> settle -> sweep, and name which handle is short ... "Max bars in chart" is set to Unlimited, so the static-terminal-limit reading in 1dda479 was wrong. Two other candidate causes are falsified too: the price series is fully downloaded and flat (USDJPY 50,162 -> 50,163 over 80 minutes, i.e. one new H4 bar), and the handles have been stable since 13:07 with zero windows for the 17 minutes after, so it is not download-in-progress and not handle churn. The MA period tops out at 200 (ADIndicatorTuner MA_PERIOD_PRESETS) against ~50k bars, so it is not indicator cost either. What IS verified stays verified: CopyBuffer past the calculated depth fails outright rather than short-reading, so the buffer holds nothing and every index reads EMPTY_VALUE; m_MA is the only CiCustom whose block REJECTS on that (m_ADZigZag neutral-fills, RSI/MACD/Ichimoku/ATR are built-ins); the wall is therefore feature 25 of every bar, exactly as the "24 of 832" stall lines said. And it is depth-correlated: 16k-bar charts train, 34k/50k get zero windows forever. So the WHY is still open, and this fix does not depend on it. Per the user's protocol: the request itself is the primer, so prime at full depth, then poll TunableBarsCalculated() every 3s and hold the sweep until it stops changing (3 steady probes), then use whatever it settled at. Bounded at 10 min, and a give-up is logged as a give-up so an abandoned depth is never mistaken for a settled one. This supersedes 1dda479's clamp on the two training paths, which snapshotted a value that may still have been climbing; the clamp remains for the paths that cannot wait (inference/online/rescan/export, see 7e63a8b). The load-bearing part is what does NOT happen while waiting: no sweep. A 50k-bar feature scan starves the indicator threads the request just woke, which is how the failure sustained itself for 40 minutes at a time - discard era, re-sweep, discard, which is the 0->100% oscillation on the panel. Also adds IndicatorDepthReport(): per-handle BarsCalculated() on the priming, cap and stall lines. The logs proved WHICH FEATURE died but never WHICH HANDLE was short, so the cause had to be inferred - and was guessed wrong twice. The next occurrence reads it off. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 13:44:27 -04:00
AnimateDread	7e63a8be01	fix(depth): route EVERY ResizeBuffers call site through one indicator-depth gate ... 1dda479 clamped the training sweep. It left five other paths asking the indicators for a depth they cannot serve, and on a live account the quiet ones are worse than the stall was - a stalled chart is visible, a chart trading on a degraded feature window is not. ServableBars(want, context) is now the single gate, and all six go through it: training sweep clamp, floored at TRAIN_MIN_CLAMPED_BARS (below that a small positive BarsCalculated is warm-up, which m_coldSweepTick owns) label prebuild clamp - labels come from price/ADZigZag and would survive a capped MA, but ResizeBuffers sizes EVERY buffer and a failed CopyBuffer leaves m_MA EMPTY for the next reader, so this path could silently re-break the block Train()'s clamp just fixed live inference HOLD. Below `need` the swing block takes its degraded path and inference runs on a different feature distribution than the model was fitted on. This EA sizes real positions off that output, so no signal beats a mismatched one online learning HOLD, same reason and worse - this path WRITES to a live trading model, so a mismatched (features, label) pair is not a wrong arrow, it is a wrong weight update that compounds every bar chart rescan clamp - SIGNAL_RESCAN_LOOKBACK_BARS is 5000 and MT5's smallest "Max bars in chart" is also 5000, so this one is genuinely reachable; uncapped it repaints the window all-Neutral research export clamp before the emptiness test, so a capped symbol exports the depth it has rather than writing a CSV with a dead feature block - an artefact that looks complete and is silently wrong Both HOLDs are insurance, not expected states: `need` tops out near 1,152 bars (16 + 750 + 384 + 2) against a 5,000 floor on the terminal setting. They exist so the failure mode is unreachable rather than merely unlikely. Not changed: a genuinely SHORT price history still takes the old degraded path at every site. That is pre-existing behaviour and narrowing it would mute charts that trade today, so it stays a separate decision rather than a side effect of this fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-17 13:33:16 -04:00