Os Portais de Nexus

[!NOTE] Status: Conteúdo pronto · Mídia: Capa gerada e ilustração SVG original · Última verificação: 2026-09-05
Capacidade principal: Selecionar papéis, harnesses, destinos e ambientes

[!TIP] Baixe este kit de aprendizagem e use o guia de extração e configuração. Mantenha o starter original intacto.

---
config:
  theme: base
  look: classic
  themeVariables:
    darkMode: false
    background: "#ffffff"
    primaryColor: "#f5f5f5"
    primaryTextColor: "#111111"
    primaryBorderColor: "#555555"
    secondaryColor: "#e0e0e0"
    secondaryTextColor: "#111111"
    secondaryBorderColor: "#666666"
    tertiaryColor: "#bdbdbd"
    tertiaryTextColor: "#111111"
    tertiaryBorderColor: "#444444"
    lineColor: "#444444"
    textColor: "#111111"
    mainBkg: "#f5f5f5"
    nodeBorder: "#555555"
    clusterBkg: "#ffffff"
    clusterBorder: "#999999"
    edgeLabelBackground: "#ffffff"
    actorBkg: "#e0e0e0"
    actorBorder: "#555555"
    actorTextColor: "#111111"
    actorLineColor: "#777777"
    signalColor: "#333333"
    signalTextColor: "#111111"
    labelBoxBkgColor: "#f5f5f5"
    labelBoxBorderColor: "#777777"
    labelTextColor: "#111111"
    loopTextColor: "#111111"
    activationBkgColor: "#bdbdbd"
    activationBorderColor: "#555555"
    noteBkgColor: "#f5f5f5"
    noteTextColor: "#111111"
    noteBorderColor: "#777777"
    attributeBackgroundColorOdd: "#f5f5f5"
    attributeBackgroundColorEven: "#e0e0e0"
---
flowchart LR
    accTitle: Mapa de capacidades de The Portals of Nexus
    accDescr: Uma responsabilidade não determina o runtime nem a localização. Mantenha essas dimensões separadas mesmo quando uma interface as apresentar juntas.
    T["Resultado da tarefa"] --> R["Papel: responsabilidade"]
    T --> H["Harness: runtime"]
    H --> P["Destino: alvo"]
    P --> E["Ambiente: arquivos e processos"]
    R --> V["Evidência para cada escolha"]
    E --> V

Legenda. As caixas nomeiam dimensões distintas; as setas mostram quais decisões devem ser conectadas antes da execução.

Explicação. Uma responsabilidade não determina o runtime nem a localização. Mantenha essas dimensões separadas mesmo quando uma interface as apresentar juntas.

Referências oficiais

Estas fontes oficiais são a autoridade sobre o comportamento e a disponibilidade do produto. Consulte-as novamente ao usar uma superfície diferente ou após uma atualização do produto.

• Conceitos de harnesses de agentes
• Executar agentes em diferentes harnesses
• Sobre o GitHub Copilot cloud agent

História

Em Nexus, quatro portais parecem idênticos até que suas runas revelam quem age, onde o trabalho é executado e qual autoridade atravessa o limiar.

A fantasia é um recurso de memorização; a lição de engenharia exige evidências observáveis e reproduzíveis.

Objetivos de aprendizagem

• Classifique uma tarefa por papel de agente, harness, destino e ambiente de execução.
• Explique por que um worktree isola alterações de origem, mas não fornece uma nova identidade.
• Complete o mapa dos portais e diferencie suas escolhas controladas das regras universais do produto.

Pré-requisitos

Para preparar ferramentas e contas pessoais, conclua o guia de pré-requisitos. Para estudar somente pelo terminal, siga o fluxo via CLI no kit extraído; as evidências específicas do VS Code continuam separadas.

Limite de evidência: O verificador verifica o mapa, não se algum host ou conta selecionados estão disponíveis.

Duração estimada da sessão: 45–75 minutos após os pré-requisitos; a duração real varia. Nunca use segredos de produção nem dados de clientes.

Explicação dos conceitos

Um fluxo de trabalho agêntico tem dimensões separadas. Um papel é Ask, Plan, Agent ou um agente personalizado. Um harness é o runtime, como Local, Copilot ou outro harness com suporte; Cloud é um destino de sessão remota. O ambiente é a pasta, worktree, máquina local ou workspace remoto. Instruções, prompts, skills, agentes personalizados e servidores MCP são primitivas distintas de personalização. Nomear cada dimensão evita autoridade acidental e resultados irreproduzíveis.

Caso de uso concreto

Um mantenedor pede uma explicação e depois uma alteração. Ask pode inspecionar sem editar; uma sessão posterior de Agent pode usar um worktree. Registre essas decisões separadamente em vez de descrever ambas como um único modo de agente.

Verificação de vocabulário

• Papel: Ask, Plan, Agent ou um agente personalizado.
• Harness/superfície: o runtime ou a superfície do produto em que um papel opera.
• Destino: o destino de sessão selecionado, como Local, Copilot ou Cloud, quando exposto.
• Ambiente: a pasta, worktree, máquina local, Codespace ou ambiente remoto.
• Instruções: contexto duradouro aplicado automaticamente.
• Prompt: um modelo de tarefa invocado manualmente.
• Skill: conhecimento especializado reutilizável, carregado quando relevante.
• Agente personalizado: um papel com instruções, ferramentas e transferências opcionais.
• MCP: Model Context Protocol.
• Evidência: um caminho, diff, resultado de comando, rastreamento ou decisão de revisão.

Fluxo de trabalho Ask → Plan → Agent

Ask — investigar

1. Identifique o resultado real esperado pelo usuário e a fonte de verdade atual.
2. Inspecione os arquivos, as instruções, as ferramentas, as permissões e as verificações existentes relevantes.
3. Cite caminhos concretos ou evidências da plataforma para cada descoberta importante.
4. Registre as incertezas e não deduza capacidades indisponíveis.

Ponto de controle: Nenhuma implementação antes de compreender o estado atual e as evidências.

Plan — projetar

1. Declare o escopo, o que está fora dele, as suposições, os riscos e os limites de confiança.
2. Selecione o mínimo necessário de papel, ferramentas, autoridade e ambiente.
3. Defina critérios de aceitação, comandos de verificação, revisão e restauração.
4. Sinalize qualquer dependência em versão prévia (Preview) ou experimental e forneça uma alternativa.

Ponto de controle: Outra pessoa em aprendizagem deve conseguir prever a conclusão a partir do plano.

Agent — executar

1. Faça a menor alteração reversível ou produza o artefato planejado.
2. Use ciclos curtos de inspecionar → alterar → verificar.
3. Preserve a saída dos comandos, o status de saída, os diffs, os rastreamentos ou os registros da plataforma.
4. Pare quando os critérios de aceitação forem atendidos; não faça limpezas sem relação com a tarefa.

Revisão — questionar

1. Inspecione o diff ou artefato completo.
2. Compare cada resultado com o plano e os critérios de aceitação.
3. Execute a verificação existente mais restrita e relevante, ampliando-a somente quando houver justificativa.
4. Registre as limitações e os riscos não resolvidos.
5. Avalie o trabalho com rubric.md.

Missão guiada

1. Prepare uma cópia isolada

1. Baixe e extraia o kit portals-of-nexus em um novo diretório de trabalho.
2. Leia KIT-START.md em sua raiz. Abra starter/ como o workspace do VS Code quando testar a descoberta, mas execute o verificador a partir da raiz do kit.
3. Inspecione starter/portal-map.json, verify.js antes de editar.
4. A partir da raiz do kit extraído, execute node verify.js.
5. Registre a baseline aprovada documentada. Um runtime ausente ou uma falha não relacionada não é o resultado esperado do exercício.

2. Investigue e planeje

Comando da verificação inicial pronto para copiar, a partir da raiz do kit extraído:

node verify.js

Em Ask, solicite um rastreamento dos arquivos inspecionados e do que o verificador realmente observa. Questione qualquer afirmação sobre execução ao vivo que não esteja respaldada pela saída.

Use este prompt de planejamento:

Map the three task rows to role, harness, target and environment. Justify each choice, identify which dimensions the verifier checks, and keep the task read-only until the map is reviewed.
Do not implement yet. Identify affected files, the negative case and a safe reset.

3. Implemente o recorte revisado

1. Aprove apenas o artefato starter nomeado e os testes focados necessários.
2. Peça a Agent para implementar um único recorte; inspecione os comandos propostos antes da execução.
3. Execute node verify.js novamente a partir da raiz do kit, ou node ../verify.js a partir de starter/.
4. Compare o resultado exato com o ponto de verificação abaixo e revise o diff completo.
5. Registre separadamente a descoberta do host ou a atividade ao vivo quando disponível. Não habilite serviços extras para fabricar um resultado aprovado.

[!IMPORTANT] Ponto de verificação: Cada linha de tarefa tem quatro dimensões independentes; um pull request do GitHub não está rotulado incorretamente como um ambiente. O verificador verifica o mapa, não se algum host ou conta selecionados estão disponíveis.

4. Comprove que uma verificação pode rejeitar um erro

No mapa descartável, troque temporariamente um papel por um valor de harness. O verificador deve rejeitar as dimensões misturadas. Restaure a linha correta.

Termine com a evidência de capacidade específica da aventura na rubrica, não apenas com a presença de um arquivo.

Falha intencional: A Suposição do Portal Universal

Faça isso somente em um ambiente descartável:

Descreva o trabalho apenas como “use o modo Agent para corrigir isto”, omitindo o harness, o ambiente, as permissões e a verificação. A solicitação falha porque Agent nomeia uma responsabilidade, não um limite de execução.

Recuperação

Retorne a Ask, identifique o limite violado, restrinja o plano, remova autoridade ou contexto desnecessários e repita a menor verificação relevante. Documente a lição sobre a causa, em vez de apenas afirmar que a tentativa falhou.

Desafio independente

Dado um bug que exige investigação, projeto, implementação e evidências de CI, justifique cada transição de papel e ambiente.

Restrições:

• Não copie a missão guiada literalmente.
• Não adicione ferramentas, permissões ou recursos de nuvem sem uma necessidade declarada.
• Não faça alegações de qualidade, desempenho, compatibilidade ou disponibilidade sem evidências obtidas por execução.
• Mantenha a linguagem de fantasia subordinada à clareza técnica.

Lista de verificação de evidências

• Descobertas de Ask fundamentadas nas fontes.
• Plano aprovado com escopo, exclusões, riscos, verificações e restauração.
• Diff ou artefato de Agent limitado ao escopo declarado.
• Saída de verificação com comando, status ou registro da plataforma.
• Causa raiz da falha intencional e recuperação.
• Resultado do desafio independente.
• Limitações explícitas e notas sobre o status das funcionalidades.
• rubric.md preenchido.

Instruções de restauração

1. Salve seu diff, a saída do comando e as limitações do kit descartável.
2. Pare apenas o processo ou a sessão de aprendizagem que você iniciou. Não pare outros projetos.
3. Se você inicializou Git no kit, inspecione git status --short lá e restaure apenas os seus arquivos de exercício nomeados a partir da baseline local.
4. Caso contrário, extraia o ZIP original em um novo diretório não utilizado para outra tentativa; não sobrescreva seu trabalho atual.
5. Remova apenas configurações, worktrees ou recursos remotos pertencentes ao exercício depois de revisar o que vale a pena preservar.

A fonte do currículo e os demais projetos devem permanecer inalterados. Uma redefinição da cópia do kit não é um reset completo do repositório.

Próxima aventura

Os Espelhos do Contexto