คำว่า subject: lock ความหมาย และให้ policy/v1 เลิกเรียกผู้กระทำว่า subject

[monthop-gmail]

ADR-0017 option B · ต่อจากข้อค้นพบ 4 ของ ADR-0016

หนึ่งคำ สามความหมาย ข้าม 5 contract

ADR-0016 บันทึกไว้ว่าเป็นปัญหาข้าม 3 contract — นับขาด · ไล่ทั้ง contracts/ แล้วมี 5:

contract	field	ความหมาย	รูป
policy/v1	Request.subject	ผู้กระทำ	object {principal, agent_id}
capability/v1	declaration.subject	ผู้ประกาศ	object {kind, id}
event/v1 🔗	subject_type/subject_id	หัวเรื่องของบันทึก	enum 9 + Id
approval/v1 🔗	subject	สิ่งที่ถูกอนุมัติ	object {type, id}
consent/v1	subject_id	เจ้าของข้อมูล — เขียนกำกับเองว่า 🔒 "ไม่ใช่ actor"	Id เดี่ยว

และคำนี้ ไม่อยู่ในตารางศัพท์ที่ lock ไว้ ทั้งที่ตารางนั้นมีอยู่เพื่อกันเรื่องนี้โดยเฉพาะ

ความเสี่ยงอยู่ตรงไหนจริง ๆ — ไม่ตีขลุม

คู่ที่อันตรายคือ policy.subject (ผู้กระทำ) ↔ consent.subject_id (เจ้าของข้อมูล) เพราะเป็น "id ของคน" ที่ความหมายตรงข้าม และเป็นสองด่านที่ต้องเรียกคู่กันตาม consent_rules ข้อ 6

แต่บน wire วันนี้ schema จับความผิดพลาดนี้ได้อยู่แล้ว — ตัวหนึ่งเป็น object อีกตัวเป็น scalar Id ส่งสลับกันจะ validate ไม่ผ่าน

ความเสี่ยงจริงจึงอยู่ที่:
  · หัวคนที่อ่าน contract สองตัวเรียงกัน
  · โมเดลภายในของ consumer ที่เขียนเอง ซึ่งไม่มี schema มาจับ

enterprise-knowledge กำลัง map Principal/PolicyContext เข้าชุดนี้อยู่ตอนนี้ และ contracts.py ของเขาเป็น Python ล้วน — ในงาน ACL-aware retrieval การสลับสองคำนี้แปลว่า เอาสิทธิ์ของคนหนึ่งไปเปิดข้อมูลของอีกคน

คำวินิจฉัยที่ lock

subject = สิ่งที่บันทึกหรือข้อความนั้นเกี่ยวกับ · ห้ามใช้เรียกผู้กระทำ — ผู้กระทำคือ actor
ความหมาย "เจ้าของข้อมูลส่วนบุคคล" ใช้ได้เฉพาะ consent/v1 เพราะเป็นศัพท์กฎหมาย (data subject) และต้องมีหมายเหตุกำกับเสมอ

กฎนี้ทำให้ 4 ใน 5 ถูกอยู่แล้ว และชี้ตัวที่ต้องแก้ได้ตัวเดียว

สิ่งที่เปลี่ยน — policy/v1 v1.2.0

Request:
  required: [context, action]     # ถอด subject ออก — ผ่อน ไม่ใช่บังคับ
  oneOf:
    - required: [actor]           # ทางใหม่
    - required: [subject]         # ทางเดิม · deprecated: true

$defs.Actor นิยามรูปครั้งเดียว ทั้ง actor และ subject $ref ตัวเดียวกัน — รูปเหมือนกันทุกอย่าง เปลี่ยนแค่ชื่อ

ไม่ breaking

payload เดิมที่ส่ง subject ยัง valid ทุกใบ · oneOf ห้ามส่งสองชื่อพร้อมกัน แต่ actor เพิ่งเกิด จึงไม่มี payload เดิมใบไหนส่งทั้งคู่ได้ · care-agent-platform และ devfactory-core ไม่ต้องทำอะไรทันที

⏳ ต้องลบใน policy/v2

บันทึกไว้ใน contracts/README.md เป็นตารางของ field ที่ deprecated — สองชื่อสำหรับสิ่งเดียวกันคือสิ่งที่ repo นี้ห้ามไว้ทุกที่ (expires_at: null · conditions: []) จึงต้องมีวันหมดอายุ ไม่ใช่อยู่ถาวร

ที่ไม่แตะ — และทำไม

event/v1 · approval/v1 ใช้ subject ในความหมายที่ ถูกตามคำวินิจฉัยอยู่แล้ว และเป็น 🔒 semantics ของ devfactory-core (RFC-0008) ที่เปลี่ยนที่นี่ไม่ได้ · consent/v1.subject_id เป็น data subject ตามศัพท์กฎหมาย ซึ่ง ADR อนุญาตไว้เป็นข้อยกเว้น

ทั้งสี่ได้ หมายเหตุอ้างอิงไขว้ แทนการเปลี่ยนชื่อ — และนั่นคือส่วนที่ปิดความเสี่ยงจริง เพราะความเสี่ยงคือการอ่าน ไม่ใช่ชื่อ

ตรวจแล้ว

drift_check.py → passed=20 FAIL=0 WARN=0 · payload จริง 7 เคสตรงตามคาด รวม negative ของ oneOf:

เคส	ผล
payload เดิมที่ใช้ subject · payload ใหม่ที่ใช้ actor · actor + consent	✅ valid
ส่งทั้ง actor และ subject · ไม่ส่งทั้งคู่ · actor ไม่มี principal · ขาด action	✅ ถูก reject ทุกเคส

🤖 Generated with Claude Code

https://claude.ai/code/session_01LHv7HRmnnGAoKT5BvxDWHs