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.
The fleet operations design and implementation plan specifies the proposed reconciliation path for overload relief, ownership balancing, and resumable node maintenance. It includes signed pressure state, busy-Cell drain, follower obligations, controller recovery, compatibility, work packages, and acceptance checks. The plan also specifies reservation ownership, an enrollment barrier for safe finalization, the source map, and the first executable implementation slice.
Start with the plan's implementation brief and application startup recipe for the delivery order and required integration adapters.
The working tree now contains operation records, schema 3 readers, shared local admission reasons, host movement actions, a local durable journal, and a caller-driven reconciler with SQLite-backed sequencing tests. The overload executable moves two real Cells across three leased nodes, reopens its controller client and checks original outcomes and restored state. Complete enrollment/observation wiring, leased-node failure integration, the maintenance workflow, and measured fleet qualification remain in progress; these foundations do not establish fleet operation support by themselves.
Follow the plan's execution checkpoints for the three delivery milestones: settled Cell movement, complete node maintenance, then deployment qualification. Each milestone specifies the public behavior, verification commands, and evidence required for completion.
For proof levels and receipt requirements, read the delivery evidence guide.