Sibling articles under this feature previously restated requirements in inconsistent forms.
FAQ and troubleshooting
Platform spec article
FAQ and troubleshooting
Spec standingStandard
-
This feature hub owns normative MUST/SHOULD contract text for Rules and diagnostics catalog.
Context
Decision
This feature hub owns normative MUST/SHOULD contract text. Sibling articles must not redefine hub requirements and should link here for authority.
Consequences
Contract changes start on the hub or in linked ADRs, then propagate to articles and implementation anchors.
Verification anchors
site/website/src/content/docs/platform-spec/compiler/semantic-pipeline/rules-and-diagnostics-catalog/index.mdxarticle bundle under the same feature directory.
-
Platform-spec text supersedes informal crate comments for Rules and diagnostics catalog.
Context
Implementation crates accumulated informal notes that diverged from published contracts.
Decision
Normative platform-spec prose and ADRs under this feature supersede informal comments in implementation crates until explicitly migrated into spec text.
Consequences
Engineers file spec/ADR updates when behavior changes; crate comments are non-authoritative for conformance arguments.
Verification anchors
compiler/crates/beskid_analysis/src/analysiscompiler/crates/beskid_analysis/src/analysis/rules/stagedcompiler/crates/beskid_analysis/src/analysis/diagnostic_kinds.rs
-
This feature defines how semantic rules are scheduled and how their findings map to stable diagnostic kinds. The primary
Context
This feature defines how semantic rules are scheduled and how their findings map to stable diagnostic kinds. The primary implementation roots are
beskid_analysis/src/analysis, staged rule modules underanalysis/rules/staged, and services that expose diagnostics to CLI/LSP consumers.Decision
The reference compiler must implement Rules and diagnostics catalog as documented in this feature hub and its article bundle.
Consequences
Changes require hub/ADR updates and verification anchor extensions.
Verification anchors
compiler/crates/beskid_analysis/src/analysiscompiler/crates/beskid_analysis/src/analysis/rules/stagedcompiler/crates/beskid_analysis/src/analysis/diagnostic_kinds.rs
- Contracts and edge cases Rule-level guarantees and high-risk semantic edge cases.
- Design model Mental model for staged semantic rules and diagnostic production.
- Examples Practical examples of semantic rule outcomes and diagnostic generation.
- FAQ and troubleshooting Common semantic-pipeline debugging questions and practical checks.
- Flow and algorithm End-to-end semantic rule flow from resolved items to user-facing diagnostics.
- Verification and traceability How semantic rule behavior is validated and traced to source modules.
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).
Why do semantic tests fail after parser changes?
Section titled “Why do semantic tests fail after parser changes?”Rules often assume specific syntax node shapes. Re-check parser output and resolver binding before changing rule logic.
Where should a new diagnostic kind be added?
Section titled “Where should a new diagnostic kind be added?”Add it in analysis/diagnostic_kinds.rs, then wire rule emission to the new kind. Do not introduce one-off string codes inside rule modules.
Why do CLI and LSP messages look different?
Section titled “Why do CLI and LSP messages look different?”Presentation may differ, but code identity and source spans must match. Validate through shared diagnostics tests and adapter checks.