execution/v1 บันทึกใบอนุมัติที่อนุญาตให้รัน — execution v1.1.0 · approval v1.2.0

[monthop-gmail]

ADR-0019 option A

ช่องว่าง — แผลชนิดเดิม ครั้งที่สาม

approval/v1 guarantees ข้อ 3 (🔒 frozen · devfactory-core RFC-0002):

"execution ที่ไม่มี APPROVE เป็นสิ่งที่ห้าม"

execution/v1 มี policy_decision ที่ $ref ไป Decision เต็มใบ — บันทึกได้ว่า ต้องขออนุมัติไหม แต่ไล่ properties ครบทุกตัวแล้ว ไม่มีอะไรชี้ไปยังใบอนุมัติได้ (grep -rn approval contracts/execution/ = 0)

policy ตัดสิน authority: approval_required   →  บันทึกใน execution ✅
มีคนอนุมัติจริง                               →  ไม่มีที่บันทึก ❌

เหมือน #22 และ ADR-0016 — ครั้งที่สาม และกระทบมากที่สุดเพราะเป็น ด่านอำนาจของมนุษย์ ซึ่งเป็นเหตุผลทั้งหมดที่ ADR-0010 แยก authority ออกจาก effect

สองครั้งก่อนเจอเพราะมีคน implement · ครั้งนี้เจอจากการไล่ guarantees ทุกข้อของทุก contract เทียบกับ properties อย่างเป็นระบบ

อ่าน guarantee ให้ตรง

ถ้าอ่านว่า execution ทุกใบ ต้องมี APPROVE จะขัดกับ authority: auto (ทำได้เลย) ทันที · ความหมายที่ถูกคือ execution ที่ผ่านด่านซึ่งต้องการอนุมัติ ต้องมี APPROVE จริง ห้ามข้าม

ทำไมที่นี่เก็บ id ก็พอ ทั้งที่ ADR-0016 บอกว่าไม่พอ

approval/v1 guarantees ข้อ 1: "decision เป็น immutable — แก้ไม่ได้หลังบันทึก" → ใบที่อ่านปีหน้าให้คำตอบเดียวกับที่อ่านวันนี้เสมอ

ต่างจาก consent/v1 ที่ใบมี conditions ซึ่งเปลี่ยนคำตอบได้ จึงต้องแช่แข็ง ผลการประเมิน

เกณฑ์จริงคือ สิ่งที่ชี้ไปเปลี่ยนได้ไหม ไม่ใช่กฎเหมารวมว่า "ห้ามเก็บ id ต้องเก็บผลเสมอ" — บันทึกไว้ชัดเพื่อไม่ให้ ADR-0016 ถูกอ่านผิด

ทำไมไม่ใส่ if/then ทั้งที่เขียนได้

ExecutionState มี rejected · cancelled · timed_out — execution ที่เข้า awaiting_approval แล้วถูกปฏิเสธหรือยกเลิกก่อนมีใครอนุมัติ ไม่มี APPROVE ให้ชี้ตามนิยาม

authority: approval_required + state: rejected   → ไม่มี approval_id ถูกต้อง
authority: approval_required + state: succeeded  → ไม่มี approval_id คือการละเมิด

ความต่างขึ้นกับ state ที่เปลี่ยนตามเวลา · schema ตรวจ payload ณ ขณะหนึ่ง จึงบังคับไม่ได้โดยไม่ผลิตสัญญาณลวง ซึ่งอันตรายพอ ๆ กับการตรวจไม่เจอ (เหตุผลเดียวกับที่ ADR-0015 ปฏิเสธ sequence แบบต่อเนื่อง)

สิ่งที่เปลี่ยน

contract	เพิ่ม	version
execution/v1	approval_id (optional)	v1.0.0 → v1.1.0
approval/v1 🔗	correlation_id (optional)	v1.1.0 → v1.2.0

correlation_id พ่วงมาเพราะ contract อื่นเกือบทั้งหมดมีแต่ไฟล์นี้ไม่มี — execution_id/subject ทำแทนไม่ได้ เพราะการอนุมัติหนึ่งครั้งอาจเกิดก่อน execution ถูกสร้าง หรือครอบหลาย execution ในสายเดียวกัน · เป็น field ระดับ platform ตาม ADR-0006 กฎข้อ 1 · guarantees ไม่ขยับ · semantics_version ยัง "1.1"

invariant ที่ผู้ผลิตต้องบังคับเอง

ใบที่อ้างต้องมีอยู่จริง · tenant_id เดียวกัน · subject ตรงกับ execution นี้ · decision ต้องเป็น APPROVE · ต้องมีก่อนออกจาก awaiting_approval ไปสู่ running

⚠️ ไม่มีค่านี้เมื่อจบที่ rejected/cancelled/timed_out = ถูกต้อง ไม่ใช่ข้อมูลขาด — เขียนไว้ในตัว field เพราะถ้า implementation ตีความผิดจะเกิดสัญญาณลวงแบบเดียวกับที่เราเพิ่งเลี่ยง

ตรวจแล้ว

drift_check.py → passed=20 FAIL=0 WARN=0 · payload จริง 8 เคสตรงตามคาด:

เคส	ผล
execution ไม่มี approval_id (payload เดิม) · มี · rejected ไม่มี · cancelled ไม่มี	✅ valid — พิสูจน์ว่าไม่แดงกับเส้นทางที่ถูกต้อง
approval ไม่มี correlation_id (payload เดิม) · มี	✅ valid
approval_id / correlation_id ผิดรูป Id	✅ ถูก reject

ผลต่อ consumer

devfactory-core pin execution/v1 อยู่แต่ยังไม่ผลิต payload ของมัน (job state machine อยู่คนละชั้น) · optional ทั้งคู่ — ไม่มีใครต้อง migrate

🤖 Generated with Claude Code

https://claude.ai/code/session_01LHv7HRmnnGAoKT5BvxDWHs