Desenvolvimento Guiado por Blueprint

O FlowForge constrói o plano antes de construir o código. Uma mudança do tamanho de uma feature flui por uma disciplina de documentação — requisitos, arquitetura, design, um brief de produto — e só depois que o fundador ratifica esse plano é que ele vira tickets. Este capítulo explica o fluxo e as duas ideias que o tornam confiável: blueprints são sagrados e apenas dois portões.

O fluxo

Uma ideia em linguagem natural vira trabalho entregável por um caminho repetível:

ideia → requisitos → arquitetura → brief de design → PRD/po-brief → RATIFICAR → decompor → tickets vinculados

• Requisitos capturam a intenção do cliente literalmente e fixam escopo, critérios de aceite e restrições — antes que qualquer arquiteto chute uma API.
• Arquitetura e o brief de design decidem como será construído e quais diretrizes governam cada superfície.
• O PRD / po-brief é a declaração ratificável do trabalho pelo product owner.
• A ratificação pelo fundador transforma o plano em autorização.
• A decomposição deriva micro-tickets a partir do plano ratificado — cada um levando um rastro de volta até a cláusula de onde veio.

Blueprints são a fonte da verdade

Um blueprint ratificado — um PRD, um ADR, uma especificação capturada — é a fonte da verdade. A implementação segue o blueprint, nunca o contrário.

Quando o código e o blueprint discordam, você não edita silenciosamente o documento para casar com o código. Você traz a lacuna à tona, e o fundador decide qual lado está correto. Documentos ratificados só são emendáveis pelo fundador ou por um ciclo de ratificação explícito. É isso que “blueprints são sagrados” significa, e é por isso que o manual que você está lendo trata a própria arquitetura de informação como subordinada ao plano ratificado por trás dele.

O rastro de documentos

Cada ticket vincula-se de volta à cláusula do blueprint que o produziu — o rastro de documentos. É esse rastro que permite a qualquer pessoa, meses depois, perguntar “por que isto existe?” e obter uma resposta real, que corre de uma linha de código de volta até uma decisão ratificada. Espera-se que o trabalho do tamanho de uma feature carregue seus artefatos de blueprint (requisitos, po-brief, ADR — mais um mockup de design onde há uma tela) nesse rastro antes de o código ser despachado. Trabalho trivial e correções de bug passam livres — o portão é escalonado por tamanho, para que nunca alarme falso em trabalho pequeno.

ADRs: decisões que permanecem decididas

Registros de Decisão de Arquitetura capturam as bifurcações relevantes — o que foi escolhido, o que foi rejeitado e por quê — em um formato mesclável no git e rastreado em registro. Um ADR é como uma decisão permanece decidida: a próxima pessoa não a reabre do zero, ela lê o registro.

Apenas dois portões

O plano projeta exatamente onde o fundador é chamado a opinar, e o FlowForge não acrescenta aprovações além dessas. Os toques do fundador equivalem aos portões que o plano projetou — nem mais.

Concretamente: uma vez que o portão final de design ratifica o plano, o registro do plano ratificado é, em si, a autoridade para emitir os tickets desse plano. Você nunca empilha um pedido separado de “posso criar os tickets?” sobre um portão que já passou. Os tickets são derivados do plano ratificado, nunca criados à mão e nunca reaprovados. Uma execução correta de “planejar uma feature” mostra dois toques do fundador — ratificar o plano, revisar antes de os tickets serem escritos — e nenhuma nova pergunta sobre criação de tickets.

Faça certo, e faça uma vez

O guiado-por-blueprint é mais lento na primeira hora e mais rápido em cada hora depois. Decidir a arquitetura de antemão significa que você constrói a coisa uma vez, em vez de três. O plano é o lugar barato para errar; o código é o lugar caro.

Por que isso importa

O desenvolvimento guiado por blueprint é como o FlowForge impede que a velocidade da IA se transforme em dívida da IA. O plano é ratificado antes de o trabalho existir, cada ticket traça de volta até esse plano, e as decisões por trás dele ficam escritas onde serão encontradas. O resultado é uma base de código cujas razões são tão legíveis quanto o seu código.