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 Crate-to-spec anchors.
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/implementation-map/crate-to-spec-anchors/index.mdxarticle bundle under the same feature directory.
-
Platform-spec text supersedes informal crate comments for Crate-to-spec anchors.
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/
-
Canonical index from compiler crates to platform-spec features.
Context
Crate references were scattered across hubs without a single ownership surface.
Decision
This feature hub is the canonical map from
compiler/crates/*to platform-spec features; other pages link here instead of duplicating tables.Consequences
New crates require anchor rows before Standard promotion of dependent features.
Verification anchors
- Implementation-map articles and
compiler/Cargo.tomlworkspace layout.
- Implementation-map articles and
- Contracts and edge cases Normative guarantees and known edge cases for `Crate-to-spec anchors`.
- Design model Conceptual model for `Crate-to-spec anchors` and its subsystem boundaries.
- Examples Practical examples that demonstrate `Crate-to-spec anchors` behavior.
- FAQ and troubleshooting Common questions and debugging guidance for `Crate-to-spec anchors`.
- Flow and algorithm End-to-end control flow and major algorithmic steps for `Crate-to-spec anchors`.
- Verification and traceability How `Crate-to-spec anchors` requirements map to tests and implementation anchors.
0 revisions (git unavailable at build; counts may be empty)
No commits recorded for this path.
| Section id | Required | Found |
|---|---|---|
what-this-feature-specifies | yes | yes |
implementation-anchors | yes | yes |
Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).
Map role
Section titled “Map role”This feature is the maintenance index between Rust crates and normative spec leaves. When you change behavior in a crate, update the linked spec article in the same change set; when you add a spec contract, anchor it to the owning crate here.
flowchart TB
subgraph cli_tooling [CLI / LSP / pckg]
cli[beskid_cli]
lsp[beskid_lsp]
pckg[beskid_pckg]
end
subgraph analysis [beskid_analysis]
proj[projects graph]
fe[front_end + mod_host]
sem[analysis rules]
end
subgraph codegen [beskid_codegen]
lower[lowering services]
end
subgraph exec [beskid_abi + beskid_runtime + beskid_engine]
abi[ABI tables]
rt[runtime builtins]
eng[JIT / AOT]
end
cli --> proj
lsp --> proj
proj --> fe --> sem --> lower --> eng
lower --> abi
eng --> rt
Primary actors
Section titled “Primary actors”| Actor | Responsibility |
|---|---|
| Producer crates | Emit diagnostics, artifacts, and ABI metadata (beskid_analysis, beskid_codegen) |
| Consumer crates | Execute or validate artifacts (beskid_engine, beskid_runtime, tooling) |
| Conformance crates | Pin observable behavior (beskid_tests, beskid_e2e_tests) |
Crate quick anchors
Section titled “Crate quick anchors”beskid_analysis— parser, resolution, semantic pipeline, mod hostbeskid_codegen— lowering contractbeskid_abi+beskid_runtime— execution ABI/runtime leavesbeskid_tests+beskid_e2e_tests— conformance leaves
Compiler mod anchors (reference compiler)
Section titled “Compiler mod anchors (reference compiler)”| Concern | Primary crates | Spec leaves |
|---|---|---|
| Stable pipeline phase ids | beskid_pipeline | Stage ordering |
Manifest + graph + CompilePlan | beskid_analysis::projects | Project manifest contract, Workspace resolution contract |
| Program assembly + effective roots | beskid_analysis::projects::assembly, beskid_analysis::services::front_end | Program assembly |
| Parse + SyntaxMirror | beskid_analysis::syntax, beskid_analysis::parser | Syntax domain model generation, SyntaxMirror facade |
| Mod host orchestration | beskid_analysis::mod_host (discovery, load, capabilities, collect, generate, merge, reparse, analyze, rewrite) | Mod host bridge, Incremental scheduling and determinism |
| Mod host service integration | beskid_analysis::services::analyze, beskid_codegen::services | Stage ordering, Typed emitter and transforms |
| Mod diagnostics + facades | beskid_analysis::analysis, beskid_analysis::query | Analysis, query, and diagnostics facades, Diagnostic code registry |
| Analyzer/rewriter staging | beskid_analysis::analysis::rules::staged | Rules pipeline contract |
| Lowering after typed merge | beskid_codegen::services | Stage ordering, Typed emitter and transforms |
| LSP parity | beskid_lsp | Diagnostics and workspace analysis |
| Incremental tests | beskid_tests | Incremental scheduling and determinism |
| Pipeline composition (Rust) | beskid_pipeline, beskid_analysis | Pipeline composition |