# CPX P3-03: ข้อมูลสรุป หลักฐานส่วนตัว และการกู้คืน

วันที่ 8 ตุลาคม 2026 · เว็บ 1.17.3 · ต้นแบบหน้าฝึกเดิม 1.16.28

## ขอบเขต

ชุดพัฒนาในเครื่องสำหรับ F13–F15 ใช้ข้อมูลน้ำท่วมและตัวตนสมมติ ทดสอบผ่าน interface กับ SQLite และไฟล์ชั่วคราวแยกจากหลักฐานเดิม ผลนี้ยังไม่ใช่การทดสอบ D1, R2 หรือ Durable Objects บน Cloudflare

## พฤติกรรมและเหตุผลในการออกแบบ

| กรณี | สิ่งที่ตรวจในเครื่อง | ขอบเขตที่ยังต้องตรวจต่อ |
|---|---|---|
| F13 ข้อมูลสรุป | การส่งข้อมูลสรุปล่าช้า ซ้ำ และผิดลำดับต้องไม่ทำให้มองว่าข้อมูลเก่าทันปัจจุบัน คำสั่งยืนยันภารกิจกลับไปตรวจ revision กับเจ้าของข้อมูล | D1 Sessions จริง และการส่งสถานะภารกิจใหม่ข้ามฝ่ายแบบสด |
| F14 หลักฐาน | เจ้าของอ่านหลักฐานที่ยืนยัน digest แล้วได้ การอ่านข้ามฝ่ายหรือหลังถอนสิทธิ์ถูกปฏิเสธ digest ผิดไม่ทำให้ไฟล์พร้อมอ่าน และไม่มี URL สาธารณะ | R2 และ Worker policy บนเครือข่ายจริง การเก็บรักษาและลบข้อมูลตามนโยบาย |
| F15 กู้คืน | ใช้ไฟล์ฐานข้อมูลจริงของเจ็ดฝ่าย พร้อมบันทึกส่ง/รับและหลักฐาน ตรวจความสัมพันธ์ก่อนคืนลงโฟลเดอร์ใหม่ คงสถานะหยุดและรอการยืนยันกลับเข้าระบบ | การเก็บ snapshot ระหว่างระบบกระจายทำงานจริง และการกู้คืนบนแพลตฟอร์ม |

ข้อมูลสรุปเป็นสำเนาสำหรับอ่าน การมี bookmark ไม่อนุญาตให้ยืนยันทีมหลักจากข้อมูลเก่า การยืนยันยังต้องตรวจเจ้าของสถานะและทรัพยากรตามกติกาภารกิจเดิม

การคืนข้อมูลไม่ใช่การเริ่มฝึกต่อ ผู้เข้าฝึกต้องมีสิทธิ์ปัจจุบันและยืนยันกลับเข้าใช้อย่างชัดเจน คำสั่งใหม่ยังถูก fence ปิดกั้น ข้อความที่ค้างอยู่ยังคงอยู่ใน outbox โดยไม่มีการส่งให้อัตโนมัติ นโยบายเริ่มฝึกต่อเป็นงานแยกใน P3-04

## วิธีตรวจและข้อจำกัด

```text
node --test tools/cpx-cloud-feasibility/*.test.mjs
node --test tools/cpx-local/*.test.mjs
```

ตรวจรวมผ่าน 19 กรณี: 15 กรณีเดิมและ 4 กรณีใหม่ ไม่มี fail/skip ต้นแบบเดิมผ่าน 147 กรณี ก่อนแก้มี assertion ล้มเหลวที่ตรวจพบสถานะหยุดเปลี่ยนโดยเลขบันทึกภารกิจเท่าเดิม จึงเพิ่ม source/current control epoch และ control lag แยกจาก owner revision แล้วตรวจผ่าน

กรณีกู้คืนตรวจทั้ง hash ภายนอกผิดและข้อมูลภายในที่ไม่ตรงกันแม้คำนวณ hash ใหม่ เช่น ลบหลักฐานรับข้อความ ลบ fence ลบ ACK หรือเปลี่ยนเนื้อหาหลักฐาน ตรวจว่าปฏิเสธและล้างปลายทางทดลองที่สร้างใหม่ โดยไฟล์ต้นทางยังตรงทุก byte

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

ตัวตน สิทธิ์ และ peer เป็น fixture ใน process การอ่านยังต้องตรวจสิทธิ์ปัจจุบัน สถานะ rejoin เก็บเฉพาะใน process และล้างเมื่อปิด ไม่ใช่ทะเบียน rejoin ถาวร ผลการกู้คืนจึงไม่แทนการทดสอบ JWT, HTTP/WebSocket หรือ policy ที่เก็บถาวร การยืนยันกลับเข้าระบบไม่ใช่หลักฐานอนุญาตให้เริ่มภารกิจหรือบิน

ผลรวมยังเป็น PARTIAL แบบบันทึกคลาวด์ F01–F16 คง NOT_RUN ทุกกรณี ยังไม่มีห้องฝึกหลายคนบน Cloudflare หรือการตรวจรับเหตุจริง การทบทวนสิทธิ์ใช้ security-audit guidance จาก source; ยังไม่มี OS-enforced audit sandbox จึงไม่อ้างผลทดสอบระหว่างพัฒนาเป็นผลตรวจรับความปลอดภัย

## ฐานวิจัย

- [D1 Sessions และ read replication](https://developers.cloudflare.com/d1/best-practices/read-replication/): bookmark ใช้ติดตามลำดับข้อมูลใน D1 session โครงการจึงแยก watermark ของเจ้าของข้อมูลออกต่างหาก
- [R2 Workers API](https://developers.cloudflare.com/r2/api/workers/workers-api-reference/): มีตัวเลือก checksum และ conditional operations ชุดนี้ตรวจสัญญาฝั่งแอปในเครื่องก่อนเชื่อม API จริง
- [R2 presigned URLs](https://developers.cloudflare.com/r2/api/s3/presigned-urls/): ผู้ถือ URL ใช้สิทธิ์ได้จนหมดอายุ หลักฐานที่ต้องถอนสิทธิ์จึงออกแบบให้อ่านผ่านการตรวจสิทธิ์ทุกครั้ง
- [Durable Object SQLite storage และ PITR](https://developers.cloudflare.com/durable-objects/api/sqlite-storage-api/): กู้คืนฐานของ object แต่ละตัว และไม่รองรับ PITR ใน local development ชุดกู้คืนหลายฝ่ายนี้เป็นสัญญาของแอปที่ต้องตรวจเพิ่ม

ตรวจเอกสารทางการวันที่ 8 ตุลาคม 2026 ข้อเสนอของแอปไม่ใช่คำรับรองพฤติกรรมข้ามบริการจาก Cloudflare

## งานถัดไป

P3-04 ตรวจการส่งสถานะภารกิจแบบสดข้ามฝ่าย ตัวตนของ peer และ policy ปัจจุบัน การเชื่อมกลับ นโยบายเริ่มฝึกต่อ และ snapshot ที่สัมพันธ์กันบนแพลตฟอร์ม เตรียมระบบทดสอบ Cloudflare แบบจำกัดหลังยืนยันวิธีเข้าสู่ระบบ การถอนสิทธิ์ retention วงเงิน และความสามารถของบัญชี จากนั้นเก็บผลซักซ้อมกับผู้ใช้จริงก่อนตรวจรับ