• Routes (rules like "when someone opens /products, run this function") are grouped in modules and in prefixed groups (Routes::group("/admin", "admin.", …)), with names (route('products.edit', id) in templates), guards that decide who may open them (.require_auth(), .guest_only(), .require_verified(), .require_gate("admin"), .require_role(…), .require_permission(…), .require_ability(…) for API tokens, .require_password_confirmed()) and rate limits that cap how often someone may call them (.throttle(60, Duration::from_secs(60)), or a named limiter that picks the limit per user or API key: .throttle_by("api")).
• Routes for other hosts (Routes::domain("{account}.example.com", …)), a fallback for what nothing else answers, redirects by route name (Redirect::route, Redirect::intended), and the current route in views (route_is('admin.*')) and handlers (CurrentRoute).
• Route model binding: Found(post): Found<Post> loads the row {post}, {id} or {slug} names (404 if there's none, within the tenant's default scope). Pages without a handler (.view("/about", "about.html"), .redirect(…)), and .etag() for 304s on feeds and lists.
• Sessions (what the app remembers about a visitor between pages) live in an encrypted cookie (or the database with SESSION_DRIVER=database). Flash messages (shown once, on the next page), old input (what the visitor typed, kept after an error) and list/counter helpers (session.push, session.increment) come built in. CSRF protection, which stops other sites from sending forms in your visitors' name, is automatic for forms and htmx.
• _method spoofing lets plain HTML forms, which can only send GET and POST, send PUT and DELETE.
• Security headers and a Content-Security-Policy are on by default, CORS can be enabled per route, TRUSTED_HOSTS refuses other hosts, and App::xsrf_cookie() hands the CSRF token to JavaScript clients as Laravel's XSRF-TOKEN cookie.
• Webhooks (messages another service sends to your app, like "this order was paid") from payment gateways and other services (impl Webhook, .webhook::<W>(path)): signature checks (HMAC, Stripe-style), each event stored and processed once in the queue, with webhook:retry when something failed.
• Maintenance mode (my-app down --secret …) and /health are included.
• Plain and encrypted cookies (Cookies, SetCookie), downloads and streamed responses (Download), and abort(StatusCode::GONE, "…") for any status with a message.
• Your own middleware, code that runs around every request (App::layer, Routes::route_layer), shared services (App::provide), template filters (App::templates), data for every view (App::share) and async gates.

• Templates are HTML files with blanks the app fills in. Renox uses MiniJinja for them, with layouts, blocks and macros. While you develop, templates reload when you refresh the page.
• .fragment("block") answers htmx with just one block of the page, not the whole page. HxTrigger, HxRedirect and Back cover the rest.
• {{ csrf_field() }}, {{ method_field('PUT') }}, old(), error(), t() and route() work in every template (route('products.index', q=q) adds a query string), can('update', product) on models the handler wrapped with Can::new, and pagination(products) once imported from renox/pagination.html.
• asset('app.css') adds a content hash (?v=…) that changes when the file changes, so browsers can keep (cache) assets for a year and still get new versions.
• Stacks: a page or component pushes a script or a <meta> into the layout's {{ stack('scripts') }} / {{ stack('head') }}, once if asked ({% call push('scripts', once='chart') %}).
• Tailwind CSS without Node: rnx new --tailwind, and rnx serve / rnx build run Tailwind's standalone CLI (downloaded once, checked by SHA-256).
• Components are macros that see the request (old, error, t, can, auth), and a UI kit ships with Renox (renox/ui.html), with a warm default theme (Inter and Poppins bundled, a type scale that puts the important figure first; a classic theme too):
  • form fields, buttons, cards, alerts, sheets, menus, tabs and tables, with dark mode;
  • the page's frame: a navigation bar or a back office's sidebar, page headers, toolbars, row actions, lists, card grids and progress bars;
  • actions as Filament has them: a form in a sheet or slide-over sent with htmx (errors stay in the sheet, a success closes it with a toast), icon buttons with tooltips, counts on buttons, disabled buttons that say why, and keyboard shortcuts (⌘S);
  • the fields Filament has: radio groups, checkbox lists, toggle buttons, tags, a searchable select (its options can come from the server as you type, and new ones can be added and renamed in place), file drops, a date picker, key-value pairs, repeaters and wizards, fields shown only when another has a value, and nested form names (lines[0][qty]) read into a Vec of structs;
  • infolists for a record's page: labels and values formatted as money (APP_CURRENCY), dates, "3 hours ago", badges, Yes/No, swatches, pairs or Markdown;
  • keyboard support and WCAG AA contrast;
  • toasts (Toast::success(…), with a body, links, a duration and a position) and live validation.
• Dashboards without a chart library (renox::chart): figures with their change and a sparkline, line, area, bar, pie and doughnut charts drawn on the server as HTML and SVG (crosshair tooltips, keyboard, a data table, colours checked for colour blindness), values per day or month from a query (Trend::of(query, "created_at").over(period).sum(…)), a period filter, and widgets that load on their own and refresh.
• A data grid for dashboards (renox::grid): filters per column by kind (a date range calendar for dates), server pages and sorting in the URL, grouped headings, frozen columns, different columns on phones and desktops kept per user, and cells drawn by the page ({{ sparkline(…) }} charts, buttons); columns moved and resized by dragging, details with audit fields, editing in place, rows dragged into order, merged cells, and CSV/Excel/print exports. Also a search box, filter chips, rows that link to a page, several grids on one page, bulk and row actions, summaries and groups, cards on phones, image/badge/link/copyable cells, columns from related tables, an advanced filter, state remembered in the session and polling (guide).
• .also("block") sends out-of-band blocks with a fragment; HxRetarget, HxReswap and HxPushUrl set the other htmx headers.

• Every form field type maps to a Rust type and a column on both databases: checkboxes, selects (#[derive(DbEnum)]), multi-selects (Json<Vec<_>>), dates, times, JSON, UUIDs (docs/types.md).
• Migrations (small files that create or change tables) are plain SQL and run in batches (migrate, migrate:rollback, migrate:fresh --seed), with per-database files when SQL differs.
• A model is a Rust struct that matches a table: one struct is one row. #[derive(Model)] gives it create, save, delete (with optional soft deletes), find_or_404, a query builder (OR groups, sub-queries, where_has, aggregates, group_by/having, raw fragments, row locks, bulk updates, upserts, update_or_create, chunks), pagination (numbered, simple or by cursor) and factories with fake data. The key is the id field's type: a number the database counts, or a ULID, UUID or string (rnx make:model Invoice --module invoices --key ulid; the module must exist).
• Models can save only what changed (save_changes, save_only), run hooks (saving, saved, deleting, deleted), carry a default scope, e.g. the current tenant, that every query applies until unscoped(), and keep secrets encrypted at rest (Encrypted<String> fields, sealed with APP_KEY). Transactions nest with savepoints (tx.savepoint(…)).
• Relations (links between tables, like a post and its comments) are explicit and N+1-free, so a list never runs one extra query per row: belongs_to, has_many, many-to-many pivots (with pivot columns) and polymorphic Morph load a page's related rows in one query each (two for pivots: the pivot rows, then the models), and count_many / sum_many give counts and sums per row (guide); joins read into #[derive(FromRow)] structs with fetch_as.
• Full-text search over a model's columns, ranked, on both databases (SQLite FTS5, PostgreSQL tsvector): #[model(search = "title, body")], a migration from renox::db::search::migration::<Post>, then Post::search(&q) with any other filter and pagination; the database keeps the index current, and the data grid's search box uses it (guide).
• For anything else there's raw SQL with ? placeholders, and transactions that can retry on a busy database (db.transaction_retrying(3, …)): renox::db::sql("…").bind(x).fetch_all(&db).
• SQLite is the default. PostgreSQL is one feature flag away, with the same code (guide).

• Validation checks what people send before your code uses it. Valid<T> validates forms, JSON bodies and query strings with rules such as required, required_if, email, between, matches (regex), digits, dates (before, after), unique, exists, same, gt/lt against another field, decimal, alpha_dash, uuid, json, timezone, size, image, mimes, dimensions (pixels) and current_password, per item of a list (each, nested, distinct), and your own reusable Rules. Messages come in English, or from your own translations (resources/lang/<locale>.json). Simple forms declare them as attributes: #[derive(Validate)] with #[validate(required, email, unique("users", "email"))].
• Form requests: prepare tidies the input, authorize answers 403 before any rule, and after runs checks that need the database, with errors shown like a rule's.
• Auth::new() adds login, registration, logout, remember me, password reset and email verification, with Argon2id password hashing (passwords are stored scrambled, never as typed) and login throttling, on pages built with the UI kit; .account() adds a profile page (email change with re-verification, password, "log out other devices", delete account). Logout ends only this device. Password rules come from Password::min(12).mixed_case()… (.uncompromised() refuses passwords from known breaches, asking Have I Been Pwned by hash prefix), and users imported from Laravel log in with their bcrypt hashes.
• Two-factor authentication from the renox-2fa crate: one module, and users turn on codes from an authenticator app on their account page, with recovery codes (guide).
• Auth events (LoggedIn, LoginFailed, Registered, …) and an opt-in Audit module that records them, plus your own entries (audit::record).
• API tokens (Authorization: Bearer) with abilities and expiry serve mobile apps and integrations.
• Policies and gates, the rules for who may do what: user.authorize("update", &product)? in handlers, can(...) in views, App::gate_before for super-admins, and an opt-in Permissions module with roles and permissions (user.assign_role(db, "editor"), .require_role("editor")).

• The job queue holds work to do in the background (like sending a mail), so pages answer fast. It lives in your own database, with retries, backoff and queue:failed / queue:retry. On PostgreSQL, workers on several servers never take the same job. Queues drain in priority order (--queue high,default); jobs can be unique, encrypted, rate limited or kept from overlapping, have a failed hook, and run in chains or in batches with progress.
• The scheduler runs tasks at set times (every_minutes(5, …), daily_at("02:00", …), cron("30 9 * * 1-5", …), weekly_on, monthly_on, with weekdays(), between(…), on_failure(…)). It runs inside serve in APP_TIMEZONE or a task's own IANA zone, daylight saving included, and each run is claimed once when several servers share the database.
• Events and listeners are included: one part of the app announces "this happened", and other parts react.
• Mail comes from templates, with a text version, several recipients, cc/bcc, reply-to and attachments, SMTP in production and a preview page at /_renox/mail while developing. More mailers by name (App::mailer), and MAIL_FAILOVER to a second provider when the first is down.
• Notifications go by mail, to the database and through your own channels (WhatsApp, SMS…), now or through the queue, to users or to plain addresses, each in the recipient's language, with channels chosen per recipient. Mail views have t() and components (button, panel, table). Auth::new().notifications() adds a bell for the navigation bar: unread badge, a panel to read, mark and delete them, and new ones arriving live over Server-Sent Events.
• A queue dashboard at /_renox/queue (behind a gate) shows waiting jobs, throughput, failed jobs to retry or forget, and batch progress.
• state.http calls other services with timeouts and retries; in tests, app.fake_http() answers instead and no request reaches the network. Scheduled tasks can ping health checks.

• Uploads are ordinary form fields, checked by their content. They're stored locally or on S3/R2, with signed temporary URLs; storage.list, copy and rename work on both. More disks, each with a name (App::disk("backups", …), state.disk_named("backups")), sit next to the default.
• The cache keeps results you don't want to work out again (remember, put, forget, add, pull, increment). It lives in memory or in the database, with atomic locks (state.cache.lock("stock:42", ttl)) that hold across servers on the database store.
• Each visitor gets their own locale, the language the app speaks to them (chosen, or their browser's with App::detect_locale()), from resources/lang/*.json, with t(), plurals and Laravel's plural ranges. Renox's own texts are English; the same files translate them (ui.*, renox.auth.*, renox.validation.*).

• {{ seo(title=…, description=…, image=…) }} writes the title, description, canonical URL, OpenGraph and Twitter card tags.
• robots.txt is generated for you, and Sitemap builds sitemap.xml from routes and models. Staging servers say noindex. /favicon.ico answers a quiet 204 until you add one.
• Search Console verification, GA4 and Tag Manager come from .env, CSP-ready with nonces, and only in production.
• analytics::event(&session, "sign_up", …) reaches gtag with the htmx swap, the page or the next page. ServerEvent sends from the server through the Measurement Protocol, where ad blockers can't drop it.

use renox::prelude::*;
use renox::testing::TestApp;

#[renox::test]
async fn login_page_and_registration_errors() {
    let app = TestApp::new(App::new().module(Auth::new())).await; // fresh DB, fake mail and queue
    app.get("/login").await.assert_ok().assert_see("Log in");
    app.htmx().post("/register", &[("email", "nope")]).await.assert_invalid("email");
}

rnx make:module products --resource --fields "name:string price:money"  # a whole CRUD with tests
rnx make:module news --resource --model Article   # when the model's name isn't the module's in the singular
                                                  # also make:model -m, make:policy, make:job, make:factory, make:test…
rnx make:command orders:close --module orders     # a typed command (clap): --help, checked arguments, prompts
rnx route:list                                    # every route with its name, module and guards
rnx db:shell                                      # SQL prompt, no sqlite3/psql needed
rnx build && rnx make:deploy                      # dist/blog + Dockerfile, systemd (+ socket), Litestream

rnx make:deploy also writes a systemd socket unit: deploys then restart the app without refusing a single connection.

In production, timeouts keep a slow database or mail server from holding requests, /health feeds your load balancer, and panics in handlers, jobs and tasks are contained. CI checks this by stopping, pausing and locking the database under a running app (running in production). Tests are covered in docs/testing.md.

Every request gets an id that's in its log lines and its X-Request-Id. Logs can be JSON (LOG_FORMAT=json) or go to a file. App::report hands 500s, failed jobs and failed tasks to Sentry or a chat channel. Error pages use the app's layout. While developing, /_renox/debug shows the last requests with their SQL, and flags N+1 queries.

• CHEATSHEET.md has every common pattern in a few lines, and it's compiled in CI, so it can't go stale.
• llms.txt maps each topic to the one example file that shows it.
• Apps made by rnx new include an AGENTS.md (and a CLAUDE.md importing it) that tells an assistant how the project works; see Use Renox with Claude Code.