Validar a pasta `.case/`

O validador estrutural é o conjunto de regras por que toda árvore .case/ precisa passar antes de ser publicada. Ele lê um checkout local e nada mais.

Você raramente o roda à mão. O /fito-case-generate o usa como ciclo de editar e conferir, e o /fito-publish-case o roda de novo antes de qualquer coisa ser enviada. Esta página serve para ler a saída dele e para reconferir uma árvore à mão.

Antes de começar

• Um diretório de trabalho com .case/ dentro. Veja Gerar a pasta .case/.

Rodar à mão

node <fito-case-author skill dir>/validate.js <case-working-dir>

Troque <fito-case-author skill dir> pelo caminho da skill fito-case-author do Fito, e <case-working-dir> pelo diretório que contém .case/. Dentro de uma sessão do pi você pode pedir a skill pelo nome e ela resolve o caminho para você.

Ele imprime JSON na saída padrão e define um código de saída: 0 quando passa, 1 quando falha, 2 num problema de uso, como um diretório ausente ou inexistente.

Ler uma falha

{
  "ok": false,
  "errors": [
    {
      "file": "rubric.yaml",
      "message": "rubric criterion weights must sum to exactly 100 (got 90)",
      "path": ["criteria"]
    }
  ]
}

Todas as violações são relatadas de uma vez — ele nunca para na primeira. Cada erro é escopado ao arquivo .case/ que o produziu, e em geral a um path de campo dentro dele.

Cuidado

Leia o path junto com o message. Sozinha, uma mensagem pode dizer Invalid input: expected string, received undefined, que não nomeia campo nenhum. É o path que diz onde.

Corrija os arquivos nomeados e rode de novo. Não regere a árvore por um erro que dá para corrigir.

Ler uma passagem

{
  "ok": true,
  "attestation": { "pass": true, "validatorVersion": "0.1.8", "rulesetVersion": "1.8.0" },
  "references": [{ "componentId": "concept:javalin.handler", "bloomLevel": "APPLICATION" }],
  "optionalFieldsNotUsed": { "manifest.yaml": ["created_at", "updated_at"] }
}

• attestation — o carimbo que uma publicação leva ao servidor do Fito. Ele nomeia a build do validador e a versão do conjunto de regras contra a qual a árvore foi conferida.
• references — o conjunto de referências do caso: cada componente e nível de Bloom, sem repetição, reunidos dos objetivos de aprendizagem, dos pré-requisitos, da rubrica e do quiz. É esse conjunto que o servidor resolve na publicação, e é ele que congela depois.
• optionalFieldsNotUsed — os campos opcionais que este caso deixa vazios, agrupados por arquivo. Nada aqui é um erro.

Nota

Nada é salvo. O atestado que o servidor recebe precisa descrever a árvore como ela está naquele momento, então cada fluxo de publicação roda a validação de novo em vez de confiar num arquivo de uma execução anterior.

O que o conjunto de regras cobra

Regra	O que significa
Arquivos obrigatórios	Os quatorze existem, mais task/steps.md num tutorial
Formato dos arquivos	Todo campo tem o tipo e os valores permitidos que o arquivo dele declara
Formato da referência	Toda referência é <type>:<technology-slug>.<component-slug>
Níveis de Bloom	Só KNOWLEDGE, COMPREHENSION e APPLICATION
Pesos da rubrica	Inteiros positivos somando exatamente 100
Níveis da rubrica	Todo critério cobre as pontuações 0, 1, 2 e 3
Um objetivo primário	Pelo menos um objetivo de aprendizagem tem weight: primary
Cobertura dos objetivos	Todo objetivo de aprendizagem é pontuado por pelo menos um critério de rubrica. Uma pergunta do quiz não conta
Nível dos objetivos	Pelo menos um desses critérios declara o nível de Bloom do objetivo ou um mais alto, porque um critério não registra mais do que o nível que declara
Documentos de situação	Todo arquivo listado em situation/situation.yaml existe em disco
Motivo da descontinuação	Um caso deprecated dá um deprecated_reason
Tipo do caso	O artefato que o tipo exige existe — veja Os três tipos
Formato do quiz	Uma pergunta multiple_choice tem choices e uma answer que bate com uma delas; os outros dois tipos têm evaluation

O que ele não confere

Duas coisas sobre as quais uma passagem não diz nada. As duas são resolvidas pelo servidor do Fito quando você publica:

• Se os componentes referenciados existem. O formato é conferido aqui; a existência não.
• Se os seus refs no git são alcançáveis. O servidor testa a tag da versão e o ramo da solução por conta própria.

Ele também não consegue conferir a regra do tema e da jogada. Um caso que entrega a própria resposta passa limpo. Essa é sustentada pelos comandos de criação e pela sua revisão.

Versões

O atestado carrega dois números, e eles se movem de forma independente:

• validatorVersion é a build do conferidor.
• rulesetVersion é a versão das regras em si.

Um caso publicado é carimbado com o par contra o qual foi conferido.

O que vem a seguir

• Gerar a pasta .case/ — onde vive o ciclo de editar e conferir.
• Publicar um caso — onde o servidor assume o que esta execução não podia decidir.