v13 maintenance scope and extension strategy

Decision adopted on 22 September 2026: concentrate Rullst’s investment on secure, productive application development and keep specialized capabilities within explicit maintenance boundaries. Reduce scope before removing useful software. Code generation by an AI assistant does not remove the need for maintenance, integration evidence or security review.

This is an approved planning direction, not an implemented package split or a deprecation notice. It leaves the published v12.1.1 release, supported APIs, defaults, MSRV and current publication inventory unchanged. Specific extractions, provider selections and retirements need their own reviewed changes. The SST describes the current architecture; the compatibility policy governs transitions.

Direction reaffirmed on 24 September 2026: prioritize measured maintenance cost and coherent application journeys before expanding the adapter catalogue. The next planning deliverable is a decision record per integration, beginning with Capital, specialized database adapters and the Labs runner. Retain useful maintained implementations; an interface without a usable implementation can transfer both development work and security mistakes to every application.

This direction can improve the conditions for broad adoption by concentrating effort on reliability, predictable upgrades and developer experience. It is not evidence of a global framework ranking. Use the comparative evaluation plan, independent feedback and application adoption to assess progress. Feature count and mutation scores alone do not establish superiority.

How to assess maintenance cost

The assessments below are qualitative, not measured engineering hours or monthly costs. They include v13 prerelease candidates. Review each capability using its actual user journey and these recurring obligations:

• external API, protocol, operating-system and toolchain changes;
• supported database, platform, blueprint and feature combinations;
• consequences of security, data-integrity and recovery failures;
• dependency updates, diagnostics, migrations and documentation;
• repeatable acceptance and any outstanding provider or independent review;
• a named person or team able to review incidents and maintain the contract.

Source size and crate count alone are poor cost measures. A small untrusted-code runner can require more operational assurance than a larger template library. An optional dependency reduces the consumer’s selected build surface; it does not eliminate the project’s support obligations. Moving code to another repository saves work only when scope, ownership or release coupling changes.

For each integration, record its actual consumer, maintained operations, dependency/API versions, compatibility matrix, validation gaps and accountable maintainer. Measure update/review effort, regressions and CI execution separately from queue time; leave unknown costs explicitly unknown. Recommend one of:

• retained official support with a bounded expansion scope;
• specialized optional extension with an explicit maintenance/release owner;
• an application/community integration with a tested contract and transition;
• deprecation with a replacement and compatibility plan, when justified.

Provider release frequency alone does not decide the category: a compatible upstream release need not require an adapter rewrite, while a rarely changing executor can still carry substantial security obligations. Evaluate independent adapter releases where stable interfaces and dependency ranges allow them; a provider correction should not unnecessarily force unrelated framework releases. This requires an actual packaging, compatibility and release-workflow migration, not just a new repository name. Security support for shipped capabilities remains in force throughout that transition.

Measured cost snapshot (13.0.0-alpha.3)

Measured on 29 October 2026 at the main that follows the 13.0.0-alpha.3 publication. These are proxies for recurring work, not hours: each line of production code, each mutant and each fuzz target is something every release must keep compiling, tested and admitted. Hosted CI minutes per crate and the time spent on reviews and incidents were not measured; they stay unknown.

¹ Most of the crate is excluded from mutation with mutants::skip, so the listed count understates its test obligation.

By tier, the share of the workspace totals (263,711 production lines, 5,958 tests, 33,834 mutants, 42 fuzz targets):

What the numbers show:

• The CLI is the largest single cost. cargo-rullst alone holds a quarter of the production code and 28% of the mutants, and changes most often, because every generator multiplies database, blueprint and platform combinations. Reducing generator combinations saves more than retiring any optional crate.
• The experimental packages are a small share. Together they are about 7% of the code and 9% of the mutants. Narrowing their promise lowers support obligations more than CI work; retiring them would not change the release cost much.
• External services are concentrated in four Extensions (rullst-connect, rullst-mail, rullst-capital, rullst-ai): about 19% of the code, and the part whose correctness depends on providers changing their APIs. Each new provider adds to this group.
• Two production applications (October 2026) enable the facade with orm, strict-postgres, nexus and auth, plus rullst-connect. The packages neither application enables directly (messaging, AI, Capital, mail, Studio and the five experimental packages) are about 28% of the code. That is evidence of current use, not a reason to retire a package by itself.

How the columns were measured: Rust lines under each package, excluding target/ and fuzz/ (test lines are tests/, benches/, *_tests.rs and tests.rs); tests are #[test], #[tokio::test] and #[rullst_orm::test] attributes; mutants are cargo mutants --list -p <package> --all-features; dependencies are the unique packages in cargo tree -p <package> --all-features -e normal, without the package itself; fuzz targets are the [[bin]] entries of <package>/fuzz/Cargo.toml; commits are git log --since=60.days -- <package>.

Crate-level investment decisions

These decisions refine the existing A/B priorities and overlapping C cost marker. They do not add milestones, change the 41-theme count or label an expensive capability dispensable merely because it is expensive.

Capital: retain billing, contain the responsibility

Owner-selected v13 scope, 8 October 2026 (superseding the 24 September selection of Stripe and Paddle): rullst-capital keeps a maintainable provider-neutral base and two adapters. The base is the billing traits, checkout/subscription/entitlement/quota/usage contracts, billing analytics, invoices, canonical webhook verification with replay protection, the Axum and Actix adapters and the offline mocks. Crypto integrations are excluded from this release.

Removed from the 13.0 workspace (8 October 2026; the source remains in git history and in the 12.x line): the Paddle, Lemon Squeezy, Polar, Razorpay, Mercado Pago, Alipay, Coinbase Commerce and PicPay adapters, the Wise payout adapter with the payout contracts, the generated Paddle billing candidate and the NFS-e preparation module (nfse feature). NFS-e was never validated with a real municipality; it may return as a separate product outside Rullst. Applications integrate other gateways by implementing the provider traits, as shown in Writing your own payment provider; the migration guide lists the removed names. Do not silently redirect existing customers or subscriptions to another provider.

Keeping these two adapters still incurs upstream API and security maintenance. The framework owns bounded protocol validation and reference lifecycle tests; applications own credentials, catalog setup, billing-owner permissions, business rules and deployment-specific operation. An adapter is not a promise to implement every provider product. Generated reference flows must reuse storage/security foundations and retain explicit limits, without growing into a full billing platform. Capital remains an optional feature. An application-specific need does not automatically justify another official adapter.

Crypto research is deferred beyond v13. Preserve applicable billing extension contracts, but do not add a crypto adapter, universal blockchain API, custody service or new crypto-specific release gate. The former Coinbase Commerce adapter was removed with the other excluded providers. Two findings remain relevant if a future application requests this:

• Coinbase’s Commerce transition notice sets 31 March 2026 as the Commerce shutdown deadline. Its Business availability page currently lists eligible receiving businesses in the United States and Singapore. Existing Commerce code is not a Business API implementation.
• BTCPay Server is an optional evaluation candidate, not a selected Rullst provider. Its altcoin FAQ separates the core Bitcoin scope from community integrations. Its August 2026 advisory records an exploited LND credential vulnerability fixed in 2.4.2. This dated reference does not identify the latest release or certify another deployment. Future evaluation must include current advisories, exact plugin/engine versions and operator maintenance, not merely API access.

Plan three explicit responsibilities, using the existing implementation as the starting point rather than rewriting it:

1. Reusable billing contracts: amounts/currencies, supported checkout and subscription state, current entitlements, idempotency and safe event processing. Keep authorization and money/state integrity reusable instead of asking every generated application to reconstruct them.
2. Provider adapters: document capabilities per operation and provider, version assumptions, signature verification, duplicate/out-of-order events, ambiguous outcomes and reconciliation. Select the actively supported expansion scope from real product demand and available validation. A common trait must not imply that every provider supports the same operations.
3. Fiscal and specialized finance: outside the framework. The bounded NFS-e preparation was removed from 13.0 without live validation; fiscal work may return as a separately maintained product with its own lifecycle.

These responsibilities need not produce one crate per provider. Decide whether modules, features, packages or repositories provide a measurable benefit after checking dependencies, downstream consumers and release costs. Independent versioning is a future migration decision, not a property already implemented.

The 12.x line keeps its published support obligations for the removed adapters. In v13 each removed name has a migration row and an assisted-upgrade finding, and the replacement is an application-owned adapter on the retained contracts. The deprecation policy also expects #[deprecated] markers in a released 12.x minor before a stable API is removed. By owner decision on 8 October 2026, the 12.3.0 minor release marks the Capital and Mail APIs removed here #[deprecated], pointing to their migration rows, before 13.0.0 ships. The assisted-upgrade findings and the fail-closed configuration errors apply in addition. Tests with deterministic mocks establish local contracts, not actual provider interoperability. The prohibition on real-account tests remains in force; outstanding external evidence stays explicitly pending.

The recurring obligations are concrete: Stripe documents duplicate events, delivery ordering and retries in its webhook guide, and version transitions in its API upgrade guide. Other providers require their own evidence rather than inferred equivalence.

Mail: four delivery transports

Owner-selected v13 scope, 8 October 2026: rullst-mail keeps the Resend, AWS SES, SendPulse and SMTP transports, the log, memory and offline mock_* development drivers, and the shared infrastructure they use: failover, the REST helpers, the pre-flight pipeline, attachment inspection, suppression, observations, verified Resend feedback and queued delivery. Removed from the 13.0 workspace (the source remains in Git history and in the 12.x line): the SendGrid, Postmark, Mailjet, Mailtrap and Azure Communication Services transports with their MAIL_DRIVER values and settings.

Upgrades must not lose mail or data silently. A configuration that still names a removed driver fails facade resolution with a typed MailError::ConfigError that names the driver and the migration guide row “Mail providers removed”; it never falls back to a development driver. Jobs queued by 12.x carry no provider name and are delivered by the upgraded worker’s configured driver, or fail visibly and stay retryable. Suppression rows and delivery observations keep their provider labels and stay readable. Applications integrate other providers by implementing MailDriver, as shown in Writing your own mail transport. Like the Capital removal, these transports are marked #[deprecated] in 12.3.0 before 13.0.0 ships. Tests with deterministic mocks establish local contracts, not provider interoperability.

Turso: assess a complete application journey before universal parity

Assessment on 24 September 2026; implementation is not scheduled here. SQLite, PostgreSQL and MySQL/MariaDB are the principal SQLx ORM backends. MariaDB shares the MySQL driver but has its own executable container contract. This does not imply every optional crate or generated application supports all four databases: some domain stores deliberately have a SQLite-only or PostgreSQL-specific implementation.

The current Turso/libSQL path already supplies typed CRUD, equality filters, ordering, bounded pagination/counts, explicit SQL transactions and reversible checksummed migrations. Blank/API generation and selected generators have bounded acceptance; the remote matrix runs against an official libSQL server. SQLx-specific relations/hooks, schema auto-diff, seed generation, full blueprint parity and transparent replica synchronization remain outside that profile. See the current persistence contracts.

The remote adapter owns an HTTP/Hrana protocol implementation; local offline execution uses SQLite through SQLx. Reusing SQL syntax does not make those transports, row codecs, transactions or generated consumers interchangeable. The current official Rust guide also distinguishes libSQL, the newer Turso Database engine, remote clients and local-first sync. The existing libSQL evidence does not validate every newer engine or sync configuration. Select an engine/protocol/version profile before expanding support, and preserve Rust 1.96.0 compatibility.

These are engineering judgments from current boundaries, not measured hours or update-frequency forecasts. Retain useful Turso support. If an actual SaaS or Academy requirement selects expansion, implement the smallest complete journey and review its recurring cost before adding another profile. Validate atomic updates/rollback, tenant isolation, concurrency, uncertain network outcomes and schema changes. Keep replica freshness and authoritative authorization/payment decisions explicit. Local/container evidence remains distinct from managed Turso Cloud acceptance; real-account tests are still prohibited in this session.

Education, supervision and Labs remain supported use cases

Rullst remains a foundation for complete education, parental-supervision and exercise platforms. Preserve the useful domain capabilities already implemented in the optional packages, alongside authentication, tenant boundaries, storage and durable work. Their current candidate status and evidence limits still apply; this decision does not promote prerelease code to a stable guarantee.

Keep small tested examples and supported integration paths where they serve actual users. Developers should be able to compose existing capabilities rather than recreate sessions, leases or observation protocols. They still own domain authorization and deployment obligations. Observation signals do not establish cheating, and an AI-written integration does not prove model accuracy or safe code execution. Each deployed Labs runner still needs its own isolation review.

Labs and the runner have different maintenance responsibilities

rullst-labs keeps the trusted exercise, authorization, submission/job, cancellation, receipt-verification and grading contracts. It does not execute the learner’s program. A runner is the separately deployed program that takes authorized work, compiles/executes the submitted code under enforced limits, returns a bounded authenticated result and tears down the execution environment. Trusted grading and expected answers remain outside the untrusted worker.

Two kinds of separation must not be confused:

• Execution isolation is mandatory today. Student-controlled code can loop, exhaust resources or attempt to read data. Run it in the separately restricted worker without application secrets and enforce CPU, memory, time and output limits. Merely putting code in another crate or process is not adequate containment; the runner’s full observed isolation controls remain required.
• The runner’s maintenance is no longer a framework obligation. The Linux/compiler/sandbox matrix has different deployment and review obligations from an ordinary web library. This plan originally considered a separately maintained official runner in the same repository.

Decision of 30 September 2026: the experimental rullst-labs-runner candidate is removed from the 13.0 workspace and is not published; its source remains in git history. rullst-labs becomes a bring-your-own-runner library: it keeps the trusted exercise, authorization, encrypted job, fenced lease, cancellation, retention and pinned-receipt contracts, and documents the controller contract an application-owned, separately deployed runner must implement, with a minimal non-executing example. The application operator now owns the runner’s isolation, review, deployment and updates. Isolation evidence must match the deployed toolchain and image.

rullst-labs still declares 13.0.0-alpha.1 with publication disabled and is not part of any published 12.x release. (Labs later joined the release inventory and was first published in 13.0.0-alpha.1 on 11 October 2026.) There is one wire protocol and no adapter layer; interchangeable external executors are not implemented. The removed candidate’s first-profile record remains a reference design, not a supported runner.

The current profile is a restricted Rust pure-function exercise named for Wasm on Linux. It does not run arbitrary Rullst projects or support every language. Do not imply production support for any runner, and do not ask applications to recreate isolation with an unrestricted process launcher.

What belongs in the framework in an AI-assisted workflow

Prioritize explicit APIs, typed errors, safe defaults, version-matched executable documentation, inspectable generators and predictable upgrades. Keep reusable authentication, tenant authorization, payment verification and data-integrity contracts centrally tested. AI-generated application code must still satisfy those contracts; an assistant is not a replacement for their review.

Application-specific forms, reports, pages and business workflows are good candidates for generated or manually written application code. Provide extension points and small tested examples rather than maintaining every possible product inside the framework. Application owners still maintain the resulting code. See the AI maintainability roadmap for proposed task fixtures and evaluation boundaries; this decision claims no model benchmark.

Transition sequence and acceptance

1. Preserve stable maintenance. Keep the published v12.1.1 release immutable and finish the active test-hardening follow-up without structural changes. Keep v12 for stable maintenance and main for v13. Continue assessing applicable fixes in both directions.
2. Make support scope observable. For each proposed expansion or extraction, record the product user, maintained operations/platforms, dependencies, evidence gaps, responsible reviewer and estimated recurring work. Start with current SaaS and Academy journeys. The v13 billing-provider set is Stripe (supported) and InfinitePay (experimental), with crypto excluded; the other adapters and NFS-e were removed with migration guidance. The v13 mail transports are Resend, AWS SES, SendPulse and SMTP; the other transports were removed the same way.
3. Prioritize separation and expansion freezes. The Labs runner’s assessment concluded with its removal from 13.0 in favor of a bring-your-own-runner contract, and Capital’s fiscal domain was removed from 13.0. Next assess IoT hardware expansion and specialized educational monitoring. Keep their existing bounded implementations and security duties visible. Reuse existing package boundaries where they already solve the problem.
4. Review one bounded migration at a time. Demonstrate the benefit before extracting modules or changing defaults. Trace facade features, generated applications, direct package consumers, serialization and data migration. Do not create a collection of nominally separate but unsupported packages.
5. Validate and integrate normally. Preserve workspace tests, strict Clippy, formatting, MSRV, feature-boundary, package-consumer and generated-application checks. A smaller future support matrix requires an explicit compatibility decision; it is not permission to skip today’s required evidence. Update the SST, manifests, release inventory, support documents and migration guide together when an actual boundary changes.

The current synchronized release train remains authoritative. Labs is already excluded from normal publication and its runner candidate was removed; other crates in the inventory are not removed by calling them extensions. Their possible future independent release lifecycles must be explicitly implemented and validated. Unfinished optional roadmap work need not block a bounded v13 release, but unresolved safety or admission requirements for what it ships still do.

Retirement is appropriate only after a concrete review finds insufficient benefit, no sustainable maintainer or a better supported replacement. Follow the existing deprecation policy: retain a deprecated stable API for at least one released minor version before removal in the next major, subject to the documented security exception. Preserve migration guidance and history.

At each review, record actual maintenance effort where available: incident and dependency-update work, CI execution versus queue time, repeated failures, supported combinations and downstream acceptance. Keep unknown measurements unknown. Prefer freezing low-demand expansion over weakening required tests or transferring critical security logic into unreviewed application code.