docs(tcg): clarify TCG schema forward-compat model (closed enums + version-matched validation) - #13
Conversation
…rsion-matched validation) The schema's top-level description promised consumers tolerate unknown enum members, but the signal/lane/status/payloadAccess/provenance enums are closed — strict validation would reject a future document carrying a new enum value, contradicting the promise (CodeRabbit, #12). Reword to the model the spec (docs/TELEMETRY_CAPABILITY_GRAPH.md 'Versioning & compatibility') already documents: the enums are intentionally closed and a document is validated strictly against the schema matching its own schemaVersion; forward compatibility comes from version-matched validation plus tolerant consumer code (map unknown enum members to the catch-all, ignore unknown properties). Description text only — no structural change, so the emitted TCG validates identically. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🧰 Additional context used📓 Path-based instructions (2)docs/schema/telemetry-capability-graph.schema.json📄 CodeRabbit inference engine (AGENTS.md)
Files:
**⚙️ CodeRabbit configuration file
Files:
⚙️ CodeRabbit configuration file
Files:
🔇 Additional comments (1)
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe top-level ChangesSchema Description Update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
Summary
Fast-follow on #12 (CodeRabbit-flagged, the one survivor of adversarial triage).
The TCG exchange schema's top-level
descriptionpromised "consumers MUST tolerate unknown enum members for forward compatibility", butsignal/lane/status/payloadAccess/provenanceare closedenums. Strict JSON-Schema validation would therefore reject a future document carrying a new enum value — contradicting the schema's own promise.Fix (description text only — no structural change)
Reword the description to the model the spec already documents (
docs/TELEMETRY_CAPABILITY_GRAPH.md→ Versioning & compatibility): the enums are intentionally closed so a document is validated strictly against the schema whose version equals its ownschemaVersion; forward compatibility comes from version-matched validation + tolerant consumer code (map unknown enum members to the catch-all, ignore unknown properties —additionalPropertiesstaystrue). Strict typo-catching is kept; the contradiction is removed.The emitted TCG validates identically (enums and structure unchanged).
🤖 Generated with Claude Code