Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions FORENSIC_CASE_STUDY_923B.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Forensic Case Study: Build 923B (Ghost Entry Fix)

## 🕵️ The Bug: Spontaneous Cancellations & Hallucinated REAPER Repairs
During live testing, the system exhibited "Ghost" behavior where follower accounts would fire orders that the Master account did not authorize, or would fail to cancel orders that were terminated by the Master.

### 1. The Critical Failure: Identity Chain
The system suffered from a **Race Condition** in the `PropagateMasterEntryMove` and `PropagateMasterCancellation` logic.
- **Symptom:** The REAPER (Audit System) would detect a discrepancy between the broker state and the internal `expectedPositions`.
- **Root Cause:** If the Master order was cancelled *before* the Follower order was fully established in the internal dictionary, the cancellation would fail (Identity Chain break), leaving the Follower order active.
- **Ghost Repair:** The REAPER, seeing an active order in a Follower account that wasn't in its `expectedPositions` map, would attempt to "repair" it by either killing it incorrectly or, in some cases, re-issuing it if it thought a fill was missing.

### 2. The REAPER Race Condition
The REAPER audit was firing while orders were still in a "Pending" state on the broker side.
- **Hallucination:** Because the broker confirmation lags the internal state update, the REAPER would occasionally "hallucinate" that a follower fill was missing and fire a market order to "sync" the accounts, resulting in double fills or unmanaged positions.

## 🛡️ The Fix: Build 923B (Forensic Ghost Repair)

### Implementation 1: Create-before-Cancel
We hardened the `PropagateMasterEntryMove` logic. The system now ensures that any identity move or adjustment is fully registered in the fleet telemetry *before* any cancellation signal is sent. This prevents the "Orphaned Order" state.

### Implementation 2: CascadeFleetFollowerCleanup
A new surgical method, `CascadeFleetFollowerCleanup`, was added.
- **Action:** When a Master order is cancelled, the strategy now performs a recursive sweep of the entire fleet to kill any "hallucinated" or orphaned follower entries that might be lingering due to network latency.

### Implementation 3: Enhanced REAPER Grace
We implemented the `ReaperFillGraceTicks` (5-second window).
- **Hardening:** The REAPER is now strictly forbidden from performing any "Autosync" or "Repair" within 5 seconds of a fresh Master entry. This allows the broker's data-cycle to catch up and prevents the "Race to Market" that caused duplicate orders.

## 🏁 Observation & Results
- **Status:** FIXED.
- **Verification:** Log audits confirm that `expectedPositions` remains stable during high-volatility price moves, and the "Ghost" orders have been eliminated.
52 changes: 52 additions & 0 deletions INFRASTRUCTURE_PROTOCOL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# BMad Hardened Infrastructure Protocol

**Purpose:** To eliminate the "Old Code" failure mode by ensuring a single, verifiable source of truth between the development environment and NinjaTrader 8.

---

## 🛡️ 1. The "One Source of Truth" (HardLink)
All strategy files in the NinjaTrader directory MUST be **HardLinks** to the files in `C:\WSGTA\universal-or-strategy\src`.
* **Verification Command (Run by AI at start of session):**
`fsutil hardlink list "C:\Users\Mohammed Khalid\Documents\NinjaTrader 8\bin\Custom\Strategies\UniversalORStrategyV12_002_Dev.cs"`
* **Success Criteria:** The command MUST return both the NinjaTrader path and the `C:\WSGTA` path. If it only returns one path, the link is broken.

## 🛠️ 2. Deployment Protocol
If the link is broken or files need refreshing, run the deployment script:
* **Script:** `C:\WSGTA\universal-or-strategy\deploy-sync.ps1`
* **Policy:** Never manually copy/paste code into the NinjaTrader editor. Always edit in the Repo and let the HardLink propagate.

## 🏷️ 3. Version Traceability (Build Tags)
Every forensic or architectural change MUST be accompanied by an increment to the `BUILD_TAG` in `UniversalORStrategyV12_002_Dev.cs`.
* **Current Build:** `930`
* **Audit Step:** On strategy start, verify the NinjaTrader Output window shows:
`🛡 BMad HARDENED DEPLOYMENT PROTOCOL ACTIVE | Build: 930`

## 🔎 4. Zero-Trust Policy
Never assume the code on GitHub is the code running in NinjaTrader.
1. **Always** verify the local Build Tag.
2. **Always** verify HardLinks using `fsutil` at the start of every session.
3. **Mandatory Script:** Use `deploy-sync.ps1` to restore or establish links. Manual copy-pasting is a violation of the Security Shield.

## 🛠️ 5. Live Repair Protocol (Emergency)
If a bug is detected during active trading:
1. **Repair Location:** Edit files ONLY in `C:\WSGTA\universal-or-strategy\src`.
2. **Build Increment:** Immediately increment the `BUILD_TAG` (e.g., `923B` -> `923C`).
3. **Propagation:** Save the file; the HardLink will update NinjaTrader's file instantly.
4. **User Action:** Instruct the user: "HardLink updated. Please press F5 in NinjaTrader to compile."
5. **Audit:** Verify the NinjaTrader Output window shows the NEW Build Tag.
6. **Commit:** Commit the repair to the current branch immediately, but **Hold Merge** until the session reset.

## 🏁 6. Git & Pull Request Workflow
To maintain code integrity, all changes must be committed to a branch and merged via Pull Request using the GitHub CLI (`gh`).
1. **Branching:** Always work on a descriptive feature branch (e.g., `audit/full-codebase-review`).
2. **Commit Policy:** Every commit must reference the `BUILD_TAG`.
3. **PR Action:** When a build is verified, the AI must automatically prepare the PR:
* `git push origin [branch-name]`
* `gh pr create --title "Build [BUILD_TAG]: [Brief Description]" --body "Forensic Audit & Repairs for Build [BUILD_TAG]."`
4. **Merge Rule:** Do not merge into `main` during live trading. Merges should happen after the market close/reset.

## 🏁 7. Handoff Requirements
When closing a coding session, the AI must confirm:
1. **Sync Status:** "All files HardLinked and verified via fsutil."
2. **Build Tag:** "Current code signature is [BUILD_TAG]."
3. **Compile Status:** "User advised to press F5 in NinjaTrader."
12 changes: 10 additions & 2 deletions src/UniversalORStrategyV12_002_Dev.Entries.OR.cs
Original file line number Diff line number Diff line change
Expand Up @@ -220,7 +220,11 @@ private void EnterORPosition(MarketPosition direction, double entryPrice, double
{
// Build 1102Y-V3 [MS-03 ROLLBACK]: Submit failed — undo Order Ledger reservation.
AddExpectedPositionDeltaLocked(ExpKey(Account.Name), -masterDeltaOR);
Print("[ERROR][1102Y-V3] OR SubmitOrderUnmanaged returned NULL for " + entryName + " — Master expected rolled back.");
Print("[ERROR][1102Y-V3] OR SubmitOrderUnmanaged returned NULL for " + entryName + " — Master expected rolled back. Fleet dispatch aborted.");
// [FIX-OR-E]: Must abort here. Without an early return, ExecuteSmartDispatchEntry
// dispatches fleet followers for a master entry that does not exist → phantom fleet entries.
activePositions.TryRemove(entryName, out _);
return;
}

entryOrders[entryName] = entryOrder;
Expand All @@ -233,7 +237,11 @@ private void EnterORPosition(MarketPosition direction, double entryPrice, double
// V12 SIMA: Dispatch to fleet (replaces legacy slave broadcast)
if (EnableSIMA)
{
ExecuteSmartDispatchEntry("OR", direction == MarketPosition.Long ? OrderAction.Buy : OrderAction.SellShort, contracts, entryPrice, OrderType.Limit);
// [923A-P0-OR]: StopMarket prevents immediate "marketable limit" fill.
// OR Long entry price is ABOVE current market; a Limit order there is immediately
// marketable on Apex/Tradovate (fills at current ask). StopMarket activates only
// when price actually reaches/breaks the OR High/Low — matching master behavior.
ExecuteSmartDispatchEntry("OR", direction == MarketPosition.Long ? OrderAction.Buy : OrderAction.SellShort, contracts, entryPrice, OrderType.StopMarket);
}
}
catch (Exception ex)
Expand Down
22 changes: 15 additions & 7 deletions src/UniversalORStrategyV12_002_Dev.LogicAudit.cs
Original file line number Diff line number Diff line change
Expand Up @@ -67,14 +67,22 @@ private void ExecuteRiskLogicAudit()
Print("");

// Audit Case 3: Target Distribution (Priority Fill)
Print("[AUDIT] CASE 3: TARGET DISTRIBUTION (5-TARGET PRIORITY + RUNNER)");
int[] testQuantities = { 1, 3, 5, 10 };
foreach (int qty in testQuantities)
// [BUILD 926 FIX]: Test all 5 count scenarios explicitly.
// activeTargetCount is useless here — this audit fires at startup BEFORE the IPC
// app connects and pushes COUNT:n. Testing all counts makes this timing-independent.
Print("[AUDIT] CASE 3: TARGET DISTRIBUTION (ALL COUNT SCENARIOS)");
int[] auditCounts = { 1, 2, 3, 4, 5 };
int[] auditQtys = { 1, 2, 3, 5, 10 };
foreach (int count in auditCounts)
{
int t1, t2, t3, t4, t5;
GetTargetDistribution(qty, out t1, out t2, out t3, out t4, out t5);
Print(string.Format(" Total {0} Contracts \u2192 T1:{1} | T2:{2} | T3:{3} | T4:{4} | T5:{5} (T1/T5 Invariant Audit)",
qty, t1, t2, t3, t4, t5));
Print(string.Format(" --- Count={0} targets ---", count));
foreach (int qty in auditQtys)
{
int t1, t2, t3, t4, t5;
GetTargetDistribution(qty, out t1, out t2, out t3, out t4, out t5, count);
Print(string.Format(" {0} contr \u2192 T1:{1} T2:{2} T3:{3} T4:{4} T5:{5}",
qty, t1, t2, t3, t4, t5));
}
}

// Audit Case 3b: Universal Ladder ATR Spread
Expand Down
Loading