Sibling articles under this feature previously restated requirements in inconsistent forms.
Design model
Platform spec article
Design model
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).
Semantic analysis is modeled as a staged rule engine:
- Resolver prepares symbol and type context.
- Rule modules read that context and emit typed issues.
- Issue kinds map to stable code/category metadata.
- Service adapters project the same issue identity into CLI and LSP output models.
For newcomers, the key idea is separation of concerns: rule logic decides what is wrong, while diagnostics infrastructure decides how it is labeled and surfaced.
Meta and meta-host diagnostics
Section titled “Meta and meta-host diagnostics”Codes E1801–E1899 are owned by manifest, workspace, mod host, emit merge, and mod contract validation—not by ordinary semantic rules. When adding mod-related failures, update Diagnostic code registry / design model first, then reference the new code from rule modules or manifest validators so the catalog remains single-sourced.