Laboratório da Fundição de Autômatos
[!TIP] Baixe o ZIP do aluno ou copie todo este laboratório para uma pasta não utilizada. Leia a configuração e as etapas opcionais do GitHub primeiro.
Antes de executar qualquer coisa
| Item | Contrato |
|---|---|
| Runtime | Node 24; as integrações ao vivo são separadas |
| Arquivos para inspecionar | starter/index.ts, starter/package.json, starter/evaluation.json, verify.js |
| Diretório do verificador | Raiz do kit extraído: node verify.js; de starter/: node ../verify.js |
| Estado inicial | Starter inacabado é rejeitado; preserve o diagnóstico |
| Evidência final | O verificador estrutural aceita a origem e os cinco casos declarados; os resultados ao vivo, se houver, são registrados separadamente. |
Conceito em prática: Um aplicativo pode enviar um prompt e imprimir uma resposta e ainda assim falhar por timeout ou solicitações sem suporte. Seu plano de avaliação deve perguntar que evidência distingue esses caminhos.
Compile e avalie um aplicativo mínimo de TypeScript com o GitHub Copilot SDK.
Isole o exercício
Copie este laboratório para um local descartável e abra starter/ como raiz do workspace. Não adicione credenciais aos arquivos-fonte.
Missão
- Complete
starter/index.ts:- leia o prompt dos argumentos da linha de comando;
- crie
CopilotClient; - crie uma sessão com
model: "auto"; - chame
sendAndWait; - imprima o conteúdo retornado;
- pare o cliente em
finally.
- Complete os cinco casos em
starter/evaluation.json:- explicação fundamentada;
- plano delimitado;
- implementação verificada;
- solicitação sem suporte;
- falha controlada de ferramenta.
- Execute o verificador estrutural determinístico:
node ../verify.js
- Se a autenticação do Copilot CLI estiver disponível, execute a aplicação:
npm install
npm start -- "Explain the evidence required before declaring a task complete."
Registre o comando, o código de saída, a resposta observada e as limitações de autenticação. O verificador não afirma a qualidade do modelo nem faz uma chamada de rede.
Execução guiada
- Execute o verificador intocado e registre o estado inicial esperado.
- Peça uma explicação fundamentada na fonte do código e das verificações relevantes.
- Planeje: complete o ciclo de vida fixado do SDK de TypeScript e a entrada do prompt da CLI. Mantenha as credenciais fora do código-fonte, encerre o cliente em finally e defina cinco casos com evidência esperada antes de qualquer solicitação ao vivo opcional.
- Implemente apenas a fatia aprovada e então execute novamente o mesmo verificador.
- Remova a limpeza do cliente do aplicativo copiado e confirme a rejeição estrutural. Restaure-a; não infira limpeza em runtime apenas a partir deste teste estático.
- Revise o diff e registre a limitação: o verificador estrutural não mede a qualidade do modelo nem autentica o aplicativo. Siga o laboratório profissional do SDK para testes offline mais sólidos de ferramenta e ciclo de vida.
Conclusão e redefinição segura
- O comportamento exigido e seu caso negativo têm evidência observada.
- O resultado distingue a verificação local do comportamento ao vivo do host/runtime.
- Nenhuma credencial, arquivo não relacionado ou serviço foi alterado.
- A evidência está salva antes de redefinir o starter copiado.
Use uma nova extração para outra tentativa, ou restaure apenas os arquivos nomeados a partir de uma linha de base Git criada nesta cópia. Nunca aplique um comando de redefinição da raiz do currículo a partir de um projeto diferente.
Continue com a aventura e a rubrica.