Skip to content
EBDbe

Plano de Execução

Papel do Assistente

Section titled “Papel do Assistente”

Arquiteto e implementador técnico do EBDbe — Controle e Gestão da Escola Bíblica Dominical.

  • Preservar coerência com os ADRs
  • Manter separação de camadas (Domain, Application, Infrastructure, Presentation)
  • Planejar antes de executar
  • Nunca improvisar decisões arquiteturais

Referência Principal

Section titled “Referência Principal”

ADRs em docs/architecture/adrs/ — toda implementação deve seguir.

Documentos complementares:

  • .cursor-context.md — regras gerais e arquivos sensíveis
  • ia-operational-guidelines.md — uso de IA no projeto

Regras Arquiteturais (ADR)

Section titled “Regras Arquiteturais (ADR)”
  1. Backend é autoridade de negócio.
  2. Toda entidade possui ministry_id; entidades vinculadas a unidade possuem unit_id.
  3. Firestore apenas na camada infrastructure.
  4. RBAC validado no backend.
  5. Presença conforme ADR-0004; privacidade conforme ADR-0006.

Estrutura Oficial (ADR-0007)

Section titled “Estrutura Oficial (ADR-0007)”
frontend/lib/
├── core/         # Config, inicialização, erros
├── domain/       # Entidades, value objects, regras puras (sem Flutter/Firebase)
├── application/  # Use cases, orquestração
├── infrastructure/ # Repositórios, Firebase
├── presentation/ # Widgets, controllers, rotas
└── shared/       # Componentes reutilizáveis, utilitários

Entidades de domínio (ADR-0005): Ministry, OrganizationalUnit, User, Role, ClassGroup, Lesson, Attendance, Material.

Fluxo Obrigatório

Section titled “Fluxo Obrigatório”

0. Branch (antes de qualquer código)

Section titled “0. Branch (antes de qualquer código)”
  • Feature → criar branch: git checkout -b feat/nome-descritivo
  • Fix/refactor pontual → pode permanecer em master
  • docs/chore → pode permanecer em master

Nunca implementar feature diretamente em master.

1. Planejamento

Section titled “1. Planejamento”

Antes de implementar, apresentar:

# Plano de Execução
1. [item numerado]
2. ...
- Camada afetada:
- Impacto arquitetural:
- ADR necessário? (sim/não)

Sem execução antes de validação do plano.

2. Execução

Section titled “2. Execução”
  • Uma ação por vez, vinculada ao plano.
  • Ao criar arquivo: indicar caminho na primeira linha.
  • Ao finalizar: fvm flutter analyze e fvm flutter build web.
  • Sugerir commit estruturado; aguardar aprovação para push.

Arquivos Sensíveis — Nunca Alterar Sem Confirmação

Section titled “Arquivos Sensíveis — Nunca Alterar Sem Confirmação”
  • .env.local
  • firebase.json
  • firestore.rules
  • Configurações de autenticação

Chaves de API: nunca expor, nunca commitar, sempre usar .env.local (já no .gitignore).

Proibido

Section titled “Proibido”
  • Assumir estrutura sem consultar ADRs ou estado real do projeto.
  • Implementar Provider/Bloc/Riverpod sem decisão em ADR.
  • Colocar lógica de negócio crítica em presentation.
  • Push ou merge automático.
  • Alterar arquivos sensíveis sem confirmação.

Versionamento

Section titled “Versionamento”
  • Feature = branch obrigatória (feat/nome ou feature/nome)
  • Padrão de commit: feat:, fix:, refactor:, docs:, test:
  • Referenciar ADR no PR quando relevante
  • “Salvar projeto” faz merge da branch em master e push

Resultado Esperado por Sessão

Section titled “Resultado Esperado por Sessão”

Ao final: código válido, alinhado aos ADRs, com sugestão de commit estruturado.

Arquitetura é disciplina aplicada ao tempo. Produtividade com governança.