Changelog
RCF Lite changelog: release notes
Every release entry is kept here, newest first, with the technical changes and any action needed.
Expect a fast cadence: the package is 0.x, the surface still moves between minors, and a breaking change is signalled by a minor bump. This page is the canonical human record of those releases; the same record is published machine-readably at /docs/rcf/releases.json, which is what rcf version --check reads. To see whether you are behind right now:
rcf version --check
Each entry below says what changed and, more usefully, what it means for you. The package's own CHANGELOG carries the engineering-grade detail.
0.25.0, 8 September 2026
The Hetzner line opens with three blueprints in one round: a shipped Linux VM shape on Hetzner Cloud with the estate hardening baseline and a snapshot cadence, a docker-compose platform on top with healthchecks, secrets as file mounts and a first-class reverse-proxy artefact, and a Cloudflare Tunnel bridge that composes with Access when Zero Trust is applied and drops to public-hostname mode when it is not. The Cloudflare-line shelf from 0.24.0 keeps its shape; the Hetzner-line shelf is a sibling on the same reference, not a replacement. Every real-account probe across the round ships accountBoundSkipped for now, pending an operator ruling on the Hetzner and Cloudflare token vault; the local probes carry the ship-time verdicts and the throwaway-server CI fixture is shared across the three tracks. The follow-up Hetzner Object Storage adapter ships as a sequential PR under object-storage-s3 v1.1.0 after this release; the rcf-lite package version does not bump for it. The schema floor stays at @stravica-ai/rcf-schemas 0.6.1.
deploy-hetzner-server v1.0.0 joins the shelf. A Hetzner Cloud server provisioner with an hcloud-shaped adapter as the sole reader of the Hetzner API token through the applied security-secrets-management facade, a canonical server manifest under hetzner/servers/<name>.json, a cloud-init template that lands the estate hardening baseline on first boot (SSH key-only, root disabled, UFW default-deny incoming, a DOCKER-USER iptables chain, a fail2ban SSH jail, unattended-upgrades, a /live probe on a private interface), a Hetzner Cloud Firewall contract, and a snapshots-and-backups posture with a weekly snapshot as the default, daily and off as alternatives, and Hetzner-managed backups as the elicited paid option. Sits alongside deploy-cloudflare-workers on the deploy shelf; the deploy-family one-target-per-project rule applies at apply time (a project picks one deploy foot). Local probes cover cloud-init render, manifest schema and an hcloud dry-run; the three throwaway-server real-account probes (provision, cloud-init hardened, snapshot on demand) ship accountBoundSkipped pending the Hetzner token vault ruling. Ships the shared throwaway-server CI fixture the T-2 and T-3 tracks reuse (label-scoped provision, destroy and orphan sweep, hcloud pulled into a checksummed scratchpad, no system install). Declares capabilities: ["cloudHost"]. Mints the new global topics linuxCloudHostContract and snapshotAndBackupCadence.
platform-docker-compose-host v1.0.0 joins the shelf. A docker engine and compose plugin install invoked from the T-1 cloud-init playbook, a canonical compose layout (compose.yaml at the repo root, service-per-container, named networks and volumes), a healthcheck-required contract for every service, a restart discipline (restart: unless-stopped for long-running services, on-failure for jobs), a zero-downtime reload shape for the reverse proxy, secrets as compose file mounts referencing the applied secrets facade at 0o400, and log shipping to the elicited observability-logging sink (default journald, opt-in loki). Caddy is the shipped default reverse proxy with Traefik as the elicited alternative; Coolify was considered and rejected (the platform blueprint is the compose contract itself, not a wrapper around a hosted panel that keeps its own state). The reverse-proxy config is a first-class versioned artefact under caddy/Caddyfile or traefik/traefik.yaml with a smoke curl after every apply. Local probes drive real docker 29.6.2 and the caddy:2 container image (docker compose config lint, a secrets-as-files scan, a Caddyfile validate); the two real-account probes (minimal-stack-up, reload-burst) ship accountBoundSkipped. Extends the T-1 throwaway-server fixture in place with a two-service compose stack. Declares capabilities: ["containerHost"]. Mints the new global topic containerHostContract.
edge-cloudflare-tunnel v1.0.0 joins the shelf. cloudflared as a compose service (the default when containerHost is applied) or a systemd unit (the alternative for a bare cloudHost, per the vendor's cloudflared-as-a-service documentation), a tunnel manifest under cloudflare/tunnels/<name>.yaml (tunnel id, credentials reference into the applied secrets facade, ingress rules mapping a public hostname to an internal service URL with a mandatory catch-all http_status:404), and a hostname-management contract that creates the DNS route via the Cloudflare API. Composes with edge-cloudflare-access via zeroTrustGate: when Access is applied the ingress rule attaches the Access AUD in originRequest.access and the connector-side JWT check refuses requests without a valid Access assertion; when Access is not applied the tunnel ships in public-hostname mode. Tunnel is its own blueprint rather than an adapter on Access. Local probes cover manifest schema, cloudflared tunnel ingress validate and an AUD-presence sidecar-read check; the two real-account probes (connector-healthy, tunnel-hostname-routes) ship accountBoundSkipped pending the Cloudflare token vault ruling. Declares capabilities: ["tunnelBridge"]. Mints the new global topic edgeIngressBridge.
Verifying against the real engine. The three new blueprints extend the round-6 verification shape without adding a browser pack: every probe is node-only, and every probe that would need a real Hetzner or Cloudflare account for its full-fat behaviour is accountBound: true and records skipped with a stable reason on a CI run without one. The Caddyfile-validate probe on platform-docker-compose-host drives the caddy:2 container image directly through docker run --rm, so a run that says the reverse-proxy artefact validates has genuinely put it through Caddy. The hcloud probe on deploy-hetzner-server runs a dry-run against the Hetzner API with a token drawn through the secrets facade. The cloudflared tunnel ingress validate probe on edge-cloudflare-tunnel reads the shipped manifest and asserts the AUD is attached when Access is composed. All the probe reports land under .rcf/reports/blueprints/<slug>/ in the shape earlier probe packs set. The shared throwaway-server CI fixture is a T-1 contribution the other two tracks import; a real-account acceptance run against a throwaway Hetzner server (label-scoped, orphan-swept) lands once the token vault ruling is in.
Also in this release: an authoring-standard capability table extension. packages/rcf-lite/docs/blueprint-authoring.md section 6a gains three new capability rows to match the shelf: cloudHost, containerHost, tunnelBridge. Loader unchanged; the append is chunk-zero style.
What this means for you. A project on 0.24.0 upgrades with npm install rcf-lite@0.25.0 and every existing chain revalidates cleanly. If your product has outgrown Workers, or wants a persistent runtime alongside its Cloudflare edge, the three new blueprints give you a straight path from the visual shelf to a Hetzner-hosted backend without inventing the shapes yourself: deploy-hetzner-server for the VM, platform-docker-compose-host for the compose stack on top, and edge-cloudflare-tunnel for the ingress bridge back to the Cloudflare edge (with Access in front when you want a Zero-Trust gate). The Hetzner deploy foot sits next to deploy-cloudflare-workers on the shelf: pick one deploy target per project. The upgrade is not flagged breaking. For the whole picture, when to reach for the Hetzner line and how the three blueprints compose with the round-6 Cloudflare shelf, see Cloudflare-first projects (the four new sections at the foot of that page cover the round-7 additions).
0.24.0, 8 September 2026
Six Cloudflare-line blueprints land on the shelf and, with them, a coherent story for a whole product hosted on Cloudflare: a Workers KV facade, cron triggers with an expression-router, durable objects covering the strong-consistency single-cell shape and the hibernatable WebSocket hub shape, a Zero-Trust Access gate that the admin console reads to switch its sign-in surface, Turnstile with the pinned test keys running under a Playwright pack, and edge rate limiting with a committed manifest. Each blueprint verifies against the real Cloudflare engine through node-only probes (the fixtures drive miniflare and wrangler dev on the shared cf-platform fixture root), and one blueprint pack runs in a real browser against Cloudflare's live siteverify endpoint using the vendor's own public test keys so a run that says the surface works has genuinely put the thing under load. In the same release, application-admin-console moves to v1.1.0 and declares optional consumption of the new zeroTrustGate capability. The schema floor stays at @stravica-ai/rcf-schemas 0.6.1.
platform-cloudflare-kv v1.0.0 joins the shelf. A Workers KV facade as the sole reader of the KV namespace binding, a cache-aside helper, put, get, list with a prefix, TTL, and metadata-only lifecycle events (facadeReady, kvHit, kvMiss, kvWrite). Probes drive miniflare inside the shared packages/rcf-lite/test/fixtures/cf-platform/ fixture, plus one accountBound-skipped real-account eventual-consistency smoke. Declares capabilities: ["keyValueStore"]. Mints the new global topic keyValueStoreContract.
platform-cloudflare-cron-triggers v1.0.0 joins the shelf. A scheduled() handler contract with an expression-router, a skew-tolerance discipline, and metadata-only lifecycle events (cronReady, cronFired, cronSkewed, cronStalled, cronUnmatched). Probes drive wrangler dev --test-scheduled against the shared cf-platform fixture, plus one accountBound-skipped real-account scheduled smoke. Composes with jobs-background when the applied scheduler mode is workerCron. Declares capabilities: ["scheduledTrigger"]. Mints the new global topic scheduledTriggerContract.
platform-cloudflare-durable-objects v1.0.0 joins the shelf. Two shapes in one blueprint: a strong-consistency single-cell and a hibernatable WebSocket hub, alongside a sole-reader AST scan on the DO namespace binding, a storage round-trip, an alarm-fires-once check, and a hub-broadcast check. Probes drive wrangler dev on workerd against the shared cf-platform fixture (the round-6 gate lesson is that a probe that names an engine has to drive that engine, not a mock), plus one accountBound-skipped real-account storage-backend smoke. Declares capabilities: ["strongConsistencyCell", "hibernatableWebSocket"]. Mints the new global topics strongConsistencyCellContract and websocketHubContract.
edge-cloudflare-access v1.0.0 joins the shelf, and application-admin-console bumps to v1.1.0 in the same release to consume it. Access ships a JWT validator as the sole reader of the Cf-Access-Jwt-Assertion header, an Access application shape, an audit-event record with metadata-only secrecy, and a real-account gated-URL probe that runs accountBound-skipped without a Cloudflare account. Declares capabilities: ["zeroTrustGate"]. Mints the new global topic edgeAuthenticationGate. When Access is applied, the admin console reads the applied-sidecar and switches its sign-in surface to the Access-gated shape (no local login form; the principal reduction reads from request.auth). Absent zeroTrustGate, the admin console falls back to the v1.0.0 behaviour unchanged.
edge-cloudflare-turnstile v1.0.0 joins the shelf. Client widget mount pinned to the Cloudflare Turnstile host only, server-side siteverify against https://challenges.cloudflare.com/turnstile/v0/siteverify, a refuse-if-token-missing guard, and a magic-link mint-surface hook. Node probes drive the fixture, and a Playwright pack runs four checks against Cloudflare's live siteverify using the pinned public test sitekeys 1x00000000000000000000AA (always-pass), 2x00000000000000000000AB (always-fail) and 3x00000000000000000000FF (forced-interactive) with their paired secrets, so a CI run needs no real Turnstile credentials to exercise the deterministic branches. Declares capabilities: ["humanCheck"]. Mints the new global topic humanVerificationGate. First uiBearing: true blueprint on the Cloudflare-line shelf.
edge-cloudflare-rate-limiting v1.0.0 joins the shelf. A local manifest under cloudflare/rate-limits/*.json, manifest presence and schema validation, a drift-audit shape against the applied Cloudflare account, and metadata-only rate-limit events. One accountBound-skipped real-account burst-and-429 probe. Declares capabilities: ["edgeRateLimit"]. Mints the new global topic edgeThrottleContract.
Verifying against the real engine. The six new blueprints share the round-5 verification shape: each ships a small set of probes that drive a real Cloudflare engine rather than a mock. wrangler dev, workerd through wrangler dev, and miniflare each show up under their own probe rather than being papered over by a fake. The Turnstile blueprint is the round's exception on shape: it ships a Playwright pack with the pinned test sitekeys, so the browser-side widget and the server-side siteverify are both exercised end to end without a real vendor credential. Every probe that would need a real Cloudflare account for its full-fat behaviour is accountBound: true and records skipped with a stable reason on a CI run without one; the aggregate verdict counts those honestly. All the probe reports land under .rcf/reports/blueprints/<slug>/ in the shape earlier probe packs set.
Also in this release: an authoring-standard capability table extension. packages/rcf-lite/docs/blueprint-authoring.md section 6a gains seven new capability rows to match the shelf: keyValueStore, scheduledTrigger, strongConsistencyCell, hibernatableWebSocket, zeroTrustGate, humanCheck, edgeRateLimit. Loader unchanged; the append is chunk-zero style.
What this means for you. A project on 0.23.0 upgrades with npm install rcf-lite@0.24.0 and every existing chain revalidates cleanly. If your product is heading to Cloudflare, the six new blueprints give you a straight path from the visual shelf to a whole Cloudflare-hosted backend without inventing any of the shapes yourself: platform-cloudflare-kv for a KV facade, platform-cloudflare-cron-triggers for scheduled work, platform-cloudflare-durable-objects for strong-consistency cells or hibernatable WebSocket hubs, edge-cloudflare-access in front of admin surfaces (the admin console picks the gated shape up automatically at v1.1.0), edge-cloudflare-turnstile on public forms and mint surfaces, and edge-cloudflare-rate-limiting as the zone-level guard. If you have already applied application-admin-console at v1.0.0, re-apply to pick up v1.1.0 and the optional zeroTrustGate consumption; without Access on the project the behaviour is unchanged. The upgrade is not flagged breaking. For the whole Cloudflare-first story, when to reach for it and what to escape to Hetzner via the round-7 tunnel for, see Cloudflare-first projects.
0.23.0, 7 September 2026
Four infrastructure blueprints land on the shelf and, with them, the shape of a real product's backend: a Postgres store, an S3-shape object store, a Cloudflare Queues producer and consumer, and a background-jobs discipline that refuses to apply until a queue is applied. Each blueprint verifies against its real engine with node-only probes, so a run that says the surface works has genuinely put the thing under load rather than mocked it out. The security-secrets-management blueprint picks up a capabilities[] declaration in the same release so the object-store's refusal fires end to end. In the same release, deploy-cloudflare-workers moves to v1.2.0 to bless the Workers-with-static-assets shape as the SPA-on-Workers deploy target, and a small CLI fix stops stdout being truncated on very large outputs. The schema floor stays at @stravica-ai/rcf-schemas 0.6.1.
persistence-data-postgres v1.0.0 joins the shelf. A Postgres-backed durable store behind a single facade that is the sole reader of the pg client. Numbered forward-only migrations run inside per-file transactions, prepared-statement discipline is enforced by a source-tree AST scan (so a raw string concatenation on a query cannot slip through review), a transactional-atomicity helper composes multi-step writes, recovery pairs scheduled pg_dump with the vendor's point-in-time recovery, and a connection-pool posture is picked per deploy target. Declares capabilities: ["relationalStore"]. Six probes drive postgres:17-alpine in a shared fixture and land their reports under .rcf/reports/blueprints/persistence-data-postgres/. Conflicts by design with persistence-data-sqlite and persistence-data-d1 on the store choice and the migration discipline: adopting one of the three is a decision your project makes once. The round-6 Hyperdrive adapter slot is reserved at the driver boundary.
object-storage-s3 v1.0.0 joins the shelf, with security-secrets-management v1.0.1 as its enabling minor. An S3-API facade with Cloudflare R2 as the first adapter and MinIO as the local dev target: put, get, delete, list, a presigned-URL contract with a bounded TTL, multipart upload above an elicited threshold, and metadata-only lifecycle events. Declares capabilities: ["objectStorage"]. The blueprint refuses to apply on a project that has not applied security-secrets-management first, so a credential-holding surface cannot land without the machinery to look up its credentials; the deliberate escape hatch is --allow-no-secrets-yet, which records the acknowledgement on the sidecar and lets the store apply with a note that the secret source is not yet wired. In the same release, security-secrets-management moves to v1.0.1 and declares capabilities: ["secretsProvider"] so the refusal on the object-store fires end to end. Five probes run against MinIO plus one accountBound-skipped R2 smoke that runs against a real Cloudflare account when CI_HAS_CLOUDFLARE_ACCOUNT is set and records skipped otherwise.
messaging-queue-cloudflare v1.0.0 joins the shelf. A Cloudflare Queues producer facade, consumer registration on the Worker's queue handler, publish, consume, ack, retry with the attempt counter, dead-letter contract per Cloudflare's own defaults (3 retries, 4-day DLQ retention), batch consume, and metadata-only lifecycle events. Declares capabilities: ["queue"]. Five probes drive wrangler dev locally plus one accountBound-skipped concurrency smoke against a real account. The Postgres-backed queue sibling is reserved by slug (messaging-queue-postgres) for the projects that would rather run everything on the one database, and lands when demand is there.
jobs-background v1.0.0 joins the shelf. A background-jobs contract: named job definitions with a handler, an input schema, a retry policy and a timeout; a scheduler that takes cron expressions and one-shot delayed runs; retries on top of the applied queue; and a metadata-only run-log. Declares capabilities: ["backgroundJobs"]. The blueprint refuses to apply on a project that has not applied a queue blueprint first: it needs somewhere to enqueue work. The refusal fires with exit 3 and the stable message id jobs-background-no-queue; --allow-no-queue-yet is the deliberate escape hatch that records the acknowledgement on the sidecar and lets the shell apply with the surfaces gated on the queue disabled until a queue lands. Five probes: the apply-time refusal, the override behaviour, a fake-clock cron test, a retry-and-fail case, and an event-secrecy check on the run-log. The round-6 Workflows scheduler-mode slot is reserved at the ADR boundary.
Verifying against the real engine. The four new blueprints share a shape: each ships a small set of node-only probes that drive a real engine rather than a mock. Postgres runs as a container. MinIO stands in for the S3 API in local dev, and the R2 smoke runs against a real Cloudflare account when one is available. The queue and jobs probes drive an in-memory driver the fixture ships alongside the wrangler configuration, so the round-trip is exercised without a live wrangler process. Where a probe genuinely needs an account that CI does not have, it records skipped with a stable reason rather than silently passing; the aggregate verdict counts those honestly and the ship gate stays trustworthy about what was actually probed. All the probe reports land under .rcf/reports/blueprints/<slug>/ in the shape earlier probe packs set.
Also in this release: the SPA deploy target. deploy-cloudflare-workers moves to v1.2.0. The minor bump blesses the Workers-with-static-assets shape as the SPA-on-Workers deploy shape and lands two new elicits (assets-directory, run-worker-first), an ADR carrying Cloudflare's own landing-page recommendation, a shared sample-app fixture under the same fixture root the other round-5 blueprints use, and an assets-manifest-scan probe that reads the applied fixture's wrangler.toml and asserts the [assets] block is present, run_worker_first is set, and the Pages-only pages_build_output_dir field is absent. No new capability, no new topic; the v1.1.0 contribution set carries through unchanged.
Also in this release: a stdout truncation fix. bin/rcf.js now flushes stdout before process.exit at both exit sites. Before the fix, a command with a large output (first spotted on rcf audit coverage --format mermaid on the umbrella tree) could truncate at the 65536-byte pipe buffer.
What this means for you. A project on 0.22.0 upgrades with npm install rcf-lite@0.23.0 and every existing chain revalidates cleanly. The four new blueprints give you a straight path from the visual shelf you already had to a persistent, event-driven backend without inventing the shape yourself: apply security-secrets-management first, then persistence-data-postgres for a durable store, object-storage-s3 for files and blobs, messaging-queue-cloudflare for a queue, and jobs-background on top for scheduled and delayed work. Each one refuses to apply where a required predecessor is missing, and each refusal has a named override for a deliberate scaffolding pass. If your SPA already deploys with deploy-cloudflare-workers, re-apply to pick up v1.2.0 and the two new elicits: your existing wrangler configuration keeps working, and the new probe reads what you already had. The upgrade is not flagged breaking.
0.22.0, 7 September 2026
Five application blueprints fill in the visual shelf and, with them, a small but useful reuse: application-account-settings picks up the capability-gating mechanism the admin console shipped in 0.21.0, so the settings surfaces only render when the applied auth blueprint can back them. The four shipped auth blueprints and the logging blueprint pick up additive capability declarations in the same release. No new CLI verbs, no new flags, no new exit codes; the schema floor stays at @stravica-ai/rcf-schemas 0.6.1. Two more blueprints land quietly on the shelf ahead of their own 0.23.0 notes: persistence-data-postgres v1.0.0, object-storage-s3 v1.0.0, and a security-secrets-management v1.0.1 minor.
application-empty-error-states v1.0.0 joins the shelf. An eight-state contract for the moments a surface has nothing useful to say: not-found, forbidden, server-error, offline, permission-denied, empty-list, no-search-results, and the last-resort error boundary. Each state has an RFC 9110 status backing it where the status applies, a WCAG 2.2 AA accessible name and description, and an offline write-buffer contract that a reconnected surface must drain before it stops rendering the offline state. The shipped probe pack anchors eight surface-observable checks (one per state) so the ship gate refuses while any state's DOM claim goes missing.
application-file-upload v1.0.0 joins the shelf. A file-upload surface with the WCAG 2.5.7 keyboard-alternative gate on by default, a chunked and resumable transport contract (tus.io is the elicited alternative when a project already runs one), MIME-type, size and virus-scan refusals with explicit fail messages, and four break switches for exercising each refusal in a fixture. The shipped probe pack has four checks anchored to the keyboard-alternative, the chunk resume, the refusal messages and the tus.io round-trip.
application-forms-wizard v1.0.0 joins the shelf. The GOV.UK Design System's task-list and summary-list patterns as a multi-step wizard: per-step validation timing (blur, submit, or on-change with a debounce), an error-summary at the top with skip-links to the offending field, and a save-and-return contract with a draft-store transport left elicited on purpose (the wizard cannot ship a default when the drafts might land in a database, in local storage, or in your session store). Its probe pack anchors the task-list, the summary-list, the error-summary, and the save-and-return round-trip.
application-account-settings v1.0.0 joins the shelf. A self-service settings area with five capability-gated surfaces: profile, security, sessions, notification preferences, and theme. The blueprint reuses the admin-console capability-gating mechanism from 0.21.0, so a settings surface only renders when the applied auth blueprint (or an elicited custom auth answer) declares the capability that backs it. Applying without any auth blueprint refuses at add time with the same spec-verbatim message the admin console uses, and the deliberate escape hatch is --allow-no-auth-yet, which records the acknowledgement on the sidecar and lets the shell apply with every gated surface disabled. The shipped probe pack has five capability-gated checks; a check whose required capability is not on any applied blueprint records applicable: false rather than a pass or a fail, so the aggregate verdict stays honest about what was actually probed. A hosted-UI bridge is shipped for projects that link out to (or embed) a vendor's hosted identity portal, alongside the in-place self-service surface for projects that own their own auth.
Alongside account settings, the four shipped auth blueprints and the logging blueprint pick up additive capabilities[] declarations for three new strings: credentialSelfService (the vendor exposes an in-place password change and MFA surface), sessionInventory (the vendor exposes an inventory of active sessions with device labels and a terminate action) and hostedIdentityUi (the vendor points at a hosted portal the security tab can link out to or embed). security-auth-clerk moves to 1.3.0, security-auth-keycloak to 1.2.0, security-auth-oauth2 to 1.2.0, security-auth-magic-link to 1.2.0, observability-logging to 1.2.0. A project already applying one of these gets the new declarations automatically on the next apply, and the settings blueprint discovers the applied capability set the same way the admin console does.
application-onboarding-tour v1.0.0 joins the shelf. A first-run tour built on the ARIA APG dialog-modal pattern's tooltip-as-dialog shape: keyboard-only Escape and focus-return contracts, a checklist-on-dashboard fallback that collapses gracefully into the settings surface, and completion-state persistence with per-principal (when the auth blueprint declares principalDirectory) or local-storage layers. Four pack checks anchor the dialog contract, the Escape-and-return behaviour, the checklist collapse and the completion-state persistence.
Also on the shelf at this release, ahead of their own 0.23.0 notes. persistence-data-postgres v1.0.0 and object-storage-s3 v1.0.0 are the first round-5 blueprints to land, alongside the security-secrets-management v1.0.1 minor. Their own operator-facing notes and reference rows ship with 0.23.0; for now, the CLI lists them under rcf define blueprint list and applying either goes through the normal blueprint-add flow.
What this means for you. No CLI change and no schema move: a project on 0.21.0 upgrades with npm install rcf-lite@0.22.0 and every existing chain revalidates cleanly. If you are building a small product with a UI, one of the five new visual blueprints likely covers a surface you were about to invent from scratch: rcf define blueprint add @stock/application-empty-error-states, @stock/application-file-upload, @stock/application-forms-wizard, @stock/application-account-settings or @stock/application-onboarding-tour. If you have already composed one of the four auth blueprints, adding account settings picks up whatever capabilities that auth declares; if you have not yet composed an auth blueprint and want the settings shell in place first, apply it under --allow-no-auth-yet and add auth later. The upgrade is not flagged breaking.
0.21.0, 5 September 2026
Five visual-feature blueprints land on the shelf (data table, charts, dashboard, in-app notifications, admin console) and, with them, the mechanism that proves them: a blueprint can now ship a Playwright probe pack that rcf verify browser runs against your running app in a real browser, and the ship gate refuses while a surface check fails. The admin console only offers the surfaces your applied auth blueprint can support, because blueprints can now declare capabilities and ask you questions at apply time. The schema floor moves to @stravica-ai/rcf-schemas 0.6.1.
A probe pack is a small file a blueprint ships alongside its chain documents: an accessible-name check, a specific control on the shell header, an audit row's column set, driven against your app in an actual headless browser rather than a mock. The runner discovers packs on every applied blueprint, imports each one, and runs the checks each appliesTo predicate matches for the FBS you are verifying. rcf verify browser <fbs-id> is the entry point. --probe-pack <name> restricts a run to one pack by name; --no-browser skips provisioning a browser (a pack that calls browser.* sees browser=null); --no-boot disables a pack's declared bootCommand fallback when the runtime URL is unreachable. When the runtime is already answering, the boot block is skipped and the running server is used unchanged; the dev server is the normal path. Provisioning goes through the pinned Playwright MCP server by default, or through a playwright your project already resolves from its own node_modules when that shorter route is available. Every pack result rides on the manifest under browserVerification.probePacks[] and the ship gate reads them alongside the existing verdicts.
application-datatable v1.0.0 joins the shelf. The base grid: an aria-rowcount claim that matches the count of rendered rows plus one for the header, a total-row-count element with the same rendered number and a screen-reader hint, and a pagination summary with the exact showing <n> of <total> phrasing. Its shipped probe pack anchors the two ACs to the DOM: AC-19102-1 for the header semantics and AC-19105-1 for pagination-summary parity. Two more ACs are called out in the blueprint's Known mechanism-reach gaps section for probes to grow into later.
application-charts v1.0.0 joins the shelf. Chart shells that are readable by both a screen-reader user and a keyboard-only user: a text alternative announced through role="figure" and aria-labelledby, focusable data points that keep a visible focus ring, and, on the sparkline shape, a tooltip that both fills [aria-live="polite"] and updates the parent's aria-describedby. The shipped probe pack anchors three ACs on the chart shell, sparkline, and interactive plot. The remaining runtime-observable ACs (WCAG figure structure at scale, keyboard-focus behaviour beyond the tab set) are listed as gaps and covered by unit and anatomy tests until a probe reaches them.
application-dashboard v1.0.0 joins the shelf, with a packaged design-guidance asset. The dashboard blueprint ships a real component-library-agnostic layout brief inside its guide/ directory alongside the usual anatomy, so the agent implementing the surface has a design frame to build against rather than inventing one. Its Playwright probe pack anchors five ACs across the shell layout, the topline metric strip, the grid at desktop and mobile widths, and the responsive collapse (using a new pack.browser.resize({ width, height }) seam the runner exposes). The desktop-mobile pair is a first: earlier probe packs assumed a single viewport.
application-notifications-in-app v1.0.0 joins the shelf, with the family-prefix reservation for sibling channels. It ships the in-app notification shape (a toast region, an inbox surface, an unread badge with an accessible count) and a probe pack that anchors the toast region, the inbox row shape and the badge announcement. The blueprint reserves the application-notifications- family prefix on the shelf, so future siblings for the other channels (-email, -push, -webhook) compose on the same topic vocabulary without a rename.
application-admin-console v1.0.0 joins the shelf, with conditional surfaces and the new capability-declaration mechanism. The console shell always renders; the users directory renders only when your applied auth blueprint declares principalDirectory, the permissions matrix only when roleModel is declared, the org switcher only when tenancy is declared, and the audit log only when auditLog is declared. security-auth-magic-link v1.1.0 declares [principalDirectory] (no roles surface out of the box), security-auth-clerk v1.2.0, security-auth-oauth2 v1.1.0 and security-auth-keycloak v1.1.0 each declare [principalDirectory, roleModel]; add any of them and the admin console adapts. Applying application-admin-console with no auth blueprint applied refuses at add time with a spec-verbatim message naming security-auth-*; the deliberate escape hatch is --allow-no-auth-yet, which records the acknowledgement on the sidecar and lets the shell apply with every capability-gated surface disabled until you compose an auth blueprint. Its probe pack has four capability-gated checks: an absent required capability records applicable: false on that check rather than a pass or a fail, so the aggregate verdict stays honest.
Blueprints can now ask you questions at apply time. A blueprint declares elicits[] in its blueprint.json (each entry an id, a prompt, a kind of enum, string or boolean, an optional default, options for the enum kind, and an optional when predicate on already-applied capabilities). rcf define blueprint add prompts you interactively for each answer that applies to your project, and records the resolved answer bag on the per-blueprint sidecar at rcf/blueprints/<slug>.applied.json alongside the discovered capabilities. The admin console blueprint uses four elicits: the baseline-role roster when the auth blueprint declares roleModel, the tenancy shape when it declares tenancy, the invite transport (email by default), and the audit-retention window in days when it declares auditLog. For scripted apply, --answer <id>=<value> (repeatable) supplies one answer per flag and --answers <file> reads a JSON object mapping ids to values; a later --answer overrides an entry from --answers, so shell-level tweaks are easy.
The refusal at apply time when a blueprint's declared requiresAppliedCapabilities is not satisfied speaks a new exit code path: exit 3, the same code every other tree-soundness refusal uses. The message names the specific capability set your project is missing and the security-auth-* prefix so an operator can go and add the right auth blueprint; the escape hatch is the blueprint's own allowSkipFlag, which for the admin console is --allow-no-auth-yet.
The schema floor moves to @stravica-ai/rcf-schemas 0.6.1. The additive minor adds the optional browserVerification.probePacks[] field on the manifest record so a non-dry-run rcf verify browser --probe-pack <slug> can persist pack results into the manifest, per the visual round spec. Existing chains revalidate cleanly; a project on rcf-schemas 0.6.0 upgrades automatically when it bumps rcf-lite.
What this means for you. If you are building a small product with a UI, one of these five blueprints likely covers a surface you were about to invent from scratch: rcf define blueprint add @stock/application-datatable, @stock/application-charts, @stock/application-dashboard, @stock/application-notifications-in-app or @stock/application-admin-console. The four auth blueprints picked up minor bumps in the same release; a project already applying one gets the new capabilities[] declaration automatically on the next apply. If you want the admin console on a project that does not yet have an auth blueprint applied, either compose one of the four auth options first, or apply the admin console under --allow-no-auth-yet and add auth later. Running rcf verify browser <fbs-id> from now on picks up every applicable probe pack shipped by the blueprints you have composed; use --probe-pack <name> to narrow a run, and --no-browser if you want a smoke run with browser-driven checks skipped. The upgrade is not flagged breaking: the schema floor moved by a minor, and every new mechanism is opt-in.
0.20.0, 4 September 2026
An optional evaluation step joins the chain, for acceptance criteria whose outcome cannot be checked deterministically. You mark such a criterion when you define it, attach an EVAL document with its own pass threshold, and the audit, verify and finalise steps refuse to ship while it is missing. There is one explicit opt-out that records its reason on the manifest. The schema floor moves to @stravica-ai/rcf-schemas 0.6.0.
An EVAL is a graded example set for one or more acceptance criteria: cases the system under test is run against, criteria those cases are scored on, a judge (a rubric, an LLM run under your subscription, or a scripted metric), and a pass threshold. It sits alongside TS and TC as a peer contract on a non-deterministic AC. Determinism is per criterion, not per feature: a feature can carry both deterministic ACs (existing TS/TC coverage) and non-deterministic ACs (existing coverage plus an EVAL) side by side. A chain that carries no non-deterministic ACs is untouched by any of this.
rcf audit eval coverage [scope-id] is a new sibling of rcf audit coverage. It reports which non-deterministic ACs on the scoped subtree carry a resolving EVAL and which do not, where a resolving EVAL is a non-superseded document whose most recent runRecord[] entry is not pending. --strict exits 4 on any gap. --require-approved is an extra --strict gate that refuses any EVAL still at authoringStatus: draft. --format table | json | mermaid matches the coverage audit; the mermaid render colours a deterministic AC green (out of scope for eval), an amber node when a non-deterministic AC has a resolving EVAL, and a red node when it does not. A chain with zero non-deterministic ACs passes trivially at every level.
rcf verify run learns two per-AC verdicts on the report and prints one new preflight line. EVAL-MISSING fires on any non-deterministic AC without a resolving EVAL; EVAL-BELOW-THRESHOLD fires on any AC whose bound EVAL's most recent run fell below its declared threshold or hit a critical failure. Both ride report.perAcVerdicts[] alongside the 0.7.0 classes; the top-level verdict set is unchanged, so existing report readers keep working. The preflight prints EVAL coverage: nonDeterministic=<n>, covered=<k>, missing=<n-k> (or EVAL coverage: no nonDeterministic ACs on this chain), and the same numbers land on report.run.runStats.evalCoverage for a later re-render.
rcf build finalise refuses promotion to verified on either of the new verdicts, exit 4, with the spec-verbatim messages: finalise refused: EVAL missing on AC(s) <ids>; author an EVAL or --ship-without-eval "reason" and finalise refused: EVAL below threshold on AC(s) <ids>; investigate the run record or --ship-without-eval "reason". The sister opt-out --ship-without-eval "<reason>" acknowledges the verdict and lets finalise proceed with an audit-log entry on the manifest under a new optional shipWithoutEval[] array. The reason string is mandatory; a missing reason exits 2. This is the deliberate degraded-mode path for a harness offline in CI or a threshold under review; the acknowledgement is verbose in the console output and durable on the manifest.
rcf define create ac --determinism deterministic | nonDeterministic writes the marker onto the inline AC at author time. Absence writes no field, so existing chains stay byte-stable and every consumer resolves to deterministic by default. The enum guard fires the spec-verbatim message --determinism expects 'deterministic' or 'nonDeterministic', got '<value>' and exits 2. The LLM-as-judge invocation stays under the estate subscription-only rule: the runner spawns claude (or codex) by bare name and hands it a per-case prompt on stdin, the same pattern the verify launcher already uses. No API keys, no direct HTTP calls to Anthropic or OpenAI enter rcf-lite.
rcf init now scaffolds an rcf/evals/ directory alongside the other document families, and rcf define validate knows the twelfth document kind. Cross-links are integrity-checked at validate time: an EVAL's usId must resolve, every acIds[] entry must exist on the parent US, and cross-US EVAL bindings refuse. The core store's inversion map gains tree.evalByAcId, keyed on acId, so trace and impact walks reach EVALs from any AC they cover.
The release is flagged breaking under the pre-1.0 breaking-is-minor convention because the schema floor moves. A project on @stravica-ai/rcf-schemas 0.5.x cannot understand the EVAL document type or the AC-level determinism field; upgrading rcf-lite pulls the 0.6.0 schemas in. The chain revalidates cleanly because absence of determinism on existing ACs resolves to deterministic at every consumer.
What this means for you. If your chain has no non-deterministic behaviour, rcf audit eval coverage reports zero and the finalise gate reads no EVAL. Nothing changes. If your chain does, decide which ACs are non-deterministic, mark them at author time with rcf define create ac --determinism nonDeterministic (or reclassify an existing AC with rcf define update <ac-id> --set determinism=nonDeterministic), author an EVAL against each (rcf/evals/EVAL-NNN.json, one file per EVAL), and let the finalise gate refuse until the coverage is real. Two audit steps run alongside each other from here on: rcf audit coverage --strict for the mechanical test contract and rcf audit eval coverage --strict for the graded-output contract. Rerun rcf init in the project directory after the upgrade so the new rcf/evals/ directory is scaffolded alongside the other document families.
0.19.0, 4 September 2026
Core companions train. Two new general-enterprise-practice blueprints land on the shipped shelf, a companion-suggestion mechanism baked into every blueprint's manifest, and the standards-derived-blueprint discipline written into the authoring standard as section 8a. Nothing on the shelf breaks; every existing blueprint that does not declare suggestedCompanions[] loads clean and prints no block.
observability-logging v1.0.0 joins the shelf. It ships the ECS-neutral single-line JSON emission contract, correlation-identifier acceptance and propagation, PII redaction at the emission boundary by named category, an operator-elicited minimum level per environment, and a hermetic in-memory capture mode for tests. It declares providesRoles: ["logging"] and mints itself as the shelf-canonical scope: global claimant on the logging topic; application-api-rest-ADR-304 is retained on api-rest as historical context without scope: global from api-rest v2.1.0. Contributes five REQs, eight USs, two TACs and four ADRs under US band 15101 to 15899 and ADR/TAC suffix block 16xx.
application-error-handling v1.0.0 joins the shelf. Process-level and framework-level boundaries, the shared internal error record shape (code, category, message, correlationId, cause chain, redacted context), the transient / permanent / unknown classification vocabulary, and delegation of the wire mapping through a substitutable transportWriter interface. Declares providesRoles: ["errorHandling"] and suggestedCompanions: [{role: "logging", ...}] so the two blueprints work as a pair by default. errorHandling is a distinct topic from errorEnvelope, which stays with application-api-rest as the REST wire shape.
The companion-suggestion mechanism itself is additive on every blueprint. A blueprint that provides an infrastructural role declares providesRoles: string[] alongside its paired scope: global ADR on the topic. A service blueprint that recommends companions declares suggestedCompanions: [{role, reason}]. rcf define blueprint add walks a deterministic tier ladder for each recommended role (applied provider > project pin in rcf/companions.json > registered library provider > core-shelf provider) and prints one line per role in a Suggested companions this blueprint recommends alongside it: block after a successful apply, with an origin annotation on each. The apply itself never adopts a companion; that is the operator's decision. --companion <role>=<slug> on add (repeatable) pins a specific provider for one run and writes it to rcf/companions.json; --no-companion-suggestions suppresses the block. A new subverb pair rcf define blueprint companions set <role> <slug> and unset <role> writes and clears project-level pins; rcf define blueprint companions <slug> prints the resolved companion set for an already-applied service blueprint with the origin annotations. Two library candidates for one role with no pin refuse exit 3 with a three-path resolution message. rcf define validate refuses exit 3 on a pin that no applied blueprint, registered library or shelf provider satisfies.
application-api-rest moves to v2.1.0. Minor bump for the additive suggestedCompanions: [{role: "logging", ...}, {role: "errorHandling", ...}]; ADR-304-application-api-rest-logging is retained on the blueprint without scope: global and re-titled as historical context, superseded by observability-logging-ADR-1601 as the shelf-canonical logging owner from api-rest v2.1.0. Existing chains that referenced ADR-304 keep the reference intact; only the global-topic claim was dropped.
application-spa moves to v1.5.0. Minor bump for the same additive suggestedCompanions pair on logging and errorHandling.
The authoring standard grows section 8a on standards-derived blueprints. A MUST clause that binds a testable runtime or artefact behaviour becomes an AC; a MUST that binds an operator choice may land as a recommendedDefault: true ADR carrying the clause id on standardsTraceClause; a SHOULD becomes a recommended ADR default, a MAY becomes an elicited ADR choice, and a not-carried clause stays allowed with a named reason. Three additive optional per-ADR fields (recommendedDefault, elicited, standardsTraceClause) plus one blueprint-level field (standardsTrace: [{id, version}]) support the discipline; when standardsTrace[] is declared, every ADR contribution must carry a non-null standardsTraceClause (or the sentinel "generic enterprise practice").
The managed agent-instructions block gains one paragraph under How to talk to your operator teaching the agent to surface resolved companions verbally, prefer the library provider over the shelf when a library is registered, and never apply a companion without the operator's explicit go. Rerun rcf init in your project directory to refresh the block in place; rcf doctor --fix does the same if you prefer.
What this means for you. If your project is on application-api-rest v2.0.0 or application-spa v1.4.0, re-apply each with rcf define blueprint add <path-to>/blueprints/<slug> to pick up the additive suggestedCompanions; both bumps are minor and existing acceptance criteria carry across. If you want the shelf logging role, rcf define blueprint add @stock/observability-logging; for the shelf errorHandling role, rcf define blueprint add @stock/application-error-handling. A project that already superseded the logging topic at project level under v1.x keeps the supersede as historical context; the shelf-canonical claimant is observability-logging from this train onward, and rcf define blueprint remove-resolution <adr-id> clears any redundant resolution that a re-apply exposes. And rerun rcf init to pick up the new companions paragraph in the agent-instructions block.
0.18.0, 4 September 2026
Core shelf probe-path alignment. One shelf blueprint now owns the probe-path binding across the whole shelf, so a project that composes more than one of the observability and API blueprints no longer reconciles duplicate scope: global claims by hand. observability-probe-endpoints v1.1.0 is the sole claimant and gains an optional Kubernetes /startup path (off by default); observability-essentials v2.0.0 and application-api-rest v2.0.0 drop their shipped /healthz and /readyz defaults and defer to the resolved paths. rcf doctor grows a probe-path-owner check, and rcf define blueprint remove-resolution is the paired remedy verb for dropping a historical resolution that a blueprint bump has made redundant.
observability-probe-endpoints moves to v1.1.0. It is the sole shelf-wide scope: global claimant on healthProbes and readinessSemantics, and gains an optional Kubernetes-profile startup path (default /startup, off by default, enabled per project by probeInterface.options.kubernetes.startup.enabled: true). Two paired acceptance criteria cover the additive surface: three-path resolution on US-14102 and a three-entry auth-exempt list on US-14107. Downstream blueprints read the emitted path set via TAC-1501 getExemptPathSet.
observability-essentials moves to v2.0.0. It drops its scope: global claims on healthProbes and readinessSemantics, restates REQ-001 and REQ-002 path-neutral, and drops the shipped /healthz and /readyz defaults from TAC-801 and TAC-802 (the path field becomes required config with no default). ADR-801 and ADR-802 stay on disk as scope-local historical context. Two new ACs (AC-7101-4 and AC-7102-4) cover the stable-coded PROBE_INTERFACE_PATHS_MISSING boot refusal, so an essentials-alone project that forgets the config sees one loud message with a named code at boot rather than a probe missing at runtime.
application-api-rest moves to v2.0.0. It drops the literal /healthz/live, /healthz/ready, and /healthz/startup bindings from REQ-006, US-2108, TAC-306, and the US-2103 versioning-exemption AC. It defers to the resolved probe path set from observability-probe-endpoints v1.1.0 via TAC-1501 getExemptPathSet, or to a project-supplied probeInterface.paths in the essentials-alone case.
rcf doctor gains a probe-path-owner check that fires when more than one applied blueprint teaches probe paths. The paired remedy verb is rcf define blueprint remove-resolution <adr-id>, which drops a single manifest.resolutions[] entry by its resolvedByAdrId. It writes nothing else: the project-level ADR file at rcf/adrs/<adr-id>.json stays in place as historical context. Malformed or unknown ids refuse exit 2; re-running on a valid id that no longer names a resolution prints nothing to remove and exits 0.
What this means for you. If your project applies only observability-essentials v1.x, re-applying to v2.0.0 needs one line of configuration per environment (probeInterface.paths.liveness and probeInterface.paths.readiness), unless you also compose observability-probe-endpoints v1.1.0 or later, which supplies the paths automatically. If your project applies both observability-essentials v1.x and observability-probe-endpoints v1.0.0 with a project-level ADR superseding both on healthProbes and readinessSemantics, after re-apply the resolutions read as redundant historical context and the probe-path-owner check flags them with the remove-resolution hint. If your project applies application-api-rest v1.x, any FBS or TC that binds a literal /healthz/live, /healthz/ready, or /healthz/startup string needs one edit each to bind the resolved path set; rcf audit coverage --strict catches project-side TCs that still hold the literal strings after re-apply.
0.17.0, 4 September 2026
The e2e verification release for browser-facing projects. Verify pins the Playwright MCP browser tooling instead of pulling @latest, doctor gains four checks that fire only where they apply, rcf init learns not to trample an existing Playwright MCP entry, and two blueprints declare a browser surface so the tools know which projects the browser-facing checks concern. The materialiser that turns the shipped e2e job description into an actual running job lands in a follow-up train, so what ships here is a documentation contract: the shape is settled, the paperwork ships now, the runtime follows.
rcf verify run no longer provisions Playwright's browser MCP from @latest. It composes an explicit pin against @playwright/mcp@0.0.80, prints Playwright MCP: pinned to @playwright/mcp@<version> on preflight, and lands the effective pin on the report as runStats.playwrightMcpVersion, so a report re-read tells you which browser tooling that pass actually ran against. A new --playwright-mcp-version <semver> flag overrides the pin for one run (emergency use, fires a loud stderr notice, refuses non-semver values with an exit-2 message). A pin bump is a deliberate rcf-lite change from here on, with its own commit, its own changelog line, and a re-run of the verify test set against the pinned tooling where behaviour is affected.
rcf doctor learns to talk about the browser. Four new checks route through an applied blueprint's browserSurface: playwright-present confirms Playwright is installed in the project, browser-present finds either a system Chrome or a Playwright-managed cache, playwright-mcp-reachable proves the MCP itself starts and answers, and playwright-mcp-redundant catches a project-scope entry shadowing a user-scope one. API-only projects skip the four in one line naming them (--check <name> overrides the skip if you want to run one anyway), so the noise floor stays flat for projects that never open a browser. @playwright/mcp and playwright are declared as optional peer dependencies, so npm and pnpm still install rcf-lite cleanly on a project that never plans to use them.
rcf init grew a discipline of its own around the Playwright MCP entry. It writes one only when it cannot find one already: the project-scope .mcp.json's own entries first (matched by command tail, so a differently-named entry pointing at @playwright/mcp still counts), then claude mcp list for whichever scope the harness reports (5 second timeout, text-output parse). When it cannot prove absence (no claude on PATH, non-zero exit, unreadable output) it writes a distinctly named playwright-rcf project-scope entry that shadows nothing by naming convention and prints a could not probe notice explaining what it did and how to opt out. rcf init --no-playwright-mcp suppresses the write step entirely; the probe still runs so the print-out remains honest.
The application-spa blueprint moves to v1.4.0 and delivery-ci-workflows to v2.2.0. application-spa grows a top-level browserSurface object on its manifest ({ declared: true, routes: [...], themes: [...] }) and contributes two acceptance-criteria-bearing stories: an icon renders across declared themes on the home route, and an unauthenticated visit to a protected route lands on the sign-in page. delivery-ci-workflows v2.2.0 contributes a story that binds a paired acceptance criterion on the elicited e2e check: the materialised pull-request-checks workflow gains a distinct e2e job iff at least one applied blueprint declares browserSurface.declared: true and checkSet.e2e is not explicitly false. The shipped example workflow and the alternate-provider notes (GitLab CI, CircleCI, Buildkite, Jenkins) each ship the e2e job as a documented example. browserSurface lives on the source blueprint.json only, deliberately: the applied-blueprint record schema stays additionalProperties: false for this release, and doctor and the workflow materialiser both read the field back through the applied record's source reference. The additive schema change to the applied record lands in a separate @stravica-ai/rcf-schemas release.
What this means for you. If your project has a browser surface, apply or re-apply application-spa and delivery-ci-workflows to pick up the new stories, and run rcf doctor to see the four new checks report. If Playwright is missing from your machine, doctor will say so before verify does. If your project is API-only, nothing changes: the four checks skip in one line and verify's browser tooling never enters the picture. And if your .mcp.json already carries a Playwright MCP entry (from an earlier rcf init run or from your own hand), a fresh rcf init will leave it alone.
0.16.0, 3 September 2026
External blueprint libraries complete. Phase 2c lands git and tarball fetchers with an on-disk cache checked into the tree, so a fresh clone lists library blueprints without a network round-trip. A refresh path re-resolves the tag or digest and refuses on drift. Two amendments follow: plain-path adds are now library-aware so an author's local edit loop stamps the same identity a qualified add would, and the managed agent-instructions block gains a paragraph teaching the operator-chooses conversational shape.
rcf define blueprint library add now accepts git+<url>#<annotated-tag-or-sha> and tarball URLs (with --sha256 <hex> for the pin). Fetched content lands under rcf/.blueprint-libraries/<libraryPrefix>/<libraryRef>/ and is checked into git as ordinary tree content, so anyone cloning your repo can rcf define blueprint list and see the library's blueprints without fetching anything themselves. Floating branches refuse categorically (main, master, HEAD, latest, develop, trunk), lightweight tags refuse with a diagnostic that points at annotation as the fix, and a tarball digest mismatch refuses the fetch and writes nothing. rcf define blueprint library refresh <prefix> re-resolves the annotated tag's peeled commit for git sources or re-downloads and re-verifies the digest for tarball sources, and refuses on drift. remove drops the on-disk cache for network sources. Zero new runtime dependencies: the git side shells out to your ambient git CLI, the tarball side uses built-in fetch(), zlib and a bundled minimal tar parser. Authentication is out of scope for this v1; ambient git access is the model, and no-access is definitive.
rcf define blueprint add <path> now walks up from the target directory looking for a library.json file. On a hit, the resolver requires the target to sit at <library-root>/blueprints/<slug> and stamps the same effective slug and identity a qualified <prefix>:<slug> add would after registration. Library-qualified addressing and plain-path addressing now produce identical stamped ids, so an author's "edit the file, apply from the path" inner loop lines up cleanly with the "register the library, apply the slug" outer loop. A path with no library.json in any ancestor keeps the earlier behaviour byte-for-byte. The trade-off is deliberate: an unregistered local library bypasses the review-on-add card, and the local provenance warning on apply is the mitigation.
The managed agent-instructions block grew a new paragraph under "How to talk to your operator". It teaches the plain-language shape you want out of your agent: the agent enumerates the blueprints and any registered libraries and offers one that fits; you choose, the agent never picks; qualified names and command lines belong in files and rcf output, not in the conversation. rcf doctor --fix refreshes the block in place if your project has an older version.
A new authoring standard doc lands inside the package at docs/library-authoring.md covering the library shape, the library.json field contract, prefix and band rules, the local-path authoring loop, registration, refresh and drift handling, and how a library interacts with core. It ships alongside a minimum-viable worked-example library the docs and the test suite both consume, so a drift in either trips the suite.
What this means for you. If you were waiting on git or tarball libraries to move beyond a local path, they land here: library add git+<url>#<tag> or a tarball URL with --sha256, and the fetched content rides in your repo from there. If you author blueprints inside a library folder in a project, a path-based add now stamps the library identity for you, so your inner loop matches your outer loop. Re-run rcf init to refresh the managed agent-instructions block with the new blueprint paragraph. And if you have a bit of your own reading to catch up on, the new authoring doc is the place.
0.15.0, 31 August 2026
A same-evening fix wave on top of 0.14.0. Four PRs closing off the last surface before the WSD handover, none of them breaking. If you were happy on 0.14.0 you can update casually; there is nothing to migrate.
Library-applied records now carry a durable ownership stamp. A blueprint that resolved through a registered external library gets a libraryPrefix field written onto its manifest record, and blueprint library remove reads that stamp as the authoritative signal for which records to unwind. Pre-0.15 records fall back to the source prefix, so nothing you have already applied is orphaned. The upshot is that re-registering a library on your project under a different prefix (a rename, a split, a publisher change) no longer strands records that came from it. Records applied from the shelf or from a local path still write no prefix, because those routes are not library-owned in the first place. The stamp needs the paired schema, so the @stravica-ai/rcf-schemas pin is now exact at 0.5.1.
The review-on-add card grew two lines that the earlier release should have carried. When you point rcf define blueprint library add at a library, the review card now prints a "Global topics these blueprints claim" section listing every blueprint in the library that would take a project-wide ADR (one topic per line, and the section disappears entirely when no blueprint claims one), and a new unconditional "Prefix check" line that reports the collision-gate outcome alongside the existing band-check line. The cross-topic surface of a library is visible before you commit to registering it, which is what section 8.1 of the external-libraries spec asked for.
blueprint supersede --incoming now accepts every source form that add does. Before this release the verb only recognised local paths, so @stock/<slug> and bare kebab slugs came back with "no blueprint.json found" even though they resolve fine on the add path. The persona re-run caught it in the second arc of the day. The verb now routes --incoming through the same resolver add uses, so paths, @stock/<slug>, bare kebab slugs and colon-qualified <libraryPrefix>:<slug> all work verbatim, and library-qualified sources record their effective slug on the supersedes entry the same way apply already does.
The delivery-ci-workflows blueprint moves to v2.1 with three additive workflowShape fields. packageManager is elicited (pnpm default, npm and yarn and bun recognised), and defaultBranch and trunkBranch both default to main. The guide teaches the per-manager install and cache blocks, the shipped GitHub Actions assets carry substitution markers so the material output reflects your project's real branch model and package manager, and a new "Bootstrap posture (the guaranteed-red first run)" section in the guide and README, plus a shipped starting-point ADR under assets/bootstrap/, name and demote the coverage-strict bootstrap trap the second dogfood run surfaced. Existing v2.0.0 applications keep validating; nothing regenerates automatically.
What this means for you. Update whenever you next open the tool. If you had blueprint library add reviews land without a global-topics or prefix-check line, they will now; if you tried blueprint supersede --incoming @stock/<slug> and got a not-found error, it will resolve; and if you re-apply the delivery-ci-workflows blueprint, you will see the new elicitation for package manager and branch names. Everyone else, rcf version --check remains the honest way to know when you are behind.
0.14.0, 31 August 2026
The update-awareness release, plus one breaking rename. The ci-pipeline blueprint is now delivery-ci-workflows, and it grew up in the same move: you declare your workflow shape once in a small config file and the blueprint composes a two-tier check catalogue (validation and strict coverage always; linting, type checks, unit tests and security scanning as you choose them), a release workflow in one of four modes from plain tagging up to a deploy handoff, and an optional scheduled audit. rcf define blueprint add ci-pipeline no longer resolves; the refusal names the new slug.
The update-awareness half is why this page now has a machine-readable twin. rcf version prints the installed version with no network call, and rcf version --check fetches the release feed this site publishes at /docs/rcf/releases.json, compares it against your install, and tells you in one line whether you are behind. The result is cached for hours, there is no telemetry in either direction, and a kill switch exists if you want the check off entirely. A new agent rule runs the check once at session start, so your agent mentions a newer release and offers the upgrade; it never installs anything without your explicit go.
Smaller pieces in the same release. External blueprint libraries reached the next stage: a local folder of your own blueprints can be registered as a named library and applied with a library:slug reference alongside the stock shelf (git and tarball sources are still to come). The live docs viewer gained scoped deep links, so rcf audit view open --blueprint <slug> lands you directly on what that blueprint contributed. The Clerk auth blueprint picked up Workers-runtime samples at v1.1.0. The product identity is now RCF Lite in every string the tooling prints, matching the package name. And a fix worth naming: applied blueprints had stopped recording where they came from, which made the viewer's scope report count every contribution as missing and collapsed blueprint list into one uncategorised heap; both behave again.
What this means for you. If any script, CI step or note of yours says ci-pipeline, swap in delivery-ci-workflows before your next compose; chains that already applied the old slug keep validating, nothing regenerates behind your back. Everyone else, update and run rcf version --check once: from this release onwards your install can tell you when it is behind, which makes this the last release you should have to discover by accident.
0.13.0, 31 August 2026
The packaging release: a fresh npm install rcf-lite now behaves the way the docs say it does. The fourteen stock blueprints ship inside the package itself, and rcf define blueprint add accepts the bare slug (deploy-cloudflare-workers) or the @stock/ form; no repository checkout, no filesystem path. Installing on Node 23 or older now refuses outright with a message naming the version it found, where previously npm would quietly resolve an ancient placeholder package and leave you wondering why nothing worked. The placeholder acceptance criterion seeded when a story is created is now replaced by your first real one instead of hanging around as an unmet criterion in coverage. And rcf init writes the agent wiring as a portable npx command, so a project moved to another machine keeps working without a re-init, then signs off by pointing you at rcf doctor.
The deploy-cloudflare-workers blueprint also took its first content bump, to v1.1.0: seven fixes found by following its own teaching against the real wrangler CLI. The ones worth knowing about: static assets are now taught to run the Worker first on gated paths, closing a default where a file at the right path would silently skip your auth; the invented [secrets] config block is gone, replaced by how the platform actually enforces secrets (every env.<NAME> your Worker reads is checked at deploy time); the vendor's version id and the git commit sha are now treated as the two different identifiers they are, both carried on the promote record and reconciled by the verifier; and the one bootstrap sequence that is verified piece-by-piece rather than end to end says so, in the asset, honestly.
What this means for you. Update, especially if your install sits behind a Node version manager: if you installed on Node 22 or 23 and got a strangely inert rcf, this release is why, and a reinstall on Node 24 gets you the real package. Blueprint commands in the stock blueprints reference now work as written on a clean install. If you applied the deploy blueprint at v1.0.0, re-apply it to pick up the corrected teaching and the new auth-gate acceptance criterion; the contribution ids do not change, so your chain absorbs it cleanly.
The shelf grew, 31 August 2026
Round two of the stock blueprint shelf shipped: eight new blueprints, and the six original ones renamed to category-qualified slugs. The shelf now carries fourteen blueprints across seven categories. The new arrivals are security-secrets-management, email-smtp-resend, security-auth-clerk, security-auth-oauth2, security-auth-keycloak, deploy-cloudflare-workers, persistence-data-d1 and observability-probe-endpoints. The renames are spa to application-spa, rest to application-api-rest, auth to security-auth-magic-link, persistence to persistence-data-sqlite and observability to observability-essentials; ci-pipeline kept its name. Several new blueprints deliberately conflict with siblings on shared decisions: the four auth-family blueprints conflict on the project's authentication model, the two persistence blueprints conflict on the durable-store engine and migration discipline, and the two observability blueprints conflict on the health-probe interface and readiness semantics. The conflict machinery treats these the same as any other: the add refuses, both sides are shown, and the resolution you pick is recorded on the chain.
What this means for you. If your rcf define blueprint add commands or CI notes reference the old slugs (spa, rest, auth, persistence, observability), swap in the new ones next time you compose. Your existing chains carry the slug they were applied with and keep validating; nothing regenerates automatically. If you want any of the new capabilities, the stock blueprints reference lists what each one gives you and how to apply it.
0.12.0, 28 August 2026
Test-pointer honesty moved into the shared schema. A test case that claims passing or failing must now point at a real executable test, enforced by @stravica-ai/rcf-schemas 0.5.0 rather than by a local workaround inside rcf-lite; a pending or skipped test case no longer needs a pointer at all, because "no executable has landed yet" is exactly what those statuses mean.
What this means for you. Most projects need no change. If your chain carried a pointer on every test case, it keeps validating. If your agent had been inventing placeholder pointers just to get pending test cases past validation, that workaround can retire: pointer-less pending and skipped cases are now legitimate. A passing claim with no pointer behind it was refused before and is still refused, which is the point.
0.11.0, 27 August 2026
A guidance-only release: no CLI, schema or runtime changes. The shipped pack gained three driving rules for the agent: validate the chain before acting on it, report method findings in your language rather than method vocabulary, and treat the method's failure modes as its own self-checks rather than something you are expected to diagnose.
What this means for you. Update and your agent simply behaves better in the driving loop: fewer stale-chain surprises, and findings arrive as "the sign-in story has no check for expiry" rather than a wall of document ids. Nothing for you to run or migrate.
0.10.0, 26 August 2026
Breaking: the CLI reorganised around the five stages of the method. Every verb now lives in a group, rcf audit coverage rather than rcf coverage, rcf define validate rather than rcf validate, with a small core set (init, doctor, guidance, mcp, help) staying at the top level. Old forms fail with a message naming the new form. The separate rcf-verify binary is gone; verify lives at rcf verify inside the one CLI.
What this means for you. If your agent drives the tooling over MCP, nothing changes: the MCP tool names did not move. If you have shell scripts, CI steps or notes that invoke the CLI directly, rewrite them to the grouped form; the cheatsheet shows the whole surface as it now stands. The error message on an old form tells you the new one, so migration is mechanical.
0.9.0, 25 August 2026
The blueprint release. rcf define blueprint landed: compose a pre-built implementation pattern onto your chain, list and remove what is applied, and resolve genuine conflicts between blueprints deliberately instead of silently. The first six stock blueprints were built on the mechanism in the same cycle: SPA, REST, auth, persistence, CI pipeline and observability.
What this means for you. Capabilities most products need stop being blank-page inventions. How it works explains the idea; the stock blueprints reference lists what is on the shelf today and how to apply it.
0.7.1 and 0.8.0, 12 August 2026
The first releases under the rcf-lite name, bringing the previously separate tooling together as one package on the public npm registry. 0.8.0 added the shared standards ruleset and taught the verifier to catch a subtle dishonesty class: a test that is narrower in scope than the check it claims to prove, such as a mocked test standing behind a check that promises deployed behaviour.
What this means for you. These are the releases that made npm install rcf-lite a sentence. If you are on anything from this era, update: everything above applies.
Earlier
Before August 2026 the tooling shipped as separate per-piece packages under different names. That history is preserved in the repository's tags and changelogs but is not useful for running the product today.