Docs / Hand-off & history

Generation preview

The generation preview is the final step, where an approved feature leaves REEZN. It hands each approved REASONS canvas to you as a clean markdown document you can copy or download, ready to feed to your engineers or your AI coding tools.

When it unlocks

The preview unlocks only once the feature is fully Approved, meaning every canvas on it has been signed off. Until then the tab is locked, showing how many of the feature’s canvases are approved so far (for example, “1 of 2 canvases approved”). A single-service feature unlocks as soon as its one canvas is approved; a multi-service feature has to clear every canvas first, so it stays locked while it sits in Partially approved.

The lock is the same gate that completes the feature: reaching Approved is what both finishes the workflow and opens the preview. There is nothing extra to do once the last canvas is signed off.

On the Business plan, the preview also offers a Generate implementation action: instead of only exporting the blueprint, REEZN can implement it, open pull requests, and verify its own work behind a further human sign-off. See implementation & verification.

What you get: one export per service

The preview does not bundle everything into one combined file. Instead it lists each approved canvas separately, one per service the feature touches, and you export each one on its own. Each export is that service’s full REASONS canvas as markdown: all seven sections (Requirements, Entities, Approach, Structure, Operations, Norms, Safeguards) with their headings and content, exactly as approved.

Keeping the exports per service mirrors how the canvases were built and reviewed: each one speaks in terms of that service’s real stack, and each goes to whoever owns that service. A feature spanning two services gives you two canvases to export, side by side in the preview.

The export is the approved canvas, the “how to build it” blueprint per service. The analysis document (the “did we understand the ask?” record) lives on its own tab and isn’t folded into these exports.

Copy or download

Each canvas in the preview carries its own “Approved” badge and two actions:

Copy: Puts that canvas’s full markdown on your clipboard in one click; the button briefly flips to “Copied.” Best for pasting straight into a coding agent, a ticket, or a chat.
Download .md: Saves that canvas as a markdown file named for the service and version (for example canvas-billing-api-v1.md), so it lands on disk with a clear, traceable name. Best for committing the plan into a repo or attaching it to a pull request.

Handing it to your AI coding tools

A canvas is grounded context an AI coding tool can build from directly. Each export in the preview comes prefixed with ready-made implementation instructions, so you can paste it (or attach the downloaded .md) straight into your coding agent as the task prompt - no separate command to set up. A toggle on the preview lets you export the bare canvas without the instructions if your team already has its own prompt.

You don’t have to use an AI tool, of course. The same markdown drops just as cleanly into a ticket, a design doc, or a pull-request description for engineers to pick up by hand.

On the Team plan and higher, a coding agent can also pull an approved blueprint directly, without a copy-paste step, over REEZN’s read-only MCP server.

Always the current version

The preview always reflects the feature’s current version. Each version keeps its own canvases, so if you create a new version and it is approved, the preview exports that version’s plans, and the filename’s version suffix tells you which one you’re holding. Older versions stay viewable in history, but it is the latest approved plan that the preview hands off.

Why this exists

The value of an agreed plan is that it travels. Exporting each approved canvas as clean markdown means the same blueprint that was reviewed is the one that gets built from, with no retyping and no drift between “what we agreed” and “what got handed off.” Keeping the exports per service, and feeding them to your coding tools as grounded context, is how a structured review turns into structured code rather than slop.