Find the right reference
Navigate portable models, runtime execution, adapters and generated contract records by responsibility.
Source and verification context ⌄
Source-guided
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 reference that answers your question
Guides explain how to accomplish a task; reference records explain a particular surface. Start with the layer that owns your question so a package catalogue does not become your learning path.
Read the supporting context
The inspected generated manifest contains 1,300 records. The public explorer shows eligible public reference metadata; internal, mixed or unspecified records stay out of its default results. Reference records describe source surfaces, not independently verified tutorials.
Explore a section, then continue with the complete article below.
Choose the reference that answers your question
Guides explain how to accomplish a task; reference records explain a particular surface. Start with the layer that owns your question so a package catalogue does not become your learning path.
The inspected generated manifest contains 1,300 records. The public explorer shows eligible public reference metadata; internal, mixed or unspecified records stay out of its default results. Reference records describe source surfaces, not independently verified tutorials.
| Question | Owner to inspect | Useful source |
|---|---|---|
| What does an operation declare? | Portable contracts | contracts-spec operation model |
| What runs before a handler? | Runtime kernel | operations/prepare and registry |
| How does HTTP or MCP expose a call? | Delivery adapter | REST handler or MCP registration |
| How are role surfaces selected? | Surface runtime | RoleMorph resolver |
| What does this specific contract contain? | Generated reference | Key, version and declaration source |
| Where is a public import supported? | Package export map | The selected version's package.json |
Give an agent a coherent slice of the system.Trace the mechanism · 3 ways to look closer＋
An agent is asked to change one operation. A useful context packet keeps the task, source identity and execution responsibilities together.
Start with orientation and a bounded reference.
The task names a capability but not the package that owns it.
Read the relevant area and task context.
An area overview and package overview narrow the source set.
A package listing does not establish registry availability or permission to edit it.
Choose the relevant package and source identity, then follow the exact manual or structured source data.
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.
Read a reference record
Use the contract key as its identity, then inspect the version, kind, ownership and stability where available. Follow the declaration source for the full model and the relevant handler or runtime for execution behavior.
A stability field describes the contract's declared status. It does not establish that an integration was exercised against a live provider or that a package has been installed outside the monorepo.
Understand generated lineage
The existing docs loader reads a manifest, loads metadata chunks and resolves each record's Markdown content from the generated docs tree. Update the owning declaration or DocBlock, then regenerate; do not make permanent edits to the generated JSON.
The inspected manifest uses a deterministic generatedAt value and has no release version. Treat that as a reproducibility mechanism with missing release provenance, not as a meaningful freshness date.