Simple capability status
This is the compact view of Rullst’s canonical M1–M39 programme. It is derived from the root ROADMAP; that roadmap and the capability ledger retain the evidence and limitations. The labels here deliberately do not turn partial foundations into completed features.
v12 engineering snapshot — 13 September 2026
This functionality inventory is deliberately separate from release quality.
All 15 non-IoT crates currently meet the approved A floor and rullst-iot
meets its approved B exception. All 15 active crates have also reached their
higher audited local ceiling: 1,509/1,509 local campaign points are backed by
repository evidence (100%), with zero planning points remaining. The exact
SHA still earns those dimensions only when its conditioning gates pass. The
older 91.8% readiness estimate was superseded after the final correction batch.
The post-audit release report is authoritative:
12.0.0-rc.1 was published after its local, hosted and package gates passed.
Stable 12.0.0 is in exact-SHA closeout: its source, manifests and public copy
are synchronized, but crates.io publication is established only after the
fully verified tag commit receives owner approval and the registry workflow
returns its receipts.
Coverage is a separate release gate. Codecov measured the approved code candidate
a6b3bc8a at 91.49% across the whole repository (76,685/83,811) and 100%
patch coverage (14/14); the separately enforced framework_libraries component
also passed its zero-tolerance 90% target. This is SHA-bound evidence, not a
security certification.
Approved RC code candidate a6b3bc8a completed all 22/22 applicable automatic
push workflows successfully, including the full all-feature workspace suite
on Linux, macOS and Windows. The final documentation closeout must preserve
that code and passed its documentation/site checks before the immutable RC tag.
The RC tag workflow then passed verification and publication at 2b19567e; its
separate redundant SLSA job failed policy setup and is neither counted nor used
for stable v12. The stable tag must repeat the retained GitHub attestation and
complete release workflow.
The later manual campaign on 45fbdbe7 produced passing bounded Miri, Kani and
sanitizer evidence, while fuzzing usefully exposed three stale harnesses and a
real Unicode-boundary panic in database-URL redaction. Those findings have
committed regressions and corrections; the repaired ORM parser plus both
affected security targets passed 100,000 local libFuzzer/AddressSanitizer
executions. This is remediation evidence, not a substitute for rerunning the
complete heavy matrix on the frozen RC SHA.
| Coverage view | Audited checkpoint | Release meaning |
|---|---|---|
| Whole repository | 90.06% (74,219/82,408) on 27e81152 | Historical passing checkpoint. This primary public number includes CLI and proc-macro production sources, but does not approve the post-audit candidate. |
| Framework libraries | 91.33% (56,119/61,446) on 27e81152 | Historical component pass; it does not replace either the repository aggregate or a fresh post-audit result. |
| v12 release requirement | at least 90% in both views | Must be reproduced by Codecov on the exact frozen release candidate, together with at least 90% patch coverage. |
The two percentages are neither conflicting measurements nor values to average: they answer questions about different path sets. Rullst must keep the whole-repository result primary and must not reuse this candidate’s passing result as proof for a later SHA that Codecov has not measured.
The latest ceiling gain is the umbrella rullst facade’s dedicated shared-local
SQLite profile. It composes Auth revocation, Capital quota, encrypted Connect
tokens, Mail suppression, encrypted Messaging and Core queueing behind
aggregate lifecycle readiness, then proves restart/idempotency, plaintext
secret exclusion and isolated fail-closed corruption. It deliberately does not
claim a cross-subsystem transaction, whole-file online consistency, key/backup
operations or multi-host coordination.
rullst-ai has now earned its audited 95/A local ceiling. In addition to strict
opt-in OpenAI-compatible SSE/cancellation, AuditDeliveryClient supplies
bounded HMAC-authenticated export and AdaptiveAiEvaluator<P> supplies
bounded multi-turn feedback, explicit pass/fail/inconclusive results and a
raw-content-free JSON report. Receiver operations, non-compatible provider
protocols, exact live-model results and corpus quality remain external or v13
work rather than being mislabeled as v12 guarantees.
rullst facade versus rullst-core
| Package | Role | Typical user choice |
|---|---|---|
rullst-core | Low-level runtime engine: HTTP server, routes, lifecycle, queue/realtime, storage/cache and the default browser-security baseline. It deliberately does not aggregate every domain crate. | Use directly when a library/application wants only the runtime primitives and explicit dependencies. |
rullst | Ergonomic umbrella facade. Cargo features re-export Core plus selected ORM, Auth, Security, AI, Mail, Capital, Studio, Nexus, Messaging and IoT APIs through one dependency. It also exposes the browser/WASM surface used by web-first applications; Omni packaging itself is a CLI workflow, not a re-exported crate. Its maturity cannot exceed the crates selected underneath it. | Use for most Rullst applications and enable only the required features. |
Documentation release gate
Before stable v12 is tagged, the complete repository documentation remains an explicit review gate: build the mdBook, compile the Rust snippets sourced from all public tutorials, validate local links and anchors, reconcile commands, features and version examples with the frozen manifests, and manually review the upgrade guides and external-provider boundaries. A green documentation build proves structural consistency, not that every external service or store workflow was homologated.
Canonical milestones
| ID | Capability | Simple status |
|---|---|---|
| M1 | CLI and make:* generator matrix | 🟡 Still to implement — partial |
| M2 | Fast linkers and measured build-time improvements | 🟡 Still to implement — partial |
| M3 | Escape hatches, granular features, diagnostics, and ejection | 🟡 Still to implement — partial |
| M4 | make:resource and local error console | ✅ Implemented — scoped |
| M5 | mdBook, OpenAPI, and typed client generation | 🟡 Still to implement — partial |
| M6 | ORM parity and Turso/libSQL profile | 🟡 Still to implement — partial |
| M7 | Portable edge runtime, distributed data, and safe upgrades | 🟡 Still to implement — partial |
| M8 | Explain-and-approve index recommendations | ⏳ Still to implement — not started |
| M9 | Local auth, OAuth/OIDC, TOTP, passkeys, and WebAuthn | 🟡 Still to implement — partial |
| M10 | Mail, DTO validation, distributed rate limits, and Shield | 🟡 Still to implement — partial |
| M11 | Nexus, Omni, billing, and entitlements | 🟡 Still to implement — partial |
| M12 | Defence-in-depth security programme | 🟡 Still to implement — continuous/partial |
| M13 | Audited PQC protocols and sandboxed Wasm extensions | ⏳ Still to implement — not started |
| M14 | HTMX-first SSR and real Leptos/Dioxus interoperability | 🟡 Still to implement — partial |
| M15 | Runtime queues/cache/scheduler plus brokered messaging | 🟡 Still to implement — bounded local messaging foundation; remote adapters open |
| M16 | Wasm islands and #[client_component] protocol | 🟡 Still to implement — partial |
| M17 | Realtime, object storage, media, and packages | 🟡 Still to implement — partial |
| M18 | LiveView-style server-driven UI | 🟡 Still to implement — partial |
| M19 | Radar, agent schemas, spans, and Prometheus | ✅ Implemented — bounded |
| M20 | Persistent event stream and verifiable ledger semantics | ⏳ Still to implement — not started |
| M21 | Omni frontend protocol and mobile bridge | 🟡 Still to implement — partial |
| M22 | Human-reviewed agentic DevOps recommendations | 🟡 Still to implement — partial |
| M23 | Diagnostic auto-healing recommendations | 🟡 Still to implement — partial |
| M24 | no_std IoT frames/packet encoders, signed OTA gate, and durable-counter CAS boundary | 🟡 Still to implement — partial |
| M25 | Embassy-based async embedded integration | ⏳ Still to implement — not started |
| M26 | Guided PaaS/VPS deployment | 🟡 Still to implement — partial |
| M27 | Kubernetes scaffolding and health/readiness probes | ✅ Implemented — scaffolding scope |
| M28 | Compile-time DI and Inject<T> | ✅ Implemented — foundation |
| M29 | Scalar playground and complete OpenAPI generation | 🟡 Still to implement — partial |
| M30 | Tonic/gRPC and Protobuf support | 🟡 Still to implement — partial |
| M31 | Aerospace/autonomous/defence systems | ⏳ Separate safety-critical programme; outside the general framework suite |
| M32 | Axum/Tower escape hatches and proc-macro diagnostics | ✅ Implemented — bounded |
| M33 | Server-side declarative SaaS entitlements | ⏳ Still to implement — not started |
| M34 | Schema-driven TypeScript/React/Dart/Swift SDKs | ⏳ Still to implement — not started |
| M35 | Distributed OpenTelemetry waterfall in Studio | 🟡 Still to implement — partial |
| M36 | Read-only explainable natural-language SQL assistant | ⏳ Still to implement — not started |
| M37 | Reviewable one-click error-console patch workflow | 🟡 Still to implement — partial |
| M38 | Vendor-specific SQLite replica/synchronization profile | ⏳ Still to implement — not started |
| M39 | Optional self-hosted rullst-gateway load balancer | ⏳ Still to implement — separate v13 research/foundation; no managed-cloud parity claim |
Current planning snapshot: 5 implemented, 24 partial, and 9 not started
inside the 38-milestone web-framework horizon. M31 is excluded because it is a
separately governed safety-critical programme. The weighted planning estimate
is 44.7% complete and 55.3% remaining; this is not v12 release readiness and
the 33 milestones without strict closure are not 33 blockers for v12.0. The
v12 programme owns release gates, while the root roadmap assigns
confirmed v12 defects to 12.0.x maintenance and all additive capability work,
research or major contracts to v13.
Claims that are impossible as framework guarantees
No useful capability above is dismissed merely because it is difficult. The
impossible label is reserved for absolute wording that code in this repository
cannot honestly establish:
| Absolute claim | Status |
|---|---|
| 100% uptime or zero data loss in every deployment | 🚫 Impossible as a framework guarantee |
| Exactly-once arbitrary external side effects | 🚫 Impossible without destination-level idempotency/transactions |
| Zero latency, zero overhead, zero allocations, or universal sub-100ms builds | 🚫 Impossible as a universal guarantee |
| Total memory safety or universal panic-freedom across dependencies, FFI, generated apps, and every input | 🚫 Impossible to prove from this repository alone |
| Automatic fiscal, security, privacy, App Store, or hardware certification | 🚫 Requires independent authorities, environments, and evidence |
| Universal one-click zero-downtime deployment | 🚫 DNS, credentials, migrations, providers, and rollback remain operational inputs |
| “Best/fastest/most secure framework in the world” | 🚫 Not a technical property without dated, reproducible comparative evidence |
| Unattended production mutation that is always safe | 🚫 Approval, scoped authority, audit, recovery, and application policy cannot be removed |
Use the quality scorecard for per-commit engineering evidence. It is intentionally separate from this functionality view.