สัญญาการแยกตัว

“แบ็กเอนด์แบบ standalone” หมายถึงอะไร ทีละบรรทัด พร้อมสิ่งใน repository ที่บังคับใช้แต่ละบรรทัด ไม่มีบรรทัดใดปรากฏที่นี่โดยไม่มีหลักฐาน บรรทัดที่มีเพียงหลักฐานแบบ local จะระบุไว้เช่นนั้น — หลักฐานจากการ deploy จริงเป็นเกณฑ์แยกต่างหาก (SPEC.md §11 R4)

เป็นหลักฐาน ไม่ใช่ดัชนีสถานะ เกณฑ์รีลีสสำหรับหลักฐานจากการ deploy คือ SPEC.md §11 R4.8 (การซ้อมการแยกตัว) และ R4.9 (ตัวเลขประสิทธิภาพ)

สัญญา

บรรทัดของสัญญา	บังคับใช้โดย	ระดับหลักฐาน
ผู้รับไปดูแล (adopter) เป็นเจ้าของ repository	wire flow scripts/github.ts; artifact ถูกรับไปไว้ในไดเรกทอรีปลายทางที่ผู้ดูแลระบบ (operator) ระบุ	local
adopter เป็นเจ้าของฐานข้อมูล	graduate/target.ts และ graduate/migrate.ts เขียนเฉพาะฐานข้อมูลปลายทางเท่านั้น; scripts/d1-provision.ts สร้าง D1 ของ adopter	local
adopter เป็นเจ้าของการ deploy และ credential	wrangler.example.jsonc ที่ถูกสร้างออกมา, scripts/configure-deployment.mjs; bearer token ถูกอ่านจาก environment ของ adopter (API_BEARER_TOKEN)	local
Prisma schema ที่ normalize แล้ว มีตารางและ index จริง	graduate/schema.ts, packages/eav-to-prisma; backend/test/graduate-generator.test.ts	local
migration ที่ตรวจทานได้และต่อท้ายได้อย่างเดียว (append-only)	graduate/migrate.ts, graduate/lineage.ts, scripts/emit-migration.mjs ที่ถูกสร้างออกมา; backend/test/graduate-adoption.test.ts “regenerates after a schema change, appending to the migration lineage”	local
route ที่สร้างขึ้นซึ่งมี semantics ของ model/query แบบ Prisma ที่คุ้นเคย	packages/prisma-generator-express (เป้าหมาย Hono); backend/test/artifact-two-version-transition.test.ts boot artifact และเรียก route ของมัน	local
ไม่มีการเรียก Dee Wan ขณะ runtime	backend/test/graduate-artifact-auth.test.ts, backend/test/graduate-no-callback.test.ts	local
ไม่พึ่งพา identity, availability หรือโครงสร้างพื้นฐานของ Dee Wan	สองเทสต์เดียวกัน: auth ที่ถูกสร้างออกมาอ่าน bearer token หนึ่งตัวจาก environment ของตัวเอง	local; หลักฐานจากการ deploy ยัง OPEN
โค้ดที่นักพัฒนาเป็นเจ้าของยังคงอยู่หลังการสร้างใหม่ (regeneration)	graduate/zones.ts + backend/test/graduate-adoption.test.ts “keeps a developer’s own file across a schema change”; กฎสำหรับ adopter อยู่ใน การขยายแบ็กเอนด์ของคุณ	local
ข้อมูล (DATA) ที่ adopter เป็นเจ้าของยังคงอยู่หลัง regeneration	backend/test/graduate-adoption.test.ts “keeps rows the adopter wrote into their own table across a schema change”	local
นักพัฒนาสามารถเลิกใช้ Dee Wan และพัฒนา repository ต่อไปได้	กฎของโซน รวมถึง scripts/regenerate.mjs และ scripts/emit-migration.mjs ที่ถูกสร้างออกมา ซึ่งรันได้โดยไม่ต้องใช้ CMS	local; ดู “การหยุดใช้” ด้านล่าง

สิ่งที่ยังไม่ได้พิสูจน์

• การซ้อมการแยกตัว (detach) บน commit ที่ระบุแน่นอนในสภาพแวดล้อมที่ deploy จริง แบ็กเอนด์ที่สร้างขึ้น ตอบคำขออ่านได้ในขณะที่ worker ของ Dee Wan ปิดอยู่ ต้องใช้อำนาจบน Cloudflare (SPEC.md §11 R0.2) สคริปต์และไฟล์หลักฐานอยู่ที่ scripts/detach-drill.ts และ docs/artifacts/detachment-evidence.md; ทั้งสองไฟล์ระบุไว้ชัดเจนเมื่อยังไม่มีการรัน
• ตัวเลขประสิทธิภาพ ยังไม่มี benchmark ใดถูกรัน ดู docs/PERFORMANCE-EVIDENCE.md จนกว่าไฟล์นั้นจะมีผลการรัน จะไม่มีการอ้างเรื่องความเร็วใดๆ

สองเรื่องที่ adopter ต้องรู้

ตารางเนื้อหาที่สร้างขึ้นเป็นของการรัน migration จะตรวจสอบเป้าหมาย เทียบกับแผน และจะปฏิเสธ (observed_row_set_mismatch) เมื่อพบแถวในตารางที่สร้างขึ้น ซึ่ง CMS ไม่ได้เผยแพร่ การปฏิเสธนั้นคือการรับประกันว่า แบ็กเอนด์ที่ deploy แล้วให้บริการสิ่งที่ CMS บอกว่ามันให้บริการ เขียนข้อมูลของคุณเองลงใน ตารางของคุณเอง — นั่นคือสิ่งที่ src/owned/ และ migration ของคุณเองมีไว้

การทำให้ฟิลด์ที่มีอยู่แล้วเป็นฟิลด์บังคับไม่ได้มาฟรี การสร้างตารางใหม่จะล้มเหลวกับ แถวที่มีค่า NULL และการรันจะปฏิเสธแทนที่จะทำลายข้อมูล ให้ backfill ก่อน แล้วจึงทำให้ฟิลด์นั้นเป็นฟิลด์บังคับ

การหยุดใช้

การแยกตัวเป็นผลลัพธ์ที่รองรับ ไม่ใช่ทางออกฉุกเฉิน adopter ลบ webhook เลิกกด Deploy และเก็บ repository ไว้

สิ่งที่ยังทำงานต่อไป:

• worker ที่ deploy แล้วและฐานข้อมูลของมัน
• ทุก route ที่สร้างไว้แล้ว
• migration lineage ที่ apply ไปแล้ว
• โค้ดของพวกเขาเองใต้ src/owned/ และตารางของพวกเขาเอง
• prisma migrate deploy, wrangler deploy, CI ของพวกเขา

สิ่งที่หยุด:

• regeneration จากโมเดลใน CMS (จะไม่มีนิยามโมเดลใหม่เข้ามา)
• การคัดลอกเนื้อหา CMS ที่เพิ่งเผยแพร่
• พื้นผิวสำหรับการเขียนเนื้อหา: CMS คือที่ที่ใช้แก้ไขเนื้อหา

นับจากจุดนั้น schema จะพัฒนาต่อผ่าน Prisma migration ตามปกติใน repository ของ adopter ไฟล์ในโซน generated สามารถแก้ไขได้อย่างอิสระเมื่อ ไม่มีใคร regenerate อีกแล้ว — กฎของโซนมีผลเฉพาะในขณะที่ CMS ยังคงสร้างไฟล์ลงใน tree นั้น

สองพื้นผิว ไม่ใช่หนึ่ง

public API ของ CMS เป็นแบบ live: การเผยแพร่จะไปถึงมันทันที edge cache ของมัน ปิดอยู่โดยค่าเริ่มต้น (no-store); เมื่อเปิดใช้ caching การเผยแพร่จะ purge cache tag ของมัน แบ็กเอนด์ที่สร้างขึ้นเป็น RELEASE ของ schema และเนื้อหา: การเปลี่ยนแปลงใน CMS จะไปถึง มันได้ผ่าน regeneration และการ deploy ที่สั่งอย่างชัดแจ้งเท่านั้น มันไม่ได้ถูก ซิงก์อย่างต่อเนื่อง การซิงก์อย่างต่อเนื่องเป็นการตัดสินใจเชิงผลิตภัณฑ์แยกต่างหาก และยังไม่ได้สร้าง