Skip to content
Beskid Platform specification

Beskid

Jump to a Beskid service

Beskid

Jump to a Beskid service

Flow and algorithm

Platform spec article

Flow and algorithm

Back to Build, analyze, and run contract Open feature in platform map

Spec standingStandard

Owner
Piotr Mikstacki
Submitter
Piotr Mikstacki

Startup

Section titled “Startup”
  1. Expand response files (argfile) and parse global flags.
  2. Initialize logging (BESKID_LOG_CRANELIFT / --log-cranelift).
  3. ensure_corelib_ready — materialize or locate bundled corelib before any project command runs.
  4. Dispatch the selected subcommand.

Project-scoped command flow

Section titled “Project-scoped command flow”
sequenceDiagram
  participant User
  participant CLI as beskid_cli
  participant Analysis as beskid_analysis
  participant Backend as JIT or AOT
  User->>CLI: subcommand + ProjectResolveArgs
  CLI->>Analysis: resolve manifest + lock policy
  Analysis-->>CLI: CompilationContext + CompilePlan
  CLI->>Analysis: semantic pipeline (+ mods)
  alt analyze / doc
    Analysis-->>CLI: diagnostics / api.json
  else build
    CLI->>Backend: lower + AOT link
  else run / test
    CLI->>Backend: JIT entrypoint
  end
  CLI-->>User: exit code + artifacts

analyze

Section titled “analyze”
  1. Resolve input to a host target and CompilationContext.
  2. Run the semantic pipeline with builtin (+ mod) rules.
  3. Print diagnostics to stderr (miette rendering); non-zero exit when errors exist.

build

Section titled “build”
  1. Resolve CompilePlan and target kind (App, Lib, Test).
  2. Lower through beskid_codegen with pipeline observation.
  3. Invoke beskid_aot::build with profile, link mode, and runtime strategy flags.
  4. Write object/shared/static/executable per --kind and target defaults.

run / test

Section titled “run / test”
  1. Resolve entry module and optional --entrypoint.
  2. JIT-compile via beskid_engine and execute; test discovers test items and aggregates results.

Workspace maintenance (fetch, lock, update)

Section titled “Workspace maintenance (fetch, lock, update)”

These commands mutate or verify the materialized dependency tree and Project.lock before host compilation. They share graph resolution with build/run but do not themselves lower user code.

Lockfile interaction

Section titled “Lockfile interaction”

When LockfilePolicyArgs require a lock, the CLI must fail fast if Project.lock is missing or stale relative to manifests, rather than silently fetching in release-critical paths unless the command documents otherwise (update vs build defaults).

Verification hooks

Section titled “Verification hooks”

Integration coverage lives in compiler/crates/beskid_tests/src/analysis/pipeline/core.rs and command-specific tests beside each commands/*.rs module.