mod host bridge - Flow and algorithm

Platform spec article

mod host bridge - Flow and algorithm

Back to Mod host bridge ◎ 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 Mod host bridge.

   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/mod-host-bridge/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 Mod host bridge.

   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/
   • compiler/crates/beskid_codegen/
   • compiler/crates/beskid_analysis/src/services.rs

   Open full ADR page

3. 0003-mod-aot-only-registration Mod host AOT-only with descriptor registration Accepted

   Mods previously risked manifest attach lists for discovery.

   Context

   Mod packages must export public Beskid types implementing SDK contracts; host loads AOT artifacts and mod.descriptor.json registrations—not manifest attach metadata.

   Decision

   Contract discovery uses (contractId, typeId, entrySymbol) tuples; failures emit E1821–E1870 before mod.collect.

   Consequences

   JIT mod execution is not normative; rebuild uses beskid mod rebuild.

   Verification anchors

   • compiler/crates/beskid_analysis/
   • mod artifact store paths in analysis services.

   Open full ADR page

Articles

• Mod host bridge - AOT artifact contract On-disk mod artifact layout, cache keys, export descriptor schema, and load-failure diagnostics. article Standard Reviewed Wed May 20
• mod host bridge - Contracts and edge cases Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules. article Standard Reviewed Thu Apr 30
• mod host bridge - Design model Rust-side mod host execution, AOT artifact lifecycle, capability policy, and typed merge. article Standard Reviewed Wed May 20
• mod host bridge - Examples Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules. article Standard Reviewed Thu Apr 30
• mod host bridge - FAQ and troubleshooting Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules. article Standard Reviewed Thu Apr 30
• mod host bridge - Flow and algorithm Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules. article Standard Reviewed Thu Apr 30
• mod host bridge - Verification and traceability Reference compiler-owned execution, capability policy, and communication with compile-time Beskid modules. 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.

Architecture

Compile-time mod execution flow

Reference ordering from parse through mod collection, generation, semantic analysis, rewrite, and lowering.

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
  mod host bridge

  Parent feature hub

Mod host orchestration

flowchart TB
  load[Load Mod AOT artifacts]
  collect[mod.collect target sets]
  gen[mod.generate typed AST]
  merge[Merge contributions]
  reparse{Syntax changed?}
  sem[semantic.snapshot]
  analyze[mod.analyze diagnostics]
  rewrite[mod.rewrite optional]
  load --> collect --> gen --> merge --> reparse
  reparse -->|yes bounded rounds| collect
  reparse -->|no| sem --> analyze --> rewrite

Primary flow

1. After parse (and macro.expand), mod.load registers contracts from resolved Mod projects in the dependency graph.
2. mod.collect records generator/analyzer/rewriter target sets per mod.
3. mod.generate emits typed AST contributions; the host merges and re-parses affected units when syntax changed (bounded by maxGeneratorRounds).
4. Builtin semantic rules run on the merged program; emit semantic.snapshot before analyzers read frozen state.
5. mod.analyze publishes diagnostics; mod.rewrite applies typed replacements when enabled.
6. Emit lower.ready only when the merged tree is consistent for HIR lowering.

Ordering constraints

• No mod body runs before a parseable Program snapshot exists for its compilation unit.
• Analyzers must not mutate syntax after semantic.snapshot; rewrites go through mod.rewrite only.
• Capability checks and step budgets are enforced in the Rust host before Beskid mod entrypoints run (see Incremental scheduling and determinism).