Publicar um caso

Publicar faz três coisas numa execução só: envia o seu caso para o GitHub, registra o caso no Fito e o torna público. Depois que dá certo, os refs criados ficam congelados para sempre.

Esta página cobre a primeira publicação de um caso. Publicar uma correção de um caso que já está no ar passa pelo mesmo comando e toma outro caminho — veja Corrigir ou aposentar um caso publicado.

Antes de começar

• Um login no Fito. Registrar e publicar exigem autenticação. Veja Entrar pelo terminal.
• Um gh autenticado. Rode gh auth login. O repositório é criado e enviado sob essa conta local.
• Uma árvore terminada. O trabalho de código feito, o ramo local case/solution-vX.Y.Z construído, e tudo comitado. Os dois scripts de publicação recusam uma árvore suja, porque o que é validado precisa ser exatamente o que é enviado.

O que é enviado

Três refs, num envio só:

Ref	O que é
main	O seu ramo de desenvolvimento
vX.Y.Z	Um ramo e uma tag, os dois congelados
case/solution-vX.Y.Z	A solução exemplar, congelada

O repositório é criado público, em https://github.com/<owner>/<name>, e é essa URL que quem aprende clona.

Só se você enviar à mão

O ramo vX.Y.Z e a tag vX.Y.Z têm o mesmo nome, o que normalmente deixa um push ambíguo. O /fito-publish-case envia cada ref pelo nome completo, então isso nunca chega até você. Se um dia você precisar recuperar um envio sozinho, os nomes completos são assim:

git push origin refs/heads/v1.0.0:refs/heads/v1.0.0
git push origin refs/tags/v1.0.0:refs/tags/v1.0.0
git push origin refs/heads/case/solution-v1.0.0:refs/heads/case/solution-v1.0.0

Publicar o caso

1. Rode o comando do diretório do caso:

   /fito-publish-case

   Ou nomeie o diretório e o repositório:

   /fito-publish-case ~/code/my-case --repo my-org/broken-json-endpoint

2. Confirme dono e nome do repositório. Um <name> sozinho pega o dono de FITO_PUBLISH_GITHUB_OWNER, ou do seu login do gh. Uma organização serve — o Fito só registra a URL.

3. Aprove a descrição de vitrine. É o markdown que quem aprende lê na listagem do catálogo antes de abrir o caso. Ela é rascunhada a partir da situação, do objetivo da tarefa e dos objetivos de aprendizagem, e nunca de qualquer coisa sob solution/. Ela é salva em .authoring/description-overview.md.

4. Deixe ele colocar status: published em .case/manifest.yaml e comitar isso junto com a descrição.

5. Deixe ele rodar a publicação. Uma execução valida, envia, registra e publica.

A vitrine nomeia o tema, nunca a jogada

A descrição é pública e lida antes de qualquer pessoa se inscrever, e é rascunhada a partir de learning_objectives.yaml — o que significa que a resposta pode chegar nela por uma porta sobre a qual os próprios arquivos do caso tomaram cuidado.

Aplique o mesmo teste ao texto rascunhado:

Alguém que viu só esta página conseguiria aplicar a correção?

Se sim, reescreva. Diga sobre o que o caso é e o que quem aprende vai praticar; deixe a técnica para o caso. Um tutorial é a exceção — os passos dele são o método.

Flags

Flag	Obrigatória	O que faz
(texto inicial)	Não	O diretório do caso. O padrão é .
--repo <owner>/<name>	Não	O repositório a criar e enviar
--case-id <uuid>	Não	Um rascunho registrado por uma tentativa anterior

Quando a publicação para

É seguro rodar de novo depois de qualquer uma delas. O repositório nunca é duplicado, e um rascunho registrado é reaproveitado em vez de criado de novo.

O que você vê	O que significa	O que fazer
“The working tree has uncommitted changes”	O que seria validado não é o que seria enviado	Comite ou guarde no stash, e rode de novo
“The local solution branch … does not exist”	O solution.yaml nomeia um ramo que você não construiu	Construa conforme o plano de código, e rode de novo
“Your local gh account … is not your Fito account’s linked GitHub identity”	As duas contas são diferentes	Se for intencional, rode de novo com --accept-gh-mismatch. A confirmação é sua
“… is already a published Fito case”	Esta URL já está no ar	Isso é uma atualização, não uma primeira publicação — veja Corrigir ou aposentar um caso publicado
“The .case/ tree fails structural validation”	O conjunto de regras rejeitou a árvore	Corrija os arquivos nomeados. Veja Validar a pasta .case/
Uma rejeição do servidor do Fito, com um status HTTP	Em geral uma referência que não resolve, ou um teste de alcance que falhou	Um componente ausente pede o pipeline de conhecimento; um teste de alcance que falha quer dizer que os refs não chegaram — confira o repositório no GitHub

Depois que dá certo

Você recebe o id do caso no backend, o status PUBLISHED, e a URL web onde o caso agora está listado.

Abra como quem aprende abriria, com /fito-case-open <case-id>. É a única forma de ver o que você de fato entregou.

Os refs agora estão congelados. O que você pode e o que não pode mudar daqui em diante é o assunto da próxima página.

O que vem a seguir

• Corrigir ou aposentar um caso publicado — os dois caminhos que uma correção pode tomar.
• Abrir e trabalhar um caso — o que quem aprende encontra.