Rullst Master Roadmap 🗺️

“The Path to the Ultimate Full-Stack Rust Framework” — an aspiration, not a guarantee

Rullst’s ambition is an asset. This roadmap preserves that ambition while separating what exists today from what is only a prototype, a research program, or a vision. An idea is never deleted merely because it is unfinished.

Our philosophy: “Security, Developer Experience and Performance, Architected for Humans and AI.”

Single roadmap source: ROADMAP.md is canonical. docs/src/roadmap.md embeds it directly in mdBook instead of maintaining a divergent copy. The deeper evidence and decision record is docs/src/capability-ledger.md. The completed v12 identity and evidence map live in docs/src/v12.md; this roadmap owns the v13 programme until a dedicated release checklist is approved.

Next twelve months (October 2026 – October 2027)

Intentions, not promises; dates follow the evidence gates described below.

• v13: 13.0.0-alpha.1 (published as a prerelease on October 11, 2026), 13.0.0-alpha.2 (published as a prerelease on October 17, 2026, with the alpha.1 dogfooding fixes), 13.0.0-alpha.3 (published on October 24, 2026: PWA, Studio production monitor, OAuth providers), 13.0.0-alpha.4 (the candidate prepared on October 29, 2026 and the 13.0 feature freeze: a lean CLI with green built in and the terminal assistant removed, deployment guides, three starters), then 13.0.0-rc.1 with fixes and documentation only, driven by user feedback, then 13.0.0 stable with the maturity tiers applying from that release.
• v12: end of life on 16 October 2026; 12.3.0 is the last release and the v12 branch is frozen. Its unpublished fixes (PR #500 and the RustSec updates) stay on the branch; new 12.x projects no longer resolve their dependencies after crates.io yanked the zip releases its Studio needs.
• Assurance: keep the OpenSSF Best Practices Silver badge (granted on 10 October 2026) current, mutation testing extended from the critical v13 code to the whole workspace, and an independent review prepared with the external audit kit.
• Selected programmes: the green software roadmap and the legal compliance roadmap.

Status language

• [x] Implemented: a bounded, testable implementation exists. This never means that every imaginable provider or production environment is covered.
• [~] Partial: useful foundations exist, and the parenthetical says whether the remaining work is worthwhile and why.
• [ ] Not implemented: the idea is preserved, and the parenthetical says whether it is worth pursuing and under which conditions.
• [!] Do not promise: the absolute wording cannot be an honest framework guarantee; a narrower measurable goal is retained when useful.

Target windows are planning intentions, not release guarantees. Promotion to [x] requires code, focused tests, truthful documentation, and the release gates at the end of this document.

September 22 direction: stable v12.1 maintenance takes priority over publishing v13 to meet a date. September 26 is a review/handoff point, and development may continue in later sessions. The investment proposal groups M1–M41 into 25 themes to invest in or maintain and 16 to defer until justified, including M31’s separate programme. It preserves the historical ideas; it does not require every theme for 13.0.0 or remove maintenance from already supported capabilities. The same proposal flags twelve existing themes with a separate high-maintenance marker and offers eight bounded follow-up subtasks. Those overlap the original themes and are not added again to the milestone count.

The owner also adopted the v13 maintenance scope and extension strategy: retain common security and productivity foundations, limit Capital’s expansion, and assess separate lifecycles for specialized extensions. This decision refines investment and compatibility planning; it neither removes current capabilities nor changes package admission or the v12.1.1 candidate.

September 23 evaluation direction: the framework comparison plan defines reference projects, equivalent application tasks and measurements of effort, failures, performance and maintenance. Begin a small baseline after active v12.1.1 maintenance rather than waiting for all 25 A themes. The plan refines existing priorities; it adds no milestone, release gate or superiority claim.

Audit of the detailed crate roadmaps

The per-crate roadmaps are intentionally preserved as detailed design backlogs. Some predate this status policy, so an old [x] can record the original author’s milestone claim rather than today’s verified end-to-end contract. This table is the current interpretation; the capability ledger contains the evidence boundary and recommendation for the highest-risk claims.

This audit does not downgrade ambitious ideas merely because they are difficult. Capabilities that require continuous operations, homologation, hardware, or a separate release lifecycle can follow the Maybe SaaS incubation strategy instead of being forced into the framework core. It prevents a checkbox from becoming a production promise before the necessary code, tests, provider/hardware environment, and operational semantics exist.

Executive milestone tracker

Quantified planning horizon through v13

This inventory counts the status labels of the canonical long-term milestone programme. It includes v13 research and v13+ ambitions, not just features selected for 13.0.0 by 26 September. It measures neither release readiness nor the percentage of implementation effort already completed.

The label counts below were checked on 29 October 2026 against M1–M41. They include v12 hardening, continuous, next-SemVer, v13 and v13-research rows. M31 is excluded because the tracker explicitly assigns aerospace/autonomous/defence work to a separately governed future programme rather than the general v12/v13 framework suite. Detailed crate-roadmap checkboxes are not added again: they overlap with and decompose these canonical milestones, so a raw sum would double-count work.

M39 stays in the [ ] row: it was abandoned on 8 October 2026 rather than implemented, and the roadmap keeps abandoned ideas recorded. M30 moved from [~] to [ ] when 13.0.0-alpha.4 removed the make:grpc generator.

There are 35 milestones without strict closure (87.5% of the labels). A partial milestone can contain substantial published functionality and years of remaining ambitions; these rows do not have equal size. The former calculation that assigned half credit to every partial row was an arbitrary index, not a measurement of completed code or remaining work. Do not use it to claim that a release implements a particular percentage of the entire framework vision.

Progress toward 13.0.0 is tracked through concrete deliverables and their acceptance evidence in the dated delivery plan. The September 22 publication candidate includes standalone Supervision and Media alongside Privacy; Labs joined on October 8, 2026, for twenty packages. All twenty were first published as the 13.0.0-alpha.1 prerelease on October 11, 2026; final release acceptance is still required; Labs remains experimental and ships contracts only, because its runner candidate was removed from 13.0. Compatible roadmap expansions can continue in 13.1 and later minors; they are not automatically deferred to a new major. Checking these labels does not constitute a fresh implementation audit of every underlying capability. Provider accounts, physical hardware, store acceptance, fiscal homologation, independent audits and research-grade cryptography cannot be completed by repository code alone. Do not add these counts to the historical-claim campaign or the v12 release checklist because those inventories substantially overlap.

AI-native vision, without absolutes

The original goal of becoming an AI-native Rust framework suite is preserved as a design ambition, not a historically provable “first” claim. The dedicated AI maintainability and project-building roadmap defines the v13 acceptance work for generated instructions, bounded context, golden tasks and reproducible model evaluation.

1. “Zero Runtime Magic, Pure Compilation”: derives, typed routes, and compiler diagnostics can make AI-assisted changes easier to inspect. (Partial and worth pursuing as an architectural preference; literal zero magic, “zero hallucinations,” and instant correction are not promises any framework can make.)
2. Context-rich scaffolding: generated projects should receive a maintained AGENTS.md/AI ruleset describing the actual selected blueprint. (Partial and worth implementing; cargo rullst new and generate:ai-context write common AGENTS.md instructions when absent plus a bounded project map, not a blueprint-specific profile. Do not document .ai-rules or .cursorrules as generated until the generator and snapshots prove it.)
3. Structured system discovery: a versioned schema should expose active routes, controllers, models, policies, and source locations. (Partial and worth completing; inspect schema prints a statically derived ORM model schema and inspect routes --json emits recognized route declarations as versioned rullst.cli-routes.v1 JSON, but controllers, policies, source locations and freshness must become an end-to-end contract.)

Preserved extraordinary capability decisions

These items were previously easy to mistake for shipped functionality. They are kept deliberately, with the opinion requested for each gap. The capability ledger contains the more detailed evidence and acceptance boundaries.

Architecture and product-contract ambitions

• Runtime-only Core with optional ORM (implemented in current hardening — bare Core no longer selects SQLx/ORM, orm and queue-sqlite are independent, Studio/Nexus opt in explicitly, and the application umbrella retains ergonomic database defaults).
• One canonical security stack (partial — worth treating as high priority; keep policy/middleware in rullst-security and only minimal bootstrap contracts in Core so WAF, headers, and telemetry cannot drift).
• Static dispatch everywhere (partial — not worth forcing absolutely; generic fast paths are valuable, but runtime-selected providers legitimately need a documented dynamic-dispatch boundary).
• Every production source file below 500 lines (partial — worth continuous responsibility-based refactoring, but it is a design target rather than a release claim and large test fixtures may need a looser limit).
• Uniform #[non_exhaustive], fallible builders, and impl Into<String> (partial — worth completing incrementally under SemVer review; a mechanical mass rewrite is not worth breaking consumers).
• Zero lock-in, zero panic/crash, zero latency/allocation, 100% memory safety, and 100% Pure-Rustls ([!] Do not promise as absolutes — migration tools, scoped zero-panic linting, benchmarks, a tiny documented unsafe allowlist, and a feature-specific transport inventory are all worth maintaining).
• Framework-wide “production-ready” badge ([!] Do not promise as one boolean — worth publishing stability per crate/capability because routing can be stable while live payment and hardware integrations remain unavailable. The v13 maturity tiers now label every crate Core, Extension or Experimental and define each promise).
• A first-party load balancer embedded in every application ([!] Do not make the default — application serving and edge proxying need independent failure, upgrade and privilege boundaries. The opt-in rullst-gateway research (M39) was abandoned on 8 October 2026 in favour of generated Caddy/nginx configuration for established proxies. Matching a managed cloud load balancer’s global infrastructure or SLA is not a repository-code claim).
• Static competitor matrix claiming other frameworks lack capabilities ([!] Do not maintain without dated sources — comparative research and a reproducible benchmark repository are worthwhile; timeless absence claims are not).

Security, identity, and compliance

• Compliance-ready defaults for the main jurisdictions (EU, US, Brazil, Asia) (planned — building blocks, generated defaults and a per-regulation guide reviewed by counsel; never an automatic legal certification. See the legal & regulatory compliance roadmap).
• Full WebAuthn/FIDO2 conformance (partial — absolutely worth completing before a stable passkey claim, preferably with an audited library or normative conformance suite).
• Zero-downtime key rotation and Cloud KMS (not implemented end to end — worth implementing through provider-neutral envelope/key-version contracts and named KMS adapters, not by embedding custody in the framework).
• Adaptive WAF and eBPF kernel threat containment (not implemented — worth research only as opt-in, platform-specific defense in depth; not worth making a portability or complete-protection promise).
• Anti-timing user-enumeration guard and Prompt Shield v2 (implemented foundations — worth keeping and testing, but timing equalization and heuristic prompt filtering cannot guarantee elimination of every side channel or injection technique).
• External reputation feeds, verified audit feeds, and SIEM delivery for Threat Radar (partial — worth pluggable connectors; never render a source as healthy or verified unless it is connected and current).
• Studio automatically stripped from every release at zero cost ([!] Do not promise — explicit feature selection and route mounting are worth documenting; a universal debug/release assumption is not).
• Distributed rate limiting and durable tamper-evident audit storage (partial/not implemented — worth pluggable Redis and append-only sink backends with atomicity, tenant namespacing, retention, and verification tests).
• Automated SBOM, SPDX/CycloneDX, cargo-vet, signed provenance, and advisory governance (partial — worth making release gates; not equivalent to SLSA Level 3 or organizational certification without independent evaluation).
• Loom/Shuttle, Kani/Miri, mutation, fuzz, and unsafe governance (partial — worth scoped blocking suites plus a reviewed cargo-geiger inventory; a full mathematical proof of the whole framework is not worth claiming).
• An IDOR scanner that proves authorization ([!] Do not promise proof — the AST scanner is worth keeping as a heuristic warning tool, paired with route-level ownership and cross-tenant negative tests).
• DevSecOps git-hook installer (partial — hook:install writes pre-commit and Conventional Commit hooks; worth adding backup/idempotency/permission tests, while CI remains authoritative because local hooks are bypassable).
• Automatic SOC 2/ISO/FedRAMP PASS reports ([!] Do not implement as an unconditional verdict — evidence export is worthwhile; certification covers an organization and deployment, not a crate).

Fiscal, payments, messaging, storage, and mail

• Live NFS-e Nacional (removed from the framework in v13 — the local preparation module was never validated with a real municipality; fiscal work may return only as a separate, dedicated product with official homologation and independent crypto validation).
• Uniform live support across many gateways ([!] Do not promise — v13 keeps Stripe and an experimental InfinitePay adapter; other gateways are application-owned adapters on the provider traits, and adapter names must not imply every payment, subscription, portal, tax, and webhook method exists).
• Static fee/settlement/tax tables and “zero-cost invoicing” ([!] Do not promise — transparent links to current provider terms are worthwhile, but framework docs cannot erase certificate, accounting, infrastructure, support, compliance, or changing commercial costs).
• Durable cross-instance webhook replay/idempotency (partial — worth a pluggable database/Redis uniqueness contract before multi-instance production billing).
• RabbitMQ, Kafka, Redis Streams, NATS JetStream, SQS/SNS, and GCP Pub/Sub (Redis Streams candidate passed source admission in PR #236 — see the supported profile. Other listed adapters remain unimplemented. The separate rullst-messaging crate supplies the common contract; add providers only after their delivery semantics pass provider-specific restart and fault evidence).
• S3 and Cloudflare R2 (v13 candidate in the 13.0.0-alpha.1 prerelease — the optional Core/facade storage-s3 feature implements bounded private object operations with official signing, explicit credentials and deterministic mocks. Hosted source/package admission passed in PR #236; final release and provider interoperability remain outstanding; see the supported contract. Server-mediated resumable multipart uploads are the separate opt-in storage-multipart candidate; direct presigned uploads and image resizing remain future increments).
• Mailgun, Brevo, MailerSend, Plunk, and Scaleway transports (not implemented — worth demand-driven adapters only when each has a maintainer and passes the shared offline/live mail contract suite).

Efficiency and sustainability

• Measured green-software reports and efficient defaults (planned — the Experimental cargo rullst green command (measured figures only, carbon as a labelled SCI estimate per ISO/IEC 21031:2024), a reproducible cross-framework benchmark, tuned release and HTTP caching defaults, carbon-aware deferrable jobs. Reports state their method and limits; no unsubstantiated “greener than” claims. See the green software roadmap).

IoT, edge, AI, and critical systems

• MQTT 5, CoAP, Sparkplug B, CAN/J1939, LoRaWAN, GPIO/I2C, real firmware download/flashing/rollback, and hardware-in-the-loop CI (not implemented — worth separate transport and target-hardware packages after named boards and interoperability environments are selected).
• Hardware HSM/secure-element and NIST ML-KEM/PQC backends (not implemented; simulators are experimental — worth audited adapters for named hardware and protocols, never home-grown crypto presented as secure hardware).
• Autonomous AI admin, NL-SQL writes, self-healing code/schema, and DevOps mutation (not implemented as a safe production contract — read-only advice, dry runs, and human-approved changes are worthwhile; default autonomous production mutation is not).
• Native JSON Schema enforcement on every LLM (partial — capability-typed support is worth completing; parseable JSON must remain distinct and providers that cannot enforce a schema should return UnsupportedCapability).
• Any local model over any arbitrary HTTP API ([!] Do not promise — named Ollama and a capability-declared OpenAI-compatible local/cloud adapter are implemented, while arbitrary APIs differ in authentication, streaming, tools, schema, and error semantics and use the public provider trait).
• Automatically air-gapped/zero-leak AI ([!] Do not promise — local endpoints can be useful, but the host network, logs, model runtime, and telemetry determine the real data boundary).
• Aerospace/autonomous/defense framework (not implemented — the research is inspiring, but it is not worth conflating safety certification with web framework quality; incubate it independently if expertise, hardware, and governance become available).

Audited execution plan

Phase 0 — containment and truthful boundaries

• Keep unfinished IoT integrations, unconfigured S3/R2, live InfinitePay and other absent provider paths fail-closed with typed Unsupported results.
• Keep Nexus fail-closed, generated credentials absent, production configuration validated, webhook secrets mandatory, local storage confined, and the release workflow blocked until its dependency order and evidence agree.
• Label every capability implemented, partial, experimental, not implemented, or intentionally unsupported; never delete the vision to obtain truthful docs.

Phase 1 — kernel security and reliability

• Complete environment precedence, atomic/fallible DB initialization, APP_KEY policy, WebAuthn conformance, content-aware DLP/PII, signed-webhook composition, trusted proxies, tenant isolation, CSWSH, bounded workers, scheduler shutdown, and the production-path zero-panic policy.
• Extend M10/M27 with cloud/VPS application-protection evidence using the existing Security/Core/CLI boundaries: one trusted-proxy and shared-rate-limit deployment profile, bounded resource policies and read-only diagnostics that redact secrets. Keep host/network administration external. This is a conditional v13 increment after supervision and shared passkey state, ahead of a new gateway; see the delivery plan. PRs #224 and #225 admitted its first increments, the Caddy/Redis deployment contract and the offline deploy:doctor; the rest is not implemented merely by appearing here, and it adds no separate milestone or crate.

Phase 2 — product integrity and scaffolding

• Compile all generated projects in temp directories; enforce server-side Nexus policy; use real or explicitly unavailable Studio telemetry; and keep offline mocks deterministic without allowing live endpoints to fail open.

Phase 3 — architecture and contract

• Keep the new Core/ORM feature boundary regression-tested, consolidate the canonical security stack, standardize public API evolution, and split OAuth identity from future messaging adapters. The umbrella feature map is now complete and must remain covered by the isolated per-feature rows of .github/check-feature-boundaries.sh, which fails when a public umbrella feature has no row.
• Implement ambitious providers only where a maintainer, conformance suite, and real interoperability environment exist.

Phase 4 — release engineering

• Require formatting, strict Clippy, full workspace tests, exclusive DB-feature checks, generated-project checks, fuzz tiers, unsafe review, package preflight, SBOM/advisory evidence, provenance, and topological publishing for the exact tag.

Release strategy

v13 execution priorities

This section records the execution order set in September 2026. Since then the v12 line reached end of life (16 October 2026), so its v12 maintenance steps are historical, and 13.0.0-alpha.4 is the 13.0 feature freeze; the current plan is under Planned after 13.0.0-alpha.4.

The Verus verification pilot is planned supporting work for the privacy, authentication and payment contracts in M41, M9 and M11. Begin with a small production age-policy scope, then evaluate Auth and Capital; keep proofs beside their modules and start with a pinned manual workflow. Reproducibility, reviewed assumptions, negative controls, consumer compatibility and measured CI cost precede mandatory checks on affected v13 changes. This does not add a public crate or a release requirement.

Execution order: verification efficiency, then the compatible 12.1.0 update experience, then concentrated v13 product development. The published v12 packages remain immutable; important maintenance fixes remain independently reviewable. Carry the compatible updater and applicable fixes into v13 without merging unrelated breaking work into the v12 line. The phased efficiency plan is in WORKFLOWS.md. Application API changes still belong to the appropriate release line.

The compatible 12.1.0 update experience is published. The publication record links its immutable source and successful release evidence. New capability work belongs to v13; compatible security fixes were eligible for v12 maintenance until its end of life.

PR #218 admitted the published 12.1.0 baseline and the SQLite/PostgreSQL replay foundation to protected v13 at 7f48d882. Subsequent source admissions are recorded individually in the delivery plan. Keep later applicable stable fixes synchronized through reviewed changes; a development branch name alone does not prove that it includes them.

The published 12.1.0 source at b62390b4 and its documentation closeout were carried into that v13 integration: account mail, one-time Stripe contracts, machine endpoints, strict driver isolation, native CLI installation and project update/recovery join the earlier SaaS and Android corrections. The age-assurance package (first published in 13.0.0-alpha.1) and v13 Labs/privacy/Verus plans remain separate. Each later increment requires its own CI evidence; stable-release results do not certify the combined v13 source.

The delivery plan and evidence retains the bounded acceptance criteria and original calendar. The September 22 priority revision removes a mandatory publication date. Neither document turns planned capabilities into shipped claims.

On September 21, the owner selected shared PostgreSQL consent and single-use email login links as the next two implementation priorities through September 23. The additional-priorities section records their acceptance boundaries and five subsequent additions approved for the implementation queue. These entries do not claim implementation or expand the validation and publication dates.

This is an execution order, not a promise that the entire historical backlog fits one month. Prefer completed user journeys and measured acceptance criteria over increasing the number of crates. The workflow roadmap retains the assurance experiments; move a proposal into the implementation column only after its code and evidence exist.

Safe update experience

Status: published in 12.1.0 for the documented compatible-update scope. The goal is the easiest practical update journey without hiding risk: one guided entry point, a clear plan, minimal repeated input, useful progress, verification and recoverable application of the approved changes. Ease and speed are acceptance criteria, not reasons to skip compatibility or security checks.

The existing cargo rullst upgrade already provides workspace-aware plans, versioned migration rules, controlled file snapshots, compiler fixes and Cargo checks. It does not install the CLI or run the application’s full acceptance suite. Extend this boundary in cargo-rullst; do not introduce another crate or count this proposal as completed work in the capability ledger.

Implementation and acceptance order:

13.0.0-alpha.4 removes the CLI self-updater (update check, update verify, update stage, update install and the CLI half of update guided): the CLI is installed and updated with cargo install cargo-rullst --version =X --locked, and a once-a-day notice prints that command. The project preparation commands below stay. The paragraphs that follow record the 12.1.0 to 13.0.0-alpha.3 history.

Published 12.1.0 discovery uses interactive-only, offline/CI-aware notices and bounded HTTPS metadata. It rejects redirects, yanked versions, prereleases and unsolicited major jumps. The legacy shared temporary cache is removed; the current result is deliberately process-local. Explicit cargo rullst update check now provides exact-target, MSRV/platform and versioned JSON discovery with separate major/prerelease opt-ins; it grants no installation or execution authority. Explicit discovery now reuses bounded, owner/permission-checked Unix metadata for six hours and supports offline reads, forced refresh and cache opt-out. Windows persistence has a private owner/DACL implementation with native acceptance recorded in the maintenance checkpoint. The 12.1.0 publication record records final acceptance. Earlier v12.0.0 provenance exercises remain historical evidence for their own artifacts.

Published preparation builds native CLI candidates on four explicit targets and binds their version, source, platform, sizes and digests in a bounded inventory. The admitted tag workflow separately attests the files and adds release assets; ordinary CI inventories have no release tag. The admitted 12.1.0 release completed this native and publication evidence. Explicit update stage rechecks a fresh registry selection, authenticates the manifest before executable downloads and bounds HTTPS redirects, sizes, time and hashes in private storage. It executes and installs nothing. Managed installation now revalidates eligibility, original manifest provenance, private root ownership and exact bytes under a destination-local lock. Explicit digest-approved application stages bounded version probes and backups before replacing entries; explicit recovery restores only the authenticated predecessor and rejects unrelated edits. Native installation/lock/interruption/ executing-image tests passed on Linux, Windows and macOS at ef0a8577 in run 35296176849. The explicit local update verify command now authenticates a private manifest snapshot with the caller-installed GitHub CLI and checks both native binary digests. It grants no installation authority or registry eligibility and does not download, execute or install candidates. Its declared platform/release acceptance is recorded with the published 12.1.0 flow below.

Working-source update project prepare now retains Git working contents and the root lockfile in private before/candidate copies, reuses exact dependency editing and the versioned source catalog, and rejects ambiguous inputs and downgrades. Local process fixtures cover dirty/untracked/deleted source, virtual workspaces, ignored or absent lockfiles, bounded findings and unsafe files without compiling application code. Native preparation tests passed on Windows and macOS at 88ddabad. Preparation grants no execution or application authority. Working-source verification now revalidates records/source under an operation lock, previews commands, and requires explicit trusted-code consent before resolving/checking/testing another private copy. Local process tests cover real acceptance, stale inputs, missing consent, contention, timeout, failed tests and unexpected source writes. Verification passed Linux/macOS and the corrected Windows path contract at the recorded maintenance checkpoints; final release acceptance followed with the published 12.1.0 release. Explicit update project review now revalidates command logs and both source inventories and emits the bounded full dependency diff plus a review digest. It performs no builds or original-file edits; the digest does not grant application authority. Explicit digest-approved project apply/recover now revalidate evidence/access policies, stage reviewed manifest/lockfile replacements and persist an intent. They refuse divergent edits and preserve unrelated files. Source locks coordinate only the same configured cache. Native project acceptance passed on all three systems at 8b58cd12; corrected Windows SDDL/Git path handling is included. Local child-kill, OS file-size-limit and injected replacement/recovery faults add bounded interruption proof, not power-loss or a complete disk-full matrix.

Working-source update guided --to VERSION composes CLI/project/both flows through the same validators. It retains exact paths and separate review digests, shows complete reviews, defaults each approval to no and reports elapsed time per stage. Project code/network and original-file writes need separate consent. Noninteractive approval and unsupported project major jumps reject. A real terminal regression covers declined preparation/execution, failed application tests and approved application followed by exact recovery. The published 12.1.0 release record holds the final release evidence for this composition.

1. Discover and explain. Make update notices useful without blocking normal CLI startup. Respect offline/CI settings and explicit notification opt-out; use bounded responses, timeouts and a private, path-safe cache. Default to supported stable releases within the selected major, with exact target pins; prereleases and major migrations require explicit selection. Show release notes, MSRV/platform requirements and unsupported migration paths before proposing changes. Metadata or a notification never grants installation authority.
2. Update the CLI safely. Offer verified prebuilt binaries for supported OS/architecture pairs, with a pinned source-install fallback when appropriate. Bind artifact identity/version/platform/digest to a trusted publisher identity through signatures or verified provenance; a checksum from the same untrusted download is insufficient. Respect package-manager ownership and permissions; stage replacements with concurrency locks, interrupted-download recovery and Windows executable-lock handling. Test rejected tampering, unexpected redirects/archives, stale metadata and unauthorized downgrades. Keep an explicit, verified known-good recovery path, not a silent downgrade.
3. Prepare and verify the project. Reuse the versioned migration catalog in an isolated working copy, preserving uncommitted user work. Show dependency, lockfile and source diffs and the validation commands before execution; Cargo build scripts, procedural macros and tests execute code, so preparation is not a sandbox or permission to run an untrusted project. Resolve the chosen target reproducibly and validate the candidate lockfile, supported feature sets and application-owned tests before accepting changes. Unknown or breaking migrations stop with actionable instructions instead of guessed rewrites.
4. Apply with consent and recover. Make the interactive happy path concise; expose structured reports and explicit non-interactive policy for automation. Verify that reviewed inputs have not changed before applying. Preserve bounded backups and prove cancellation, concurrent edits, disk-full recovery and restoration on Linux, Windows and macOS. State exactly which files are restored: file rollback does not undo arbitrary test side effects, database changes or external services. Opening an application or running a build must never silently replace its framework, migrate its database or deploy it.
5. Prove usability and speed. Exercise published-package/generated-project fixtures, pinned versions, offline operation, unsupported targets and failed migrations. Measure cold/warm discovery, download, compilation and validation separately. Reuse only correctly keyed caches and applicable test evidence. A prebuilt CLI can avoid CLI compilation; updating a Rust application can still require rebuilding, testing and a separate deployment. Do not promise instant upgrades, zero downtime or automatic production readiness.

The 12.1.0 delivery must preserve v12’s public APIs, CLI/configuration behavior and opt-in boundaries. It prepares discovery and installation of a compatible migration CLI, not guesses about a future major’s source changes. Actual v12-to-v13 automation requires v13’s published migration catalog and tested application fixtures; the same-major restriction of the v12 upgrade command must not be silently removed. Reserve incompatible changes for v13. On main, the v13 CLI accepts Rullst 12 and 13 projects: cargo rullst upgrade reports v12 → v13 source findings with their migration-guide rows. These support a review; they do not migrate an application automatically.

Continue new capability work on v13; the v12 line is no longer maintained after its end of life on 16 October 2026. The website redesign is a separate documentation delivery, not a reason to bump framework versions or postpone verification work. This plan neither bumps package versions nor authorizes publication, and it does not claim that any major application migration is already automatic.

API documentation quality

Status: planned for v13; improve documentation alongside each implemented contract, not only at release time. Distinguish the Rust framework API (types, traits, functions and features) from guides for building HTTP/REST APIs. The existing REST quickstart intentionally covers one JSON endpoint; routing, authentication and Scalar/OpenAPI guidance live in separate chapters. More pages alone will not make those paths easier to discover or complete. The v12 navigation index now connects existing guides to exact-version crate references and identifies the remaining REST walkthrough gaps. This first navigation improvement is not completion of the reference and behavioral-example programme below.

Use Qt’s reference navigation and a concrete class reference as organizational inspiration, not as a reason to adopt Qt or copy its text. Adapt the pattern to Rust with a searchable crate/module/task index linking the book and version-pinned rustdoc pages. For prioritized public interfaces, document purpose, imports/Cargo features, arguments, results and typed errors, security/ownership/concurrency constraints, runnable examples, related APIs, version availability and migration notes. Start with the umbrella facade, Core/routing, Auth/Security and ORM; extend coverage with each v13 increment.

Provide a coherent REST learning path covering typed input validation, error responses, CRUD and pagination, authentication, owner/tenant authorization, OpenAPI, tests and deployment boundaries. Validate examples against the documented release and feature set, including rejected input and access denial. Keep the existing book-doctest integration and add behavioral fixtures where compilation alone cannot prove the documented result. Check rendered book links as well as repository-local links. Record which API surfaces were reviewed; do not infer complete reference coverage from a green book build or label unimplemented v13 contracts as available in v12.

Ideas recorded for after 13.0

Recorded on 8 October 2026. These are ideas, not commitments or shipped features, and they add no milestone to the counts above.

• Offline IoT/health example application. Sensor readings flow to a Rullst server, are stored in SQLite and appear on a dashboard, with no internet connection required. It would build on SensorTelemetry, AnomalyDetector and the snapshot card from the experimental rullst-iot, with a maintained transport crate (for example rumqttc) rather than a new Rullst transport. A health-oriented variant must treat readings as sensitive personal data and must not present itself as a medical device.
• Multiplayer quiz example. Core realtime and presence (BroadcastManager, PresenceTracker) for live rounds, with rullst-labs grading contracts for server-authoritative, idempotent scoring. Answers are graded on the server, never trusted from the client.
• Reverse-proxy configuration instead of a gateway. The self-hosted rullst-gateway (M39) is abandoned. Deployment work goes into generated, reviewable configuration for established proxies: extend the existing Caddy output and add nginx, with the readiness/drain and trusted-proxy contracts that rullst-core already exposes.

Delivered in 13.0.0-alpha.3

Planned on 15 and 16 October 2026 with the maintainer and prepared on 23 October 2026 as the 13.0.0-alpha.3 release candidate; the coordinator records publication in the table below. Each item states what the release contains and what stays open. They add no milestone to the counts above.

• [x] First-class PWA, and retiring Omni (done in the 13.0.0-alpha.3 source; see the PWA guide). Decided on 16 October 2026 with the maintainer. The make:omni Tauri shells (desktop, Android, iOS) only open the hosted Rullst application in a native webview and deliberately expose no native API to it, so they give the same result as packaging a Progressive Web App, while costing three mandatory release workflows (Android NDK, iOS simulator, desktop on three systems), Tauri upgrades and per-platform signing. alpha.3 replaces them:

  1. cargo rullst make:pwa: web app manifest, icons, a service worker with an offline page and an update prompt, compatible with Core’s CSP nonces and Cache-Control defaults; browser-side offline data (IndexedDB) where an application needs it.
  2. Google Play through a Trusted Web Activity: a Bubblewrap configuration (twa-manifest.json) and a /.well-known/assetlinks.json route fed by the application’s signing-key fingerprint. Bubblewrap is the scriptable tool PWABuilder itself uses for Android.
  3. Microsoft Store: a guide to packaging the same PWA as MSIX with PWABuilder, which Microsoft supports for its store. The Apple App Store usually rejects apps that only wrap a website (guideline 4.2), so iOS users install the PWA from Safari.
  4. Remove make:omni, cargo rullst omni, the three Omni release workflows and the native-only offline-sync feature, whose only consumer is the Omni shell, before 13.0.0 (the last release where removing them does not wait for v14).

  All four are implemented: make:pwa (with --android for the Bubblewrap configuration), rullst::pwa::AssetLinks, the Microsoft Store and iOS sections of the guide, and the removal, with cargo rullst upgrade findings for an Omni shell and the offline-sync feature. They ship with 13.0.0-alpha.3; store acceptance and physical devices stay application work.

• [x] Studio as a production monitor for several projects (phases 1 to 3 done in the 13.0.0-alpha.3 source; see the production monitoring guide). Before alpha.3 Studio is a development tool: it runs inside the application process in debug builds, listens only on 127.0.0.1:5555 and reads that process’s own telemetry, queues, cache and local database. The only production-facing piece is the signed, push-only trace ingestion of M35. The plan keeps every development page and adds a remote mode in three phases:

  1. A read-only production monitoring endpoint in the application, behind the application’s own login policy (the policy the Nexus package for alpha.2 adds) or a dedicated token. It reports request rate, latency, errors, queue depth and failures, and N+1 findings, never database rows, .env values or configuration secrets.
  2. A standalone Studio “remote projects” mode on the developer’s machine: a project list with a switcher, per-project credentials encrypted locally, and the monitoring pages (radar, traces, jobs, security radar) reading the selected project’s endpoint. Studio stays bound to loopback; it only connects outwards. Reaching private networks is left to established tools (WireGuard, Tailscale, an SSH tunnel), which the guide documents instead of Studio implementing VPN access.
  3. History and alerts. All three phases are implemented for 13.0.0-alpha.3: the /_rullst/monitor/v1 endpoint (Server::with_monitor), the standalone rullst-studio binary with overview, routes, queues and N+1 pages, and its bounded local history with per-project alerts and an optional webhook. Traces and the security radar are not part of the phase 1 document, so remote mode does not show them yet; desktop notifications are not implemented (alerts show in Studio and can go to a webhook). The data browser, .env viewer, AI and API playgrounds and migration pages stay local-only, because in production they would expose secrets and personal data or run arbitrary operations. The work needs a threat-model update before phase 1 ships. Estimated at three to four focused packages plus mutation tests.

• [x] The rest of the mutation campaign (all but cargo-rullst done in the 13.0.0-alpha.3 source; cargo-rullst moves to the next section). As the verification order requires:

  • rullst-orm and rullst-orm-macros: re-measured in full for alpha.3 on hosted runs, with all-feature targeted runs and the orm-sqlite, orm-polyglot, orm-sql-servers, orm-strict-postgres, orm-strict-mysql and orm-polyglot-servers contracts of mutants.yml, which run the SQLite, optional-backend and database-server suites that the all-feature build compiles out. rullst-orm has 2,414 mutants: 1,967 caught, 421 unviable, 17 timeouts and 9 missed, of which 8 are accepted equivalents. The ninth is the MySQL FOR UPDATE SKIP LOCKED claim query of Outbox::claim_next_at_inner, which only concurrent claims tell apart from the portable query. rullst-orm-macros has 542 mutants: 514 caught, 26 unviable and 2 accepted equivalents. A full all-feature campaign still reports the mutants that only those contracts reach.
  • rullst-core: the files the first pass left (PR #465) were finished in PR #532: 78 files and 2,435 mutants, 72 missed at the end (71 documented equivalents; the remaining one needs an open PostgreSQL pool).
  • rullst-nexus: measured for the first time in PR #532 (26 files, 876 mutants); 170 of 171 first misses were killed by new tests, one is a documented equivalent, and one real defect was fixed.
  • cargo-rullst is not measured yet; a targeted campaign was stopped before completion and is not part of alpha.3.
  • The 29 rullst-capital mutants that only a live Stripe response reaches stay with provider sandbox testing.

• [x] Feedback from the platforms built on alpha.2. The reports from the platforms built on 13.0.0-alpha.2 chose the fixes in this release (see the changelog), as the alpha.1 report did for alpha.2.

Delivered in 13.0.0-alpha.4

Planned with the maintainer on 29 October 2026 and prepared the same day as the 13.0.0-alpha.4 release candidate; the coordinator records publication in the table below. Goal: a lean CLI for people and a predictable framework for AI assistants. The framework crates’ APIs do not change. They add no milestone to the counts above.

• [x] Lean main CLI (PR #555). Foundry, nixify/new --nix, generate:buildah/new --buildah, make:grpc, the Fly.io, Render and Railway deploy targets and the self-updater’s download and binary replacement were removed; a once-a-day notice prints the cargo install command for a newer CLI. Each removal has a migration row and, where an application can be detected using it, an upgrade review rule.
• [x] green in the main CLI, the terminal assistant removed: cargo rullst green (Experimental; measured size, memory, dependency and CPU figures, carbon only as a labelled SCI estimate) replaces footprint in cargo-rullst. cargo rullst ai was removed from 13.0 (its code stays in git history) and now prints what replaces it; the rullst-ai crate is unchanged. A separate cargo-rullst-extras package was prepared in PR #555 and dropped before publication, so the release still has twenty packages.
• [x] Deployment guides (PR #555): one deploy path (Dockerfile, compose.yaml and Caddyfile for Docker or Podman), the Linux VM, Hetzner Cloud, DigitalOcean, Oracle Cloud and Google Cloud guides and Advanced deployment (Nix, Buildah, Podman Quadlet, Kubernetes; described, not generated). The guides were written from the providers’ documentation and not followed on real accounts, and no automated test starts the generated stack.
• [x] Three starters, the others as examples (PR #558): cargo rullst new offers Blank, API and SaaS; LMS, ERP and Portfolio are workspace applications under examples/ with their own tests.
• [x] For AI assistants (PR #555): one --json contract with a schema id (new for inspect models, inspect schema and pkg list), and llms.txt with an optional section, checked by validate-site.py.
• [x] Shorter development builds (PR #559): generated projects get a [profile.dev] (line tables for the application, no debug information for dependencies), and the SaaS starter no longer declares rullst-connect. On the measuring machine cold builds took 15 to 19 % less time, rebuilds after an edit about half and target/ about 41 % less disk (Build times). The framework-level items are planned below.
• [x] Targeted cargo-rullst mutation campaign (PR #557): hosted targeted runs with the CLI’s library tests measured 83 CLI files and 3,189 mutants of the self-update, audit and IDOR scanner, add and consumer-file editors, doctor and deployment configuration and upgrade code. New tests killed 1,041 of the 1,129 first-run survivors and 51 are documented equivalents; the 76 files left without a survivor were listed in .github/mutants-pr-cli.txt, so mutants-pr.yml mutates their changed lines on every pull request. Left: size and count bounds that only very large projects reach (hundreds of mebibytes, or 10,000 to 250,000 files): upgrade snapshot 6, upgrade source walk 3, project snapshot 13, replacement and verification totals 2 and 2, the 64 MiB preparation report 4. The Studio remote mode (20 files) was measured in the same campaign and has no survivor left. The self-updater’s binary replacement was removed in 13.0.0-alpha.4, with its 7 remaining installation mutants; its 13 measured files left the gate list with it, and generators/deploy.rs and update/guided.rs, rewritten in that release, left it until they are measured again.

Planned after 13.0.0-alpha.4

Work items for later prereleases, not shipped features. They add no milestone to the counts above.

• 13.0.0-rc.1: fixes and documentation only. 13.0.0-alpha.4 is the 13.0 feature freeze. rc.1 freezes the public APIs that 13.0 supports and states which packages and features its stability promise covers, starting from the maturity tiers. After rc.1, changes are limited to defects found in the release candidate.
• Framework build time. Measured on the generated starters (Build times). Rullst keeps aws-lc-rs as the TLS crypto provider (rustls’ post-quantum hybrid key exchange), so the aws-lc-sys build script (about 52 s, reached through Studio → rullst-capital → reqwest/rustls) stays in a project’s first build; later builds reuse it, and the generated Dockerfile’s dependency layer (the cargo-chef approach) caches it in images. Moving to ring is not planned. Planned for 13.0.0-rc.1 if they need no breaking change, otherwise for 13.1: SQLx’s compile-time macros compiling some crates, SQLite among them, a second time, and rullst-nexus pulling rullst-ai into the SaaS starter.
• Re-measure generators/deploy.rs and update/guided.rs with targeted mutants.yml runs and return them to .github/mutants-pr-cli.txt once only accepted equivalents are left.
• The first hour and the documentation: follow the path from installation to a deployed starter as a new user, and fix the documentation and CLI messages that get in the way.
• Turso/libSQL beyond the blank and API starters, if users ask for it. Turso can be the primary database only in those starters and does not work with #[derive(Orm)], Schema, artisan!, Server::with_db, Nexus or Studio. A partial bridge (Schema emitting Turso migrations, #[derive(Orm)] also generating the Turso model) is a candidate for a 13.x release. Full parity, which would let the ORM core run on a backend other than SQLx, is deferred to a later major release because it would put the SQLx drivers at risk.
• Feedback from the platforms upgraded to 13.0.0-alpha.3 and alpha.4. Their reports choose the fixes and priorities of the next prerelease, as the alpha.1 and alpha.2 reports did before.
• Then 13.0.0, once rc.1 leaves no open defect in the stability scope.

Published and planned release lines

The framework may call a milestone implemented only when the same commit passes the repository’s formatting, strict lint, full-test, feature-matrix, security, and packaging gates. Performance numbers must cite a reproducible benchmark; security and compliance claims must state their threat model and evidence scope.