Signal

สัญชาตญาณหลักของ XCAP นั้นโหดร้ายและขัดกับความเข้าใจของผู้ที่มาจากสาย SaaS อย่างยิ่ง: ในระบบวิจัยการซื้อขาย เครือข่ายไม่ใช่ความสะดวก แต่คือพื้นผิวการโจมตี (attack surface) ที่ใหญ่ที่สุดที่คุณมี ทุก endpoint ที่ต้องใช้ key คือ credential ที่อาจรั่วไหลได้ ทุกการเรียกแบบ write คือ trade ที่อาจถูกสั่งโดย bug ด้วยเหตุนี้ XCAP จึงยุบการเปิดรับเครือข่ายทั้งหมดลงเหลือเพียงจุดเดียว: ingest edge แบบ read-only, keyless และ GET-only ส่วนที่เหลือของระบบเป็น deterministic จากดิสก์ หากคุณเข้าใจสิ่งนี้ คุณก็เข้าใจว่าทำไม `binance_public.py` จึงร้องขอแค่ klines (แท่งเทียน OHLCV ในอดีต) ผ่าน HTTP GET โดยไม่มี API key ไม่ลงนามอะไรเลย และไม่เคยแตะ endpoint ของบัญชีหรือคำสั่งซื้อขายเลย

ในเชิงรูปธรรม รูปแบบคือ: source ที่เป็นนามธรรม (ใน XCAP คือลำดับชั้น `OHLCSource`) ที่มีสอง implementation `LocalCSVSource` อ่านไฟล์ CSV ที่อยู่บนดิสก์อยู่แล้ว — ไม่มีเครือข่ายเลย เป็นกรณีโดยปริยาย และเป็นตัวที่ loop อัตโนมัติทุกตัวใช้ และ `HttpOHLCSource` (รองรับโดย `binance_public.py`) ซึ่งจะทำงานก็ต่อเมื่อ caller ส่ง `allow_network=True` อย่างชัดเจน หรือเรียกคำสั่ง `data-fetch` ความไม่สมมาตรนี้เป็นความตั้งใจ: เส้นทางที่ปลอดภัยคือค่าโดยปริยาย และเส้นทางที่มีเครือข่ายต้องระบุตัวเลือกอย่างชัดเจนในทุกครั้งที่เรียก ไม่ใช่ flag global ที่อยู่ในสภาพแวดล้อม ไม่ใช่ environment variable ที่ค้างเปิดทิ้งไว้

endpoint ของ Binance ที่คุณใช้คือ endpoint ตลาดสาธารณะ: `GET https://api.binance.com/api/v3/klines?symbol=BTCUSDT&interval=1d&limit=1000` ซึ่งคืนค่าเป็น array ซ้อน array: `[openTime, open, high, low, close, volume, closeTime, ...]` จงสังเกตสิ่งที่ไม่มีอยู่ตรงนี้: ไม่มี header `X-MBX-APIKEY` ไม่มี query param สำหรับลายเซ็น HMAC ไม่มี timestamp ที่ลงนาม endpoint นี้โดยกายภาพไม่สามารถอ่านยอดเงินคงเหลือหรือวางคำสั่งซื้อขายของคุณได้ เพราะ API บัญชีของ Binance อยู่อีกเส้นทางหนึ่งและต้องการลายเซ็น ความปลอดภัยไม่ใช่คำสัญญาของคุณว่าจะประพฤติดี แต่เป็นคุณสมบัติของ endpoint ที่คุณเลือกเอง

เสาหลักที่สองคือการ normalize ที่ขอบ (edge) ข้อมูลจากโลกจริงมาแบบสกปรก: timestamp เป็นมิลลิวินาที ตัวเลขมาเป็น string แท่งเทียนซ้ำกัน มีช่องว่าง edge ของคุณต้อง normalize ให้เป็นรูปแบบ canonical เดียวก่อนที่ downstream อะไรจะแตะมัน ใน XCAP ไฟล์ CSV ของ `data/real` เป็นตัวพิมพ์เล็ก (`open,high,low,close,volume`) timestamp ถูก parse เป็นวันที่ และ `LocalCSVSource` อ่านมันด้วยวิธีเดิมเสมอ วินัยนี้คือสิ่งที่ทำให้ระบบสามารถทำซ้ำได้: classifier ของ regime (SG-02) และ Market Memory (SG-03) อ่านรูปแบบที่เสถียรจากดิสก์ ไม่ใช่จาก HTTP response ที่ผันผวนและเปลี่ยนไปในแต่ละรอบการรัน

การตรวจสอบคือบทสรุป XCAP มีคำสั่ง `check` (รันด้วย `PYTHONPATH=src python3 -m xcap.control check`) ที่ยืนยันเป็น invariant ว่า connector เป็น keyless, read-only ไม่สามารถซื้อขายได้ และไม่สามารถเคลื่อนย้ายเงินได้ มันไม่ใช่ test ที่ผ่านครั้งเดียว แต่เป็นการ assert ที่รันทุกครั้งที่ `check` ดังนั้นหากมีใครเพิ่ม key หรือ method แบบ write เข้าไป `check` ก็จะกลายเป็นสีแดง นี่คือวิธีที่คุณเปลี่ยนเจตนาในการออกแบบให้กลายเป็นคุณสมบัติที่ระบบปกป้องตัวเอง กฎทอง: ความปลอดภัยที่ขึ้นอยู่กับว่าคุณจะจดจำบางอย่างได้ ไม่ใช่ความปลอดภัย แต่ความปลอดภัยที่ test สีแดงบังคับให้คุณเคารพ คือความปลอดภัยจริง

รายละเอียดเชิงปฏิบัติที่สำคัญ: dashboard ของ XCAP bind เฉพาะ `127.0.0.1` ไม่เคยเป็น `0.0.0.0` ingest edge คือพื้นผิวขาออกเพียงพื้นผิวเดียว ส่วนพื้นผิวขาเข้า (dashboard) ไม่ฟังบนเครือข่าย และ FileVault (AES-256) เข้ารหัสดิสก์ขณะพักนิ่ง ห่วงโซ่ทั้งหมด — ดิสก์ที่เข้ารหัส, ingest แบบ keyless read-only, dashboard ที่เป็น local-only, Capital Gate ที่ปิดอยู่ — คือสิ่งที่ทำให้สามารถมีระบบ trading-research บนแล็ปท็อปได้โดยไม่กลายเป็นระเบิดเวลา

ความผิดพลาดเชิงแนวคิดที่ XCAP แก้ไขในการ audit เดือนมิถุนายน 2026 นั้นละเอียดอ่อนและมีค่าดั่งทอง: การสับสนระหว่างสุขภาพเชิงปฏิบัติการ (operational health) กับ regime ของราคา `market_state.py` วัดสุขภาพของระบบ (ฉันมีข้อมูลใหม่หรือไม่? flag ตั้งถูกหรือเปล่า?) ส่วน `regime.py` วัดสิ่งที่แตกต่างโดยสิ้นเชิง: ตลาดเองอยู่ในสถานะใด? ทั้งสองเป็นแกนที่ตั้งฉากกัน (orthogonal) และการนำมาปนกันจะสร้าง classifier ที่ไม่รู้ว่าตัวเองกำลังบอกอะไร วินัยข้อแรกคือ: classifier ของ regime พูดถึงเฉพาะราคาเท่านั้น ไม่เคยพูดถึงสถานะของ infrastructure ของคุณ

การออกแบบของ XCAP จำแนกตามแกนอิสระสี่แกน Trend (ขึ้น ลง หรือออกข้าง? — ผ่านความชันของค่าเฉลี่ยหรือผลตอบแทนสะสมในหน้าต่างหนึ่ง) Volatility (สงบหรือปั่นป่วน? — ผ่าน standard deviation ของผลตอบแทน ที่ normalize แล้ว) Behavior (มีความต่อเนื่อง/เป็นแนวโน้ม หรือ mean-reverting? — ผ่าน autocorrelation ของผลตอบแทน) และ Stress (มี drawdown กำลังก่อตัวหรือไม่?) แต่ละแกนคำนวณอย่างบริสุทธิ์: input เดียวกัน output เดียวกัน ไม่มีสถานะซ่อนเร้น ไม่มีความสุ่ม จากนั้น cascade ของลำดับความสำคัญที่มี document ก็จะ derive `Regime` หลักเพียงตัวเดียวจากแกนทั้งสี่

insight ที่คมที่สุดของ XCAP อยู่ที่วิธีนิยาม Panic และนี่คือจุดที่เกือบทุกคนพลาด สิ่งล่อใจคือการนิยาม panic ว่าเป็น 'ความผันผวนสูง' (อัตราส่วน stdev สูง) ซึ่งไม่ถูกต้อง crash แบบโมโนโทน — ราคาที่ตกลงเกือบเป็นเส้นตรง — มีความผันผวน 'ภายใน' ต่ำ เพราะแต่ละแท่งเทียนคล้ายแท่งก่อนหน้า หากคุณนิยาม panic ด้วย stdev คุณจะพลาด crash ที่อันตรายที่สุดพอดี นิยามที่ถูกต้องของ XCAP คือ: panic คือ drawdown ขนาดใหญ่ที่กำลังก่อตัวอย่างรวดเร็ว วัดด้วยผลตอบแทนล่าสุดที่ติดลบรุนแรงและเฉียบคม ไม่ใช่ด้วยการกระจายตัว นี่คือสิ่งที่แยกแยะ classifier ที่คิดโดยคนที่เคยมองดู crash จริงออกจากคนที่ลอกสูตรมาจากตำรา

ความบริสุทธิ์ไม่ใช่ความเอาแต่ใจเชิงสุนทรียะ แต่เป็นรากฐานของความเชื่อมั่น `regime.py` เป็น pure function: `classify(bars) -> Regime` มันไม่อ่านจากดิสก์ภายในตัวเอง ไม่เรียกเครือข่าย ไม่กลายพันธุ์อะไรที่เป็น global ไม่มีสาขาที่สุ่ม นี่หมายความว่าคุณสามารถรันมันพันครั้งบนหน้าต่างเดียวกันแล้วได้ป้ายเดียวกัน คุณสามารถ test มันด้วย fixture ที่ deterministic และคุณสามารถ audit ได้อย่างแม่นยำว่าทำไมมันถึงบอกว่า 'Panic' ในวันที่หนึ่ง ๆ classifier ที่มีสถานะซ่อนเร้นคือ classifier ที่คุณไม่สามารถไว้ใจให้สร้าง Market Memory ทับลงไปได้

กฎที่สำคัญที่สุด และเป็นกฎที่เชื่อมโยงกับทั้ง constellation: classifier เป็นแบบ label-only มันไม่เคยกำหนดขนาดหรือซื้อขาย คืนค่าเป็นป้ายและไม่มีอะไรอื่น เหตุผลคือสถาปัตยกรรมแห่งความซื่อสัตย์: หาก module เดียวกันที่วินิจฉัย regime ยังเป็นตัวตัดสินขนาดของตำแหน่งด้วย คุณก็มีแรงจูงใจให้การวินิจฉัยมาสนับสนุนการซื้อขายที่คุณอยากทำอยู่แล้ว การแยกการวินิจฉัยออกจากการกระทำคือสิ่งที่ทำให้ใน SG-03 สามารถวัดได้อย่างซื่อสัตย์ว่า regime มีคุณค่าในการทำนายหรือไม่ — เพราะป้ายถูกสร้างขึ้นโดยไม่รู้ว่าคุณจะเอามันไปทำอะไร

เพื่อ implement ให้ดี จง document cascade ของลำดับความสำคัญเป็นโค้ดที่อ่านง่าย ไม่ใช่ if ที่พันกันยุ่งเหยิง เช่น: หาก Stress สั่ง Panic แล้ว Panic ชนะเหนือสิ่งอื่นใด หากไม่ และ Volatility สูงพร้อม Trend แรง ก็เป็น Trending-Volatile หาก Behavior เป็น mean-reverting และ Trend ออกข้าง ก็เป็น Range เป็นต้น แต่ละสาขาต้องมี comment ที่อธิบายเหตุผลเชิงตลาด ไม่ใช่แค่ค่า threshold comment นั้นคือสิ่งที่ผู้ตรวจสอบ — หรือตัวคุณเองในอีกหกเดือน — ต้องการเพื่อจะไว้ใจป้ายนั้น

การค้นพบหลักของการ audit ใน XCAP นั้นทำลายล้าง: ทุก module ก่อนหน้านี้เป็นได้แค่การคำนวณแบบ stateless หรือเป็นตัวสะสมแบบ passive ไม่มีอะไรเลยที่บันทึกคำทำนายที่พิสูจน์เท็จได้ก่อนผลลัพธ์ แล้วให้คะแนน calibration ของตัวเอง loop ที่ขาดหายไปนี้คือสิ่งที่ทำให้ระบบ research หลอกได้ยาก และเป็นแหล่งหลักฐานเดียวที่ซื่อสัตย์ของ edge Market Memory (`market_memory.py`) คือ loop นั้น หากคุณไม่สร้าง module นี้ ทุกอย่างที่เหลือก็เป็นเพียงละคร: การคำนวณที่สวยงามแต่ไม่เคยถูกเผชิญหน้ากับความเป็นจริง

หัวใจคือ `advance_market_memory(universe, state_dir, horizon_days=5, ...)` และลำดับของมันศักดิ์สิทธิ์ตามลำดับนี้: สังเกตวันที่ใหม่ → จำแนก regime (โดยใช้ `regime.py` ของ SG-02) → บันทึก forecast ที่ถูกล็อก (baseline ที่ derive จาก regime พร้อมความน่าจะเป็นและ horizon ของมัน) → แก้ไข forecast ที่ครบกำหนดแล้วเทียบกับผลตอบแทน forward ที่เกิดจริง → ให้คะแนน คำว่าล็อกคือคำสำคัญ: เมื่อคุณบันทึกแล้วว่า 'ในวันที่ T ฉันทำนาย prob_up=0.62 ที่ 5 วัน' บันทึกนั้นเปลี่ยนแปลงไม่ได้ คุณกลับไปแตะมันไม่ได้เมื่อเห็นผลลัพธ์ ความเปลี่ยนแปลงไม่ได้นี้คือสิ่งที่เปลี่ยน ledger ให้กลายเป็นหลักฐาน ไม่ใช่การหาเหตุผลย้อนหลัง

metric ไม่ได้มีแค่ตัวเดียว แต่เป็นแผงควบคุมที่ซื่อสัตย์ Hit-rate (คำทำนายเชิงทิศทางถูกกี่ส่วน?) Brier score (ความน่าจะเป็นถูก calibrate ดีแค่ไหน? — ลงโทษทั้งความมั่นใจเกินและความมั่นใจน้อยเกิน) calibration ตาม bucket ของความมั่นใจ (เมื่อคุณบอก 70% คุณถูก 70% ของเวลาหรือเปล่า?) และอัญมณี: hit-rate ตาม regime ตัวสุดท้ายนี้คือตัวที่ให้ข้อมูลจริง ๆ มันบอกคุณว่าคำทำนายของคุณมีคุณค่าในแนวโน้มแต่เป็นขยะในตลาด sideways หรือคุณถูกแค่ในตลาดสงบเท่านั้น hit-rate รวมที่ 55% อาจซ่อน 70% ในแนวโน้มและ 40% ใน panic — และการแยกย่อยนี้คือสิ่งที่บอกว่า edge อยู่ตรงไหน ถ้ามี

คุณสมบัติต้านการปลอมแปลงเป็นโดยโครงสร้าง (เราจะเจาะลึกใน SG-04 แต่ที่นี่มันเป็นเชิงโครงสร้างแล้ว): มีเพียง forecast ที่ horizon ครบกำหนดด้วยข้อมูลที่มีอยู่หลังวันที่ของ forecast เท่านั้นที่ถูกแก้ไข มันเป็น out-of-sample โดยการออกแบบ คุณไม่เคยสามารถ 'ทำนาย' วันที่ที่คุณรู้ผลลัพธ์อยู่แล้ว เพราะ forecast ถูกล็อกที่ T และแก้ไขก็ต่อเมื่อถึง T+horizon พร้อมข้อมูลจริง state dir ถูก gitignore — ประวัติศาสตร์ไม่ถูก version เพื่อไม่ให้มีสิ่งล่อใจในการแก้ไขด้วยมือและแต่งหน้าผลลัพธ์

คุณสมบัติความถูกต้องสามประการที่ XCAP บังคับใช้ และที่คุณต้องทำซ้ำ: สะสม (ledger เติบโตข้ามรอบการรัน ไม่เคย reset), idempotent (รัน tick สองครั้งบนวันที่เดียวกันไม่ทำให้ forecast ซ้ำหรือถูกแก้ไขสองครั้ง) และ Gate-closed (ไม่เคยซื้อขาย) นี่คือ invariant ตระกูลเดียวกับ capital invariant ของ SG-05: สถานะของระบบคือผลรวมของเหตุการณ์จริง ไม่ใช่การ replay หรือ baseline ใหม่ CLI `market-memory-tick` ทำหน้าที่ orchestrate สิ่งนี้และอ่านไฟล์ CSV รูปแบบ `data/real` (ตัวพิมพ์เล็ก) ผ่าน `LocalCSVSource` — ไม่มีเครือข่าย ทุกอย่าง deterministic จากดิสก์

จุดหนึ่งที่แยกวิศวกรออกจากมือสมัครเล่น: baseline ที่คุณบันทึกต้องซื่อสัตย์และถ่อมตน XCAP บันทึก 'regime_baseline' — ความน่าจะเป็นที่ derive จาก regime ไม่ใช่ model ที่ซับซ้อนซึ่งคุณ optimize ไปแล้วโดยมองอดีต ทำไมต้องเริ่มต้นอย่างถ่อมตน? เพราะ baseline คือไม้บรรทัดวัดของคุณ หาก forecaster ที่ซับซ้อนเอาชนะ regime baseline แบบ out-of-sample ไม่ได้ คุณก็ไม่มี edge คุณมี overfitting Market Memory มีอยู่เพื่อหักล้างความคิดของคุณ ไม่ใช่เพื่อยืนยันมัน และบันทึก forecast ที่ดีคือหลักฐาน ไม่เคยเป็นข้อพิสูจน์ — ด้วยเหตุนี้ Capital Gate จึงยังปิดอยู่ไม่ว่า hit-rate จะดูดีแค่ไหนก็ตาม

คำถามที่นิยาม module นี้คือ: คุณจะสร้างระบบที่ 'ไม่สามารถ' โกหกคุณเรื่อง edge ได้อย่างไร? คำตอบของ XCAP ไม่ใช่ 'จงระมัดระวัง' แต่คือการแนะนำคู่ต่อสู้เชิงโครงสร้าง — null controls — ที่ทุกการอ้าง edge ต้องแข่งขันด้วย Hypothesis Lab (`hypothesis_lab.py`) มี registry ของ forecaster จริง (regime_baseline, trend_follow, momentum_follow, mean_revert) และ null control โดยเจตนาสองตัว: `always_up` (null ของ DRIFT — ตลาดขึ้นโดยเฉลี่ย forecaster ของคุณแค่จับสิ่งนั้นหรือเปล่า?) และ `coin_flip` (null ของความสุ่ม — seeded และ deterministic คุณเอาชนะการโยนเหรียญได้ไหม?) forecaster ที่เอาชนะ null ทั้งสองไม่ได้ ไม่มี edge มันมีแค่ภาพลวงตา

เสาหลักที่สองคือนัยสำคัญพร้อมการแก้ไขสำหรับการเปรียบเทียบหลายครั้ง หากคุณทดสอบ forecaster ยี่สิบตัว บางตัวจะดูดีด้วยความสุ่มล้วน ๆ — นั่นคือปัญหา data-snooping XCAP จัดการมันด้วย threshold z ที่แก้ไขด้วย Bonferroni ซึ่ง scale ตาม K (จำนวน forecaster ที่ประเมิน): ยิ่งคุณทดสอบ hypothesis มากเท่าไร มาตรฐานที่แต่ละตัวต้องผ่านก็ยิ่งสูง `evaluate_forecasters(universe, names, horizon_days, min_samples, alpha)` เปรียบเทียบ forecaster จริงแต่ละตัวกับ null ทั้งสอง (Δความสุ่มและΔdrift) และมอบ `candidate_edge` ก็ต่อเมื่อมันเอาชนะความสุ่มและ drift และผ่าน threshold ที่แก้ไขแล้ว และมีอย่างน้อย `min_samples` observation เงื่อนไขทั้งสี่ต้องเป็นจริงพร้อมกัน การเอาออกข้อใดข้อหนึ่งเปิดประตูสู่การปลอมแปลง

รายละเอียดที่พิสูจน์ว่าระบบซื่อสัตย์และไม่ถูกจัดฉาก: `edge_demonstrated` เป็น False เสมอ lab สามารถมอบ `candidate_edge` — 'สิ่งนี้ควรค่าแก่การวิจัยเพิ่ม' — แต่ไม่เคยประกาศ edge ที่พิสูจน์แล้ว เพราะไม่มี backtest ใด ไม่ว่าจะดีแค่ไหน ที่พิสูจน์ edge ในอนาคตได้ นี่คือการตัดสินใจในการออกแบบที่ปกป้องคุณจากความมองโลกในแง่ดีของตัวเอง: ระบบไม่มีเส้นทางโค้ดใดที่บอกว่า 'ใช่ คุณมี edge จง trade' เลย Capital Gate ยังปิดอยู่โดยโครงสร้าง ไม่ใช่ด้วยวินัยของคุณ

การตรวจสอบว่า scoreboard ไม่ถูกจัดฉากนั้นสง่างามและคุณต้องทำซ้ำ: XCAP ตรวจสอบบนแนวโน้มสังเคราะห์ว่า `trend_follow` ชนะแบบขาดลอย (ตรวจจับสัญญาณจริง), `mean_revert` ติดลบอย่างมีนัยสำคัญ (ตรวจจับ anti-edge — การเดิมพันสวนแนวโน้มย่อมขาดทุน) และ `coin_flip` ลงเอยที่ราว 50% (ความสุ่มไม่ได้รับรางวัล) หาก coin_flip ของคุณออกมาที่ hit-rate 60% pipeline ของคุณพังหรือมี leakage null ไม่ใช่แค่คู่ต่อสู้: มันคือ probe สำหรับ calibrate ระบบการวัดของคุณเอง coin_flip ที่ไม่ให้ราว 50% คือระบบที่กำลังโกหกตัวเอง และคุณต้องหยุดทุกอย่างจนกว่าจะเข้าใจว่าทำไม

รากฐานที่ใช้ร่วมกันป้องกันกลโกงการย้ายเสาประตู: `scoring.py` คือแหล่งความจริงเดียวสำหรับ primitive (prob_up, is_hit, brier, conf_bucket, hit_rate_z) ทั้ง Market Memory (SG-03) และ Hypothesis Lab ให้คะแนนด้วยโค้ดเดียวกัน หากคุณมี implementation ของ 'hit' สองตัว คุณก็สามารถ — รู้ตัวหรือไม่ก็ตาม — ใช้ตัวที่ใจกว้างกว่าให้กับ forecaster ตัวโปรดของคุณ primitive ที่ใช้ร่วมกันเพียงตัวเดียวปิดประตูนั้น นี่คือการต้านการปลอมแปลงโดยโครงสร้าง: คุณเลือกกฎที่เข้าทางคุณไม่ได้เพราะมีกฎเพียงข้อเดียว

ทุกการประเมินเป็น out-of-sample โดยกลไกเดียวกับ SG-03: แท่งเทียนแต่ละแท่งถูกจำแนกครั้งเดียว forecast ถูกสร้างโดยไม่เห็นอนาคต และถูกแก้ไขเทียบกับผลตอบแทน forward จริง doc `docs/HYPOTHESIS_LAB.md` และ invariant 4 ตัวของ `check` เข้ารหัสหลักประกันเหล่านี้ บทเรียนเชิงลึก ซึ่งเป็นทีสิสของทั้ง constellation Signal: ข้อจำกัดที่กำหนด (binding constraint) สำหรับการใช้ทุนจริงคือ edge ที่ 'พิสูจน์แล้ว' และเครื่องมือเหล่านี้วัด edge อย่างซื่อสัตย์ (null controls + นัยสำคัญ) แทนที่จะอ้างมัน ระบบที่สามารถออกได้แค่ `candidate_edge` และไม่เคย `edge_demonstrated` คือระบบที่เคารพในสิ่งที่ตัวเองไม่รู้

module นี้ถือกำเนิดจากความผิดพลาดจริงและเจ็บปวดใน XCAP และนั่นคือเหตุผลที่มันสอนได้ดีนัก autorun ที่ตั้งเวลาไว้กำลัง reset ledger กลับไปที่ยอดเริ่มต้น 500 อย่างเงียบ ๆ และเล่นซ้ำ fixture เดิมที่เหมือนกันทุก 5 นาที ระบบแสดงกิจกรรม ตัวเลขเปลี่ยนแปลง ดูเหมือนมีชีวิต — แต่เป็นเท็จโดยสิ้นเชิง กฎสามข้อถูกละเมิดพร้อมกัน และเป็นสามข้อที่นิยาม capital invariant จงจำกฎเหล่านี้เพราะมันคือแก่นแกน: สะสม, เฉพาะที่เกิดขึ้นจริง (realized-only) และการเข้าใหม่ (re-entry) สานต่อเซสชันก่อนหน้า

กฎข้อ 1 — สะสม ทุนไม่ reset ระหว่างรอบการรันหรือเซสชัน หากคุณจบเซสชันเมื่อวานที่ 547.30 วันนี้คุณเริ่มที่ 547.30 baseline ใหม่ทุกการเริ่มต้นไม่ใช่การบัญชี แต่คือ demo ในคราบปลอมตัว ledger ถูกโหลดจากดิสก์เมื่อเริ่ม และถูก persist เมื่อจบ สถานะดำรงอยู่ระหว่างการ execute

กฎข้อ 2 — เฉพาะที่เกิดขึ้นจริง (realized-only) ยอดคงเหลือเคลื่อนที่ก็ต่อเมื่อสถานะถูกปิด/ขายเท่านั้น P&L ที่ยังไม่เกิดขึ้นจริง (mark-to-market มูลค่าลอยตัวของสถานะที่เปิดอยู่) ไม่เคยทำให้ยอดคงเหลือพอง invariant ที่แม่นยำ ซึ่งคุณต้องสามารถยืนยันได้ทุกเมื่อ: `current_balance == starting_balance + realized_pnl` สถานะที่เปิดอยู่พร้อมกำไรลอยตัว +200 ไม่เปลี่ยนยอดคงเหลือ มันเปลี่ยนก็ต่อเมื่อคุณปิดมันและ +200 นั้นกลายเป็น realized สิ่งนี้ป้องกันกับดักทางจิตวิทยาที่เก่าแก่ที่สุดในการซื้อขาย: การนับกำไรก่อนเก็บเข้ากระเป๋า

กฎข้อ 3 — การเข้าใหม่สานต่อ เมื่อ restart ทุนคือผลลัพธ์สะสมของการซื้อขายในเซสชันก่อนหน้า ไม่ใช่เส้นฐานใหม่ ระบบต้องสามารถปิดและเปิดได้พันครั้งและทุนยังคงเป็นผลรวมที่ซื่อสัตย์ของการปิดสถานะจริงทั้งหมดที่เกิดขึ้น นี่คือสิ่งเดียวกับคุณสมบัติการสะสมของ Market Memory (SG-03): สถานะคือผลรวมของเหตุการณ์จริง ไปในทิศทางเดียว ไม่มีการ replay

บทเรียนเชิงสถาปัตยกรรมคือความแตกต่างระหว่างสองคำสั่งที่ XCAP จงใจแยกออกจากกัน autorun ที่ตั้งเวลาไว้รัน `sim-autopilot-tick`: โหลด ledger ที่มีอยู่ หมุน regime สังเคราะห์ และสะสมทับสิ่งก่อนหน้า ยังมี `sim-run-agent` ด้วย ซึ่ง reset และเล่นซ้ำ fixture — แต่ตัวนั้นเก็บไว้เฉพาะสำหรับ demo แบบ deterministic เท่านั้น และไม่เคยควรเป็นสิ่งที่ autorun รัน bug คือการชี้ scheduler ไปยังคำสั่งที่ผิดพอดี บทเรียน: คำสั่งที่ reset กับคำสั่งที่สะสมไม่ควรสับสนกันได้เลย จงตั้งชื่อให้ตัวที่อันตรายตะโกนบอกสิ่งที่มันทำ

วิธีหุ้มเกราะสิ่งนี้ไม่ให้พังอีก: invariant ถูก LOCKED โดย `tests/test_sim_autopilot_tick.py` หากคุณแตะ ledger หรือ autorun test เหล่านั้นต้องยังเขียวอยู่ มันไม่ใช่ document แต่คือกุญแจที่ execute ได้ กฎเชิงปฏิบัติที่ผู้ใช้กำหนดอย่างหนักแน่น: หากคุณแตะการบัญชี คุณต้องรัน test นั้น และหากมันกลายเป็นสีแดง คุณได้ทำลายความถูกต้องของทุน และคุณต้องหยุด นี่คือปรัชญาเดียวกับ Capital Gate และ `check` ของ SG-01: invariant ที่สำคัญจริง ๆ ถูกเข้ารหัสเป็น test ที่ปฏิเสธจะให้คุณทำลายมัน การบัญชีของ XCAP ไม่ได้น่าเชื่อถือเพราะผู้เขียนระมัดระวัง แต่น่าเชื่อถือเพราะ test สีแดงห้ามไม่ให้เขาประมาท

autopilot tick คือโค้ดที่รันโดยไม่มีมนุษย์เฝ้าดู และนั่นคือเหตุผลพอดีที่มันต้องเป็นโค้ดที่มีวินัยมากที่สุดในระบบ ความผิดพลาดที่ XCAP ประสบกับตัวเองสอนทุกอย่าง: tick ที่ตั้งเวลาไว้ซึ่งทุก 5 นาทีจะ reset ledger และเล่นซ้ำ fixture ที่เหมือนกัน มองจากภายนอกระบบดูเหมือนมีชีวิต — ตัวเลขเคลื่อนไหว กิจกรรมต่อเนื่อง แต่ภายในมันคือคำโกหกใน loop คำถามที่นิยาม tick ที่ดี: loop นี้ เมื่อรันพันครั้ง 'สะสม' อะไรที่แท้จริง หรือแค่สร้างภาพลักษณ์ของกิจกรรม?

คุณสมบัติ 1 — deterministic จากดิสก์ tick อ่าน input ของมันจากดิสก์ (CSV `data/real` ผ่าน `LocalCSVSource`) ไม่ใช่จากเครือข่าย loop อัตโนมัติของ XCAP ไม่เคยเปิดเครือข่าย — `allow_network` คงเป็น False เสมอ นี่คือความต่อเนื่องโดยตรงจาก SG-01: เครือข่ายเป็น opt-in อย่างชัดเจนต่อการเรียกของมนุษย์ (คำสั่ง `data-fetch`) ไม่เคยเป็นสิ่งที่ loop อัตโนมัติเปิดเอง tick ที่แตะเครือข่ายโดยไม่มีการดูแลคือ tick ที่สามารถรั่ว, fail แบบไม่สามารถทำซ้ำได้ หรือค้างรอ socket ได้ deterministic จากดิสก์หมายความว่าสถานะเดียวกันบนดิสก์ให้ผลลัพธ์เดียวกัน กล้าหาญและทำซ้ำได้

คุณสมบัติ 2 — idempotent การรัน tick สองครั้งบนวันที่เดียวกันต้องไม่ทำให้ forecast ซ้ำ ไม่แก้ไขสิ่งที่แก้ไขแล้วซ้ำ และไม่นับการปิดสถานะสองครั้ง สิ่งนี้สำคัญมากใน loop เพราะ scheduler fail, retry, ทับซ้อน หาก tick ของคุณไม่ idempotent การ retry จะทำให้สถานะเสียหายอย่างเงียบ ๆ วิธีทำให้สำเร็จ: ทุกเหตุการณ์ (forecast หนึ่งตัว, การปิดสถานะหนึ่งครั้ง) มี key ธรรมชาติ (วันที่+สัญลักษณ์) และ tick ตรวจสอบการมีอยู่ก่อนเขียน `advance_market_memory` และ `sim-autopilot-tick` เป็น idempotent ด้วยเหตุผลนี้

คุณสมบัติ 3 — สะสม ไม่ reset tick โหลดสถานะก่อนหน้าและสร้าง 'ทับ' มัน `sim-autopilot-tick` โหลด ledger หมุน regime สังเคราะห์ และสะสม — เป็นกฎเดียวกันกับ capital invariant ของ SG-05 และ Market Memory ของ SG-03 พอดี นี่คือ invariant เดียวกันที่ปรากฏเป็นครั้งที่สามใน constellation และไม่ใช่เรื่องบังเอิญ: ความซื่อสัตย์ของระบบอัตโนมัติ 'คือ' การปฏิเสธที่จะ reset ตัวเอง loop ที่เริ่มจากศูนย์ทุกครั้งไม่เรียนรู้อะไร loop ที่สะสมคือสิ่งเดียวที่สามารถสร้างประวัติ calibration ที่มีค่าได้

คุณสมบัติ 4 — Gate-ปิดโดยโครงสร้าง tick ไม่เคยซื้อขายทุนจริง Capital Gate (`capital/broker/live_trading/automation` เป็น False ทั้งหมด) ถูกตรวจสอบโดย `python3 -m xcap.control check` autopilot คือจุดที่ระบบ trading ฆ่าเจ้าของมันพอดี: มันรันเอง และหากมันมีความสามารถซื้อขายจริง bug ตอนตีสามก็ทำให้บัญชีหมดเกลี้ยง ด้วยเหตุนี้ใน XCAP autopilot จึงเป็น sim-only โดยไม่มีข้อยกเว้น และ `check` ยืนยันมันในทุกการรัน ระบบอัตโนมัติและความสามารถซื้อขายจริงคือสองสิ่งที่ไม่เคยควรอยู่ร่วมกันได้โดยปราศจากการตัดสินใจของมนุษย์ที่จงใจอย่างที่สุด

วิธีดำเนินการและหุ้มเกราะทั้งหมดนี้: tick รันผ่าน scheduler (ใน XCAP คือ task ที่ตั้งเวลาไว้ซึ่งเรียก `sim-autopilot-tick` คำสั่งที่สะสม — ไม่เคย `sim-run-agent` ตัวที่ reset สำหรับ demo) พฤติกรรมถูก LOCKED โดย `tests/test_sim_autopilot_tick.py`: หากคุณแตะ autorun test เหล่านั้นยังเขียวอยู่ มิฉะนั้นคุณได้ทำลายความถูกต้องของ loop และทุกการรันจบด้วย `check` ที่ยืนยัน invariant อีกครั้ง (keyless, Gate-ปิด, การสะสม) หลักการสุดท้ายที่ผนึก constellation ทั้งหมด: loop ที่ซื่อสัตย์คือ loop ที่หลักประกันไม่ขึ้นอยู่กับว่ามีใครเฝ้าดู เพราะมันถูกเข้ารหัสเป็น test และ invariant ที่ loop เองตรวจสอบในทุกรอบ จงสร้าง loop ที่ปฏิเสธจะโกหกแม้ในยามที่ไม่มีใครมองดู — นั่นคือระบบอัตโนมัติเดียวที่ระบบ research ไว้ใจได้