Consumers need one contract.
Project manifest contract
Platform spec feature
Project manifest contract
Spec standingStandard
-
Hub authority
Context
Decision
Hub owns Project.proj normative text.
Consequences
Mod/Template on hub.
Verification anchors
manifest tests.
-
Mod and Template types
Context
Discriminate project kinds.
Decision
May declare type Mod or Template; hosts use Host + corelib.
Consequences
Links to mods/scaffolding.
Verification anchors
project fixtures.
- Contracts and edge cases Strict guarantees and failure modes for Mod project manifests.
- Design model Conceptual model for `Project manifest contract` and its subsystem boundaries.
- Examples Concrete examples for `Project manifest contract` decisions and usage patterns.
- FAQ and troubleshooting Project manifest tooling FAQ.
- Flow and algorithm Manifest validation and Mod package discovery flow.
- Project link libraries Normative project.link block for Extern library resolution at link time (v0.3).
- Verification and traceability Verification for tooling-side project manifest contracts.
0 revisions (git unavailable at build; counts may be empty)
No commits recorded for this path.
| Section id | Required | Found |
|---|---|---|
what-this-feature-specifies | yes | yes |
implementation-anchors | yes | yes |
Full tree: run pnpm verify:platform-spec-layout (writes src/generated/platform-spec-layout-report.json).
What this feature specifies
Project manifest contract defines one operational contract that a newcomer can follow end-to-end: first the model, then execution flow, then strict guarantees, concrete examples, and verification guidance.
Implementation anchors
- Manifest loading in
compiler/crates/beskid_analysis/src/services.rs - CLI project graph setup in
compiler/crates/beskid_cli/src/commands/ - Workspace resolution in
compiler/crates/beskid_analysis/src/resolve/items.rs - Contract tests in
compiler/crates/beskid_tests/src/projects/corelib/mod.rs
Mod project type (`Mod`)
A manifest may declare type: Mod. A Mod project is a compiler-mod package: discovered from the dependency graph, compiled AOT, and executed through SDK contracts during host compilation. See Compiler Mod SDK and Compiler Mods.
Normative project.mod keys (maxGeneratorRounds, capabilities, optional artifactPolicy) are specified in design model; examples show illustrative manifests.
v0.3 FFI: optional project.link for foreign libraries is specified in project link libraries and populated via foreign library import.
Template project type (`Template`)
A manifest may declare type: Template for template authoring packages. Consumer-facing scaffold contracts live under Project scaffolding. Instantiated host projects from templates follow normal Host rules; corelib is always implicit (no opt-out manifest flag).
Decisions
No open decisions. D-TOOL-MAN-0001 (hub authority), 0002 (Mod and Template project types)—see adr/ and the ADRs tab.
Articles
- Hub authorityHub authority
- Contracts and edge casesStrict guarantees and failure modes for Mod project manifests.
- Design modelConceptual model for `Project manifest contract` and its subsystem boundaries.
- ExamplesConcrete examples for `Project manifest contract` decisions and usage patterns.
- FAQ and troubleshootingProject manifest tooling FAQ.
- Flow and algorithmManifest validation and Mod package discovery flow.
- Project link librariesNormative project.link block for Extern library resolution at link time (v0.3).
- Verification and traceabilityVerification for tooling-side project manifest contracts.