Gerar a pasta `.case/`

Gerar transforma a proposta no contrato. O comando escreve a pasta .case/ num diretório de trabalho e roda o validador estrutural sobre ela até a árvore passar.

Dois limites valem do início ao fim. Ele escreve só dentro do diretório de trabalho — num projeto que você já tinha, .case/ é assunto dele e os seus arquivos de código não são — e não envia nada para lugar nenhum. Ele também não escreve o código inicial: isso é construído fora do Fito, guiado por Planejar o código do caso.

Antes de começar

Uma proposta de caso vinda de Desenhar um caso. Este passo começa desse arquivo, nunca do zero.
Uma sessão do pi num diretório de trabalho seu, com o Fito instalado nele.

Os três modos

O comando escolhe o modo pelo que encontra, e diz qual escolheu.

Modo	Quando	O que acontece
Greenfield	Ainda não há árvore de projeto	O diretório é criado e inicializado no git
Reuse	`--dir` nomeia um projeto existente	`.case/` é gerada dentro dele; o projeto mantém repositório e histórico
Re-validate	O diretório já tem `.case/`	Tudo é pulado, menos a validação

Re-validate é a viagem de volta. Você chega nele depois do trabalho de código, para a árvore terminada ganhar um atestado novo.

Gerar o contrato

Rode o comando do diretório onde está a sua proposta:
```
/fito-case-generate
```
Ou nomeie a proposta e o destino:
```
/fito-case-generate ./case-proposal.md --dir ~/code/my-case
```
Confirme o plano que ele apresenta — título, tipo, duração, diretório e modo. Duas coisas são fechadas aqui: a autoria do manifesto e quaisquer Open questions que a proposta trouxe.
Deixe ele escrever os arquivos e leia o resumo. Ele relata os objetivos e pré-requisitos com os níveis de Bloom, cada critério de rubrica com peso e método de avaliação, os documentos de situação, se um quiz vem junto, e os campos opcionais que o contrato deixa vazios.
Peça para ver qualquer arquivo, e mude o que quiser, antes do commit.
Deixe ele fazer o commit. Greenfield comita num main novo; reuse comita no ramo em que você está.

Flags

Flag	Obrigatória	O que faz
(texto inicial)	Não	O arquivo da proposta. O padrão é `./case-proposal.md`
`--dir <path>`	Não	O diretório de trabalho onde os artefatos ficam

O que ele escreve

Os quatorze arquivos obrigatórios, mais quiz.yaml exatamente quando a proposta trouxe perguntas, e task/steps.md num tutorial. A lista completa está em O que é um caso.

Uma primeira geração preenche os campos de versão para você:

Campo	Valor
`manifest.yaml` → `version`	`1.0.0`
`manifest.yaml` → `status`	`draft`
`manifest.yaml` → `submission.method`	`pull_request`
`manifest.yaml` → `submission.target_branch`	`v1.0.0`
`manifest.yaml` → `submission.student_branch`	`solution`
`solution.yaml` → `branch`	`case/solution-v1.0.0`

Esses são valores iniciais, não nomes que você pode reaproveitar depois. A publicação muda status para published, e toda versão depois da primeira precisa mover version, target_branch e o ramo da solução juntos — veja Corrigir ou aposentar um caso publicado.

Vale conhecer dois arquivos antes de ler:

starter_state/known_state.yaml — antes de o código existir, ele declara o contrato que esse trabalho precisa realizar: quais testes precisam falhar, quais erros precisam aparecer. É uma promessa, não uma observação, até a passagem de re-validate.
artifacts.yaml — numa execução de reuso, ele anota os arquivos reais do projeto. Numa greenfield, começa vazio e é finalizado na passagem de re-validate.

Leia os campos opcionais não usados

Uma validação que passa relata optionalFieldsNotUsed: os campos opcionais que este caso deixa vazios, agrupados por arquivo.

Não há nada errado com eles. Um campo opcional é a única coisa que o validador nunca consegue rejeitar, então ele ficaria invisível para sempre. O relatório existe para você preencher um — ou deixar como está — enquanto a árvore ainda não foi comitada.

O ciclo é editar, depois validar

Quando o validador falha, corrija os arquivos nomeados e rode de novo. Nunca regere a árvore por causa de um erro que dá para corrigir. Cada erro nomeia o arquivo e o caminho do campo que o produziu, e é isso que torna a correção pequena possível.

O validador, a saída dele e as regras têm uma página própria: Validar a pasta .case/.

Quando a geração para

O que você vê	O que significa	O que fazer
O arquivo da proposta não existe	Este fluxo começa na saída do passo de desenho	Rode Desenhar um caso antes
Falta um bloco obrigatório na proposta	Parameters, learning objectives, prerequisites ou rubric criteria não chegaram	Termine o passo de desenho
Erros estruturais, agrupados por arquivo	A árvore não satisfaz o conjunto de regras	Corrija os arquivos nomeados e rode o validador de novo

O que vem a seguir

Planejar o código do caso — a especificação e o plano do trabalho de código.
Construa o código inicial fora do Fito, guiado por esses documentos.
Rode este comando de novo sobre a árvore terminada, para o atestado novo.
Publicar um caso.

Uma passagem estrutural não prova que os componentes referenciados existem. Isso é resolvido pelo servidor do Fito quando você publica.