[{"id": "g1", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Um agente de análise de documentos descobre que duas fontes confiáveis contêm estatísticas diretamente contraditórias para uma métrica-chave: um relatório governamental indica crescimento de 40%, enquanto uma análise da indústria indica 12%. Ambas as fontes parecem confiáveis e a discrepância pode afetar materialmente as conclusões da pesquisa. Como o agente de análise de documentos deve lidar com essa situação da forma mais efetiva?", "question": "Qual abordagem é mais efetiva?", "options": [{"letter": "A", "text": "Aplicar heurísticas de credibilidade para escolher o número mais provavelmente correto, finalizar a análise com esse valor e adicionar uma nota de rodapé mencionando a discrepância.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Incluir ambos os números na saída da análise sem marcá-los como conflitantes, deixando o agente de síntese decidir qual usar com base em contexto mais amplo.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Parar a análise e escalar imediatamente ao coordenador, pedindo que ele decida qual fonte é mais autoritativa antes de continuar.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Concluir a análise com ambos os números, anotar explicitamente o conflito com atribuição de fonte e deixar o coordenador decidir como reconciliar os dados antes de passá-los à síntese.", "correct": true, "explanation": "Esta abordagem preserva a separação de responsabilidades: o agente de análise conclui seu trabalho principal sem bloquear, preserva ambos os valores conflitantes com atribuição clara e passa corretamente a reconciliação ao coordenador, que tem contexto mais amplo."}], "correct": "D", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "g2", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Os agentes de busca web e de análise de documentos concluíram suas tarefas e retornaram resultados ao coordenador. Qual é o próximo passo para criar um relatório de pesquisa integrado?", "question": "Qual próximo passo é mais apropriado?", "options": [{"letter": "A", "text": "Cada agente envia seus resultados diretamente ao agente redator do relatório, contornando o coordenador.", "correct": false, "explanation": ""}, {"letter": "B", "text": "O agente de análise de documentos solicita os resultados de busca web e os funde internamente.", "correct": false, "explanation": ""}, {"letter": "C", "text": "O coordenador passa ambos os conjuntos de resultados ao agente de síntese para uma integração unificada.", "correct": true, "explanation": "Em uma arquitetura coordenador–subagente, o coordenador encaminha ambos os conjuntos de resultados ao agente de síntese para uma integração centralizada, preservando o controle e garantindo uma fusão de alta qualidade."}, {"letter": "D", "text": "O coordenador concatena as saídas brutas de ambos os agentes e as devolve como resultado final.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "1.2", "objective": "Orchestrate multi-agent systems with coordinator-subagent patterns", "group": "A"}, {"id": "g3", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Um subagente de análise de documentos falha frequentemente ao processar arquivos PDF: alguns têm seções corrompidas que disparam exceções de parsing, outros são protegidos por senha e às vezes a biblioteca de parsing trava em arquivos grandes. Atualmente, qualquer exceção termina imediatamente o subagente e retorna um erro ao coordenador, que precisa decidir se retenta, pula ou falha a tarefa toda. Isso causa envolvimento excessivo do coordenador no tratamento rotineiro de erros. Qual melhoria arquitetural é mais efetiva?", "question": "Qual melhoria é mais efetiva?", "options": [{"letter": "A", "text": "Criar um agente dedicado a tratamento de erros que monitore todas as falhas via fila compartilhada e decida ações de recuperação, enviando comandos de reinício diretamente aos subagentes.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Configurar o subagente para sempre retornar resultados parciais com status de sucesso, embutindo detalhes do erro em metadados; o coordenador trata todas as respostas como bem-sucedidas.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Fazer com que o coordenador valide todos os documentos antes de enviá-los ao subagente, rejeitando documentos que possam causar falhas.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Implementar recuperação local no subagente para falhas transitórias e escalar ao coordenador apenas erros que ele não consegue resolver, incluindo passos tentados e resultados parciais.", "correct": true, "explanation": "Trate erros no nível mais baixo capaz de resolvê-los. A recuperação local reduz a carga do coordenador enquanto ainda escala questões verdadeiramente irrecuperáveis com contexto completo e progresso parcial."}], "correct": "D", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "g4", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Após executar o sistema sobre \"impacto da IA nas indústrias criativas\", você observa que cada subagente conclui com sucesso: o agente de busca web encontra artigos relevantes, o agente de análise de documentos os sumariza corretamente e o agente de síntese produz um texto coerente. No entanto, os relatórios finais cobrem somente artes visuais e perdem totalmente música, literatura e cinema. Nos logs do coordenador, você vê que ele decompôs o tema em três subtarefas: \"IA em arte digital\", \"IA em design gráfico\" e \"IA em fotografia\". Qual é a causa-raiz mais provável?", "question": "Qual é a causa-raiz mais provável?", "options": [{"letter": "A", "text": "Faltam ao agente de síntese instruções para detectar lacunas de cobertura.", "correct": false, "explanation": ""}, {"letter": "B", "text": "O agente de análise de documentos filtra fontes não-visuais por critérios de relevância excessivamente estritos.", "correct": false, "explanation": ""}, {"letter": "C", "text": "A decomposição de tarefas do coordenador é estreita demais, atribuindo aos subagentes trabalho que não cobre todas as áreas relevantes.", "correct": true, "explanation": "O coordenador decompôs um tema amplo apenas em subtarefas de artes visuais, perdendo totalmente música, literatura e cinema. Como os subagentes executaram suas atribuições corretamente, a decomposição estreita é a causa-raiz óbvia."}, {"letter": "D", "text": "As queries do agente de busca web são insuficientes e deveriam ser ampliadas para cobrir mais setores.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "1.6", "objective": "Design task decomposition strategies for complex workflows", "group": "A"}, {"id": "g5", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "O subagente de busca web retorna resultados para apenas 3 das 5 categorias de fontes solicitadas (sites de concorrentes e relatórios da indústria têm sucesso, mas arquivos de notícias e feeds sociais sofrem timeout). O subagente de análise de documentos processa com sucesso todos os documentos fornecidos. O subagente de síntese precisa produzir um sumário a partir de entradas a montante de qualidade mista. Qual estratégia de propagação de erro é mais efetiva?", "question": "Qual estratégia de propagação de erro é mais efetiva?", "options": [{"letter": "A", "text": "Continuar a síntese usando apenas as fontes bem-sucedidas e produzir uma saída sem mencionar quais dados estavam indisponíveis.", "correct": false, "explanation": ""}, {"letter": "B", "text": "O subagente de síntese retorna um erro ao coordenador, disparando retry total ou falha da tarefa por dados incompletos.", "correct": false, "explanation": ""}, {"letter": "C", "text": "O subagente de síntese pede ao coordenador para retentar fontes com timeout com prazo maior antes de iniciar a síntese.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Estruturar a saída da síntese com anotações de cobertura indicando quais conclusões estão bem suportadas e onde existem lacunas devido a fontes indisponíveis.", "correct": true, "explanation": "Anotações de cobertura implementam degradação graciosa com transparência, preservando valor do trabalho concluído enquanto propagam incerteza para permitir decisões informadas sobre confiança."}], "correct": "D", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "g6", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "O subagente de análise de documentos encontra um arquivo PDF corrompido que ele não consegue parsear. Ao desenhar o tratamento de erros do sistema, qual é a forma mais efetiva de lidar com essa falha?", "question": "Qual abordagem é mais efetiva?", "options": [{"letter": "A", "text": "Retornar um erro com contexto ao agente coordenador, permitindo que ele decida como prosseguir.", "correct": true, "explanation": "Retornar um erro com contexto ao coordenador é a abordagem mais efetiva porque o deixa tomar uma decisão informada — pular o arquivo, tentar um método alternativo de parsing ou notificar o usuário — mantendo visibilidade da falha."}, {"letter": "B", "text": "Pular silenciosamente o documento corrompido e continuar processando os demais arquivos para evitar interromper o workflow.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Retentar automaticamente o parsing três vezes com backoff exponencial antes de reportar uma falha.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Lançar uma exceção que termina o workflow inteiro de pesquisa.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "g8", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Um colega propõe que o agente de análise de documentos envie seus resultados diretamente ao agente de síntese, contornando o coordenador. Qual é a vantagem principal de manter o coordenador como hub central para toda comunicação entre subagentes?", "question": "Qual é a vantagem principal de manter o coordenador como hub central?", "options": [{"letter": "A", "text": "O coordenador pode observar todas as interações, tratar erros de forma uniforme e decidir que informação cada subagente deve receber.", "correct": true, "explanation": "O padrão coordenador fornece visibilidade central sobre todas as interações, tratamento de erros uniforme em todo o sistema e controle granular sobre que informação cada subagente recebe — essas são as principais vantagens de uma topologia de comunicação em estrela."}, {"letter": "B", "text": "O coordenador agrupa múltiplas requisições aos subagentes, reduzindo o total de chamadas de API e a latência geral.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Roteamento pelo coordenador habilita lógica de retry automática que chamadas inter-agente diretas não suportam.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Subagentes usam memória isolada e a comunicação direta exigiria serialização complexa que só o coordenador consegue realizar.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "1.2", "objective": "Orchestrate multi-agent systems with coordinator-subagent patterns", "group": "A"}, {"id": "g9", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "O subagente de busca web sofre timeout ao pesquisar um tema complexo. Você precisa desenhar como a informação sobre essa falha é retornada ao coordenador. Qual abordagem de propagação de erro melhor habilita recuperação inteligente?", "question": "Qual abordagem de propagação de erro melhor habilita recuperação inteligente?", "options": [{"letter": "A", "text": "Retornar contexto estruturado de erro ao coordenador, incluindo o tipo de falha, a query executada, quaisquer resultados parciais e abordagens alternativas potenciais.", "correct": true, "explanation": "Retornar contexto estruturado de erro — incluindo tipo de falha, query executada, resultados parciais e abordagens alternativas — dá ao coordenador tudo que precisa para tomar decisões inteligentes de recuperação (ex.: retentar com query modificada ou continuar com resultados parciais). Preserva o máximo de contexto para decisões informadas no nível de coordenação."}, {"letter": "B", "text": "Capturar o timeout dentro do subagente e retornar um conjunto de resultados vazio marcado como bem-sucedido.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Implementar retentativas automáticas com backoff exponencial dentro do subagente, retornando apenas um status genérico \"busca indisponível\" depois de esgotar as tentativas.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Propagar a exceção de timeout diretamente ao handler de topo, terminando o workflow de pesquisa inteiro.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "g11", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Ao pesquisar um tema amplo, você observa que o agente de busca web e o agente de análise de documentos investigam os mesmos subtemas, levando a duplicação substancial em suas saídas. O uso de tokens quase dobra sem aumento proporcional na amplitude ou profundidade da pesquisa. Qual é a forma mais efetiva de tratar isso?", "question": "Qual é a forma mais efetiva de tratar isso?", "options": [{"letter": "A", "text": "Permitir que ambos os agentes terminem em paralelo e fazer com que o coordenador desduplique resultados sobrepostos antes de passá-los ao agente de síntese.", "correct": false, "explanation": ""}, {"letter": "B", "text": "O coordenador particiona explicitamente o espaço de pesquisa antes de delegar, atribuindo a cada agente subtemas distintos ou tipos de fonte distintos.", "correct": true, "explanation": "Fazer o coordenador particionar explicitamente o espaço de pesquisa antes de delegar é mais efetivo porque ataca a causa-raiz — fronteiras de tarefa pouco claras — antes de qualquer trabalho começar. Preserva paralelismo prevenindo esforço duplicado e tokens desperdiçados."}, {"letter": "C", "text": "Implementar um mecanismo de estado compartilhado em que agentes registrem sua área de foco atual para que outros agentes evitem duplicação dinamicamente durante a execução.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Mudar para execução sequencial em que a análise de documentos rode somente após a busca web concluir, usando os resultados da busca web como contexto para evitar duplicação.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "1.6", "objective": "Design task decomposition strategies for complex workflows", "group": "A"}, {"id": "g12", "domain": 1, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Durante a pesquisa, o subagente de busca web consulta três categorias de fontes com resultados diferentes: bases acadêmicas retornam 15 papers relevantes, relatórios da indústria retornam \"0 resultados\" e bases de patentes retornam \"Connection timeout\". Ao desenhar a propagação de erro para o coordenador, qual abordagem habilita as melhores decisões de recuperação?", "question": "Qual abordagem habilita as melhores decisões de recuperação?", "options": [{"letter": "A", "text": "Agregar resultados em uma única métrica de percentual de sucesso (ex.: \"67% de cobertura de fontes\") com logs detalhados disponíveis sob demanda.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Reportar tanto \"timeout\" quanto \"0 resultados\" como falhas que requerem intervenção do coordenador.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Retentar falhas transitórias internamente e reportar apenas erros persistentes.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Distinguir falhas de acesso (timeout) que exigem decisão de retry de resultados vazios válidos (\"0 resultados\") que representam queries bem-sucedidas.", "correct": true, "explanation": "Um timeout (falha de acesso) e \"0 resultados\" (resultado vazio válido) são desfechos semanticamente diferentes que exigem respostas diferentes. Distingui-los permite ao coordenador retentar a base de patentes enquanto aceita os \"0 resultados\" dos relatórios da indústria como achado válido e informativo."}], "correct": "D", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "g47", "domain": 1, "scenario": "Agente de Suporte ao Cliente", "situation": "Seu agente lida com pedidos de questão única com 94% de acurácia (ex.: \"preciso de reembolso para o pedido #1234\"). Mas quando clientes incluem múltiplas questões em uma mensagem (ex.: \"preciso de reembolso para o pedido #1234 e também atualizar o endereço de entrega do pedido #5678\"), a acurácia de seleção de ferramenta cai para 58%. O agente normalmente resolve apenas uma questão ou mistura parâmetros entre os pedidos. Qual abordagem melhora confiabilidade para pedidos multi-questão de forma mais efetiva?", "question": "Qual abordagem é mais efetiva?", "options": [{"letter": "A", "text": "Implementar uma camada de pré-processamento que use uma chamada separada do modelo para decompor mensagens multi-questão em pedidos separados, lidar com cada um independentemente e mesclar resultados.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Combinar ferramentas relacionadas em menos ferramentas universais.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar exemplos few-shot ao prompt demonstrando raciocínio correto e sequenciamento de ferramentas para pedidos multi-questão.", "correct": true, "explanation": "Exemplos few-shot que demonstram raciocínio correto e sequenciamento de ferramentas para pedidos multi-questão são mais efetivos porque o agente já performa bem em questão única — o que precisa é orientação sobre o padrão para decompor e rotear múltiplas questões mantendo parâmetros separados."}, {"letter": "D", "text": "Implementar validação de resposta que detecta respostas incompletas e re-prompta automaticamente o agente para resolver questões perdidas.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "3.5", "objective": "Apply iterative refinement techniques for progressive improvement", "group": "I"}, {"id": "g48", "domain": 1, "scenario": "Agente de Suporte ao Cliente", "situation": "Logs de produção mostram que para pedidos simples como \"reembolso para o pedido #1234\", seu agente resolve em 3–4 chamadas de ferramenta com 91% de sucesso. Mas para pedidos complexos como \"fui cobrado em dobro, meu desconto não foi aplicado e quero cancelar\", o agente faz em média 12+ chamadas com apenas 54% de sucesso — frequentemente investigando questões sequencialmente e buscando dados redundantes do cliente para cada uma. Qual mudança melhora o tratamento de pedidos complexos de forma mais efetiva?", "question": "Qual mudança é mais efetiva?", "options": [{"letter": "A", "text": "Adicionar checkpoints explícitos de verificação entre estágios, exigindo que o agente registre progresso após resolver cada questão antes de passar para a próxima.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Reduzir o número de ferramentas combinando `get_customer`, `lookup_order` e ferramentas relacionadas a cobrança em uma única `investigate_issue`.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Decompor o pedido em questões separadas, depois investigar cada uma em paralelo usando contexto compartilhado do cliente antes de sintetizar uma resolução final.", "correct": true, "explanation": "Decompor em questões separadas e investigar em paralelo com contexto compartilhado do cliente corrige ambos os problemas-chave: elimina recuperação redundante de dados reutilizando contexto compartilhado entre questões e reduz total de loops de chamada paralelizando investigação antes de sintetizar uma única resolução."}, {"letter": "D", "text": "Adicionar exemplos few-shot ao system prompt demonstrando sequências ideais de chamada de ferramentas para vários cenários multi-faceta de cobrança.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "1.1", "objective": "Design and implement agentic loops for autonomous task execution", "group": "A"}, {"id": "g50", "domain": 1, "scenario": "Agente de Suporte ao Cliente", "situation": "Após chamar `get_customer` e `lookup_order`, o agente tem todos os dados disponíveis no sistema mas ainda enfrenta incerteza. Qual situação é o gatilho mais justificado para chamar `escalate_to_human`?", "question": "Qual situação é mais justificada para escalonamento?", "options": [{"letter": "A", "text": "Um cliente quer cancelar um pedido enviado ontem e que chega amanhã. O agente deve escalar porque o cliente pode mudar de ideia depois de receber o pacote.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Um cliente afirma que não recebeu um pedido, mas o tracking mostra que foi entregue e assinado em seu endereço três dias atrás. O agente deve escalar porque apresentar evidência contraditória pode prejudicar o relacionamento.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Um cliente solicita matching de preço de concorrente. Suas políticas permitem ajustes de preço para quedas no próprio site dentro de 14 dias, mas não dizem nada sobre preços de concorrente. O agente deve escalar para interpretação de política.", "correct": true, "explanation": "Esta é uma genuína lacuna de política: regras da empresa cobrem quedas de preço no próprio site mas não tratam matching de concorrente. O agente não deve inventar política e deve escalar para julgamento humano sobre como interpretar ou estender regras existentes."}, {"letter": "D", "text": "Uma mensagem do cliente contém tanto uma questão de cobrança quanto uma devolução. O agente deve escalar para que um humano coordene ambas em uma única interação.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.2", "objective": "Design effective escalation and ambiguity resolution patterns", "group": "C"}, {"id": "g53", "domain": 1, "scenario": "Agente de Suporte ao Cliente", "situation": "Métricas de produção mostram que seu agente faz em média 4+ loops de API por resolução. A análise revela que Claude frequentemente solicita `get_customer` e `lookup_order` em turnos sequenciais separados, mesmo quando ambos são necessários inicialmente. Qual é a forma mais efetiva de reduzir o número de loops?", "question": "Qual é a forma mais efetiva de reduzir loops?", "options": [{"letter": "A", "text": "Implementar execução especulativa que automaticamente chama ferramentas provavelmente necessárias em paralelo a qualquer ferramenta solicitada e retorna todos os resultados, independentemente do que foi pedido.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Aumentar `max_tokens` para dar a Claude mais espaço para planejar e combinar naturalmente solicitações de ferramenta.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Criar ferramentas compostas como `get_customer_with_orders` que agrupam combinações comuns de lookup em uma única chamada.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Instruir Claude no prompt a agrupar solicitações de ferramenta em um turno e retornar todos os resultados juntos antes da próxima chamada de API.", "correct": true, "explanation": "Pedir a Claude que agrupe solicitações de ferramenta relacionadas em um único turno aproveita sua capacidade nativa de pedir múltiplas ferramentas de uma vez. Corrige diretamente o padrão de chamadas sequenciais com mudança arquitetural mínima."}], "correct": "D", "task_id": "1.1", "objective": "Design and implement agentic loops for autonomous task execution", "group": "A"}, {"id": "g58", "domain": 1, "scenario": "Agente de Suporte ao Cliente", "situation": "Você está implementando o loop do agente de suporte. Após cada chamada de API ao Claude, é preciso decidir se continua o loop (executa as ferramentas pedidas e chama Claude novamente) ou para (apresenta a resposta final ao cliente). O que determina essa decisão?", "question": "O que determina essa decisão?", "options": [{"letter": "A", "text": "Verificar o campo `stop_reason` na resposta do Claude — continuar se for `tool_use` e parar se for `end_turn`.", "correct": true, "explanation": "`stop_reason` é o sinal estruturado explícito do Claude para controle de loop: `tool_use` indica que Claude quer rodar uma ferramenta e receber resultados de volta, enquanto `end_turn` indica que Claude completou sua resposta e o loop deve encerrar."}, {"letter": "B", "text": "Parsear o texto do Claude por frases como \"Estou pronto\" ou \"Posso ajudar com mais alguma coisa?\" — sinais de linguagem natural indicam conclusão.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Definir um número máximo de iterações (ex.: 10 chamadas) e parar quando atingido, independentemente de Claude indicar mais trabalho.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Verificar se a resposta contém conteúdo de texto do assistente — se Claude gerou texto explicativo, o loop deve terminar.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "1.1", "objective": "Design and implement agentic loops for autonomous task execution", "group": "A"}, {"id": "m1", "domain": 1, "scenario": null, "situation": "Seu pipeline de pesquisa multiagente falhou após processar 12 de 28 documentos. O agente de busca na web havia identificado fontes relevantes, o agente de análise de documentos havia concluído parcialmente a extração e o sintetizador havia iniciado a identificação de padrões. Você precisa retomar o processamento sem repetir trabalho nem perder a fidelidade das descobertas anteriores.", "question": "Qual abordagem de gerenciamento de estado equilibra melhor a fidelidade das informações com a eficiência da janela de contexto ao restaurar o estado dos agentes?", "options": [{"letter": "A", "text": "Fazer com que cada agente mantenha seu próprio arquivo de estado persistente e o recarregue de forma independente no início de cada sessão.", "correct": false, "explanation": "Estado fragmentado por agente quebra a visibilidade do coordenador e torna o raciocínio entre agentes frágil. Cada agente recarregando estado interno não relacionado também sobrecarrega seu contexto com ruído de que não precisa."}, {"letter": "B", "text": "Persistir o log de conversa do coordenador contendo todas as delegações de tarefas e respostas, fornecendo-o aos agentes na retomada.", "correct": false, "explanation": "Um log de conversa completo é a opção de maior fidelidade, mas a menos eficiente em contexto. Você reproduziria tudo em cada subagente e estouraria os orçamentos de contexto."}, {"letter": "C", "text": "Fazer com que cada agente persista um relatório estruturado em um local conhecido. Na retomada, o coordenador carrega os relatórios e injeta o estado relevante nos prompts dos agentes.", "correct": true, "explanation": "Correto. Relatórios estruturados por agente mantêm a fidelidade (as descobertas, com esquema), permitem que o coordenador permaneça no comando da orquestração e mantêm o contexto de cada subagente focado. Este é o padrão de coordenador + artefato compacto."}, {"letter": "D", "text": "Indexar todas as saídas dos agentes em um armazenamento vetorial compartilhado. Ao retomar, cada agente consulta o armazenamento usando busca semântica para recuperar descobertas anteriores relevantes.", "correct": false, "explanation": "A recuperação semântica sobre as saídas dos agentes é exagero para retomar um pipeline que falhou — adiciona um modo de falha de recuperação e pode perder o estado preciso que um relatório estruturado preserva exatamente."}], "correct": "C", "task_id": "1.7", "objective": "Manage session state, resumption, and forking", "group": "A"}, {"id": "m2", "domain": 1, "scenario": null, "situation": "Depois que o agente de busca na web encontra 25 fontes (120 mil tokens de conteúdo bruto), o agente de análise de documentos extrai os principais insights (15 mil tokens) e o agente de síntese produz um rascunho de narrativa coerente (3 mil tokens), o coordenador deve passar o contexto para o agente de geração de relatórios para a saída final com as devidas citações de fonte.", "question": "Qual estratégia de passagem de contexto oferece o melhor equilíbrio entre completude e eficiência?", "options": [{"letter": "A", "text": "Passar apenas o rascunho de síntese e ter um pipeline de pós-processamento separado para associar afirmações às fontes e inserir citações depois que o relatório for gerado.", "correct": false, "explanation": "A associação posterior é frágil — sem o mapeamento que o modelo usou, você não consegue vincular afirmações à fonte correta de forma confiável. Citações alucinadas ou mal atribuídas são o modo de falha habitual."}, {"letter": "B", "text": "Passar o rascunho de síntese junto com um índice de fontes estruturado que mapeia as principais afirmações às URLs de suas fontes e aos trechos relevantes.", "correct": true, "explanation": "Correto. A síntese fornece a narrativa; o índice de fontes dá ao gerador de relatórios exatamente o vínculo de que ele precisa para citar sem reler 120 mil tokens de conteúdo bruto."}, {"letter": "C", "text": "Passar um resumo condensado de todas as etapas anteriores que preserva as principais descobertas e as atribui às fontes apenas pelo nome.", "correct": false, "explanation": "A atribuição apenas por nome perde URLs e trechos, então o gerador de relatórios não consegue citar nem verificar — e 'apenas por nome' tende a derivar para citações vagas."}, {"letter": "D", "text": "Passar todo o contexto acumulado de todos os agentes anteriores.", "correct": false, "explanation": "Completude máxima, mas perdulária — mais de 120 mil tokens de conteúdo bruto de busca são, em sua maioria, ruído irrelevante na etapa de geração de relatórios."}], "correct": "B", "task_id": "1.4", "objective": "Implement multi-step workflows with enforcement and handoff patterns", "group": "A"}, {"id": "m4", "domain": 1, "scenario": null, "situation": "O agente de busca na web reuniu várias fontes relevantes para um tópico de pesquisa. O agente de análise de documentos agora precisa examinar essas fontes.", "question": "Como as informações normalmente fluem entre esses dois subagentes especializados?", "options": [{"letter": "A", "text": "Os agentes se comunicam por meio de uma fila de mensagens orientada a eventos, com o agente de análise de documentos assinando os eventos de conclusão da busca na web.", "correct": false, "explanation": "Barramentos de eventos não fazem parte do modelo de subagentes do Claude. Os subagentes não publicam nem assinam uns aos outros diretamente."}, {"letter": "B", "text": "O agente de busca na web invoca diretamente o agente de análise de documentos, passando as fontes descobertas como parâmetros.", "correct": false, "explanation": "Os subagentes são isolados — eles não conseguem chamar diretamente subagentes irmãos. Isso também os acoplaria fortemente e anularia o padrão de coordenador."}, {"letter": "C", "text": "O agente coordenador recebe a saída do agente de busca na web e inclui as descobertas relevantes no prompt ao invocar o agente de análise de documentos.", "correct": true, "explanation": "Correto. Em um padrão coordenador-trabalhador, o coordenador é o hub. Ele coleta a saída de cada subagente e encaminha explicitamente as partes relevantes para o prompt do próximo subagente."}, {"letter": "D", "text": "Ambos os agentes acessam um armazenamento de memória compartilhado, onde o agente de busca na web grava as descobertas e o agente de análise de documentos as lê.", "correct": false, "explanation": "Um armazenamento compartilhado pode ser adicionado como otimização, mas não é assim que os subagentes normalmente se comunicam — e ele introduz problemas de leituras desatualizadas e de consistência."}], "correct": "C", "task_id": "1.2", "objective": "Orchestrate multi-agent systems with coordinator-subagent patterns", "group": "A"}, {"id": "m5", "domain": 1, "scenario": null, "situation": "Em produção, você observa que consultas simples de verificação de fatos (por exemplo, \"Em que ano o Acordo de Paris sobre o Clima foi assinado?\") percorrem todos os quatro subagentes sequencialmente, consumindo mais de 40 segundos e tokens significativos por consulta. Pesquisas comparativas complexas se beneficiam do pipeline completo. Sua distribuição de consultas é diversa e está evoluindo à medida que os usuários descobrem novas aplicações.", "question": "Qual é a abordagem mais eficaz para otimizar para variações de complexidade das consultas?", "options": [{"letter": "A", "text": "Implementar roteamento baseado em padrões que categoriza as consultas por estrutura (fato único vs. comparativa vs. analítica) e mapeia cada categoria para uma combinação predefinida de subagentes.", "correct": false, "explanation": "O roteamento por padrões se cristaliza à medida que a distribuição de consultas evolui — novas intenções quebram os padrões e caem silenciosamente no pipeline errado."}, {"letter": "B", "text": "Criar um caminho rápido para perguntas factuais que ignora completamente os subagentes, roteando todas as outras consultas pelo pipeline completo para garantir a profundidade da pesquisa.", "correct": false, "explanation": "Um caminho rápido binário resolve o pior caso, mas desperdiça o pipeline completo em toda consulta moderadamente complexa que poderia ter usado um subconjunto."}, {"letter": "C", "text": "Fazer com que o coordenador analise cada consulta e decida dinamicamente quais subagentes invocar com base em sua avaliação dos requisitos da consulta.", "correct": true, "explanation": "Correto. Permitir que o LLM coordenador raciocine sobre cada consulta e escolha apenas os subagentes de que precisa se adapta naturalmente a uma distribuição de consultas diversa e em evolução — esta é a força do padrão de coordenador."}, {"letter": "D", "text": "Treinar um classificador de complexidade de consultas com dados históricos rotulados para prever as combinações ideais de subagentes, retreinando periodicamente à medida que os padrões de consulta evoluem.", "correct": false, "explanation": "Um classificador treinado precisa de rótulos, retreinamento e monitoramento de desvio. Isso é sobre-engenharia quando o coordenador pode tomar a mesma decisão em tempo de execução a partir da própria consulta."}], "correct": "C", "task_id": "1.2", "objective": "Orchestrate multi-agent systems with coordinator-subagent patterns", "group": "A"}, {"id": "m6", "domain": 1, "scenario": null, "situation": "Ao pesquisar \"adoção de energia renovável\", o agente de busca na web retorna estatísticas recentes (2024: 35% de adoção), enquanto o agente de análise de documentos extrai dados de relatórios internos (2022: 18% de adoção). O agente de síntese sinaliza incorretamente essas fontes como contraditórias, em vez de reconhecer que os dados mostram crescimento ao longo do tempo.", "question": "Qual mudança permitiria melhor que o agente de síntese interpretasse corretamente essas diferenças temporais?", "options": [{"letter": "A", "text": "Exigir que os subagentes incluam as datas de publicação ou de coleta de dados em suas saídas estruturadas.", "correct": true, "explanation": "Correto. O agente de síntese interpreta mal os dados porque nunca vê as datas. Fazer com que cada ponto de dado carregue seu próprio carimbo de data na saída estruturada permite que a síntese raciocine sobre tendências em vez de contradições."}, {"letter": "B", "text": "Adicionar um agente de resolução de conflitos que descarta automaticamente os dados mais antigos quando existem dados mais recentes para a mesma métrica.", "correct": false, "explanation": "Descartar silenciosamente dados mais antigos destrói as informações de tendência — exatamente aquilo que a pergunta está abordando."}, {"letter": "C", "text": "Configurar o agente de busca na web para retornar apenas resultados dos últimos 6 meses.", "correct": false, "explanation": "Reduzir a janela descarta o contexto histórico e não corrige a lacuna arquitetural de que os metadados não estão sendo passados para a síntese."}, {"letter": "D", "text": "Instruir o agente de síntese a sempre tratar os dados mais recentes como autoritativos e colocar as descobertas mais antigas em um apêndice histórico separado.", "correct": false, "explanation": "Instruções de prompt sozinhas não são confiáveis e ainda escondem o raciocínio temporal por trás de uma regra. Estruturar os dados com datas é a correção sistemática."}], "correct": "A", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "m7", "domain": 1, "scenario": null, "situation": "O agente de síntese recebe descobertas resumidas dos agentes de busca na web e de análise de documentos e, em seguida, passa um resumo consolidado para o gerador de relatórios. Durante os testes, você descobre que os relatórios gerados fazem afirmações factuais sem as devidas citações — o gerador de relatórios não consegue atribuir as declarações às suas fontes originais porque esses metadados foram perdidos durante as etapas de resumo.", "question": "Qual é a abordagem mais eficaz para garantir a atribuição correta de fontes nos relatórios finais?", "options": [{"letter": "A", "text": "Fazer com que cada agente produza dados estruturados que separem os resumos de conteúdo dos metadados de fonte (URLs, nomes de documentos, números de página).", "correct": true, "explanation": "Correto. Conteúdo estruturado + metadados de fonte separados preservam o mapeamento de ponta a ponta, de modo que o gerador de relatórios recebe tanto o que foi dito quanto de onde veio."}, {"letter": "B", "text": "Fazer com que o gerador de relatórios consulte o agente de busca na web para relocalizar as fontes das afirmações no relatório final.", "correct": false, "explanation": "Reconsultar é lento, com perdas e propenso a má atribuição — o agente de busca na web não sabe qual afirmação veio de qual fonte."}, {"letter": "C", "text": "Instruir o agente de síntese a incorporar referências de fonte em linha no texto do resumo usando um formato de citação consistente.", "correct": false, "explanation": "Citações em linha em texto livre se deslocam e são descartadas durante resumos posteriores. Metadados estruturados sobrevivem melhor às transformações."}, {"letter": "D", "text": "Pular o resumo e passar as saídas brutas completas da busca na web e da análise de documentos diretamente para o gerador de relatórios.", "correct": false, "explanation": "Você estouraria o orçamento de contexto e tornaria o trabalho do gerador de relatórios mais difícil. O resumo é útil; perder os metadados durante o resumo é o verdadeiro bug."}], "correct": "A", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "m9", "domain": 1, "scenario": null, "situation": "Em produção, os relatórios finais frequentemente contêm afirmações sem a devida atribuição de fonte. A investigação mostra que, embora os agentes de busca na web e de análise de documentos anexem corretamente as citações às suas saídas, o agente de síntese perde o controle de quais fontes sustentam quais conclusões ao combinar as descobertas.", "question": "Qual é a mudança arquitetural mais eficaz?", "options": [{"letter": "A", "text": "Manter transcrições completas de todas as interações dos subagentes e adicionar um agente de resolução de citações para analisar os logs e determinar as atribuições antes da geração do relatório.", "correct": false, "explanation": "A análise posterior de logs é frágil e cara — e ainda perde os vínculos quando a síntese mescla pontos de várias fontes."}, {"letter": "B", "text": "Exigir que todos os subagentes produzam mapeamentos estruturados de afirmação-fonte que o agente de síntese deve preservar e mesclar ao combinar descobertas de várias fontes.", "correct": true, "explanation": "Correto. Mapeamentos explícitos de afirmação-fonte são uma saída de primeira classe que o agente de síntese pode mesclar de forma determinística — nenhuma atribuição é descartada durante o resumo."}, {"letter": "C", "text": "Adicionar uma etapa de verificação em que o gerador de relatórios usa correspondência por similaridade semântica com as fontes originais para reconstruir quais afirmações vieram de quais documentos.", "correct": false, "explanation": "A busca por similaridade pode atribuir a fonte errada quando duas fontes dizem coisas parecidas. Você quer o mapeamento original do modelo, não uma reconstrução."}, {"letter": "D", "text": "Fazer com que o coordenador injete prefixos de identificador de fonte no texto antes de cada transferência e, em seguida, analise esses prefixos na geração do relatório para reconstruir as citações.", "correct": false, "explanation": "Tokens de prefixo dentro da prosa são descartados, parafraseados ou alucinados. Mapeamentos estruturados fora da prosa são mais robustos."}], "correct": "B", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "m10", "domain": 1, "scenario": null, "situation": "Depois que o agente de busca na web e o agente de análise de documentos concluem suas tarefas, o coordenador invoca o agente de síntese. No entanto, o agente de síntese responde que não consegue concluir a tarefa porque nenhuma descoberta de pesquisa foi fornecida.", "question": "Qual é a causa mais provável desse problema?", "options": [{"letter": "A", "text": "A janela de contexto do agente de síntese não é grande o suficiente para conter as saídas combinadas dos dois agentes anteriores.", "correct": false, "explanation": "Um estouro da janela de contexto normalmente se manifesta como truncamento ou erro de API, não como o agente dizendo 'nenhuma descoberta fornecida'."}, {"letter": "B", "text": "O coordenador não incluiu as saídas dos agentes anteriores no prompt do agente de síntese.", "correct": true, "explanation": "Correto. As invocações de subagentes são isoladas — nada flui entre eles a menos que o coordenador coloque explicitamente no prompt. A mensagem 'nenhuma descoberta fornecida' é exatamente o que você veria."}, {"letter": "C", "text": "Os subagentes precisam compartilhar uma única conexão de API para permitir o compartilhamento automático de contexto entre as invocações.", "correct": false, "explanation": "Não existe 'compartilhamento automático de contexto' sobre uma conexão compartilhada. O isolamento de contexto é intencional."}, {"letter": "D", "text": "O agente de síntese precisa de ferramentas que possam buscar resultados diretamente dos históricos de conversa dos outros agentes.", "correct": false, "explanation": "Buscar o histórico entre agentes não é uma capacidade padrão e não é a correção certa — o coordenador deveria estar encaminhando as descobertas explicitamente."}], "correct": "B", "task_id": "1.3", "objective": "Configure subagent invocation, context passing, and spawning", "group": "B"}, {"id": "m12", "domain": 1, "scenario": null, "situation": "O coordenador fornece instruções detalhadas passo a passo ao subagente de busca na web, especificando consultas de busca exatas, prioridades de fontes e filtros de data. O monitoramento em produção revela três problemas: (1) o subagente relata \"resultados insuficientes\" em vez de tentar abordagens alternativas quando as buscas pré-especificadas falham, (2) a qualidade da pesquisa cai para tópicos emergentes que não correspondem aos padrões esperados e (3) o subagente raramente traz à tona fontes tangenciais valiosas.", "question": "Qual é a forma mais eficaz de melhorar a adaptabilidade do subagente?", "options": [{"letter": "A", "text": "Remover completamente os detalhes procedurais, delegando com metas simples como \"pesquise X minuciosamente\" e contando com as capacidades gerais do subagente.", "correct": false, "explanation": "Longe demais na direção oposta — 'pesquise X minuciosamente' perde as proteções (qualidade da fonte, atualidade) que tornam a delegação confiável."}, {"letter": "B", "text": "Adicionar diretivas explícitas de contingência às instruções detalhadas: \"Se as buscas especificadas retornarem menos de N resultados, tente formulações de consulta alternativas antes de relatar falha.\"", "correct": false, "explanation": "Remenda um modo de falha, mas mantém o agente preso ao pensamento procedural — ainda frágil para tópicos emergentes e fontes tangenciais."}, {"letter": "C", "text": "Implementar uma etapa de classificação de tópicos em que o coordenador categoriza as solicitações como \"bem definidas\" ou \"exploratórias\" e usa estilos de instrução diferentes para cada categoria.", "correct": false, "explanation": "Um classificador com dois grupos é frágil, e você ainda envia instruções rígidas no ramo bem definido."}, {"letter": "D", "text": "Especificar metas de pesquisa e critérios de qualidade (amplitude de cobertura, diversidade de fontes, atualidade) em vez de etapas procedurais, deixando que o subagente determine sua estratégia de busca.", "correct": true, "explanation": "Correto. Delegue intenção e parâmetros de qualidade, não procedimentos. O subagente pode então escolher consultas, seguir tangentes promissoras e se recuperar de becos sem saída por conta própria."}], "correct": "D", "task_id": "1.3", "objective": "Configure subagent invocation, context passing, and spawning", "group": "B"}, {"id": "m13", "domain": 1, "scenario": null, "situation": "O monitoramento em produção mostra que consultas de acompanhamento como \"resuma o que aprendemos sobre tendências de mercado\" levam consistentemente mais de 40 segundos. A investigação revela que o coordenador inicia o subagente de síntese para cada solicitação de resumo, passando mais de 80 mil tokens de descobertas acumuladas. O coordenador já tem essas descobertas em seu contexto por ter orquestrado a pesquisa.", "question": "Qual é a forma mais eficaz de melhorar o tempo de resposta para esses resumos de acompanhamento?", "options": [{"letter": "A", "text": "Pré-gerar e armazenar em cache resumos em várias granularidades sempre que novas descobertas se acumulem.", "correct": false, "explanation": "A geração especulativa desperdiça tokens com resumos que o usuário pode nunca pedir, e as granularidades em cache nunca correspondem exatamente ao que é solicitado."}, {"letter": "B", "text": "Fazer com que o coordenador trate diretamente as solicitações de resumo simples usando seu contexto existente, reservando o início de subagentes para análises complexas.", "correct": true, "explanation": "Correto. Se o coordenador já tem as descobertas, iniciar um subagente para reingerir 80 mil tokens é puro custo adicional. Deixe o coordenador responder a acompanhamentos simples por conta própria."}, {"letter": "C", "text": "Habilitar o cache de prompt no subagente de síntese para reduzir o custo adicional de transferir repetidamente as mesmas descobertas de pesquisa.", "correct": false, "explanation": "O cache de prompt reduz o custo no prefixo repetido, mas o desperdício arquitetural — iniciar um subagente inteiro para um resumo — permanece."}, {"letter": "D", "text": "Iniciar o subagente de síntese com contexto reduzido e fazer com que ele solicite descobertas específicas ao coordenador sob demanda.", "correct": false, "explanation": "Adiciona idas e voltas e complexidade para o mesmo resultado que o coordenador poderia produzir diretamente."}], "correct": "B", "task_id": "1.2", "objective": "Orchestrate multi-agent systems with coordinator-subagent patterns", "group": "A"}, {"id": "m14", "domain": 1, "scenario": null, "situation": "Ao analisar casos jurídicos complexos que citam vários precedentes, o subagente de análise de documentos processa cada um sequencialmente. Um caso paradigmático que cita 12 precedentes leva mais de 3 minutos para ser analisado completamente.", "question": "Qual é a forma mais eficaz de reduzir essa latência, preservando a capacidade do coordenador de monitorar e depurar o sistema?", "options": [{"letter": "A", "text": "Implementar uma fila de mensagens em que as tarefas de análise de precedentes são processadas de forma assíncrona por um pool de agentes trabalhadores.", "correct": false, "explanation": "Filas externas complicam a observabilidade — o coordenador perde a visibilidade direta de quais tarefas tiveram êxito e o que produziram."}, {"letter": "B", "text": "Criar uma hierarquia recursiva de agentes em que os agentes de análise subdividem o trabalho entre agentes filhos até atingir a granularidade de um único precedente.", "correct": false, "explanation": "A recursão adiciona níveis de indireção que dificultam a depuração e o monitoramento, sem ganho real de velocidade além da primeira distribuição."}, {"letter": "C", "text": "Fazer com que o coordenador inicie subagentes de análise de documentos em paralelo, cada um tratando um subconjunto de precedentes, e depois agregue os resultados antes da síntese.", "correct": true, "explanation": "Correto. O paralelismo gerenciado pelo coordenador distribui o trabalho, mantém o escopo de cada subagente restrito e preserva um único hub para monitoramento e agregação."}, {"letter": "D", "text": "Permitir que o subagente de análise de documentos inicie seus próprios subagentes especializados dinamicamente quando encontrar casos com muitas citações.", "correct": false, "explanation": "O início aninhado esconde a execução dentro dos subagentes e torna a visão de depuração do coordenador incompleta."}], "correct": "C", "task_id": "1.2", "objective": "Orchestrate multi-agent systems with coordinator-subagent patterns", "group": "A"}, {"id": "m15", "domain": 1, "scenario": null, "situation": "O agente coordenador tem `AgentDefinitions` configuradas para todos os quatro subagentes especializados, cada um com descrições, prompts e restrições de ferramentas apropriadas. Durante os testes, você percebe que o coordenador raciocina corretamente sobre quando delegar — ele gera mensagens como \"Vou pedir ao agente de busca na web que encontre fontes sobre este tópico\" — mas nenhuma execução de subagente jamais ocorre. O coordenador então prossegue como se a delegação tivesse acontecido e continua com informações incompletas. Os logs não mostram erros.", "question": "Qual é a causa mais provável?", "options": [{"letter": "A", "text": "A configuração `max_tokens` do coordenador é baixa demais, fazendo com que a invocação da ferramenta Task seja truncada antes que o parâmetro de tipo do subagente possa ser especificado.", "correct": false, "explanation": "Um truncamento apareceria nos logs e normalmente deixaria blocos `tool_use` parciais — não no-ops silenciosos."}, {"letter": "B", "text": "As `AgentDefinitions` estão configuradas corretamente, mas o prompt de sistema do coordenador não lista explicitamente os tipos de subagentes disponíveis, impedindo que o modelo saiba que eles podem ser invocados.", "correct": false, "explanation": "Os esquemas de ferramentas/agentes são apresentados ao modelo automaticamente — você não precisa relistá-los no prompt de sistema para que o modelo os veja."}, {"letter": "C", "text": "A configuração allowedTools do coordenador não inclui \"Task\", então, embora ele possa raciocinar sobre a delegação, não consegue invocar a ferramenta necessária para iniciar subagentes.", "correct": true, "explanation": "Correto. Sem a ferramenta Task em allowedTools, o coordenador pode falar sobre delegar, mas não tem como realmente chamar um subagente — o que corresponde ao sintoma 'raciocina sobre isso, sem execução, sem erros'."}, {"letter": "D", "text": "O isolamento de contexto dos subagentes significa que as descrições de tarefa do coordenador não chegam automaticamente aos subagentes; você precisa configurar o encaminhamento explícito de contexto em ClaudeAgentOptions.", "correct": false, "explanation": "O isolamento de contexto é real, mas afeta o que o subagente vê uma vez iniciado — não se o coordenador consegue iniciá-lo."}], "correct": "C", "task_id": "1.3", "objective": "Configure subagent invocation, context passing, and spawning", "group": "B"}, {"id": "m21", "domain": 1, "scenario": null, "situation": "Sua ferramenta de exploração de base de código armazena IDs de sessão para permitir que os engenheiros continuem investigações entre sessões de trabalho. Um engenheiro passou uma hora ontem analisando um módulo de autenticação legado, acumulando contexto sobre sua arquitetura e dependências. Ele quer continuar hoje. O ID da sessão é válido, mas o controle de versão mostra que 3 dos 12 arquivos que o agente leu anteriormente foram modificados durante a noite pelo merge de um colega.", "question": "Qual abordagem melhor equilibra eficiência e precisão?", "options": [{"letter": "A", "text": "Retomar a sessão sem informar o agente sobre os arquivos alterados", "correct": false, "explanation": "Retomar silenciosamente deixa o agente raciocinando sobre conteúdo desatualizado em 3 dos 12 arquivos — exatamente a origem de recomendações ruins."}, {"letter": "B", "text": "Iniciar uma nova sessão para garantir que o agente trabalhe com o estado atual da base de código sem suposições desatualizadas", "correct": false, "explanation": "Joga fora uma hora de contexto válido sobre os 9 arquivos que não mudaram."}, {"letter": "C", "text": "Retomar a sessão e informar o agente sobre quais arquivos específicos mudaram para uma reanálise direcionada", "correct": true, "explanation": "Correto. Mantém o contexto custoso que você já construiu, ao mesmo tempo em que diz ao agente exatamente quais 3 arquivos reler — desperdício mínimo, precisão máxima."}, {"letter": "D", "text": "Retomar a sessão e imediatamente fazer o agente reler todos os 12 arquivos previamente analisados", "correct": false, "explanation": "Desnecessário para os 9 arquivos inalterados. Apenas adiciona tokens sem melhorar a precisão."}], "correct": "C", "task_id": "1.7", "objective": "Manage session state, resumption, and forking", "group": "A"}, {"id": "m22", "domain": 1, "scenario": null, "situation": "Um engenheiro usou o agente ontem para analisar um módulo de autenticação legado, identificando duas abordagens distintas de refatoração: extrair um microsserviço versus refatorar no local. Hoje, ele quer explorar ambas as abordagens em profundidade — fazendo o agente propor mudanças de código específicas para cada uma — antes de decidir qual implementar.", "question": "Qual é a maneira mais eficaz de estruturar essa exploração?", "options": [{"letter": "A", "text": "Retomar a sessão de ontem para explorar a primeira abordagem e, então, iniciar uma nova sessão para a segunda, recriando manualmente o contexto original.", "correct": false, "explanation": "A recriação manual é propensa a erros e perde o estado de trabalho exato da análise de ontem."}, {"letter": "B", "text": "Iniciar duas sessões novas, fornecendo manualmente um resumo das descobertas da análise de ontem para estabelecer o contexto.", "correct": false, "explanation": "Refaz o trabalho e arrisca que as duas sessões divirjam da mesma linha de base que você estabeleceu ontem."}, {"letter": "C", "text": "Retomar a sessão de ontem e explorar ambas as abordagens sequencialmente dentro da mesma thread de conversa.", "correct": false, "explanation": "A exploração sequencial em uma única thread permite que cada abordagem contamine o contexto da outra."}, {"letter": "D", "text": "Usar `fork_session` para criar duas ramificações a partir da análise de ontem, explorando uma abordagem em cada ramificação.", "correct": true, "explanation": "Correto. Ramificar a partir da sessão de ontem dá a cada abordagem seu próprio contexto independente, partindo da mesma linha de base de análise — limpo, paralelo, sem contaminação."}], "correct": "D", "task_id": "1.7", "objective": "Manage session state, resumption, and forking", "group": "A"}, {"id": "m24", "domain": 1, "scenario": null, "situation": "Um engenheiro pede ao seu agente para identificar caminhos de código não testados em um módulo legado de processamento de pagamentos que abrange 45 arquivos. Após ler os primeiros 8 arquivos-fonte, as respostas do agente estão ficando visivelmente menos precisas — ele está esquecendo padrões de código discutidos anteriormente e ainda não localizou todos os arquivos de teste nem rastreou os fluxos de pagamento críticos.", "question": "Qual é a abordagem mais eficaz para concluir essa investigação?", "options": [{"letter": "A", "text": "Documentar todas as descobertas atuais em um relatório de resumo, limpar o contexto completamente e, então, usar esse relatório como única referência para continuar a investigação.", "correct": false, "explanation": "Um único relatório torna-se a única fonte de verdade e tende a comprimir e descartar os padrões de código específicos que você precisaria depois."}, {"letter": "B", "text": "Criar subagentes para investigar perguntas específicas (por exemplo, \"encontrar todos os arquivos de teste do processamento de pagamentos\", \"rastrear as dependências do fluxo de reembolso\") enquanto o agente principal coordena as descobertas e preserva o entendimento de alto nível.", "correct": true, "explanation": "Correto. Delegue investigações bem delimitadas a subagentes com contexto novo, enquanto o agente principal mantém a visão arquitetural geral. Este é o padrão para escalar a exploração além de uma única janela de contexto."}, {"letter": "C", "text": "Limpar o contexto com /clear e, então, reler seletivamente apenas os arquivos mais críticos descobertos até agora, gravando as descobertas-chave em um arquivo de rascunho que persiste entre as redefinições de contexto.", "correct": false, "explanation": "Arquivos de rascunho ajudam, mas limpar + reler descarta o entendimento que você já construiu ao longo de 8 arquivos."}, {"letter": "D", "text": "Passar a usar o Grep para buscar nomes de funções específicas em vez de ler arquivos inteiros, reduzindo o conteúdo carregado no contexto para a exploração restante.", "correct": false, "explanation": "Você não consegue identificar caminhos não testados apenas fazendo grep de nomes — é preciso ler o suficiente de cada caminho para saber quais ramificações os testes não cobrem."}], "correct": "B", "task_id": "5.4", "objective": "Manage context effectively in large codebase exploration", "group": "G"}, {"id": "m25", "domain": 1, "scenario": null, "situation": "Um desenvolvedor pede ao agente para investigar por que um endpoint de API específico retorna erros 500 de forma intermitente. A base de código tem mais de 200 arquivos e o desenvolvedor não sabe quais componentes estão envolvidos. O agente precisa rastrear o erro pelas camadas de roteamento, middleware, lógica de negócio e banco de dados.", "question": "Qual abordagem de decomposição de tarefas seria mais eficaz?", "options": [{"letter": "A", "text": "Fazer o agente primeiro criar um plano abrangente mapeando todos os caminhos de código pelo endpoint antes de iniciar qualquer exploração de arquivos ou leitura de código.", "correct": false, "explanation": "Você não consegue construir um plano correto para um erro desconhecido sem nenhuma exploração. Planejar às cegas desperdiça tempo e ignora o caminho real da falha."}, {"letter": "B", "text": "Fazer o agente gerar dinamicamente subtarefas de investigação com base no que descobre a cada passo, adaptando seu plano de exploração à medida que novas informações sobre o caminho do erro surgem.", "correct": true, "explanation": "Correto. A depuração é adaptativa por natureza — cada arquivo que você lê muda qual é o próximo passo mais útil. Deixe o agente seguir as evidências."}, {"letter": "C", "text": "Definir antecipadamente uma sequência fixa de passos de investigação — fazer grep de padrões de erro, depois ler os tratadores de erro, depois verificar as consultas ao banco de dados, depois examinar o middleware — executando cada passo independentemente das descobertas intermediárias.", "correct": false, "explanation": "Um pipeline fixo desperdiça trabalho em camadas que não estão envolvidas e pode impedir o agente de chegar ao caminho real da causa raiz."}, {"letter": "D", "text": "Executar agentes de trabalho paralelos que investigam simultaneamente todas as quatro camadas e, então, sintetizar suas descobertas para identificar onde o erro se origina.", "correct": false, "explanation": "A divisão em paralelo é útil quando você já tem subtarefas bem delimitadas. Aqui você não tem — você pagaria 4× o custo para olhar em três camadas que não são o problema."}], "correct": "B", "task_id": "1.6", "objective": "Design task decomposition strategies for complex workflows", "group": "A"}, {"id": "m26", "domain": 1, "scenario": null, "situation": "O subagente de exploração de um engenheiro passou 30 minutos analisando um sistema de pagamentos legado, lendo 47 arquivos e documentando os fluxos de dados. A sessão foi interrompida quando a conexão do engenheiro caiu. Enquanto ele estava ausente, um colega fez o merge de um PR que renomeou duas funções utilitárias. O engenheiro quer continuar a mesma exploração.", "question": "Qual é a abordagem mais eficaz?", "options": [{"letter": "A", "text": "Retomar o subagente a partir de sua transcrição anterior sem mencionar as mudanças — o entendimento da arquitetura continua válido.", "correct": false, "explanation": "Retomar silenciosamente faz com que o agente continue referenciando os nomes antigos das funções em suas recomendações."}, {"letter": "B", "text": "Iniciar um subagente novo e incluir a transcrição anterior no prompt inicial para fornecer contexto.", "correct": false, "explanation": "Carregar 30 minutos de transcrição no prompt de um novo subagente é um desperdício e polui seu contexto inicial."}, {"letter": "C", "text": "Iniciar um subagente novo com um resumo das descobertas anteriores.", "correct": false, "explanation": "Refazer o resumo descarta os fluxos de dados detalhados que o agente já estava rastreando ao longo de 47 arquivos."}, {"letter": "D", "text": "Retomar o subagente a partir de sua transcrição anterior e informá-lo sobre as funções renomeadas.", "correct": true, "explanation": "Correto. Mantenha o entendimento acumulado e dê a ele um delta direcionado sobre as renomeações para que possa atualizar seu modelo mental — desperdício mínimo, precisão máxima."}], "correct": "D", "task_id": "1.7", "objective": "Manage session state, resumption, and forking", "group": "A"}, {"id": "m28", "domain": 1, "scenario": null, "situation": "Seu agente analisou um módulo de serviço complexo — lendo 23 arquivos-fonte, rastreando fluxos de requisição e identificando padrões de tratamento de erros. Um desenvolvedor quer comparar duas estratégias de teste antes de se comprometer com uma: testes ponta a ponta com serviços externos simulados (mocked) versus testes de snapshot que capturam as saídas esperadas. Ele precisa desenvolver ambas as abordagens de forma independente para avaliar os trade-offs.", "question": "Como você deve gerenciar as sessões?", "options": [{"letter": "A", "text": "Exportar as descobertas principais da sessão de análise para um arquivo e, então, criar duas novas sessões que referenciem esse arquivo.", "correct": false, "explanation": "Um resumo exportado perde mais informação do que o estado vivo da sessão que o agente construiu enquanto lia 23 arquivos."}, {"letter": "B", "text": "Retomar a sessão de análise com `fork_session` habilitado, criando uma ramificação separada para cada estratégia de teste.", "correct": true, "explanation": "Correto. Ramificar dá a cada estratégia seu próprio contexto independente, partindo exatamente da linha de base da análise — sem contaminação cruzada, sem reanálise."}, {"letter": "C", "text": "Iniciar duas sessões novas, fazendo cada uma reler os arquivos-fonte relevantes antes de começar.", "correct": false, "explanation": "Queima tokens refazendo um trabalho que a sessão original já fez e arrisca que cada sessão nova chegue a conclusões diferentes a partir do mesmo código."}, {"letter": "D", "text": "Continuar na sessão original, desenvolvendo primeiro os testes ponta a ponta e depois os testes de snapshot, sequencialmente.", "correct": false, "explanation": "O desenvolvimento sequencial em uma única thread permite que a implementação da primeira estratégia enviese o raciocínio sobre a segunda."}], "correct": "B", "task_id": "1.7", "objective": "Manage session state, resumption, and forking", "group": "A"}, {"id": "m30", "domain": 1, "scenario": null, "situation": "Um engenheiro que acabou de entrar na equipe pede ao agente para ajudá-lo a entender a arquitetura de autenticação e autorização antes de fazer melhorias de segurança. A base de código tem mais de 800 arquivos espalhados por múltiplos serviços.", "question": "Qual estratégia de exploração construirá o entendimento de forma mais eficaz, considerando as ferramentas nativas do Claude e os limites de contexto?", "options": [{"letter": "A", "text": "Ler primeiro quaisquer arquivos CLAUDE.md e README e, então, pedir ao engenheiro para especificar quais 10 a 15 arquivos são mais importantes para entender o sistema de autenticação.", "correct": false, "explanation": "O engenheiro acabou de entrar — ele provavelmente não sabe quais arquivos importam. É exatamente nisso que o agente deveria ajudar."}, {"letter": "B", "text": "Iniciar subagentes paralelos para explorar diferentes serviços simultaneamente e, então, sintetizar suas descobertas em uma visão arquitetural geral.", "correct": false, "explanation": "Sem saber onde a autenticação está, a divisão em paralelo explora de forma ampla demais e os subagentes duplicam trabalho e perdem os fluxos entre serviços."}, {"letter": "C", "text": "Usar o Grep para encontrar os pontos de entrada de autenticação, ler esses arquivos e, então, seguir as importações e chamadas de função para mapear o fluxo de autenticação de forma incremental.", "correct": true, "explanation": "Correto. Comece pelos pontos de entrada (login, verificação de token, middleware) e, então, rastreie para fora seguindo as conexões reais do código. Incremental, fundamentado e dentro dos limites de contexto."}, {"letter": "D", "text": "Ler todos os arquivos que contenham \"auth\", \"login\", \"permission\" ou \"token\" em seu conteúdo ou nome de arquivo.", "correct": false, "explanation": "Essas palavras-chave atingem uma enorme quantidade de código não relacionado em mais de 800 arquivos e afogam o contexto em ruído."}], "correct": "C", "task_id": "5.4", "objective": "Manage context effectively in large codebase exploration", "group": "G"}, {"id": "m31", "domain": 1, "scenario": null, "situation": "Um cliente retorna 4 horas após a sessão inicial sobre a mesma disputa de cobrança. A sessão anterior, com 32 turnos, contém resultados de `lookup_order` mostrando \"Status: PENDING, Resolução prevista: 24-48 horas.\" Em testes, você observa que, ao retomar sessões com resultados de ferramentas desatualizados, o agente frequentemente faz referência aos dados obsoletos nas respostas (por exemplo, \"Vejo que seu reembolso ainda está em processamento\"), mesmo após chamadas de ferramentas mais recentes retornarem informações diferentes.", "question": "Qual abordagem lida de forma mais confiável com clientes que retornam?", "options": [{"letter": "A", "text": "Retomar com o histórico completo, mas filtrar as mensagens `tool_result` anteriores antes de retomar, mantendo apenas os turnos do humano/assistente para que o agente precise buscar novamente os dados necessários.", "correct": false, "explanation": "Remover os `tool_results` do meio de uma conversa pode deixar mensagens do assistente referenciando resultados inexistentes — a transcrição se torna internamente inconsistente."}, {"letter": "B", "text": "Iniciar uma nova sessão, injetar um resumo estruturado da interação anterior (tipo de problema, ações tomadas, status de resolução) e fazer novas chamadas de ferramentas antes de iniciar o atendimento.", "correct": true, "explanation": "Correto. Uma sessão limpa com um resumo mantém a continuidade narrativa, ao mesmo tempo em que garante que o agente não esteja raciocinando sobre resultados de ferramentas desatualizados."}, {"letter": "C", "text": "Retomar com o histórico completo e adicionar uma instrução no prompt do sistema dizendo ao agente para sempre preferir os resultados de ferramentas mais recentes quando houver várias chamadas à mesma ferramenta no contexto.", "correct": false, "explanation": "Instruções no prompt são sugestões. Você observou exatamente esse modo de falha nos testes — o modelo ainda faz referência a resultados antigos."}, {"letter": "D", "text": "Retomar com o histórico completo e configurar o agente para chamar novamente, de forma automática, todas as ferramentas usadas anteriormente no início da sessão, garantindo a atualidade dos dados.", "correct": false, "explanation": "Chamar tudo novamente de forma indiscriminada é um desperdício, é lento e ainda deixa os resultados antigos no contexto, confundindo o modelo."}], "correct": "B", "task_id": "1.4", "objective": "Implement multi-step workflows with enforcement and handoff patterns", "group": "A"}, {"id": "m32", "domain": 1, "scenario": null, "situation": "Você está implementando a lógica de escalonamento para quando o agente deve chamar `escalate_to_human`. Sua equipe propõe quatro abordagens diferentes para acionar o escalonamento.", "question": "Qual abordagem identificará de forma mais confiável os casos que genuinamente exigem intervenção humana?", "options": [{"letter": "A", "text": "Instruir o agente a escalonar quando o cliente solicitar um humano, quando o problema exigir exceções de política ou quando o agente não conseguir avançar de forma significativa.", "correct": true, "explanation": "Correto. Decisões de escalonamento são julgamentos sobre intenção e progresso — exatamente aquilo em que os LLMs são bons. Critérios claros em linguagem natural superam regras rígidas para a cauda longa."}, {"letter": "B", "text": "Configurar o agente para escalonar após três chamadas de ferramenta consecutivas que falhem em resolver o problema declarado pelo cliente, garantindo uma tentativa razoável antes de envolver um humano.", "correct": false, "explanation": "Um número fixo de novas tentativas dispara tanto cedo demais (novas tentativas legítimas) quanto tarde demais (problemas óbvios de política logo na primeira chamada)."}, {"letter": "C", "text": "Implementar análise de sentimento que monitore indicadores de frustração (linguagem negativa, perguntas repetidas, pontos de exclamação) e acione o escalonamento quando a pontuação de frustração ultrapassar um limite configurado.", "correct": false, "explanation": "A análise de sentimento pode captar a frustração, mas ignora clientes calmos que simplesmente precisam de um humano para uma exceção de política, e escalona em excesso diante de linguagem estilística."}, {"letter": "D", "text": "Construir um motor de regras que mapeie tipos específicos de problemas, segmentos de clientes e categorias de produtos para decisões de escalonamento, eliminando a necessidade de julgamentos do modelo.", "correct": false, "explanation": "Motores de regras quebram nos casos para os quais não foram projetados — e o atendimento ao cliente é cheio deles."}], "correct": "A", "task_id": "5.2", "objective": "Design effective escalation and ambiguity resolution patterns", "group": "C"}, {"id": "m33", "domain": 1, "scenario": null, "situation": "Após investigar uma disputa de cobrança ao longo de mais de 25 turnos, você identificou que as cobranças duplicadas ocorreram devido a um timeout do gateway de pagamento que acionou a lógica de nova tentativa. O reembolso necessário (US$ 847) excede seu limite de autorização de US$ 500. Você precisa chamar `escalate_to_human`, e o agente humano não terá acesso à transcrição da sua conversa.", "question": "Qual contexto você deve repassar para permitir uma resolução eficaz?", "options": [{"letter": "A", "text": "A reclamação original do cliente na íntegra, mais os trechos dos resultados de ferramentas que mostram as transações duplicadas.", "correct": false, "explanation": "Artefatos brutos sem síntese forçam o humano a refazer os 25 turnos de investigação que você acabou de concluir."}, {"letter": "B", "text": "Um resumo estruturado: ID do cliente, causa raiz, valor do reembolso e ação recomendada.", "correct": true, "explanation": "Correto. Um repasse estruturado com identificadores, causa, valor e ação recomendada é o que um agente humano precisa para assumir o caso instantaneamente, sem reinvestigar."}, {"letter": "C", "text": "A transcrição completa da conversa com todos os resultados de ferramentas.", "correct": false, "explanation": "Despejar a transcrição inteira força o humano a vasculhar 25 turnos em vez de ler um resumo de uma tela."}, {"letter": "D", "text": "Apenas o seu diagnóstico e o valor do reembolso.", "correct": false, "explanation": "Faltam os identificadores do cliente e a ação recomendada — o humano não consegue agir sem eles."}], "correct": "B", "task_id": "1.4", "objective": "Implement multi-step workflows with enforcement and handoff patterns", "group": "A"}, {"id": "m34", "domain": 1, "scenario": null, "situation": "A conformidade exige que reembolsos acima de US$ 500 sejam automaticamente escalonados para um agente humano — essa regra não pode ficar a critério do modelo. Apesar de instruções claras no prompt do sistema, os logs de produção mostram que o agente ocasionalmente processa reembolsos de alto valor diretamente (taxa de falha de 3%).", "question": "Como você deve garantir conformidade assegurada?", "options": [{"letter": "A", "text": "Modificar a ferramenta de reembolso para retornar um erro com a mensagem \"Valor excede o limite da política — favor escalonar\" quando o limite for ultrapassado.", "correct": false, "explanation": "Isso ajuda, mas depende de o agente interpretar o erro corretamente e escalonar — ainda é critério do modelo no ponto de decisão."}, {"letter": "B", "text": "Adicionar exemplos few-shot ao prompt mostrando o comportamento correto de escalonamento em diversos valores de reembolso (US$ 400, US$ 500, US$ 600).", "correct": false, "explanation": "Exemplos few-shot deslocam a distribuição, mas não eliminam a falha de 3%. A conformidade diz que a regra não pode ficar a critério do modelo."}, {"letter": "C", "text": "Implementar um hook para interceptar as chamadas de ferramenta; quando o valor do processo de reembolso exceder US$ 500, bloqueá-lo e invocar o escalonamento humano.", "correct": true, "explanation": "Correto. Regras de nível de conformidade pertencem fora do modelo — um hook determinístico na chamada de ferramenta é garantido de disparar sempre, independentemente do comportamento do modelo."}, {"letter": "D", "text": "Reforçar o prompt do sistema com linguagem enfática: \"POLÍTICA CRÍTICA: Reembolsos acima de US$ 500 DEVEM acionar escalonamento humano. NUNCA processe esses diretamente.\"", "correct": false, "explanation": "Prompts enfáticos reduzem, mas não eliminam o uso indevido. Regras que \"não podem ficar a critério do modelo\" descartam qualquer solução baseada apenas em prompt."}], "correct": "C", "task_id": "1.5", "objective": "Apply Agent SDK hooks for tool call interception and data normalization", "group": "E"}, {"id": "m35", "domain": 1, "scenario": null, "situation": "Durante a resolução de uma disputa de cobrança, seu agente recupera com sucesso as informações do cliente via `get_customer` e os detalhes do pedido via `lookup_order`, mas, ao tentar chamar `process_refund`, a ferramenta retorna um erro de timeout. O agente tem informações suficientes para explicar as cobranças e verificar a elegibilidade do reembolso, mas não consegue de fato processar o reembolso devido à falha no backend.", "question": "Qual abordagem equilibra melhor a resolução no primeiro contato com o tratamento de erros adequado?", "options": [{"letter": "A", "text": "Escalonar imediatamente para um agente humano, já que a ação de reembolso não pode ser concluída.", "correct": false, "explanation": "Repassa um problema transitório de backend a um humano quando o agente ainda poderia explicar a situação e oferecer opções."}, {"letter": "B", "text": "Implementar novas tentativas automáticas com backoff exponencial para `process_refund`, mantendo a conversa aberta até que o reembolso seja processado com sucesso.", "correct": false, "explanation": "Forçar o cliente a esperar por novas tentativas indefinidas é uma péssima experiência e pode nunca dar certo se a indisponibilidade for prolongada."}, {"letter": "C", "text": "Explicar a cobrança, confirmar a elegibilidade do reembolso, reconhecer o problema do sistema que impede o processamento imediato e oferecer escalonamento ou nova tentativa mais tarde.", "correct": true, "explanation": "Correto. Entregue o valor parcial que você pode (explicação + elegibilidade), seja honesto sobre a falha e deixe o cliente escolher entre escalonamento humano ou uma nova tentativa. Degradação graciosa clássica."}, {"letter": "D", "text": "Confirmar que o reembolso será processado e encerrar a conversa, já que o sistema tem todas as informações necessárias para concluí-lo automaticamente.", "correct": false, "explanation": "Comprometer-se com um resultado que não aconteceu é enganar o cliente — uma falha maior do que o próprio timeout."}], "correct": "C", "task_id": "1.4", "objective": "Implement multi-step workflows with enforcement and handoff patterns", "group": "A"}, {"id": "m36", "domain": 1, "scenario": null, "situation": "Um cliente escreve: \"Já estou indo e voltando com essa devolução há dias. Só quero falar com alguém que possa realmente me ajudar.\" O agente confirmou via `lookup_order` que a devolução é simples — dentro da política e elegível para processamento imediato.", "question": "O que o agente deve fazer?", "options": [{"letter": "A", "text": "Reconhecer a frustração, informar que isso pode ser resolvido agora e oferecer-se para concluí-la ou escalonar.", "correct": true, "explanation": "Correto. Acolha o sentimento, ofereça por escrito o caminho de resolução rápida e preserve a escolha do cliente. Essa é a atitude de respeito ao cliente que ainda aproveita a capacidade do agente."}, {"letter": "B", "text": "Chamar `escalate_to_human` imediatamente para atender ao pedido do cliente.", "correct": false, "explanation": "Enfileiramento desnecessário quando o problema está a uma chamada de ferramenta de distância. Frustra ainda mais o cliente ao adicionar espera a um caso já simples."}, {"letter": "C", "text": "Processar o reembolso via `process_refund` para resolver o problema de fundo e, em seguida, informar que está concluído.", "correct": false, "explanation": "Toma uma ação unilateral depois que o cliente pediu explicitamente para falar com alguém — passa por cima da preferência declarada por ele."}, {"letter": "D", "text": "Perguntar especificamente o que não funcionou nas tentativas anteriores antes de decidir se escalona ou resolve automaticamente.", "correct": false, "explanation": "Interrogar um cliente frustrado sobre falhas passadas é o oposto do que ele pediu."}], "correct": "A", "task_id": "5.2", "objective": "Design effective escalation and ambiguity resolution patterns", "group": "C"}, {"id": "m39", "domain": 1, "scenario": null, "situation": null, "question": "Quando o agente chama `lookup_order` e recebe detalhes do pedido mostrando que o item foi comprado há 45 dias, como o loop agêntico determina se deve chamar `process_refund` ou `escalate_to_human` em seguida?", "options": [{"letter": "A", "text": "A camada de orquestração roteia automaticamente para a próxima ferramenta com base no campo de status do pedido.", "correct": false, "explanation": "Não existe uma camada de orquestração implícita escolhendo ferramentas a partir de um campo. O modelo conduz a seleção de ferramentas."}, {"letter": "B", "text": "O agente segue uma árvore de decisão pré-configurada que mapeia atributos do pedido para chamadas de ferramentas específicas.", "correct": false, "explanation": "Loops agênticos são conduzidos pelo modelo, não por árvores de decisão. Árvores codificadas são o oposto da proposta do padrão de agente."}, {"letter": "C", "text": "Os detalhes do pedido são adicionados à conversa e o modelo raciocina sobre qual ação tomar.", "correct": true, "explanation": "Correto. O loop agêntico funciona acrescentando mensagens `tool_result` à conversa e deixando o modelo decidir o próximo passo a cada turno. É assim que 45 dias → reembolso vs. escalonamento é resolvido."}, {"letter": "D", "text": "O agente executa as etapas restantes em uma sequência de ferramentas planejada no início da requisição.", "correct": false, "explanation": "Não há um plano comprometido de antemão — o agente escolhe cada próximo passo com base no contexto mais recente."}], "correct": "C", "task_id": "1.1", "objective": "Design and implement agentic loops for autonomous task execution", "group": "A"}, {"id": "m40", "domain": 1, "scenario": null, "situation": "Um cliente envia: \"Isso é frustrante. Já expliquei meu problema duas vezes e nada está sendo resolvido. Quero falar com uma pessoa de verdade AGORA.\" O agente ainda não chamou nenhuma ferramenta para investigar a conta dele.", "question": "O que o agente deve fazer?", "options": [{"letter": "A", "text": "Reconhecer a frustração e fazer uma pergunta direcionada para entender o problema específico antes de escalonar.", "correct": true, "explanation": "Correto. O cliente disse \"duas vezes\", mas você ainda não tem contexto. Uma pergunta focada e acolhedora lhe dá uma chance de resolução no primeiro contato, sem desconsiderar a frustração nem atrasar um possível repasse."}, {"letter": "B", "text": "Explicar brevemente com o que o agente pode ajudar e oferecer-se para resolver o problema rapidamente, escalonando apenas se o cliente repetir o pedido.", "correct": false, "explanation": "Começar a listar capacidades para um cliente frustrado que pediu um humano soa como descaso."}, {"letter": "C", "text": "Chamar `escalate_to_human` imediatamente com o histórico da conversa.", "correct": false, "explanation": "Escalonar sem nenhum contexto de ferramentas cria um repasse frio, no qual o humano também começa do zero."}, {"letter": "D", "text": "Primeiro chamar `get_customer` e `lookup_order` para reunir o contexto da conta e, em seguida, escalonar para um agente humano.", "correct": false, "explanation": "Investigar sem perguntar adiciona latência e não respeita o pedido do cliente. Uma única pergunta acolhedora é mais rápida e mais respeitosa."}], "correct": "A", "task_id": "5.2", "objective": "Design effective escalation and ambiguity resolution patterns", "group": "C"}, {"id": "m41", "domain": 1, "scenario": null, "situation": "Seu agente está tratando uma disputa de cobrança. Depois de chamar `get_customer` e `lookup_order`, ele identifica que a disputa envolve um erro de preço promocional que exige aprovação gerencial — acima do nível de autorização do agente.", "question": "Como o fluxo de trabalho deve lidar com esse escalonamento no meio do processo?", "options": [{"letter": "A", "text": "Chamar `escalate_to_human` repassando apenas a mensagem original do cliente.", "correct": false, "explanation": "Descarta o contexto derivado das ferramentas que o agente acabou de reunir, forçando o humano a refazer a investigação."}, {"letter": "B", "text": "Compilar um repasse estruturado com os dados do cliente, informações do pedido e o problema identificado antes de chamar `escalate_to_human`.", "correct": true, "explanation": "Correto. Um resumo estruturado (quem, qual pedido, qual problema, por que excede a autorização) permite que o agente humano assuma instantaneamente. Esse é o padrão de escalonamento no meio do processo."}, {"letter": "C", "text": "Tentar o reembolso com `process_refund` mesmo assim, escalonando apenas se o sistema rejeitar a transação.", "correct": false, "explanation": "Exceder a autorização de forma consciente é uma violação de política — não é algo para tentar e torcer para que o sistema detecte."}, {"letter": "D", "text": "Persistir a conversa completa e o histórico de respostas das ferramentas em um banco de dados e, em seguida, chamar `escalate_to_human` com um ID de referência.", "correct": false, "explanation": "Adiciona infraestrutura e uma etapa extra de consulta quando um resumo estruturado embutido é mais simples e rápido."}], "correct": "B", "task_id": "1.4", "objective": "Implement multi-step workflows with enforcement and handoff patterns", "group": "A"}, {"id": "g7", "domain": 2, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Logs de produção mostram um padrão persistente: pedidos como \"analise o relatório trimestral enviado\" são roteados ao agente de busca web em 45% das vezes em vez de ao agente de análise de documentos. Revisando as definições das ferramentas, você descobre que o agente de busca web tem uma ferramenta `analyze_content` descrita como \"analyzes content and extracts key information\", enquanto o agente de análise de documentos tem `analyze_document` descrita como \"analyzes documents and extracts key information\". Como corrigir o problema de roteamento errado?", "question": "Como corrigir o problema?", "options": [{"letter": "A", "text": "Adicionar um classificador de pré-roteamento que detecta se o usuário se refere a arquivos enviados ou a conteúdo web antes de o coordenador decidir a delegação.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Renomear a ferramenta de busca web para `extract_web_results` e atualizar sua descrição para \"processes and returns information retrieved from web search and URLs.\"", "correct": true, "explanation": "Renomear a ferramenta de busca web para `extract_web_results` e atualizar a descrição para referenciar explicitamente busca web e URLs remove diretamente a causa-raiz ao eliminar a sobreposição semântica entre nomes e descrições. Isso torna o propósito de cada ferramenta inequívoco, permitindo ao coordenador distinguir análise de documentos de busca web de forma confiável."}, {"letter": "C", "text": "Adicionar exemplos few-shot ao prompt do coordenador mostrando o roteamento correto: \"User uploads a quarterly report → document analysis agent\" e \"User asks about a web page → web-search agent.\"", "correct": false, "explanation": ""}, {"letter": "D", "text": "Expandir a descrição da ferramenta de análise de documentos com exemplos de uso como \"Use for uploaded PDFs, Word docs, and spreadsheets,\" deixando a ferramenta de busca web inalterada.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "g10", "domain": 2, "scenario": "Sistema de Pesquisa Multiagente", "situation": "No seu desenho de sistema, você deu ao agente de análise de documentos acesso a uma ferramenta de uso geral `fetch_url` para que ele pudesse baixar documentos por URL. Logs de produção mostram que esse agente agora frequentemente baixa páginas de resultados de busca para fazer busca web ad hoc — comportamento que deveria passar pelo agente de busca web — causando resultados inconsistentes. Qual correção é mais efetiva?", "question": "Qual correção é mais efetiva?", "options": [{"letter": "A", "text": "Substituir `fetch_url` por uma ferramenta `load_document` que valida que URLs apontem para formatos de documento.", "correct": true, "explanation": "Substituir uma ferramenta de uso geral por uma específica de documento que valida URLs contra formatos de documento ataca a causa-raiz ao restringir capacidade no nível da interface. Isso segue o princípio do menor privilégio, tornando o comportamento indesejado de busca impossível em vez de meramente desencorajado."}, {"letter": "B", "text": "Remover `fetch_url` do agente de análise de documentos e rotear toda busca por URL pelo coordenador para o agente de busca web.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Implementar filtragem que bloqueia chamadas de `fetch_url` para domínios conhecidos de buscadores enquanto permite outras URLs.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Adicionar instruções no prompt do agente de análise de documentos dizendo que `fetch_url` só deve ser usada para baixar URLs de documentos, não para buscar.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "2.3", "objective": "Distribute tools appropriately across agents and configure tool choice", "group": "B"}, {"id": "g15", "domain": 2, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Em testes, você observa que o agente de síntese frequentemente precisa verificar afirmações específicas ao mesclar resultados. Atualmente, quando verificação é necessária, o agente de síntese devolve o controle ao coordenador, que chama o agente de busca web e então re-invoca a síntese com os resultados. Isso adiciona 2–3 loops extras por tarefa e aumenta a latência em 40%. Sua avaliação mostra que 85% dessas verificações são checagens simples (datas, nomes, estatísticas) e 15% exigem pesquisa mais profunda. Qual abordagem é mais efetiva para reduzir overhead preservando confiabilidade?", "question": "Qual abordagem é mais efetiva?", "options": [{"letter": "A", "text": "Dar ao agente de síntese acesso a todas as ferramentas de busca web para que ele possa lidar com qualquer necessidade de verificação diretamente, sem loops do coordenador.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Fazer o agente de síntese acumular todas as necessidades de verificação e devolvê-las como um lote ao coordenador no fim, que então as envia todas de uma vez ao agente de busca web.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Fazer o agente de busca web cachear proativamente contexto extra ao redor de cada fonte durante a pesquisa inicial, antecipando necessidades da síntese.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Dar ao agente de síntese uma ferramenta `verify_fact` de escopo limitado para checagens simples, enquanto roteia verificações complexas pelo coordenador para o agente de busca web.", "correct": true, "explanation": "Uma ferramenta de verificação de fato de escopo limitado deixa o agente de síntese lidar diretamente com 85% das checagens simples, eliminando a maioria dos loops, enquanto preserva o caminho de delegação pelo coordenador para os 15% de verificações complexas. Aplica menor privilégio enquanto reduz significativamente a latência."}], "correct": "D", "task_id": "2.3", "objective": "Distribute tools appropriately across agents and configure tool choice", "group": "B"}, {"id": "g18", "domain": 2, "scenario": "Claude Code para Integração Contínua", "situation": "Seu componente de code review é iterativo: Claude analisa o arquivo modificado, depois pode pedir arquivos relacionados (imports, classes-base, testes) via chamadas de ferramenta para entender contexto antes de prover feedback final. Sua aplicação define uma ferramenta que permite a Claude pedir conteúdo de arquivos; Claude chama a ferramenta, recebe resultados e continua a análise. Você está avaliando processamento em lote para reduzir custo de API. Qual é a principal limitação técnica ao considerar processamento em lote para esse fluxo?", "question": "Qual é a principal limitação técnica?", "options": [{"letter": "A", "text": "O processamento em lote não inclui IDs de correlação para mapear saídas de volta às requisições de entrada.", "correct": false, "explanation": ""}, {"letter": "B", "text": "O modelo assíncrono não consegue executar ferramentas no meio da requisição e devolver resultados para Claude continuar a análise.", "correct": true, "explanation": "A natureza assíncrona da Batch API (uma requisição = uma resposta) significa que ela não consegue executar ferramentas no meio da chamada e devolver resultados para o modelo continuar a análise iterativa. Isso torna fundamentalmente incompatível workflows que precisam de tool calling multi-turn. (A está incorreta: `custom_id` existe. C está incorreta: a Batch API aceita ferramentas nos params. D é uma preocupação real mas não é a limitação fundamental — algumas review podem tolerar 24 horas; a limitação fundamental é não conseguir executar tool calls iterativos em meio à requisição.)"}, {"letter": "C", "text": "A Batch API não suporta definições de ferramentas nos parâmetros da requisição.", "correct": false, "explanation": ""}, {"letter": "D", "text": "A latência de até 24 horas do processamento em lote é lenta demais para feedback de pull request, embora o fluxo funcionasse no resto.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "4.5", "objective": "Design efficient batch processing strategies", "group": "H"}, {"id": "g46", "domain": 2, "scenario": "Agente de Suporte ao Cliente", "situation": "Em testes, você nota que o agente frequentemente chama `get_customer` quando usuários perguntam sobre status de pedido, embora `lookup_order` fosse mais apropriado. O que você deve checar primeiro para tratar esse problema?", "question": "O que você deve checar primeiro?", "options": [{"letter": "A", "text": "Implementar um classificador de pré-processamento para detectar pedidos relacionados a ordem e roteá-los diretamente a `lookup_order`.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Reduzir o número de ferramentas disponíveis ao agente para simplificar a escolha.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar exemplos few-shot ao system prompt cobrindo todos os padrões possíveis de pedido para melhorar a seleção de ferramentas.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Verificar as descrições das ferramentas para garantir que diferenciem claramente o propósito de cada uma.", "correct": true, "explanation": "Descrições de ferramentas são a entrada principal que o modelo usa para decidir qual chamar. Quando um agente escolhe consistentemente a ferramenta errada, o primeiro passo de diagnóstico é verificar se as descrições separam claramente o propósito e os limites de uso."}], "correct": "D", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "g51", "domain": 2, "scenario": "Agente de Suporte ao Cliente", "situation": "Logs de produção mostram que em 12% dos casos seu agente pula `get_customer` e chama `lookup_order` diretamente usando apenas o nome fornecido pelo cliente, às vezes levando a contas mal identificadas e reembolsos incorretos. Qual mudança corrige esse problema de confiabilidade de forma mais efetiva?", "question": "Qual mudança é mais efetiva?", "options": [{"letter": "A", "text": "Adicionar exemplos few-shot mostrando que o agente sempre chama `get_customer` primeiro, mesmo quando clientes voluntariamente fornecem detalhes do pedido.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Implementar um classificador de roteamento que analisa cada pedido e habilita só um subconjunto de ferramentas apropriado para o tipo.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar uma pré-condição programática que bloqueia `lookup_order` e `process_refund` até que `get_customer` retorne um identificador verificado.", "correct": true, "explanation": "Uma pré-condição programática fornece garantia determinística de que o sequenciamento exigido seja seguido. É a abordagem mais efetiva porque elimina a possibilidade de pular a verificação, independentemente do comportamento do LLM."}, {"letter": "D", "text": "Reforçar o system prompt declarando que verificação do cliente via `get_customer` é mandatória antes de qualquer operação de pedido.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "1.5", "objective": "Apply Agent SDK hooks for tool call interception and data normalization", "group": "E"}, {"id": "g55", "domain": 2, "scenario": "Agente de Suporte ao Cliente", "situation": "Sua ferramenta `get_customer` retorna todas as correspondências ao buscar por nome. Atualmente, quando há múltiplos resultados, Claude escolhe o cliente com pedido mais recente, mas dados de produção mostram que isso seleciona a conta errada em 15% dos casos para correspondências ambíguas. Como você deveria tratar isso?", "question": "Como você deveria tratar isso?", "options": [{"letter": "A", "text": "Implementar um sistema de pontuação de confiança que age autonomamente acima de 85% e pede esclarecimento abaixo do limiar.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Instruir Claude a pedir um identificador adicional (email, telefone ou número do pedido) quando `get_customer` retornar múltiplas correspondências antes de tomar qualquer ação específica do cliente.", "correct": true, "explanation": "Pedir ao usuário um identificador adicional é a forma mais confiável de resolver ambiguidade porque o usuário tem conhecimento definitivo da própria identidade. Um turno de conversa extra é um preço pequeno a pagar para eliminar uma taxa de erro de 15% causada por escolher a conta errada."}, {"letter": "C", "text": "Modificar `get_customer` para retornar apenas uma única correspondência mais provável com base em algoritmo de ranking, eliminando ambiguidade.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Adicionar exemplos few-shot ao prompt demonstrando raciocínio correto e sequenciamento de ferramentas para correspondências ambíguas.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "g57", "domain": 2, "scenario": "Agente de Suporte ao Cliente", "situation": "Logs de produção mostram que o agente frequentemente chama `get_customer` quando usuários perguntam sobre pedidos (ex.: \"verifique meu pedido #12345\") em vez de chamar `lookup_order`. Ambas as ferramentas têm descrições mínimas (\"Gets customer information\" / \"Gets order details\") e aceitam formatos de identificador parecidos. Qual é o primeiro passo mais efetivo para melhorar a confiabilidade da seleção de ferramenta?", "question": "Qual é o primeiro passo mais efetivo?", "options": [{"letter": "A", "text": "Implementar uma camada de roteamento que analisa o input do usuário antes de cada turno e pré-seleciona a ferramenta correta com base em palavras-chave detectadas e padrões de ID.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Combinar ambas em uma única `lookup_entity` que aceita qualquer identificador e decide internamente qual backend consultar.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar exemplos few-shot ao system prompt demonstrando padrões corretos de seleção, com 5–8 exemplos roteando consultas relacionadas a pedido para `lookup_order`.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Expandir a descrição de cada ferramenta para incluir formatos de entrada, queries de exemplo, casos de borda e fronteiras explicando quando usá-la versus ferramentas similares.", "correct": true, "explanation": "Expandir descrições com formatos de entrada, queries de exemplo, casos de borda e fronteiras claras corrige diretamente a causa-raiz — descrições mínimas que não dão ao LLM informação suficiente para distinguir ferramentas similares. É um primeiro passo de baixo esforço e alto impacto que melhora o mecanismo principal usado pelo LLM para seleção de ferramenta."}], "correct": "D", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "g59", "domain": 2, "scenario": "Agente de Suporte ao Cliente", "situation": "Logs de produção mostram que o agente interpreta mal saídas de suas ferramentas MCP: timestamps Unix de `get_customer`, datas ISO 8601 de `lookup_order` e códigos de status numéricos (1=pendente, 2=enviado). Algumas ferramentas são servidores MCP de terceiros que você não pode modificar. Qual abordagem para normalização de formato de dados é mais mantível?", "question": "Qual abordagem é mais mantível?", "options": [{"letter": "A", "text": "Usar um hook PostToolUse para interceptar saídas de ferramentas e aplicar transformações de formato antes que o agente processe.", "correct": true, "explanation": "Um hook PostToolUse fornece um ponto centralizado e determinístico para interceptar e normalizar todas as saídas de ferramenta — incluindo dados de servidores MCP de terceiros — antes que o agente as processe. É mais mantível porque transformações vivem em código e se aplicam uniformemente, sem depender da interpretação do LLM."}, {"letter": "B", "text": "Modificar ferramentas que você controla para retornar formatos legíveis para humanos e criar wrappers para ferramentas de terceiros.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Criar uma ferramenta `normalize_data` que o agente chama após cada recuperação de dados para transformar valores.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Adicionar documentação detalhada de formato no system prompt explicando convenções de dado de cada ferramenta.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "1.5", "objective": "Apply Agent SDK hooks for tool call interception and data normalization", "group": "E"}, {"id": "g61", "domain": 2, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Sua ferramenta `remove_team_member` usa um parâmetro `dry_run: boolean` para visualizar impactos antes da execução. Monitoramento de produção mostra que o agente burla o passo de preview chamando com `dry_run=false` diretamente. Você precisa garantir que toda remoção seja precedida por um preview que o usuário confirme explicitamente.", "question": "Qual é a abordagem mais confiável?", "options": [{"letter": "A", "text": "Adicionar validação no servidor que permite `dry_run=false` apenas quando uma chamada `dry_run=true` com parâmetros idênticos ocorreu nos últimos 60 segundos.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Anotar a ferramenta como exigindo confirmação e configurar a camada de orquestração para pedir aprovação ao usuário antes de encaminhar quaisquer chamadas a ferramentas anotadas.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar instruções detalhadas e exemplos few-shot na descrição da ferramenta exigindo que o agente sempre chame com `dry_run=true` primeiro e espere confirmação antes de chamar de novo.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Substituir por duas ferramentas: `preview_remove_member` retorna detalhes de impacto e um token de confirmação de uso único; `execute_remove_member` exige esse token, ligando a execução ao preview.", "correct": true, "explanation": "A abordagem de duas ferramentas com binding por token torna arquiteturalmente impossível executar sem um preview prévio — a ferramenta de execução literalmente exige um token que só a ferramenta de preview pode gerar. É a única abordagem que aplica a restrição no nível de código em vez de depender de conformidade do LLM com instruções (C), heurísticas de timing (A) ou infraestrutura de orquestração (B)."}], "correct": "D", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "g62", "domain": 2, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Monitoramento de produção mostra que sua ferramenta `search_catalog` falha 12% do tempo: 8% são timeouts de rede que sucedem ao retentar e 4% são erros de sintaxe de query que nunca sucedem por mais que se retente. Atualmente ambos os tipos de erro são retornados de forma idêntica, causando retentativas desperdiçadas.", "question": "Como você deveria modificar o tratamento de erros da ferramenta?", "options": [{"letter": "A", "text": "Adicionar exemplos few-shot ao system prompt demonstrando como distinguir erros de rede de erros de sintaxe.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Aplicar lógica de retry com backoff exponencial uniformemente a todos os erros.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Implementar retry automático com backoff para timeouts de rede dentro da ferramenta; retornar erros de sintaxe imediatamente com detalhes de validação de parâmetro.", "correct": true, "explanation": "Tratar retries no nível da ferramenta para erros transitórios é a fronteira de abstração correta — a ferramenta tem conhecimento definitivo do tipo de erro e pode implementar lógica de retry determinística sem depender do agente para interpretar uma flag (D) ou seguir instruções no nível do prompt (A). Backoff uniforme (B) desperdiça tempo em erros de sintaxe que nunca sucederão."}, {"letter": "D", "text": "Retornar todos os erros com flag booleana `retryable` e detalhes do tipo de erro.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "m3", "domain": 2, "scenario": null, "situation": "O agente de análise de documentos tem uma única ferramenta `analyze_document` que recebe um documento e um parâmetro de instrução em texto livre. Durante a avaliação, solicitações como \"extrair as principais métricas financeiras\" frequentemente retornam resumos narrativos, enquanto \"resumir a metodologia\" às vezes retorna tabelas de dados brutos. O agente de síntese relata que 35% dos resultados de análise exigem novas solicitações com instruções esclarecidas.", "question": "Qual é a forma mais eficaz de melhorar a confiabilidade?", "options": [{"letter": "A", "text": "Dividir a ferramenta genérica em ferramentas específicas para cada propósito — `extract_data_points`, `summarize_content`, `verify_claim_against_source` — cada uma com contratos de entrada/saída definidos.", "correct": true, "explanation": "Correto. Instruções em texto livre colocam a semântica na prosa, que o modelo interpreta de forma inconsistente. Ferramentas específicas para cada propósito dão ao modelo um contrato explícito e bem tipado para escolher."}, {"letter": "B", "text": "Manter a ferramenta única, mas adicionar um parâmetro enum `analysis_type` que exija a seleção explícita entre os modos de extração, resumo e verificação.", "correct": false, "explanation": "Melhor que texto livre, mas ainda é uma única ferramenta com um único formato de saída. A saída ainda precisa ser uma string genérica, e o modelo pode confundir os modos. Ferramentas separadas impõem contratos de entrada/saída distintos."}, {"letter": "C", "text": "Fazer com que o coordenador pré-classifique cada solicitação de análise antes de passar as instruções ao agente de análise de documentos.", "correct": false, "explanation": "Move a ambiguidade para cima sem resolvê-la. O contrato da ferramenta continua impreciso; a classificação do coordenador é mais uma superfície de erro."}, {"letter": "D", "text": "Aprimorar a descrição da ferramenta com exemplos detalhados mostrando como diferentes formulações de instrução devem mapear para diferentes formatos de saída.", "correct": false, "explanation": "Exemplos ajudam, mas a confiabilidade no uso de ferramentas vem primeiro de limites de ferramenta claros e esquemas de saída, não de engenharia de prompt heroica em uma única ferramenta genérica."}], "correct": "A", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "m16", "domain": 2, "scenario": null, "situation": "Após integrar um servidor MCP local que fornece ferramentas de análise de código (`analyze_dependencies`, `find_dead_code`, `calculate_complexity`), você verifica que o servidor está saudável e que as ferramentas aparecem na resposta de tools/list. No entanto, você observa que o agente usa consistentemente o Grep para buscar declarações de importação em vez de chamar `analyze_dependencies` — mesmo quando os usuários perguntam explicitamente sobre \"dependências de código\". Ao examinar as definições das ferramentas, você encontra: MCP: `analyze_dependencies` - \"Analisa o grafo de dependências\" Nativa: Grep - \"Busca o conteúdo de arquivos por um padrão usando expressões regulares. Retorna as linhas correspondentes com números de linha e contexto ao redor.\"", "question": "Qual é a abordagem mais eficaz para melhorar a seleção de ferramentas MCP pelo agente?", "options": [{"letter": "A", "text": "Remover o Grep das ferramentas disponíveis quando o servidor MCP estiver conectado, para eliminar a sobreposição funcional.", "correct": false, "explanation": "Mutilar uma ferramenta de uso geral para forçar a adoção de uma especializada penaliza outros casos legítimos de uso do Grep."}, {"letter": "B", "text": "Adicionar instruções de roteamento ao prompt do sistema especificando que perguntas relacionadas a dependências devem usar ferramentas MCP em vez do Grep.", "correct": false, "explanation": "O roteamento no nível do prompt pode ajudar, mas a causa raiz é que a descrição da ferramenta MCP é mais pobre que a do Grep. Corrija primeiro as descrições das ferramentas."}, {"letter": "C", "text": "Dividir `analyze_dependencies` em ferramentas granulares (`list_imports`, `resolve_transitive_deps`, `detect_circular_deps`) para que cada uma tenha um propósito focado e menos propenso a se sobrepor ao Grep.", "correct": false, "explanation": "Dividir às vezes é o certo, mas aqui as ferramentas irmãs ainda teriam descrições fracas. O mesmo bug de seleção reapareceria."}, {"letter": "D", "text": "Expandir as descrições das ferramentas MCP para detalhar capacidades e saídas — por exemplo, \"Constrói um grafo de dependências mostrando importações diretas, dependências transitivas e ciclos.\"", "correct": true, "explanation": "Correto. A seleção de ferramentas é guiada pelas descrições que o modelo vê. Uma descrição de uma linha como 'Analisa o grafo de dependências' perde para a descrição rica do Grep. Reforce a descrição da ferramenta MCP."}], "correct": "D", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "m17", "domain": 2, "scenario": null, "situation": "Um engenheiro pede ao agente para encontrar todos os chamadores de uma função antes de removê-la. A função é definida em uma biblioteca central, mas também é exposta por meio de módulos wrapper que renomeiam a função para uso específico de domínio (por exemplo, calculateTax na biblioteca torna-se computeOrderTax no módulo de pedidos).", "question": "Qual estratégia de exploração identificará de forma mais confiável todos os chamadores?", "options": [{"letter": "A", "text": "Ler a biblioteca e os módulos wrapper para identificar todos os nomes sob os quais a função é exposta e, em seguida, usar o Grep para cada nome em toda a base de código.", "correct": true, "explanation": "Correto. Você precisa enumerar cada nome sob o qual a função é exposta — caso contrário, wrappers renomeados ocultam chamadores. Leia os módulos relevantes, reúna todos os aliases e então faça grep para cada um."}, {"letter": "B", "text": "Usar o Grep para encontrar todos os arquivos que importam da biblioteca ou dos módulos wrapper e, então, ler cada arquivo para verificar se ele usa a função.", "correct": false, "explanation": "Deixa de fora importações dinâmicas, reexportações e cadeias de chamada indiretas. Além disso, escala mal."}, {"letter": "C", "text": "Usar o Grep para buscar o nome original da função em toda a base de código.", "correct": false, "explanation": "O nome original não aparecerá em lugar nenhum onde um wrapper o tenha renomeado — você perderia uma classe significativa de chamadores."}, {"letter": "D", "text": "Buscar o nome da função na documentação do projeto para entender os padrões de uso pretendidos e navegar até os pontos de integração documentados.", "correct": false, "explanation": "A documentação é incompleta e frequentemente desatualizada. Você não pode remover uma função com segurança baseando-se em evidências de nível documental."}], "correct": "A", "task_id": "5.4", "objective": "Manage context effectively in large codebase exploration", "group": "G"}, {"id": "m27", "domain": 2, "scenario": null, "situation": "Após adicionar um servidor MCP com ferramentas especializadas de refatoração de código (`extract_function`, `rename_variable`, `inline_function`), você nota que o agente ainda usa manipulação básica de texto via Write e comandos sed do Bash para tarefas de refatoração. O servidor MCP está conectado e saudável. Ao examinar a configuração, você descobre que cada ferramenta MCP tem uma descrição mínima como \"`extract_function`: extrai uma função do código.\"", "question": "Qual é a maneira mais eficaz de melhorar a adoção das ferramentas de refatoração MCP?", "options": [{"letter": "A", "text": "Implementar um classificador de requisições que detecta a intenção de refatoração e roteia automaticamente essas requisições para o servidor MCP antes de o agente processá-las.", "correct": false, "explanation": "Um classificador prévio é um sistema separado para manter e pode rotear de forma errada. A correção mais barata é tornar as descrições das ferramentas fortes o suficiente para que o agente as escolha por conta própria."}, {"letter": "B", "text": "Remover a ferramenta Write da configuração do agente durante as sessões de refatoração, de modo que ele seja obrigado a usar as ferramentas MCP para modificações de código.", "correct": false, "explanation": "Remover ferramentas de uso geral força a adoção por subtração e quebra casos legítimos de uso do Write."}, {"letter": "C", "text": "Aceitar isso como comportamento esperado, já que ferramentas mais simples como o sed são mais previsíveis do que ferramentas especializadas de refatoração.", "correct": false, "explanation": "Capitular anula o propósito de integrar ferramentas de refatoração. A integração está bem — as descrições é que são o problema."}, {"letter": "D", "text": "Aprimorar as descrições das ferramentas MCP para explicar quando cada ferramenta é preferível à manipulação de texto e esclarecer as entradas e saídas esperadas.", "correct": true, "explanation": "Correto. A seleção de ferramentas é guiada pelas descrições que o Claude vê. Quando as ferramentas MCP dizem 'extrai uma função do código' e o Write/sed vêm com documentação rica, o Claude escolhe o Write/sed. Reforce as descrições."}], "correct": "D", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "m29", "domain": 2, "scenario": null, "situation": "Seu agente precisa inserir uma nova função auxiliar no meio de um módulo utilitário de 150 linhas, entre duas funções existentes. A ferramenta Edit falha porque seu parâmetro `old_string` não consegue encontrar um texto único para correspondência — o arquivo tem docstrings, nomes de variáveis e padrões estruturais repetitivos.", "question": "Qual é a maneira mais confiável de concluir essa inserção?", "options": [{"letter": "A", "text": "Usar o Edit com um `old_string` extremamente longo, capturando mais de 30 linhas de contexto para garantir a unicidade", "correct": false, "explanation": "Strings de correspondência longas e frágeis frequentemente falham devido a espaços em branco ou pequenas edições e produzem falhas confusas."}, {"letter": "B", "text": "Usar o parâmetro `replace_all` do Edit para mirar em um padrão comum e embutir a nova função no texto de substituição", "correct": false, "explanation": "`replace_all` modificaria todas as ocorrências do padrão — corrompendo o arquivo inteiro."}, {"letter": "C", "text": "Usar o Bash para anexar a definição da função ao final do arquivo usando a sintaxe de heredoc", "correct": false, "explanation": "Anexar coloca a função no local errado. O requisito é inserir entre duas funções existentes."}, {"letter": "D", "text": "Usar o Read para carregar o arquivo, adicionar a função no local apropriado e, então, usar o Write para gravar o arquivo atualizado", "correct": true, "explanation": "Correto. Quando o contrato de correspondência única do Edit não pode ser satisfeito em um arquivo repetitivo, recorra a Read → modificar em memória na linha pretendida → gravar o arquivo completo de volta com Write."}], "correct": "D", "task_id": "2.5", "objective": "Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively", "group": "F"}, {"id": "m38", "domain": 2, "scenario": null, "situation": "Os logs de produção revelam um tratamento de erros inconsistente: quando `lookup_order` falha, o agente às vezes tenta novamente mais de 5 vezes (desperdício quando o ID do pedido não existe), às vezes escalona imediatamente (prematuro para problemas temporários de rede) e às vezes pede esclarecimentos ao usuário (inadequado quando o problema é um erro de permissão no backend). A investigação mostra que sua ferramenta MCP retorna respostas de erro uniformes: {\"isError\": true, \"content\": [{\"type\": \"text\", \"text\": \"Operation failed\"}]}. O agente não consegue distinguir entre os tipos de erro.", "question": "Qual é a melhoria mais eficaz?", "options": [{"letter": "A", "text": "Enriquecer as respostas de erro com metadados estruturados: incluir errorCategory (transient/validation/permission), um booleano isRetryable e uma descrição do que causou a falha.", "correct": true, "explanation": "Correto. Dê ao agente a informação de que ele precisa para tomar a decisão certa: categoria, possibilidade de nova tentativa e uma causa legível por humanos. Isso substitui a adivinhação por uma política determinística."}, {"letter": "B", "text": "Criar uma ferramenta MCP `analyze_error` que o agente chama após qualquer falha para determinar a categoria do erro e a ação recomendada.", "correct": false, "explanation": "Adiciona uma viagem de ida e volta extra para algo que a ferramenta original já sabe. Coloque os metadados na resposta original."}, {"letter": "C", "text": "Implementar lógica de nova tentativa com backoff exponencial no seu servidor MCP para todos os erros, retornando ao agente somente depois de esgotadas as tentativas.", "correct": false, "explanation": "Novas tentativas indiscriminadas prejudicam em erros permanentes (pedido não encontrado) e escondem distinções úteis do agente."}, {"letter": "D", "text": "Adicionar exemplos few-shot ao prompt do sistema demonstrando como interpretar padrões de mensagens de erro e selecionar respostas adequadas para cada um.", "correct": false, "explanation": "Se a ferramenta retorna \"Operation failed\" para toda falha, nenhuma quantidade de exemplos few-shot extrai informação de categoria que não está lá."}], "correct": "A", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "m43", "domain": 2, "scenario": null, "situation": "Ao implementar sua ferramenta MCP `lookup_order`, o backend às vezes retorna erros (por exemplo, \"Order not found\" ou falhas temporárias de banco de dados).", "question": "Qual é o padrão correto para comunicar esses erros de volta ao agente?", "options": [{"letter": "A", "text": "Registrar o erro no lado do servidor e retornar um resultado vazio para evitar confundir o modelo.", "correct": false, "explanation": "Retornar sucessos vazios faz o agente pensar que não existem dados, em vez de que algo deu errado — uma confusão diferente e pior."}, {"letter": "B", "text": "Retornar a mensagem de erro no conteúdo do resultado da ferramenta, com a flag isError definida como true.", "correct": true, "explanation": "Correto. O padrão projetado do MCP: colocar o texto do erro no campo content e marcar isError=true. O Claude vê tanto a flag de falha quanto uma mensagem legível para raciocinar."}, {"letter": "C", "text": "Lançar uma exceção a partir do handler da ferramenta para que o framework do agente possa capturá-la e registrá-la.", "correct": false, "explanation": "Exceções não capturadas quebram o protocolo da ferramenta e não dão ao modelo nada com que raciocinar."}, {"letter": "D", "text": "Retornar uma resposta de sucesso com um campo \"status\" indicando o tipo de erro.", "correct": false, "explanation": "Campos \"status\" improvisados variam entre ferramentas e o modelo não tem uma forma padrão de interpretá-los. isError é o padrão."}], "correct": "B", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "m44", "domain": 2, "scenario": null, "situation": "Sua ferramenta `process_refund` retorna dois tipos de erro: erros técnicos (\"503 Service Unavailable\", \"Connection timeout\") que são transitórios (5% das chamadas) e erros de negócio (\"Order exceeds 30-day return window\", \"Item already refunded\") que são permanentes (12% das chamadas). O monitoramento mostra que o agente desperdiça de 3 a 4 turnos tentando novamente erros de negócio que nunca podem ter sucesso. Atualmente, ambos os tipos de erro retornam apenas uma mensagem de texto simples ao Claude.", "question": "Qual é a forma mais eficaz de reduzir as novas tentativas desperdiçadas e, ao mesmo tempo, melhorar a qualidade das respostas voltadas ao cliente?", "options": [{"letter": "A", "text": "Retornar respostas de erro estruturadas com retryable: false para erros de negócio e uma explicação amigável ao cliente para o Claude usar.", "correct": true, "explanation": "Correto. Uma flag retryable diz ao Claude, de forma determinística, \"não tente novamente\", e uma mensagem amigável ao cliente já pronta melhora a resposta de saída. Resolve os dois problemas de uma vez."}, {"letter": "B", "text": "Adicionar exemplos few-shot mostrando como distinguir erros recuperáveis de não recuperáveis analisando o texto da mensagem de erro.", "correct": false, "explanation": "Depender de o modelo analisar textos de erro como strings é frágil e é exatamente a instabilidade que você vê hoje."}, {"letter": "C", "text": "Adicionar uma ferramenta `check_refund_eligibility` que deve ser chamada antes de `process_refund` para evitar violações de regras de negócio.", "correct": false, "explanation": "Útil em princípio, mas adiciona uma viagem de ida e volta a todo reembolso para proteger contra 12% dos casos, e não ajuda quando `process_refund` ainda falha por outros motivos de negócio."}, {"letter": "D", "text": "Implementar lógica de nova tentativa automática no nível da ferramenta apenas para erros técnicos, repassando erros de negócio ao Claude sem novas tentativas.", "correct": false, "explanation": "Esconder novas tentativas transitórias dentro da ferramenta pode mascarar latência e tira o modelo do circuito nas decisões de recuperação. Os erros de negócio também continuam chegando como uma string simples, então a resposta voltada ao cliente não melhora."}], "correct": "A", "task_id": "2.2", "objective": "Implement structured error responses for MCP tools", "group": "J"}, {"id": "m55", "domain": 2, "scenario": null, "situation": "Seu pipeline usa uma ferramenta chamada `extract_metadata` com um esquema JSON para detalhes do artigo. Você também definiu as ferramentas `lookup_citations` e `verify_doi` para enriquecimento. Durante os testes, você nota que, quando os usuários incluem pedidos como \"extract the metadata and tell me how cited it is\", o Claude às vezes chama `lookup_citations` primeiro, o que falha porque ela precisa do DOI que `extract_metadata` forneceria.", "question": "Qual é a maneira mais eficaz de garantir que a extração estruturada de metadados aconteça primeiro?", "options": [{"letter": "A", "text": "Definir `tool_choice` como \"any\" para que o Claude tenha de usar uma ferramenta, combinado com instruções no prompt do sistema priorizando `extract_metadata`.", "correct": false, "explanation": "'any' força uma chamada de ferramenta, mas não força a correta. Você ainda veria `lookup_citations` sendo escolhida primeiro."}, {"letter": "B", "text": "Definir `tool_choice` como \"auto\" e reordenar as definições de ferramentas para que `extract_metadata` apareça primeiro no array de ferramentas, já que o Claude prioriza as ferramentas listadas antes.", "correct": false, "explanation": "Não há uma preferência de ordenação documentada na qual confiar; isso pressupõe um comportamento que não é contratual."}, {"letter": "C", "text": "Definir `tool_choice` como {\"type\": \"tool\", \"name\": \"`extract_metadata`\"} e processar os pedidos de enriquecimento em turnos subsequentes, depois de receber os metadados extraídos.", "correct": true, "explanation": "Correto. `tool_choice`=ferramenta-específica força de forma determinística `extract_metadata` no primeiro turno. Em seguida, você devolve o controle para 'auto' e deixa o modelo usar o enriquecimento de citações/DOI com os metadados em contexto."}, {"letter": "D", "text": "Definir `tool_choice` como {\"type\": \"tool\", \"name\": \"`extract_metadata`\"} para toda chamada de API no pipeline, garantindo que o Claude sempre extraia metadados antes que qualquer enriquecimento possa ocorrer.", "correct": false, "explanation": "Fixar `extract_metadata` em toda chamada impede que as ferramentas de enriquecimento sejam usadas."}], "correct": "C", "task_id": "2.3", "objective": "Distribute tools appropriately across agents and configure tool choice", "group": "B"}, {"id": "g16", "domain": 3, "scenario": "Claude Code para Integração Contínua", "situation": "Seu pipeline de CI executa o Claude Code CLI (em modo `--print`) usando CLAUDE.md para fornecer contexto do projeto para code review, e os devs em geral acham as reviews substantivas. Porém, eles relatam que integrar achados ao workflow é difícil — Claude emite parágrafos narrativos que precisam ser copiados manualmente para comentários no PR. O time quer postar automaticamente cada achado como comentário inline separado no local relevante do código, o que exige dados estruturados com path do arquivo, número da linha, nível de severidade e correção sugerida. Qual abordagem é mais efetiva?", "question": "Qual abordagem é mais efetiva?", "options": [{"letter": "A", "text": "Adicionar uma seção \"Output Format for Review\" ao CLAUDE.md com exemplos de achados estruturados para que Claude aprenda o formato esperado a partir do contexto do projeto.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Usar as flags do CLI `--output-format json` e `--json-schema` para forçar achados estruturados, depois parsear a saída para postar comentários inline via API do GitHub.", "correct": true, "explanation": "Usar `--output-format json` com `--json-schema` força saída estruturada no nível do CLI, garantindo JSON bem formado com os campos exigidos (path, linha, severidade, correção sugerida) que pode ser parseado de forma confiável e postado como comentários inline via API do GitHub. Aproveita capacidades nativas do CLI projetadas justamente para saída estruturada."}, {"letter": "C", "text": "Incluir instruções explícitas de formatação no prompt de review exigindo que cada achado siga um template parseável como `[FILE:path] [LINE:n] [SEVERITY:level] ...`.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Manter o formato narrativo de review mas adicionar um passo de sumarização que use Claude para gerar um sumário JSON estruturado dos achados.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.6", "objective": "Integrate Claude Code into CI/CD pipelines", "group": "D"}, {"id": "g26", "domain": 3, "scenario": "Claude Code para Integração Contínua", "situation": "Seu script de pipeline executa `claude \"Analyze this pull request for security issues\"`, mas o job trava indefinidamente. Logs mostram que o Claude Code está esperando entrada interativa. Qual é a abordagem correta para rodar Claude Code em pipeline automatizado?", "question": "Qual é a abordagem correta?", "options": [{"letter": "A", "text": "Adicionar a flag `--batch`: `claude --batch \"Analyze this pull request for security issues\"`.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Adicionar a flag `-p`: `claude -p \"Analyze this pull request for security issues\"`.", "correct": true, "explanation": "A flag `-p` (ou `--print`) é a forma documentada de rodar Claude Code em modo não-interativo. Processa o prompt, imprime o resultado no stdout e encerra sem esperar entrada do usuário — ideal para pipelines CI/CD."}, {"letter": "C", "text": "Redirecionar stdin de `/dev/null`: `claude \"Analyze this pull request for security issues\" < /dev/null`.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Definir a variável de ambiente `CLAUDE_HEADLESS=true` antes de executar o comando.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.6", "objective": "Integrate Claude Code into CI/CD pipelines", "group": "D"}, {"id": "g32", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Você precisa adicionar Slack como novo canal de notificação. A base existente tem padrões claros e estabelecidos para email, SMS e push. Porém, a API do Slack oferece abordagens fundamentalmente diferentes — webhooks de entrada (simples, unidirecional), bot tokens (suporte a confirmação de entrega e controle programático), ou Slack Apps (eventos bidirecionais, requer aprovação do workspace). Sua tarefa diz \"adicionar suporte a Slack\" sem especificar método de integração ou exigir features avançadas como tracking de entrega.", "question": "Como abordar essa tarefa?", "options": [{"letter": "A", "text": "Começar em modo de execução direta usando webhooks de entrada para casar com o padrão existente unidirecional.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Mudar para modo de planejamento para explorar opções de integração e implicações arquiteturais, depois apresentar uma recomendação antes da implementação.", "correct": true, "explanation": "Integração com Slack tem múltiplas abordagens válidas com implicações arquiteturais significativamente diferentes, e os requisitos são ambíguos. O modo de planejamento deixa avaliar trade-offs entre webhooks, bot tokens e Slack Apps e alinhar uma abordagem antes de implementar."}, {"letter": "C", "text": "Começar em execução direta fazendo scaffolding de uma classe de canal Slack usando padrões existentes, adiando a decisão do método de integração.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Começar em execução direta usando uma abordagem de bot-token para garantir que confirmação de entrega seja possível.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.4", "objective": "Determine when to use plan mode vs direct execution", "group": "C"}, {"id": "g33", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Seu CLAUDE.md cresceu para 400+ linhas contendo padrões de código, convenções de testes, um checklist detalhado de PR review, instruções de deploy e procedimentos de migração de banco. Você quer que Claude sempre siga padrões de código e convenções de testes, mas aplique guias de PR review, deploy e migration apenas quando estiver fazendo essas tarefas.", "question": "Qual abordagem de reestruturação é mais efetiva?", "options": [{"letter": "A", "text": "Mover toda a orientação para arquivos Skills separados organizados por tipo de fluxo, deixando apenas uma breve descrição do projeto no CLAUDE.md.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Manter tudo no CLAUDE.md mas usar sintaxe `@import` para organizar em arquivos mantidos separadamente por categoria.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Dividir o CLAUDE.md em arquivos sob `.claude/rules/` com padrões glob path-bound para que cada regra carregue só para os tipos de arquivo relevantes.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Manter padrões universais no CLAUDE.md e criar Skills para guias específicos de fluxo (PR review, deploy, migrations) com palavras-chave de gatilho.", "correct": true, "explanation": "Conteúdo do CLAUDE.md carrega em toda sessão, garantindo que padrões de código e convenções de teste sempre se apliquem, enquanto Skills são invocadas sob demanda quando Claude detecta palavras-chave de gatilho — ideal para guias específicos de fluxo como PR review, deploy e migrations."}], "correct": "D", "task_id": "3.1", "objective": "Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization", "group": "D"}, {"id": "g34", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Você foi designado para reestruturar a aplicação monolítica do seu time em microsserviços. Isso impacta mudanças em dezenas de arquivos e exige decisões sobre fronteiras de serviço e dependências de módulos.", "question": "Qual abordagem você deve escolher?", "options": [{"letter": "A", "text": "Mudar para modo de planejamento para explorar a base, entender dependências e desenhar a abordagem de implementação antes de fazer mudanças.", "correct": true, "explanation": "Modo de planejamento é a estratégia certa para reestruturação arquitetural complexa como dividir um monolito: permite exploração segura e decisões informadas sobre fronteiras antes de comprometer-se com mudanças potencialmente caras em muitos arquivos."}, {"letter": "B", "text": "Começar em execução direta e mudar para planejamento somente após encontrar complexidade inesperada durante a implementação.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Começar em execução direta e fazer mudanças incrementais, deixando a implementação revelar fronteiras naturais de serviço.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Usar execução direta com instruções detalhadas antecipadas que especificam a estrutura de cada serviço.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "3.4", "objective": "Determine when to use plan mode vs direct execution", "group": "C"}, {"id": "g35", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Seu time criou uma skill `/analyze-codebase` que faz análise profunda de código — varredura de dependências, contagem de cobertura de testes e métricas de qualidade. Após rodar o comando, membros do time relatam que Claude fica menos responsivo na sessão e perde o contexto da tarefa original.", "question": "Como você corrige isso de forma mais efetiva mantendo as capacidades plenas de análise?", "options": [{"letter": "A", "text": "Adicionar `context: fork` no frontmatter da skill para rodar a análise em contexto isolado de subagente.", "correct": true, "explanation": "`context: fork` roda a análise em contexto de subagente isolado, de modo que a saída grande não polui a janela de contexto da sessão principal e Claude não perde o rastro da tarefa original. Preserva capacidade plena de análise mantendo a sessão principal responsiva."}, {"letter": "B", "text": "Adicionar `model: haiku` no frontmatter para usar um modelo mais rápido e barato para análise.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Dividir a skill em três skills menores, cada uma produzindo menos saída.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Adicionar instruções à skill para comprimir todos os resultados em um sumário curto antes de exibi-los.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "3.2", "objective": "Create and configure custom slash commands and skills", "group": "D"}, {"id": "g36", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Seu time usa uma skill `/commit` em `.claude/skills/commit/SKILL.md`. Um dev quer customizá-la para seu fluxo pessoal (formato diferente de commit message, checagens extras) sem afetar colegas.", "question": "O que você recomenda?", "options": [{"letter": "A", "text": "Criar uma versão pessoal sob `~/.claude/skills/` com um nome diferente, ex.: `/my-commit`.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Adicionar lógica condicional baseada em username no frontmatter da skill do projeto.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Criar uma versão pessoal em `~/.claude/skills/commit/SKILL.md` com o mesmo nome.", "correct": true, "explanation": "Skills pessoais têm precedência sobre skills de projeto com o mesmo nome. Uma skill pessoal em `~/.claude/skills/commit/SKILL.md` sobrescreverá a do time, permitindo ao dev customizar seu fluxo enquanto mantém o nome familiar `/commit` para uso pessoal. Essa abordagem é melhor que A porque preserva o nome de comando original, melhorando o fluxo do dev sem afetar colegas."}, {"letter": "D", "text": "Definir `override: true` no frontmatter da skill pessoal para priorizá-la sobre a versão do projeto.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "3.2", "objective": "Create and configure custom slash commands and skills", "group": "D"}, {"id": "g37", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Seu time usa Claude Code há meses. Recentemente, três devs reportam que Claude segue a orientação \"sempre incluir tratamento abrangente de erros\", mas um quarto dev recém-chegado diz que Claude não a segue. Os quatro trabalham no mesmo repo e têm código atualizado.", "question": "Qual a causa mais provável e correção?", "options": [{"letter": "A", "text": "A orientação está nos arquivos de nível usuário `~/.claude/CLAUDE.md` dos devs originais, não no `.claude/CLAUDE.md` do projeto. Mover a instrução para o arquivo de nível projeto para que todos os membros recebam.", "correct": true, "explanation": "Se a orientação foi adicionada apenas aos configs de nível usuário dos devs originais e não ao `.claude/CLAUDE.md` do projeto, novos membros não a recebem. Mover para a configuração de nível projeto garante que todos os membros atuais e futuros recebam a orientação automaticamente."}, {"letter": "B", "text": "O `~/.claude/CLAUDE.md` do novo dev contém instruções conflitantes que sobrescrevem o projeto; ele deve apagar a seção conflitante.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Claude Code aprende preferências por usuário com o tempo; o novo dev precisa repetir o requisito até Claude \"lembrar\".", "correct": false, "explanation": ""}, {"letter": "D", "text": "Claude Code cacheia CLAUDE.md após a primeira leitura; os devs originais usam versões em cache. Todos devem limpar o cache.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "3.1", "objective": "Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization", "group": "D"}, {"id": "g38", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Você descobre que incluir 2–3 implementações completas de endpoint como contexto melhora significativamente a consistência ao gerar novos endpoints de API. Porém, esse contexto só é útil ao criar novos endpoints — não ao depurar, revisar código ou outros trabalhos no diretório de API.", "question": "Qual abordagem de configuração é mais efetiva?", "options": [{"letter": "A", "text": "Adicionar exemplos de endpoint e documentação de padrão ao CLAUDE.md do projeto para que estejam sempre disponíveis.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Referenciar manualmente exemplos de endpoint em cada solicitação de geração copiando código no prompt.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Configurar regras path-specific em `.claude/rules/api/` que incluam exemplos de endpoint e ativem ao trabalhar no diretório de API.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Criar uma skill que referencie os exemplos de endpoint e contenha instruções de seguimento de padrão, invocada sob demanda via slash command.", "correct": true, "explanation": "Uma skill invocada sob demanda carrega o contexto de exemplo apenas ao gerar novos endpoints, não em tarefas não relacionadas como depuração ou review. Isso mantém o contexto principal limpo enquanto preserva geração de alta qualidade quando necessária."}], "correct": "D", "task_id": "3.1", "objective": "Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization", "group": "D"}, {"id": "g39", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Seu time criou uma skill `/migration` que gera arquivos de migração de banco. Recebe o nome da migração via `$ARGUMENTS`. Em produção você observa três problemas: (1) devs frequentemente rodam a skill sem argumentos, causando arquivos mal nomeados, (2) a skill às vezes usa detalhes de schema de conversas anteriores não relacionadas, e (3) um dev rodou acidentalmente cleanup destrutivo de teste quando a skill tinha acesso amplo a ferramentas.", "question": "Qual abordagem de configuração corrige todos os três problemas?", "options": [{"letter": "A", "text": "Usar parâmetros posicionais `$1` e `$2` em vez de `$ARGUMENTS` para forçar entradas específicas, incluir referências explícitas a schema via sintaxe `@` para controle de contexto, e adicionar uma descrição no frontmatter alertando sobre operações destrutivas.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Adicionar `argument-hint` no frontmatter para pedir parâmetros obrigatórios, usar `context: fork` para isolar a execução, e restringir `allowed-tools` a operações de escrita de arquivo.", "correct": true, "explanation": "Usa três features de configuração separadas para tratar cada problema: `argument-hint` melhora a entrada de argumentos e reduz argumentos faltando, `context: fork` impede vazamento de contexto de conversas anteriores e `allowed-tools` restringe a skill a operações seguras de escrita de arquivo, prevenindo ações destrutivas."}, {"letter": "C", "text": "Dividir em `/migration-create` e `/migration-apply`, adicionar instruções de validação para pedir o nome da migração se faltar e usar escopos de `allowed-tools` diferentes para cada.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Adicionar instruções de validação no SKILL.md para garantir que `$ARGUMENTS` seja um nome válido, adicionar prompts para ignorar contexto de conversas anteriores e listar operações proibidas.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.2", "objective": "Create and configure custom slash commands and skills", "group": "D"}, {"id": "g40", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Sua base contém áreas com convenções de código diferentes: componentes React usam estilo funcional com hooks, handlers de API usam async/await com tratamento específico de erros e modelos de banco seguem o padrão repository. Arquivos de teste estão distribuídos pela base ao lado do código sob teste (ex.: `Button.test.tsx` ao lado de `Button.tsx`), e você quer que todos os testes sigam as mesmas convenções independentemente da localização.", "question": "Qual é a forma mais suportada de garantir que Claude aplique automaticamente as convenções corretas ao gerar código?", "options": [{"letter": "A", "text": "Colocar todas as convenções no CLAUDE.md raiz sob cabeçalhos por área e contar com Claude para inferir qual seção se aplica.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Criar skills em `.claude/skills/` para cada tipo de código, embutindo convenções em cada SKILL.md.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Colocar um arquivo CLAUDE.md separado em cada subdiretório com convenções para aquela área.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Criar arquivos de regra em `.claude/rules/` com frontmatter YAML especificando padrões glob para aplicar convenções condicionalmente baseadas em paths.", "correct": true, "explanation": "Arquivos `.claude/rules/` com frontmatter YAML e padrões glob (ex.: `**/*.test.tsx`, `src/api/**/*.ts`) permitem aplicação determinística e baseada em path de convenções independente da estrutura de diretórios. É a abordagem mais suportada para padrões cross-cutting como arquivos de teste distribuídos."}], "correct": "D", "task_id": "3.1", "objective": "Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization", "group": "D"}, {"id": "g41", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Você quer criar um slash command customizado `/review` que rode o checklist padrão de code review do seu time. Ele deve estar disponível para todo dev quando clonar ou atualizar o repositório.", "question": "Onde criar o arquivo do comando?", "options": [{"letter": "A", "text": "Em `~/.claude/commands/` no diretório home de cada dev.", "correct": false, "explanation": ""}, {"letter": "B", "text": "No repositório do projeto sob `.claude/commands/`.", "correct": true, "explanation": "Colocar slash commands customizados sob `.claude/commands/` dentro do repositório do projeto garante que estejam versionados e disponíveis automaticamente para todo dev que clone ou atualize o repo. É o local previsto para comandos customizados de nível projeto no Claude Code."}, {"letter": "C", "text": "Em `.claude/config.json` como array de comandos.", "correct": false, "explanation": ""}, {"letter": "D", "text": "No CLAUDE.md raiz do projeto.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.2", "objective": "Create and configure custom slash commands and skills", "group": "D"}, {"id": "g42", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "O CLAUDE.md do seu time cresceu além de 500 linhas misturando convenções TypeScript, orientação de testes, padrões de API e procedimentos de deploy. Devs têm dificuldade de localizar e atualizar as seções certas.", "question": "Qual abordagem o Claude Code suporta para organizar instruções de nível projeto em módulos tópicos focados?", "options": [{"letter": "A", "text": "Definir um `.claude/config.yaml` mapeando padrões de arquivo a seções específicas dentro do CLAUDE.md.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Criar arquivos Markdown separados em `.claude/rules/`, cada um cobrindo um tópico (ex.: `testing.md`, `api-conventions.md`).", "correct": true, "explanation": "Claude Code suporta um diretório `.claude/rules/` onde você pode criar arquivos Markdown separados para guias tópicos (ex.: `testing.md`, `api-conventions.md`), permitindo a times organizar grandes conjuntos de instruções em módulos focados e mantíveis."}, {"letter": "C", "text": "Dividir instruções em arquivos README.md em subdiretórios relevantes que Claude carrega automaticamente como instruções.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Criar múltiplos arquivos chamados CLAUDE.md em níveis diferentes da árvore de diretórios, cada um sobrescrevendo instruções pai.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.1", "objective": "Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization", "group": "D"}, {"id": "g43", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Você cria uma skill customizada `/explore-alternatives` que seu time usa para fazer brainstorming e avaliar abordagens de implementação antes de escolher uma. Devs reportam que após rodar a skill, respostas subsequentes do Claude são influenciadas pela discussão de alternativas — às vezes referenciando abordagens rejeitadas ou retendo contexto de exploração que interfere na implementação real.", "question": "Como configurar essa skill de forma mais efetiva?", "options": [{"letter": "A", "text": "Usar o prefixo `!` na skill para rodar lógica de exploração como subprocesso bash.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Adicionar `context: fork` no frontmatter da skill.", "correct": true, "explanation": "`context: fork` roda a skill em contexto isolado de subagente para que discussões de exploração não poluam o histórico da conversa principal. Isso impede que abordagens rejeitadas e contexto de brainstorming influenciem trabalho subsequente de implementação."}, {"letter": "C", "text": "Dividir em duas skills — `/explore-start` e `/explore-end` — para marcar fronteiras quando o contexto de exploração deve ser descartado.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Criar a skill em `~/.claude/skills/` em vez de `.claude/skills/`.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.2", "objective": "Create and configure custom slash commands and skills", "group": "D"}, {"id": "g44", "domain": 3, "scenario": "Geração de Código com Claude Code", "situation": "Seu time quer adicionar um servidor MCP do GitHub para buscar PRs e checar status de CI via Claude Code. Cada um dos seis devs tem seu próprio token pessoal de acesso ao GitHub. Você quer ferramental consistente em todo o time sem commitar credenciais no controle de versão.", "question": "Qual abordagem de configuração é mais efetiva?", "options": [{"letter": "A", "text": "Que cada dev adicione o servidor em escopo de usuário via `claude mcp add --scope user`.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Criar um wrapper de servidor MCP que leia tokens de um arquivo `.env` e proxie chamadas à API do GitHub, depois adicionar o wrapper ao `.mcp.json` do projeto.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar o servidor ao `.mcp.json` do projeto usando substituição de variável de ambiente (`${GITHUB_TOKEN}`) para auth e documentar a variável necessária no README.", "correct": true, "explanation": "Um `.mcp.json` de projeto com substituição de variável de ambiente é idiomático: fornece uma única fonte versionada de verdade para a configuração MCP enquanto deixa cada dev fornecer credenciais via variáveis de ambiente. Documentar a variável facilita o onboarding sem commitar segredos."}, {"letter": "D", "text": "Configurar o servidor no escopo de projeto com token placeholder, depois pedir aos devs que sobrescrevam no config local.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "2.4", "objective": "Integrate MCP servers into Claude Code and agent workflows", "group": "J"}, {"id": "m19", "domain": 3, "scenario": null, "situation": "Uma engenheira usou o `Claude Code` ontem para investigar fluxos de autenticação em um monolito legado, acumulando um contexto significativo ao longo de uma sessão de 2 horas. Hoje ela quer continuar essa investigação específica. Ela trabalhou em outras três bases de código desde então e sabe que a sessão se chamava \"auth-deep-dive\".", "question": "Como ela deve retomar?", "options": [{"letter": "A", "text": "Começar do zero e reler os mesmos arquivos", "correct": false, "explanation": "Desperdiça as duas horas de contexto acumulado de ontem."}, {"letter": "B", "text": "Usar `--session-id` com o UUID do arquivo de transcrição da sessão de ontem", "correct": false, "explanation": "Possível, mas trabalhoso — ela teria que caçar o UUID quando já tem o nome da sessão."}, {"letter": "C", "text": "Usar `--continue` para retomar de onde a conversa mais recente parou", "correct": false, "explanation": "`--continue` retoma a sessão mais recente neste repositório. Ela trabalhou em outras três bases de código desde então, então a mais recente não é a auth-deep-dive."}, {"letter": "D", "text": "Usar `--resume` auth-deep-dive para carregar essa sessão específica pelo nome", "correct": true, "explanation": "Correto. `--resume` com o nome da sessão foi projetado exatamente para isso: escolher uma sessão anterior específica dentre muitas, pelo nome que você deu a ela."}], "correct": "D", "task_id": "1.7", "objective": "Manage session state, resumption, and forking", "group": "A"}, {"id": "g17", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Seu time usa Claude Code para gerar sugestões de código, mas você nota um padrão: questões não-óbvias — otimizações de performance que quebram casos de borda, limpezas que mudam comportamento inesperadamente — só são pegas quando outro membro do time revisa o PR. O raciocínio do Claude durante a geração mostra que ele considerou esses casos mas concluiu que sua abordagem estava correta. Qual abordagem aborda diretamente a causa-raiz dessa limitação de auto-checagem?", "question": "Qual abordagem aborda diretamente a causa-raiz?", "options": [{"letter": "A", "text": "Rodar uma segunda instância independente do Claude Code para revisar as mudanças sem acesso ao raciocínio do gerador.", "correct": true, "explanation": "Uma segunda instância independente do Claude Code sem acesso ao raciocínio do gerador ataca diretamente a causa-raiz evitando viés de confirmação. Essa perspectiva de \"olhos novos\" espelha a peer review humana, em que outro revisor pega problemas que o autor racionalizou."}, {"letter": "B", "text": "Habilitar modo de extended thinking na geração para permitir deliberação mais minuciosa antes de produzir sugestões.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar instruções explícitas de auto-review ao prompt de geração pedindo que Claude critique suas próprias sugestões antes de finalizar.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Incluir arquivos de teste e documentação completos no contexto do prompt para que Claude entenda melhor o comportamento esperado durante a geração.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "4.6", "objective": "Design multi-instance and multi-pass review architectures", "group": "F"}, {"id": "g19", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Seu sistema CI/CD roda três análises baseadas em Claude: (1) checagens rápidas de estilo em todo PR que bloqueiam o merge até concluir, (2) auditorias semanais e abrangentes de segurança em toda a base, e (3) geração noturna de casos de teste para módulos recém-modificados. A Message Batches API oferece 50% de economia, mas o processamento pode levar até 24 horas. Você quer otimizar custo de API mantendo experiência aceitável para devs. Qual combinação casa corretamente cada tarefa com uma abordagem de API?", "question": "Qual combinação está correta?", "options": [{"letter": "A", "text": "Use a Message Batches API para todas as três tarefas para maximizar a economia de 50%, configurando o pipeline para fazer polling até a conclusão dos lotes.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Use chamadas síncronas para checagens de estilo em PR; use a Message Batches API para auditorias semanais de segurança e geração noturna de testes.", "correct": true, "explanation": "Checagens de estilo em PR bloqueiam devs e exigem respostas imediatas via síncronas, enquanto auditorias semanais e geração noturna de testes são tarefas agendadas com prazos flexíveis que toleram a janela de até 24 horas — capturando 50% de economia em ambas."}, {"letter": "C", "text": "Use chamadas síncronas para todas para tempos de resposta consistentes, contando com prompt caching para reduzir custos.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Use chamadas síncronas para checagens de estilo em PR e geração noturna de testes; use a Message Batches API apenas para auditorias semanais.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "4.5", "objective": "Design efficient batch processing strategies", "group": "H"}, {"id": "g20", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Suas reviews automatizadas encontram problemas reais, mas devs reportam que o feedback não é acionável. Achados incluem frases como \"lógica complexa de roteamento de tickets\" ou \"potencial null pointer\" sem especificar o que exatamente mudar. Quando você adiciona instruções detalhadas como \"sempre inclua sugestões concretas de correção\", o modelo ainda produz saída inconsistente — às vezes detalhada, às vezes vaga. Qual técnica de prompting produz feedback consistentemente acionável de forma mais confiável?", "question": "Qual técnica de prompting é mais confiável?", "options": [{"letter": "A", "text": "Refinar mais as instruções com requisitos mais explícitos para cada parte do formato de feedback (location, issue, severity, proposed fix).", "correct": false, "explanation": ""}, {"letter": "B", "text": "Expandir a janela de contexto para incluir mais código adjacente para que o modelo tenha informação suficiente para propor correções concretas.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Implementar uma abordagem em duas passagens em que um prompt identifica problemas e outro gera correções, permitindo especialização.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Adicionar 3–4 exemplos few-shot mostrando o formato exato exigido: problema identificado, localização no código, sugestão concreta de correção.", "correct": true, "explanation": "Exemplos few-shot são a técnica mais efetiva para alcançar formato consistente quando instruções sozinhas produzem resultados variáveis. Fornecer 3–4 exemplos que mostram a estrutura desejada (issue, location, concrete fix) dá ao modelo um padrão concreto a seguir, mais confiável que instruções abstratas."}], "correct": "D", "task_id": "3.5", "objective": "Apply iterative refinement techniques for progressive improvement", "group": "I"}, {"id": "g21", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Seu pipeline CI inclui dois modos de code review baseados em Claude: um hook pré-merge-commit que bloqueia o merge do PR até concluir, e uma \"análise profunda\" que roda à noite, faz polling até concluir o lote e posta sugestões detalhadas no PR. Você quer reduzir custo de API usando a Message Batches API, que oferece 50% de economia mas exige polling e pode levar até 24 horas. Qual modo deveria usar processamento em lote?", "question": "Qual modo deveria usar processamento em lote?", "options": [{"letter": "A", "text": "Apenas o hook pré-merge-commit.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Apenas a análise profunda.", "correct": true, "explanation": "Análise profunda é candidata ideal para processamento em lote porque já roda à noite, tolera atraso e usa um modelo de polling antes de publicar resultados — o que casa com a arquitetura assíncrona baseada em polling da Message Batches API enquanto captura 50% de economia."}, {"letter": "C", "text": "Ambos os modos.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Nenhum dos modos.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "4.5", "objective": "Design efficient batch processing strategies", "group": "H"}, {"id": "g22", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Sua review automatizada analisa comentários e docstrings. O prompt atual instrui Claude a \"verificar que comentários estão precisos e atualizados\". Achados frequentemente sinalizam padrões aceitáveis (marcadores TODO, descrições simples) enquanto perdem comentários que descrevem comportamento que o código não implementa mais. Qual mudança ataca a causa-raiz dessa análise inconsistente?", "question": "Qual mudança ataca a causa-raiz?", "options": [{"letter": "A", "text": "Incluir dados de `git blame` para que Claude possa identificar comentários anteriores a mudanças recentes de código.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Adicionar exemplos few-shot de comentários enganosos para ajudar o modelo a reconhecer padrões similares na base.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Filtrar TODO, FIXME e padrões de comentários descritivos antes da análise para reduzir ruído.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Especificar critérios explícitos: marcar comentários apenas quando o comportamento que afirmam contradiz o comportamento real do código.", "correct": true, "explanation": "Critérios explícitos — marcar comentários apenas quando o comportamento afirmado contradiz o comportamento real do código — atacam diretamente a causa-raiz substituindo uma instrução vaga por uma definição precisa do que constitui um problema. Isso reduz falsos positivos em padrões aceitáveis e perdas de comentários genuinamente enganosos."}], "correct": "D", "task_id": "4.1", "objective": "Design prompts with explicit criteria to improve precision and reduce false positives", "group": "I"}, {"id": "g23", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Seu sistema de code review automatizado mostra severidades inconsistentes — questões similares como riscos de null pointer são classificadas \"critical\" em alguns PRs mas só \"medium\" em outros. Pesquisas com devs mostram desconfiança crescente — muitos começam a descartar achados sem ler porque \"metade está errada\". Categorias com altas taxas de falsos positivos minam a confiança em categorias acuradas. Qual abordagem melhor restaura a confiança dos devs enquanto melhora o sistema?", "question": "Qual abordagem melhor restaura a confiança dos devs?", "options": [{"letter": "A", "text": "Desabilitar temporariamente categorias de alto FP (estilo, naming, documentação) e manter apenas categorias de alta precisão enquanto melhora os prompts.", "correct": true, "explanation": "Desabilitar temporariamente categorias com alto FP interrompe imediatamente a erosão de confiança removendo achados ruidosos que levam devs a descartar tudo, preservando valor de categorias de alta precisão como segurança e correção. Também cria espaço para melhorar prompts das categorias problemáticas antes de reabilitá-las."}, {"letter": "B", "text": "Manter todas as categorias mas exibir scores de confiança junto a cada achado para que devs decidam o que investigar.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Manter todas as categorias e adicionar exemplos few-shot para melhorar a acurácia em cada categoria nas próximas semanas.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Aplicar uma redução uniforme de rigor em todas as categorias para baixar a taxa geral de FP.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "4.1", "objective": "Design prompts with explicit criteria to improve precision and reduce false positives", "group": "I"}, {"id": "g24", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Sua review automatizada gera sugestões de casos de teste para cada PR. Revisando um PR que adiciona tracking de conclusão de curso, Claude sugere 10 casos de teste, mas o feedback dos devs mostra que 6 duplicam cenários já cobertos pela suíte de testes existente. Qual mudança reduz duplicação de forma mais efetiva?", "question": "Qual mudança é mais efetiva?", "options": [{"letter": "A", "text": "Incluir o arquivo de teste existente no contexto para que Claude possa determinar quais cenários já estão cobertos.", "correct": true, "explanation": "Incluir o arquivo de teste existente corrige a causa-raiz da duplicação: Claude só pode evitar sugerir cenários já cobertos se souber quais testes já existem. Isso dá a Claude a informação necessária para propor testes genuinamente novos e valiosos."}, {"letter": "B", "text": "Reduzir o número solicitado de sugestões de 10 para 5, assumindo que Claude prioriza os casos mais valiosos primeiro.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar instruções direcionando Claude a focar exclusivamente em casos de borda e condições de erro em vez de caminhos felizes.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Implementar pós-processamento que filtra sugestões cujas descrições casam com nomes de testes existentes via sobreposição de palavras-chave.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "3.5", "objective": "Apply iterative refinement techniques for progressive improvement", "group": "I"}, {"id": "g25", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Após uma review automatizada inicial identificar 12 achados, um dev faz push de novos commits para tratar os problemas. Re-rodar a review produz 8 achados, mas devs reportam que 5 duplicam comentários anteriores em código que já foi corrigido nos novos commits. Qual é a forma mais efetiva de eliminar esse feedback redundante mantendo a profundidade?", "question": "Qual é a forma mais efetiva de eliminar feedback redundante?", "options": [{"letter": "A", "text": "Rodar review apenas quando o PR é criado e no estado final pré-merge, pulando commits intermediários.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Adicionar um filtro de pós-processamento que remove achados que casam com anteriores por path e descrição antes de postar comentários.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Restringir o escopo da review aos arquivos alterados no push mais recente, excluindo arquivos de commits anteriores.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Incluir achados de reviews anteriores no contexto e instruir Claude a reportar apenas problemas novos ou ainda não resolvidos.", "correct": true, "explanation": "Incluir achados de reviews anteriores no contexto deixa Claude distinguir problemas novos dos já tratados em commits recentes. Isso preserva profundidade da review enquanto usa o raciocínio do Claude para evitar feedback redundante em código já corrigido."}], "correct": "D", "task_id": "4.1", "objective": "Design prompts with explicit criteria to improve precision and reduce false positives", "group": "I"}, {"id": "g27", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Um pull request altera 14 arquivos em um módulo de tracking de inventário. Uma review de única passagem que analisa todos os arquivos juntos produz resultados inconsistentes: feedback detalhado em alguns arquivos mas comentários superficiais em outros, bugs óbvios não detectados e feedback contraditório (um padrão é marcado em um arquivo mas código idêntico aprovado em outro arquivo no mesmo PR). Como reestruturar a review?", "question": "Como reestruturar a review?", "options": [{"letter": "A", "text": "Rodar três passagens independentes de review do PR completo e marcar apenas problemas que aparecem em pelo menos duas das três execuções.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Dividir em passagens focadas: revisar cada arquivo individualmente para problemas locais, depois rodar uma passagem separada orientada a integração para examinar fluxos de dados cross-file.", "correct": true, "explanation": "Passagens focadas por arquivo atacam a causa-raiz — diluição de atenção — garantindo profundidade consistente e detecção confiável de problemas locais. Uma passagem separada de integração cobre questões cross-file como dependências e interações de fluxo de dados."}, {"letter": "C", "text": "Exigir que devs dividam PRs grandes em submissões menores de 3–4 arquivos antes de rodar review automatizada.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Mudar para um modelo maior com janela de contexto maior para que ele possa atender suficientemente todos os 14 arquivos em uma passagem.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "4.6", "objective": "Design multi-instance and multi-pass review architectures", "group": "F"}, {"id": "g28", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Sua review automatizada média 15 achados por PR e devs reportam taxa de FP de 40%. O gargalo é tempo de investigação: devs precisam clicar em cada achado para ler a justificativa do Claude antes de decidir corrigir ou descartar. Seu CLAUDE.md já contém regras abrangentes para padrões aceitáveis e stakeholders rejeitaram qualquer abordagem que filtre achados antes de devs verem. Qual mudança melhor ataca o tempo de investigação?", "question": "Qual mudança ataca melhor o tempo de investigação?", "options": [{"letter": "A", "text": "Exigir que Claude inclua sua justificativa e estimativa de confiança diretamente em cada achado.", "correct": true, "explanation": "Incluir justificativa e confiança diretamente em cada achado reduz tempo de investigação ao deixar devs triar rapidamente sem abrir cada achado. Satisfaz a restrição de \"não filtrar\" porque todos os achados permanecem visíveis enquanto acelera a tomada de decisão."}, {"letter": "B", "text": "Adicionar um pós-processador que analisa padrões de achados e suprime automaticamente os que casam com assinaturas históricas de FP.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Categorizar achados como \"blocking issues\" vs \"suggestions\", com requisitos de revisão diferentes por nível.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Configurar Claude para mostrar apenas achados de alta confiança, filtrando flags incertas antes de devs verem.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "4.6", "objective": "Design multi-instance and multi-pass review architectures", "group": "F"}, {"id": "g29", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "A análise da sua review automatizada de código mostra grandes diferenças nas taxas de falsos positivos por categoria de achado: achados de segurança/correção têm 8% de FP, performance 18%, estilo/naming 52% e documentação 48%. Pesquisas com devs mostram desconfiança crescente — muitos começam a descartar achados sem ler porque \"metade está errada\". Categorias de alto FP minam a confiança em categorias acuradas. Qual abordagem melhor restaura a confiança dos devs enquanto melhora o sistema?", "question": "Qual abordagem melhor restaura a confiança dos devs?", "options": [{"letter": "A", "text": "Desabilitar temporariamente categorias de alto FP (estilo, naming, documentação) e manter apenas categorias de alta precisão enquanto melhora os prompts.", "correct": true, "explanation": "Desabilitar temporariamente categorias com alto FP interrompe imediatamente a erosão de confiança removendo achados ruidosos que levam devs a descartar tudo, preservando valor de categorias de alta precisão como segurança e correção. Também cria espaço para melhorar prompts das categorias problemáticas antes de reabilitá-las."}, {"letter": "B", "text": "Manter todas as categorias mas exibir scores de confiança junto a cada achado para que devs decidam o que investigar.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Manter todas as categorias e adicionar exemplos few-shot para melhorar a acurácia em cada categoria nas próximas semanas.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Aplicar uma redução uniforme de rigor em todas as categorias para baixar a taxa geral de FP.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "4.1", "objective": "Design prompts with explicit criteria to improve precision and reduce false positives", "group": "I"}, {"id": "g30", "domain": 4, "scenario": "Claude Code para Integração Contínua", "situation": "Seu time quer reduzir custos de API para análise automatizada. Atualmente, chamadas síncronas ao Claude atendem dois fluxos: (1) checagem bloqueante pré-merge que precisa concluir antes de devs poderem mergear, e (2) relatório de tech-debt gerado de noite para revisão na manhã seguinte. Seu gerente propõe mover ambos para a Message Batches API para economizar 50%. Como avaliar essa proposta?", "question": "Como avaliar essa proposta?", "options": [{"letter": "A", "text": "Mover ambos para processamento em lote com fallback para chamadas síncronas se os lotes demorarem demais.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Mover ambos os fluxos para processamento em lote com polling de status para verificar conclusão.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Use processamento em lote apenas para relatórios de tech-debt; mantenha chamadas síncronas para checagens pré-merge.", "correct": true, "explanation": "O processamento da Message Batches API pode levar até 24 horas sem SLA de latência, o que é aceitável para relatórios de tech-debt noturnos mas inaceitável para checagens pré-merge bloqueantes em que devs esperam. Isso casa cada fluxo com a API certa baseada em requisitos de latência."}, {"letter": "D", "text": "Manter chamadas síncronas para ambos os fluxos para evitar problemas com ordenação de resultados em lote.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "4.5", "objective": "Design efficient batch processing strategies", "group": "H"}, {"id": "g31", "domain": 4, "scenario": "Geração de Código com Claude Code", "situation": "Você pediu ao Claude Code para implementar uma função que transforma respostas de API em um formato interno normalizado. Após duas iterações, a estrutura de saída ainda não casa com as expectativas — alguns campos são aninhados de modo diferente e timestamps formatados incorretamente. Você descreveu requisitos em prosa, mas Claude os interpreta de forma diferente a cada vez.", "question": "Qual abordagem é mais efetiva para a próxima iteração?", "options": [{"letter": "A", "text": "Escrever um JSON schema descrevendo a estrutura de saída esperada e validar a saída do Claude contra ele após cada iteração.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Fornecer 2–3 exemplos concretos de entrada-saída mostrando a transformação esperada para respostas representativas da API.", "correct": true, "explanation": "Exemplos concretos de entrada-saída removem a ambiguidade inerente a descrições em prosa mostrando a Claude o resultado exato esperado da transformação. Isso ataca diretamente a causa-raiz — interpretação errada de requisitos textuais — fornecendo padrões inequívocos para aninhamento e formatação de timestamp."}, {"letter": "C", "text": "Reescrever requisitos com mais precisão técnica, especificando mapeamentos exatos de campos, regras de aninhamento e strings de formato de timestamp.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Pedir ao Claude para explicar seu entendimento atual dos requisitos para identificar onde as interpretações divergem.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "3.5", "objective": "Apply iterative refinement techniques for progressive improvement", "group": "I"}, {"id": "g49", "domain": 4, "scenario": "Agente de Suporte ao Cliente", "situation": "Seu agente atinge 55% de resolução no primeiro contato, bem abaixo da meta de 80%. Logs mostram que ele escala casos simples (substituições padrão para mercadorias danificadas com prova fotográfica) enquanto tenta lidar autonomamente com situações complexas que exigem exceções de política. Qual é a forma mais efetiva de melhorar a calibração de escalonamento?", "question": "Qual é a forma mais efetiva de melhorar a calibração?", "options": [{"letter": "A", "text": "Exigir que o agente auto-classifique confiança em escala 1–10 antes de cada resposta e roteie automaticamente para humanos quando a confiança cair abaixo de um limiar.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Implantar um modelo classificador separado treinado em tickets históricos para prever quais pedidos precisam de escalonamento antes de o agente principal começar.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar critérios explícitos de escalonamento ao system prompt com exemplos few-shot mostrando quando escalar vs resolver autonomamente.", "correct": true, "explanation": "Critérios explícitos de escalonamento com exemplos few-shot atacam diretamente a causa-raiz — limites de decisão pouco claros entre casos simples e complexos. É a primeira intervenção mais proporcional e efetiva, ensinando o agente quando escalar e quando resolver autonomamente sem infraestrutura extra."}, {"letter": "D", "text": "Implementar análise de sentimento para determinar nível de frustração do cliente e escalar automaticamente acima de um limiar de sentimento negativo.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.2", "objective": "Design effective escalation and ambiguity resolution patterns", "group": "C"}, {"id": "g52", "domain": 4, "scenario": "Agente de Suporte ao Cliente", "situation": "Métricas de produção mostram que ao resolver disputas complexas de cobrança ou devoluções multi-pedido, scores de satisfação do cliente são 15% menores que para casos simples — mesmo quando a resolução está tecnicamente correta. Análise de causa-raiz mostra que o agente fornece soluções acuradas mas explica a justificativa de forma inconsistente: às vezes omitindo detalhes relevantes de política, às vezes perdendo info de timeline ou próximos passos. As lacunas de contexto variam caso a caso. Você quer melhorar qualidade da solução sem adicionar supervisão humana. Qual abordagem é mais efetiva?", "question": "Qual abordagem é mais efetiva?", "options": [{"letter": "A", "text": "Adicionar uma etapa de auto-crítica em que o agente avalia uma resposta de rascunho quanto à completude — garantindo que resolva o problema, inclua contexto relevante e antecipe perguntas de follow-up.", "correct": true, "explanation": "Uma etapa de auto-crítica (padrão evaluator-optimizer) ataca diretamente a completude inconsistente das explicações forçando o agente a avaliar seu próprio rascunho contra critérios concretos — como contexto de política, timelines e próximos passos — antes de apresentá-lo. Isso captura lacunas específicas do caso sem supervisão humana."}, {"letter": "B", "text": "Adicionar uma etapa de confirmação em que o agente pergunta \"Isso resolve totalmente seu problema?\" antes de fechar, permitindo que clientes peçam informações adicionais.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Atualizar o modelo de Haiku para Sonnet em casos complexos, roteando com base em uma métrica de complexidade definida.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Implementar exemplos few-shot no system prompt mostrando explicações completas para cinco tipos comuns de casos complexos, demonstrando como incluir contexto de política, timelines e próximos passos.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "3.5", "objective": "Apply iterative refinement techniques for progressive improvement", "group": "I"}, {"id": "g56", "domain": 4, "scenario": "Agente de Suporte ao Cliente", "situation": "Logs de produção mostram um padrão consistente: quando clientes incluem a palavra \"conta\" em sua mensagem (ex.: \"quero verificar minha conta de um pedido que fiz ontem\"), o agente chama `get_customer` primeiro 78% das vezes. Quando clientes formulam pedidos similares sem \"conta\" (ex.: \"quero verificar um pedido que fiz ontem\"), chama `lookup_order` primeiro 93% das vezes. As descrições das ferramentas são claras e inequívocas. Qual a causa-raiz mais provável dessa discrepância?", "question": "Qual a causa-raiz mais provável?", "options": [{"letter": "A", "text": "O system prompt contém instruções sensíveis a palavras-chave que direcionam comportamento baseado em termos como \"conta\", criando padrões não intencionais de seleção de ferramenta.", "correct": true, "explanation": "O padrão sistemático dirigido por palavra-chave (78% vs 93%) indica fortemente lógica explícita de roteamento no system prompt reagindo à palavra \"conta\" e direcionando o agente a ferramentas relacionadas ao cliente. Como as descrições já são claras, a discrepância aponta para instruções no nível do prompt criando direcionamento comportamental não intencional."}, {"letter": "B", "text": "O treinamento base do modelo cria associações entre terminologia de \"conta\" e operações relacionadas ao cliente que sobrepõem descrições de ferramentas.", "correct": false, "explanation": ""}, {"letter": "C", "text": "O modelo precisa de mais dados de treino sobre mensagens multi-conceito e deveria ser fine-tuned em exemplos contendo terminologias de conta e pedido.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Descrições de ferramentas precisam de exemplos negativos adicionais especificando quando NÃO usar cada ferramenta para evitar essa confusão induzida por palavras-chave.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "4.1", "objective": "Design prompts with explicit criteria to improve precision and reduce false positives", "group": "I"}, {"id": "g60", "domain": 4, "scenario": "Agente de Suporte ao Cliente", "situation": "Logs de produção mostram que o agente às vezes escolhe `get_customer` quando `lookup_order` seria mais apropriado, especialmente para queries ambíguas como \"preciso de ajuda com minha compra recente\". Você decide adicionar exemplos few-shot ao system prompt para melhorar a seleção. Qual abordagem trata o problema de forma mais efetiva?", "question": "Qual abordagem é mais efetiva?", "options": [{"letter": "A", "text": "Adicionar orientações explícitas \"use quando\" e \"não use quando\" em cada descrição de ferramenta cobrindo casos ambíguos.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Adicionar exemplos agrupados por ferramenta — todos os cenários de `get_customer` juntos, depois todos os cenários de `lookup_order`.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Adicionar 4–6 exemplos direcionados a cenários ambíguos, cada um com justificativa de por que uma ferramenta foi escolhida em detrimento de alternativas plausíveis.", "correct": true, "explanation": "Direcionar exemplos few-shot aos cenários ambíguos específicos onde os erros ocorrem, com justificativa explícita de por que uma ferramenta é preferível, ensina ao modelo o processo de decisão comparativo necessário para casos de borda. Mais efetivo que exemplos genéricos ou regras declarativas."}, {"letter": "D", "text": "Adicionar 10–15 exemplos de pedidos claros e inequívocos demonstrando escolha correta para cenários típicos de cada ferramenta.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "2.1", "objective": "Design effective tool interfaces with clear descriptions and boundaries", "group": "J"}, {"id": "g69", "domain": 4, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Durante testes de QA, Claude segue diretrizes do system prompt nos primeiros 10–15 turnos, mas respostas posteriores desviam. A conversa ainda está dentro dos limites de tokens.", "question": "Qual a melhor solução?", "options": [{"letter": "A", "text": "Mover diretrizes comportamentais para a primeira mensagem do usuário.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Iniciar nova conversa após 20 turnos.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Inserir mensagens com role user reforçando diretrizes em pontos de interrupção da conversa.", "correct": true, "explanation": "A injeção periódica de lembretes comportamentais combate diretamente a deriva de instrução restabelecendo restrições em intervalos regulares conforme o histórico se acumula. Mover diretrizes para a primeira mensagem do usuário (A) reduz sua autoridade. Iniciar nova conversa (B) destrói contexto. Validação pós-resposta (D) é corretiva em vez de preventiva e adiciona latência significativa."}, {"letter": "D", "text": "Usar validação pós-resposta para regenerar respostas não conformes.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g71", "domain": 4, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Seu assistente precisa manter um tom entusiástico, explicar seu raciocínio e fazer perguntas esclarecedoras. Onde essas diretrizes comportamentais devem ser definidas?", "question": "Onde essas diretrizes comportamentais devem ser definidas?", "options": [{"letter": "A", "text": "Prependendo a cada mensagem do usuário.", "correct": false, "explanation": ""}, {"letter": "B", "text": "No system prompt.", "correct": true, "explanation": "O system prompt é especificamente desenhado para restrições e diretrizes comportamentais persistentes que se aplicam ao longo de toda a conversa. Prependê-las a cada mensagem do usuário (A) é overhead redundante. A primeira mensagem do assistente (C) não é confiável porque o modelo pode desviar de suas próprias declarações anteriores. Variáveis de ambiente (D) não têm efeito sobre o comportamento do modelo."}, {"letter": "C", "text": "Na primeira mensagem do assistente.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Em variáveis de ambiente.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g72", "domain": 4, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Usuários reportam aberturas de resposta repetitivas como \"Certamente!\" e \"Ficarei feliz em ajudar!\".", "question": "Qual a abordagem mais efetiva?", "options": [{"letter": "A", "text": "Anexar uma mensagem parcial do assistente com uma abertura direta.", "correct": true, "explanation": "Pré-preencher a resposta do assistente com o início de uma resposta direta evita padrões de saudação no nível de geração — o modelo continua a partir do prefill em vez de gerar novas frases de abertura. Instruções no system prompt (D) podem ajudar mas são menos confiáveis pois o modelo ainda pode produzir variantes. Pós-processamento (C) é um workaround frágil. Temperatura (B) controla aleatoriedade, não padrões específicos de frase."}, {"letter": "B", "text": "Reduzir o ajuste de temperatura.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Pós-processar respostas para remover saudações.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Adicionar instruções no system prompt para evitar essas frases.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "4.3", "objective": "Enforce structured output using tool use and JSON schemas", "group": "H"}, {"id": "g73", "domain": 4, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Um webhook notifica seu sistema de que o pacote do usuário foi enviado enquanto o usuário está conversando ativamente. Você quer que o assistente incorpore isso naturalmente na próxima resposta.", "question": "Qual a melhor abordagem?", "options": [{"letter": "A", "text": "Adicionar status de envio ao system prompt.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Enviar imediatamente uma mensagem sintética do usuário.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Forçar o assistente a chamar uma ferramenta de status a cada turno.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Anexar a atualização de status como prefixo à próxima mensagem do usuário.", "correct": true, "explanation": "Prefixar a atualização de status à próxima mensagem do usuário injeta contexto em tempo real em uma fronteira natural da conversa sem perturbar o fluxo. Modificar o system prompt (A) exige reconstruir a sessão ou é arquiteturalmente custoso. Uma mensagem sintética do usuário (B) pode quebrar o fluxo natural do diálogo e confundir atribuição. Forçar uma chamada de ferramenta a cada turno (C) é desperdício quando eventos são raros."}], "correct": "D", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g74", "domain": 4, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Usuários frequentemente enviam pedidos como \"Reserve um local para a festa\". O assistente faz 4+ perguntas esclarecedoras, causando 35% de abandono.", "question": "Qual abordagem melhora melhor o trade-off?", "options": [{"letter": "A", "text": "Prosseguir com defaults ocultos.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Fazer todas as perguntas esclarecedoras em uma única mensagem composta.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Declarar suposições explicitamente e prosseguir convidando correções.", "correct": true, "explanation": "Declarar suposições explicitamente e prosseguir dá ao usuário uma resposta imediata e útil enquanto preserva sua capacidade de corrigir suposições erradas. Defaults ocultos (A) deixam o usuário sem saber o que foi assumido. Uma lista composta de perguntas (B) ainda exige esforço inicial do usuário. Um formulário estruturado (D) adiciona mais atrito, não menos — contradiz o objetivo de reduzir abandono."}, {"letter": "D", "text": "Usar um formulário estruturado de coleta.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.2", "objective": "Design effective escalation and ambiguity resolution patterns", "group": "C"}, {"id": "g76", "domain": 4, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Usuários fazem pedidos vagos como \"Pode ajudar com o relatório?\". O assistente responde fazendo várias perguntas (qual relatório? que ajuda? prazo?), causando 40% de abandono.", "question": "Qual a melhor solução?", "options": [{"letter": "A", "text": "Fazer suposições razoáveis, declará-las explicitamente e oferecer ajustes.", "correct": true, "explanation": "Prosseguir com suposições razoáveis declaradas elimina totalmente o vai-e-vem mantendo o usuário informado e no controle. Interpretações silenciosas predefinidas (C) deixam usuários confusos quando a resposta não casa com sua intenção. Um limite de uma pergunta (D) ainda exige turnos de vai-e-vem. Um modelo menor de classificação (B) adiciona latência e complexidade de infraestrutura sem resolver o problema central de UX."}, {"letter": "B", "text": "Classificar a ambiguidade com um modelo menor antes de responder.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Usar interpretações predefinidas sem declarar suposições.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Limitar o assistente a uma pergunta esclarecedora por turno.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "5.2", "objective": "Design effective escalation and ambiguity resolution patterns", "group": "C"}, {"id": "m8", "domain": 4, "scenario": null, "situation": "Revisões em produção revelam um tratamento inconsistente da incerteza nos relatórios finais. Às vezes, descobertas conflitantes dos subagentes são sintetizadas em uma única afirmação confiante (perdendo a nuance), enquanto outras vezes os relatórios fazem ressalvas em excesso com qualificações exageradas (tornando-se inúteis). Quando o agente de busca na web retorna \"analistas do setor estimam um mercado de US$ 50 bi (a metodologia varia)\" e o agente de análise de documentos retorna \"estudo revisado por pares estima 35 bi (±7 bi, IC 95%)\", o coordenador ou escolhe um arbitrariamente ou produz afirmações vagas como \"o mercado pode ser de 35 bi a 50 bi dependendo de fatores\".", "question": "Qual abordagem sistemática aborda melhor isso?", "options": [{"letter": "A", "text": "Configurar os subagentes para relatar apenas descobertas que atendam a um limite de alta confiança, filtrando informações incertas antes que cheguem ao coordenador.", "correct": false, "explanation": "A filtragem descarta evidências úteis, porém incertas. Ela não ajuda o agente de síntese a raciocinar sobre conflitos — apenas os esconde."}, {"letter": "B", "text": "Implementar uma camada de calibração de confiança que normaliza as expressões de incerteza dos subagentes em pontuações de probabilidade padronizadas (0,0 a 1,0) e, em seguida, faz a média ponderada das descobertas por sua confiança calibrada.", "correct": false, "explanation": "Reduzir os ICs revisados por pares e as estimativas de analistas a um único número médio destrói a diferença metodológica que é o cerne da questão."}, {"letter": "C", "text": "Instruir o agente de síntese a estruturar os relatórios com seções explícitas que distinguem descobertas bem estabelecidas das contestadas, preservando as caracterizações das fontes originais e o contexto metodológico.", "correct": true, "explanation": "Correto. Uma estrutura de relatório que mantém o contexto metodológico e separa afirmações consolidadas das contestadas é como se obtém nuance sem ressalvas em excesso."}, {"letter": "D", "text": "Adicionar um subagente de verificação que faz referência cruzada das descobertas entre as fontes, passando para a síntese apenas as afirmações corroboradas por ao menos duas fontes independentes.", "correct": false, "explanation": "Mínimos de duas fontes descartam descobertas legítimas de fonte única e não resolvem estimativas genuinamente conflitantes com metodologias diferentes."}], "correct": "C", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "m11", "domain": 4, "scenario": null, "situation": "Um usuário está expandindo o sistema de pesquisa além de seu único agente de busca na web, adicionando fontes de dados especializadas. Ele adiciona um agente de API financeira que retorna JSON estruturado com receita, margens e taxas de crescimento; um agente de monitoramento de notícias que retorna resumos em prosa de acontecimentos recentes; e um agente de análise de patentes que retorna listas estruturadas de áreas de tecnologia. O agente de síntese combina tudo isso em briefings executivos. Atualmente, ele converte tudo em tópicos, fazendo com que as comparações financeiras percam a clareza tabular e os resumos de notícias percam o fluxo narrativo.", "question": "Qual mudança melhoraria mais a qualidade do briefing?", "options": [{"letter": "A", "text": "Padronizar todas as saídas dos subagentes como resumos em prosa com citações em linha.", "correct": false, "explanation": "Achatar dados financeiros estruturados em prosa perde a comparabilidade que você deseja em um briefing executivo."}, {"letter": "B", "text": "Adicionar uma camada de conversão de formato entre os subagentes e a síntese que transforma todas as saídas em uma representação intermediária comum.", "correct": false, "explanation": "Uma única representação intermediária costuma acabar com perdas demais — ou mantém a estrutura (as notícias sofrem) ou mantém a prosa (as tabelas sofrem). A correção é renderização ciente do tipo, não uniformidade."}, {"letter": "C", "text": "Atualizar o agente de síntese para renderizar cada tipo de conteúdo de forma apropriada — dados financeiros como tabelas, notícias como prosa.", "correct": true, "explanation": "Correto. Briefings executivos precisam de renderização mista: tabelas para números, prosa para narrativa. Pedir à síntese que preserve o formato nativo de cada entrada é a abstração certa."}, {"letter": "D", "text": "Padronizar todas as saídas dos subagentes como JSON com campos para afirmação, evidência, fonte e confiança.", "correct": false, "explanation": "Forçar notícias densas em prosa em um esquema de afirmação/evidência retira o fluxo narrativo que os executivos realmente leem."}], "correct": "C", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "m46", "domain": 4, "scenario": null, "situation": "Seu sistema de extração processa dois tipos de documentos: relatórios mensais padrão (arquivados após o processamento) e relatórios de exceção urgentes (que devem disparar alertas de negócio em até 30 minutos do recebimento). Ambos usam o mesmo esquema JSON. Você quer minimizar os custos de API atendendo aos requisitos de latência.", "question": "Como você deve arquitetar o pipeline de processamento?", "options": [{"letter": "A", "text": "Enviar todos os documentos para a Messages API em tempo real, garantindo latência de processamento consistente entre os tipos de documento.", "correct": false, "explanation": "Consistente, porém caro. Os relatórios mensais padrão não precisam de latência em tempo real e não deveriam pagar por ela."}, {"letter": "B", "text": "Enviar todos os documentos para a `Batch API` com `custom_ids` para rastreamento. Quando os resultados chegarem, processar imediatamente os documentos urgentes e disparar alertas atrasados para as exceções.", "correct": false, "explanation": "O batch tem uma janela de até 24 horas — SLAs de alerta de 30 minutos para relatórios de exceção não podem ser atendidos roteando-os pelo batch."}, {"letter": "C", "text": "Enfileirar todos os documentos e enviar batches a cada hora, sinalizando os documentos urgentes para tratamento acelerado quando os resultados do batch retornarem.", "correct": false, "explanation": "Batches a cada hora ainda dependem do SLO do batch e não garantem a janela de alerta de 30 minutos para as exceções."}, {"letter": "D", "text": "Rotear os relatórios padrão para a `Batch API`, obtendo 50% de economia de custo, e rotear os relatórios de exceção urgentes para a Messages API em tempo real.", "correct": true, "explanation": "Correto. Combine o perfil de latência com a urgência do documento: batch para o volume (barato), tempo real para as exceções sensíveis à latência (rápido). Minimiza o custo atendendo ao SLA."}], "correct": "D", "task_id": "4.5", "objective": "Design efficient batch processing strategies", "group": "H"}, {"id": "m47", "domain": 4, "scenario": null, "situation": "Seu esquema inclui um campo skills: string[]. O monitoramento em produção revela três problemas de consistência: (1) frases compostas como \"Python and SQL\" às vezes são mantidas como uma única entrada, às vezes divididas; (2) habilidades implícitas, mas não declaradas, ocasionalmente aparecem nas extrações; (3) documentos semelhantes produzem comprimentos de array muito diferentes (5-10 vs. 40+ entradas). Seu prompt atualmente diz \"Extract all skills mentioned.\"", "question": "Qual é a melhoria mais eficaz?", "options": [{"letter": "A", "text": "Adicionar exemplos few-shot demonstrando o tratamento de frases compostas, critérios explícitos de menção e a granularidade adequada das entradas.", "correct": true, "explanation": "Correto. Os três problemas dizem respeito à interpretação do modelo sobre o que conta como 'uma habilidade'. Exemplos few-shot ensinam o padrão de forma concreta — dividir ou não dividir, mencionado ou inferido, granularidade adequada."}, {"letter": "B", "text": "Adicionar restrições: \"Extract 10-20 skills maximum, one skill per entry, only explicitly named skills.\"", "correct": false, "explanation": "Limites rígidos de contagem são arbitrários e podem forçar o modelo a descartar habilidades reais ou inventar preenchimento para atingir a faixa."}, {"letter": "C", "text": "Adicionar uma normalização pós-extração que mapeia as habilidades para uma taxonomia canônica e deduplica entradas semelhantes.", "correct": false, "explanation": "O pós-processamento não consegue corrigir habilidades inferidas, mas não mencionadas, nem escolher a divisão correta para 'Python and SQL' — essa decisão precisa ser tomada no momento da extração."}, {"letter": "D", "text": "Enriquecer o esquema para {skill: string, confidence: float, `source_quote`: string}[] para capturar metadados da extração.", "correct": false, "explanation": "Sinal útil, mas não trata a inconsistência subjacente na forma como as habilidades são interpretadas em primeiro lugar."}], "correct": "A", "task_id": "4.2", "objective": "Apply few-shot prompting to improve output consistency and quality", "group": "I"}, {"id": "m48", "domain": 4, "scenario": null, "situation": null, "question": "Seu sistema opera com revisão humana de 100% há 3 meses. A análise mostra que extrações com confiança do modelo >90% têm 97% de precisão no geral. Para reduzir a carga de trabalho dos revisores, você planeja automatizar as extrações de alta confiança. Antes de implantar, qual etapa de validação é a mais crítica?", "options": [{"letter": "A", "text": "Analisar a precisão por tipo de documento e por campo para verificar se as extrações de alta confiança têm desempenho consistente em todos os segmentos, e não apenas no agregado.", "correct": true, "explanation": "Correto. A precisão agregada esconde falhas por segmento — um tipo de documento pode estar em 70% enquanto outros estão em 99%. O roteamento automático apenas pelo número global arrisca erros sistêmicos nos segmentos fracos."}, {"letter": "B", "text": "Comparar a precisão em diferentes limiares de confiança (85%, 90%, 95%) para encontrar o ponto de corte ótimo que maximiza a automação minimizando os erros.", "correct": false, "explanation": "Ajustar o limiar vale a pena, mas só depois de saber que a precisão se mantém uniformemente entre os segmentos — caso contrário, você está otimizando um número que mente."}, {"letter": "C", "text": "Executar um piloto de duas semanas roteando 25% das extrações de alta confiança diretamente para os sistemas downstream e monitorar os relatórios de erro.", "correct": false, "explanation": "Um piloto é uma boa prática, mas vem depois da análise por segmento — se um segmento estiver sistematicamente errado, você só descobrirá prejudicando os usuários."}, {"letter": "D", "text": "Verificar se a precisão de 97% atende aos requisitos de todos os sistemas downstream que consomem os dados extraídos.", "correct": false, "explanation": "Uma questão de produto importante, mas que pressupõe que os 97% se mantêm em todos os lugares — de novo, é justamente isso que a análise por segmento verifica primeiro."}], "correct": "A", "task_id": "5.5", "objective": "Design human review workflows and confidence calibration", "group": "C"}, {"id": "m49", "domain": 4, "scenario": null, "situation": "Seu pipeline de extração processa contratos que frequentemente incluem aditivos. Quando um contrato contém tanto os termos originais quanto aditivos posteriores (por exemplo, a cláusula original especifica \"30-day payment terms\" enquanto o Aditivo 1 altera isso para \"45 days\"), o modelo extrai de forma inconsistente um valor ou o outro, sem indicar qual se aplica.", "question": "Qual é a abordagem mais eficaz para melhorar a precisão da extração em documentos com aditivos?", "options": [{"letter": "A", "text": "Redesenhar o esquema para que os campos alterados capturem múltiplos valores, cada um com sua localização na fonte e data de vigência.", "correct": true, "explanation": "Correto. Aditivos são estruturalmente sobre valores versionados. Um esquema com valor + localização na fonte + data de vigência modela o domínio corretamente e deixa de forçar o modelo a escolher um único."}, {"letter": "B", "text": "Adicionar instruções no prompt para sempre extrair o valor do aditivo mais recente e ignorar os termos originais substituídos.", "correct": false, "explanation": "Os consumidores downstream às vezes também precisam do original (por exemplo, para resolução de disputas). Fixar 'o mais recente prevalece' descarta isso."}, {"letter": "C", "text": "Pré-processar os documentos com um classificador que identifica e remove as seções substituídas antes da etapa principal de extração.", "correct": false, "explanation": "Apagar seções com um classificador pode remover acidentalmente conteúdo que ainda está legalmente vigente — aditivos frequentemente modificam apenas subconjuntos de cláusulas."}, {"letter": "D", "text": "Implementar uma validação pós-extração usando correspondência de padrões para detectar aditivos e sinalizar essas extrações para revisão manual.", "correct": false, "explanation": "Roteia todo contrato com aditivo para um humano — caro, e ainda assim não fornece aos sistemas downstream uma resposta estruturada."}], "correct": "A", "task_id": "4.3", "objective": "Enforce structured output using tool use and JSON schemas", "group": "H"}, {"id": "m50", "domain": 4, "scenario": null, "situation": "Seu sistema de extração implementa novas tentativas automáticas quando a validação falha. A cada nova tentativa, o erro de validação específico é anexado ao prompt. Essa abordagem de nova tentativa com feedback de erro resolve a maioria das falhas em 2-3 tentativas.", "question": "Para qual padrão de falha novas tentativas seriam MENOS eficazes?", "options": [{"letter": "A", "text": "O modelo extrai palavras-chave como um objeto aninhado organizado por categoria quando o esquema exige um array plano de strings", "correct": false, "explanation": "Uma incompatibilidade estrutural que o modelo definitivamente consegue corrigir com feedback sobre o formato esperado."}, {"letter": "B", "text": "O modelo extrai contagens de citações como strings formatadas conforme o local (\"1,234\") quando o esquema exige inteiros", "correct": false, "explanation": "O número exigido está presente no documento — o modelo só precisa parar de formatá-lo. Fácil de corrigir com nova tentativa por feedback."}, {"letter": "C", "text": "O modelo extrai datas como strings de data e hora ISO 8601 (\"2023-03-15T00:00:00Z\") quando o esquema exige apenas a parte da data (YYYY-MM-DD)", "correct": false, "explanation": "Correção puramente de formato — o valor subjacente está correto e o modelo pode remover a parte da hora na nova tentativa."}, {"letter": "D", "text": "O modelo extrai \"et al.\" para coautores quando a lista completa existe apenas em um documento externo que não está na entrada", "correct": true, "explanation": "Correto. Nenhuma quantidade de novas tentativas ensina ao modelo informações que não estão na entrada. A nova tentativa com feedback de erro só corrige erros que o modelo poderia ter acertado a partir da fonte."}], "correct": "D", "task_id": "3.5", "objective": "Apply iterative refinement techniques for progressive improvement", "group": "I"}, {"id": "m51", "domain": 4, "scenario": null, "situation": "Seu pipeline de extração processa cardápios de restaurantes e deve produzir um JSON estruturado com campos para nomes dos itens, descrições, preços e tags dietéticas. Alguns cardápios usam formatação inconsistente — preços como \"$12\" vs. \"12.00\", informação dietética como ícones vs. texto.", "question": "Qual é a abordagem mais confiável?", "options": [{"letter": "A", "text": "Usar chamadas de extração separadas para cada campo, garantindo o tratamento consistente de cada tipo.", "correct": false, "explanation": "Múltiplas chamadas por cardápio multiplicam custo e latência e perdem o contexto entre campos (por exemplo, quais ícones dietéticos ficam ao lado de quais itens)."}, {"letter": "B", "text": "Extrair os dados como estão e normalizar os formatos em código de pós-processamento depois que o Claude retornar.", "correct": false, "explanation": "Pós-processar um blob bruto é frágil — código determinístico tem que lidar com todas as permutações de formato. É melhor deixar o modelo normalizar no momento da extração."}, {"letter": "C", "text": "Solicitar várias tentativas de extração por documento e selecionar o formato mais comum.", "correct": false, "explanation": "A votação por conjunto é cara e ainda pode escolher uma maioria com formato errado."}, {"letter": "D", "text": "Definir um esquema de saída estrito e incluir regras de normalização de formato no seu prompt.", "correct": true, "explanation": "Correto. Esquema estrito + regras de normalização explícitas ('preços como decimal com duas casas', 'dietético como tags enumeradas') permite ao modelo extrair e normalizar em uma única passada."}], "correct": "D", "task_id": "4.2", "objective": "Apply few-shot prompting to improve output consistency and quality", "group": "I"}, {"id": "m52", "domain": 4, "scenario": null, "situation": "Seu sistema extrai metadados de eventos (data, local, organizador, `attendee_count`) de artigos de notícias usando um esquema JSON com todos os campos anuláveis. Durante a avaliação, você observa que o modelo frequentemente gera valores plausíveis, porém incorretos, para campos não mencionados no artigo — por exemplo, gerando \"500\" para `attendee_count` quando a fonte não contém nenhuma informação de público.", "question": "Qual é a maneira mais eficaz de reduzir essas extrações falsas?", "options": [{"letter": "A", "text": "Adicionar uma etapa de pós-processamento usando uma segunda chamada de LLM para verificar se cada valor extraído existe no documento de origem.", "correct": false, "explanation": "Uma segunda passada cara para um comportamento que você pode corrigir na fonte — diga ao modelo para retornar null quando o campo não estiver declarado."}, {"letter": "B", "text": "Adicionar instruções no prompt para retornar null em qualquer campo cuja informação não esteja diretamente declarada na fonte.", "correct": true, "explanation": "Correto. Os campos já são anuláveis; o modelo só precisa de uma instrução explícita para preferir null em vez de um palpite plausível. Essa é a correção padrão para alucinação consciente do esquema."}, {"letter": "C", "text": "Tornar todos os campos do esquema obrigatórios (não anuláveis) com regras de validação estritas para garantir que o modelo só produza dados verificáveis.", "correct": false, "explanation": "Campos obrigatórios forçam o modelo a inventar valores quando a informação está ausente — o oposto do que você quer."}, {"letter": "D", "text": "Migrar para um nível de modelo mais capaz, com melhor aderência a instruções, para reduzir a tendência a alucinações.", "correct": false, "explanation": "Adiciona custo e ainda assim não comunica sua política ao modelo — retornar null em vez de inventar."}], "correct": "B", "task_id": "4.3", "objective": "Enforce structured output using tool use and JSON schemas", "group": "H"}, {"id": "m53", "domain": 4, "scenario": null, "situation": "Depois de implementar o uso de ferramentas com definições de esquema estritas, os erros de sintaxe JSON foram eliminados, mas 5% das extrações ainda têm JSON válido com arrays vazios ou valores nulos para campos obrigatórios como citações e metodologia. Uma verificação por amostragem revela que os documentos de origem contêm essas informações, mas em formatos variados — citações inline vs. bibliografias, seções de metodologia vs. detalhes embutidos nas introduções.", "question": "Qual é a maneira mais eficaz de tratar essas falhas?", "options": [{"letter": "A", "text": "Implementar uma lógica de nova tentativa que reenvia as requisições quando a validação detecta campos obrigatórios vazios.", "correct": false, "explanation": "Uma nova tentativa com o mesmo prompt não vai, de repente, ensinar o modelo a reconhecer metodologia embutida numa introdução. A capacidade de extração é a lacuna."}, {"letter": "B", "text": "Construir uma camada de pós-processamento baseada em regex que varre os documentos de origem em busca de padrões de citação e palavras-chave de metodologia, preenchendo os campos vazios quando o modelo falha em extrair.", "correct": false, "explanation": "Regex sobre prosa é frágil, perde os casos sutis (metodologia embutida na introdução) e entrega dados silenciosamente errados."}, {"letter": "C", "text": "Modificar seu esquema para tornar citações e metodologia opcionais e sinalizar os registros incompletos para revisão manual em vez de falhar na validação.", "correct": false, "explanation": "Mascara o sintoma. Os campos realmente são obrigatórios downstream — roteá-los para humanos troca um problema pela carga de trabalho dos revisores."}, {"letter": "D", "text": "Adicionar exemplos few-shot demonstrando extrações de documentos com estruturas variadas — mostrando como identificar citações em diferentes formatos e localizar detalhes de metodologia em tipos diferentes de seção.", "correct": true, "explanation": "Correto. O modo de falha é o modelo não reconhecer formatos variados. Exemplos concretos ao longo da distribuição de formatos elevam diretamente a revocação nos 5%."}], "correct": "D", "task_id": "4.2", "objective": "Apply few-shot prompting to improve output consistency and quality", "group": "I"}, {"id": "m54", "domain": 4, "scenario": null, "situation": "Seu pipeline de extração processa faturas e extrai itens de linha, subtotais, valores de impostos e totais gerais. Durante a avaliação, você descobre que em 18% das extrações a soma dos valores dos itens de linha extraídos não corresponde ao total geral extraído — às vezes por erros de OCR no documento de origem, às vezes por erros de extração do modelo. Os sistemas contábeis downstream rejeitam registros com totais discrepantes.", "question": "Qual é a abordagem mais eficaz para melhorar a confiabilidade da extração?", "options": [{"letter": "A", "text": "Adicionar um campo \"`calculated_total`\", em que o modelo soma os itens de linha extraídos, ao lado de um campo \"`stated_total`\". Sinalizar os registros para revisão humana quando os valores diferirem.", "correct": true, "explanation": "Correto. Capturar ambos os valores transforma a discrepância em um sinal de primeira classe — você detecta erros de OCR e erros de extração de forma uniforme e pode rotear apenas os 18% discrepantes para humanos."}, {"letter": "B", "text": "Extrair os itens de linha e os totais de forma independente e, então, usar um modelo de validação separado para reconciliar as discrepâncias, determinando quais valores extraídos são mais prováveis de estar corretos.", "correct": false, "explanation": "Um modelo de reconciliação pode mascarar erros de OCR ao escolher silenciosamente um número em vez do outro — o sistema contábil ainda recebe dados errados sem nenhuma sinalização."}, {"letter": "C", "text": "Adicionar exemplos few-shot demonstrando faturas em que os itens de linha extraídos somam corretamente ao total declarado, incentivando o modelo a produzir extrações matematicamente consistentes.", "correct": false, "explanation": "Pode incentivar o modelo rumo à consistência, mas quando a própria fonte é internamente inconsistente (erros de OCR), o modelo tem que escolher um número 'errado'."}, {"letter": "D", "text": "Implementar um pós-processamento que ajusta automaticamente os valores dos itens de linha de forma proporcional quando a soma deles não corresponde ao total declarado.", "correct": false, "explanation": "Reescritas silenciosas de dados financeiros são perigosas — você estaria fabricando itens de linha para um sistema contábil downstream."}], "correct": "A", "task_id": "4.2", "objective": "Apply few-shot prompting to improve output consistency and quality", "group": "I"}, {"id": "m56", "domain": 4, "scenario": null, "situation": "Sua extração usa uso de ferramentas com um esquema JSON em que `property_type` é definido como um enum: ['house', 'apartment', 'condo', 'townhouse']. Após a implantação, 8% das extrações falham na validação do esquema. A investigação revela que os anúncios mencionam muitos tipos de imóvel incomuns — \"studio\", \"loft\", \"duplex\", \"mobile home\", \"tiny house\", \"converted warehouse\" — e novos tipos continuam surgindo regularmente.", "question": "Qual é a solução de longo prazo mais eficaz?", "options": [{"letter": "A", "text": "Expandir continuamente o enum para incluir os tipos de imóvel recém-observados e adicionar monitoramento para casos extremos adicionais.", "correct": false, "explanation": "Manutenção do enum tipo 'enxuga-gelo' — cada novo estilo de anúncio arrisca outra falha de validação."}, {"letter": "B", "text": "Adicionar um valor \"other\" ao seu enum, com um campo string `property_type_detail` separado para as especificidades quando \"other\" for selecionado.", "correct": true, "explanation": "Correto. Mantém o enum forte para os casos comuns (joins downstream limpos) ao mesmo tempo em que oferece uma válvula de escape bem tipada que preserva o detalhe. Estável no longo prazo."}, {"letter": "C", "text": "Mudar `property_type` de enum para uma string de formato livre e implementar uma etapa de normalização no pós-processamento.", "correct": false, "explanation": "Perde por completo a garantia de validação e empurra o problema de normalização para downstream sem nenhum vocabulário canônico."}, {"letter": "D", "text": "Adicionar exemplos few-shot ao seu prompt demonstrando como mapear tipos de imóvel inesperados para o valor de enum existente mais próximo.", "correct": false, "explanation": "Forçar 'tiny house' para dentro de 'house' descarta distinções reais downstream — você está sendo silenciosamente lossy."}], "correct": "B", "task_id": "4.3", "objective": "Enforce structured output using tool use and JSON schemas", "group": "H"}, {"id": "m57", "domain": 4, "scenario": null, "situation": "Seu sistema de extração analisa descrições de produtos de e-commerce para extrair especificações como dimensões, peso e materiais em JSON. Apesar de ter um esquema bem definido, o modelo extrai o campo \"materials\" de forma inconsistente — às vezes retornando \"cotton blend\", outras vezes \"Cotton/Polyester mix\" e, ocasionalmente, omitindo o campo quando a informação de material está claramente presente na fonte.", "question": "Qual é a maneira mais eficaz de melhorar a consistência da extração?", "options": [{"letter": "A", "text": "Tornar o campo \"materials\" obrigatório em vez de opcional no esquema para forçar o modelo a sempre extrair um valor", "correct": false, "explanation": "A obrigatoriedade não resolve a inconsistência de formato e pode forçar valores inventados quando a informação de material realmente está ausente."}, {"letter": "B", "text": "Migrar para um nível de modelo mais capaz, já que a extração inconsistente indica capacidade de modelo insuficiente", "correct": false, "explanation": "Caro, e não trata a causa real — o modelo não conhece o formato de saída canônico que você quer."}, {"letter": "C", "text": "Definir a temperatura como 0 para eliminar a aleatoriedade e garantir saídas determinísticas", "correct": false, "explanation": "O determinismo não define o formato correto; apenas torna consistentes as respostas com formato errado."}, {"letter": "D", "text": "Adicionar exemplos few-shot mostrando 2-3 pares completos de entrada-saída com formatos padronizados de descrição de material", "correct": true, "explanation": "Correto. Exemplos few-shot demonstram o formato canônico exato que você quer ('cotton/polyester' como uma lista normalizada) e também elevam a revocação da informação de material que estava sendo ignorada."}], "correct": "D", "task_id": "4.2", "objective": "Apply few-shot prompting to improve output consistency and quality", "group": "I"}, {"id": "m58", "domain": 4, "scenario": null, "situation": "Documentos chegam continuamente ao longo do horário comercial e precisam ter dados estruturados extraídos. Para reduzir custos, você quer usar a `Message Batches API` (50% de desconto, janela de processamento de até 24 horas). Seu SLA especifica que os resultados da extração devem estar disponíveis em até 30 horas da chegada do documento, com 99,9% de confiabilidade.", "question": "Qual estratégia de batch é a mais apropriada?", "options": [{"letter": "A", "text": "Enviar batches a cada 6 horas contendo os documentos daquela janela", "correct": false, "explanation": "No pior caso, um documento espera 6 horas para ser inserido em um batch e, depois, até 24 horas para ser processado = exatamente 30 horas. Sem margem de segurança para uma meta de confiabilidade de 99,9%."}, {"letter": "B", "text": "Enviar um único batch no fim do dia contendo todos os documentos daquele dia", "correct": false, "explanation": "Um documento que chega logo após o início da manhã espera o dia inteiro para ser inserido no batch, mais até 24 horas de processamento — bem acima das 30 horas."}, {"letter": "C", "text": "Enviar batches a cada 4 horas contendo os documentos daquela janela", "correct": true, "explanation": "Correto. Espera máxima de 4 horas + SLO de batch de até 24 horas = pior caso de 28 horas, deixando uma folga de 2 horas abaixo do SLA de 30 horas para absorver a variação do batch e atingir 99,9%."}, {"letter": "D", "text": "Usar a API em tempo real para todos os documentos em vez do processamento em batch", "correct": false, "explanation": "Atende ao SLA trivialmente, mas joga fora a economia de 50% de custo que a questão pede para capturar."}], "correct": "C", "task_id": "4.5", "objective": "Design efficient batch processing strategies", "group": "H"}, {"id": "m59", "domain": 4, "scenario": null, "situation": "Após a implantação, você descobre que 12% das extrações contêm erros semânticos que passam na validação do esquema JSON (por exemplo, uma duração como \"30 minutes\" colocada incorretamente em um campo de quantidade de ingrediente). Os revisores humanos têm capacidade para verificar apenas 20% das extrações.", "question": "Qual abordagem aloca a atenção dos revisores de forma mais eficaz?", "options": [{"letter": "A", "text": "Fazer o modelo gerar pontuações de confiança no nível de campo e, então, calibrar os limiares de revisão usando um conjunto de validação rotulado.", "correct": true, "explanation": "Correto. A confiança no nível de campo permite rotear os 20% de baixa confiança — onde se concentram os 12% de erros semânticos — para humanos. A calibração torna a escolha do limiar orientada por dados."}, {"letter": "B", "text": "Amostrar aleatoriamente 20% das extrações para revisão, usando as correções para acompanhar a precisão e identificar padrões de erro.", "correct": false, "explanation": "Ótimo para medição, ruim para cobertura — a amostragem aleatória só captura 20% dos 12% de erros (~2,4% no total). O roteamento por confiança encontra muito mais."}, {"letter": "C", "text": "Priorizar a revisão de todas as extrações em que campos obrigatórios estão vazios ou explicitamente marcados como não encontrados.", "correct": false, "explanation": "Campos vazios são um modo de erro estreito. O problema dos 12% são valores errados em campos preenchidos, que esse filtro não detecta."}, {"letter": "D", "text": "Revisar todas as extrações de documentos com anomalias de formatação, como layouts incomuns ou tipos de conteúdo mistos.", "correct": false, "explanation": "Uma heurística útil, mas anomalia de formatação não prevê de forma confiável onde os campos foram confundidos uns com os outros."}], "correct": "A", "task_id": "5.5", "objective": "Design human review workflows and confidence calibration", "group": "C"}, {"id": "g13", "domain": 5, "scenario": "Sistema de Pesquisa Multiagente", "situation": "O monitoramento de produção mostra qualidade inconsistente de síntese. Quando os resultados agregados têm ~75K tokens, o agente de síntese cita de forma confiável informações dos primeiros 15K tokens (manchetes/snippets de busca web) e dos últimos 10K (conclusões da análise de documentos), mas frequentemente perde achados críticos nos 50K do meio — mesmo quando respondem diretamente à pergunta de pesquisa. Como reestruturar a entrada agregada?", "question": "Como reestruturar a entrada agregada?", "options": [{"letter": "A", "text": "Sumarizar todas as saídas dos subagentes para abaixo de 20K tokens antes da agregação para manter o conteúdo dentro do alcance confiável de processamento do modelo.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Streamar incrementalmente os resultados dos subagentes ao agente de síntese, processando primeiro os de busca web até concluir e depois adicionando os de análise de documentos.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Posicionar um sumário de achados-chave no início da entrada agregada e organizar resultados detalhados com cabeçalhos de seção explícitos para navegação mais fácil.", "correct": true, "explanation": "Posicionar um sumário de achados-chave no início aproveita o efeito de primazia, colocando informação crítica na posição de processamento mais confiável. Adicionar cabeçalhos de seção explícitos ajuda o modelo a navegar e atender ao conteúdo do meio, mitigando diretamente o fenômeno \"lost in the middle\"."}, {"letter": "D", "text": "Implementar rotação que alterne quais resultados aparecem primeiro entre tarefas de pesquisa para garantir que ambas as fontes ganhem posição superior ao longo do tempo.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g14", "domain": 5, "scenario": "Sistema de Pesquisa Multiagente", "situation": "Em testes, a saída combinada do agente de busca web (85K tokens incluindo conteúdo de páginas) e do agente de análise de documentos (70K tokens incluindo cadeias de raciocínio) totaliza 155K tokens, mas o agente de síntese performa melhor com entradas abaixo de 50K tokens. Qual solução é mais efetiva?", "question": "Qual solução é mais efetiva?", "options": [{"letter": "A", "text": "Modificar agentes upstream para retornar dados estruturados (fatos-chave, citações, scores de relevância) em vez de conteúdo verboso e raciocínio.", "correct": true, "explanation": "Modificar agentes upstream para retornar dados estruturados ataca a causa-raiz reduzindo o volume de tokens na origem enquanto preserva informação essencial. Evita passar conteúdo volumoso de páginas e traços de raciocínio que inflam tokens sem melhorar a etapa de síntese."}, {"letter": "B", "text": "Adicionar um agente intermediário de sumarização que condense achados antes de passá-los à síntese.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Fazer o agente de síntese processar achados em lotes sequenciais, mantendo estado entre chamadas.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Armazenar achados em uma base vetorial e dar ao agente de síntese ferramentas de busca para consultar durante o trabalho.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "5.6", "objective": "Preserve information provenance and handle uncertainty in multi-source synthesis", "group": "B"}, {"id": "g45", "domain": 5, "scenario": "Geração de Código com Claude Code", "situation": "Você está adicionando wrappers de tratamento de erros ao redor de chamadas de API externas em uma base de 120 arquivos. O trabalho tem três fases: (1) descobrir todos os call sites e padrões, (2) desenhar colaborativamente a abordagem de tratamento de erros, e (3) implementar wrappers de forma consistente. Na Fase 1, Claude gera saída grande listando centenas de call sites com contexto, enchendo rapidamente a janela de contexto antes da descoberta terminar.", "question": "Qual abordagem é mais efetiva para concluir a tarefa mantendo consistência de implementação?", "options": [{"letter": "A", "text": "Usar um subagente Explore para a Fase 1 para isolar saída verbosa de descoberta e retornar um sumário, depois continuar Fases 2–3 na conversa principal.", "correct": true, "explanation": "Um subagente Explore isola a saída verbosa de descoberta em contexto separado e retorna apenas um sumário conciso à conversa principal. Isso preserva a janela de contexto principal para as fases de design colaborativo e implementação consistente, em que contexto retido é mais valioso."}, {"letter": "B", "text": "Fazer todas as fases na conversa principal, periodicamente usando `/compact` para reduzir uso de contexto enquanto avança nos arquivos.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Mudar para modo headless com `--continue`, passando sumários explícitos de contexto entre chamadas em batch para manter continuidade.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Definir o padrão de tratamento de erros no CLAUDE.md, depois processar arquivos em lotes em múltiplas sessões contando com o arquivo de memória compartilhada para consistência.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "5.4", "objective": "Manage context effectively in large codebase exploration", "group": "G"}, {"id": "g54", "domain": 5, "scenario": "Agente de Suporte ao Cliente", "situation": "Logs de produção mostram um padrão: clientes referenciam valores específicos (ex.: \"o desconto de 15% que mencionei\"), mas o agente responde com valores incorretos. Investigação mostra que esses detalhes foram mencionados 20+ turnos atrás e condensados em sumários vagos como \"preços promocionais foram discutidos\". Qual correção é mais efetiva?", "question": "Qual correção é mais efetiva?", "options": [{"letter": "A", "text": "Aumentar o limiar de sumarização de 70% para 85% para que conversas tenham mais espaço antes de a sumarização disparar.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Armazenar histórico completo da conversa em armazenamento externo e implementar recuperação quando o agente detectar referências como \"como mencionei\".", "correct": false, "explanation": ""}, {"letter": "C", "text": "Extrair fatos transacionais (valores, datas, números de pedido) para um bloco persistente de \"case facts\" incluído em todo prompt fora do histórico sumarizado.", "correct": true, "explanation": "Sumarização inerentemente perde detalhes precisos. Extrair fatos transacionais para um bloco estruturado \"case facts\" fora do histórico sumarizado preserva informação crítica para que esteja disponível de forma confiável em todo prompt, independente de quantos turnos foram sumarizados."}, {"letter": "D", "text": "Revisar o prompt de sumarização para preservar explicitamente todos os números, percentuais, datas e expectativas declaradas pelo cliente verbatim.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g63", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Ao longo de vários turnos discutindo estratégia de investimento, um usuário declarou \"tenho tolerância a risco muito baixa\" e depois \"quero maximizar meus retornos\". Agora ele pergunta: \"Em que devo investir?\"", "question": "Qual abordagem melhor garante que a recomendação se alinhe com a prioridade real do usuário?", "options": [{"letter": "A", "text": "Trazer à tona a contradição e pedir ao usuário que esclareça o que importa mais.", "correct": true, "explanation": "Quando preferências do usuário se contradizem diretamente, trazer o conflito à tona e pedir esclarecimento é a única forma de garantir que a recomendação se alinhe com a real intenção do usuário. Qualquer outra abordagem envolve assumir algo que pode estar errado — maximizar retornos e baixa tolerância a risco são objetivos fundamentalmente incompatíveis que exigem decisão humana."}, {"letter": "B", "text": "Fornecer recomendações separadas para ambos os cenários.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Prosseguir com a preferência declarada mais recentemente.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Recomendar um portfólio balanceado sem tratar do conflito.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g64", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Usuários refinam preferências de playlist em vários turnos. Duas mensagens depois de o usuário dizer \"amo jazz\", Claude pergunta \"Quais gêneros você gosta?\".", "question": "Qual a causa mais provável?", "options": [{"letter": "A", "text": "Claude exige conexão com base vetorial para manter memória de conversa.", "correct": false, "explanation": ""}, {"letter": "B", "text": "A janela de contexto do modelo foi excedida.", "correct": false, "explanation": ""}, {"letter": "C", "text": "A Claude API exige um parâmetro `session_id`.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Sua aplicação não está incluindo as mensagens anteriores no array `messages`.", "correct": true, "explanation": "Claude não tem memória do lado do servidor — toda chamada de API é stateless. Sem incluir o histórico completo no array `messages` de cada requisição, Claude não tem conhecimento de turnos anteriores. Bases vetoriais (A) e `session_id` (C) não fazem parte da arquitetura do Claude; estouro de janela de contexto (B) é impossível em troca de duas mensagens."}], "correct": "D", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g65", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Após uma sessão culinária de 40 minutos, a conversa atinge 78.000 tokens. O histórico inclui alergias, escala de receitas, termos culinários esclarecidos e discussão geral. Você precisa reduzir tokens preservando informação importante.", "question": "Qual abordagem melhor balanceia preservação e redução de tokens?", "options": [{"letter": "A", "text": "Sumarizar todo o histórico da conversa.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Manter apenas os 20.000 tokens mais recentes.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Extrair dados estruturados críticos (alergias, quantidades, preferências), sumarizar a discussão geral e manter trocas recentes verbatim.", "correct": true, "explanation": "A abordagem híbrida preserva a informação de maior valor ao menor custo. Fatos críticos como alergias e quantidades são extraídos para um bloco estruturado compacto (evitando perda de precisão que ocorre na sumarização), discussão geral é sumarizada e trocas recentes mantidas verbatim para coerência conversacional. A e B arriscam perder informação dietética crítica; D é overkill arquitetural para uma única sessão."}, {"letter": "D", "text": "Armazenar a conversa completa externamente e recuperar partes relevantes via busca semântica.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g66", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Usuários reportam que durante conversas extensas o assistente perde o rastro de tópicos e preferências anteriores. Sua implementação atual mantém apenas os últimos 25 pares de mensagens.", "question": "Qual a solução mais efetiva?", "options": [{"letter": "A", "text": "Abordagem híbrida: sumarizar mensagens antigas mantendo as recentes verbatim.", "correct": true, "explanation": "A abordagem híbrida ataca ambas as dimensões do problema: retém contexto exato recente (crítico para coerência conversacional) enquanto mantém uma representação comprimida das preferências anteriores (evitando perda total quando pares são descartados). Aumentar a janela (C) só atrasa o mesmo problema. Busca vetorial (B) pode perder contexto importante que não é semanticamente similar à query atual. Sumarização total por turno (D) adiciona overhead e acumula erros de sumarização."}, {"letter": "B", "text": "Busca por similaridade vetorial sobre o histórico completo da conversa.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Aumentar a janela para 50 pares de mensagens.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Sumarizar mensagens descartadas a cada turno e prepender o sumário corrente.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g67", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Usuários reportam que latência aumenta e custos sobem quando conversas excedem 50 turnos.", "question": "Qual a causa principal?", "options": [{"letter": "A", "text": "Todo o histórico da conversa é incluído em cada requisição da API.", "correct": true, "explanation": "A API do Claude é totalmente stateless — toda requisição precisa incluir o histórico completo no array `messages`. Conforme conversas crescem, cada requisição carrega mais tokens, o que aumenta diretamente latência de processamento e custo. O modelo não mantém estado interno entre chamadas (D é falso) e o tamanho da resposta não está intrinsecamente ligado ao tamanho da conversa (B)."}, {"letter": "B", "text": "O modelo gera respostas progressivamente mais longas.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Operações de banco ficam mais lentas conforme o histórico cresce.", "correct": false, "explanation": ""}, {"letter": "D", "text": "O modelo constrói um perfil interno do usuário que exige mais processamento.", "correct": false, "explanation": ""}], "correct": "A", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g68", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Após três meses de sessões semanais, o histórico cresce para 85.000 tokens. Quando um usuário pergunta \"O que concluímos sobre o tema do isolamento?\", o assistente dá respostas genéricas em vez de referenciar discussões anteriores.", "question": "Qual a abordagem mais efetiva?", "options": [{"letter": "A", "text": "Truncamento por janela rolante.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Sumarização progressiva capturando conclusões-chave.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Embeddings semânticos com recuperação de trocas relevantes.", "correct": true, "explanation": "Busca semântica sobre o histórico de conversa é a única abordagem que escala para três meses de discussão sendo capaz de surfar trocas específicas relevantes sob demanda. Janela rolante (A) descartaria a maior parte do histórico. Sumarização progressiva (B) comprime discussões em abstrações que perdem as conclusões específicas que os usuários estão pedindo. Tags XML (D) exigem reestruturar todo conteúdo passado e não resolvem o problema de recuperação nessa escala."}, {"letter": "D", "text": "Adicionar tags XML estruturadas marcando conclusões da discussão.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g70", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Seu tutor de IA tem um system prompt de 2.800 tokens definindo metodologia de ensino e regras de adaptação. Após 12 turnos, o assistente começa a ignorar níveis de proficiência.", "question": "Qual a correção mais efetiva?", "options": [{"letter": "A", "text": "Injetar lembretes a cada 4–5 turnos.", "correct": false, "explanation": ""}, {"letter": "B", "text": "Substituir regras verbosas por exemplos few-shot demonstrando adaptação por nível de proficiência.", "correct": true, "explanation": "Um system prompt de 2.800 tokens com regras declarativas é vulnerável a deriva porque regras abstratas exigem que o modelo raciocine sobre elas a cada turno. Substituir regras verbosas por exemplos few-shot concretos que demonstram adaptação correta por nível de proficiência dá ao modelo padrões comportamentais claros para casar — isso é seguido de forma mais confiável ao longo de muitos turnos do que instruções abstratas. Injeção de lembretes (A) ajuda mas trata sintomas; posicionamento no fim (C) ajuda inicialmente mas não com deriva por turno; regeneração (D) é cara e corretiva."}, {"letter": "C", "text": "Posicionar regras críticas no fim do system prompt.", "correct": false, "explanation": ""}, {"letter": "D", "text": "Avaliar respostas e regenerar se o nível de dificuldade não casar.", "correct": false, "explanation": ""}], "correct": "B", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "g75", "domain": 5, "scenario": "Padrões de Arquitetura de IA Conversacional", "situation": "Seu assistente usa um system prompt de persona \"empreiteiro\". Os primeiros turnos seguem as regras, mas no turno 7 o assistente passa a dar conselhos genéricos. O comprimento da conversa é de apenas 2.500 tokens.", "question": "Qual a causa mais provável?", "options": [{"letter": "A", "text": "System prompts apenas estabelecem comportamento inicial.", "correct": false, "explanation": ""}, {"letter": "B", "text": "A atenção do modelo enfraquece à medida que turnos se acumulam.", "correct": false, "explanation": ""}, {"letter": "C", "text": "Respostas acumuladas do assistente diluem a influência do system prompt.", "correct": true, "explanation": "Conforme respostas do assistente se acumulam no histórico, a proporção de texto refletindo as restrições comportamentais do system prompt diminui em relação ao volume crescente de conteúdo gerado pelo assistente. O modelo cada vez mais casa padrão com suas próprias saídas anteriores em vez do system prompt, agravando deriva mesmo em comprimentos curtos de tokens. O system prompt é incluído em toda chamada de API (D é falso isoladamente) e degradação de atenção (B) não opera em 2.500 tokens."}, {"letter": "D", "text": "O system prompt é enviado apenas uma vez.", "correct": false, "explanation": ""}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "m18", "domain": 5, "scenario": null, "situation": "Durante os testes, você observa que em sessões de exploração prolongadas (mais de 30 minutos), o agente começa a dar respostas inconsistentes sobre a estrutura de código que discutiu anteriormente. Os engenheiros relatam ter que repetir o contexto sobre módulos que já exploraram.", "question": "Qual é a abordagem mais eficaz para resolver isso?", "options": [{"letter": "A", "text": "Fazer o agente manter um arquivo de rascunho que registra as descobertas principais, consultando-o para perguntas subsequentes.", "correct": true, "explanation": "Correto. Um arquivo de rascunho descarrega as descobertas em um armazenamento durável que o agente pode reler sob demanda, dando a ele uma 'memória' estável independente de quão cheia a janela de contexto fique."}, {"letter": "B", "text": "Mudar para um nível de modelo de maior capacidade para fornecer mais espaço de janela de contexto para os dados de exploração acumulados.", "correct": false, "explanation": "Uma janela maior adia o problema, mas não resolve a degradação da atenção em contextos longos e ruidosos."}, {"letter": "C", "text": "Implementar a limpeza automática do contexto a cada 15 minutos para garantir que o agente comece com um contexto novo e não contaminado.", "correct": false, "explanation": "A limpeza completa descarta descobertas válidas — exatamente o estado que os engenheiros reclamam de ter que reestabelecer."}, {"letter": "D", "text": "Criar resumos de todos os arquivos-fonte antes do início da exploração, carregando no contexto apenas essas representações comprimidas.", "correct": false, "explanation": "Resumos prévios perdem os detalhes que tornam a exploração de código útil e frequentemente distorcem os arquivos que mais importam ao engenheiro."}], "correct": "A", "task_id": "5.4", "objective": "Manage context effectively in large codebase exploration", "group": "G"}, {"id": "m20", "domain": 5, "scenario": null, "situation": "Seu agente passou 25 minutos explorando o subsistema de renderização de um motor de jogos — lendo código de shaders, gerenciamento de buffers e a lógica de sincronização de frames. Um engenheiro agora pede que ele entenda como o motor de física se integra à renderização para sobreposições de depuração de colisão. Você nota que respostas recentes fazem referência a \"padrões típicos de renderização\" em vez das classes específicas VulkanPipeline e FrameGraph que ele descobriu antes.", "question": "Qual é a abordagem mais eficaz?", "options": [{"letter": "A", "text": "Criar um subagente para explorar a física de forma independente e, então, sintetizar manualmente suas descobertas com o conhecimento de renderização acumulado na conversa principal.", "correct": false, "explanation": "A síntese manual na conversa principal empurra ainda mais conteúdo para um contexto que já está se degradando."}, {"letter": "B", "text": "Continuar no contexto atual com prompts mais direcionados que referenciam as classes específicas pelo nome.", "correct": false, "explanation": "O agente já está perdendo especificidade ('padrões típicos' em vez de VulkanPipeline). Insistir mais sobre o mesmo contexto degradado não o restaura."}, {"letter": "C", "text": "Resumir as descobertas principais de renderização e, então, criar um subagente para a exploração de física com esse resumo em seu contexto inicial.", "correct": true, "explanation": "Correto. Condense o que você aprendeu sobre renderização em um resumo compacto e, então, dê a um subagente novo esse resumo mais a tarefa de física — você preserva o sinal importante e escapa do contexto degradado."}, {"letter": "D", "text": "Usar /clear para redefinir o contexto completamente e, então, começar do zero com a exploração de física usando os caminhos de arquivo do CLAUDE.md do projeto.", "correct": false, "explanation": "/clear destrói as descobertas de renderização que você realmente precisa para a pergunta transversal sobre as sobreposições de depuração de colisão."}], "correct": "C", "task_id": "5.4", "objective": "Manage context effectively in large codebase exploration", "group": "G"}, {"id": "m23", "domain": 5, "scenario": null, "situation": "Um engenheiro pede ao agente para entender como funciona a camada de cache antes de adicionar um novo gatilho de invalidação de cache. Após as buscas iniciais com Grep, o agente identificou que a lógica de cache se espalha por 15 arquivos, incluindo decoradores, middleware e classes de serviço (~8.000 linhas no total).", "question": "Qual é o próximo passo mais eficaz para construir o entendimento gerenciando as restrições de contexto?", "options": [{"letter": "A", "text": "Usar a ferramenta Read para carregar sequencialmente todos os 15 arquivos, construindo um entendimento completo de toda a implementação de cache.", "correct": false, "explanation": "Carregar 8.000 linhas sem estrutura inunda o contexto e enterra a lógica de invalidação em código não relacionado."}, {"letter": "B", "text": "Analisar as importações e hierarquias de classe para identificar a classe base de cache, ler esse arquivo para entender a interface e, então, rastrear as implementações específicas de invalidação.", "correct": true, "explanation": "Correto. Comece pela raiz arquitetural (a interface) e, então, navegue apenas pelas implementações específicas que importam para a invalidação — leitura focada, baixo custo de contexto."}, {"letter": "C", "text": "Usar o Grep para buscar os padrões \"invalidate\" e \"expire\" em todos os arquivos e, então, ler apenas esses intervalos de linha específicos com o mínimo de contexto ao redor.", "correct": false, "explanation": "A leitura apenas por palavra-chave remove o contexto de classe/método que indica o que a invalidação realmente protege."}, {"letter": "D", "text": "Usar o Glob para encontrar arquivos que correspondam a padrões comuns de cache (cache.py, caching/), priorizar os maiores arquivos lendo-os primeiro e, então, verificar os menores em busca de lacunas.", "correct": false, "explanation": "O tamanho é um péssimo indicador de importância. Você desperdiçaria contexto em grandes arquivos utilitários e perderia os pequenos arquivos estratégicos."}], "correct": "B", "task_id": "5.4", "objective": "Manage context effectively in large codebase exploration", "group": "G"}, {"id": "m37", "domain": 5, "scenario": null, "situation": "O agente verifica a identidade do cliente por meio de um processo de múltiplas etapas antes de redefinir senhas. Durante os testes, você nota que, depois que o cliente responde à terceira pergunta de verificação, o agente pede que ele informe o nome novamente, como se a troca anterior nunca tivesse acontecido.", "question": "Qual é a causa mais provável desse comportamento?", "options": [{"letter": "A", "text": "A ferramenta de verificação está limpando o estado interno do agente após cada etapa de validação bem-sucedida.", "correct": false, "explanation": "Ferramentas não limpam o estado do agente — o estado da conversa fica no array de mensagens que você envia."}, {"letter": "B", "text": "O prompt não tem instruções dizendo ao Claude para lembrar informações ao longo de múltiplas trocas.", "correct": false, "explanation": "A memória entre turnos não é obtida por uma instrução — ela vem de repassar os turnos anteriores na próxima requisição."}, {"letter": "C", "text": "O histórico da conversa não está sendo repassado nas requisições subsequentes da API.", "correct": true, "explanation": "Correto. A API é stateless. Cada requisição deve incluir o array completo de mensagens. Se você enviar apenas o último turno, o modelo não tem memória dos anteriores — exatamente o sintoma de \"pedir o nome de novo\"."}, {"letter": "D", "text": "A retenção de memória do Claude é limitada a dois turnos de conversa por padrão, exigindo configuração explícita para estendê-la.", "correct": false, "explanation": "Esse limite padrão não existe. O contexto é limitado pela janela, e o tamanho do histórico está sob seu controle."}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "m42", "domain": 5, "scenario": null, "situation": "Um cliente levanta três questões distintas durante uma sessão: uma consulta de reembolso (turnos 1-15), uma dúvida sobre assinatura (turnos 16-30) e uma atualização de método de pagamento (turnos 31-45). No turno 48, o cliente pergunta \"O que aconteceu com o meu reembolso?\" A conversa está se aproximando dos limites de contexto.", "question": "Qual estratégia mantém melhor a capacidade do agente de tratar todas as questões ao longo da sessão?", "options": [{"letter": "A", "text": "Extrair e persistir dados estruturados das questões (IDs de pedidos, valores, status) em uma camada de contexto separada.", "correct": false, "explanation": "Uma camada de contexto paralela adiciona trabalho de engenharia e não preserva naturalmente a narrativa conversacional que o cliente espera."}, {"letter": "B", "text": "Confiar nas ferramentas MCP para buscar novamente as informações relevantes sob demanda quando o cliente fizer referência a questões anteriores.", "correct": false, "explanation": "Buscar novamente é adequado para atualidade, mas não resolve o problema do tamanho do contexto — e você perde o que foi dito entre o cliente e o agente."}, {"letter": "C", "text": "Resumir os turnos anteriores em uma descrição narrativa, preservando o histórico completo de mensagens apenas para a questão ativa.", "correct": true, "explanation": "Correto. A sumarização progressiva comprime tópicos estáveis já resolvidos, mantendo a thread ativa na íntegra — o padrão clássico para conversas longas com múltiplas questões próximas do limite de contexto."}, {"letter": "D", "text": "Implementar contexto em janela deslizante que retém os 30 turnos mais recentes.", "correct": false, "explanation": "Uma janela deslizante pura descarta silenciosamente a questão do reembolso (turnos 1-15) do contexto, que é exatamente o que o cliente está perguntando."}], "correct": "C", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "m45", "domain": 5, "scenario": null, "situation": "Seu agente chamou `lookup_order` várias vezes enquanto investigava os pedidos de devolução de um cliente. Cada resposta inclui mais de 40 campos (itens, detalhes de envio, informações de pagamento, histórico de status). As saídas das ferramentas agora representam a maior parte do contexto da conversa. O cliente menciona mais dois pedidos que deseja discutir.", "question": "Qual é a abordagem mais eficaz antes de fazer consultas adicionais?", "options": [{"letter": "A", "text": "Extrair apenas os campos relevantes para a devolução (itens, data da compra, prazo de devolução, status) de cada resposta de pedido existente, removendo os detalhes verbosos.", "correct": true, "explanation": "Correto. Mantenha os campos que importam para a tarefa e descarte o resto. Isso aborda diretamente o problema de inchaço do contexto antes de você adicionar mais duas consultas."}, {"letter": "B", "text": "Fazer com que o modelo gere um resumo em linguagem natural dos detalhes principais de cada pedido, substituindo as respostas estruturadas por descrições em prosa.", "correct": false, "explanation": "Resumos em prosa perdem precisão para campos que o modelo pode precisar depois (datas e valores exatos). A poda estruturada é melhor do que a paráfrase."}, {"letter": "C", "text": "Mover todas as respostas das ferramentas para um banco de dados vetorial com indexação semântica, recuperando as partes relevantes conforme a conversa avança.", "correct": false, "explanation": "Um banco de dados vetorial é uma infraestrutura pesada para o que é essencialmente um problema de poda."}, {"letter": "D", "text": "Prosseguir com as consultas adicionais sem modificar o contexto existente das saídas das ferramentas.", "correct": false, "explanation": "Não faz nada quanto ao inchaço — você está caminhando para o esgotamento do contexto."}], "correct": "A", "task_id": "5.1", "objective": "Manage conversation context to preserve critical information across long interactions", "group": "G"}, {"id": "m60", "domain": 5, "scenario": null, "situation": "Depois que seu batch diário de 10.000 documentos é concluído, 300 documentos (3%) falharam com erros \"`context_length_exceeded`\". O arquivo de resultados identifica cada falha por `custom_id`.", "question": "Qual é a abordagem mais econômica para processar essas falhas?", "options": [{"letter": "A", "text": "Reprocessar o batch inteiro com prompt caching habilitado para reduzir o custo de repetir requisições com prompts de sistema idênticos", "correct": false, "explanation": "Reexecutar 10.000 documentos bem-sucedidos para resolver 300 falhas é um desperdício, independentemente da economia do caching. E o caching não corrige o erro de comprimento excedido."}, {"letter": "B", "text": "Reenviar apenas os 300 documentos que falharam, após dividi-los em pedaços menores, e então combinar as extrações parciais", "correct": true, "explanation": "Correto. Direcionado, e trata a causa real (entrada longa demais). Divida os documentos superdimensionados, extraia por pedaço e depois mescle — mínimo de tokens, corrige o modo de falha específico."}, {"letter": "C", "text": "Reenviar o batch inteiro de 10.000 documentos usando um nível de modelo com uma janela de contexto maior", "correct": false, "explanation": "Caro (reprocessar 9.700 sucessos) e ainda pode falhar em documentos realmente descomunais."}, {"letter": "D", "text": "Aumentar o parâmetro `max_tokens` para os 300 documentos que falharam e reenviá-los em um novo batch", "correct": false, "explanation": "`max_tokens` controla o comprimento da saída, não o da entrada. Não resolve `context_length_exceeded`, que diz respeito ao orçamento combinado de entrada mais saída."}], "correct": "B", "task_id": "4.3", "objective": "Enforce structured output using tool use and JSON schemas", "group": "H"}]