Sibling articles under this feature previously restated requirements in inconsistent forms.
Incremental scheduling and determinism - FAQ and troubleshooting
Platform spec article
Incremental scheduling and determinism - FAQ and troubleshooting
Spec standingStandard
-
This feature hub owns normative MUST/SHOULD contract text for Incremental scheduling and determinism.
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/compiler-mods/incremental-scheduling-determinism/index.mdxarticle bundle under the same feature directory.
-
Platform-spec text supersedes informal crate comments for Incremental scheduling and determinism.
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/analysis/rules/staged/compiler/crates/beskid_lsp/
-
Incremental mod runs produced unstable ordering.
Context
Incremental mod runs produced unstable ordering.
Decision
Invalidation keys and dirty sets for mod pipelines must replay deterministically for identical inputs (Collector scope + syntax snapshot hashes).
Consequences
LSP rescan triggers share the same keys as batch compile.
Verification anchors
compiler/crates/beskid_lsp/compiler/crates/beskid_analysis/src/analysis/rules/staged/.
- Incremental scheduling and determinism - Contracts and edge cases Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads.
- Incremental scheduling and determinism - Design model Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads.
- Incremental scheduling and determinism - Examples Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads.
- Incremental scheduling and determinism - FAQ and troubleshooting Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads.
- Incremental scheduling and determinism - Flow and algorithm Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads.
- Incremental scheduling and determinism - Verification and traceability Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads.
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).
This article collects FAQ entries for Incremental scheduling and determinism.
Why separate language-meta and compiler pages?
Section titled “Why separate language-meta and compiler pages?”Language-meta defines Beskid-side mod contracts; this compiler area defines how the Rust host executes them safely and incrementally.
Can meta call arbitrary FFI?
Section titled “Can meta call arbitrary FFI?”No — unless explicitly granted by platform policy and declared in compilation capabilities. Default contracts deny ambient FFI.
Where do Roslyn/KSP parallels apply?
Section titled “Where do Roslyn/KSP parallels apply?”Only as rationale for incremental caches and typed models; Beskid contracts are authoritative here, not foreign tool behavior.