Start with the behavior you need.

A small user.create command accepts one required email address. Its current handler returns the same email. This gives you a compact place to understand the contract and handler boundary before adding storage or authentication.

1. Describe the input

   Read UserInput in src/contracts/user.ts. The schema has one required EmailAddress field. The command uses the schema for both input and output.

2. Name the operation

   Inspect the user.create key, version 1.0.0, owner, goal, and anonymous authentication policy. These describe the operation and its boundary.

3. Follow the handler

   Open src/handlers/user-input.handler.ts. HandlerForOperationSpec derives the handler shape from CreateUser. The implementation returns input.email; it does not create a persisted account.

4. Inspect and adapt the starter

   Read the package smoke fixture and validation script. Replace the echo handler with your own behavior, then test that behavior and the contract boundary together.

A synthetic rest.approval.protected command has write and external-side-effect declarations. The fixture sends a request first without approval evidence, then with a receipt bound to the operation and input.

1. Declare the boundary

   The fixture defines a command with execution.effects set to write and external-side-effect, and execution.approval.required set to true.

2. Inspect the denied request

   The first test binds a handler with a call counter. Without a receipt, it expects HTTP 403, APPROVAL_REQUIRED with reason missing_receipt, and calls equal to zero.

3. Inspect the approved request

   The second test provides a receipt through createFetchHandler's approvalReceipt option and an approval port with a controlled clock. The response is expected to be 200 with value ran.

4. Apply the pattern to your side effect

   Replace the synthetic handler with your operation and trusted receipt source. Add tests for the exact subject, operation, input, expiry, and effect requirements your application uses.

The same sample account grid appears through ContractSpec's data-view, headless table, web primitive, and design-system layers. You can inspect how sorting, selection, expansion, loading, and empty states are represented without adopting a whole business template.

1. Start with the declarative table

   The README's DataViewSpec references a sample query and declares a table view. Its initial state uses four rows per page, descending ARR sorting, a hidden notes column, and the account column pinned left.

2. Compare rendering layers

   The showcase exposes client, server, DataView, web primitive, and native primitive lanes around the same account data. Inspect how each layer maps the shared table behavior.

3. Explore visible states

   The UI source includes pinning, sorting, row expansion, simulated loading, empty state, and an interaction log. Its smoke fixture checks rendering and selected interactions.

4. Adapt the source contract

   Replace sample account fields and the query reference with your own data contract. Establish server filtering, pagination, authorization, and performance behavior in your host application.

A customer intake can begin with a name. In the fixture, a quick capture is accepted while email, phone, and consent remain completion debt. A richer profile can then determine whether the record is ready for the next workflow.

1. Choose the form contract

   Inspect all-fields, progressive-steps, and customer-projection forms. The package includes field kinds, conditional rules, sections, and step layouts.

2. Inspect minimal intake

   The quick-capture fixture contains a customer ID and display name. The smoke test expects capture to succeed and completion to remain incomplete with email, phone, and consent debt.

3. Inspect conditional validation

   Another test builds Zod validation with relations and expects a missing repeated contact value to be reported at contacts[0].value.

4. Use the public proof map

   The proof-config export lists docs, sandbox, forms, and UI entrypoints. Adapt through the supported exports, then supply your own persistence and submission behavior.

An internal budget request reaches a founder, operations manager, frontline staff member, customer, AI agent, or auditor. Each role receives a relevant surface. Vendor commitment and budget exceptions retain explicit action boundaries across those views.

1. Inspect the roles

   The internal approval fixture defines six roles and components for budget risk, vendor queues, requester status, agent procurement planning, and audit history.

2. Separate permissions from policy

   The operations manager can be eligible for vendor selection while a budget exception still requires approval. The agent plan blocks vendor commitment and marks the budget exception as requiring approval.

3. Change presentation hints

   The related service-delivery fixture compares plain and adaptive contexts and asserts unchanged action boundaries. The internal-approval fixture separately tests vendor restrictions and budget approval. Presentation guidance does not create authority.

4. Inspect the restricted view

   The customer fixture hides protected actions and tests that explanations do not expose redacted information. Apply the same checks to the roles and data in your own workflow.

A reference application composes Integration, Agent System, Agent Network, Workflow, Auth User, Auth Admin, Communication, CompanyOS, and Social Media hubs with deterministic adapters. It compares web and native route projections and applies an integration settings override.

1. Read the composition fixture

   The fixture supplies the hubs' required ports with inert deterministic adapters. This makes the composition inspectable without provider credentials.

2. Compare semantic routes

   The test expects nine hub keys and equal semantic, web, and native route ID lists.

3. Inspect the hybrid override

   The reference imports a granular Integration Hub view model and uses a hybrid route/component override with the /settings/apps alias.

4. Plan host qualification

   The result remains candidate. Replace fixture ports with your own integrations and qualify the deployed topology, including storage, queues, scheduling, recovery, and authorization.

A reference agent drafts a message, waits for approval, and invokes sendMessage. The MCP smoke test uses a real MCP server and client over an in-memory transport. The actual handlers remain deterministic fixture logic.

1. Separate the two operations

   The source defines draftAndSend.draftMessage and draftAndSend.sendMessage. Drafting is automation-safe; sending declares its approval requirement.

2. Inspect the workflow

   The example connects draft, approval wait, send, and receipt stages through the WorkflowDevkit adapter. This is a composed reference flow, not an invitation feature in the minimal starter.

3. Inspect the MCP boundary

   The smoke test registers the operation registry as MCP tools, then calls sendMessage with valid, absent, and tampered receipt evidence. It expects success only for the valid case.

4. Read what send actually does

   The bound handler derives a message ID and returns status sent in memory. To send through a real provider, supply your own port and preserve the same execution boundary.

A customer support signal reveals a product gap. The canonical fixture builds a permissioned graph, redacts data before agent access, compiles a dry-run runbook, blocks stale or conflicting paths, and keeps PM approval visible.

1. Read the messy signal

   Begin with the support-to-product scenario in the workbench. Treat other scenario previews as comparison material: this is the documented canonical end-to-end path.

2. Inspect the operating graph

   Follow signals, actors, capabilities, policies, approvals, and evidence. The permission view makes visible what an actor can query and what is redacted.

3. Replay blocked and corrected paths

   The timeline includes policy denials, pending approval, stale/conflict checks, state differences, and a correction replay. The authorized execution lane stays dry_run.

4. Inspect the receipt

   The exported structured receipt is derived from the same deterministic replay events. Use it to inspect the demonstrated technical sequence and its remaining approval boundaries.

A fixed enterprise request moves through Understand, Shape, Match, Bound, and Verify. The package default uses prepared analysis and a committed recording. A host can explicitly enable live analysis and a bounded loopback browser run after preflight.

1. Inspect the prepared request

   The source uses one allowlisted profile and a curated capability map. It shapes the request into a reviewed Outcome Pack and bounded proof plan.

2. Choose the execution mode explicitly

   The package's prepared runtime exposes recorded evidence and reports live browser execution unavailable. The web host may inject its API-backed runtime with explicit enablement and browser preflight.

3. Check the bound proof

   The proof plan permits a narrow loopback mutation and structured read-back. Approval denial and off-domain attempts are blocked; assertion failures remain visible.

4. Inspect recorded artifacts

   The repository includes companyos-acme-proof.png and a validated-recording manifest. The recording schema binds profile, plan digest, captured run, proof, and artifact hashes. A stored recording is evidence of its captured run, not evidence of a new live run.

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.

1. Compile the application

   The source compiles the release-steward filesystem application and inspects required approvals for patching, draft PR creation, and selected delegation tools.

2. 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.

3. 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.

4. 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.

A deterministic assistant searches a named curated snapshot. The integration fixture publishes an initial rule version, creates and reviews a change, publishes a second snapshot, and checks that the new answer cites that snapshot.

1. Validate the request envelope

   The orchestrator checks the request envelope before searching. An invalid envelope returns a refused answer with a reason code.

2. Search one snapshot

   The caller supplies kbSearch. The orchestrator uses the snapshot ID and jurisdiction from the validated envelope and derives citations from the returned rule-version IDs.

3. Enforce scope and citations

   Scope and citation checks can replace the draft with an escalation or blocked answer. The answer builder is deterministic and makes no LLM calls.

4. Review and publish a change

   The integration test uses in-memory KB and pipeline handlers, approves updated rule material, publishes a new snapshot, and asserts that a subsequent answer cites it.