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
| 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 |
| Project an operation to HTTP or streaming | Project communication boundaries |
| Export and consume Rust or TypeScript clients | Generate and use an SDK |
| Coordinate retries, timers, and human approval | Build a durable workflow |
| 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 |
| Build a mobile, desktop, terminal, or device client | Build other application targets |
| Give an agent bounded typed tools | Build an agent |
| 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 |
| Project commands and events to a broker | Use messaging |
| Derive analytical, search, and vector views | Build data projections |
| Release a bounded customer control plane | Build a multi-tenant platform |
| Create organization-owned meaning | Define a semantic domain |
| Change a contract and its stored data | Evolve and migrate |
| Restore, fail over, or roll back | Recover a release |
| Connect live signals to causal facts | Observe and trace history |
| Sign, admit, publish, and revoke | Govern the supply chain |
| Manage workspace and package source changes | Use source transactions |
| Authenticate CI without a stored production secret | Use workload identity |
| Bind accessibility, performance, and CI to a release | Qualify a release |
| Keep negative outcomes distinct | Handle failures |
| Produce and inspect a governed release | Ship and inspect 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.