ADR-0029: เพดานที่ยกทุกอย่างให้เข้มขึ้น จะกั้น action ที่ความเร็วคือความปลอดภัย - #65
Merged
Merged
Conversation
…วามปลอดภัย care-agent-platform รายงานเคสจาก production ว่าเพดานของเขายกทุกอย่างให้เข้มขึ้น อย่างสม่ำเสมอ ผลคือ emergency escalate ถูกยกจาก notify เป็น human_command_required แปลว่าตอนผู้ป่วยล้ม ระบบจะรอคนสั่งก่อนถึงจะเรียกคน เพดานที่ตั้งใจเพิ่มความปลอดภัย กลับลบความปลอดภัยข้อที่สำคัญที่สุดทิ้ง วันเดียวกัน รูปเดียวกันโผล่จากคนละโดเมนในกระทู้ ai-tools-mcp คือ tools cancel และการฆ่า execution ที่กำลังรันต้องไม่มีวันติดคิวอนุมัติ สองทีม สองโดเมน หนึ่งวัน จึงเป็นเรื่องของสัญญา ไม่ใช่ของ implementation ใครคนใดคนหนึ่ง สาเหตุเชิงโครงสร้างคือ authority_map map จาก action_risk ไป authority และ ADR-0010 นิยาม action_risk ว่าความเสียหายถ้าทำผิด ไม่มีที่ไหนในสัญญาที่บันทึกความเสียหายถ้า ไม่ทำ taxonomy จึงมีแกนเดียวแต่โลกมีสองแกน เพดานใดที่สร้างบนแกนเดียวนี้จะกั้นการ กระทำที่คุณค่าของมันคือความเร็ว โดยไม่ได้ผิดกติกาสักข้อ ผู้รายงานตอบตรง ๆ ว่าฝั่งเขาไม่มีกลไก แยกด้วยมือและเคยตั้งผิดมาแล้ว แล้วเสนอทางที่ ตรวจได้คืออย่าประกาศคุณสมบัติ ให้ประกาศความสัมพันธ์ ด้วย undoes ที่ชี้ไป CapabilityId จริง กฎจึงกลายเป็นสิ่งที่เครื่องตรวจได้ว่าตัวที่ undo ต้องไม่ต้องการ authority สูงกว่า ตัวที่มันยกเลิก แต่เขาเตือนเองว่ามันไม่ครอบ emergency escalate ซึ่งไม่ได้ undo อะไร และถ้ารวมสองรูปเป็นฟิลด์เดียว อันที่สองจะลากอันแรกลงไปเป็นเชื่อผมเถอะด้วย ใบนี้เป็น Proposed เสนอ D คือสองฟิลด์แยกกัน และบันทึกไว้ว่า E ซึ่งเป็นการเขียนกฎ อย่างเดียวรอ producer เป็นทางที่ตรงกับนิสัยของ repo นี้ที่สุดและใช้มาแล้วสามรอบติด ต่างกันตรงที่สามรอบนั้นความล้มเหลวคืออ่านยาก รอบนี้คือระบบไม่เรียกคนตอนคนล้ม และ กฎเปล่าไม่ได้ป้องกันเคสนี้เพราะทีมที่รู้หลักอยู่แล้วยังตั้งผิด อัปเดตทะเบียน consumer ของ care ด้วย ตรวจโดยดึง platform-contract.yaml มาอ่านเอง ไม่ได้เชื่อรายงาน พบว่า manifest โตเป็น 6 conformance check แล้ว และพบข้อไม่ตรงกัน คือ profile_check อ้าง profile/v1 แต่ profile/v1 ไม่อยู่ใน contracts ของ manifest บันทึกไว้เป็นคำถาม ไม่ใช่ข้อสรุป drift check 34/34 FAIL=0 WARN=0 Claude-Session: https://claude.ai/code/session_01LHv7HRmnnGAoKT5BvxDWHs Co-authored-by: monthop-gmail <monthop-gmail@users.noreply.github.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…นฟิลด์เดียว เจ้าของงานเคาะทางเลือก D เหตุผลที่ไม่เลือก E ทั้งที่ E ตรงกับนิสัยของ repo นี้ที่สุดและถูกมาแล้วสามรอบติด คือ สามรอบนั้นความล้มเหลวเป็นเรื่องอ่านยาก ส่วนรอบนี้เป็นเรื่องระบบไม่เรียกคนตอนผู้ป่วยล้ม และหลักฐานบอกว่ากฎที่ไม่มีของบังคับไม่พอ เพราะทีมที่รู้หลักนี้อยู่แล้วยังตั้งผิด ที่ทางของข้อยกเว้นยังไม่ตัดสินในใบนี้ รอ producer รายแรกตามหลักเดียวกับ ADR-0025 และ ADR-0027 และบันทึกไว้ว่าถ้าเคาะ D แล้วรอบถัดไปไม่มีใครใช้ undoes เลย นั่นคือ หลักฐานว่าควรถอยไป E ไม่ใช่เหตุผลให้เติมฟิลด์เพิ่ม drift check 34/34 FAIL=0 WARN=0 Claude-Session: https://claude.ai/code/session_01LHv7HRmnnGAoKT5BvxDWHs Co-authored-by: monthop-gmail <monthop-gmail@users.noreply.github.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Status: Proposed — รอเจ้าของงานเคาะ
care-agent-platformรายงานเคสจาก production ในdis-65134078seq 12:วันเดียวกัน รูปเดียวกันโผล่จากคนละโดเมนใน
dis-a84b7a8e:tools.cancelต้องไม่มีวันติดคิวอนุมัติ · สองทีม สองโดเมน หนึ่งวัน → เป็นเรื่องของสัญญา ไม่ใช่ของ implementation ใครคนใดคนหนึ่งสาเหตุเชิงโครงสร้าง — taxonomy มีแกนเดียว
ไม่มีที่ไหนในสัญญาที่บันทึกความเสียหายถ้า "ไม่ทำ" — เพดานใดที่สร้างบนแกนเดียวนี้จะกั้น action ที่คุณค่าของมันคือความเร็ว โดยไม่ผิดกติกาสักข้อ
Options
never_gatedundoesอย่างเดียวemergency.escalateซึ่งเป็นเคสที่จุดชนวนundoes+ ข้อยกเว้นที่ประกาศแยก ห้ามยุบเป็นฟิลด์เดียวundoesมาจากผู้รายงานเอง พร้อมคำเตือนของเขาว่า ถ้ารวมสองรูปเป็นฟิลด์เดียว อันที่สองจะลากอันแรกลงไปเป็น "เชื่อผมเถอะ" ด้วยยังไม่ปิด
capability/v1หรือprofile/v1) — รอ producer รายแรกundoesเลยวันนี้ รวมทั้งผู้เสนอ · ถ้าเคาะ D แล้วไม่มีใครใช้ในรอบถัดไป นั่นคือหลักฐานว่าควรถอยไป Eอัปเดตทะเบียน consumer ด้วย
ตรวจ
care-agent-platformโดยดึงplatform-contract.yamlมาอ่านเอง ไม่ได้เชื่อรายงาน — manifest โตเป็น 6 conformance check แล้ว และพบข้อไม่ตรงกัน:profile_checkอ้างprofile/v1แต่profile/v1ไม่อยู่ในcontracts:· บันทึกไว้เป็นคำถาม ไม่ใช่ข้อสรุปตรวจแล้ว
drift check 34/34 · FAIL=0 · WARN=0🤖 Generated with Claude Code
https://claude.ai/code/session_01LHv7HRmnnGAoKT5BvxDWHs