Abrir e trabalhar um caso

Abrir um caso é um comando só. Ele coloca uma cópia de trabalho do caso na sua máquina, em uma branch sua, e então explica o que estão pedindo de você.

Esta página supõe que você já escolheu um caso e tem o id dele. Se ainda não, comece em Encontrar um caso para trabalhar.

Antes de começar

• Você está logado — /fito-login.
• O git e o gh estão instalados, e o gh está autenticado como a conta do GitHub vinculada ao seu perfil Fito. Abrir faz o fork de um repositório sob aquela conta, e enviar depois confere se as duas batem.

Abrir o caso

1. Na sua sessão do pi, rode:

   /fito-case-open <case-id>

   <case-id> é o id do caso — a última parte da URL /cases/<id>. Os casos não têm nome curto no terminal, então esse id é o que todo comando recebe.

2. Acompanhe. Em ordem, ele:

   • faz o fork do repositório do caso para a sua conta do GitHub
   • clona o fork em ~/.fito/cases/<case-id>/
   • faz checkout da versão publicada do caso, não da branch padrão dele
   • revalida estruturalmente a pasta .case/ no seu checkout
   • cria a sua branch de trabalho
   • registra a sua inscrição com o Fito

3. Confirme o checkout. Ele imprime onde o caso caiu e em que branch você está:

   Case opened at: ~/.fito/cases/<case-id>
   on branch '<name>'

   Confira que o fork nomeado pertence à sua conta vinculada ao Fito.

O que o briefing dá a você

Assim que o checkout existe, a sessão lê o caso e orienta você. Ele vem em quatro partes, nesta ordem.

1. O cabeçalho — o título do caso, o seu tipo (diagnostic, implementation ou tutorial) e a duração estimada.

2. A situação — todos os documentos de situação que o caso declara, na ordem em que ele os declara, cada um enquadrado pelo que é: um chamado, um e-mail, uma saída de log, uma conversa, a descrição de um pull request ou prosa simples. Nada é reordenado nem pulado, porque a ordem faz parte da história.

3. A tarefa — o objetivo, as restrições dentro das quais você tem de trabalhar, os passos se for um caso tutorial, e as entregas esperadas.

4. Os artefatos — um mapa anotado dos arquivos relevantes do repositório, rotulados como evidence, target, reference ou scaffold, com os arquivos target que você provavelmente vai mudar destacados.

Depois disso ele ancora o caso no vocabulário do Fito, em dois grupos: This case develops, a partir dos objetivos de aprendizagem do caso, e You should already know, a partir dos pré-requisitos dele. Cada um é buscado ao vivo no Repositório de Conhecimento, e não parafraseado.

A solução está fora de alcance, não apenas proibida

O briefing nunca mostra o .case/solution/, e o tutor também não. Isso não é uma regra que se pede a eles para cumprir.

A superfície de briefing serve documentos por uma chave enumerada — manifest, situation, task, artifacts, starter_state, knowledge_refs — e nunca por caminho de arquivo. Quatro coisas não têm chave nenhuma: a pasta da solução exemplar, o solution.yaml, o rubric.yaml e o quiz.yaml. Não existe requisição que chegue até eles, então não há nada a resistir.

O manifesto do próprio caso é podado do mesmo jeito. Você vê o título, o tipo e a duração; os autores, o status de publicação e a configuração de envio são metadados de autoria e não são servidos.

Os arquivos estão no seu disco de qualquer jeito

O seu checkout é um repositório git, e a versão publicada não carrega a branch da solução. O que você não alcança pelo briefing, também não alcança lendo em volta.

Trabalhar

Abra ~/.fito/cases/<case-id>/ no seu editor e resolva o caso. Commite na branch de trabalho — é essa a branch que o envio vai subir.

Travado? Pergunte ao tutor. Ele consegue ler este caso e o conhecimento por trás dele, e mais nada.

Quando quiser ver onde está sem entregar nada, rode /fito-evaluate <case-id>. Ele avalia o seu trabalho localmente e não registra nada. Veja Como um caso é avaliado.

Voltar a um caso que você já tentou

Se o seu fork já carrega a branch de trabalho deste caso — você enviou uma vez, apagou o checkout local e voltou — a abertura para e pergunta a você.

Escolha	O que faz
Retomar	Faz checkout da branch do fork e a acompanha. Os seus commits e o seu pull request aberto sobrevivem.
Recomeçar	Apaga a branch do fork, o que fecha o pull request antigo, e começa de novo da versão publicada.

A sessão repassa as duas opções e espera. Ela nunca escolhe por você, porque uma das duas joga trabalho fora.

Recomeçar fecha o seu pull request e descarta trabalho não mesclado

Apagar a branch do fork não tem volta pelo Fito. Escolha isso só quando você quiser mesmo abandonar aquela tentativa.

Uma primeira abertura — sem fork, ou com um fork sem aquela branch — nunca pergunta.

Quando uma abertura recusa

O que ele diz	O que quer dizer
Um relatório “case source malformed”, e nenhuma branch	A pasta .case/ do próprio caso não valida. Não há nada errado do seu lado. Tente mais tarde, ou reporte o caso.
Uma recusa citando um caso descontinuado	O caso foi retirado. Não contorne; escolha outro.
⚠ This case has been deprecated…, e depois uma abertura normal	O caso está de saída, mas ainda dá para trabalhá-lo.
Ele não sobrescreve um checkout não vazio	Você já tem este caso aberto em ~/.fito/cases/<case-id>/. Trabalhe ali.
GitHub CLI is not ready — install gh and run 'gh auth login'.	O gh está ausente ou deslogado.

O que vem a seguir

• Pergunte ao tutor — ajuda com escopo no caso enquanto você trabalha.
• Como um caso é avaliado — o que a rubrica vai julgar.
• Enviar e ler o seu resultado — entregue.