Rullst Blueprints Roadmap 🗺️

“A practical collection of reviewed Rullst application starters”

This document maps the expansion plan for the Rullst Starter Blueprints ecosystem. The goal is to provide reviewable application starting points with explicit production checklists and capability boundaries.

🚀 Blueprints Design Philosophy

Every blueprint added to the CLI must meet three fundamental principles:

1. Clear first experience: Responsive, accessible interfaces whose browser assets and CSP are explicit.
2. Native Rust/Rullst Features: Demonstrate measured resource use, typed concurrency and explicit server/realtime boundaries.
3. Production-minded defaults: Generate .env.example, database configuration, and a conservative .gitignore; deployment readiness remains an application-level review.

The v13 privacy and age-assurance programme applies across blueprint shapes: minimize collection, disable optional tracking, generate explicit policies and rights workflows, and require age evidence only when the selected risk policy calls for it. Camera checks are not a universal default. The SaaS maintenance triage separately covers the v12.1/v13 payment and generator defects reported by Rullst/examples.

🗺️ Proposed blueprints (ordered from easiest to hardest)

These rows describe design targets and are not selectable CLI starters; ERP exists as the examples/erp application. A proposal becomes implemented only when its generated project and negative boundaries pass the release gates. Since 13.0.0-alpha.4 cargo rullst new --blueprint offers blank, api and saas; the former LMS, Blog, Portfolio and ERP starters are complete applications under the repository’s examples/ (see examples), and a new domain is more likely to arrive as an example than as a starter.

🔍 Highlighted Architectural Details

🪙 8. AI Credit-Based SaaS (The Token-Burner)

• Architecture goal: a server-owned chat flow with bounded SSE streaming, cancellation and provider error handling.
• Data Security goal: use a database transaction and provider-specific lock semantics to reserve credit before an LLM request. This workflow is not yet a generated, cross-database guarantee.
• Monetization goal: integrate a reviewed usage ledger with a supported payment adapter; billing portals remain provider/application work.

🏢 12. B2B Multi-Tenant Platform (The Corporate Boilerplate)

• Isolation goal: derive a validated TenantContext at the HTTP boundary and carry it explicitly through database, cache, queue and realtime operations. Rullst does not inject a tenant predicate into every arbitrary SQL statement.
• Permissions goal: typed roles (Admin, Member, Billing) enforced in middleware and again at sensitive service boundaries.
• Invitations goal: hashed, single-use, expiring invitation tokens delivered through a configured mail adapter.

💬 13. Discord-Like Realtime Chat

• Client goal: use server-rendered messages and an explicit WebSocket client without making bundle size a proxy for correctness.
• Scale gate: publish connection count, message mix, backpressure behavior, CPU/RSS, hardware and distributed topology before attaching capacity numbers.

🏥 9. Scheduling & Clinics (The Scheduler)

• Conflict-prevention goal: enforce a database constraint plus a transaction strategy tested on every declared backend; isolation level alone is not a universal double-booking proof.
• Reminder goal: use bounded, idempotent scheduler jobs and a configured mail adapter. Multi-instance leadership and durable retry must be explicit.

🤖 7. AI Agent & RAG Boilerplate (AI-Native)

• Structure goal: quarantine and scan bounded uploads, parse supported formats in an isolated adapter, generate embeddings and store an authorized index.
• Provider goal: expose an explicit provider selection and capability check. Changing an environment variable does not make data policy, schema or model behavior interchangeable.