Blueprints

A blueprint is a pre-built implementation pattern packaged as chain documents: requirements, stories with their acceptance criteria, architecture components and decision records, plus the reference assets the pattern needs, such as design tokens, an OpenAPI skeleton or a CI workflow example. Your agent composes one onto the project at define time:

rcf define blueprint add <source>

The contributions are copied into the chain under the blueprint's own namespace, spa-REQ-001 rather than REQ-001, so they can never collide with the documents you and your agent author. From that point on they are ordinary chain documents: coverage counts them, the build queue schedules them, and the verifier holds the built work to their checks.

Why compose instead of invent

Three reasons, in the order they matter.

Proven patterns over blank-page invention. When you ask for "an app with sign-in", your agent can invent an auth model from scratch, and every invention is a fresh set of decisions nobody reviewed. A blueprint is the reviewed version: the requirements, the checks and the recorded decisions for that capability, worked through once and reused. Your agent still does the building; it stops doing the inventing.

Consistency across builds. Two projects composed from the same blueprint share requirement structure, decision records and check vocabulary. When you run several small products, or hand one over, that sameness is worth a lot: anyone who has read one chain can read the next.

The gates already know the pattern. Because a blueprint arrives as acceptance criteria rather than as advice, the whole referee applies to it unchanged. A blueprint's checks are counted by coverage, enforced at the build cycle's review and finalise gates, and probed by the independent verifier, exactly like checks you wrote yourself. The pattern does not sit alongside the method; it is inside it.

Composition, and what happens on conflict

Blueprints are designed to stack. A working set for a small product might compose a SPA front end, a REST surface, auth and persistence onto one chain, and the namespacing keeps every contribution attributable to its source.

Two blueprints can genuinely disagree: each ships a project-wide decision record on the same topic, say two different auth models. rcf define blueprint add detects that and refuses, printing both sides and the honest ways out: adopt the incoming decision, keep the existing one, or supersede both with a project-level decision of your own via rcf define blueprint supersede. rcf define blueprint diff <topic> shows the disagreement side by side before you choose. The choice is always yours, recorded as a decision on the chain; nothing resolves silently.

Removal is guarded the same way. rcf define blueprint remove refuses while any document you authored still references a blueprint contribution, and tells you which ones.

What ships today, and what is in build

The compose mechanism ships in rcf-lite now: add, list, remove, supersede and diff are live verbs, and rcf help define blueprint prints the surface. The stock blueprint library is an active build. Fourteen stock blueprints exist today across seven categories, and are listed, with what each gives you and how to apply it, on the stock blueprints reference; they are applied from a local path, and resolving a blueprint by registry name or git reference is not built yet. As with everything on this site, the status page is the honest map of built versus building.