# CPX P3-01: ผลทดลองตัวตนและบันทึกประจำฝ่ายในเครื่อง

วันที่ 7 ตุลาคม 2026 · เว็บ 1.17.1 · ต้นแบบหน้าฝึกเดิม 1.16.28

## ขอบเขตและสถานะ

ชุดทดลองผ่านการทดสอบระหว่างพัฒนาในเครื่อง 9 กรณี ครอบคลุม interface ของ F01–F08 และการตรึงฐานข้อมูล ชุดนี้ใช้ Node.js 22.23.1, SQLite และตัวตนสมมติ เพื่อทดสอบสัญญาของ IdentityPolicy และ OwnerJournal ใช้กติกาภารกิจจากต้นแบบเดิม ไม่มีการเปิดห้องฝึกหรือสร้าง Durable Objects, D1, R2 บนคลาวด์

ผลในเครื่องแยกจากการตรวจบน Cloudflare แบบบันทึกคลาวด์ F01–F16 ยังเป็น NOT_RUN ทุกกรณี การทดสอบโปรแกรมไม่แทนการซักซ้อมเจ็ดบทบาท การตรวจรับการบิน หรือการใช้กับเหตุจริง

## สิ่งที่ตรวจในชุดนี้

| กรณี | พฤติกรรมที่ตรวจผ่าน interface ในเครื่อง | ชั้นที่ยังต้องตรวจต่อ |
|---|---|---|
| F01 | ผู้ไม่มีสมาชิกหรือยืนยัน policy ปัจจุบันไม่ได้ ถูกปฏิเสธก่อนอ่าน/เขียน | วิธีเข้าสู่ระบบและ issuer จริง |
| F02 | grant ผูกฝ่าย/บทบาท/ห้อง/รอบ เปลี่ยนฝ่ายหรือปลอม object ใช้ไม่ได้ ทรัพยากรส่วนตัวไม่แสดงข้ามฝ่าย | HTTP, WebSocket และ routing จริง |
| F03 | ถอนสิทธิ์แล้ว context เดิมอ่าน/ส่ง/ขอผลคำสั่งเดิมไม่ได้ และแสดง revoking จน ACK ครบ | policy กระจายข้าม owner และ socket ที่ค้างจริง |
| F04 | สอง connection เสนอทีมหลักคนละทีมด้วย revision เดียวกัน คำสั่งที่สองพบ SQLITE_BUSY ขณะคำสั่งแรกยังล็อกและไม่ commit หลังปล่อยล็อกแล้ว retry คำสั่งเดิมได้ revision conflict มีทีมหลักหนึ่งทีม | สอง browser ผ่าน gateway/DO จริง |
| F05 | ส่ง ID/เนื้อหาเดิมหลังเปิดฐานใหม่ คืนผลเดิมโดยตรวจสิทธิ์ปัจจุบันก่อน มีผลธุรกิจครั้งเดียว | reconnect ผ่านเครือข่ายจริง |
| F06 | ID เดิมแต่เนื้อหาเปลี่ยน ถูกปฏิเสธโดยไม่มีบันทึกเพิ่ม | เส้นทาง client/gateway จริง |
| F07 | ข้อมูลสังเคราะห์ที่แผนหรือการสนับสนุนเปลี่ยนแล้ว ปฏิเสธคำสั่งอ้างฉบับเก่า ทีมหลักเดิมยังอยู่และต้องทบทวน | การส่งการเปลี่ยนแปลงจาก owner อื่นแบบสด |
| F08 | จุดขัดข้องก่อน commit rollback ทั้งชุด หลัง commit เปิดฐานใหม่และ retry ได้ผลเดิม journal/result/outbox ครบ | process kill, eviction, hibernation และ storage บน Cloudflare |

## วิธีทดสอบและหลักฐาน

คำสั่งสำหรับทดสอบสัญญาชุดใหม่:

```text
node --test tools/cpx-cloud-feasibility/interface.test.mjs
```

คำสั่งสำหรับตรวจต้นแบบเดิม:

```text
node --test tools/cpx-local/*.test.mjs
```

ก่อน implementation กรณี F01–F08 ล้มเหลวครบแปดกรณีเพราะ interface ยังไม่มี หลัง implementation ผ่านเก้ากรณี ไม่ข้ามกรณีใด ต้นแบบเดิมผ่าน 147 กรณีในรอบนี้ การทดสอบใช้ฐานข้อมูลชั่วคราวที่แยกกันและลบหลังปิด connection/worker ของชุดนั้นแล้ว Node แจ้งว่า SQLite ยังเป็น experimental feature

การตรวจคุณภาพพบว่า gate ของ F04 เดิมยังไม่พิสูจน์การแย่งเขียน SQLite จึงเพิ่มข้อยืนยันให้รอผล BUSY จริงก่อนปล่อย writer แรก การทดสอบที่เข้มขึ้นล้มเหลวกับ worker เดิม และผ่านหลังแก้ protocol ผลตรวจซ้ำพบ ERR_SQLITE_ERROR/errcode 5 และข้อความ database is locked หลังรอ 5538.4 ms ก่อน retry แล้วได้ REVISION_CONFLICT ระยะรอเป็นผลจาก SQLite busy timeout ในเครื่อง ไม่ใช่ค่า latency ของคลาวด์

## ข้อจำกัดของหลักฐาน

ตัวตนเป็น fixture ที่ host สร้าง ไม่ใช่การตรวจ JWT หรือบัญชีจริง ข้อมูลจากฝ่ายอื่นเป็น trusted prefix ที่สร้างผ่าน runtime เดิมและตรึงกับฐานข้อมูลตอนเปิด ชุดนี้ยังไม่มี transport รับข้อมูลข้ามฝ่าย revision ของ journal ในชุดทดลองเริ่มที่ศูนย์หลัง prefix และแยกจากลำดับเหตุการณ์ใน projection

การขัดข้อง F08 ใช้จุดแทรกข้อผิดพลาดก่อน/หลัง commit และ close/reopen ฐานข้อมูล ผลยังไม่พิสูจน์ไฟดับ การหยุด process ระหว่าง write หรือพฤติกรรม Durable Objects สถานะ revocation/ACK ในชุดนี้เป็น policy fixture ในเครื่อง ยังต้องตรวจการบันทึก fence ที่ owner จริงและการกระจาย policy ต่อ

ตรวจ source ด้านสิทธิ์และข้อมูลตาม security-audit guidance เท่านั้น ยังไม่มี OS-enforced audit sandbox จึงไม่อ้างการตรวจรับความปลอดภัยจากผล dev tests เอกสาร [Cloudflare Storage](https://developers.cloudflare.com/durable-objects/best-practices/access-durable-objects-storage/) เป็นฐานสำหรับออกแบบ storage ของ owner; ผล SQLite ในเครื่องต้องตรวจซ้ำกับ storage API จริง

## ลำดับถัดไป

1. P3-02: delivery, outbox/receipt, การเชื่อมกลับ และ stop fence ข้ามฝ่าย โดยแยก received จากการรับภารกิจ
2. P3-03: projection watermark, หลักฐานตามสิทธิ์ และ coordinated restore
3. P3-04: ตรวจบน Cloudflare หลังยืนยัน issuer/login กติกาถอนสิทธิ์ retention วงเงิน และสิทธิ์บัญชีจริง
4. ซักซ้อมกับผู้ใช้จริงและตรวจรับขอบเขต ก่อนขยายหลายฝ่ายหรือใช้กับเหตุจริง
