---
read_when:
    - คุณกำลังพิสูจน์การสลับพื้นที่จัดเก็บข้อมูล SQLite ของ Path 3 กับ Gateway ที่ทำงานจริง
    - คุณต้องแยกความคลาดเคลื่อนของ JSONL แบบเดิมที่คาดไว้ ออกจากความล้มเหลวขณะรันไทม์
    - คุณกำลังสร้างหรือตรวจสอบชุดทดสอบ E2E แบบสดที่ขับเคลื่อนโดยเอเจนต์สำหรับ SQLite
summary: การออกแบบสำหรับการพิสูจน์ Gateway แบบใช้งานจริงของการสลับเซสชัน/ทรานสคริปต์ SQLite ใน Path 3
title: ชุดทดสอบ E2E ของ SQLite แบบใช้งานจริงสำหรับเส้นทางที่ 3
x-i18n:
    generated_at: "2026-07-16T19:38:44Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 2749bf47cb4967bc80a5ed37a12f2a553f3b388ed8cd90cfb3217e1b5e8afae9
    source_path: reference/path3-live-sqlite-e2e-harness.md
    workflow: 16
---

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

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

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

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

```bash
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 เป็นที่จัดเก็บหลัก