What's new

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.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.