ขอบเขตผลิตภัณฑ์ 1.0

สถานะ: Pre-MVP ยังไม่ได้ release อัปเดตล่าสุด: 2026-08-27

อ้างอิงจาก: โค้ดปัจจุบันใน repository, การทดสอบเฉพาะจุดในเครื่อง (local) และสเปกหลัก (canonical) ยังไม่มีบันทึกการยอมรับ (acceptance ledger) บน Cloudflare จริงที่ครบถ้วน หรือการยอมรับพอร์ตโฟลิโอสี่ไซต์ที่ได้รับอนุญาต SPEC.md §11 เป็นเจ้าของเกณฑ์การ release (release gate)

ผลิตภัณฑ์: headless CMS สำหรับกำหนดและดำเนินงานเนื้อหาแบบมีโครงสร้าง ซึ่งสามารถสร้าง แบ็กเอนด์แบบ standalone ที่ผู้รับไปดูแล (adopter) เป็นเจ้าของได้ Graduation ส่งออก Prisma schema ที่ normalize แล้ว, migration ที่ตรวจทานได้, route ที่สร้างขึ้นพร้อม semantics ของ model/query แบบ Prisma ที่คุ้นเคย และเนื้อหาที่เผยแพร่แล้ว ไปยัง repository, ฐานข้อมูล และ runtime ที่ adopter เป็นเจ้าของ แบ็กเอนด์ที่สร้างขึ้นอ่านตารางที่ normalize แล้ว และไม่มี runtime dependency กับ Dee Wan

Cloudflare คือแพลตฟอร์มปัจจุบัน Strapi คือ migration adapter ตัวแรก ทั้งสองอย่างไม่ได้กำหนด กลุ่มผู้ใช้ การนำเข้า (import) ช่วยเรื่องการนำไปใช้และการย้ายระบบได้ แต่ไม่ใช่แนวคิดหลักของผลิตภัณฑ์

แต่ละความสามารถอยู่ในรายการเดียว: สัญญา 1.0, pilot ภายใต้การกำกับดูแล หรือยังไม่มีให้ใช้ “ยังไม่มีให้ใช้” ไม่ใช่คำสัญญาว่าจะสร้าง

สัญญา 1.0 — สร้างแล้วและตรวจสอบในเครื่องแล้ว

การดำเนินงานด้านเนื้อหา

• โมเดลเนื้อหาและฟิลด์ที่กำหนดผ่าน UI: text, rich text, number, boolean, select, date, media, JSON, relation และ component
• การตรวจสอบ breaking change ก่อนนำนิยามโมเดลไปใช้
• เนื้อหาหลายภาษาพร้อมภาษาที่กำหนดค่าได้ และนโยบาย locale fallback
• snapshot ที่เผยแพร่แล้วซึ่งแก้ไขไม่ได้, ประวัติเวอร์ชัน, การกู้คืน และ publish/unpublish
• draft/publish โดยตรง และกลไก approval workflow ที่กำหนดค่าได้
• โหมด review ที่เลือกเปิดได้ ปิดไว้โดยค่าเริ่มต้นและตั้งค่าแยกต่อไซต์ แท็บ General settings มีสวิตช์นี้ PATCH /api/sites/:id จะปฏิเสธการปิดโหมดนี้ขณะที่ยังมีเนื้อหาอยู่ในสถานะ review และระบุชื่อ รายการเหล่านั้น เมื่อเปิดไว้ dashboard คือคิว review — แสดงสิ่งที่กำลังรอ, สิ่งที่ผู้เรียกนี้ทำได้ ต่อไป, แถวที่ผู้เรียกขยับไม่ได้กำลังรออะไรอยู่ และแยกต่างหากคือสิ่งที่ถูกส่งกลับ เมื่อปิดไว้ dashboard แสดงสิ่งที่เปลี่ยนแปลงล่าสุด ไม่มีนิยาม workflow ใดถูกเขียนใหม่ไม่ว่ากรณีใด ดังนั้นไซต์ ที่ปรับแต่ง workflow ไว้จะได้คืนมาโดยไม่เปลี่ยนแปลง
• การกู้คืนงานที่ยังไม่บันทึก สำหรับการแก้ไขเนื้อหาทั่วไป และ (AND) page composer การแก้ไขจะถูกเขียนลง storage ภายในเบราว์เซอร์ โดยผูกกับ baseline ของเซิร์ฟเวอร์ที่ใช้ตอนเริ่มแก้ไข และจะเสนอให้กู้คืนเฉพาะเมื่อเทียบกับ baseline เดียวกันนั้นเท่านั้น ดังนั้น การกู้คืนจะไม่เขียนทับสิ่งที่คนอื่นบันทึกไว้แบบเงียบ ๆ เด็ดขาด ครอบคลุมแท็บที่ crash, การ reload และ process ที่ถูกเรียกคืน ส่วน leave guard ภายในแอปครอบคลุมการนำทางออกโดยตั้งใจ ใน composer baseline คือ version id ปัจจุบันของหน้า และงานที่เก็บไว้รวมถึง PROPOSAL ที่ยังไม่ได้นำไปใช้ (UNAPPLIED PROPOSAL) — สิ่งเดียวบนหน้าจอนั้นที่มีต้นทุนเป็นการเรียก provider และผลิตภัณฑ์จงใจไม่เขียน version ให้ เก็บในเบราว์เซอร์และแยกต่ออุปกรณ์: ไม่ใช่ความต่อเนื่องของ draft ข้ามอุปกรณ์ที่มีเซิร์ฟเวอร์รองรับ
• component ที่ไซต์เป็นเจ้าของ พร้อม shared library ที่เลือกใช้ได้ เมื่อตั้งค่า component.site_id หมายความว่าไซต์หนึ่ง เป็นเจ้าของ และ model:apply บนไซต์นั้นก็เพียงพอ ส่วน NULL หมายถึง shared library ซึ่งทุกไซต์ อ่านได้และมีเพียง superadmin ที่เขียนได้ ความไม่ซ้ำกันนับแยกต่อเจ้าของ ดังนั้นสองไซต์อาจต่างก็เป็นเจ้าของ hero ของตัวเองได้ ไซต์หนึ่งอาจ FORK component ที่ใช้ร่วมกันมาไว้ในไซต์ของตัวเอง fork คือการ OVERRIDE ทั้งไซต์ (SITE-WIDE OVERRIDE): ไม่เขียน แถวใดใหม่ และทุกฟิลด์บนไซต์นั้นที่อ้างถึง slug อยู่แล้วจะ resolve ไปยัง fork หลังจากนั้น route จะคืนจำนวนการอ้างอิงที่ถูกเปลี่ยนเป้าหมาย และ UI จะแจ้งผลที่ตามมาก่อน การคลิก การสร้างแบบปกติที่จะไปตรงกับ slug ที่ใช้ร่วมกันจะถูกปฏิเสธ (REFUSED) จนกว่าผู้เรียกจะ รับทราบการ override SLUG ของ component แก้ไขไม่ได้ (IMMUTABLE) หลังสร้าง — เพราะเป็นวิธีที่ทุก ฟิลด์, component ที่ซ้อนกัน และ preset อ้างถึงมัน และไม่มีที่ใดเก็บ id ไว้ ดังนั้นการเปลี่ยนชื่อจะ ชี้ใหม่หรือทำให้ทุกการอ้างอิงกำพร้าแบบเงียบ ๆ ส่วนชื่อยังแก้ไขได้ คำเตือนเรื่อง fork และ delete guard นับการอ้างอิงจากทั้ง (BOTH) ฟิลด์ของโมเดลและนิยามของ component อื่น component ถูกอ้างถึงด้วย SLUG (BY SLUG) ตลอดทั้งระบบ ดังนั้น component ที่ไซต์เป็นเจ้าของจะบัง (SHADOWS) component ที่ใช้ร่วมกันซึ่งมี slug เดียวกัน — ชุด component ที่ไซต์มองเห็นมี slug ไม่ซ้ำกัน และการอ้างอิงที่ถูกบังจะไม่นับรวม กับ component ที่ใช้ร่วมกันเมื่อ component นั้นถูกลบ การนำนิยาม component ที่นำเข้ามาไปใช้ไม่ถูกบล็อกแล้วใน ระดับ schema และการอนุญาต ส่วน importer ที่เขียนนิยามเหล่านั้นยังไม่ได้สร้าง (NOT built) และความถูกต้องครบถ้วนของ component ยังไม่ได้แสดงให้เห็น
• บทบาท (role) ต่อไซต์ และสิทธิ์ที่จำกัดตามเจ้าของ
• การประกอบหน้าเป็นเอกสารแบบมีโครงสร้างที่ไม่ผูกกับ framework ใด revision ใช้การจัดการเวอร์ชันปกติ, กฎการเผยแพร่ และการ rollback นี่คือสัญญาด้านเนื้อหา ไม่ใช่ตัว render เว็บไซต์

การส่งมอบแบ็กเอนด์ที่แยกตัวได้ (หลัก)

• GET /api/models/public-client.ts ที่ต้องยืนยันตัวตนจะส่งออก TypeScript client ที่ไม่มี dependency สำหรับ ไซต์หนึ่ง: ฟิลด์ของโมเดลที่แน่นอน, locale union, query type, response envelope และ method ของโมเดล
• client ที่สร้างขึ้นต้องสร้างใหม่ด้วยตนเองหลังโมเดลเปลี่ยน ไม่มีการตรวจจับ drift อัตโนมัติ หรือการจัดการเวอร์ชันของ artifact
• Graduation ส่งออกแบ็กเอนด์ที่มี type ซึ่ง adopter เป็นเจ้าของ และ snapshot ของเนื้อหาที่เผยแพร่ ณ เวลาที่สร้าง runtime ที่สร้างขึ้นแยกตัวจาก Dee Wan และใช้ bearer token ของตัวเอง
• workflow การสร้างใหม่ (regeneration) ที่ CMS จัดการเป็นแบบประสานงาน: ดึงนิยามและรายงานผล กลับไปยัง Dee Wan อำนาจของ runtime และการประสานงาน build แยกจากกัน

Tenancy และตัวตน

• หลายไซต์ใน installation (การติดตั้ง Dee Wan หนึ่งชุด) เดียว โดยมีขอบเขตไซต์ที่ระบุชัดเจน ผู้เรียกไม่สามารถอนุมาน tenant หรือ เลือก database binding ได้
• การแยกเชิงตรรกะในฐานข้อมูล bootstrap ที่ใช้ร่วมกัน
• session ฐานข้อมูลของ Better Auth, bootstrap claim, ความเป็นเจ้าของรหัสผ่าน, การกู้คืน, การเพิกถอน, การล็อกบัญชี และการจำกัด request
• perimeter ของ Cloudflare Access ที่เลือกเปิดได้ ปิดไว้โดยค่าเริ่มต้น
• บัญชีที่มีอยู่แล้วสามารถรับ grant ต่อไซต์ได้ ยังไม่มีระบบคำเชิญ

การอ่านแบบสาธารณะ

• public-read Worker ที่แยกต่างหาก การระบุไซต์ใช้ Host ไม่ใช้ site ID ที่ผู้เรียกส่งมาเด็ดขาด
• การอ่าน snapshot ที่เผยแพร่แล้ว, นโยบาย locale แบบ strict หรือ fallback, การแบ่งหน้าด้วย cursor, ตัวกรอง relation/tag และการ purge cache tag เมื่อเผยแพร่
• โมเดลสาธารณะไม่ต้องใช้ token โมเดลแบบ private ใช้ read token ที่มีขอบเขตระดับไซต์ และไม่เข้าไปอยู่ใน cache ที่ใช้ร่วมกัน
• D1 binding ของ Worker เป็นแบบอ่านอย่างเดียวตามกฎการ review โค้ด D1 ไม่มีการตั้งค่า binding แบบอ่านอย่างเดียว

Media และ AI

• storage แบบ R2 หรือ Cloudflare Images พร้อมการแปลงเป็น WebP/AVIF
• การสร้างข้อความ การแปล และการสร้างภาพ ผ่าน proxy ฝั่งเซิร์ฟเวอร์ไปยัง DeepInfra key ของ provider ไม่ไปถึงเบราว์เซอร์
• โควตารายชั่วโมงต่อไซต์ ไม่รองรับ inference provider เพิ่มเติม

การย้ายระบบและ migration adapter

• site bundle ของ Dee Wan ที่ย้ายได้ และการถ่ายโอนเนื้อหาแบบ CSV/XLSX
• adapter ภายนอกตัวแรก: การตรวจสอบ archive ของ Strapi v4/v5, การ mapping partition อย่างชัดเจน, dry run, การทำต่อ (resume), การรันซ้ำที่ให้ผลเหมือนเดิม, receipt, แถวที่มีปัญหา, manifest และ undo ที่มีการป้องกัน
• ความเป็นเจ้าของต้นทางที่กำกวมจะบล็อก dry run importer ไม่เดาจากชื่อ, slug หรือ URL
• fixture จากพอร์ตโฟลิโอจริง, ข้อจำกัดของ Worker ที่ deploy แล้ว และหลักฐาน cutover/rollback ยังเป็นงาน acceptance ที่เหลืออยู่

การดำเนินงาน

• การวางแผนติดตั้งผ่าน CLI, apply/resume, การวินิจฉัย, การตรวจสอบ, manifest และ teardown แบบ dry-run

• ตัวติดตั้ง (installer) บนเบราว์เซอร์ในเครื่อง สำหรับนักพัฒนาที่มี Node, checkout และ terminal อยู่แล้ว

• ประวัติการ deploy และการปฏิเสธ rollback หลัง migration ที่ทำลายข้อมูล

• การกำหนดค่า outbound webhook, ประวัติการส่งที่มีลายเซ็น, การหมุนเวียน secret และการส่งซ้ำด้วยตนเอง

• รายงานข้อผิดพลาด error ที่ไม่ได้ถูกจัดการจะถูกส่งไปยังโปรเจกต์ Sentry ของ Dee Wan โดยลบเนื้อหา, ค่าในฟอร์ม, อีเมล และ credential ออกก่อน superadmin ปิดการส่งได้สำหรับทั้ง deployment ที่ Settings → Integrations → Error reports ตัวแปร Worker DEEWAN_ERROR_REPORTING=off ก็ให้ผลเช่นเดียวกัน

  

• การลองส่งซ้ำอัตโนมัติแบบมีขอบเขตสำหรับ outbound webhook การส่งที่ล้มเหลวด้วยเหตุผลที่อาจ ผ่านได้ในภายหลัง — ไม่มีการตอบ, 408, 429, 5xx ใด ๆ — จะถูกลองซ้ำตามตารางเวลาแบบ exponential ที่มี jitter สูงสุดห้าครั้ง โดยเคารพ Retry-After ส่วนการปฏิเสธที่ผู้รับ (subscriber) จะตอบซ้ำเหมือนเดิมถือเป็นจุดสิ้นสุด ทันที ทุกครั้งที่ลองส่งใช้ event id เดียวกัน ดังนั้นรายการซ้ำที่เกิดจาก timeout จะเป็นสิ่งที่ consumer จดจำได้ ครั้งที่รอส่งได้รับการยกเว้นจากเพดานของประวัติการส่ง และการลองซ้ำ ส่งไบต์ที่บันทึกไว้ตรงตามเดิมทุกไบต์ โดยลงลายเซ็นด้วย secret ปัจจุบัน (CURRENT) ของ subscriber ครอบคลุมเฉพาะในเครื่อง ไม่มีหลักฐานจากการ deploy

• Rich text คือ HTML จากผู้เขียนที่เชื่อถือได้ และตัว RENDER ต้อง SANITISE มัน type ที่สร้างขึ้นคือ Html — ไม่ใช่ SafeHtml และไม่ใช่ Json แบบทั่วไปเด็ดขาด — เพราะไม่มีสิ่งใดในผลิตภัณฑ์นี้ sanitise หรือ เขียน markup ที่จัดเก็บไว้ใหม่ มีสองสิ่งที่ถูกบังคับใช้ (ARE enforced) ที่ขอบเขตการเขียนจุดเดียว: ค่าต้องเป็น STRING (ค่าที่ไม่ใช่ string จะได้ 400 แบบมีโครงสร้างที่ระบุชื่อฟิลด์และ type ที่ได้รับ ไม่ใช่ [object Object] ที่ถูกแปลงเป็น string) และต้องมีขนาดไม่เกิน 256 KiB ของ UTF-8 นับเป็นไบต์ สิ่งใดก็ตาม ที่ผู้เขียนที่ได้รับอนุญาตหรือการสร้างด้วย AI ผลิตขึ้นจะถูกเผยแพร่ตามที่เขียนไว้ ดังนั้น consumer ที่ แทรกมันลงในหน้าโดยไม่ sanitise คือผู้ที่รับความเสี่ยงเอง

• พื้นที่ Delivery หนึ่งเดียว (Settings → Delivery) CMS read API ที่ใช้งานจริงและแบ็กเอนด์ที่ graduate แล้ว ถูกนำเสนอเป็นสัญญาสองฉบับที่แตกต่างกัน (DIFFERENT) โดยระบุความแตกต่างด้าน route, การยืนยันตัวตน, envelope, deployment, rollback และการพึ่งพา CMS ก่อนการ cutover มันรายงานสถานะ ยังไม่เคยสร้าง, ปัจจุบัน, drift, กำลัง build, build/deployment ล้มเหลว และแยกตัวแล้ว และรายการ revision เก็บ การปฏิเสธ rollback แยกต่อ revision ของตัวเอง ครอบคลุมเฉพาะในเครื่อง ไม่มีหลักฐานจากการ deploy

• เวอร์ชันของ artifact ที่สร้างขึ้นและ drift ของสัญญา ตัวตนของ artifact คือเวอร์ชันของ generator รวมกับ digest แบบ deterministic ของสัญญาขาเข้า — ไม่ใช่ timestamp เด็ดขาด — ดังนั้นไซต์ที่ไม่เปลี่ยนแปลง แต่ถูก build ใหม่ด้วย generator ที่เปลี่ยนไปจะถูกรายงานว่า drift แทนที่จะเป็นปัจจุบัน deployment ที่ ไม่ได้บันทึกเวอร์ชันของ generator จะถูกอ่านว่า drift ไม่ใช่ว่าตรงกัน การสร้างใหม่ยังคงต้องสั่งอย่างชัดเจน: ไม่มีสิ่งใดสร้างใหม่หรือ deploy เอง

• audit ledger สำหรับงานบริหาร ใครเปลี่ยนโมเดล, component, บทบาท, grant, site token, การตั้งค่า, โครงสร้างพื้นฐาน, hostname หรือใคร deploy และ rollback — บันทึกไว้ใน control plane แบ่ง partition ตามไซต์ ในรูปของ intent ที่เขียนก่อน (BEFORE) การกระทำ และผลลัพธ์ที่เขียน หลังจากนั้น เชื่อมกันด้วย operation id เดียว การกระทำจะไม่ทำงานหากเขียน intent ไม่ได้ หาก เขียนผลลัพธ์ไม่ได้ intent จะถูกเก็บไว้และผลจะถูกอ่านเป็น UNKNOWN แทนที่จะเป็น สำเร็จ การอ่านมีจุดเดียวซึ่งอยู่หลังสิทธิ์ audit:read ของตัวเอง ที่ Settings → History เพิ่มต่อท้ายได้อย่างเดียว: ไม่มี route สำหรับเขียน นี่ไม่ใช่ telemetry — ไม่มี counter, ไม่มี aggregate, ไม่มี dashboard

Pilot ภายใต้การกำกับดูแล — สร้างในเครื่องแล้ว แต่หลักฐานภายนอกยังไม่ครบ

• content D1 ต่อไซต์ control D1 หนึ่งตัวบวก content D1 หนึ่งตัวต่อไซต์คือ topology ที่เลือกไว้ การแยก schema, routing, provisioning, การกระจาย migration, backup/restore และ teardown ได้รับการตรวจสอบ ในเครื่องแล้ว ยังไม่มีหลักฐานบน Cloudflare จริง, ด้านความจุ, backup/restore และการแยกสี่ไซต์
• deployment ของ graduation ที่ขับเคลื่อนโดย CMS claim, build token, workflow ของ repository ที่สร้างขึ้น, ลำดับสายของ migration, การรายงานกลับ และการควบคุม rollback ได้รับการตรวจสอบในเครื่องแล้ว ยังไม่มี GitHub Actions ร่วมกับ deployment บน Cloudflare ที่เก็บไว้เป็นหลักฐานพิสูจน์ loop ทั้งหมด
• เส้นทางตัวติดตั้งที่สมบูรณ์ admin Worker และ UI ทำตามเส้นทาง setup ปกติ setup ยัง เขียน (WRITES) backend/wrangler.public.jsonc ด้วย ณ จุดที่บัญชี, zone และ database id ถูกกำหนดครบแล้ว มันไม่เขียนทับไฟล์ที่มีอยู่เด็ดขาด และจะปฏิเสธโดยระบุชื่อ (REFUSES BY NAME) แทนที่จะ เดาค่าที่มันหาไม่ได้ การเตรียมไฟล์เองจากตัวอย่างคือทางสำรองสำหรับการ ปฏิเสธนั้น ไม่ใช่เส้นทางปกติ หากไม่มีไฟล์นี้ deploy จะปฏิเสธ (REFUSES) แทนที่จะข้ามไป: installation ที่จงใจไม่ให้บริการเนื้อหาสาธารณะจะระบุเช่นนั้นด้วย --admin-only และการรันนั้นจะถูก รายงานว่าเป็น admin-only แทนที่จะเป็นสมบูรณ์ ไม่มีการข้ามแบบเงียบ ๆ และไม่มีการ fallback ไปใช้ public config ของ installation อื่น สิ่งที่ยังค้างอยู่คือหลักฐานจากการ deploy ไม่ใช่ตัวไฟล์
• Preview routing API เก็บ origin ของตัว render แบบ HTTPS และ route template ต่อโมเดล และ editor จะเปิด URL ที่ render แล้วซึ่งถูกส่งกลับมา Settings → Preview อ่านและเขียนสัญญานั้น แจ้ง ว่าปุ่ม Preview ของไซต์ที่ยังไม่ได้กำหนดค่าทำอะไร และระบุชื่อการปฏิเสธแต่ละแบบ หากไม่ได้กำหนดค่า ตัว render ไว้ Preview จะเปิด JSON response ของ public API และหน้าจอจะแจ้งเช่นนั้น
• Remote plugin protocol v1 (ฝั่ง core) การติดตั้งจาก HTTPS manifest พร้อม grant ของ capability และ โมเดลที่เลือกด้วยมือ, installation token ที่ถูก hash และหมุนเวียนได้, disable/enable/uninstall, delegated launch แบบใช้ครั้งเดียว, การอ่านเนื้อหาแบบมีขอบเขต และคำสั่ง publish/unpublish ที่ปักหมุดไว้ (SPEC-PLUGINS.md) คำสั่งนี้อ่านอำนาจของผู้มอบ delegation ใหม่อีกครั้ง ณ ตอนดำเนินการ, มีผล ไม่เกินหนึ่งครั้งต่อ idempotency key และ workflow revision, เผยแพร่ทั้ง translation group และ ตอบทุกการปฏิเสธด้วย terminal code ที่มีชื่อ ครอบคลุมเฉพาะในเครื่อง ไม่มีหลักฐานจากการ deploy
• Backup และ restore สร้างและตรวจสอบกับ SQLite ในเครื่องแล้ว ยังไม่ได้ตรวจสอบกับ D1 จริง
• การย้ายระบบ Strapi สี่ไซต์ เส้นทาง adapter แบบทั่วไปมีอยู่แล้ว แต่ archive ที่ได้รับอนุญาต, สัญญาของ consumer, partition ที่ตรวจทานแล้ว, staging, หลักฐาน cutover และ rollback ยังไม่มี

ภายหลัง / ยังไม่มีให้ใช้ — ยังไม่ได้สร้างหรือถูกปิดไว้

• ตัว render อ้างอิงสำหรับ production, starter theme และเส้นทางการส่งมอบ SEO/sitemap/redirect ที่สมบูรณ์
• ตัวติดตั้งที่ไม่ต้องใช้ terminal เลย หรือ Cloudflare OAuth application ที่ลงทะเบียนไว้
• GitHub App การเชื่อมต่อ repository ในปัจจุบันใช้ device flow
• ระบบคำเชิญ ทั้งหมด กลไกลิงก์ที่ไม่ได้ใช้งานอยู่ถูกซ่อนไว้หลัง ENABLE_INVITATIONS การกำหนดค่า ที่ติดตามใน repository ไม่ได้ตั้งค่านี้ และทุก route ของคำเชิญตอบ 404 ยังไม่มีการส่งอีเมลที่ตรวจสอบแล้ว หรือ ขั้นตอนพิสูจน์ที่อยู่อีเมล
• การดำเนินการแบบกลุ่ม, มุมมองที่บันทึกไว้ และการ release เนื้อหาแบบประสานงาน
• การ crop media, focal point และการจัดการไฟล์ซ้ำ การค้นหา (SEARCH) media และการกรอง alt-text สร้างแล้ว
• การมอบหมาย review, ความคิดเห็น และการแจ้งเตือน
• การเข้าคิว webhook ที่เกินกว่าการลองซ้ำแบบมีขอบเขตข้างต้น และการรับประกันการส่งใด ๆ ที่แข็งแรงกว่า at-least-once
• การ synchronize ต่อเนื่องจาก CMS ไปยังฐานข้อมูลที่ graduate แล้ว
• การแก้ไขแบบคัดลอกตรงตัวหรือแบบล็อกส่วนใน page composer
• การ shard ฐานข้อมูลระดับโมเดล
• Enterprise SSO, MFA และ passkey
• การเผยแพร่และยกเลิกการเผยแพร่ตามกำหนดเวลาใน core การตั้งเวลาเป็นปลั๊กอิน Scheduling ที่แยกต่างหาก (plugins/scheduling/) และยังไม่ได้ deploy

ความจริงของการส่งมอบ

Dee Wan มีช่องทางการส่งมอบสำหรับนักพัฒนาสองช่องทาง:

1. CMS public API ใช้งานจริงอยู่ การเผยแพร่จะอัปเดตการอ่าน snapshot ทันทีและ purge cache tag
2. แบ็กเอนด์ที่ graduate แล้วคือ release ของ schema และเนื้อหา มันมีสิ่งที่เผยแพร่ไว้ ณ ตอนที่ การสร้างทำงาน การเผยแพร่ใน CMS ภายหลังจะไปถึงมันก็ต่อเมื่อมีการ graduate ใหม่และ deploy ใหม่อย่างชัดเจนเท่านั้น

อย่าอธิบาย graduation ว่าเป็น live feed อย่าอธิบาย test coverage ในเครื่องว่าเป็น release การอ้างสถานะ 1.0 ครั้งแรกต้องให้ทุกเกณฑ์ภายนอกและเกณฑ์สุดท้ายที่ยังเปิดอยู่ใน SPEC.md §11 ผ่านบน commit เดียวที่ระบุแน่นอน