This page separates implemented framework behavior from work that still needs application integration or measured qualification. It is a planning map, not a promise of a hosted service or a release date.
| Area | Current framework surface | Where to start |
|---|---|---|
| Authoring | SQL, KV, Blob, Queue, Cron, Workflow, Activities, and Effects through typed application handles. | API guide and primitives |
| Cell execution | One fenced writer, durable request outcomes, receipt-bound reads, and bounded admission. | Architecture |
| Persistence | Managed SQLite, immutable LTX history, exact-root publication, and verified recovery. | LTX crate |
| Fleet lifecycle | Signed enrollment, owner fencing, resource admission, reader replacement, warm promotion, drain, and shutdown. | Framework integration |
| Optional peer transport | Runtime-contract HTTP adapter with pinned mTLS; applications own endpoints and authorization. | Peer adapter |
The quickstart exercises a local application path. Local success is evidence for that path and environment; it does not establish cloud provider, scale, fault, or upgrade behavior.
- Real providers and constrained fleets. Run conditional object writes, range reads, multipart behavior, bounded Cell populations, and pressure shedding under measured provider and resource limits. Keep raw logs and bind them to the source, image, and profile digest.
- Failure and rollout paths. Exercise interrupted publication, ambiguous replies, owner loss, reader replacement, fenced promotion, and shutdown under the fault profiles.
- Compatibility. Demonstrate upgrade and rollback behavior for any deployed storage prefix or signed peer population before claiming a compatible rollout. Persisted identities, paths, roots, and messages are contracts; no local API test can substitute for an upgrade run.
- Matched crate release. Complete the verification and packaging gates, then publish the seven-crate set in dependency order using the release guide.
Additional Timer, Projection, or hosted Queue consumer APIs should follow a concrete application need. Any new capability must integrate with the current registry, owner admission, maintenance budget, and host lifecycle; former APIs from earlier codebases are not part of today's supported surface.
For proof levels and receipt requirements, read the delivery evidence guide.