v13 framework references and comparative evaluation

Planning direction adopted on 23 September 2026. Study useful designs from other frameworks and measure comparable application journeys to guide Rullst investment. This document specifies future evaluation, not measured results or a claim that Rullst is superior. Finish the active v12.1.1 maintenance admission before beginning this work. The SST still governs architecture.

Relationship to the priorities

The 25 A priorities are broad themes to invest in or maintain, not 25 unfinished features that must all ship before evaluation. Some already have bounded implementations; others contain substantial optional follow-up. Start a small baseline once the selected application journeys are usable, then repeat relevant measurements after meaningful changes. Findings should help select the next investment instead of arriving only after the entire roadmap.

This work refines existing themes such as M1/M2/M3/M5/M9/M11/M12/M15 and the downstream fixtures, recovery and authorization proposals S1-S3. It adds no top-level milestone and does not change the 41-theme or 25/16 counts. It is not a new release gate, a promise to complete all themes for v13, or authorization to publish. Preserve the maintenance scope: common security contracts remain maintained, while specialized extensions need owners.

Reference frameworks

The following official documentation was consulted on 23 September 2026. These are design-study recommendations, not a ranked list or independent verification of the projects’ claims. Pin actual versions when executing a comparison; mutable documentation links alone do not identify tested source.

Begin with Loco for comparable Rust application work, Laravel for onboarding, Django for security/documentation study, and Axum for a small HTTP baseline. The other references are targeted follow-ups. Do not build and permanently maintain nine parallel application suites merely because nine references are listed. Adoption of an idea requires a demonstrated gap and a bounded change; the list does not authorize copying each framework’s architecture or features.

First application journeys

Use synthetic data, disposable databases, local provider fixtures and supported public APIs. Reuse existing SaaS/Academy regression fixtures where appropriate. Write equivalent acceptance contracts before timing implementations.

The first executable pilot should cover the small SaaS journey and one authorization-negative case. Expand to account recovery, events, durable work and upgrades only as the acceptance fixtures and available resources permit. An unsupported journey is a recorded scope gap, not an invented successful run.

Bounded SaaS pilot

The opt-in cli-saas-journey diagnostic in the existing Rust CI workflow implements the first Rullst acceptance contract. Dispatch it with platform=ubuntu-latest; it is outside the default platform/shard matrix and does not replace any required CI or release gate. Run records, not this source description, establish whether a particular SHA passed.

Its canonical resource, migration and runner live in examples/saas. python3 examples/saas/run.py runs the diagnostic locally; --serve keeps the same disposable application open for exploration without claiming a test pass. The example README documents registration, local membership provisioning, notes requests, disk requirements and cleanup.

gh workflow run ci.yml --ref <candidate-branch> \
  -f platform=ubuntu-latest -f shard=cli-saas-journey

The script installs the reviewed source CLI in an isolated prefix, verifies its version, generates the SQLite SaaS, checks its source dependency paths and runs the installed db:migrate command twice. It adds one explicit application-owned migration/resource, then checks the generated application with strict Clippy. Real loopback HTTP exercises three disposable users: permitted registration, login, create/read/update, wrong-password and anonymous denial, same-tenant ownership denial, cross-tenant denial, forged tenant hints, CSRF, bounded input, rejected owner/tenant mass assignment, persistence across an owned process restart, fresh membership revocation and client-cookie logout.

The resource uses the starter’s real Auth middleware, database-owned membership, TenantLayer, parameterized SQL and RbacGuard. The fixture operator provisions membership directly in its disposable database; this is application code, not automatic organization management in the SaaS blueprint. Neither a tenant header nor a request body grants membership. A missing tenant hint can select the authenticated user’s sole trusted membership, as documented by Core. The additional resource mounts CSRF, secure headers and WAF explicitly, including in this loopback development profile. The starter’s existing middleware and Server’s production baseline remain unchanged.

saas-journey-ubuntu-latest retains sanitized JSON evidence even on failure: source and lock identities, installed CLI version/hash, toolchain, phases, acceptance outcomes, application fixture size and observed wall times. No database, generated secrets or raw application output is uploaded. Failed commands expose only a bounded, redacted diagnostic tail in the job log.

This first profile uses a source-installed debug CLI, a local SQLite file and HTTP clients. It does not establish archive/registry installation, browser cookie enforcement, production TLS/provider behavior, stateless-cookie server revocation, load capacity, application upgrades, rollback safety or superiority over another framework. Independent archive/platform suites retain their own source identities. Setup edits and compile/startup times are observable; active implementation effort and failed CI attempts must still be retained in the trial report. A small functional run cannot predict support for 1,000–10,000 concurrent users.

Local execution requires Linux, a fetched workspace lock and at least 32 GiB available on the source and temporary filesystems for a conservative cold-build allowance. The runner checks space between phases and during owned builds, stopping those builds at the 12 GiB reserve. Prefer hosted CI on workstations near the 15 GiB preventive threshold. This is an operating check, not a disk quota or protection against writes from unrelated processes.

Measurements

A fast implementation that fails the agreed security, durability or correctness contract does not qualify as a performance/productivity winner. Report the failure; do not disable protections to improve numbers. Internal Rullst scorecard grades are not comparative measurements.

Fairness and reproducibility

• Freeze task requirements, acceptance tests, effort budget and measurement method before the trial. Use idiomatic supported approaches on every stack. Give competing implementations a comparable debugging/tuning budget.
• Record framework/application commits, exact versions, dependency locks, toolchains, OS, machine/container limits, database version/schema/data, cache state and commands. Distinguish released software from unpublished candidates.
• Compare matching authentication, validation, persistence, durability and response semantics. A minimal Axum HTTP baseline is not a full SaaS competitor; disclose application code and libraries needed to assemble missing layers.
• Isolate the load generator, check for bottlenecks, warm up appropriately and repeat trials. Declare trial counts, load schedules, errors and variability; report inconclusive differences. Hosted CI timing is useful for regression detection but is noisy evidence for cross-framework performance rankings.
• Separate local fixture acceptance from provider/device/production evidence. Use only free resources and standard public CI runners where appropriate; respect the local disk reserve. No real provider accounts, production data, paid services or automatic deployments are authorized by this plan.
• For AI-assisted work, retain the actual model/version, tools, instructions, budgets and interventions. Keep the procedure comparable and disclose familiarity and tuning differences. One assistant’s result measures that assisted workflow, not universal human productivity or model capability. Reuse the AI evaluation protocol, without changing models automatically or claiming independent human validation.
• Keep scripts, sanitized fixtures, raw results and a source-bound report. Retain failed trials and tradeoffs; do not publish only favorable workloads or turn a weighted internal score into a universal league table.

Delivery sequence and acceptance

1. After stable maintenance: select the first bounded SaaS task, references, supported versions and free execution budget. Confirm fixture reuse and document the threat/behavior contract before adding implementation work. The bounded SaaS pilot implements that task’s Rullst-side acceptance contract.
2. Baseline: exercise usable Rullst source and the selected reference with the same acceptance contract. Record current gaps and uncertainty. Do not wait for every A priority to be completed and do not claim unrun results.
3. One improvement: choose a measured problem with a clear user benefit, check the SST and maintenance cost, implement it, and rerun affected cases. Existing release and compatibility requirements still apply.
4. Release review: when the selected v13 scope is ready, summarize the relevant measurements and remaining limits. Required release checks decide admission; this optional comparison cannot certify security or waive them.
5. Maintenance checkpoints: repeat relevant cases after upgrades or material changes. Keep focused regressions in normal CI when useful; run expensive cross-framework campaigns explicitly at checkpoints, not on every PR.

An evaluation deliverable needs reproducible commands and source identities, actual acceptance results, comparable measurements, disclosed exclusions and a short prioritized response to the findings. A defensible conclusion names the specific workload and dimension in which Rullst improved, matched or lagged. The outcome may be to fix a defect, simplify a journey, retain an existing design or defer an expensive extension. There is no predetermined winner.