EspecificaçãoCore 1.0 · estável

Protocolo de Versionamento Pedagógico - Core 1.0

Apresentação navegável baseada no Core 1.0. A fonte normativa completa permanece no repositório público.

Versão 1.0.0Data 2026-03-04Autor Leidison Lima dos SantosLicença CC BY 4.0Idioma PT · EN informativo

Status do texto. Esta página apresenta uma leitura navegável baseada no Core 1.0 e não substitui a fonte normativa completa, fixada na tag v1.0.0 do repositório público. Em caso de qualquer divergência, prevalece a fonte no repositório.

Limites atuais. E0-E3 não demonstra eficácia, aprendizagem ou qualidade. A referência de 90 segundos é uma estimativa de desenho, não uma medida. As formulações históricas reproduzidas abaixo não foram reescritas retroativamente.

O PVP (Protocolo de Versionamento Pedagógico) é um protocolo aberto para registrar, versionar e acumular melhorias em planos de aula a partir de evidências observadas em sala.

1Definição

O PVP é um conjunto mínimo de regras para registro, versionamento e acúmulo de melhorias em planos de aula. Inspira-se nos princípios do controle de versão de software (Git), transpondo-os para a realidade do planejamento pedagógico.

O PVP é protocolo - não metodologia, framework ou sistema. Um professor que segue as 5 regras está usando o PVP. Um professor que não segue, não está.

2Justificativa

O professor brasileiro trabalha em média 9,3 horas semanais em planejamento (OECD TALIS, 2024), atende múltiplas turmas e opera em contexto de alta rotatividade. Melhorias identificadas após cada aula são voláteis: existem na mente do professor por segundos e se perdem sem registro. O conhecimento pedagógico prático (PCK - Shulman, 1986) permanece tácito e desaparece com a mudança de escola, turma ou ano letivo.

O PVP propõe infraestrutura mínima para que esse conhecimento seja registrado, acumulado e rastreável.

3As cinco regras

Regra 1 - Versão explícita

Todo plano de aula sob o PVP carrega número de versão no formato X.Y.Z ou X.Y.

Regra 2 - Mudança registrada

Toda melhoria é documentada em um Registro de Melhoria (RM) contendo obrigatoriamente três campos: (a) o que mudou, (b) por que mudou, (c) o sinal de sala que motivou a mudança.

Regra 3 - Contexto declarado

O plano declara seu contexto de aplicação: série/ano, tempo de aula, recursos disponíveis e perfil da turma.

Regra 4 - Evidência mínima

Cada RM requer pelo menos um sinal de sala observado - evidência empírica coletada durante ou após a aplicação da aula.

Regra 5 - Proveniência preservada

O histórico de versões e a autoria permanecem rastreáveis ao longo do tempo. Nenhuma versão anterior é apagada; são substituídas por versões novas.

4Entidades

4.1 PAV - Plano de Aula Versionado

Qualquer plano de aula que passa a carregar número de versão e histórico de mudanças. O formato é agnóstico: pode ser caderno, documento digital, planilha, slide ou qualquer suporte. O PAV é o artefato do protocolo.

Campos mínimos: identificação (disciplina, tema, série, autor); versão atual (X.Y.Z ou X.Y); contexto (Regra 3); conteúdo do plano (formato livre); histórico de versões.

4.2 RM - Registro de Melhoria

A unidade atômica de mudança do protocolo. Cada RM documenta uma melhoria específica, com tempo estimado de preenchimento de 90 segundos.

Campos obrigatórios: o que mudou (descrição concreta); por que mudou (justificativa conectada à prática); sinal de sala (evidência observacional que motivou a mudança). Opcionais: data, tipo de mudança (X, Y ou Z), resultado observado.

4.3 VC - Variação Contextual

Adaptação de um PAV para contexto diferente do original, mantendo conexão rastreável com o plano base. A VC resolve o problema de professores que atuam em múltiplos contextos (regular/EJA, matutino/noturno, presencial/remoto, regular/PEI).

Identifica o PAV base de origem, declara o contexto específico da variação, mantém histórico próprio de versões, e melhorias universais podem ser reintegradas ao PAV base. Nomenclatura sugerida: VC-[contexto] (ex.: VC-EJA, VC-PEI, VC-Noturno).

5Versionamento semântico pedagógico

Baseado no Semantic Versioning (Preston-Werner, 2013), adaptado:

PosiçãoNomeIncrementa quando…Exemplo
XMajorReestruturação significativa: mudança de abordagem, público-alvo, redesenho da sequência1.3.0 → 2.0.0
YMinorAjuste dentro da mesma estrutura: troca de atividade, adição de exemplo, redistribuição de tempo1.2.0 → 1.3.0
ZPatchMicro-correção: link quebrado, clareza de instrução, correção de enunciado1.3.0 → 1.3.1

Quando X incrementa, Y e Z voltam a zero; quando Y incrementa, Z volta a zero. O formato simplificado X.Y é aceito (Z implícito = 0). A versão inicial é 1.0.0 (ou 1.0).

6Escala de evidência

Escala de maturidade do plano baseada no nível de validação empírica:

NívelNomeCritério
E0RascunhoPlano nunca aplicado em sala - planejamento teórico
E1Aplicado 1×Aplicado pelo menos uma vez com observação do professor
E2Aplicado 2+×Aplicado duas ou mais vezes com checagem de aprendizagem
E3MulticontextoAplicado em contextos diferentes com Variação Contextual documentada

A evidência é indicada após a versão. Exemplo: v3.2.1 - E3.

7Camadas de implementação

O protocolo é implementável em quatro camadas progressivas. Cada camada funciona de forma autônoma.

CamadaNomeDescriçãoRequisitos
1EssencialProfessor preenche RM com 3 campos em 90s após a aulaCaneta e caderno
2EstruturadoUso do Canvas PVP, organização em planilha, histórico formalCanvas impresso ou planilha
3ColaborativoCompartilhamento institucional, contribuições entre pares, curadoriaRepositório compartilhado, coordenação
4PlataformaSistema digital com automações, busca, integração BNCC, análise de dadosPlataforma web/app

8Sinal de sala

Conceito central do PVP. Sinal de sala é qualquer evidência observacional que o professor coleta durante ou após a aula e que motiva uma melhoria. Não exige instrumento formal, pesquisa padronizada ou análise estatística.

Exemplos válidos:

  • “70% dos alunos erraram a questão 3 no exercício de fixação.”
  • “A turma dispersou após 20 minutos de exposição.”
  • “Os alunos do fundo se engajaram quando troquei o exemplo abstrato por concreto.”
  • “Nenhum aluno conseguiu iniciar a atividade sem pedir ajuda.”
O sinal de sala torna o PVP um sistema puxado: a melhoria é puxada pela realidade observada, não empurrada por teoria, plataforma ou diretriz externa.

9Transposição Git → PVP

GitPVPFunçãoDivergência
RepositoryPAVArtefato versionadoPAV é agnóstico de formato
CommitRMRegistro atômico de mudançaRM exige sinal de sala
BranchVCVariação para outro contextoVC tem motivação pedagógica/legal
Semantic VersioningVersionamento PedagógicoConvenção X.Y.ZCategorias adaptadas
Pull RequestContribuição (SC)Proposta de melhoriaCuradoria humana obrigatória
MergeIntegraçãoIncorporação de contribuiçãoSem merge automático
ChangelogHistórico de versõesRegistro cronológico-
Automated testsSinais de salaValidaçãoEscala qualitativa E0-E3

10Referências

  1. SHULMAN, L. S. Those who understand: knowledge growth in teaching. Educational Researcher, v. 15, n. 2, p. 4-14, 1986.
  2. SHULMAN, L. S. Knowledge and teaching: foundations of the new reform. Harvard Educational Review, v. 57, n. 1, p. 1-22, 1987.
  3. NONAKA, I.; TAKEUCHI, H. The Knowledge-Creating Company. Oxford University Press, 1995.
  4. OHNO, T. Toyota Production System. Productivity Press, 1988.
  5. PRESTON-WERNER, T. Semantic Versioning 2.0.0. 2013. semver.org.
  6. LEWIS, C. Lesson Study: A Handbook of Teacher-Led Instructional Change. RBS, 2002.
  7. OECD. TALIS 2024 Results. OECD Publishing, 2024.
  8. McNIFF, J. Action Research: Principles and Practice. 3ª ed. Routledge, 2013.

PVP Core 1.0 · Leidison Lima dos Santos · CC BY 4.0 · 2026 · DOI 10.5281/zenodo.18874305