# Read your first operation

Trace a maintained contract from its input schema to its deliberately small handler.

Source context: Source reading walkthrough
Source: https://github.com/lssm-tech/contractspec/blob/d58fa5b7de53a947811e5cc68346be028ce18528/examples/minimal/src/contracts/user.ts

## What this walkthrough demonstrates

The maintained minimal example declares an operation named user.create. It accepts an email and returns the same email. Despite the operation's name, the shown handler does not create a persistent account, send a message or call a provider.

This is a reading walkthrough of real source. It helps you understand the shape of an operation before introducing databases, authentication or transport setup. The complete files are linked from the source snapshot; the excerpts below are intentionally partial.

## Read its identity first

The meta object gives the operation a stable key and version, then records its purpose, ownership and stability. These fields tell a caller which contract it is using and help a maintainer find the responsible team.

Use the key and version together when comparing an implementation with its documentation. A source path can move without changing the operation's public identity.

```typescript
key: 'user.create',
version: '1.0.0',
```
Exact metadata excerpt from examples/minimal/src/contracts/user.ts at d58fa5b7; not a standalone declaration.

## Follow the input and output

UserInput is a SchemaModel with one required email field. The maintained declaration uses ScalarTypeEnum.EmailAddress(). Both input and output point to that model, so the example describes the same shape on either side.

Its authentication setting is anonymous because the example is demonstrating data flow. Treat that as an intentional property of this sample, not a default to copy into an operation that reads or changes private data.

```typescript
io: {
  input: UserInput,
  output: UserInput,
},
policy: {
  auth: 'anonymous',
},
```
Exact partial contract excerpt from examples/minimal/src/contracts/user.ts at d58fa5b7.

## Find the business implementation

The companion userInputHandler has a type derived from CreateUser and returns the provided email. The contract describes the boundary; this function supplies the implementation. Editing the declaration does not magically add persistence to this function.

To turn the example into a real account workflow, you would need to decide how accounts are stored, what happens when an address is already used, how identity is established and which outcome the caller receives. Those choices belong to your application.

```typescript
return {
  email: input.email,
};
```
Exact handler excerpt from examples/minimal/src/handlers/user-input.handler.ts at d58fa5b7.

## Make the next experiment observable

First inspect the example's typecheck, validation and smoke scripts. Its smoke test checks stable example metadata and the feature-to-operation reference; it is not an end-to-end API test.

For your own next step, bind a disposable handler to the registry and test a valid email, invalid input and an invalid handler result. Then expose that registry through one adapter. This adds one responsibility at a time and makes failures easy to locate.

## Related examples

- [Write your first contract](https://lssm.co/examples/minimal-user-contract/): Follow user.create from an email schema to a typed handler. Start with the smallest maintained example.