Skip to content
DocumentationAssemble a complete project
On this page

Page resources

Open Markdownllms.txtView source

Last updated

This recipe follows ParcelHub's checked canonical project. It combines owned Contracts, native One implementations, a generated Rust SDK, a framework-native Orders Desk, tests, an exact lock, and the ordinary lifecycle without adding a product-specific manifest or parallel build path.

The layout and commands below correspond to current owning evidence. Elided digests and caller-owned credential inputs remain illustrative end-product values.

Project layout

systems/system-idl/examples/parcelhub/
├── Cargo.toml
├── one.one
├── one.lock
├── one/
│   ├── contracts.one
│   ├── application.one
│   ├── system.one
│   ├── orders_get.one
│   ├── orders_place.one
│   └── orders_cancel.one
├── generated/
│   └── orders.receipt
├── src/
│   ├── generated/orders.rs
│   ├── orders_desk_terminal.rs
│   └── app/page.tsx
└── tests/
    ├── generated_sdk.rs
    └── reactive_orders.rs

The complete source is available in the ParcelHub owning example.

One canonical scope entry

one.one contains one project declaration and no implementation item:

one 1

semantic parcelhub
    domain one.project@1
    project ParcelHub@1
        source ./one/contracts.one
        source ./one/application.one
        source ./one/system.one
        source ./one/orders_get.one
        source ./one/orders_place.one
        source ./one/orders_cancel.one
        lock ./one.lock

The selected .one units remain bounded sources. Their physical co-location does not merge semantic items, implementation claims, body grammars, reachability, trust, or selection.

Independent roots

The System declaration selects two roots:

system ParcelHub@1
    root parcelhub_embedded
        include OrdersService
        build development
        build release
        build reproducible

    root parcelhub_orders_desk
        include OrdersDeskApplication
        source OrdersDeskApplication from parcelhub.build#OrdersDeskWeb@1
        activate parcelhub.test#OrdersDeskHealth@1
        activate parcelhub.projection#OrdersTypeScript@1
        build development
        build release
        build reproducible

parcelhub_embedded closes the native order service. parcelhub_orders_desk closes the framework-native Next/TypeScript presentation, its readiness scenario, and exact client projection. Sharing a project does not merge their source, artifacts, providers, credentials, or grants.

Verify the owning code

cargo test -p parcelhub --all-targets
cargo check -p parcelhub --no-default-features

one init systems/system-idl/examples/parcelhub --offline
one check \
  --workspace systems/system-idl/examples/parcelhub --offline

The Cargo tests own generated-SDK parity, exact process-local dispatch, operator-language uncertain-outcome behavior, and exact-key reactive query behavior. The project check reparses and normalizes the canonical sources through the exact lock.

Inspect without selecting or mutating

one inspect parcelhub.system#OrdersService@1 \
  --workspace systems/system-idl/examples/parcelhub --format json

one inspect parcelhub.implementation#OrdersGetOne@1 \
  --workspace systems/system-idl/examples/parcelhub --format json

one inspect root:parcelhub_embedded \
  --workspace systems/system-idl/examples/parcelhub --format json

These views distinguish normalized component meaning, an implementation claim, and root reachability. Candidate visibility is not Planning selection, Build realization, binding, or authority.

Exercise the public lifecycle

The focused owning integration test supplies disposable provider packages and request values in a temporary directory, then invokes the checked-in project through the public CLI:

cargo test -p one-cli --test parcelhub_lifecycle \
  parcelhub_native_one_workflow_retains_interpreter_receipt \
  -- --exact --nocapture

The complete release path remains:

init/adopt -> invoke local -> release -> approve -> apply -> inspect -> reconcile

Provider packages, configuration, OCS requests, credentials, and release evidence used by the integration test are owning test inputs. They do not become ParcelHub source, an ambient provider catalog, or product acceptance by mere fixture presence.

Continue with Build a typed service, Use a framework-native application, Build a durable workflow, and Ship and inspect a release.