Retire the event-type waiver, and refuse a malformed event_type at intake - #27
Merged
Conversation
…take agent-platform#17 closed on 2026-08-18 — event/v1's event_type refs EventTypeName, an open set constrained by shape, instead of the closed $defs.EventType enum. The waiver we recorded against it stayed behind in conformance/pinned.yaml. A waiver left behind after its cause is fixed does not sit there harmlessly. Its condition was "any validation error at event_type on an external event", which covers a value we have not met and a value that is not a value at all. Injecting an external event typed "sighting recorded!!" into the scenario showed it being tolerated with the run still green at exit 0 — the same false-green shape this repository has already been bitten by twice, from the wrong side this time. So both halves are dealt with. known_gaps goes to an empty list, with a note at the top saying why a retired entry has to be removed rather than left: that list is machinery and a stale entry still runs. The record of what we deviated on and why stays in platform-contract.yaml under gaps:, which is documentation and marks closed entries status: resolved rather than deleting them, following the convention already in that file. Intake now refuses a malformed event_type. This is not a reversal of the rule that an unrecognised type is kept: event/v1 says keep what you do not recognise and skip interpreting it, and SIGHTING_RECORDED from navi-ims is still accepted whole. EventTypeName constrains the shape of the name so a vocabulary allowed to grow still reads as a vocabulary. Unknown is a value we have not met; malformed is not a value, and RFC-0008 puts that refusal at the boundary rather than in a record nobody can correct. EVENT_TYPE_PATTERN mirrors the contract for the same reason identity.ID_PATTERN does, and is the minimum needed to refuse rather than a second copy of the schema. One line of output was also saying "except for known gaps" on every run whether or not anything had been excepted, which invites a reader to assume a waiver is at work. It now appears only when something was actually tolerated. 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
1 participant
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.
งานเล็กสองอันที่เจอตอนเชคสถานะ — เก็บให้จบก่อนไป #26
1. waiver ที่ตายแล้ว แต่ยังกลืนของอยู่
agent-platform#17 ปิดไปตั้งแต่ 2026-08-18 — เขาแก้ให้แล้ว
event_typeอ้างEventTypeName(ชุดเปิด บังคับแค่รูปแบบ^[A-Z][A-Z0-9_]{2,63}$) ไม่ได้อ้าง$defs.EventType(ชุดปิด) อีก · pin ปัจจุบันมีตัวแก้นั้นอยู่แล้วแต่
known_gapsในconformance/pinned.yamlยังค้างอยู่ หมดอายุ 2026-11-18ปัญหาไม่ใช่ความรกรุงรัง — เงื่อนไขของ waiver คือ "error ที่ field
event_typeของ event ที่source.kind: external" ซึ่งครอบทั้ง ค่าที่ไม่รู้จัก และ ค่าที่ผิดรูปยัด event ภายนอกที่
event_type="sighting recorded!!"เข้า scenario:event ที่ผิดรูปชัด ๆ ไหลเข้า audit log แล้ว CI บอกว่าเรียบร้อย — false ✅ ชนิดเดียวกับที่ repo นี้เจอมาแล้วสองครั้ง (คำว่า
approvalโผล่ในย่อหน้าอื่น · status ที่หาทั้งไฟล์) แต่คราวนี้มาจากฝั่งเราเองแยกสองที่ตามหน้าที่จริง
conformance/pinned.yamlknown_gaps[]platform-contract.yamlgaps:status: resolved+resolved_by+ noteข้อหลังทำตามธรรมเนียมที่ไฟล์นั้นเขียนไว้เองว่า "ข้อที่ปิดแล้วไม่ลบทิ้ง แต่ติด
status: resolved"เพิ่มคำเตือนไว้ในหัว
known_gapsด้วย เพื่อไม่ให้ครั้งหน้าค้างอีกด้วยเหตุผลเดิม2. intake ปฏิเสธ
event_typeที่ผิดรูปไม่ใช่การกลับคำเรื่อง "ค่าที่ไม่รู้จักต้องเก็บไว้" —
SIGHTING_RECORDEDจากnavi-imsยังรับเต็ม ๆ เหมือนเดิมEventTypeNameบังคับรูปแบบชื่อ ไม่ใช่ตัวค่า เพื่อให้ vocabulary โตได้โดยที่ชื่อยังอ่านรู้ว่าเป็น event typeSIGHTING_RECORDEDMEDICATION_TAKENABCis_recognised = False"sighting recorded!!"lowercaseMixed_CaseAB9START"A"*65MalformedEventTypeEVENT_TYPE_PATTERNมิเรอร์ contract ด้วยเหตุผลเดียวกับidentity.ID_PATTERN— ขอบต้องปฏิเสธก่อนเขียนลง record ที่แก้ไม่ได้ และ contract อยู่คนละ repo · เป็นขั้นต่ำที่จำเป็นเพื่อปฏิเสธ ไม่ใช่ schema ขนานที่ RFC-0005 Rule 4 ห้าม (เขียนกำกับไว้ในโค้ดแล้ว)เพิ่มเทสต์ที่ยืนยันว่า vocabulary ของเราเองทั้ง 9 ตัวผ่าน pattern — กฎที่ปฏิเสธคำของตัวเองคือกฎที่ผิด
3. ของแถม — ข้อความที่ชวนเข้าใจผิด
payload_checkเคยพิมพ์ "56 event ผ่าน (ยกเว้นช่องว่างที่รู้ตัว)" ทุกครั้ง แม้ไม่มีอะไรถูกยกเว้น · ตอนนี้วงเล็บนั้นโผล่เฉพาะเมื่อมีของถูกยกเว้นจริงจำนวน check ลดจาก 20 เป็น 19 เพราะไม่มี waiver ให้ตรวจอายุแล้ว — ไม่ใช่มีอะไรหาย
Impacted planes
Observability เท่านั้น · job state machine ไม่ถูกแตะ (core 335 tests ผ่านเหมือนเดิม)
Risk analysis
EVENT_TYPE_PATTERNdrift จาก contract (low) → pattern อยู่ที่เดียว มี comment ชี้ไปEventTypeName· ถ้า contract ผ่อนรูปแบบ conformance จะยังเขียว (เราเข้มกว่า) แต่ถ้าเขาเข้มขึ้น payload ของเราจะแดงทันที ซึ่งเป็นทิศที่ปลอดภัยRelated
#26 (งานใหญ่ถัดไป) · agent-platform#17 · RFC-0008 · RFC-0009
🤖 Generated with Claude Code