Diagnóstico atual do projeto EBDbe

Data de referência: 17/03/2026

1) Visão Executiva

O projeto EBDbe possui direção de produto e arquitetura bem definidas em documentação (Vision + ADRs), com implementação funcional relevante já entregue em frontend e backend.
O estado atual é de maturidade intermediária: há features implementadas e integradas, porém coexistem itens ainda em proposta formal, lacunas de qualidade automatizada e bloqueios operacionais de ambiente.

Status geral consolidado:

• Objetivos e princípios: Definidos e rastreáveis.
• Macrofeatures de produto: 3 implementadas, 2 parciais/propostas.
• Base técnica (Flutter Web + Firebase/Functions): Ativa e funcional.
• Qualidade automatizada: Parcial no frontend e insuficiente no backend.
• Documentação do site: Starlight em docs/, publicação em docs.ebdbe.com.br (Firebase Hosting docs-prod).

2) Objetivos Vigentes (Fonte de Verdade)

Referências primárias:

• docs/vision/vision-001-ebdbe-plataforma-ebd.md
• docs/architecture/adrs/adr-0000-fundacao-do-projeto.md

Objetivos executivos vigentes:

• Entregar uma plataforma digital para gestão da Escola Bíblica Dominical com foco mobile-first.
• Operar em estrutura multi-igreja com isolamento por ministério e unidade organizacional.
• Garantir controle de acesso por papéis e escopo hierárquico, com backend como autoridade de negócio.
• Permitir registro de ocorrências da EBD (sessões, classes, lições e materiais) com evolução incremental.
• Aplicar privacidade por padrão, minimização de dados e governança arquitetural formal.
• Manter separação clara entre domínio, aplicação, infraestrutura e apresentação.
• Evoluir por decisões registradas (ADRs), evitando mudanças estruturais não formalizadas.

3) Matriz de Status Funcional por PRD

Feature (PRD)	Status documental	Evidência em código	Lacuna principal
PRD-0001 Perfil do usuário	Implementado	frontend/lib/presentation/modules/profile_dialog/ + backend myProfileHttp	Consolidar cobertura de testes de fluxos críticos de perfil
PRD-0002 Página inicial	Proposta (aguardando aprovação)	Home com abas Início/Ações/Mensagens em frontend/lib/presentation/pages/home/; listener de mensagens ativo	Formalização pendente no ciclo de aprovação do PRD; conflito de merge no arquivo da Home
PRD-0003 Relatório de EBD (preencher)	Proposta (aguardando aprovação)	EbdReportPage com modos sessionSetup e classFill; ações “Criar sessão” e “Preencher classe”	Aprovação documental pendente + validações de workflow no backend precisam ampliar cobertura automatizada
PRD-0004 Relatório de EBDs (listar)	Implementado	frontend/lib/presentation/modules/ebd_sessions_report/ebd_sessions_report_page.dart	Reforçar testes automatizados de filtros e navegação
PRD-0005 Relatório de classes (listar)	Implementado	frontend/lib/presentation/modules/classes_report/classes_report_page.dart	Reforçar testes automatizados de listagem e abertura de relatório

Leitura consolidada:

• Implementado com evidência documental+técnica: PRD-0001, PRD-0004, PRD-0005.
• Parcial/proposto com evidência técnica já existente: PRD-0002, PRD-0003.

4) Status Técnico-Operacional

Capacidades backend disponíveis (backend/functions/src/index.ts):

• healthcheck
• userGatewayHttp
• myProfileHttp
• registerPendingAccount
• emailSignupStartHttp
• emailSignupResendHttp
• emailSignupVerifyHttp
• publicChurchesHttp
• platformDebugHttp
• platformDebugApplyHttp
• platformDebugFirestoreHttp
• docsGateway

Capacidades de suporte/migração (backend/functions/src/scripts/):

• Migrações e reconciliação de dados (migrate-*, reconcile-*)
• Seeds de controle de acesso e workflow (seed-*)
• Ferramentas operacionais (db-cli, list-messages, test-access-control)

Maturidade de qualidade:

• Frontend: possui testes em frontend/test/ (inclui teste de adapter de domínio e widget básico).
• Backend: script de test em package.json está como "No tests configured yet"; não há suíte formal de testes automatizados de unidade/integração.
• Pipeline de backend inclui lint e build no predeploy.

Riscos e dívidas priorizados:

• Alto: marcador de conflito de merge (<<<<<<<, =======, >>>>>>>) em frontend/lib/presentation/pages/home/home_page.dart.
• Médio: ambiente local com git bloqueado por safe.directory (impede leitura confiável de branch/diff no fluxo atual).
• Médio: indisponibilidade de rg no ambiente atual (fallback para PowerShell reduz produtividade e observabilidade).
• Médio: divergência entre status documental (“Proposta”) e status técnico (funcionalidade parcialmente pronta) em PRD-0002/0003.

5) Backlog Recomendado (Curto Prazo)

Prioridade orientada por impacto/risco.

1. P1 — Resolver conflito de merge em home_page.dart e validar execução da Home.
2. P1 — Formalizar aprovação/revisão de PRD-0002 e PRD-0003 para alinhar documento x implementação.
3. P1 — Criar suíte mínima de testes backend para myProfileHttp e userGatewayHttp.
4. P1 — Cobrir fluxo de relatório EBD (criar sessão + preencher classe) com testes de integração.
5. P2 — Cobrir PRD-0004 e PRD-0005 com testes de UI/integração (filtro, listagem, navegação).
6. P2 — Definir e aplicar critério de “Definition of Done” documental+técnico por PRD.
7. P2 — Padronizar checklist de release para scripts de migração/seed com validação dry-run.
8. P2 — Sanear ambiente de desenvolvimento (git safe.directory e rg) para diagnóstico contínuo.
9. P3 — Publicar painel simples de rastreio PRD x ADR x código (matriz viva).
10. P3 — Revisar e priorizar roadmap de chat/grupos (aba Mensagens) com recorte incremental.

6) Rotina Semanal de Atualização de Status

Cadência:

• Toda semana, segunda-feira, 09:00 (horário local do time).

Responsáveis:

• Dono de Produto: status documental (Vision/BRD/PRD).
• Líder Técnico Frontend: status de implementação e testes no app.
• Líder Técnico Backend: status de APIs, scripts e qualidade.
• Arquiteto/Tech Lead: coerência ADR/TDD e priorização de riscos.

Checklist fixo semanal:

• Revalidar status de cada PRD com evidência em código.
• Conferir riscos abertos e atualizar severidade/mitigação.
• Atualizar backlog priorizado com no máximo 10 itens ativos.
• Confirmar cobertura de testes adicionada/pendente na semana.
• Registrar bloqueios de ambiente e ação de resolução.

Critério de transição de status:

• Proposto -> Parcial: existe implementação funcional em código, ainda sem validação completa documental+técnica.
• Parcial -> Implementado: PRD aprovado, implementação entregue, validação manual concluída e testes mínimos presentes.
• Implementado -> Parcial: regressão funcional, conflito de merge, ou perda de evidência mínima.

Evidência mínima obrigatória por item:

• Documento: PRD/ADR/TDD atualizado ou explicitamente referenciado.
• Código: caminho de implementação identificado e revisável.
• Validação: teste automatizado relevante ou checklist manual registrado.

7) Cenários de Validação do Diagnóstico

• Consistência documental: cada objetivo aponta para fonte explícita (Vision/ADR/PRD).
• Cobertura funcional: todos os PRDs existentes aparecem na matriz.
• Rastreabilidade: itens “Implementado” possuem evidência objetiva em código.
• Acurácia operacional: bloqueios de ambiente e limitações de observabilidade estão registrados com mitigação.
• Utilidade prática: backlog permite iniciar execução sem decisões pendentes.