Pre-launch. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

Proving a package still fits the framework — and what that does not prove

Check it follows the rules

People ask this as: validate a plugin against a framework contract before shipping it

A generic conformance harness that composes a package into a throwaway copy of the project, boots the application twice, attaches and detaches it, and reports what the framework's own machinery says — declaration, source boundaries, composition refusals, module manifests and migration identity, lifecycle, and agreement with the inspector. No package is special-cased by name, a check that cannot run is skipped or not-applicable with a reason rather than passed, and twelve limitation codes say what conformance is not: it proves nothing about whether the domain logic is right.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • It proves framework conformance only. Whether the package computes, decides or promises the right thing is what its own tests are for (DOMAIN_CORRECTNESS_NOT_PROVEN).
  • It executes no declared action, drives no declared state transition and evaluates no policy behaviour — those need records only the domain knows how to create (ACTION_EXECUTION_NOT_ATTEMPTED, STATE_TRANSITIONS_NOT_DRIVEN, POLICY_BEHAVIOUR_NOT_EVALUATED).
  • Child-process isolation is not a sandbox. The package runs with the operator's authority and could write anywhere that operator can write, including the caller's project (PACKAGE_SOURCE_TRUSTED, PROCESS_ISOLATION_BOUNDED, SCRATCH_PROJECT_ONLY).
  • It never opens the caller's database. The scratch database is created empty and destroyed with the scratch project (DATA_NOT_INSPECTED).
  • It contacts, authenticates and health-checks no provider, and reads no secret, credential or environment value (PROVIDER_HEALTH_UNKNOWN, SECRETS_NOT_INSPECTED).
  • A data-bearing module upgrade is not exercised: that needs two manifests one revision apart, and a package ships one manifest per record (UPGRADE_NOT_EXERCISED).
  • It does not check package-contributed HTTP routes — the framework has no seam for them, and that gap is tracked rather than tested around.
  • A conforming result says the package fits this framework. It says nothing about whether the package should be trusted: there is no signing, no provenance and no isolation from a package that means harm.

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. Every claim and every limitation is on one page.

What question it answers

"Does this package satisfy the framework's generic package contract and integration invariants?" One question, one answer, and the boundary stated in the same breath: it proves nothing about whether the domain logic is correct.

Its two siblings read; this one composes and boots. That distinction is why it could not be a flag on either of them.

What it does

`npm run crm -- package test <path> --json` emits `packageConformanceContract: 1` with per-check `status` and `authority`, plus `counts`, `problems`, `limitations`, a `scratch` block and both a report fingerprint and the `inspectionFingerprint` of the application it composed against.

Run here against `packages/service` it exited 0 with 26 passed, 0 failed, 0 skipped, 2 not applicable. The checks span six authorities: `authoring-rule` (private imports, cross-package imports, source shape, label, metadata), `package-contract` (declaration validity, surface, contract version, policy fingerprints), `composition` (a clean compose, its action targets, and five refusals proven by attempting them — duplicate, resource collision, capability collision, undeclared reach, unmet dependency), `module-factory` (the manifests the package applies, and their migration identity), `application-boot` (attach, detach, actions registered, capabilities resolve) and `app-inspect` (the inspector's own row for the package, its capabilities, and resource coverage). Its `scratch` block reported composing `contracts` and `service`, applying 16 manifests, one project record (`order`), and a database "created empty in a temporary copy and destroyed with it".

Run against `examples/custom-packages/partner-scorecard` it exited 1: 21 passed, 1 failed, 6 not applicable, with `declaration.action-targets` failing under authority `composition` for `UNDECLARED_PACKAGE_RECORD_DEPENDENCY`, and `scratch.undeclaredRecordOwners: ["delivery"]`. That failure is the harness's most important design decision, kept rather than engineered away. The package acts on a record `delivery` owns and declares no dependency on it; the first draft composed the owner, marked the finding not-applicable and exited 0. That is monorepo magic — the package only works because this repository happens to contain `delivery`, and a third-party consumer would get a different answer. So the teaching example in this repository does not conform, and the report says so.

Four cases are graded differently and the difference is the point: a record the package owns passes, a record no package owns passes (it is a host-application record — every package here acts on `order`, which a project supplies), a record a declared dependency owns passes (the coupling is record-level, which `requires` cannot express, but the relationship is visible in the graph), and a record an undeclared package owns fails.

No package name appears in harness code. The official matrix is a test, not a code path — and one of the four packages that runs through it legitimately fails.

What it refuses to claim

Twelve codes in `limitations[]`. The first is the headline: `DOMAIN_CORRECTNESS_NOT_PROVEN` — this command proves framework conformance only; whether the package computes, decides or promises the right thing is what its own tests are for, and nothing here is evidence about it. Then `PACKAGE_SOURCE_TRUSTED` and `PROCESS_ISOLATION_BOUNDED` state the trust boundary in the exact three clauses the review forced: no intentional mutation of the caller's project, trusted source running with the operator's authority, and isolation that is not a filesystem, network or OS sandbox.

`SCRATCH_PROJECT_ONLY` is unusually candid: the harness writes only inside a temporary copy and removes it afterwards, and it cannot prevent package code from writing wherever the operator can write — including the caller's project — because that code runs with the operator's authority. An earlier version imported the package from the caller's own tree, so a package writing beside its source wrote into the caller's repository; the scratch copy is now built first from filesystem facts alone, and the package is imported from the copy.

`UNDECLARED_OWNER_COMPOSED_LOCALLY` explains the failure above: when an action targets a record another package owns, that owner is located in this project and composed so the rest of the report can still be produced — which is exactly why an undeclared owner is reported as a failure rather than rescued.

The remaining five bound what a conformance pass covers. `ACTION_EXECUTION_NOT_ATTEMPTED` (no declared action is executed; driving one needs records only the domain knows how to create). `STATE_TRANSITIONS_NOT_DRIVEN` (declared `fromStates` are published, never exercised — a generic probe has no record in any of those states). `POLICY_BEHAVIOUR_NOT_EVALUATED` (a policy is checked for identity, declared config and a fingerprint; what it decides is domain behaviour). `UPGRADE_NOT_EXERCISED` (module evolution needs two manifests one revision apart, and a package ships one per record). Plus `PROVIDER_HEALTH_UNKNOWN`, `SECRETS_NOT_INSPECTED` and `DATA_NOT_INSPECTED`.

A check that cannot run is `skipped` or `not_applicable` with a reason code, never `passed`, and no failure is ever demoted to a limitation to make an official package green. Every row names the authority it speaks for, drawn from a closed list with no entry for the harness itself — a rule this command would have had to invent is either advisory or absent.

What it costs to run

Measured here on 2026-08-09: about 2.3 s wall clock for `packages/service --json`, which is roughly an order of magnitude more than the source-only checks and three orders less than a full verification run. The ExecPlan records ~1,710 ms for one package on this repository.

Exit codes: `0` conforms, `1` conformance failures, `2` the package or project could not be read. Both observed runs matched — service 0, partner-scorecard 1.

It writes nothing to your project. The scratch copy is removed on success, on failure and on timeout, and the scratch database is created empty and destroyed with it; the caller's configured database is never opened. Output is deterministic across runs, processes, working directories and a path containing spaces, and contains no absolute path, scratch location, stack frame, SQL, source body or secret.

Imports and boots run in their own process group under a timeout and byte bounds, with the report on file descriptor 3, so a package that hangs, floods a stream, spawns a grandchild that holds the pipe open, or calls `process.exit` produces a stable outcome and never hangs the parent.

Where it fits

It is what makes the package seam self-enforcing rather than a convention: the scaffold exists because there is now a command that can grade its output, and the two were designed against each other.

The jobs it touches are recorded conservatively. Creating and composing a custom package and depending on another package through a declared capability are validated end to end; validating a package before booting it and removing one without losing its data are only partially supported; running an untrusted package safely is not supported and is not planned at this layer — repository source is trusted, and the consumer name passed when opening a capability is asserted by the caller.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-13 A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares.

    LimitNo scaffold, no registry, no marketplace, and no sandboxing — package code runs with the host process's authority. Detaching leaves its data behind; there is no uninstall.

  • C-19 Generated modules evolve without rewriting history: explicit revisions, a checked-in state file and append-only named migrations.

    LimitThe view is source-only: what the checked-in revisions and migrations say is knowable; what a particular database has actually applied is not.

  • C-17 Zero third-party runtime dependencies. Node 22 and a checkout — no build step, no bundler, no framework underneath your framework.

    LimitDevelopment dependencies and the eventual PostgreSQL adapter are separate questions. Having no runtime dependencies is a property of the framework, not of whatever you add on top of it.

Limitations

  • L-08 Ownership today means copying source, not installing a dependency. There is a project bootstrap and there is no published package, and the two are different facts. The repository's bootstrap command scaffolds a project that boots, reports `valid` from `app inspect` and exits 0 from `project doctor`, offline and with no install — run from a checkout of this repository. The package published under the reserved npm name is still an empty 0.0.1 placeholder, so the `npm create` route installs nothing until a human publishes it. Either way the framework is vendored into the project rather than depended on by version: you own the result outright, and upgrading means merging, not bumping.
  • L-01 No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.

Jobs it covers

Documented in

Proved by