As Regras

O FlowForge vem com um livro de regras compacto — o sistema operacional de como o trabalho é feito. As regras são poucas, são universais em todo projeto, e as que sustentam a estrutura são aplicadas por máquina, não por memória. Este capítulo cobre as regras que você encontra no dia a dia e o modelo de aplicação por trás delas.

O núcleo universal

Um punhado de regras viaja com todo projeto FlowForge, não importa a linguagem ou a stack:

• Regra #5 — Toda sessão roda sobre um ticket. Seu trabalho fica atrelado a uma unidade rastreável, mensurável e faturável. Um ticket bem calibrado por entrega.
• Regra #18 — Nunca faça commit na main/develop. Sempre em branch de feature; branches protegidas permanecem limpas.
• Regra #3 — Desenvolvimento guiado por testes no código que importa. Testes primeiro na lógica central; bom senso, não dogma, em spikes e em interfaces descartáveis.
• Regra #33 — Sem atribuição à IA no histórico do git. Os commits se leem como um histórico profissional, de autoria humana. (Documentos e arquivos de agente podem creditar o assistente; mensagens de commit, não.)
• Regra #12 — Não feche um ticket sem a aprovação do fundador. A conclusão é uma decisão, não um efeito colateral.
• Regra #35 — Recorra aos agentes especialistas quando eles multiplicam você. Orquestre quando compensa; execute diretamente quando for mais rápido.

Há outras (35 no conjunto completo), mas estas são as que moldam a textura de um dia normal.

Bom senso, não dogma

As regras são uma disciplina, não uma camisa de força. A Regra #3 pede testes no código que importa e afrouxa a barra de cobertura em spikes descartáveis. A Regra #35 diz para orquestrar quando compensa e executar diretamente quando subir um especialista custaria mais do que o próprio trabalho. O objetivo é tornar a decisão certa barata, não substituir o pensamento por cerimônia.

Aplicação: máquina, não memória

Uma regra que vive apenas na cabeça de alguém é uma regra que é pulada sob prazo. A resposta do FlowForge é a aplicação estrutural — a regra é verdadeira por construção no ponto em que importa:

• Hooks verificam as regras que sustentam a estrutura em cada ação relevante. Tente fazer commit na main e o caminho de pré-commit barra você; despache um ticket pela raia errada e o guardião de despacho o recusa.
• O ponto de estrangulamento do merge recusa estruturalmente um pull request que altera a lógica central mas não entrega testes — o portão de TDD é aplicado, não apenas recomendado.
• /flowforge:dev:checkrules roda o livro de regras completo sob demanda, quando você quer uma leitura completa de conformidade.

O princípio é ser colado: os invariantes são tornados verdadeiros no ponto de estrangulamento, de modo que um ticket fechado é um fato aplicado, não uma esperança.

Autorreparo em vez de tickets de acompanhamento

Onde uma regra protege algo visível ao cliente, o FlowForge prefere reparar o sintoma automaticamente em vez de registrar uma anotação para depois. Caminhos obsoletos, hooks ausentes e desvios de configuração se consertam na instalação, na atualização e ao iniciar o cockpit. O fundador não estará presente para digitar a correção, então o sistema se conserta sozinho.

Por que isso importa

As regras tornam a velocidade segura. Como as que sustentam a estrutura são aplicadas por máquina, você obtém o benefício da disciplina sem ter de lembrá-la sob pressão — e o histórico que você produz é confiável precisamente porque os invariantes por trás dele nunca foram opcionais.