Incremental scheduling and determinism - Verification and traceability

Platform spec article

Incremental scheduling and determinism - Verification and traceability

Back to Incremental scheduling and determinism ◎ Open feature in platform map

Spec standingStandard

Owner

Piotr Mikstacki pmikstacki@cybernomad.it

Submitter

Piotr Mikstacki pmikstacki@cybernomad.it

Current document

ADRs (3)

1. 0001-feature-hub-authority Feature hub authority Accepted

   This feature hub owns normative MUST/SHOULD contract text for Incremental scheduling and determinism.

   Context

   Sibling articles under this feature previously restated requirements in inconsistent forms.

   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.mdx
   • article bundle under the same feature directory.

   Open full ADR page

2. 0002-spec-over-implementation-notes Specification over implementation notes Accepted

   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/

   Open full ADR page

3. 0003-mod-invalidation-deterministic-replay Deterministic mod invalidation and replay Accepted

   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/.

   Open full ADR page

Articles

• Incremental scheduling and determinism - Contracts and edge cases Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads. article Standard Reviewed Thu Apr 30
• Incremental scheduling and determinism - Design model Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads. article Standard Reviewed Fri May 01
• Incremental scheduling and determinism - Examples Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads. article Standard Reviewed Thu Apr 30
• Incremental scheduling and determinism - FAQ and troubleshooting Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads. article Standard Reviewed Thu Apr 30
• Incremental scheduling and determinism - Flow and algorithm Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads. article Standard Reviewed Thu Apr 30
• Incremental scheduling and determinism - Verification and traceability Cache boundaries, invalidation keys, and replay guarantees for mod outputs and Mod SDK reads. article Standard Reviewed Thu Apr 30

History

0 revisions (git unavailable at build; counts may be empty)

Open full history on GitHub

No commits recorded for this path.

Completeness

OKfeature · 0 SpecSection(s) · 3 H2 heading(s)

Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).

Related spec docs

• Feature
  Incremental scheduling and determinism

  Parent feature hub

This article documents verification and traceability for Incremental scheduling and determinism.

Traceability matrix

• Anchor: compiler/crates/beskid_analysis/src/analysis/rules/staged/ — precedent for staged invalidation.
• Anchor: compiler/crates/beskid_lsp/ — incremental document models and rescan triggers.

Verification expectations

• Key tuple replay — Tests under compiler/crates/beskid_tests/src/projects/ (or a dedicated meta_incremental/ subdirectory) must assert that when syntax_generation_id, capture_fingerprint, manifest_generation_id, and capability_set_id match a prior run, the host skips re-execution of process-only work; when any id changes, caches miss deterministically.
• Isolating vs aggregating — Pairwise fixtures demonstrate narrow vs wide dirty sets as described in design model.
• LSP alignment — Mirror at least one replay scenario through compiler/crates/beskid_lsp session tests so soft vs hard invalidation matches Snapshot and refresh contract.
• Golden traces (optional) — Record ordered phase ids + cache hits for regression when mod host complexity grows.

Review cadence

• Update this bundle whenever public Beskid.Compiler.* shapes or host policies change.