Reference
Stock blueprints
Every stock blueprint ships inside the rcf-lite npm package. This page lists exactly what is on the shelf, nothing that is not, and how to compose each one.
This page lists the stock blueprints that exist right now. If a blueprint is not on this page, it does not exist yet; when a new one lands, this page grows a row. What a blueprint is and how composition works is covered in how it works.
Where they live and how to apply one
The stock blueprints ship inside the rcf-lite npm package itself, alongside the compose mechanism. Applying one is a single command, no repository checkout, no filesystem path:
rcf define blueprint add @stock/<slug>
The bare slug does the same thing: rcf define blueprint add application-spa resolves to the same packaged shelf. A filesystem path still works too, for a blueprint of your own. Mistype a slug and the refusal prints every slug on the shelf back at you, so the error message doubles as the catalogue.
Each blueprint's directory inside the installed package carries its own README with the full anatomy, and a guide/ doc covering when to use it, when not to, and what stays your call. The same files are browsable in the public rcf-lite repository.
The shelf
The shelf groups by category, an optional lower-kebab tag each blueprint.json may declare. Categories name the shelf drawer a blueprint belongs to and give the shelf room to grow past a handful without turning into a flat wall. rcf define blueprint list on your own project groups by the same field. The starter vocabulary is documented in the blueprint authoring standard; new categories are added there, not by patching code.
application
Whole-app shapes.
| Blueprint | Version | Gives you |
|---|---|---|
application-spa |
1.3.1 | A single-page application pattern: public and authenticated surfaces, session-based auth, dark and light themes, responsive by default. Ships design tokens, a stylesheet, nine canonical wireframes, component behaviour contracts and sample data alongside a full requirements set and its acceptance criteria. |
application-api-rest |
1.0.0 | A REST service pattern: versioned wire contract, problem-details errors, pagination envelope, four auth classes, no UI in scope. Ships an OpenAPI skeleton, middleware behaviour contracts and request-response sample pairs. Composes with application-spa by design. |
security
Auth and secrets.
| Blueprint | Version | Gives you |
|---|---|---|
security-auth-magic-link |
1.0.0 | Passwordless magic-link sign-in with server-issued opaque cookie sessions, pluggable email delivery and a pluggable principal registry. Ships email templates, a stub adapter for tests and two registry patterns for solo operators and small teams. |
security-auth-clerk |
1.1.0 | Hosted identity via Clerk. The vendor owns the sign-in surface, credential storage, MFA and account recovery; the project owns a framework-agnostic middleware boundary, a session verifier confined to one module, and a reduced principal shape the rest of the codebase reasons against. |
security-auth-oauth2 |
1.0.0 | Vendor-neutral delegated identity via OAuth2 authorisation-code plus PKCE against any project-configured IdP (Google, GitHub, Microsoft, Okta, Auth0, a corporate ADFS-fronted OIDC, a self-hosted issuer). Ships a fixed provider-abstraction contract; the project drops in the provider it wants. |
security-auth-keycloak |
1.0.0 | Delegated identity to a Keycloak realm the operator runs, federated through OIDC. Per-realm verification mode (JWKS or token introspection), a role adapter, a provider-routing seam, and an optional application session on top. For the vendor-neutral shape use security-auth-oauth2 instead. |
security-secrets-management |
1.0.0 | A vendor-agnostic secrets management contract: a repo-root secrets.yaml manifest, a single Secrets Manager client every call site imports, least-privilege per-deployable slices, a durable metadata-only audit trail, an agent-safe piped-stdin CLI, and .env treated as an ephemeral regenerable reflection. |
The four auth-family blueprints deliberately disagree with each other on the project's authentication model. Composing any two on one chain raises a globalAdrTopic conflict at rcf define blueprint add; the four documented resolutions (adopt the incoming, keep the existing, project-level supersede, or --resolve authModel=project:<ADR-id> on the add) apply as they do for every conflict.
email
Message delivery adapters.
| Blueprint | Version | Gives you |
|---|---|---|
email-smtp-resend |
1.0.0 | A Resend-backed SMTP mail adapter that fills the magic-link blueprint's email-delivery slot as a shipped default. Retry-and-backoff posture, four-class error taxonomy, and webhook signature verification with replay defence. Pairs with security-auth-magic-link; a future sibling for a different vendor slots in on the same shape. |
persistence
Durable stores and migration discipline.
| Blueprint | Version | Gives you |
|---|---|---|
persistence-data-sqlite |
1.0.0 | A SQLite-first durable store behind a single facade, with a forward-only numbered migration catalog applied atomically at open and a downtime-free file-level backup procedure. |
persistence-data-d1 |
1.0.0 | Cloudflare D1 as the durable store for Workers-deployed applications, behind a request-scoped Worker-side facade. Numbered forward-only migrations owned by the wrangler CLI, a deploy pipeline gate ordering migrations strictly before the Worker deploy, prepared-statement discipline that closes the SQL-injection surface by construction, and a two-path recovery model (Time Travel plus scheduled portable export). |
Composing persistence-data-sqlite with persistence-data-d1 raises deliberate conflicts on the durable-store and migration-discipline decisions; the same conflict resolutions apply.
delivery
Gates that fire on the way in.
| Blueprint | Version | Gives you |
|---|---|---|
delivery-ci-workflows |
2.1.0 | The full workflow set a project runs on its CI provider, composed from a workflow shape you declare once in a small config file. Two commit-triggered check workflows run a two-tier catalogue: rcf define validate and rcf audit coverage --strict always, then linting, type checks, unit tests and security scanning as you choose them, all with machine-readable reports. A release workflow scales across four modes from plain tagging up to a deploy handoff, and a scheduled audit is there if you want it. GitHub Actions workflows ship as the worked example; notes map the same entry points onto GitLab CI, CircleCI, Buildkite and Jenkins. |
observability
Health, readiness, probes, status pages.
| Blueprint | Version | Gives you |
|---|---|---|
observability-essentials |
1.0.0 | Liveness and readiness HTTP probes with strict semantics, a public status page with machine-readable incident notices, and a durable notification-outcome sink. For projects that own their observability floor. |
observability-probe-endpoints |
1.0.0 | A health probe interface derived from an operator-declared target integration profile: Kubernetes, load balancer, uptime monitor, systemd, docker healthcheck, reverse proxy, plus a custom:<name> slot. Each profile fixes the transport, path or command surface, response contract, and the liveness-versus-readiness distinction for the supervisor at hand. For projects that integrate with a specific external supervisor and let its conventions drive the wire shape. |
Composing observability-essentials with observability-probe-endpoints raises deliberate conflicts on the health-probe and readiness-semantics decisions, because the two blueprints answer different questions. Pick the one that matches your case, or supersede both with a project-level decision.
deploy
How bits reach a running target.
| Blueprint | Version | Gives you |
|---|---|---|
deploy-cloudflare-workers |
1.1.0 | Cloudflare Workers deploy with an artefact-upload plus explicit-promote model: three addressable URLs (per-version, stable preview alias, production), a single Deploy Adapter as the sole vendor caller, a repo-root wrangler manifest as the sole declaration of deploy shape, rollback-is-promote, and a served-surface verifier on every promote. |
Apply commands
The compose command is the same for each, and this list is generated from the packaged shelf at build time:
rcf define blueprint add @stock/application-api-rest
rcf define blueprint add @stock/application-spa
rcf define blueprint add @stock/delivery-ci-workflows
rcf define blueprint add @stock/deploy-cloudflare-workers
rcf define blueprint add @stock/email-smtp-resend
rcf define blueprint add @stock/observability-essentials
rcf define blueprint add @stock/observability-probe-endpoints
rcf define blueprint add @stock/persistence-data-d1
rcf define blueprint add @stock/persistence-data-sqlite
rcf define blueprint add @stock/security-auth-clerk
rcf define blueprint add @stock/security-auth-keycloak
rcf define blueprint add @stock/security-auth-magic-link
rcf define blueprint add @stock/security-auth-oauth2
rcf define blueprint add @stock/security-secrets-management
Most projects apply a handful, not the full set. application-spa and application-api-rest carry two deliberate project-wide decision conflicts between them; the four auth-family blueprints each carry the same conflict on authModel with the others; the two persistence blueprints conflict on persistenceStore and migrationDiscipline; the two observability blueprints conflict on healthProbes and readinessSemantics. These are not accidents but a demonstration of the conflict machinery doing its job: the add refuses, shows both sides, and records whichever resolution you choose.
Checking this page
The shelf above is checkable the same way the status page is: the packaged shelf inside the installed rcf-lite is the truth, and the slugs, versions and apply commands on this page are read from it at build time. rcf define blueprint list prints what is applied to your own project, and misspelling a slug at rcf define blueprint add prints the live shelf list back at you. If a blueprint listed here is missing from the package, that is a defect in this page.