สถานะแผน

เวอร์ชัน 5.0.0. สถานะ: เสถียร เอกสารนี้ระบุชั้นสถานะแผนที่เครื่องอ่านได้ของระเบียบวิธี Deep Work Plan ซึ่งตอนนี้ปรับให้สอดคล้องกับเวอร์ชันของมาตรฐาน DWP เอง — ไม่มีข้อกำหนดเดิมใดถูกทำให้อ่อนลงจากการเปลี่ยนหมายเลขนี้ ฉบับแก้ไขนี้ยังบันทึกเรื่องตัวอัปเดตสถานะที่มีการป้องกัน การเผยแพร่แผนที่ผ่านการตรวจสอบ และกฎความจริงของหลักฐานที่แผนที่เสร็จสมบูรณ์ต้องปฏิบัติตาม (ดูด้านล่าง) คำสำคัญ MUST, MUST NOT, SHOULD, SHOULD NOT และ MAY ให้ตีความตามที่อธิบายไว้ใน RFC 2119

สิ่งประดิษฐ์ JSON สองชิ้น — manifest.json (เอกลักษณ์คงที่ของแผน) และ state.json (สถานะการดำเนินงานต่อหนึ่งงานแบบสด รวมถึงผลลัพธ์ validation gate) — ที่ทุกแผน MAY พกไว้ร่วมกับไฟล์ markdown และที่การดำเนินงานแบบไม่มีผู้ดูแล (ดู โปรโตคอลของเอเจนต์) และ workspace ที่ไม่มี git (ดู Archetype §3) MUST พก

แผน markdown ยังคงเป็น แหล่งความจริงที่มนุษย์อ่านได้ ชั้น JSON เป็น การฉายภาพที่ได้รับมา: มันถูกสร้างใหม่โดยเอเจนต์ที่จุดโปรโตคอลที่กำหนด ไม่เคยถูกแก้ไขด้วยมือ และไม่เคยถูกปล่อยให้ขัดแย้งกับ markdown อย่างเงียบ ๆ จุดประสงค์ของมันคือความสามารถในการทำงานร่วมกัน — การ lint การตรวจสอบความสอดคล้อง การ diff การแสดงผล การค้นพบ registry และการซิงโครไนซ์กับโครงสร้างพื้นฐาน session ภายนอก — ไม่มีสิ่งใดที่สามารถสร้างได้อย่างน่าเชื่อถือบนข้อความธรรมดา

เหตุผลที่มีอยู่

จนถึง v1.1 แผนเป็นเพียง markdown ธรรมดา นั่นทำให้มันตรวจสอบได้และไม่ขึ้นกับเอเจนต์ แต่ไม่มีสิ่งใดที่เครื่องมือจะตรวจสอบ diff หรือใช้งานได้: ไม่มี gate ความสอดคล้อง ไม่มีการตรวจจับการเบี่ยงเบนระหว่าง README.md และ PROGRESS.md ไม่มีทางที่ daemon หรือ cloud session จะรู้สถานะของแผนโดยไม่ต้องแยกวิเคราะห์ข้อความธรรมดา v1.2 เพิ่มการฉายภาพ JSON โดยไม่ลดความสำคัญของ markdown — การฉายภาพได้รับมาจาก markdown ในลักษณะเดียวกับที่ lockfile ได้รับมาจาก manifest

การจัดวาง

แผนที่ใช้ชั้นสถานะมีโครงร่างนี้

.dwp/plans/PLAN_{name}/
├── README.md            ← แหล่งความจริงของมนุษย์ (ไม่เปลี่ยนแปลง)
├── PROGRESS.md          ← log เชิงบรรยาย (ไม่เปลี่ยนแปลง)
├── PROMPTS.md           ← ไม่เปลี่ยนแปลง
├── manifest.json        ← เอกลักษณ์คงที่ (เขียนตอน materialization)
├── state.json           ← สถานะสด (เขียนใหม่ที่จุดโปรโตคอล)
├── analysis_results/
└── {N}.task_{...}.md

manifest.json MUST ถูกเขียนหนึ่งครั้งเท่านั้น เมื่อ flow create ทำให้แผนเป็นรูปธรรม และ MUST NOT เปลี่ยนแปลงหลังจากนั้น ยกเว้นการย้ายเวอร์ชัน spec ที่บันทึกไว้ใน PROGRESS.md

state.json MUST ถูกเขียนใหม่โดยเอเจนต์ที่แต่ละจุดโปรโตคอลเหล่านี้: plan materialization (งานทั้งหมดเป็น pending), การเริ่มงาน (in_progress), แต่ละการรัน validation gate (บันทึก gate ถูกเพิ่มหรืออัปเดต), การเสร็จสิ้นงาน (completed ซึ่งเป็นส่วนหนึ่งของโปรโตคอลการเสร็จสิ้นงานใน ข้อกำหนด DWP), จุด checkpoint ก่อนการหยุดพักที่วางแผนไว้ใด ๆ และการหยุด blocked

ไฟล์ทั้งสองชิ้น MUST ถูกเขียนแบบ atomic: เขียนไปยังไฟล์ชั่วคราวในไดเรกทอรีเดียวกัน แล้วเปลี่ยนชื่อทับไฟล์เป้าหมาย การเขียนที่ขัดจังหวะ MUST NOT ทิ้งไฟล์ JSON ที่ตัดทอนไว้

เมื่อใดที่ชั้นนี้จำเป็น

• สำหรับการดำเนินงานแบบโต้ตอบใน git repository ชั้นสถานะ RECOMMENDED สำหรับแผนใหม่และ OPTIONAL สำหรับแผนก่อน v1.2 แผนที่ไม่มีมันยังคงสอดคล้อง
• สำหรับการดำเนินงานแบบไม่มีผู้ดูแล ชั้นสถานะ REQUIRED
• ในagent workspaceที่ไม่มี git ชั้นสถานะ REQUIRED: state.json พกข้อมูลการกู้คืนที่ git log พกใน repository

manifest.json — เอกลักษณ์แผน

{
  "schema": "https://deepworkplan.com/schema/plan-manifest/v2.json",
  "spec_version": "2.4.0",
  "name": "PLAN_payment_webhooks",
  "title": "Add payment webhook handling",
  "archetype": "individual",
  "rigor": "standard",
  "plan_format": "full",
  "created_at": "2026-06-09T14:00:00Z",
  "created_by": { "agent": "claude-code", "model": "claude-fable-5" },
  "tags": ["backend", "payments"],
  "task_count": 7,
  "parent_plan": null
}

schema, spec_version, name, archetype, rigor, created_at, task_count และ plan_format REQUIRED

archetype MUST เป็นหนึ่งใน individual, orchestrator-hub, agent-workspace

rigor MUST เป็นหนึ่งใน micro, standard, deep (ดู ความเข้มงวดตามสัดส่วน)

plan_format MUST เป็นหนึ่งใน lite, full — คือรูปแบบที่ถูกเลือกไว้ตอนสร้าง (ดู แผน Lite) มันเป็นค่าคงที่ในระดับ manifest: การเลื่อนขั้นจาก Lite เป็น Full ในภายหลังถูกบันทึกไว้ใน state.json ไม่ใช่ด้วยการเขียน manifest ใหม่

parent_plan เชื่อมแผนลูกกับแผน orchestrator ของมัน ({repo}:{plan_name} หรือ null)

created_by SHOULD ระบุเอเจนต์และโมเดลที่สร้าง มัน MUST NOT ประกอบด้วยความลับ token หรือตัวระบุผู้ใช้นอกเหนือจากชื่อที่แสดง

state.json — สถานะการดำเนินงานสด

{
  "schema": "https://deepworkplan.com/schema/plan-state/v2.json",
  "plan": "PLAN_payment_webhooks",
  "updated_at": "2026-06-09T16:42:10Z",
  "updated_by": { "agent": "claude-code", "model": "claude-fable-5" },
  "status": "in_progress",
  "completed_count": 2,
  "task_count": 7,
  "format": "full",
  "materialization": "ready",
  "approval": "approved",
  "promotion": null,
  "tasks": [
    {
      "id": 1,
      "locator": { "kind": "file", "value": "1.task_webhook_endpoint.md" },
      "title": "Create webhook endpoint",
      "status": "completed",
      "started_at": "2026-06-09T14:10:00Z",
      "completed_at": "2026-06-09T15:02:33Z",
      "commit": "a1b2c3d",
      "gates": [
        {
          "command": "pnpm run test",
          "passes": true,
          "exit_code": 0,
          "last_run": "2026-06-09T15:01:50Z",
          "evidence": "42 passed, 0 failed"
        }
      ],
      "outcome": {
        "tried": ["raw body parsing via middleware"],
        "failed": ["initial signature check used wrong header"],
        "worked": "verify signature against X-Sig header before JSON parse",
        "notes": "stripe-style HMAC; see analysis_results/webhook_notes.md"
      }
    },
    {
      "id": 3,
      "locator": { "kind": "file", "value": "3.task_retry_queue.md" },
      "title": "Add retry queue",
      "status": "in_progress",
      "started_at": "2026-06-09T16:30:00Z",
      "gates": []
    }
  ],
  "checkpoint": {
    "task": 3,
    "step": "instructions:4",
    "at": "2026-06-09T16:42:10Z",
    "note": "queue table migrated; worker loop not yet wired"
  },
  "blocked": null
}

รายการงานของแผน Lite ใช้ locator แบบ inline ที่ชี้ไปยัง anchor ของงานนั้นใน README.md แทนที่จะเป็นไฟล์แยกต่างหาก — ส่วนที่เหลือของรายการ (gate, ผลลัพธ์, สถานะ) ทำงานแบบเดียวกันทุกประการ:

{
  "format": "lite",
  "materialization": "ready",
  "approval": "pre_approved",
  "promotion": null,
  "tasks": [
    {
      "id": 2,
      "locator": { "kind": "inline", "value": "#task-2" },
      "title": "Add retry queue",
      "status": "pending",
      "gates": []
    }
  ]
}

format, materialization, approval และ promotion

format MUST เป็นหนึ่งใน lite, full และสะท้อน plan_format ของ manifest — แต่แก้ไขได้ที่นี่ ต่างจาก manifest เพราะแผน Lite MAY เลื่อนขั้นเป็น Full ในภายหลัง materialization MUST เป็นหนึ่งใน materializing (โฟลเดอร์แผนกำลังถูกเขียน), ready (materialization เสร็จสมบูรณ์) หรือ promoting (การเลื่อนขั้นจาก Lite เป็น Full กำลังดำเนินอยู่) approval MUST เป็นหนึ่งใน pending, approved, pre_approved มันเป็น OPTIONAL ใน schema นี้ เพื่อให้แผนที่เขียนขึ้นก่อนที่ฟิลด์นี้จะถูกบันทึกยังคงผ่านการตรวจสอบ — เมื่อมันไม่มีอยู่ ให้ถือว่าแถว Approval ของ README เป็นค่านั้น และเป็น pending เมื่อไม่มีทั้งสองอย่าง promotion เป็น null นอกช่วงการเลื่อนขั้น หรือเป็น object ที่บันทึกความตั้งใจและงานปลายทางของการเลื่อนขั้น ขณะที่ materialization เป็น promoting ดูวงจรชีวิตเต็มรูปแบบที่ฟิลด์เหล่านี้เข้ารหัสไว้ได้ที่ แผน Lite

รายการงาน

ทุกงาน — ไม่ว่าจะเป็นไฟล์แยกต่างหากในแผน Full หรือบันทึกแบบ inline {#task-N} ในแผน Lite — MUST มีรายการหนึ่งรายการใน tasks พอดี โดยระบุด้วยหมายเลข (id) และ locator ของมัน locator.kind MUST เป็น file (Full — value คือชื่อไฟล์ของงาน) หรือ inline (Lite — value คือ anchor ของงาน, #task-N)

status MUST เป็นหนึ่งใน pending, in_progress, completed, blocked, skipped skipped ใช้ได้เฉพาะเมื่อผู้ใช้ลบงานออกจากขอบเขตอย่างชัดเจนผ่าน refine เท่านั้น state.json MUST NOT ถูกใช้เพื่อข้ามงานอย่างเงียบ ๆ

รายการ completed MUST พก completed_at และในที่ที่แผน commit hash สั้น commit — นี่คือลิงก์การติดตามจากแผนไปยังโค้ด

บันทึก gate

การรันแต่ละครั้งของคำสั่งตรวจสอบ SHOULD ถูกบันทึกเป็นบันทึก gate: command, passes (boolean), exit_code, last_run และสตริง evidence สั้นที่มนุษย์อ่านได้ (บรรทัดสรุปหรือพาธใต้ analysis_results/ ท้องถิ่นของแผน (ภายในโฟลเดอร์ของแผนเอง ไม่ใช่ที่รูทของ repo) ไม่ใช่ output คำสั่งเต็ม)

งาน MUST NOT ถูกทำเครื่องหมายว่า completed ใน state.json ขณะที่บันทึก gate ใดของมันมี passes: false และไม่มีการรันที่ผ่านในภายหลัง บันทึก gate คือสิ่งเทียบเท่าเครื่องจักรของ “อย่าทำเครื่องหมายว่าเสร็จโดยไม่มีหลักฐาน” — รูปแบบของ flag passes ต่อหนึ่งรายการที่ป้องกันการสำเร็จก่อนเวลา

บันทึกผลลัพธ์ในฐานะหน่วยความจำเชิงลำดับเหตุการณ์

งานที่ completed SHOULD พกบันทึก outcome: สิ่งที่ tried สิ่งที่ failed สิ่งที่ worked และ notes รูปแบบอิสระ รักษาแต่ละรายการไว้หนึ่งบรรทัด

บันทึกผลลัพธ์ทำให้แผนที่เสร็จแล้วเป็นหน่วยความจำเชิงลำดับเหตุการณ์ที่ค้นคืนได้: เอเจนต์ (หรือแพลตฟอร์มจัดทำดัชนีหน่วยความจำ) สามารถค้นคืนได้ในภายหลังว่าปัญหาถูกแก้ไขอย่างไร ไม่ใช่แค่ว่ามันถูกแก้ไขแล้ว มันป้อนข้อมูลให้กับการจัดการเรื่อง skill ภายในงาน และการกระทบยอดเรื่อง skill ของ Final Review ซึ่งอ่านมันเมื่อขุดค้นรูปแบบ บนแพลตฟอร์มอย่าง Hermes ที่จัดทำดัชนีหน่วยความจำของเอเจนต์ บันทึกผลลัพธ์ใน state.json ทำให้แผนที่เสร็จแล้วค้นคืนได้โดยตรงข้ามเซสชันในอนาคต

สถานะ checkpoint และ blocked

checkpoint บันทึกจุด resume ที่ละเอียดที่สุดภายในงานปัจจุบัน: id ของงาน ตัวระบุ step แบบอิสระ timestamp และหมายเหตุหนึ่งบรรทัด เอเจนต์ SHOULD อัปเดตมันทุกครั้งที่หยุดชั่วคราวภายในงาน มัน MUST อัปเดตก่อนการหยุดพักที่วางแผนไว้ในโหมดไม่มีผู้ดูแล

blocked เป็น null หรือ { "task": N, "reason": "...", "since": "...", "needs": "..." } เอเจนต์ไม่มีผู้ดูแลที่ถึงเงื่อนไขหยุด MUST เติม blocked ก่อนหยุด — นี่คือวิธีที่ heartbeat ครั้งถัดไปของ daemon หรือมนุษย์ รู้ว่าทำไมแผนถึงหยุด

การฉายภาพและการปรับประสานงาน

markdown MUST ชนะทุกข้อขัดแย้ง ถ้า state.json บอกว่างาน 4 เป็น completed แต่ README ของแผนแสดง checkbox ที่ยังไม่ได้ทำเครื่องหมาย ไฟล์สถานะนั้นล้าสมัย

เอเจนต์ที่กำลัง resume MUST เปรียบเทียบรายการ checkbox ของ README กับ state.json ก่อนดำเนินการต่อ เมื่อเบี่ยงเบน มัน MUST สร้าง state.json ใหม่จาก markdown (และ git log ในกรณีที่มี) บันทึกการปรับประสานงานใน PROGRESS.md แล้วจึงดำเนินการต่อ

sub-skill verify MUST ถือว่าการเบี่ยงเบนเป็นผลการตรวจสอบความสอดคล้อง: รายงานว่างานใดไม่ตรงกันและในทิศทางใด

เครื่องมืออื่นที่ไม่ใช่เอเจนต์ที่กำลังดำเนินงาน MUST ถือว่าไฟล์ JSON ทั้งสองชิ้นเป็นแบบอ่านอย่างเดียว

การอัปเดตสถานะแบบมีการป้องกัน

การเขียนความคืบหน้าตามปกติผ่านตัวอัปเดตที่จัดส่งมาและเจาะจงเป้าหมาย แทนที่จะเขียนไฟล์ทั้งไฟล์ใหม่ มันปฏิเสธสถานะที่ผิดรูปแบบทันที และปฏิเสธที่จะทำเครื่องหมายงานว่า completed โดยไม่มีหลักฐาน gate ที่ไม่ว่างเปล่าแนบมาด้วย — มีรูปแบบ --gate-json ให้ใช้สำหรับคำสั่งที่ output ของตัวเองมีอักขระ pipe และตัวอัปเดตยอมรับ gate object แบบปิดชนิดเดียวกับที่อธิบายไว้ข้างต้น การรันซ้ำ (retry) จะแทนที่เฉพาะคำสั่งของตัวเองเท่านั้น คำสั่งที่ต่างกันยังคงมีบันทึกแยกของตัวเอง --block-reason บันทึกตัวบล็อก; --resolve-blocker แก้ตัวบล็อกของงานปัจจุบันเท่านั้น ไม่เคยแตะของงานอื่น งานที่ถูกข้ามไม่มีวันทำให้แผน completed ได้ --reopen-reason บันทึกความตั้งใจของผู้เรียกที่จะแก้ไขแผนผ่าน refine — การแก้ไขและหลักฐานใดที่มันทำให้เป็นโมฆะ MUST ถูกบันทึกใน log ของงานก่อน --expected-sha256 ปฏิเสธการเขียนที่เทียบกับ snapshot สถานะที่ได้เปลี่ยนไปแล้วนับแต่นั้น ไดเรกทอรี .lock แบบร่วมมือ (cooperative) จัดลำดับผู้เขียนที่เกิดขึ้นพร้อมกัน ล็อกของผู้เขียนที่ล่มไปแล้ว MUST ถูกตรวจสอบก่อนถูกลบออก และไม่มีการอ้างการป้องกันใดต่อบรรณาธิการที่ข้ามล็อกไปโดยสิ้นเชิง บันทึกเหล่านี้ยืนยันผลลัพธ์ — มันไม่ได้พิสูจน์ด้วยตัวเองว่าคำสั่งถูกรันจริง หรือว่า output ของมันได้รับการยอมรับในเชิงความหมาย

การเผยแพร่แผนที่ได้รับการยืนยัน

ก่อนประกาศการเสร็จสิ้น log ของงานที่เสร็จแล้ว (แต่ละรายการพก การจัดการผลลัพธ์ skill (Skills disposition) ของตัวเอง และใน Final Review พก การตัดสินใจเรื่องเอกสาร (Documentation decision) ของตัวเอง) ดัชนี README และ PROGRESS.md MUST ถูกเขียนขึ้นจากแหล่งที่มาและผลการยอมรับที่ได้มาจริง งานสุดท้ายของแผนจึงปิดผ่านตัวสรุปผล (finalizer) ที่จัดส่งมา: การเปลี่ยนสถานะขั้นสุดท้ายของมันตรวจสอบผู้สมัครที่เสร็จสมบูรณ์เทียบกับสิ่งประดิษฐ์ทุกชิ้นของแผนก่อนเขียนสถานะ ตรวจสอบไฟล์อีกครั้งภายหลัง และบันทึกใบเสร็จ analysis_results/FINALIZATION.json gate ที่ผ่านแบบสร้างขึ้นเอง (invented) MUST NOT หนุนหลังการเปลี่ยนสถานะนี้ — ใบเสร็จคือหลักฐานภายนอกของสิ่งที่ถูกตรวจสอบจริง ไม่ใช่เงื่อนไขเบื้องต้นของตัวมันเอง bash ../verify/conformance.sh --plan PLAN_name รันต่อจากนั้น เทียบกับสิ่งประดิษฐ์จริงบนดิสก์

การเผยแพร่ที่ถูกขัดจังหวะจะทิ้งเครื่องหมาย .finalizing.json ไว้ในที่; การตรวจสอบตามปกติจะล้มเหลวจนกว่าหลักฐานจะถูกตรวจสอบและตัวช่วยกู้คืนสำเร็จเทียบกับผู้สมัครรายเดิม — ไม่มีสิ่งใดทำให้การเผยแพร่กลับมาทำต่อโดยการสันนิษฐาน ล็อกร่วมมือที่ค้างอยู่ (stale) ต้องยืนยันว่าไม่มีผู้เขียนใดยังทำงานอยู่ก่อนจะลบออก ไม่มีสิ่งใดในชั้นนี้ที่ commit, push, รันคำสั่ง gate ที่บันทึกไว้ หรือซ่อมแซม markdown ของแผนอย่างเงียบ ๆ interpreter Python ที่ขาดหายไปให้ผล UNVERIFIED ไม่เคยเป็น completed

ความจริงของหลักฐานและการแก้ไข

ทุกการเปลี่ยนแปลงต่อขอบเขต เกณฑ์การยอมรับ หรือการเลื่อนออกไปของงานหนึ่ง พกบันทึกการแก้ไข (amendment) ที่ถาวรหนึ่งรายการ: เกณฑ์ดั้งเดิมตามตัวอักษร สิ่งที่สังเกตได้ การจัดการผลลัพธ์ (disposition) เหตุผล อำนาจที่อยู่เบื้องหลังมัน (ผู้ใช้ นักพัฒนา หรือหลักฐาน) งานที่ได้รับผลกระทบ และหลักฐานใดถูกทำให้เป็นโมฆะหรือถูกรักษาไว้ การแก้ไขถูกผนวกต่อท้าย ไม่เคยย้อนวันที่; manifest.json รักษาที่มาการสร้างของมันไว้ และไม่เคยถูกเขียนใหม่ให้ตรงกับขอบเขตที่เปลี่ยนไปในปัจจุบัน

สถานะหลักฐานห้าแบบอธิบายว่าบันทึกงานหนึ่งอาจปิดเทียบกับอะไรได้บ้าง:

• การสืบสวนที่เสร็จสมบูรณ์ (Completed investigation) — งานจริงที่ถูกบันทึกไว้; มันปิดงานได้เฉพาะเทียบกับเกณฑ์ที่แก้ไขแล้วซึ่งระบุถึงมัน ไม่เคยเทียบกับเกณฑ์ดั้งเดิมตามที่เขียนไว้
• สถานการณ์ที่ไม่ได้ดำเนินการ (Unexecuted scenario) — บันทึกไว้ว่าไม่ได้ทำ; มันไม่ให้หลักฐานที่ผ่านในยุคใดเลย
• ความต้องการที่เลื่อนออกไป (Deferred requirement) — เกณฑ์ถูกย้ายไปยังงานปลายทางที่มีชื่อระบุ พร้อมอำนาจที่บันทึกไว้; มีเพียงการแก้ไขนั้นเท่านั้นที่ปิดต้นทาง
• Gate ที่ล้มเหลว (Failed gate) — ยังคงล้มเหลวจนกว่าเจตนาการยอมรับเดียวกันจะถูกรันซ้ำและผ่าน; การรันซ้ำจะแทนที่เฉพาะคำสั่งของตัวเองเท่านั้น
• ผลลัพธ์ผลิตภัณฑ์ที่บรรลุแล้ว (Achieved product outcome) — เกณฑ์ตามที่เขียนไว้ ได้รับการยืนยันโดย gate ของมันเอง; เป็นสถานะเดียวที่ทำให้งานเสร็จสมบูรณ์โดยไม่มีการเปลี่ยนแปลง

การบังคับใช้เป็นไปโดยกลไกในทุกที่ที่บันทึกเอื้ออำนวย หลักฐาน gate ที่ทำเครื่องหมายว่า “invalidated by refine” คือประวัติที่ถูกเก็บรักษาไว้ ไม่เคยเป็นหลักฐานที่ผ่าน และงานที่ completed ซึ่งยังพึ่งพามันอยู่จะถูกรายงานโดยตัวตรวจสอบ บันทึกที่ผ่านแต่ข้อความของตัวมันเองยอมรับว่าการตรวจสอบไม่เคยรันจริง (เช่น “never entered”, “did not run” หรือ “cannot be measured”) ถือเป็นความขัดแย้ง และถูกรายงานในลักษณะเดียวกัน — เช่นเดียวกับงานสถานะ completed ที่ log ของตัวมันเองยังคงอ่านว่า Status: pending ความขัดแย้งเชิงบรรยายที่เกินกว่านี้ — รายงานที่ข้อสรุปขัดแย้งกับเช็กลิสต์ของตัวมันเอง — ต้องการผู้ตรวจทานที่เป็นมนุษย์; ตัวตรวจสอบรายงานสิ่งที่บันทึกบอกไว้ ไม่ใช่สิ่งที่ข้อความหมายถึง ผู้ใช้ MAY ยอมรับข้อยกเว้นที่มีขอบเขตอย่างชัดแจ้งพร้อมอำนาจที่บันทึกไว้; การอนุมัติล่วงหน้าแบบไม่มีผู้ดูแลไม่เคยเป็นใบอนุญาตครอบคลุมให้ละทิ้งวัตถุประสงค์หลัก และเกณฑ์บังคับที่ไม่มีทางบรรลุได้คือตัวบล็อก ไม่เคยเป็นงานที่เสร็จสมบูรณ์

การกำหนดเวอร์ชัน schema

ทั้งสอง schema มีเวอร์ชันตาม URL ฟิลด์เพิ่มเติมได้รับอนุญาตภายในเวอร์ชัน การเปลี่ยนชื่อหรือเปลี่ยนประเภทฟิลด์ต้องใช้ schema เวอร์ชันใหม่และหมายเหตุการย้ายใน changelog ของ spec การแก้ไขฉบับนี้นำ /v2.json มาใช้กับทั้งสอง schema: ฟิลด์ file ของรายการงานกลายเป็น locator ที่มีชนิดข้อมูล ({"kind": "file" | "inline", "value": ...}) manifest ได้ plan_format เพิ่มมา และไฟล์สถานะได้ format, materialization, approval และ promotion เพิ่มมา — รวมกันแล้วคือฟิลด์ที่แผน Lite ต้องการ (ดู แผน Lite) manifest และไฟล์สถานะแบบ /v1.json ยังคงใช้งานได้และจะไม่ถูกเขียนทับเป็น v2 อย่างเงียบ ๆ เลย เซสชัน refine MAY ย้ายมันอย่างตั้งใจ ฟิลด์ spec_version ใน manifest ปักหมุดเวอร์ชัน DWP spec ที่แผนถูกสร้างขึ้น เอเจนต์ที่พบแผนที่ใหม่กว่า spec ที่ติดตั้งอยู่ SHOULD บอกเช่นนั้นแทนที่จะเดา