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 release gates and executable checklist for the next major version live in docs/src/v12.md.

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.

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 second progress lens answers a different question from release readiness: how much of the canonical long-term milestone programme through v13 remains if every milestone that is not yet [x] stays in scope?

The snapshot below was recalculated on 4 September 2026 from M1–M39. It includes 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.

Two calculations are intentionally retained:

• Strict closure: 5/38 are closed, so 86.8% remains open (33 milestones). This is the correct answer when a partial milestone counts as unfinished.
• Weighted engineering maturity: (5 + 24 × 0.5) / 38 is 44.7% complete, leaving 55.3% equivalent work. That remainder is the nine untouched milestones (23.7 percentage points) plus the unfinished half of the 24 partial milestones (31.6 points).

This is a scope/maturity indicator, not a duration estimate. Provider accounts, physical hardware, store acceptance, fiscal homologation, independent audits and research-grade cryptography cannot be completed by repository code alone. The 55.3% must not be added to the historical-claim campaign or the v12 release checklist because those lenses 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 post-v12-RC 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; 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; the CLI can inspect rullst-schema.json, but generation 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 fiscal and hardware integrations remain unavailable).
• A first-party load balancer embedded in every application ([!] Do not make the default — an opt-in rullst-gateway process is worth researching for self-hosted deployments, but application serving and edge proxying need independent failure, upgrade and privilege boundaries. 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

• 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 with PKCS#12, XML C14N/XMLDSig, XSD validation, mTLS, official rejection parsing, and SEFIN homologation (not implemented — an extraordinary and worthwhile Brazilian-market program, but only as a dedicated maintained fiscal workstream with official homologation and independent crypto validation).
• Alipay RSA2 and uniform live support across every advertised gateway (not implemented/partial — worth only with provider sandbox access, demand, and a method-by-method capability matrix; adapter names must not imply every payment, subscription, payout, 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 (remote adapters not implemented — the separate rullst-messaging crate now provides the bounded envelope, in-memory broker, durable local SQLite adapter and common contract foundation; add providers only after their delivery semantics pass provider-specific restart and fault evidence).
• S3, Cloudflare R2, and image resizing (not implemented — worth isolated optional storage/media crates with official signing, multipart/retry semantics, strict path/pixel limits, deterministic mocks, and fuzzing).
• 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).

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).

Execution plan aligned with gpt.md §15

Phase 0 — containment and truthful boundaries

• Keep live Fiscal, unfinished IoT integrations, S3/R2, Alipay, 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.

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 its powerset test.
• 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

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.