Pular para conteúdo

F0 — Preflight read-only do Núcleo Curricular

Objetivo

Registrar o estado técnico do núcleo curricular antes da evolução canônica aprovada em setembro de 2026. Esta fase é estritamente de leitura: não altera dados, não executa backfill e não modifica a SSoT de produção.

Estado confirmado no repositório principal

Fonte canônica de conteúdo ministrado

content_entries é a fonte oficial para novas escritas de conteúdo pedagógico. learning_objects permanece legado/read-only por meio dos bridges históricos. O contrato canônico atual contém content, methodology, observations, vínculo de turma/componente/data/aula, autoria/vínculo docente, versionamento otimista, publicação/correção e auditoria.

Decisão de migração aprovada:

  • o texto histórico hoje exibido como Conteúdo/Objeto de Conhecimento permanece integralmente em content;
  • a semântica de content passa a ser somente Conteúdo;
  • nenhum algoritmo tentará decompor o texto histórico para inferir Objeto de Conhecimento;
  • Objetos de Conhecimento, Habilidades e Práticas estruturadas serão campos aditivos para novos lançamentos e para eventual adjudicação humana posterior.

Divergência atual do currículo

O frontend possui SkillPicker e mantém adaptation_ids no estado do formulário de Objetos de Conhecimento, porém o contrato canônico ContentEntryCreate/ContentEntryUpdate não persiste adaptation_ids. A decisão anterior de cutover havia removido skill_codigos, adaptation_ids e outros campos do contrato canônico.

Consequência: a interface pode permitir selecionar habilidade, mas essa relação não é garantida na SSoT content_entries.

Cobertura Curricular atual

O endpoint /api/curriculum/coverage:

  • usa curriculum_adaptations ativas como denominador;
  • usa learning_objects.adaptation_ids como numerador;
  • pode filtrar o numerador por class_id e academic_year;
  • não usa content_entries como fonte do realizado;
  • não possui um Plano de Ensino Bimestral versionado como denominador;
  • não amarra de forma canônica a base prevista ao ano/série real da turma selecionada;
  • a consulta do numerador legado não constitui a SSoT atual.

Conclusão: o indicador atual não deve ser promovido a indicador institucional definitivo antes da Cobertura v2.

Modelo curricular atual

Existem, entre outras, as coleções:

  • bncc_skills;
  • curriculum_components;
  • curriculum_adaptations;
  • curriculum_adaptation_methods.

curriculum_adaptations mistura hoje responsabilidades que no modelo futuro devem ser separadas: vínculo com habilidade canônica, contextualização/localização municipal, ano, bimestre, objeto de conhecimento, fonte e ordem.

Permissões

A rota frontend de Adaptações Curriculares permite acesso a super_admin, coordenador e apoio_pedagogico. As mutações do backend usam a política de super_admin, apesar de comentário histórico mencionar coordenação. Isso produz divergência de expectativa entre consulta e gerenciamento.

A adequação adotará dois níveis:

  • consulta curricular: perfis pedagógicos autorizados e Matriz de Permissões;
  • gestão/publicação curricular: capacidade específica de gestão curricular da mantenedora, com defaults restritos e override pela Matriz.

Enquanto a capacidade granular não estiver operacional, a interface não deve oferecer mutações a quem o backend não autoriza.

Pontos de preservação obrigatória

  1. content_entries continua SSoT das novas escritas.
  2. learning_objects não volta a receber escrita.
  3. Nenhum registro histórico é reinterpretado automaticamente.
  4. content histórico não é apagado, dividido nem resumido.
  5. Cada nova relação curricular deve respeitar mantenedora_id e fail-closed multi-tenant.
  6. Currículo deve ser versionado por vigência; alterações futuras não podem reescrever a leitura de 2026.
  7. Habilidades nacionais permanecem canônicas; a mantenedora referencia/contextualiza, não reescreve silenciosamente a fonte nacional.
  8. Habilidade local nova exige governança curricular; não é texto livre do professor.
  9. Objeto de Conhecimento NOVO e Prática Pedagógica NOVA pertencem ao registro da aula e não alteram automaticamente o plano oficial.
  10. Planejado, trabalhado, avaliado e aprendido são estados distintos.

Limitação do preflight

Este preflight foi realizado sobre o código e os contratos versionados do SIGESC. A conexão GitHub utilizada nesta execução não fornece acesso direto ao MongoDB de produção; por isso, contagens de documentos reais por coleção não são inventadas neste relatório. Como o plano aprovado não depende de reescrita automática dos dados históricos, essa limitação não bloqueia as fases aditivas. Qualquer backfill futuro que use dados legados deverá ter dry-run próprio, métricas de produção e autorização operacional explícita no artefato de migração.

Gate de saída da F0

F0 é considerada concluída quando:

  • a SSoT atual está identificada;
  • a desconexão entre SkillPicker e content_entries está explicitada;
  • a Cobertura legada está classificada como transitória;
  • a política de preservação histórica está fixada;
  • nenhum dado foi modificado.