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.rsThe 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 --offlineThe 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 jsonThese 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 --nocaptureThe complete release path remains:
init/adopt -> invoke local -> release -> approve -> apply -> inspect -> reconcileProvider 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.