Pular para conteúdo

Plano de Adequação e Adaptação do Núcleo Curricular do SIGESC

Status: proposta arquitetural aprovada conceitualmente pelo proprietário do produto em 07/09/2026.

Escopo: currículo estruturado, Plano de Ensino Bimestral, registro docente, Cobertura Curricular e preparação da futura camada de Avaliação e Evidências de Aprendizagem.

Não é escopo desta primeira etapa: geração automática de provas, correção por imagem/PDF, atribuição automática de domínio de habilidades ou intervenção pedagógica automatizada. O modelo deve, porém, nascer compatível com essas capacidades futuras.

1. Objetivo

Transformar o núcleo curricular atual do SIGESC em uma cadeia canônica, versionada, multi-tenant e auditável que diferencie claramente:

Fonte curricular oficial → currículo estruturado → Plano de Ensino Bimestral → registro docente → cobertura curricular → avaliação → evidência de aprendizagem → intervenção.

A mudança deve preservar os lançamentos existentes, não reativar learning_objects como fonte de novas escritas e não inferir artificialmente habilidades ou objetos de conhecimento em dados históricos.

2. Decisões canônicas já aprovadas

2.1 Fontes curriculares possíveis

Cada mantenedora poderá ter um conjunto de fontes oficiais aplicáveis ao seu currículo, entre elas:

  • BNCC;
  • Complemento à BNCC da Computação, em âmbito nacional;
  • Documento Curricular Municipal — DCM;
  • referenciais municipais específicos, como o Referencial Curricular Municipal de Computação e Educação Digital de Floresta do Araguaia.

Nem toda fonte precisa ser aplicada a todo componente. O SIGESC deve registrar quais fontes são aplicáveis a cada domínio/componente e preservar sua proveniência.

2.2 Autoridade curricular

A mantenedora é a autoridade curricular institucional no SIGESC.

A escola e o professor podem contextualizar, executar e registrar práticas e conteúdos reais, mas não podem alterar silenciosamente uma habilidade canônica nem transformar uma digitação livre em item oficial do currículo da rede.

2.3 Plano de Ensino Bimestral

O produto derivado das fontes curriculares será denominado Plano de Ensino Bimestral.

Ele será estruturado por, no mínimo:

mantenedora + ano letivo + etapa/modalidade + ano/série/faixa + componente curricular + bimestre/período.

O Plano de Ensino Bimestral é o elo entre as fontes oficiais e o trabalho do professor.

2.4 Registro docente

O registro da aula deve separar explicitamente:

  • Habilidade(s) curricular(es);
  • Objeto(s) de Conhecimento;
  • Conteúdo/atividade efetivamente realizada;
  • Prática(s)/estratégia(s) pedagógica(s);
  • Observações.

Habilidades, objetos e práticas devem suportar múltiplas seleções quando pedagogicamente necessário.

2.5 Regra de migração do campo histórico Conteúdo/Objeto de Conhecimento

Decisão obrigatória: todo valor já gravado no campo histórico Conteúdo/Objeto de Conhecimento migra integralmente para o novo conceito Conteúdo.

Não deve haver tentativa automática de separar o texto histórico entre “Conteúdo” e “Objeto de Conhecimento”.

Portanto:

conteúdo/objeto legado → conteúdo novo, texto preservado integralmente.

O campo estruturado Objeto de Conhecimento será preenchido apenas quando houver vínculo curricular confiável, registro novo ou adjudicação humana explícita.

Isso evita perda de informação e falsas classificações retrospectivas.

2.6 Opção NOVO

Para Objeto de Conhecimento, o professor poderá escolher NOVO — Objeto não previsto no plano e digitar livremente. Esse registro pertence à aula e não altera o Plano de Ensino Bimestral oficial.

Para Prática Pedagógica, o professor poderá selecionar sugestões ou NOVO/Outra prática, com digitação livre. A prática é campo de forte autonomia docente e não requer aprovação curricular para existir no registro da aula.

Para Habilidade, não haverá criação livre equivalente a NOVO. Se a habilidade necessária não existir, o professor deverá solicitar inclusão/regularização; uma nova habilidade local deve ser criada por perfil curricular autorizado da mantenedora, com código local, descrição, origem, vigência e aprovação.

3. Estado atual que precisa ser respeitado

No código atual do SIGESC, content_entries é a fonte canônica para novas escritas de conteúdo pedagógico. learning_objects permanece legado/read-only por bridges de histórico e não deve voltar a ser fonte de novas gravações.

O contrato atual de content_entries possui, entre outros, os campos content, methodology e observations. O campo content corresponde hoje à semântica histórica de Conteúdo/Objeto de Conhecimento, enquanto methodology é exibido como Práticas Pedagógicas.

A interface LearningObjects.js ainda mantém adaptation_ids no estado do formulário e usa SkillPicker, mas o blueprint de cutover do conteúdo registra que adaptation_ids, skill_codigos e resources foram deliberadamente deixados fora do contrato canônico de content_entries na migração anterior.

A adequação curricular deve, portanto, reconectar habilidades ao fluxo canônico sem reintroduzir dupla SSoT.

4. Modelo de domínio alvo

4.1 Fontes documentais curriculares

Entidade conceitual: curriculum_sources.

Responsabilidades:

  • identificar documento e origem;
  • mantenedora proprietária quando local;
  • âmbito: nacional, estadual, municipal ou institucional;
  • tipo: BNCC, BNCC_COMPUTACAO, DCM, REFERENCIAL_MUNICIPAL etc.;
  • versão/data/vigência;
  • URL ou referência documental;
  • hash de integridade quando disponível;
  • status: rascunho, em revisão, aprovado, arquivado;
  • proveniência.

4.2 Versões curriculares

Entidade conceitual: curriculum_versions.

Deve impedir que uma alteração feita em 2027 modifique retrospectivamente o que era considerado currículo vigente em 2026.

Escopo mínimo:

  • mantenedora_id;
  • academic_year ou intervalo de vigência;
  • versão;
  • status;
  • fontes documentais utilizadas;
  • aprovação e auditoria.

4.3 Habilidades canônicas

A base nacional deve permanecer canônica e imutável para a mantenedora.

Habilidades municipais/localmente definidas devem existir em camada distinta, com origem e código local. Habilidades de faixa, como EF15COxx e EF69COxx, não podem ser forçadas a um único ano.

4.4 Itens curriculares municipais

Entidade conceitual: curriculum_items.

Um item deve poder relacionar:

  • versão curricular;
  • componente;
  • etapa/modalidade;
  • ano/série/faixa;
  • bimestre/período;
  • eixo/unidade temática;
  • objeto do conhecimento;
  • objetivo de aprendizagem;
  • habilidade canônica ou habilidade local;
  • descrição/localização documental;
  • sugestões metodológicas;
  • ordem/progressão;
  • página/trecho de origem.

4.5 Plano de Ensino Bimestral

Entidade conceitual: teaching_plans + teaching_plan_items.

O Plano de Ensino Bimestral não deve ser uma cópia textual solta. Deve apontar para os itens da versão curricular vigente e permitir organização por período.

Estados sugeridos:

rascunho → em revisão → publicado → encerrado/arquivado.

A publicação congela uma revisão identificável. Alterações posteriores devem gerar nova versão/revisão, nunca edição histórica invisível.

4.6 Registro canônico da aula

content_entries permanece SSoT do que efetivamente foi trabalhado.

O contrato deve evoluir de forma compatível para representar:

  • content: texto livre do conteúdo/atividade efetivamente realizada;
  • skill_refs[]: referências estruturadas às habilidades usadas no registro;
  • knowledge_object_refs[]: objetos previstos selecionados;
  • knowledge_object_custom[]: objetos livres marcados como não previstos;
  • pedagogical_practice_refs[]: práticas sugeridas/normalizadas selecionadas;
  • pedagogical_practice_custom[]: práticas livres;
  • teaching_plan_id e/ou teaching_plan_revision_id;
  • teaching_plan_item_ids[] quando aplicável;
  • snapshots de código/descrição necessários para auditabilidade histórica;
  • flags de desvio do plano, sem impedir o registro docente.

Os nomes finais dos campos devem ser definidos em ADR antes do código. O princípio é mais importante que o nome provisório.

5. UX alvo do professor

Ao abrir a aula, o SIGESC já conhece turma, componente, data, ano letivo e bimestre. A partir desse contexto, deve carregar o Plano de Ensino Bimestral vigente.

Passo 1 — Habilidade(s) BNCC / DCM

O professor pesquisa por código ou texto. O autocomplete prioriza habilidades previstas para aquele plano, exibindo código, descrição, origem e contexto.

É permitido selecionar mais de uma habilidade.

Se nenhuma habilidade for localizada, a interface oferece Solicitar inclusão/regularização, não criação curricular livre.

Passo 2 — Objeto(s) de Conhecimento

Após a seleção da habilidade, o SIGESC apresenta os objetos associados à habilidade dentro do Plano de Ensino Bimestral vigente.

Opções:

  • selecionar um ou mais objetos previstos;
  • escolher NOVO — Objeto não previsto no planejamento e digitar livremente.

Objeto livre permanece vinculado somente ao registro da aula, salvo processo posterior de homologação curricular.

Passo 3 — Conteúdo

Campo livre obrigatório para registrar o que foi efetivamente trabalhado.

Esse campo receberá, sem alteração de conteúdo, os valores históricos que hoje estão em content sob o rótulo combinado Conteúdo/Objeto de Conhecimento.

Passo 4 — Práticas Pedagógicas

O SIGESC apresenta sugestões relacionadas ao plano/habilidade/objeto quando existirem.

O professor pode:

  • selecionar uma ou várias sugestões;
  • optar por NOVO/Outra prática e digitar livremente;
  • combinar sugestão estruturada com prática própria.

Sugestão metodológica não é obrigação metodológica.

Passo 5 — Observações

Campo livre preservado.

6. Política de permissões

A implementação deve abandonar regras implícitas baseadas apenas no fato de o usuário conseguir abrir uma página.

Separar permissões funcionais, no mínimo, em:

Capacidade Política recomendada
consultar fontes/referencial perfis pedagógicos e de gestão autorizados
consultar Plano de Ensino professor da atribuição + gestão pedagógica autorizada
criar/editar versão curricular perfil curricular da mantenedora
publicar Plano de Ensino autoridade curricular da mantenedora
registrar aula professor/vínculo pedagógico e exceções administrativas já governadas
registrar Objeto NOVO permitido no registro docente, sem alterar plano
registrar Prática NOVA permitido no registro docente
criar Habilidade local somente autoridade curricular autorizada
homologar sugestão escolar/docente no currículo mantenedora

A matriz final deve ser integrada ao RBAC e à Matriz de Permissões existentes, sempre fail-closed e isolada por mantenedora.

7. Estratégia de migração e compatibilidade

7.1 Princípio central

A migração deve ser aditiva e reversível na fase de rollout, sem apagar ou reinterpretar dados históricos.

7.2 content_entries.content

O texto existente é preservado integralmente e passa a ser apresentado com o rótulo Conteúdo.

Não será feito parser semântico para descobrir automaticamente qual parte era Objeto de Conhecimento.

7.3 methodology

O texto histórico deve ser preservado. Não se deve converter automaticamente um texto livre em uma prática pedagógica normalizada sem correspondência inequívoca.

Estratégia recomendada:

  • manter o valor histórico legível;
  • marcá-lo como prática histórica não estruturada quando não houver vínculo confiável;
  • novos registros passam a usar refs estruturadas + campo livre quando necessário;
  • projeções/PDFs continuam exibindo o histórico de modo compatível.

7.4 Habilidades históricas

Não inferir habilidades a partir do texto de conteúdo.

Se houver adaptation_ids confiáveis no legado learning_objects, eles podem ser estudados em preflight específico, mas nenhuma cópia deve ocorrer automaticamente apenas porque o campo existe.

Qualquer backfill deve possuir relatório de correspondência, taxa de confiança, dry-run e adjudicação para casos ambíguos.

7.5 Histórico sem estrutura curricular

Registros antigos sem habilidades/objetos estruturados permanecem válidos como conteúdo histórico não estruturado.

Eles não podem ser contados falsamente como “cobertos” nem como “não ensinados” numa métrica curricular que exige vínculo estruturado.

8. Cobertura Curricular — regra futura

A Cobertura deverá ser reconstruída sobre a SSoT canônica, nunca voltar a depender de novas escritas em learning_objects.

Denominador:

versão curricular vigente + Plano de Ensino publicado + escopo mantenedora/escola/turma/ano-série/componente/período.

Numerador:

habilidades/itens curriculares estruturados efetivamente vinculados a content_entries válidos.

A cobertura deve distinguir:

  • previsto e trabalhado;
  • previsto e ainda não registrado;
  • realizado fora do plano;
  • histórico não estruturado;
  • período futuro/não iniciado;
  • plano inexistente ou não publicado.

Nenhuma dessas categorias equivale a aprendizagem do estudante.

9. Preparação para Avaliação e Evidências de Aprendizagem

A modelagem desta adequação deve permitir futuramente:

Plano → habilidade → objeto → conteúdo ministrado → item de avaliação → resposta do estudante → evidência → domínio/avanço/necessidade.

Cada questão futura poderá apontar para uma ou mais habilidades e guardar gabarito, pontuação, fonte, revisão humana e versão.

A correção automática por imagem/PDF e a geração supervisionada de avaliações serão subsistemas posteriores. Não devem contaminar a primeira migração com lógica prematura, mas os identificadores curriculares precisam ser estáveis desde agora.

10. Fases de execução

F0 — Preflight e inventário read-only

Objetivo: provar o estado real antes de alterar modelo ou dados.

Entregas:

  • contagem e schema real de content_entries e learning_objects por mantenedora/ano;
  • inventário de content, methodology, adaptation_ids, skill_codigos e campos correlatos;
  • cobertura de PDFs/relatórios que exibem o rótulo combinado;
  • mapa de endpoints e páginas afetadas;
  • inventário de permissões atuais;
  • diagnóstico da Cobertura Curricular atual;
  • relatório de risco multi-tenant;
  • zero escrita em banco.

Gate: nenhuma fase seguinte começa sem relatório do preflight.

F1 — ADR e contrato canônico

Objetivo: congelar conceitos antes de programar.

Decidir formalmente:

  • nomenclatura de entidades e campos;
  • SSoT de fontes, versões, planos e registros;
  • política de permissões;
  • política de versionamento;
  • representação de habilidades por ano e por faixa;
  • semântica de NOVO;
  • compatibilidade de APIs e PDFs;
  • regras de auditoria e tenant scope.

Gate: ADR aprovado antes de schema/runtime.

F2 — Fontes e versões curriculares

Objetivo: criar infraestrutura para documentos curriculares e vigência.

Entregas:

  • modelos/coleções e índices;
  • tenant isolation;
  • importação/registro de fontes;
  • versão curricular;
  • proveniência documental;
  • validação de habilidades canônicas/localmente definidas;
  • UI administrativa somente após contratos estabilizados.

F3 — Plano de Ensino Bimestral

Objetivo: representar o que a mantenedora prevê para cada recorte curricular.

Entregas:

  • plano por ano letivo, etapa, ano/série/faixa, componente e bimestre;
  • itens vinculados à versão curricular;
  • estados de revisão/publicação;
  • histórico de revisões;
  • leitura pelo professor;
  • publicação controlada pela mantenedora.

F4 — Contrato aditivo de content_entries

Objetivo: preparar o registro docente sem quebrar histórico.

Entregas:

  • novos campos estruturados opcionais;
  • snapshots e referências estáveis;
  • compatibilidade com registros antigos;
  • optimistic locking e fluxo de correção preservados;
  • auditoria ampliada;
  • bridges históricos mantidos read-only.

Gate: nenhum backfill destrutivo; nenhuma nova escrita em learning_objects.

F5 — Nova UX do Registro Docente

Objetivo: implementar o fluxo aprovado.

Fluxo:

Habilidade(s) → Objeto(s) relacionado(s) / NOVO → Conteúdo → Práticas sugeridas / NOVO → Observações.

Entregas adicionais:

  • multisseleção;
  • busca por código e texto;
  • indicação visual de origem curricular;
  • indicação de “fora do plano” sem bloquear autonomia docente;
  • preservação de rascunhos e compatibilidade offline onde aplicável;
  • PDFs e revisão de conteúdo adaptados aos novos campos.

F6 — Migração controlada do legado

Objetivo: adequar a leitura histórica sem inventar estrutura curricular.

Regra obrigatória:

content legado → content novo sem transformação textual.

A fase deve produzir:

  • dry-run por mantenedora;
  • contagens antes/depois;
  • hashes/amostras para comprovar preservação;
  • classificação de registros estruturados e não estruturados;
  • rollback/compensação;
  • relatório final de migração.

F7 — Cobertura Curricular v2

Objetivo: substituir a métrica atual por cálculo confiável.

Entregas:

  • isolamento completo por tenant;
  • filtro correto por turma, ano/série/faixa, componente e período;
  • denominador baseado em plano/versionamento;
  • numerador baseado em content_entries estruturados;
  • tratamento explícito de histórico não estruturado;
  • testes de invariantes matemáticos;
  • reconciliação com casos de referência conhecidos.

F8 — Preparação da camada de Aprendizagem

Objetivo: definir contratos, ainda sem automação completa.

Entregas:

  • avaliação/instrumento;
  • item/questão;
  • vínculo questão ↔ habilidade;
  • resposta/evidência individual;
  • separação entre nota e domínio de habilidade;
  • versionamento de gabarito;
  • fila de revisão humana futura.

A geração por IA e correção por imagem/PDF só devem entrar após esses contratos serem validados.

11. Estratégia de PRs e rollout

Cada fase deve ser dividida em PRs pequenos, auditáveis e reversíveis.

Sequência sugerida de implementação no repositório principal:

P0/F0 preflight → F1 ADR → F2 fontes/versões → F3 planos → F4 contrato aditivo → F5 UX → F6 migração → F7 cobertura v2 → F8 contratos de aprendizagem.

Não misturar em um único PR:

  • mudança de schema;
  • migração de dados;
  • mudança de cálculo de cobertura;
  • redesign amplo de frontend.

Cada mudança de dados deve possuir dry-run e evidência. Cada deploy deve usar o processo protegido de release do SIGESC.

12. Testes e gates obrigatórios

A suíte precisa provar, no mínimo:

  • isolamento multi-tenant em todas as novas coleções e endpoints;
  • impossibilidade de professor editar habilidade canônica;
  • professor consegue registrar Objeto NOVO sem alterar plano;
  • professor consegue registrar Prática NOVA;
  • múltiplas habilidades/objetos/práticas são preservadas;
  • conteúdo histórico permanece byte-a-byte/textualmente equivalente após a adequação;
  • ausência de tentativa automática de inferir Objeto de Conhecimento do content legado;
  • ausência de escrita nova em learning_objects;
  • optimistic locking e correção publicada continuam válidos;
  • PDFs/relatórios exibem Conteúdo separado de Objeto de Conhecimento nos registros novos;
  • registros antigos continuam legíveis;
  • cobertura v2 nunca mistura mantenedoras;
  • cobertura por turma usa apenas currículo/plano compatível com aquela série/faixa e componente;
  • bimestres futuros não aparecem como atraso;
  • plano inexistente não produz falso 0% de cobertura;
  • habilidade de faixa (EF15CO, EF69CO) não é forçada a um ano único;
  • EJA pode contextualizar referência sem inventar código BNCC-EJA inexistente.

13. Critérios de aceite do programa

A adequação será considerada concluída quando o SIGESC conseguir responder, de forma auditável e sem ambiguidade:

  1. Qual fonte oficial sustenta este item curricular?
  2. Qual versão curricular valia para esta mantenedora naquele ano?
  3. O que estava previsto no Plano de Ensino Bimestral desta turma/componente?
  4. Qual habilidade o professor selecionou?
  5. Qual Objeto de Conhecimento previsto foi utilizado, ou qual objeto livre foi registrado?
  6. Qual conteúdo/atividade foi efetivamente realizado?
  7. Qual prática pedagógica foi utilizada?
  8. O registro estava dentro ou fora do plano?
  9. Quanto do plano foi efetivamente trabalhado?
  10. Quais registros históricos permanecem não estruturados e, portanto, não podem ser usados como prova automática de cobertura?

A pergunta “o que o estudante aprendeu?” ficará deliberadamente fora da Cobertura Curricular e será respondida pela futura camada de Evidências de Aprendizagem.

14. Restrições de segurança e governança

  • Fail-closed por mantenedora.
  • Nenhuma enumeração cross-tenant.
  • Toda fonte local pertence explicitamente a uma mantenedora.
  • Toda versão publicada é imutável como fato histórico; correções criam nova revisão.
  • Nenhuma IA altera currículo oficial sem adjudicação humana.
  • Nenhuma migração sem preflight, dry-run, contagens e rollback.
  • Nenhuma habilidade canônica nacional é reescrita pela mantenedora.
  • Nenhuma digitação livre do professor vira automaticamente item oficial do currículo.
  • content_entries permanece a SSoT de novas escritas do conteúdo ministrado.
  • learning_objects permanece legado/read-only durante a transição.

15. Próximo passo recomendado

Executar F0 — Preflight read-only do Núcleo Curricular, sem alteração de dados ou comportamento de produção.

O preflight deve produzir o mapa exato do estado atual antes de abrir a ADR da F1. Só depois dessa evidência deve ser fechado o schema final e iniciado qualquer código de migração.