Ir para o conteúdo

Catálogo de Specs

Objetivo

Este catálogo lista as specs SDD/TDD criadas para o projeto e indica o status de cada uma.

Specs atuais

Spec Status Objetivo Relação
000-documentacao-do-projeto Implementada/Ativa Definir padrão de qualidade documental, SDD, TDD, AGENTS e skills. Issue #86
001-integracao-frontend-backend Implementada Definir integração entre frontend, backend, autenticação, submissão, listagem, detalhe e validação da demo da R1. Issues #93, #94, #95 e #96
002-requirements-r2 Implementada Definir requisitos, critérios de aceite, integração de IA e regras de negócio para a Release 2. Issues #106, #147
003-analysis-classifier Implementada Implementar o fluxo online de análise de qualidade legislativa via classificação multi-label com o LegalBERT-pt, cálculo do score, warnings e cache. Issue #86, #106
003-framework-testes Implementada Configurar centralmente o framework de testes automatizados do CrivoAI para backend (Pytest) e frontend (Jest/ESLint) e integração no CI. Issue #114
004-automatic-summary Implementada Implementar a geração automática de resumos curtos no backend via API do Gemini com fallback mockado. Issue #134
004-readability-score Implementada Implementar o cálculo do score de legibilidade (Flesch-Kincaid) adaptado para português no backend. Issue #132
004-resumo-ia-frontend Implementada Exibir o resumo explicativo por IA e tratar seus estados locais de carregamento e erro no frontend. Issue #155
005-user-profile Implementada Implementar tela de perfil do usuário (/profile) com edição e visualização de dados e tratamento de permissões. Issue #135, #147
005-warnings-sidebar Implementada Exibir os problemas (warnings) identificados pela IA em uma sidebar interativa na tela de detalhe da lei, permitindo scroll e destaque de trecho. Issue #137
006-ingestion-training-legalbert Implementada Executar o fluxo offline de preparação do dataset, fine-tuning do LegalBERT-pt, ingestão em lote e integração de catálogo. Issue #86
007-remove-mockdata-and-restrict-submission Implementada Remover dados mockados (simulados) do dashboard da página inicial, e restringir a submissão de leis a usuários autenticados. Issue #172, #177, #178

Ciclo de Vida de uma Spec

Status Significado
Draft A spec ainda está sendo escrita e pode conter ambiguidades.
Em revisão A spec já possui estrutura mínima e está pronta para revisão do time.
Ativa A spec foi aprovada e pode orientar implementação ou manutenção.
Implementada A funcionalidade ou processo descrito foi entregue e validado.
Obsoleta A spec foi substituída ou não representa mais a decisão atual do projeto.

Toda mudança de status deve ser feita por PR ou registrada em uma issue relacionada, para manter rastreabilidade.

Próximas specs planejadas

As especificações iniciais planejadas para a Release 2 foram consolidadas e implementadas nas especificações de 002 a 007 descritas no catálogo de specs atuais. Novas especificações para evoluções futuras da plataforma serão catalogadas aqui à medida que novas features forem planejadas pelo time.

Uma spec só deve entrar como ativa quando possuir:

  • spec.md;
  • plan.md;
  • test-plan.md;
  • tasks.md;
  • quickstart.md;
  • status claro;
  • issue relacionada.

Specs ligadas a issues, requisitos, arquitetura, sprint, release ou decisões do time devem ser versionadas no repositório.