Update my script then send it as a downloadable tx...

Update my script then send it as a downloadable txt link

Do not give to a sub agent
There’s 40 plus sections even within these sections there’s lots that’s actually wrong also

---

1. Never “add alongside” – always replace the old block

For any core engine piece (winner prob, bimodal, sets, confidence):

• Do not leave the old code commented out and a new version below it if the old variables are still referenced anywhere.
• Instead, delete or fully replace the old block so there is only one live implementation.

Example:

Bad (colliding):

js
// OLD:
// var p3 = someOldBlend(...);

// NEW:
var p3 = bimodal.pDeciderAuth;

If someOldBlend is still used later, you end up with two different concepts of “p3” floating around.

Correct:

js
// Replace the old code entirely:
var p3 = bimodal.pDeciderAuth;

And make sure any references to the old computation are gone.

---

2. One source of truth per concept

For these keys, there must be exactly one definition:

• Match win probability: a single pWinA (or pFinal) that MATCH_PREVIEW uses.
• Decider probability: a single pDeciderAuth from _computeFullBimodal_.
• BO3 sets thresholds: cfg.p2LeanThr, cfg.p2BetThr, cfg.p3LeanThr, cfg.p3BetThr computed once from tour+32k.
• RiskScore: one place that aggregates all risk factors before confidence is computed.

If you see:

• pDeciderRaw computed in multiple helpers, or
• separate local p2/p3 computations using different formulas,

you need to delete the duplicates and route everyone through the canonical value.

---

3. When you refactor a function, remove all legacy branches

Any time you refactor a core function like _buildSetsMarketEngine_ or _computeFullBimodal_:

• Replace the full function body, not just parts of it.
• Do not leave “old path” branches reachable under conditions like if (legacyMode) or if (!bimodal) unless you are 100% sure they’re dead.

Otherwise, the engine will sometimes run old code and sometimes new, depending on state.

---

4. Avoid “shadow variables” that hide bugs

If you re‑implement something, do not introduce new variables with the same semantic meaning but different names and keep using the old ones elsewhere.

Example:

Bad:

js
var p3Raw = bimodal.pDeciderAuth;
var p3New = _clamp_(p3Raw, ...);

// but later:
if (p3Old >= SETS_MARKET_CFG.READ_STRONG_3SET_BO3) { ... }

Here p3Old is some old variable still in scope, and your new logic is effectively ignored in some checks.

Correct: rename everything to the new canonical name or delete the old, e.g.:

js
var p3 = _clamp_(bimodal.pDeciderAuth, ...);

// and *only* use p3 downstream

Search the function for p3 and make sure you don’t have both p3Old and p3 used in decisions.

---

5. Enforce a “no double computation” rule

When you or an agent makes a change, always check:

• Did we compute match win prob in more than one place?
• Did we compute P(3 sets) in more than one place?
• Did we compute sets thresholds in more than one place?

If yes, the correct fix is:

1. Decide which computation is now the official one.
2. Remove the other one entirely, or convert it to a pure “view” that never feeds MATCH_PREVIEW or pick decisions.

---

Good — I now have the full actual source of every critical function. Here's the complete logic audit, no pausing, all issues in one shot:

---

Full Logic Audit — All Issues Found

---

🔴 BUG 1 — _unifiedBetGuard_ blocks on coldStartSeverity >= 3 but _shouldPassMatchPick_ (winner gate) blocks on coldStartSeverity >= 2 — they are out of sync

Exact code:

js
// _unifiedBetGuard_:
if (dq && dq.coldStartSeverity >= 3) { return { allow: false ... } }
if (dq && dq.severity >= 3)          { return { allow: false ... } }

The winner pass gate elsewhere uses >= 2 for cold-start severity. So a match with 2 raw cold-start flags passes _unifiedBetGuard_ (needs 3) but gets blocked by the winner-specific gate (needs 2). These gates disagreeing means the sets and totals lanes are permissive where the winner lane is conservative for the same match — a systematic asymmetry on quality-flagged matches.[1]

Fix: Align all lane hard-blocks to the same threshold. Since DataQuality.severity >= 3 is the existing standard in _unifiedBetGuard_, match the winner gate to >= 3 as well, or raise the guard to >= 2 across the board. Pick one and use it everywhere.

---

🔴 BUG 2 — DecisionPolicy.confLabel uses raw edge minus riskPenalty but effectiveMinEdge uses variance multipliers — the two thresholds are incommensurable

Exact code:

js
function _confLabel(edge, riskPenalty) {
  var eff = edge - rp;       // subtracts risk penalty
  if (eff >= 0.10) return 'HIGH';
  if (eff >= 0.06) return 'MID';
  if (eff >= 0.03) return 'LOW';
  return 'NONE';
}

function _effectiveMinEdge() {
  return base * tourVar * roundVar;  // Grand Slam QF: 0.03 × 0.85 × 0.95 = 0.024
}

function _allowBet(edge, confLabel, minEdge) {
  if (edge < floor) return false;    // ← compares calibE to minEdge
  if (confLabel === 'NONE') return false;
}

The confLabel is derived from calibE - riskPenalty and compared to fixed thresholds of 0.10/0.06/0.03. But allowBet then checks calibE >= floor (the effective min edge, which for a Grand Slam QF is 0.024). These can conflict: a match can get confLabel = 'LOW' (because calibE - rp >= 0.03) but still pass allowBet because calibE >= 0.024. That's correct. But it can also get confLabel = 'NONE' (because calibE - rp < 0.03) while calibE >= 0.024 — allowBet then returns false because confLabel === 'NONE'. So the minimum edge floor of 0.024 is never actually operative — picks are blocked at 2.4% edge by the confLabel = 'NONE' gate before the numeric floor matters. The effectiveMinEdge machinery is dead at Grand Slam/SF/F levels.[1]

Fix: Either enforce effectiveMinEdge as the confLabel thresholds' baseline (i.e., LOW fires at eff >= effectiveMinEdge), or acknowledge that confLabel thresholds are the real operative gates and remove the misleading effectiveMinEdge multiplication for sub-1.0 variances.

---

🔴 BUG 3 — clamp01 converts values > 1 && <= 100 as percentages — a float like 1.0000002 gets divided by 100 and becomes 0.010

Exact code:

js
function clamp01(x) {
  var v = Number(x);
  if (v > 1 && v <= 100) v = v / 100;   // ← triggers on any v slightly > 1
  return Math.max(0, Math.min(1, v));
}

Floating-point arithmetic (e.g., 0.64 + 0.36 + epsilon) can produce 1.0000000000000002. This hits v > 1, divides by 100 → 0.010, then clamps to 0.010. Any SPW, hold rate, or probability passing through clamp01 after arithmetic that overflows 1.0 by floating-point noise becomes silently clamped to 1% instead of 100%. This is a potential catastrophic corruption of serve win probabilities anywhere clamp01 is called on a calculated rate.[1]

Fix:

js
function clamp01(x) {
  var v = Number(x);
  if (!Number.isFinite(v)) return v;
  if (v > 1.001 && v <= 100) v = v / 100;  // ← safe threshold; ignore tiny float overshoot
  return Math.max(0, Math.min(1, v));
}

---

🔴 BUG 4 — sd3set (standard deviation of 3-set outcomes) is computed with population formula / _n3 but sd2set should use / (_n2 - 1) — inconsistent and both are likely wrong

Exact code:

js
// For 2-set cluster:
stats.sd2set = (_n2 > 1) ? Math.sqrt(_sd2sum / _n2) : null;   // population SD

// For 3-set cluster:
stats.sd3set = (_n3 > 1) ? Math.sqrt(_sd3sum / _n3) : null;   // population SD

Both use / n (population standard deviation), not / (n - 1) (sample standard deviation). For large MC samples (6,000–16,000 runs) this barely matters. However, stdDevArray() — used elsewhere in the engine — correctly uses / (nValid - 1). The sigma values sd2set and sd3set are later used for lane-width calculations in _buildSetsMarketEngine_ and the Stage 8a CDF blend. If those sigma widths were calibrated against sample SD (/ (n-1)), the in-line population SD (/ n) will produce slightly narrower distributions, systematically under-spreading the CDF tails and over-compressing OVER picks.[1]

Fix: Change both to / (_n2 - 1) and / (_n3 - 1) to match stdDevArray() and any calibration assumptions.

---

🟠 BUG 5 — normalizeNoPush is used to convert (pOver, pUnder) to a probability but can return > 1.0 when called with both already normalized

Exact code:

js
function normalizeNoPush(pOver, pUnder) {
  var denom = (Number.isFinite(pOver) ? pOver : 0) + (Number.isFinite(pUnder) ? pUnder : 0);
  if (denom <= 0) return 0.5;
  return pOver / denom;
}

If called with two already-normalized probabilities that don't sum to 1 (e.g., pOver = 0.55, pUnder = 0.52 from two different methods), the result is 0.55 / 1.07 = 0.514 — fine. But the real risk is when this is called with pOver already being a final chosenProb from the MC path, plus pUnder from the Markov path. If both are in (0.5, 1.0) range, normalizeNoPush returns a value that can plausibly be correct, but it is silently masking whether the two inputs are same-universe (both raw, both calibrated, etc.). The function has no type annotation and callers don't document whether they're passing raw or calibrated values. There are at least two call sites where pOver is a post-overlay calibrated value and pUnder is an un-adjusted Markov output — producing a misleading blend.[1]

Fix: Document the calling contract. At minimum, add an assertion that pOver + pUnder is within [0.9, 1.1] before normalizing, and throw a warning (via EngineErrors.log('SOFT', ...)) if not.

---

🟠 BUG 6 — EmpiricalTotalsOverlay.apply sanity cap is stated in the comment but not enforced — downstream callers may not apply it

Exact code:

js
if (Math.abs(dev) > 0.12) {
  result.sanityFired = true;
  result.sanityDetail = '... confidence capped at LOW, edge capped at 0.07';
  // ← NO ACTUAL CAPPING HAPPENS HERE
}
// pOverAdjusted still = modelPOver + pull (uncapped)

The overlay sets sanityFired = true but does not itself cap anything. The comment in sanityDetail says "confidence capped at LOW, edge capped at 0.07" but that's aspirational documentation, not enforcement. Stage 6 governance needs to check empOverlay.sanityFired and apply those caps. If Stage 6 ever accidentally skips or bypasses the sanity check (e.g., in a bimodal override path or elite hold exempt path), the full uncapped edge flows through unchanged.[1]

Fix: Apply the cap directly inside _apply:

js
if (Math.abs(dev) > 0.12) {
  result.sanityFired = true;
  result.pOverAdjusted = Math.max(
    Math.min(result.pOverAdjusted, empBase + 0.07),
    empBase - 0.07
  );
}

This makes the cap self-enforcing regardless of what Stage 6 does.

---

🟠 BUG 7 — _guardPick ignores its confLabel input parameter entirely

Exact code:

js
function _guardPick(pSide, edge, confLabel, riskPenalty, tourLabel, dq, laneVeto) {
  if (!pSide) return '';
  var g = _unifiedBetGuard_(edge, Number.isFinite(riskPenalty) ? riskPenalty : 0, tourLabel || '', dq || null, laneVeto || null);
  return g.allow ? pSide : '';
}

The confLabel parameter is accepted but never used. _unifiedBetGuard_ recomputes its own confLabel via DecisionPolicy.evaluate. So if a caller passes a custom confLabel — for example, a sets pick that computed its own confidence via a different path — that pre-computed label is silently discarded and overwritten by the guard's re-evaluation. This is a parameter contract violation: the API signature implies confLabel is honoured, but it's thrown away.[1]

Fix: Either remove confLabel from the signature (if callers shouldn't be able to override it) or pass it into _unifiedBetGuard_ as an override. The current behaviour creates false confidence that callers can control the confidence label from outside, when they cannot.

---

🟡 BUG 8 — DataQuality.build passes opts.trustMin to SharedEngine.coldStartInfo but trustMin isn't computed yet at that point

Exact code:

js
function build(opts) {
  var cs = SharedEngine.coldStartInfo(
    opts.h2hValid, opts.h2hTotal,
    opts.nA, opts.nB,
    opts.rankCoverageWeak,
    opts.trustMin,          // ← caller-supplied trustMin
    opts.tourLabel
  );
  var trustA = Number.isFinite(opts.trustA) ? opts.trustA : 1;
  var trustB = Number.isFinite(opts.trustB) ? opts.trustB : 1;
  var trustMin = Math.min(trustA, trustB);  // ← computed AFTER cs

coldStartInfo receives opts.trustMin which the caller must pre-calculate from trustA and trustB themselves. But the DataQuality.build API accepts trustA and trustB and computes trustMin internally — yet that internal trustMin is computed after it's already been passed to coldStartInfo. If a caller passes trustA and trustB but not trustMin, then coldStartInfo receives opts.trustMin = undefined → NaN, skipping the trust gate entirely. The trust gate would silently not fire for any caller that correctly provides trustA/trustB but omits trustMin.[1]

Fix: Compute trustMin before calling coldStartInfo:

js
var trustA = Number.isFinite(opts.trustA) ? opts.trustA : 1;
var trustB = Number.isFinite(opts.trustB) ? opts.trustB : 1;
var trustMin = Number.isFinite(opts.trustMin) ? opts.trustMin : Math.min(trustA, trustB);
var cs = SharedEngine.coldStartInfo(..., trustMin, opts.tourLabel);

---