The Automation Layer: Building the Operational Backbone of RAIDER
Development Log · 2026-07-06
1. Title
"The Automation Layer: Building the Operational Backbone of RAIDER"
2. Date / Phase
Date: July 6, 2026 Phase: RAIDER Operational Maturity — Automation Infrastructure
3. Background
RAIDER ในฐานะ Execution Layer ของ KOOeda6 มีกระบวนการ monthly backtest update ที่ซับซ้อน ประกอบด้วย 7 ขั้นตอนหลัก ครอบคลุมการเตรียมไฟล์ การรัน backtest ผ่าน MT5 Strategy Tester การวิเคราะห์ผ่าน Excel Macro และการคัดเลือก candidates สำหรับ Alpha/Beta/Gamma deployment
ก่อนบทสนทนานี้ กระบวนการทั้งหมดดำเนินการด้วย manual steps เกือบทั้งสิ้น ทำให้เกิดความเสี่ยงจากความผิดพลาดของมนุษย์ ใช้เวลานาน และไม่สามารถ reproduce ได้อย่างสม่ำเสมอ คำถามเริ่มต้นคือ — ขั้นตอนใดที่สามารถ automate ได้โดยไม่ต้องเข้าถึง MT5 โดยตรง?
4. Key Insights
4.1 Boundary of Automation ข้อจำกัดที่ชัดเจนที่สุดของบทสนทนานี้คือการยอมรับว่า MT5 และ AHK ไม่สามารถถูกสั่งจากภายนอกได้โดยตรง ณ เวลาที่สร้างระบบ ดังนั้น automation จึงถูกออกแบบให้ทำงาน รอบๆ manual steps ไม่ใช่แทนที่ทั้งหมด แนวคิดนี้นำไปสู่รูปแบบ Guided Wizard ที่ script ทำหน้าที่เป็น conductor — สั่งงาน auto เมื่อทำได้ และ pause รอมนุษย์เมื่อจำเป็น
4.2 Wizard-First Design Mode S (Sequential Guided Wizard) เป็น insight ที่สำคัญที่สุดของบทสนทนานี้ แทนที่จะให้ผู้ใช้จำลำดับขั้นตอนเอง script กลายเป็น ผู้นำทาง ที่รู้ว่าขั้นตอนถัดไปคืออะไร บอก instruction ที่ชัดเจน และรับ confirmation ก่อนดำเนินการต่อ
4.3 Config Injection as Automation การที่
0_RAIDER_UpdateMaster.py สามารถ patch
1_gen_ini_from_CAND_forUpdate.py โดยตรงผ่าน
re.sub + re.MULTILINE แสดงให้เห็นว่า automation
ไม่จำเป็นต้องควบคุม process โดยตรง — การควบคุม configuration ของ
script อื่นก็เป็น automation รูปแบบหนึ่งที่ทรงพลัง
4.4 Observability During Execution ความต้องการ
always-on-top progress overlay ระหว่าง AHK run สะท้อนหลักการสำคัญ —
ระบบที่ดีต้องให้ operator เห็น ว่ากำลังเกิดอะไรขึ้นอยู่เสมอ
แม้จะควบคุมไม่ได้โดยตรง การนับ .ini/.xlsx pair
แทนการนับ .xlsx อย่างเดียว เป็นตัวอย่างของ precision
monitoring
4.5 Coordinate-Based Fragility ปัญหา AHK taskbar x/y เลื่อนเมื่อ PS เปิดอยู่เผยให้เห็นความเปราะบางของ automation ที่พึ่งพา pixel coordinates — แนวคิดที่ถูกต้องกว่าคือ detect by identity (window title, process name, account number) ไม่ใช่ detect by position
5. Decisions
| การตัดสินใจ | รายละเอียด |
|---|---|
สร้าง 0_RAIDER_UpdateMaster.py เป็น master
orchestrator |
รวม step 0+1, 2, 5+6, 7 ไว้ในไฟล์เดียว |
| เพิ่ม version v7 เข้าสู่ระบบ | VALID_VERSIONS = ("2", "4", "5", "7") |
| ใช้ภาษาอังกฤษทั้งหมดใน script | แก้ปัญหา encoding เพี้ยนบน Windows terminal |
| Mode S เป็น default ที่แนะนำ | Guided wizard แทน manual step selection |
| Auto-patch config ของ 1_gen_ini | ไม่ต้อง pause ให้ผู้ใช้แก้เอง |
| Tkinter overlay แทน PS window | always-on-top ไม่ถูก AHK บัง |
| นับ ini/xlsx pair แทนนับ xlsx | แก้ bug นับขึ้นทีละ 2 |
| Auto SaveAs + Close xlsm หลัง macro | ลด manual steps ใน batch loop |
| Auto rename CSV และ xlsm | pattern ชัดเจนทุก batch |
| Auto archive ini+xlsx ไป SUMMARY_RESULTS | เคลียร์ INI_OUT_DIR พร้อม batch ถัดไป |
6. Architecture Changes
RAIDER Operational Layer — Before / After
Before: Manual 7-step process ที่ผู้ใช้ต้องจำและทำเองทุกขั้นตอน
After: Hybrid automation ที่แบ่งชัดเจนระหว่าง:
AUTO : file prep, config injection, batch split,
progress monitoring, script execution,
CSV rename, xlsm SaveAs/Close/rename, archiving
MANUAL: MT5 ini load, AHK run, xlsm macro triggerNew Files Added to RAIDER Infrastructure
02_tools_updateBacktest/
├── 0_RAIDER_UpdateMaster.py ← Master orchestrator (NEW)
├── watch_batch_progress.py ← Always-on-top Tkinter overlay (NEW)
├── 2_BackTestCand__forUpdate_fixed.ahk ← WinActivate-based AHK (NEW, optional)
└── [existing scripts unchanged]7. Philosophy
บทสนทนานี้แสดงให้เห็นหลักการที่สำคัญประการหนึ่งของ KOOeda6 —
"Automate the boundary, not just the center."
ระบบส่วนใหญ่พยายาม automate สิ่งที่อยู่ตรงกลาง กระบวนการหลักที่ชัดเจน แต่ RAIDER Automation Layer นี้เลือก automate ขอบเขต รอบๆ manual core แทน การเตรียมข้อมูลก่อน การจัดการผลลัพธ์หลัง และการสังเกตระหว่าง ทำให้ manual core ที่เหลืออยู่มีขนาดเล็กลง มีบริบทชัดเจนขึ้น และเกิดความผิดพลาดได้น้อยลง
นอกจากนี้ Guided Wizard สะท้อนแนวคิดว่า ระบบที่ดีไม่ได้แค่ทำงานแทนมนุษย์ แต่ทำให้มนุษย์ทำงานได้ดีขึ้น
8. Future Work
- AHK modernization — พิจารณาเปลี่ยน
2_BackTestCand__forUpdate.ahkทั้งหมดให้ใช้ window detection แทน coordinate-based clicking - pywin32 integration — ทดสอบ SaveAs xlsm ผ่าน COM automation บน machine จริง
- Batch 2-4 copy automation — ปัจจุบันยังต้อง copy .ini จาก Batch folder ไป root ด้วยตนเอง อาจ automate ได้ใน future iteration
- MT5 access layer — เมื่อ AI สามารถ access MT5 ได้โดยตรง กระบวนการทั้งหมดอาจ automate ได้ 100%
- Cross-version parallel run — พิจารณา architecture สำหรับรัน v2/v5/v7 พร้อมกัน
9. Impact
บทสนทนานี้เปลี่ยน RAIDER จาก ระบบที่มีกลยุทธ์ดี แต่ operate ได้ยาก ไปสู่ ระบบที่มีกลยุทธ์ดี และมี operational infrastructure รองรับ ความสำคัญอยู่ที่การลด cognitive load ของ operator ในวันที่ต้อง update ซึ่งอาจใช้เวลาหลายชั่วโมง จากการที่ต้องจำและทำทุกอย่างเอง กลายเป็นการ follow wizard ที่บอกทุกขั้นตอน
ในบริบทของ KOOeda6 นี่คือก้าวสำคัญของ RAIDER สู่ความเป็น production-grade system ที่สามารถ operate ได้อย่างสม่ำเสมอในระยะยาว
10. Final Architecture
0_RAIDER_UpdateMaster.py (Master Orchestrator)
│
├── [MODE S — Guided Wizard]
│ │
│ ├── STEP 0+1 ─── AUTO: clear INI_OUT_DIR
│ │ AUTO: create SUMMARY_RESULTS/YYYYMMDD_vX_updated/
│ │ AUTO: find + copy + rename candidates CSV
│ │
│ ├── AUTO ──────── patch 1_gen_ini config (re.sub + MULTILINE)
│ │ subprocess.run 1_gen_ini → generate ~500 .ini
│ │
│ ├── STEP 2 ───── AUTO: split .ini → Batch_1_vX ... Batch_N_vX
│ │
│ └── BATCH LOOP (per batch)
│ │
│ ├── AUTO ──── launch watch_batch_progress.py (Tkinter overlay)
│ │ always-on-top, count ini/xlsx pairs, show ETA
│ │
│ ├── MANUAL ── copy ini to INI_OUT_DIR root
│ │ MT5: load first .ini, run once
│ │ AHK: 2_BackTestCand#_forUpdate.ahk
│ │ xlsm: RunAnalysisCandidates → Done? (y)
│ │
│ ├── AUTO ──── close monitor overlay
│ │ SaveAs xlsm → _done.xlsm
│ │ Close _done.xlsm
│ │ subprocess.run 4_update_candidates_allgroup_detail.py
│ │ rename CSV: _updated_YYYYMMDD.csv → _updated_YYYYMMDD_vXBatchX.csv
│ │ rename xlsm: _done.xlsm → _done_vXBatchX.xlsm
│ │ create SUMMARY_RESULTS/Batch_X_vX/
│ │ move RAIDER_vX_*.ini + *.xlsx → Batch_X_vX/
│ │
│ └── Continue to next batch? (y/n)
│
├── STEP 5+6 ──────── AUTO: merge all Batch CSVs
│ AUTO: filter LOSS rows
│ AUTO: save candidates_updated_YYYYMMDD_vX.csv
│
├── MANUAL ───────── paste into AlphaBetaGamma xlsm
│ filter ZZ_Clusters AvgHedge=7
│
└── STEP 7 ────────── AUTO: archive all vX files → SUMMARY_RESULTS/YYYYMMDD_vX_updated/11. Closing Note
ในการสร้างระบบ algorithmic trading ที่ยั่งยืน มีสิ่งหนึ่งที่มักถูกมองข้ามในช่วงต้น นั่นคือ ต้นทุนของการ operate กลยุทธ์ที่ดีที่สุดจะไม่มีความหมายหากผู้สร้างไม่สามารถ update มันได้อย่างสม่ำเสมอ หรือเกิดความเหนื่อยล้าสะสมจากกระบวนการที่ซ้ำซ้อนทุกเดือน
บทสนทนาในวันที่ 6 กรกฎาคม 2026 จึงไม่ใช่เพียงการเขียน script — แต่เป็นการลงทุนในความยั่งยืนของ RAIDER ในฐานะ Execution Layer ของ KOOeda6 การที่ wizard รู้ว่าต้องทำอะไรต่อไป บอก operator ว่าต้องทำอะไร และจัดการผลลัพธ์ให้โดยอัตโนมัติ ทำให้ operator สามารถโฟกัสกับสิ่งที่มนุษย์ทำได้ดีกว่า machine — การตัดสินใจ การสังเกต และการปรับปรุงกลยุทธ์
ในบริบทที่กว้างกว่านั้น บทสนทนานี้แสดงให้เห็นว่า KOOeda6 กำลังเติบโตจากโปรเจกต์ส่วนตัวไปสู่ระบบที่มี infrastructure จริง — ระบบที่สามารถ operate ได้ในระยะยาว แม้ในวันที่ผู้สร้างไม่ได้อยู่หน้าจอตลอดเวลา
12. Historical Significance
★★★☆☆ Significant Improvement
เหตุผล: บทสนทนานี้ไม่ได้เปลี่ยน philosophy หรือ architecture ของ KOOeda6 โดยรวม RAIDER ยังคงเป็น RAIDER, AMARA ยังคงเป็น Meta Layer และ KOOeda6 ยังเดินหน้าในทิศทางเดิม
แต่สิ่งที่เปลี่ยนคือ ความสามารถในการ operate ระบบที่มีอยู่ได้อย่างสม่ำเสมอและมีประสิทธิภาพ ซึ่งเป็นรากฐานที่จำเป็นก่อนที่ระบบจะขยายตัวต่อไปได้
หากเปรียบกับการสร้างบ้าน บทสนทนาที่ผ่านมาสร้างโครงสร้าง กำแพง และหลังคา — บทสนทนานี้สร้าง ระบบไฟฟ้าและประปา ที่ทำให้บ้านสามารถอยู่อาศัยได้จริง ไม่華麗 แต่ขาดไม่ได้