Installation and release channels
Match documentation to the code you actually consume, then verify a small external project.
Source and verification context ⌄
Registry verification pending
Inspect the source ↗Repository links may require access. Source inspection is separate from a clean public-package installation.
Get the shape of this guide.
Move through the ideas, inspect their relationships, or make a focused reading path. The complete guide stays below.
Choose the code you are evaluating
There are two useful starting points: consuming published packages in your application, or studying a checked-out repository snapshot. Select one explicitly. Instructions for a monorepo can rely on workspace dependencies and repository scripts that a package consumer does not have.
Read the supporting context
For this preview, the architecture and excerpts come from integration commit d58fa5b7de53a947811e5cc68346be028ce18528. The remote release branch was separately observed at b67c376f35354177f1f56a5f88c78d74d19586ce. Neither identifier is a promise that the same bytes are available from a public package registry.
Explore a section, then continue with the complete article below.
Choose the code you are evaluating
There are two useful starting points: consuming published packages in your application, or studying a checked-out repository snapshot. Select one explicitly. Instructions for a monorepo can rely on workspace dependencies and repository scripts that a package consumer does not have.
For this preview, the architecture and excerpts come from integration commit d58fa5b7de53a947811e5cc68346be028ce18528. The remote release branch was separately observed at b67c376f35354177f1f56a5f88c78d74d19586ce. Neither identifier is a promise that the same bytes are available from a public package registry.
| Channel | Use it for | Record |
|---|---|---|
| Published package | Adding a supported version to your product | Exact package names, versions, registry and lockfile |
| Source snapshot | Reading implementation or contributing | Commit SHA, repository setup and owning-package scripts |
| Managed application | Evaluating a hosted product | Application release and supported deployment scope |
Ask which identity changed.Compare the choices · 3 ways to look closer＋
An operation, a package and a deployed application can change independently. Use the identifier that answers the question you are investigating.
Compare the contract and its consumers.
An operation now requires an extra input or a stricter approval condition.
The declared behavior and which existing requests succeed may change.
A package number or website revision is not enough to identify the selected operation.
Record the contract key and version. Plan how older callers move to the new requirement.
Where this explanation comes from
An authored situation, grounded in the linked source guides. Choosing a case explores its expected responsibilities; it does not execute an operation.
Current distribution status
The inspected distribution configuration declares an npm-only package closure with qualification state workspace-available. Other repository guidance still describes private GitHub Packages and a smaller public exception set. Until those sources agree and a clean consumer succeeds, this preview does not prescribe an installation command.
When selecting a release, use that release's documented registry and package names. Do not rewrite a package scope or add private credentials merely because another branch's documentation mentions them. A missing package and a missing local dependency are different problems.
Evaluate the maintained example from source
After following the setup instructions for your chosen checkout, inspect examples/minimal/package.json. Its current scripts distinguish compilation from scaffolding: build runs TypeScript compilation, scaffold invokes the repository CLI, and validate checks the example contract. This distinction matters when older prose uses build to mean generation.
The commands below are existing scripts for that example directory. They are a source-workspace check, not a verified installation procedure; they were not executed while preparing this preview.
bun run typecheck
bun run validate
bun run smokeRun from examples/minimal after repository setup. Scripts inspected in examples/minimal/package.json at d58fa5b7.
What a successful consumer check includes
Use an empty directory outside the repository, the documented supported toolchain, and no workspace links. Install the exact public artifacts, import the documented entry points, and run a tiny operation with a successful request and an expected failure.
Keep the package versions and output with the example. That makes the result reproducible and lets the docs show a precise verified-version badge later. A green repository test cannot stand in for this check.