ชุดทดสอบ E2E ของ SQLite แบบใช้งานจริงสำหรับเส้นทางที่ 3

เส้นทางทดสอบ E2E แบบสดด้วย SQLite สำหรับ Path 3 พิสูจน์ว่า Gateway ใช้ SQLite เป็นที่จัดเก็บเซสชันและทรานสคริปต์หลัก ขณะที่ไฟล์ JSONL แบบเดิมยังคงเป็นข้อมูลนำเข้าสำหรับการย้ายข้อมูลหรือวัสดุจัดเก็บถาวร นี่เป็นชุดทดสอบเพื่อการพิสูจน์สำหรับผู้ดูแล ไม่ใช่เครื่องมือวินิจฉัยสำหรับผู้ใช้ทั่วไป

หลังจาก Gateway ประมวลผลทราฟฟิกภายหลังการย้ายข้อมูลแล้ว ความสอดคล้องกับ JSONL แบบเดิมจะไม่ใช่สัญญาณสุขภาพของรันไทม์ที่ถูกต้องอีกต่อไป Gateway ที่ย้ายข้อมูลแล้วและทำงานปกติอาจมีจำนวนแถวทรานสคริปต์ใน SQLite แตกต่างจากจำนวนใน JSONL แบบเดิม เนื่องจากเทิร์นใหม่ควรเพิ่มข้อมูลใน SQLite เท่านั้น ดังนั้นชุดทดสอบแบบสดต้องวัดพฤติกรรมของ Gateway การเปลี่ยนแปลงของแถว SQLite การไม่มีความเคลื่อนไหวของไฟล์แบบเดิม และสุขภาพของบันทึกในแต่ละขั้นตอน

รูปแบบคำสั่ง

คำสั่งแบบสดที่กำหนดไว้คือ:

node scripts/path3-live-sqlite-e2e.mjs \  --url http://127.0.0.1:18789 \  --agent main \  --session-key agent:main:path3-live-e2e:<timestamp> \  --json

คำสั่งนี้เชื่อมต่อกับ Gateway ที่กำลังทำงานอยู่แล้ว โดยจะไม่เริ่ม หยุด นำเข้า หรือเรียกใช้การย้ายข้อมูลซ้ำ เว้นแต่จะเพิ่มโหมดการย้ายข้อมูลอย่างชัดเจนในภายหลัง ตัวแปรสำหรับ CI หรือสภาพแวดล้อมภายในเครื่องที่แยกออกมาอาจใช้ test/helpers/openclaw-test-instance.ts แต่เส้นทางการพิสูจน์แบบสดควรตรวจสอบ Gateway จริงของผู้ดำเนินการและฐานข้อมูล SQLite ต่อเอเจนต์จริงของระบบ

การพิสูจน์ด้วย CLI ที่สร้างแล้วในสภาพแวดล้อมแยก

ตัวเรียกใช้การพิสูจน์ด้วย CLI ที่สร้างแล้วจะเตรียมที่จัดเก็บเซสชันแบบเดิมในสภาพแวดล้อมแยก เริ่ม Gateway ที่สร้างใหม่ และพิสูจน์ว่าการเริ่มต้นระบบนำเข้าเซสชันแบบเดิมที่ใช้งานอยู่เข้าสู่ SQLite ก่อนเริ่มการอ่านในรันไทม์ โดยต้องไม่เรียกใช้ openclaw doctor --fix ก่อนเริ่ม Gateway ครั้งแรก เพราะการทำเช่นนั้นจะพิสูจน์เส้นทางการย้ายข้อมูลด้วยตนเองแทนเส้นทางการอัปเกรดที่ผู้ใช้ได้รับในการบูตครั้งแรกหลังจากสลับระบบ

หลังจากการนำเข้าระหว่างเริ่มต้นระบบ การพิสูจน์ในสภาพแวดล้อมแยกอาจเรียกใช้ openclaw doctor --session-sqlite inspect และ openclaw doctor --session-sqlite validate เป็นหลักฐานสำหรับการวินิจฉัย คำสั่ง doctor เหล่านั้นไม่ใช่ตัวขับเคลื่อนการย้ายข้อมูลสำหรับการพิสูจน์การอัปเกรดระหว่างเริ่มต้นระบบ สถานการณ์นำเข้าด้วย doctor ที่แยกต่างหากควรเตรียมไฟล์ทรานสคริปต์แบบเดิมพร้อมไฟล์เสริม trajectory และตรวจสอบว่า doctor จัดเก็บอาร์ติแฟกต์เหล่านั้นไว้ในคลัง ขณะที่ SQLite ยังคงเป็นที่จัดเก็บหลัก

การตรวจสอบเบื้องต้น

การตรวจสอบเบื้องต้นจะรวบรวมค่าพื้นฐานและล้มเหลวก่อนส่งเทิร์นสำหรับการพิสูจน์ หาก Gateway ไม่พร้อมใช้งาน:

• GET /health และสถานะเชิงลึกของ Gateway ต้องรายงานว่า Gateway กำลังทำงานและเข้าถึงได้
• เวอร์ชันของ CLI และ Gateway ต้องตรงกับแบรนช์ที่กำลังทดสอบ
• ชุดทดสอบบันทึกเคอร์เซอร์ของบันทึกสำหรับไฟล์บันทึกของ Gateway ที่ใช้งานอยู่
• ชุดทดสอบบันทึกจำนวนแถวของตาราง SQLite ต่อเอเจนต์สำหรับ sessions, session_entries, transcript_events, transcript_event_identities และ session_routes
• ชุดทดสอบบันทึก mtime, size และสถานะการมีอยู่ของไฟล์แบบเดิม sessions.json, ไฟล์ JSONL ที่อ้างอิง และเส้นทาง JSONL ที่อาจใช้สำหรับเซสชันพิสูจน์
• lsof -p <gateway-pid> ต้องแสดงแฮนเดิล SQLite DB/WAL/SHM และไม่มีแฮนเดิล .jsonl หรือ sessions.json ที่ใช้งานอยู่

openclaw doctor --session-sqlite validate ใช้เพื่อให้ข้อมูลเท่านั้นในโหมดสด หลังจากมีทราฟฟิกภายหลังการสลับระบบ อาจรายงานความคลาดเคลื่อนจากไฟล์แบบเดิมตามที่คาดไว้ ชุดทดสอบควรใช้ผลลัพธ์ของ doctor เพื่อจำแนกประเภทและจัดทำรายการการย้ายข้อมูล ไม่ใช่ใช้เป็นเกณฑ์ตัดสินผ่าน/ไม่ผ่านของรันไทม์

สถานการณ์ที่ขับเคลื่อนโดยเอเจนต์

สถานการณ์แบบสดใช้คีย์เซสชันเฉพาะสำหรับการพิสูจน์ และดำเนินการกับ Gateway ผ่านเส้นทาง RPC สาธารณะทุกครั้งที่ทำได้ เทิร์นของเอเจนต์หนึ่งเทิร์นควรเพียงพอสำหรับทดสอบการคงอยู่ตามปกติ แต่การพิสูจน์แบบเต็มควรครอบคลุมจุดเชื่อมต่อ 3.1b ซึ่งก่อนหน้านี้ต้องตรวจสอบแบบสดแยกกัน:

• เทิร์นแชตทั่วไป: สร้างหรือนำเซสชันพิสูจน์กลับมาใช้ ส่งพรอมต์จริงให้เอเจนต์ รอผลลัพธ์สุดท้ายจากผู้ช่วย และตรวจสอบ chat.history หรือการฉายข้อมูลที่เทียบเท่าของ Gateway
• อัตลักษณ์ของทรานสคริปต์: ตรวจสอบว่าเครื่องหมายเดียวกันปรากฏในประวัติของ Gateway และในแถวทรานสคริปต์ของ SQLite รวมถึงแถวอัตลักษณ์เหตุการณ์ที่คงที่เมื่อมี
• ตัวเข้าถึงข้อมูลเมตาของเซสชัน: อ่านเซสชันพิสูจน์และเซสชันสดที่มีอยู่ซึ่งเลือกไว้ผ่านตัวเข้าถึง Gateway/เซสชัน แล้วเปรียบเทียบกับแถวใน SQLite
• การฉายแพตช์เซสชัน: ใช้การเปลี่ยนแปลงข้อมูลเมตาของโมเดล/เซสชันที่ย้อนกลับได้กับเซสชันพิสูจน์ จากนั้นตรวจสอบว่าแถวที่ฉายและการตอบกลับของ Gateway สอดคล้องกัน
• วงจรชีวิตของจุดตรวจสอบ Compaction: แสดงรายการ สร้างแขนง และกู้คืนจุดตรวจสอบเฉพาะในเซสชันพิสูจน์หรือเซสชันฟิกซ์เจอร์สังเคราะห์ที่ชุดทดสอบสร้างขึ้นเท่านั้น
• การกู้คืนหลังเริ่มใหม่: เรียกใช้เส้นทางเครื่องหมายการกู้คืนที่ปลอดภัยกับเซสชันพิสูจน์ที่ควบคุมได้หรืออินสแตนซ์ทดสอบที่แยกออกมา ในโหมดสดจะเรียกใช้ขั้นตอนนี้ได้เฉพาะเมื่อกำหนดชุดเซสชันเป้าหมายไว้อย่างชัดเจนและสามารถย้อนกลับได้
• วงจรชีวิตการล้างข้อมูล: ลบหรือรีเซ็ตเซสชันพิสูจน์ จากนั้นตรวจสอบแถววงจรชีวิตใน SQLite และสถานะทรานสคริปต์ที่จัดเก็บถาวร

จุดเชื่อมต่อเฉพาะทรานสปอร์ตที่ไม่สามารถทดสอบได้อย่างปลอดภัยบน Gateway จริงของผู้ดำเนินการ เช่น ช่องทางขาเข้าจาก WhatsApp หรือการโทรด้วยเสียง ควรใช้โพรบระดับรันไทม์ของเจ้าของกับสัญญา SQLite เดียวกันแทนการจำลองทรานสปอร์ตภายนอก

การยืนยันในแต่ละขั้นตอน

แต่ละขั้นตอนจะบันทึกสแนปช็อตสถานะก่อนและหลัง และเขียนระเบียนการยืนยันแบบมีโครงสร้าง:

• จำนวนแถว SQLite เพิ่มขึ้นเฉพาะตำแหน่งที่คาดไว้
• แถวรันไทม์ trajectory เพิ่มขึ้นสำหรับเซสชันพิสูจน์ที่มีเครื่องหมายกำกับและบันทึกเหตุการณ์รันไทม์
• แถวของเซสชันพิสูจน์มี session_id, สถานะ, การประทับเวลา, ข้อมูลเมตา และแถวเส้นทางตามที่คาดไว้
• ประวัติ/การฉายเซสชันของ Gateway ตรงกับส่วนท้ายของทรานสคริปต์ SQLite
• ไม่มีการสร้างหรือแก้ไขไฟล์ JSONL ของเซสชันพิสูจน์
• ไม่มีการสร้างไฟล์เสริม .trajectory.jsonl, .trajectory-path.json หรือ trajectory/<session>.jsonl ที่ได้มาจากเครื่องหมายสำหรับเซสชันพิสูจน์
• ไฟล์ JSONL แบบเดิมที่มีอยู่และ sessions.json ต้องไม่เปลี่ยนแปลง เว้นแต่ขั้นตอนนั้นเป็นการย้ายข้อมูลแบบออฟไลน์หรือการดำเนินการจัดเก็บถาวรอย่างชัดเจน
• กระบวนการ Gateway ต้องไม่เปิดแฮนเดิล .jsonl หรือ sessions.json
• บันทึกหลังเคอร์เซอร์ก่อนหน้าต้องไม่มี ERROR, FATAL, SQLITE_, no such column, ข้อความว่าไม่พร้อมใช้งานของที่จัดเก็บเซสชัน, ความล้มเหลวในการกู้คืนหลังเริ่มใหม่ หรือคำเตือนการปรับยอดทรานสคริปต์ เว้นแต่สถานการณ์นั้นอนุญาตไว้อย่างชัดเจนในรายการอนุญาต

การสแกนบันทึกเป็นส่วนหนึ่งของสัญญาการผ่าน/ไม่ผ่าน Gateway ที่ตอบการตรวจสอบสุขภาพได้แต่ปล่อยข้อผิดพลาดสคีมา SQLite หรือความล้มเหลวซ้ำ ๆ ในการปรับยอดทรานสคริปต์ จะไม่ถือว่าผ่านสำหรับ Path 3

อาร์ติแฟกต์หลักฐาน

ชุดทดสอบควรเขียนหลักฐานไว้ภายใต้ .artifacts/path3-live-e2e/<timestamp>/ และไม่นำเข้า git:

• summary.json: อาร์กิวเมนต์คำสั่ง เวอร์ชัน Gateway ผลลัพธ์ การยืนยันที่ล้มเหลว และเส้นทางอาร์ติแฟกต์
• sqlite-before.json และ sqlite-after.json: จำนวนแถวและแถวพิสูจน์ที่เลือก
• legacy-files.json: สถานะการมีอยู่ของไฟล์แบบเดิม mtime ขนาด และสถานะว่าแต่ละไฟล์เปลี่ยนแปลงหรือไม่
• gateway-log-scan.json: ช่วงเคอร์เซอร์ บรรทัดบันทึกที่ตรงกัน และการตัดสินใจตามรายการอนุญาต
• events.jsonl: ข้อสังเกตตามลำดับในแต่ละขั้นตอนที่เหมาะสำหรับความคิดเห็นหลักฐานใน PR

หลักฐานใน PR ควรสรุปอาร์ติแฟกต์เหล่านี้แทนการวางทรานสคริปต์ฉบับเต็มหรือเนื้อหาข้อความส่วนตัว

กฎความปลอดภัย

• โหมดสดต้องไม่นำเข้า JSONL แบบเดิมซ้ำขณะที่ Gateway กำลังทำงาน
• โหมดสดต้องไม่แก้ไขเซสชันที่ไม่ใช่เซสชันพิสูจน์ ยกเว้นโพรบการซ่อมแซมที่เลือกไว้อย่างชัดเจนและสามารถย้อนกลับได้
• ขั้นตอนการย้ายข้อมูลที่ทำลายข้อมูลหรือครอบคลุมกว้างต้องมีข้อมูลสำรองใหม่ของฐานข้อมูล SQLite และไดเรกทอรีเซสชันแบบเดิมที่ได้รับผลกระทบ
• ข้อมูลสำรองควรจำกัดขอบเขตไว้ที่ฐานข้อมูล/ไดเรกทอรีเซสชันของเอเจนต์ที่ได้รับผลกระทบ และนำกลับมาใช้ภายในการพิสูจน์หนึ่งรอบเพื่อหลีกเลี่ยงการใช้พื้นที่ดิสก์เพิ่มขึ้นโดยไม่มีขีดจำกัด
• ขั้นตอนการล้างข้อมูลต้องไม่เหลือเซสชันพิสูจน์ JSONL สำหรับการพิสูจน์ หรือไฟล์แบบเดิมที่ถูกแก้ไข เว้นแต่ผู้เรียกส่ง --keep-artifacts

ผลลัพธ์ที่ผ่าน

การเรียกใช้แบบสดที่ผ่านหมายความว่า Gateway ยอมรับโฟลว์เซสชันจริงที่ขับเคลื่อนโดยเอเจนต์ สถานะหลักที่สังเกตได้ทั้งหมดอยู่ใน SQLite ไฟล์รันไทม์แบบเดิมไม่มีความเคลื่อนไหว และสุขภาพของบันทึกยังคงสะอาดตลอดช่วงที่วัดผล ไม่ได้หมายความว่าความสอดคล้องของ JSONL แบบเดิมจะยังคงสมบูรณ์หลังจากมีทราฟฟิกสด การคลาดเคลื่อนระหว่างการทำงานแบบสดเป็นสิ่งที่คาดไว้เมื่อ SQLite เป็นที่จัดเก็บหลัก