Planejar o código do caso

Um caso precisa de código: o estado inicial que quem aprende recebe, e a solução exemplar em case/solution-vX.Y.Z. O Fito não escreve esse código. Ele escreve os dois documentos que guiam você enquanto escreve.

Este passo fica entre gerar o contrato e publicar. Ele escreve só .authoring/, nunca .case/ e nunca o código do seu projeto, e não envia nada para lugar nenhum.

Antes de começar

Um diretório de trabalho com .case/ dentro. Veja Gerar a pasta .case/.
O case-proposal.md que Desenhar um caso escreveu. O comando lê dele a versão de linha principal de cada tecnologia e a toolchain.
Um provedor de LLM configurado no pi, e o pacote pi-subagents instalado. O planejamento é entregue a uma persona trabalhadora por esse pacote, no seu próprio modelo.

Planejar o código

Do diretório onde está o case-proposal.md, rode o comando e nomeie o diretório do caso:
```
/fito-case-plan-source ~/code/my-case
```
Para forçar o cenário, ou para ler uma proposta guardada em outro lugar, acrescente as flags:
```
/fito-case-plan-source ~/code/my-case --scenario greenfield --proposal ~/code/case-proposal.md
```
Confirme o cenário que ele detectou e o arquivo de proposta que ele encontrou. Reuse quer dizer que a árvore já carrega código de projeto; greenfield quer dizer que o código inicial é construído do zero.

Quando ele não encontra proposta nenhuma, pergunta o caminho do arquivo. Sem uma proposta, informe a versão de linha principal de cada tecnologia e a toolchain no lugar dela.
Leia o resumo que ele relata: os dois estados finais, o número de passos do plano, quais gates da rubrica são cobertos, e a conferência de toolchain dele.
Peça qualquer seção, e devolva revisões, até os documentos ficarem certos.
Deixe ele comitar. Só .authoring/ entra. Se algo fora dessa pasta mudou, ele para e mostra em vez de comitar.

Flags

Flag	Obrigatória	O que faz
(texto inicial)	Não	O diretório do caso. O padrão é `.`
`--scenario reuse\|greenfield`	Não	Sobrescreve a detecção do passo 2
`--proposal <path>`	Não	A proposta de caso a ler. O padrão é `case-proposal.md` no diretório do caso, depois `./case-proposal.md`

Os dois documentos

Arquivo	O que é
`.authoring/source-spec.md`	O que o código precisa ser — tanto o estado inicial quanto o ramo da solução
`.authoring/source-plan.md`	Passos ordenados e verificáveis para chegar lá

Rodar o comando de novo numa árvore que já os tem é uma execução de revisão. Ele diz isso e pergunta o que deve mudar; ele nunca sobrescreve em silêncio documentos que você revisou.

Dois tipos de problema, dois caminhos diferentes

O planejador lê o seu contrato .case/ contra o código. Quando os dois discordam, a correção depende de qual está errado.

O que ele relata	Onde a correção fica
Um conflito de contrato — um comando de gate que os arquivos de build do projeto não declaram, um caminho de teste que não pode existir	Em `.case/`. Volte a Gerar a pasta `.case/`, corrija, e rode este comando de novo
Uma divergência de toolchain — a sua toolchain declarada contradiz o que uma versão de tecnologia diz precisar	Em lugar nenhum automático. É informativo: reconcilie a declaração você mesmo

Nunca planeje em volta do contrato. Se o contrato está errado, mude o contrato.

Construa o código fora do Fito

Executar .authoring/source-plan.md é trabalho seu, no seu harness, com as ferramentas que você quiser. O Fito não indica ferramenta nenhuma e não tem comando para esta metade.

O que cada documento é

Os dois documentos não são dois passos. Eles são um roteiro e a régua que esse roteiro precisa alcançar:

Arquivo	Papel	O que você faz com ele
`.authoring/source-plan.md`	O roteiro	Execute os passos numerados, na ordem
`.authoring/source-spec.md`	O critério de aceitação	Confira a árvore pronta contra ele

Entregue os dois. O planejador os escreve para se bastarem — todo nome de teste, comando de gate, texto de erro e nome de ramo está escrito ali dentro — então uma sessão que não conhece o Fito consegue executá-los. Um agente de código os lê tão bem quanto você.

Um passo termina quando a verificação dele passa

Todo passo traz uma verificação: um comando, e o resultado que você deve observar. É isso que torna seguro entregar o plano a um agente. Você não está confiando em um relato, você está rodando um comando.

Dois tipos de passo ainda precisam de você:

Um valor que o planejador não conseguiu fundamentar. Quando nem o conhecimento buscado nem a árvore existente mostraram como algo se faz, o passo nomeia esse valor para você conferir contra o toolchain real, em vez de inventar uma API que seguiria adiante para dentro do projeto do caso.
Uma lacuna que o planejador apontou. Se uma entrada de failing_tests, um erro conhecido ou uma entrega não teve contraparte em nível de arquivo, ele diz isso no resumo em vez de encobrir. Fechar essa é com você.

Você termina quando dois comandos concordam

Rode os dois e leia a saída:

Ramo	O que você precisa ver
`case/solution-vX.Y.Z`	Todo comando de gate da rubrica passa na sua condição de aprovação
O ramo inicial, o que carrega `.case/`	Falham exatamente os testes que o `known_state.yaml` nomeia, cada um pelo motivo declarado. Nada mais falha

O ramo da solução fica local. Empurrá-lo é trabalho do /fito-publish-case; o seu plano só precisa deixá-lo existindo.

Volte e revalide

Quando o código estiver pronto, rode o comando de geração de novo sobre a árvore:

/fito-case-generate --dir ~/code/my-case

Ele encontra .case/ já ali e toma o caminho de re-validate. O artifacts.yaml é finalizado contra a árvore agora real, e a árvore ganha o atestado novo que a publicação leva.

O que vem a seguir

Publicar um caso — enviar os refs, registrar e entrar no ar.