lifecycle: approval หมดอายุแล้ว "ต้องขอใหม่" — แต่ไม่มีทางขอใหม่ที่ลิงก์กลับงานเดิม

[monthop-gmail]

พบตอนทำ #17
(PR #20 merged) —
สัญญาบอกว่า approval ที่หมดอายุ "ต้องขอใหม่" แต่ lifecycle ไม่มีทางให้ขอใหม่

ช่องว่าง

approval/v1 เขียนไว้ที่ field expires_at:

approval ที่หมดอายุแล้วใช้เดินงานไม่ได้ ต้องขอใหม่

ตอนนี้ PR #20 บังคับครึ่งแรกแล้ว (ExpiredApproval ปฏิเสธการเดินงานต่อ) แต่ครึ่งหลังไม่มีทางทำ:

• ไม่มี edge APPROVED → GOVERNANCE_ANALYSIS — ขออนุมัติใหม่ในงานเดิมไม่ได้
• supersede() ใช้ได้เฉพาะจาก FAILED ตาม RFC-0007 Decision 1 · แต่ APPROVED
  ไม่อยู่ใน FAILABLE (RFC-0010) จึงเข้า FAILED ไม่ได้เลย

ทางออกที่เหลือของ job ที่ approval หมดอายุจึงมีแค่ TIMED_OUT หรือ CANCELLED
· และการยื่นใหม่กลายเป็น job ใหม่ที่ไม่มีอะไรลิงก์กลับไปหางานเดิม

ทำไมถึงสำคัญกว่าที่เห็น

RFC-0007 Decision 1 อุตส่าห์ปิดรูนี้ไว้ตอนห้ามชุบชีวิต job ที่ FAILED — เหตุผลคือ
ต้องมีสายโซ่ของความพยายามที่ตรวจสอบได้ (supersedes_job_id) ไม่ใช่ job ที่ประวัติวนเป็นวง

แต่เส้นทาง "approval หมดอายุ" กลับออกทางที่ไม่มีสายโซ่เลย — งานเดิมจบเป็น TIMED_OUT
งานใหม่เริ่มที่ DRAFT โดยไม่มีอะไรบอกว่ามันคือความพยายามรอบสองของเรื่องเดียวกัน
· audit trail จึงตอบไม่ได้ว่า "งานนี้เคยถูกอนุมัติแล้วปล่อยจนหมดอายุกี่รอบ"
ซึ่งเป็นสัญญาณของปัญหาเชิงกระบวนการที่ควรมองเห็น

ทางเลือก (ยังไม่เลือก — ต้องมี RFC)

	ทาง	ข้อสังเกต
ก	ให้ supersedes_job_id ใช้ได้กับ terminal ทุกตัว ไม่ใช่แค่ FAILED	เล็กที่สุด · ไม่แตะตาราง transition เลย · แค่ผ่อนกฎว่าใครอ้างใครได้
ข	เพิ่ม edge APPROVED → GOVERNANCE_ANALYSIS (ขออนุมัติใหม่ในงานเดิม)	ตรงกับคำว่า "ขอใหม่" ที่สุด · แต่ทำให้ job เดียวมีหลาย approval ตามลำดับเวลา ต้องเคาะว่า audit อ่านยังไง
ค	ปล่อยไว้ตามนี้ แล้วบันทึกว่าเป็นพฤติกรรมที่ตั้งใจ	ถูกที่สุด แต่ต้องยอมรับว่า chain ขาดตรงนี้

ผมเอนไปทาง ก — มันคืนสายโซ่ได้โดยไม่แตะ lifecycle และไม่สร้าง state ใหม่
แต่เป็นการแก้ RFC-0007 จึงต้องมีคนเคาะ

สภาพปัจจุบันถูกบันทึกไว้แล้ว

PR #20 มีเทสที่ยืนยันสภาพนี้ตามความจริง (ไม่ใช่ซ่อน) — job ที่ approval หมดอายุ
เดินต่อไม่ได้และไม่มีทางกลับไปขอใหม่ · ถ้าเลือกทางไหนแล้ว เทสตัวนั้นจะเปลี่ยนไปตามกฎใหม่