Blueprint Discipline

FlowForge sells one thing above all others: disciplined delivery. The product’s keel is a single refusal — we don’t build features without blueprints first. The docs trail FlowForge produces along the way (feature → tickets → artifacts) is the proof a feature was designed before it was built, and it is beautiful enough to send to your client, your CTO, or your team lead.

This section documents that discipline: what it means, how the delivery process actually runs end to end, and how the blueprint-first gate keeps the discipline honest without nagging you over a typo fix.

What “blueprints sacred” means

A blueprint is the design layer of a feature — its requirements, its product-owner brief, its architecture decision (ADR), and, where a screen exists, its designer mockup. Once a blueprint is ratified, it is the source of truth. Implementation follows the blueprint, never the reverse. When code and blueprint disagree, the gap goes to the founder gap-by-gap — the document is never quietly edited to match the code.

That is a discipline, reinforced by a skill, not a hard programmatic lock on every file. The point is cultural and procedural: the design is authored, reviewed, and ratified before the worker that writes the code is ever dispatched.

Why it is the product

FlowForge refuses to write code before the documentation exists — and makes that refusal feel like a gift, because the artifacts it forces you to produce are worth keeping. Every architectural decision gets a number and a home in your repo. Every feature can be traced from its first ticket to its final chart, with nothing orphaned. That traceable trail is the live demo of what FlowForge sells.

This section

• The Process — the full delivery flow, node by node: from calling ACE, through requirements, blueprint, architecture, micro-tickets, worker dispatch, GOLDEN review, and the founder’s merge-go. Includes the process chart and an explanation of each gate.
• Blueprints Are Sacred — the doctrine: ratified blueprints as source of truth, implementation-follows-blueprint, and the gap-by-gap founder workflow.
• The Blueprint Gate — the size-tiered blueprint-first gate (#2066): how flowforge gate check works, why it warns by default and records every override, how to opt in to hard enforcement, and the enforced EMIT ⟺ RATIFIED chokepoint that lets implementation tickets be created only from a ratified blueprint. It also points to FlowForge’s honest enforcement registry — the map of what is enforced by construction versus what is still discipline.

If you are new to FlowForge, start with The Process for the big picture, then read The Blueprint Gate for the day-to-day mechanics.