Criar uma nova funcionalidade quando o ambiente de fundação já está consolidado (após a fase de Bootstrap). Este roteiro dita como avançar código sem romper os contratos de projeto ou negligenciar os painéis de status interligados.
Objetivo: Entregar uma nova capacidade funcional blindada pela rastreabilidade do escopo primário até a execução do teste.
Fontes da Verdade: Workflows/new-feature.md, Manual/16SCENARIOS-BASELINE.md e Manual/17EXECUTION-BASELINE.md.
Estrutura — O Rito de Nova Funcionalidade
A orquestração de inclusão de funcionalidade obedece a regras imutáveis do Baseline do Framework. Segue abaixo a literalidade da conduta.
1. Gatilho
Condição de partida: Ocorre formalmente quando surge uma Nova demanda funcional transcrita nas pendências do artefato Docs/tasks.md.2. A Regra de Ouro (Governança Obrigatória)
Transplantada do Manual 17 (Execution Baseline), toda feature nova é submetida as 4 leis irrevogáveis da execução:
1. O Bootstrap estrutural ocorreu e mora no passado (apenas na primeira task do projeto).
2. O desenvolvimento em andamento permite apenas EDIÇÃO de conteúdo nas pastas de código ou arquivos previstos (novos scaffolds não geram quebra do sistema e devem orbitar do Structure.md).
3. Cada Task concluída pela Feature gera OBRIGATORIAMENTE EXATAMENTE 1 Commit no repositório.
4. O Quality Gate (`Quality/gate.md`) é inalienável e ocorre antes do fechamento formal da tarefa corrente de Feature e de seu commit respectivo.3. Documentos Principais Editados
Os alicerces afetados por este workflow. Quem programa a feature vai obrigatoriamente interagir ou validar estes artefatos de governança:
- Docs/project.md
- Docs/user-stories.md
- Docs/plan.md
- Docs/tasks.md
- Docs/contract.yaml (Se API/Entidade for afetada)
- Docs/design-system.md / Docs/tokens.json (Se Design sofrer alteração visual)
- Quality/gate.md (No instante de validação limpa ou reprovação da task atual)4. Sequência Recomendada de Execução (O Core do Workflow)
Retirado fidedignamente do arquivo padrão do repósitório Workflows/new-feature.md, o desenvolvimento prático obedece este cronograma progressivo de 10 passos:
1. User Stories (Revisão da história exigida)
2. Contratos (Assinatura técnica da entrada e saída de dados, antes de tocar na lógica)
3. UI/UX (Mapear mudança da tela)
4. Fluxo (Verifica navegação real)
5. Prototype (Apenas quando houver interface nova ou alterada nas views)
6. Implementação (O Código em si — as horas de teclado real nas pastas 'src/')
7. Testes (Unitário e Integração acoplados)
8. Curl (Testagem final dos limites caso haja API persistente afetada)
9. Quality Gate (Execução da matriz limpa)
10. Atualização de Docs/control.md (Ata de fechamento atestando vitória ou bloqueios)5. Card de Cenário da Feature
Definido no Manual/16SCENARIOS-BASELINE.md, este é o padrão canônico para registrar a iniciativa formal antes de designar um Agente ou programador Humano à execução:
# Contexto
[Resumo do porquê programaremos essa nova feature. Ex: Ampliar busca.]
# Objetivo
[O que deve ser entregue pronto ao cliente e o que sequer entra em escopo.]
# Workflow e Skills
Workflows/new-feature.md acoplado com as Skills/... necessárias (ex: Node/React).
# Evidências Exigidas
- Quality Gate aprovado evidenciado
- O Hash do commit cravado no log
- Riscos (se sobrou algo pendente) guardados no Control.md.Prompt para gerar com agente (Workflow Start)
Atue como ExecutionAgent.
Objetivo: Iniciar o trabalho na Feature baseada no caso de uso [X].
Workflow associado: new-feature
Carregue os contextos fundamentais do Docs/tasks.md atual onde essa feature está endereçada, acople o contrato YAML para obedecer limites de persistência de dados. Leia a Seção 4 (Workflow de 10 Passos) e siga rigorosamente este mapa. Detenha-se no passo 9 e aguarde confirmação manual minha para fechar o Quality Gate oficial antes de aprovar o commit isolado.Definição de pronto
A Feature Nova foi integralmente desenvolvida de forma orgânica ao Nébula se atendeu a:
- O Workflow de 10 passos transitou por Contratos e Prototype antes do item 6 (Implementação real física na pasta de dev).
- O passo de Curl/Testes confirmou ausência absoluta de "Mocks disfarçados".
- A regra de "um único commit" para essa task atômica funcionou limpamente associada ao Quality Gate.
- A vitória não foi presumida, devendo figurar devidamente documentada explodindo o gargalo no doc de Controle Direto do Master.
Confundir "Programar Nova Feature" com apenas "Abrir as subpastas da aplicação e começar a escrever o Código", é esquecer que o framework exige preceções. Iniciar as lógicas do passo 6 sem ratificar que a história de usuário bateu com o YAML estático do contrato no passo 2 garante, estatisticamente, o retrabalho ou o nascimento de "Remendos" que estourarão na migração de Deployment.