Ir para o conteúdo

Workflow de Desenvolvimento mindflow

Processo acordado entre PO e Tech Lead. Qualquer desvio deve ser discutido explicitamente.

Antes de codificar qualquer coisa

  1. Atualizar /docs/arquitetura/contrato-fb.md com os novos endpoints e/ou componentes frontend
  2. PO aprova o contrato (lê o diff, confirma que faz sentido)
  3. Tech Lead implementa em TDD: teste → código → verde
  4. Atualizar /docs/CHANGELOG.md com a feature

Nenhuma linha de código de feature entra sem contrato aprovado.

Ciclo TDD (por sessão)

1. Escrever o teste (red — vai falhar)
2. Rodar: pytest tests/test_X.py -v   →  confirmar que falha pelo motivo certo
3. Implementar o mínimo para passar
4. Rodar novamente: pytest tests/test_X.py -v   →  verde
5. Refatorar se necessário (sem quebrar o teste)
6. Commit: "feat(S1): schema v1 — testes passando"

Depois de implementar

  1. Verificar que o contrato em /docs/arquitetura/contrato-fb.md ainda bate com o código (request/response, auth, campos)
  2. Rodar a suite completa: pytest tests/ -v
  3. Commit com referência à sessão e ao contrato: feat(S2): rotina brisa — contrato-fb.md atualizado
  4. Se a sessão está completa, marcar como feita no /docs/versoes/v0.3-dev-plan.md

Regras de ouro

  • Sem contrato = sem código. Feature sem contrato aprovado não entra.
  • Sem teste = sem merge. Código novo sem teste não entra em main.
  • Contrato quebrado = bug. Se o código diverge do contrato, é regressão — corrige antes de avançar.
  • CI bloqueia. Push para main com testes falhando é barrado pelo GitHub Actions.

Referências

  • Plano detalhado: /docs/versoes/v0.3-dev-plan.md
  • Contrato frontend-backend: /docs/arquitetura/contrato-fb.md
  • Schema de metadados: /docs/arquitetura/metadata-schema.md
  • Changelog: /docs/CHANGELOG.md