beskid mod CLI

Mods ship like other Beskid packages—manifest, graph, lockfile—but consumers only load them if AOT output exists for the active target.

Workflow sketch

1. Create or open a type: Mod project (Project manifest).
2. Implement public types satisfying SDK contracts (Collector, Generator, …).
3. beskid build the mod for the target triple you need in downstream compiles.
4. Add the mod package to app/lib dependencies; host discovers exports at mod.load.

CLI details evolve—cross-check CLI command reference and build for flags your workspace supports.

Artifacts

Normative contract: AOT artifact contract.

Expect:

• Native object for the triple
• mod.descriptor.json (or equivalent export table) listing contract entrypoints

Missing artifact for the requested triple → fail closed, not “skip mod silently.”

Testing mods

• Unit-test Beskid logic in test items where possible.
• Platform behavior locks live in beskid_tests with spec updates (Conformance).

Next

Pipeline phases