Choose a problem that crosses an interface.
A good first operation has clear inputs, a bound implementation and more than one place where its behavior must remain consistent.
Choose something your team already maintains: an action shared by the application and an API, or an existing operation you want to expose to an agent.
- Name the operation and its current owner.
- Identify the entry points that invoke it.
- Write down one rule that must hold and one failure you can reproduce.
Choose an evaluation that can teach you something.Explore a situation · 3 ways to look closer＋
Keep the existing application. Make one operation explicit, then decide what the next useful proof would be.
Start with behavior you can compare.
An existing account lookup already returns a useful result to an API consumer.
The operation gains an explicit input, result, errors and ownership boundary.
Its business implementation can remain in place.
Compare the current route with the new binding using the same valid and invalid cases. Widen the scope only after the difference is understood.
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.
Choose the evaluation path that matches the evidence.
The first-operation walkthrough is a source-guided explanation. It shows the contract and implementation boundary without presenting an untested install as a complete quickstart.
Published package availability is tracked separately. The 27 October 2026 audit found public artifacts, but did not establish that they reproduce the current source architecture in a clean consumer installation.
| Path | Useful for | Check before proceeding |
|---|---|---|
| Source-guided walkthrough | Understanding the model and the maintained example | Source access and the pinned snapshot |
| Published package evaluation | Trying a particular published version in your environment | Compatible dependency set and a verified recipe |
| Source preview | Inspecting newer capabilities | Branch, prerequisites and qualification limits |
Write down the behavior you intend to preserve.
Define required input, successful outcomes and meaningful failures. Identify the caller context and the policy or approval decisions the runtime needs.
Keep business work in the handler. A useful contract makes that handler's obligations clearer; it does not replace your implementation.
Read the first-operation walkthrough →Connect two useful entry points.
Bind one implementation, then expose it through the supported paths your product actually uses. An application form that invokes a REST route shares that route's execution boundary.
Supply the host identity and authority context explicitly. Do not infer permission from a visible button, an MCP annotation or a descriptive tag.
Adopt into an existing codebase →Check a result you can observe.
Run an allowed request and a rejected request. Where approval is required, verify that the rejected call never enters the handler. Inspect each adapter's actual result rather than assuming every protocol uses the same response shape.
For a successful call, record the operation version, outcome and actual effect. If you use fixture identity or simulated providers, retain that label in the result.
Design meaningful checks →Choose the check that answers the question.Examine the support · 3 ways to look closer＋
One green check cannot establish every boundary. Connect the intended claim with the smallest observation that can support it.
Observe a denied call through the real entry point.
The operation explicitly requires approval, and the request otherwise has valid input.
A disposable counter or fake outbox can reveal whether the handler was entered.
A hidden button or mocked always-allow verifier cannot establish the guard.
Omit the required receipt, inspect the adapter’s canonical failure and verify the effect remains untouched in your actual test.
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.
Expand only where the first operation helps.
Review what became explicit, which definitions stopped being duplicated and what integration work remained. Record any friction that would recur across the next ten operations.
If the benefit is clear, extend to another operation or add role-aware presentation and composition. If it is not, keep the evaluation bounded and revisit the fit.
Explore the wider product model →Bring a real operation to the conversation.
Share what the operation does, the interfaces that invoke it and the failure or maintenance cost you want to address.
A scoped adoption discussion can establish the implementation work, the result to verify and any commercial terms before you commit.
Discuss your operation →