# แผนทดลอง CPX หลายฝ่ายบน Cloudflare

ปรับปรุง 7 ตุลาคม 2026 · ชุดเตรียมเฟส 3 · รุ่นเว็บ 1.17.0

สถานะ: จัดทำแผนและเกณฑ์ทดสอบแล้ว ยังไม่ได้รันทดสอบ Cloudflare และยังไม่ได้เปิดห้องฝึกหลายคน

## ข้อตกลงและเป้าหมาย

ผู้ใช้ยืนยันเป็นผู้ดูแลการเพิ่ม/ถอนสิทธิ์ผู้ฝึก และใช้บัญชี Cloudflare เดิมของเว็บ เมื่อ 7 ตุลาคม 2026 การยืนยันนี้ไม่ใช่ผลตรวจสิทธิ์บัญชีหรือการอนุมัติค่าใช้จ่าย ต้องกำหนดวิธีเข้าสู่ระบบ กติกาถอนสิทธิ์ และวงเงินก่อนสร้างบริการทดสอบบนคลาวด์

ใช้ข้อมูลน้ำท่วม/ช่วยเหลือสังเคราะห์ เจ็ดที่นั่ง N-C, N-D-A, N-D-B, N-R, N-A, N-X, N-E ตามต้นแบบ 1.16.28 เริ่มทดลองบน loopback/เครือข่ายทดสอบ แล้วตรวจเส้นทาง Cloudflare จริงแบบจำกัด ผลจาก emulator ไม่แทนผลแพลตฟอร์มจริง ผลทางเทคนิคไม่แทนการซักซ้อมกับคนหรือการตรวจรับด้านการบิน

## หลักฐานแพลตฟอร์มที่ตรวจเมื่อ 7 ตุลาคม 2026

| รหัส | ข้อเท็จจริงจากเอกสารทางการ | ผลต่อแบบที่เสนอ |
|---|---|---|
| CF3-01 | [DO SQLite storage](https://developers.cloudflare.com/durable-objects/api/sqlite-storage-api/) เป็น transactional/strongly consistent ภายใน instance; transactionSync ต้องทำงาน synchronous | บันทึกผลคำสั่ง event และ outbox ใน transaction เดียวที่เจ้าของ ห้ามเรียกเครือข่ายใน transaction; ไม่มี transaction ข้ามเจ้าของ |
| CF3-02 | [WebSocket Hibernation](https://developers.cloudflare.com/durable-objects/best-practices/websockets/) คง socket ได้เมื่อ object หลับ แต่ in-memory state ต้องสร้างใหม่ | socket เป็นการแจ้งเตือน cursor; journal เป็นหลักฐาน ใช้ reconnect และ snapshot เพื่อเติมช่องว่าง |
| CF3-03 | [Queues delivery](https://developers.cloudflare.com/queues/reference/delivery-guarantees/) เป็น at-least-once; [How Queues works](https://developers.cloudflare.com/queues/reference/how-queues-works/) ระบุว่าไม่รับประกันลำดับ | deduplicate ที่ผู้รับและจัดลำดับตาม sequence; ไม่เลือก Queue เป็นเจ้าของการยืนยันภารกิจ |
| CF3-04 | [D1 Sessions](https://developers.cloudflare.com/d1/best-practices/read-replication/) ให้ sequential consistency ใน session | bookmark ของ D1 ไม่พิสูจน์ว่า event จาก DO ถูก project แล้ว ต้องมี watermark ของแอปแยก |
| CF3-05 | [Access JWT validation](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/) ต้องตรวจ JWT และ audience | login ไม่แทนสิทธิ์ประจำฝ่าย แอปตรวจ membership ปัจจุบันทุกคำสั่ง/การอ่าน/การส่งข้อมูล |
| CF3-06 | [R2 presigned URLs](https://developers.cloudflare.com/r2/api/s3/presigned-urls/) ใช้สิทธิ์จาก URL จนหมดอายุ | หลักฐานที่ต้องถอนสิทธิ์ทันทีให้อ่านผ่าน Worker ที่ตรวจสิทธิ์ ไม่แจก URL ระยะยาว |

ส่วนต่อไปเป็นข้อเสนอของโครงการ ไม่ใช่สิ่งที่ Cloudflare รับประกันให้โดยอัตโนมัติ ไม่มีการระบุราคาหรือเพดานจากความจำ ก่อนทดลองจริงอ่าน [DO pricing](https://developers.cloudflare.com/durable-objects/platform/pricing/), [Workers pricing](https://developers.cloudflare.com/workers/platform/pricing/), [D1 pricing](https://developers.cloudflare.com/d1/platform/pricing/) และ [R2 pricing](https://developers.cloudflare.com/r2/pricing/) พร้อมแผนบัญชีที่ใช้จริง

## ทางเลือกและขอบเขตทดลอง

1. เลือก DO ต่อเจ้าของ + durable outbox ตามแบบเดิม: ตรวจการแยกฝ่ายและการส่งข้ามเจ้าของได้ตรงเป้าหมาย แม้ต้องทำ recovery protocol เพิ่ม
2. หนึ่ง DO ต่อห้อง: ทดลองลำดับง่าย แต่ไม่พิสูจน์การหยุด/กู้คืนข้ามเจ้าของ จึงไม่ใช้เป็นเกณฑ์เฟส 3
3. D1 + polling: เหมาะอ่านสรุป แต่เพิ่มภาระ concurrency และไม่แทนเจ้าของสถานะ จึงไม่ย้ายแกนภารกิจไป D1

ชุดแรกใช้ ExerciseControl และ TrainingNode ที่แยกจริง; N-C ถือทะเบียนทีมหลักหนึ่งทีมต่อภารกิจ ส่วน N-A ถือทะเบียนประสานห้วงอากาศร่วม ทั้งสองใช้ owner instance ของตน ฝ่ายโดรนถือแผน/ทรัพยากร/รายงานของตน ไม่มีฝ่ายใดยืนยันทีมหลักหรือพื้นที่บินร่วมจากสำเนาที่ตามไม่ทัน การจองไม่ผูกขาด waiting list การยืนยันภารกิจไม่ใช่สิทธิ์บิน

ใช้การส่ง DO-to-DO จาก durable outbox ในชุดแรก ทดสอบ duplicate/reorder ด้วย fault adapter; เพิ่ม Queues เฉพาะเมื่อพิสูจน์ความจำเป็นของงานเบื้องหลัง D1 เป็น read model ขนาดเล็ก R2 ใช้ไฟล์ fixture สังเคราะห์ส่วนตัวเท่านั้น ไม่มี CrisisLink จริงหรือคำสั่งอากาศยานในชุดนี้

## Interface และข้อกำหนด

| Module | Interface และ invariant |
|---|---|
| IdentityPolicy | resolveActor/authorize ผูก subject ที่ตรวจแล้วกับ environment/exercise/session/node/role และ membershipRevision; client เปลี่ยน node/role เองไม่ได้; source ปัจจุบันไม่พร้อมให้ปฏิเสธการเข้าถึง |
| OwnerJournal | submit(commandId, payloadDigest, expectedRevision, controlEpoch) ให้ผล durable หลัง commit; ID เดิม/เนื้อหาเดิมคืนผลเดิม ID เดิม/เนื้อหาเปลี่ยนปฏิเสธ; การตรวจสิทธิ์ต้องมาก่อนคืนผลเก่า |
| Delivery | receiveEnvelope(sourceOwner, recipientOwner, session, messageId, payloadDigest, sourceSequence, deliverySequence) ตรวจผู้ส่งและ binding ก่อน append/receipt; receipt ไม่ใช่ business acceptance; gap ในลำดับของผู้รับรอเติม ไม่เดาสถานะ |
| Projection | readAllowed(cursor) คืน allowed snapshot, ownerRevision และ projectionWatermark; ข้อมูลเก่าระบุชัด คำสั่งตัดสินใจตรวจกับ owner อีกครั้ง |
| Control | stop(expectedRevision) บันทึก epoch ใหม่และ stopping; ทุก owner บันทึก fence/finalSequence แล้ว ACK; stopped ได้เมื่อ ACK ครบตาม manifest; offline ยัง unconfirmed |
| Recovery | restoreManifest ผูก package digest/session/epoch/owner checkpoints/outbox/receipts และ evidence digests; restore ต้องฝึกหยุดและให้ owner rejoin ชัดเจน ไม่มี replay backlog อัตโนมัติ |

### ข้อกำหนดลำดับข้อความสำหรับชุดทดลอง P3-02

`sourceSequence` ใช้อ้างคำสั่งที่บันทึกกับฝ่ายผู้ส่ง ส่วน `deliverySequence` เรียงเฉพาะคู่ผู้ส่ง–ผู้รับ คำสั่งหนึ่งอาจส่งไปหลายฝ่าย และบางคำสั่งไม่ส่งให้ผู้รับรายนี้ จึงห้ามใช้เลขคำสั่งที่ข้ามเป็นหลักฐานว่าข้อความของผู้รับหาย ข้อนี้เป็นการออกแบบสัญญาของ CPX จากพฤติกรรมคิวที่เอกสาร Cloudflare ระบุ ไม่ใช่คำรับรองการเรียงลำดับจากผู้ให้บริการ

หลักฐานรับระดับ transport ต้องผูก ID เนื้อหา ผู้ส่ง ผู้รับ ห้อง/รอบ และลำดับ เมื่อบันทึกแล้วแต่คำตอบหาย การส่งซ้ำต้องคืนหลักฐานเดิมโดยตรวจสิทธิ์ปัจจุบันก่อน การรับภารกิจยังต้องผ่านแผน ทรัพยากร และการยืนยันทีมหลักของ N-C แยกต่างหาก

ผลทดลอง P3-02 ในเครื่องใช้ตัวตนและ peer fixture ที่ host สร้าง บันทึกการส่ง/รับแยกจากกติกาภารกิจเดิม การส่งสถานะภารกิจจาก owner อื่นเข้าสู่ projection แบบสดยังเป็นงานที่ต้องตรวจต่อก่อน P3-04 การเปิดฐานข้อมูลใหม่ไม่แทนการตรวจ WebSocket reconnect หรือ Durable Objects hibernation จริง ดู [ผลและข้อจำกัดของชุดทดลอง](control-delivery-local-results-2026-10-07.md)

membership การถอนสิทธิ์มีลำดับที่ owner ของ policy บันทึกอย่างชัดเจน ไม่อ้างว่าย้อนยกเลิกคำสั่งที่ commit ก่อนการถอนแล้ว การถอนเสร็จเมื่อ affected owners ปิดกั้น subject และ ACK revision ครบ; ถ้ารับทราบไม่ครบแสดง revoking ไม่แสดง revoked สำเร็จ ทุก read/command/replay และ outbound WebSocket ต้องตรวจ policy ปัจจุบัน หากยืนยัน policy ไม่ได้ให้ระงับการเข้าถึง ห้ามเก็บสิทธิ์ไว้ใน socket attachment เป็น authority ถาวร

## งานเป็นลำดับและเกณฑ์ผ่าน

| ชุด | ส่งมอบ | หลักฐานและเกณฑ์ผ่าน |
|---|---|---|
| P3-00 เตรียม | แผนนี้ + CSV 16 กรณี + owner/account decision | เอกสารสอดคล้องแบบเดิม ทุกกรณีเป็น NOT_RUN; ไม่มี service หรือสิทธิ์ที่แต่งขึ้น |
| P3-01 local harness | isolated identity fixtures, owner journal และ fault adapter | cases F01–F08; ปฏิเสธข้ามฝ่าย/ข้ามห้องก่อนอ่านหรือเปลี่ยน state; journal/replay เทียบ fixture ที่คาด |
| P3-02 transport/control | reconnect, outbox/receipt, stop fences | F09–F12; disconnect ทุกจุดสำคัญไม่สูญ command และไม่เพิ่ม acceptance ซ้ำ; offline ไม่ทำให้หยุดครบ |
| P3-03 stores/recovery | D1 projection, private R2 fixture, coordinated restore | F13–F15; stale summary ไม่ทำให้ตัดสินใจผิด; ไม่มีหลักฐานหลุดสิทธิ์; restore mismatch ปฏิเสธ |
| P3-04 restricted cloud | เส้นทาง identity/WS/hibernation/store จริง + วัดโหลดและค่าใช้จ่าย | rerun F01–F16 บน deployment ทดสอบ; owner ตรวจทรัพยากร/วงเงิน/cleanup; local pass อย่างเดียวไม่ผ่าน |
| P3-05 pilot review | เจ็ดผู้ร่วมฝึกหรือผู้สวมบทบาทที่ระบุจริง + AAR | บันทึกวัน ผู้สังเกต ข้อค้นพบ และการยอมรับขอบเขต; ยังรอผลซักซ้อมเฟส 2; แก้ประเด็นก่อนเปิดกว้าง |

การเตรียม P3-00 ไม่ปิด gate เฟส 2/3 ชุด local harness ทำเตรียมได้โดยใช้ตัวตนสมมติ แต่ก่อน restricted cloud ต้องยืนยัน issuer/login, membership/revocation policy, retention, owner account permissions และวงเงิน ผู้ใช้เลือกเจ้าของและบัญชีแล้ว; ไม่มีการขอรหัสผ่าน/token ลงไฟล์สาธารณะ

## UX/UI ที่ชุดทดลองต้องแสดง

ใช้หน้าประจำฝ่ายจากต้นแบบเดิม: inbox และ receipt ของตน รายการรอ/จอง/แผน/ทรัพยากรของหน่วย ทีมหลักที่แชร์ งานตามบทบาท และการประสานห้วงอากาศ ผู้ฝึกเห็นสถานะ locally-recorded / delivery-pending / received แยกกัน ขณะ offline เก็บ draft ได้แต่ไม่แสดงว่าส่งสำเร็จหรือรับภารกิจแล้ว เมื่อ reconnect ต้องอ่าน revision ปัจจุบันก่อนให้ส่งใหม่

ส่วนหัวแสดงชื่อฝ่าย ห้อง/รอบฝึก เวลาสถานการณ์ และเวลาข้อมูลล่าสุด ฝ่ายที่ถูกถอนสิทธิ์ไม่เห็นข้อมูลใหม่และไม่ส่งคำสั่งต่อ EXCON เห็น stopping พร้อมรายชื่อฝ่าย unconfirmed; evaluator อ่านตามสิทธิ์และ cutoff ไม่ดึง truth อนาคต ทุกกรณีต้องมีข้อความที่อ่านเข้าใจได้และใช้คีย์บอร์ดได้ ไม่ใช้สีอย่างเดียวบอกสถานะ

## แผนความจุ ค่าใช้จ่าย และการหยุดทดลอง

สมมติฐาน workload ที่เสนอ: หนึ่งห้อง เจ็ดที่นั่ง เริ่มหนึ่ง browser ต่อที่นั่ง แล้วทดลองสอง browser ต่อที่นั่งเพื่อจับคำสั่งชนกัน ใช้จำนวนคำสั่ง/ข้อความจาก walkthrough เดิมและทดสอบ burst/reconnect ที่ควบคุมในสภาพแวดล้อมเฉพาะ ไม่ส่ง load ไปเว็บความรู้จริง เก็บ requests, DO duration/storage rows, D1 reads/writes, R2 storage/operations, retries และ latency p50/p95 จากผลจริง

คำนวณค่าใช้จ่ายจากปริมาณที่วัด × อัตราปัจจุบันของแผนบัญชี แล้วระบุค่ารวม/สมมติฐาน/วันอัตราราคา; ไม่อ้างว่าบัญชีเดิมฟรีหรือรองรับเพียงพอ Owner กำหนดวงเงินก่อน provision ใช้ application caps จำกัดห้อง สมาชิก payload/retries และระยะทดลอง การแจ้งเตือน billing ไม่ถือเป็น hard spending cap โดยไม่มีหลักฐานจากบัญชี

หยุดทันทีเมื่อพบ cross-role leakage, duplicate business effect, stale command ถูกยอมรับ, stopped ทั้งที่ ACK ไม่ครบ, recovery digest mismatch หรือเกิน caps ที่กำหนด แสดงผล FAILED และเก็บหลักฐานขั้นต่ำตามสิทธิ์ ห้ามแก้ผลย้อนหลังให้เป็น PASS

## การแยก deployment และเก็บหลักฐาน

เว็บความรู้ drone-hub เดิมคงเป็น static deployment ส่วน runtime ทดสอบแยก Worker/namespace/bindings และ protected test route ที่ตรวจแล้วในบัญชีเดิม ไม่วางข้อมูลบทบาทใน static assets ไม่มี wildcard route ทับ /knowledge/ หรือ /sim/ ก่อนพิสูจน์ routing/fallback/auth แยก dev/test/production ด้วย object IDs ที่รวม environment/exercise/session/node และห้าม remote binding ใน local tests

P3-04 ต้องบันทึก source SHA, Wrangler/compatibility version, environment, deployment ID, grant revision, package digest, test IDs, expected/actual, owner sequences, projection watermarks, stop ACK และ fixture digests เก็บหลักฐานดิบในที่ส่วนตัว รายงานสาธารณะเฉพาะข้อมูลสังเคราะห์ที่ตรวจแล้ว ไม่มี cookie/JWT/keys/emails หรือข้อมูลผู้ประสบภัย CSV นี้เป็นแบบบันทึก ไม่ใช่ผลทดสอบ

## สิ่งที่ยังต้องยืนยัน

- วิธีเข้าสู่ระบบ/issuer/audience: เสนอ Access + JWT validation และ app membership แต่ยังไม่เลือกใช้งานจริง
- กติกา revocation, retention, วงเงิน และขอบเขตบัญชีทดสอบ: รอกำหนดและตรวจสิทธิ์จริง
- ผู้ร่วมซักซ้อม วันซักซ้อม และผู้บันทึกข้อค้นพบเฟส 2: รอยืนยัน
- การตรวจแผนที่/ห้วงอากาศจริงและ CrisisLink: เป็น gate แยก ไม่อยู่ในผลตรวจชุดนี้