These recipes show the finished One product through complete, task-oriented slices. Start with a goal, follow its authored meaning into implementation and operation, and keep every physical choice behind its owning contract.
All .one and language API snippets in this section are illustrative end-product
syntax. They demonstrate the product contract and intended
ergonomics; the owning language packages and executable examples remain the
source of exact implementation evidence.
Commands under an Executable evidence heading are current, copyable owning checks. Other command snippets describe the finished product interface and do not claim that a current package implements that capability. This distinction keeps the end-product documentation useful without turning an illustrative coordinate, option, or output into false repository evidence.
Choose a recipe
Foundations
| If you want to… | Follow |
|---|---|
| See how every file and root fits together | Assemble a complete project |
| Define and invoke a typed operation | Build a service |
| Add governed persistent state | Build a data-backed service |
| Create organization-owned meaning | Define a semantic domain |
| Manage workspace and package source changes | Use source transactions |
Services and data
| If you want to… | Follow |
|---|---|
| Project an operation to HTTP, streaming, or messaging | Project communication boundaries |
| Export and consume Rust or TypeScript clients | Generate and use an SDK |
Applications and experience
| If you want to… | Follow |
|---|---|
| Present typed places and intents in a browser | Build a One Web application |
| Use One from Next.js without pretending it is One Web | Use a framework-native application |
Workflows and agents
| If you want to… | Follow |
|---|---|
| Coordinate retries, timers, and human approval | Build a durable workflow |
| Give an agent bounded typed tools | Build an agent |
Platform and extension
| If you want to… | Follow |
|---|---|
| Bound concurrent work and resource lifetimes | Manage resources and execution |
| Grant one effect and deliver a protected secret | Grant authority and deliver secrets |
| Connect an external system without surrendering ownership | Build a provider adapter |
| Release a bounded customer control plane | Build a multi-tenant platform |
Operations
| If you want to… | Follow |
|---|---|
| Produce and inspect a governed release | Ship and inspect a release |
| Change a contract and its stored data | Evolve and migrate |
| Restore, fail over, or roll back | Recover a release |
| Keep negative outcomes distinct | Handle failures |
| Connect live signals to causal facts | Observe and trace history |
| Sign, admit, publish, and revoke | Govern the supply chain |
| Bind accessibility, performance, and CI to a release | Qualify a release |
Read examples as one lifecycle
Every recipe uses the same boundaries:
authored declaration
-> checked owner value
-> selected implementation and providers
-> exact Build artifacts
-> authorized placement and effects
-> observations, receipts, and causal historyA declaration is never executable authority. A code body is never selected merely because it exists. A provider package is inert until one root selects it. A successful command output is not deployment evidence unless its owner record and receipts remain resolvable.
Use Build your first system for the shortest guided introduction, then return here for the capability you need.