Diagnostic codes owned in analysis sources
Platform spec ADR
Diagnostic codes owned in analysis sources
Spec standingStandard
- Contracts and edge cases Stability requirements and risky changes in the diagnostic registry.
- Design model Conceptual model for owning and evolving semantic diagnostic codes.
- Examples Representative registry update scenarios and expected outcomes.
- FAQ and troubleshooting Common registry maintenance questions and recovery guidance.
- Flow and algorithm Lifecycle of a semantic diagnostic code from definition to surfaced output.
- Verification and traceability Checks that keep diagnostic code docs and source synchronized.
0 revisions (git unavailable at build; counts may be empty)
No commits recorded for this path.
Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).
Context
Section titled “Context”Rendered diagnostics drifted from semantic registry.
Decision
Section titled “Decision”Code-to-meaning mapping is normative in SemanticIssueKind::code() and diagnostic_kinds.rs, synchronized with trudoc verify scripts—not LSP presentation layers.
Consequences
Section titled “Consequences”Renaming codes requires migration notes; new issues need unique codes before release.
Verification anchors
Section titled “Verification anchors”compiler/crates/beskid_analysis/src/analysis/diagnostic_kinds.rspackages/trudoc/scripts/verify-diagnostics-spec-sync.mjs.