Repository links may require access. Source inspection is separate from a clean public-package installation.
AN INTERACTIVE READING MAP
Get the shape of this guide.
Move through the ideas, inspect their relationships, or make a focused reading path. The complete guide stays below.
⌘↗
READING SEQUENCEUnderstand how the ideas connect
Choose a point to look closer ↓
01 / Guide section
Know which version you mean
A contract's version identifies a particular declared behavior. A package version identifies a distribution artifact. A website or application revision identifies a deployment. Those numbers can change independently.
Read the supporting context +
When reporting a problem, include the contract key and version plus the package versions or source commit. The documentation shell's version is not enough to identify the operation a consumer is executing.
Explore a section, then continue with the complete article below.
1 / 4
Know which version you mean
A contract's version identifies a particular declared behavior. A package version identifies a distribution artifact. A website or application revision identifies a deployment. Those numbers can change independently.
When reporting a problem, include the contract key and version plus the package versions or source commit. The documentation shell's version is not enough to identify the operation a consumer is executing.
Identifier
Example of its role
Use it to
Contract key + version
A specific operation definition
Resolve a referenced behavior
Package name + version
A published artifact
Reproduce dependencies and imports
Source commit
An immutable code snapshot
Inspect implementation and generated lineage
Deployment revision
A running application build
Correlate production behavior with release evidence
⇄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.
What changed in your situation?
A CONCRETE SITUATION
Compare the contract and its consumers.
An operation now requires an extra input or a stricter approval condition.
What changes
The declared behavior and which existing requests succeed may change.
What stays explicit
A package number or website revision is not enough to identify the selected operation.
FOLLOW THE CONSEQUENCE
Record the contract key and version. Plan how older callers move to the new requirement.
Use explicit references where reproducibility matters
The portable VersionedSpecRef model contains a key and version. OptionalVersionedSpecRef permits the version to be omitted, typically selecting the latest available definition through the owning resolver.
Use explicit versions in examples and compatibility tests that must be reproducible. If you intentionally use latest-version selection, test what happens when the registry receives a newer definition.
Exact type shape from contracts-spec/src/versioning/refs.ts at d58fa5b7; comments omitted.
Review the behavioral change
Compare inputs, outputs, named failures, policy requirements and effect expectations. Adding a required input can break an existing caller even when the handler remains unchanged. Tightening an approval rule can change which requests succeed.
Plan how old consumers transition: keep the old contract temporarily, provide an intentional mapping, or coordinate an upgrade. Do not silently repoint a stable example at a different behavioral contract.
Publish the matching documentation
Pin source links and examples to the release they describe. Generate reference output from that same source and retain the provenance in the docs artifact. Update prose when an import path or execution guarantee changes.
When a source refactor preserves a compatibility facade, explain both the canonical owner and the supported historical import. Ownership moving between packages is not automatically a consumer migration.
See it in an example.
Agents / Advanced
Review an agent's migration proposal
Control side effects
Follow a deterministic release migration through scoped subagents, digest-bound approval, and a draft PR receipt.
01
Compile the application
02
Inspect the migration scope
03
Bind approval and apply once
Source demonstratesThe inspected source asserts separate subagent authority and digest-bound approval.
Does not demonstrateA real patch applied to a user's repository or an actual GitHub PR.
Inspect the walkthroughBehavior · proof and limits · source checks+
Follow the source behavior
A fixture release removes billing.invoices.createLegacy and identifies two affected consumer files. The reference separates impact analysis, migration, and independent verification, then produces governed patch and draft-PR evidence without contacting GitHub.
Compile the application
The source compiles the release-steward filesystem application and inspects required approvals for patching, draft PR creation, and selected delegation tools.
Inspect the migration scope
The fixture calculates an immutable source digest and identifies the affected billing files. Subagent evidence records permitted tools and denied effects, including auto-merge.
Bind approval and apply once
Tests assert that approval is bound to migration digests, changed material invalidates it, and the patch invocation occurs once even when replayed.
Read the remaining qualification
The fixture's PR URL is under github.example.test, its PR is a draft, and autoMerge is false. Adapter and deployment composition results explicitly remain candidate with unresolved live requirements.
What this example establishes+
Source demonstrates
The inspected source asserts separate subagent authority and digest-bound approval.
Tests assert one application invocation, replay evidence, a draft result, and no auto-merge.
Candidate readiness retains unresolved requirements for exact live environments.
Does not demonstrate
A real patch applied to a user's repository or an actual GitHub PR.
Successful CI in a production repository; this fixture reports deterministic CI evidence.
Production isolation or deployment qualification merely because a topology composes.
Look inside the guideOpening context · complete reading path+
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.
Look inside the guideOpening context · complete reading path+
Separate authored behavior from derived artifacts
Keep the contract and the business implementation distinct from files produced by tooling. Review the source that owns a change, then regenerate the affected output instead of patching a derived file as the permanent fix.
Look inside the guideOpening context · complete reading path+
Read the instructions for the selected checkout
Begin with the repository's AGENTS.md and the instructions in the owning package. The integration branch is actively changing, so locate the current owner rather than relying on a historical directory map.