Ba level này có lệnh thực sự được mở trong cycle target.
ALAMO v2 / Hotfix4 / Snapshot Anchor
Case DD 41.14%: lệnh nào FIRE thật, lệnh nào chỉ chạm gate
Đây là public report cho build FBot_v4.1_Alamo_Jun2026_(v2-LenhY-Hotfix4-SnapshotAnchor).
Nội dung dưới đây chỉ bám theo những gì đã implement trong code hiện tại và những gì log ngày
20260523.log xác nhận ở cycle ngày 2026.02.23.
L4 nhiều lần chạm fire gate 40%, nhưng bị skip ngay vì thiếu free margin.
Snapshot và anti-volatility fallback đều resolve đúng ticket để monitoring/close.
Khi đóng full loop, prev-cache và SC cache đều được dọn sạch.
Những gì đã implement / fix / thay đổi
Tóm tắt này lấy từ header của advisor Hotfix4 và diff hiện tại trong Include/FBot/.
- L1 vẫn giữ logic legacy: lot của L1 bằng tổng tất cả losing lots của dominant-side main grid, không đổi sang kiểu tính mới.
- L2 vẫn giữ rule cũ: muốn monitor/fire tiếp thì
prevLnphải còn mở. Rule mới chỉ nới từ L3 trở đi. - Từ L3 trở đi, chỉ cần
Ln-1đã FIRE là đủ để vào monitoring; active hay đã close không còn là điều kiện bắt buộc. - Snapshot của L2+ không còn rebuild theo chính Ln mới mở. Nó bám theo fire-decision anchor của prevLn để tránh lệch subset và rơi về
count=0. - Tracking ticket -> real Ln được giữ riêng bằng
g_alamoTicketLevels[], nên khi một level đóng trước level khác thì mapping Ln vẫn không bị trôi. - Dữ liệu
lệnh_yvày-1nay giữ thêm volume và raw lot-sequence index, giúp close logic biết đúng ticket lớn nhất và ticket dự phòng. - Khi full loop close, cycle reset không chỉ về STANDBY mà còn clear prev-cache và để Skill 6 flush SC cache/memory ngay sau đó.
Case ALAMO FIRE trong cycle 41.14%
Câu hỏi chính là: trong đúng case này, những lệnh ALAMO FIRE nào thực sự tồn tại? Câu trả lời ngắn gọn là: L1, L2, L3 là FIRE thật; L4 chỉ chạm gate nhưng không mở được lệnh.
L1 FIRE thật
L1 mở BUY 8.29 lot và kích hoạt S1 cho L2. Đây là điểm bắt đầu cycle target.
log: 78373-78375L2 FIRE thật
L2 snapshot bắt được 5 lệnh phù hợp, lệnh_y=1806, y-1=1805, rồi L2 FIRE ở DD 20.45%.
L2 giao close cho PosMan
Vì snapshotCount của L2 là 5, close được defer sang PositionManager thay vì đóng ngay từng lệnh.
log: 79218 và lặp lại đến 84777L3 FIRE thật
L3 snapshot bắt được 2 lệnh sau prevLn, resolve lệnh_y=1810, y-1=1809, và FIRE ở DD 30.40%.
L3 anti-volatility fallback chạy đúng
Vì giá của Ln nằm sai phía của lệnh_y, hệ thống fallback sang y-1=1809. Sau đó L3 đóng thành công khi 1809 flip profit dương.
L4 chạm gate nhưng không FIRE thật
DD lên 41.14%, fireGate 40% đã đạt, nhưng required margin lớn hơn free margin nên lệnh L4 bị skip ngay.
log: 83328-83329Full loop close + reset
Hệ thống chạy CloseAll, reset về STANDBY, rồi flush SC cache và clear SC memory.
Data monitoring trong case này có hoạt động bình thường không?
Có. Trong case này, dữ liệu monitoring cho Y và Y-1 vẫn hoạt động bình thường. Quan trọng là phải tách
rule runtime mới với những gì cycle này thực sự đã đi qua.
lệnh_y=1806, y-1=1805
L2 snapshot dùng fire_decision_anchor của L1 và pool after_prev_ln, không bị collapse về empty subset.
lệnh_y=1810, y-1=1809
L3 vẫn resolve được cặp theo đúng window sau prevLn. Đây là bằng chứng rằng snapshot anchor mới đang giữ dữ liệu đúng.
1809 hoạt động
L3 không bám cứng ticket lớn nhất. Khi lệnh_y ở wrong side, logic fallback sang y-1 và tiếp tục monitoring được.
1809 flip profit
Dòng close thực tế của L3 ghi rõ lệnh_y=1809 flipped profit > 0, nên đường dữ liệu từ snapshot tới close vẫn thông.
Lưu ý: rule mới "L3+ chỉ cần Ln-1 đã fired là monitor được" là một thay đổi ở code-path tổng quát.
Trong cycle target này, L2 vẫn đang bị defer cho PosMan nên không tạo ra tình huống "prevLn đã đóng trước khi L3 monitor".
Tuy vậy, dữ liệu Y / Y-1 trong case này vẫn xác nhận là không bị hỏng sau khi đổi sang snapshot-anchor mới.
Bảng line-number chứng cứ để đối chiếu log
Phần này dành riêng để chứng minh với Silverf Smurfer. Mỗi dòng dưới đây chỉ ra rõ:
level nào thật sự mở lệnh, level nào chỉ đạt gate nhưng không mở được, và level nào đóng riêng hay bị giao về full-loop close.
Tất cả line-number đều lấy từ 20260523.log trong cycle 2026.02.23 01:06:28 -> 02:00:54.
| Ln | Trạng thái | Log lines | Raw proof | Kết luận |
|---|---|---|---|---|
| L1 | FIRED thật | 78373-7837584992-84998 |
78373 `ALAMO: FIRED ALAMO_L1 | BUY 8.29 @ 5122.92 | ticket=1801`
78374 `ALAMO L1 FIRE | accountDD=10.28% | thr=10.00%`
84992-84998 close ticket #1801 rồi `ALAMO: CloseAll | closed=2` và `reset to STANDBY`
|
L1 có lệnh mở thật ở ticket Trong target cycle này L1 không có dòng close riêng; nó sống tới cuối loop và bị đóng trong batch |
| L2 | FIRED thật | 79207-7921884726-8477784987-84998 |
79207 `S1 của L2 FIRE | DD=20.01% >= fireGate=20.00%`
79213-79216 snapshot lệnh_y=1806, y-1=1805, rồi `FIRED ALAMO_L2 | ticket=1807`
79218 `ALAMO_DEFER_POSMAN_CLOSE L2 ... PosMan owns close`
84987-84998 close ticket #1807 trong full-loop batch rồi reset
|
L2 không chỉ chạm gate; nó mở lệnh thật ở ticket Nhưng L2 cũng không tự close theo nhánh riêng, vì snapshot có 5 lệnh nên close path bị giao cho PosMan và kết thúc bằng full-loop close. |
| L3 | FIRED + close riêng | 79986-7999984769-84775 |
79986 `S1 của L3 FIRE | DD=30.01% >= fireGate=30.00%`
79992-79995 snapshot lệnh_y=1810, y-1=1809, rồi `FIRED ALAMO_L3 | ticket=1812`
79999 `wrong side of lệnh_y ... fallback to y-1 (1809)`
84769 fallback cuối cùng sang 1809, 84775 `ALAMO_v2_CLOSE L3 | ticket=1812 | lệnh_y=1809 flipped profit > 0`
|
L3 là level chứng minh rõ nhất rằng data monitoring của Nó FIRE thật, sau đó anti-volatility không bám cứng |
| L4 | Gate đạt, không mở lệnh | 83328-83329 |
83328 `S1 của L4 FIRE | DD=41.14% >= fireGate=40.00% | qualCount=3`
83329 `ALAMO: FIRE SKIP — margin 74765.89 > free 4770.97`
|
Đây là chỗ dễ hiểu nhầm nhất: L4 có fire condition thật, nhưng không có order opened. Nói đúng theo log là: gate hit yes, order send no, vì fail margin check. |
| Loop reset | Full close + cache clear | 84997-85004 |
84997 `ALAMO: CloseAll | closed=2 failed=0`
84998 `ALAMO: CloseAll — reset to STANDBY`
84999-85002 `Flushing SC cache`, `reset completed`, `cache flushed`
85004 `SC memory cleared (g_scClosed[] reset)`
|
Phần đóng full loop không chỉ đóng lệnh còn lại, mà còn reset state và dọn cache đúng như yêu cầu hotfix. Đây là bằng chứng rằng cycle kết thúc sạch, không để lại prev-cache hay SC memory cũ. |
Vì sao DD vẫn lên 41.14%?
DD không dừng ở L3 vì L4 không mở được. Nói thẳng: đây là giới hạn margin, không phải lỗi snapshot hay lỗi Y/Y-1.
Các dòng L4 FIRE bắt đầu từ vùng 40.88% và đi qua đúng mốc 41.14%.
74765.89 > 4770.97
Ở mốc 41.14%, required margin lớn hơn free margin rất xa, nên AlamoFire skip trước khi có order mới.
Vì thế case này phải được đọc là L1, L2, L3 real FIRE và L4 skipped by margin.
Evidence map
Hotfix4 header ghi rõ: L2 giữ rule cũ, L3+ monitor khi Ln-1 đã fired, snapshot bám fire-decision anchor, full-loop close clear prev cache.
78373-78375: L1 mở thật và kích hoạt monitoring cho L2.
79213-79216 và 79992-79995: có đủ count, lệnh_y, y-1, và snapshot basis.
79999 và 84775: fallback sang 1809 rồi L3 close thành công bằng ticket đó.
83328-83329: DD đạt 41.14%, nhưng margin required lớn hơn free margin nên không có L4 order.
84997-85004: CloseAll, reset STANDBY, flush cache, và clear SC memory đều xuất hiện đúng thứ tự.
Core files behind this version
Experts/Advisors/FBot_v4.1_Alamo_Jun2026_(v2-LenhY-Hotfix4-SnapshotAnchor).mq5
Header của build này là public summary tốt nhất cho phạm vi thay đổi đang được deploy.
Include/FBot/FBotAlamo.mqh
Chứa rule L2 vs L3+, snapshot anchor mới, mapping ticket-level, close behavior, và full-loop cache clear.
Include/FBot/FBotGlobals.mqh
Chứa g_alamoTicketLevels[], fields mới cho lệnh_y / y-1, và schema snapshot mở rộng.