Sibling articles under this feature previously restated requirements in inconsistent forms.
Incremental scheduling and determinism - Examples
Platform spec article
Incremental scheduling and determinism - Examples
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 examples for Incremental scheduling and determinism (informative sketches aligned with contracts).
Example A — Minimal query
Section titled “Example A — Minimal query”A compile-time module reads a syntax attribute using the query API, then emits a diagnostic without mutating syntax.
Example B — Emitter sketch
Section titled “Example B — Emitter sketch”A contributor constructs a new method declaration through Beskid.Compiler.Emit, attaches trivia, and registers it with the incremental graph.
Executable snippets will track the reference implementation as mod host execution lands in the compiler; until then, treat these as specification fixtures.