Governance decision interface — decision เป็น record ไม่ใช่ flag (#5)

[monthop-gmail]

ปิด #5 · decision กลายเป็น record ที่ตรวจสอบได้ ไม่ใช่ flag ที่ใครก็ตั้งได้

แกนของการเปลี่ยน

Job._approved: bool → Job._approval: Decision | None

ข้อห้าม "execution ก่อน APPROVED" เดิมผูกกับ boolean ที่ตั้งเป็น True ได้โดยไม่มีใครรับผิดชอบ
ตอนนี้ผูกกับ record ที่บังคับ 4 field ตาม RFC-0002 — decision · reason · decided_at · authority
ถ้าไม่มีใบอนุมัติจริง งานเดินต่อไม่ได้ และ "ใครอนุมัติ" ตอบได้เสมอ

Decision เป็น frozen dataclass · serialize เป็นรูป approval/v1 ของ agent-platform ตรง ๆ
(decision_id → approval_id ตาม RFC-0005 Rule 1) · self-approval ของ agent ถูกปฏิเสธ
ตาม invariant ที่สัญญาเขียนไว้ ("no agent has total authority")

REQUIRE_CHANGES — รับเป็นคำ แต่ยังใช้ไม่ได้ โดยตั้งใจ

vocabulary มีครบ 3 ค่าตามสัญญา (ชุดปิด ขาดไม่ได้) แต่ engine ปฏิเสธ REQUIRE_CHANGES
ด้วย UnmappedDecision เพราะ ไม่มีเอกสารไหนบอกว่างานไปสถานะไหนต่อ:

• approval/v1 guarantee บอกแค่ว่า "ไม่ใช่ REJECT — งานยังมีชีวิตและกลับมายื่นใหม่ได้"
• GOVERNANCE_ANALYSIS มีทางออกแค่ APPROVED กับ REJECTED

ทางเลือกทั้งสามทาง (เพิ่ม edge → DRAFT · ใช้ REJECTED · เพิ่ม state ที่ 14) เป็น lifecycle change
ที่ต้องมี RFC ก่อนตาม CONTRIBUTING.md · PR นี้จึงไม่เลือกให้ — ถามไว้ที่
agent-platform#22 แล้ว

ยอมให้ค่าหนึ่งใช้ไม่ได้ชั่วคราว ดีกว่าปล่อยให้โค้ดเลือกกฎ lifecycle เองแล้วเอกสารตามไม่ทัน
ซึ่งเป็นสิ่งที่เพิ่งเกิดกับเราใน #14 มาแล้วรอบหนึ่ง · ไม่บล็อก PR นี้

audit trail

ทุก APPROVE/REJECT emit GOVERNANCE_DECISION คู่กับ STATE_TRANSITION เสมอ
ไม่ว่าจะเข้าผ่าน decide() หรือ transition() ทั่วไป — guarantee ผูกกับ state ไม่ใช่กับ method
จึงไม่มีทางเข้า APPROVED แบบข้ามการบันทึกได้

known gap ที่ลงทะเบียนไว้

approval/v1 บังคับว่า "การเปลี่ยนใจคือ approval ใบใหม่ที่อ้างใบเดิม" แต่ schema ไม่มี field ให้อ้าง
· ใส่ supersedes_decision_id ฝั่งเราไปก่อน (schema ไม่ได้ปิด additionalProperties)
และลงใน gaps: ของ platform-contract.yaml ชี้ไป agent-platform#22 · ถ้าเขาตั้งชื่อ field เอง
งานที่เหลือคือ rename ไม่ใช่ออกแบบใหม่

ผลตรวจ

• pytest 350 passed (เดิม 302 · เทสใหม่ 48 ตัวใน test_decisions.py)
• conformance/payload_check.py 13 passed · 0 fail — validate decision จริงกับ approval/v1
  และ probe ว่า REQUIRE_CHANGES ถูกปฏิเสธจริง
• ไม่ bump semantics_version · ไม่แตะบล็อก frozen

breaking ระดับ in-repo

approve() / reject() คืน Decision แทน Event — call site ในเรโปแก้ครบแล้ว

ที่ยังไม่ทำในนี้

• ปลายทางของ REQUIRE_CHANGES → รอ agent-platform#22 แล้วค่อยออก RFC
• คนอนุมัติงานตัวเองยังทำได้ (ปฏิเสธเฉพาะ agent ตามที่สัญญาเขียน) — บันทึกไว้ใน
  state-machine.md §Open questions ถ้าจะขยายให้ครอบคลุมคนต้องเป็น RFC

Closes #5