A seção Changed da 1.3.0 do IronClaw (19/ago), que eu tinha lido por cima em 22/ago, traz quatro linhas que só se explicam juntas. Verbatim, do CHANGELOG.md no main:

• "Context-window eviction compacts instead of discarding: the accepted task and any steering survive the eviction."
• "Lease expiry recovers safe runs instead of failing them, and the journal heartbeat pool is isolated."
• "An unavailable capability call is repaired instead of aborting the run, and repeated-call detection is advisory rather than fatal."
• "Model-bound secrets are redacted without rejecting the turn."

Quatro subsistemas — contexto, concorrência, capacidades e segredo — e a mesma decisão em todos: quando o caminho normal falha, o sistema degrada e segue. Repare no vocabulário, que é o mesmo nas quatro: instead of discarding, instead of failing, instead of aborting, without rejecting.

E isso conversa direto com o achado de 29/ago, onde goose e Claude Code escolheram o oposto: "Fail closed on malformed tool visibility" e aprovação obrigatória para "malformed commands". Duas filosofias, as duas datadas, as duas em código.

O que as concilia é o que está em jogo. Onde a falha é de autoridade — a política não sabe o que o comando faz —, os três harnesses fecham. Onde a falha é de disponibilidade — o lease expirou, a capacidade sumiu, o contexto encheu —, o IronClaw repara. O eixo que o cap. 07 formula desde 16/ago ("o que o portão faz quando não consegue decidir") estava mal recortado por mim: a resposta certa depende de qual propriedade a indecisão ameaça.

Impacto B nos caps. 07 e 11, com nota no cap. 02. É a melhor seção que saiu do Radar esta semana.

Ainda na 1.3.0, na seção Added, dentro do item de automações estruturadas. Verbatim:

"A deterministic no-result sentinel lets a run that has nothing to report finish silently instead of delivering filler."

Em 26 e 29/ago eu acumulei sete instâncias, em três harnesses, do defeito inverso: interrupção, corte por limite e cancelamento chegando ao consumidor com a forma de conclusão, e o vazio chegando como "completed with no output", "empty result" e "empty messages". A tese subiu para A no cap. 02 justamente porque o loop representa término e vazio com o mesmo símbolo.

Aqui está um sistema que resolveu pelo outro lado: dar ao "nada a relatar" um valor próprio, determinístico, para que o resultado vazio deixe de precisar virar texto. O contraste com filler é o ponto — sem sentinela, um agente que não tem o que dizer preenche.

A mesma linha traz a outra metade do item: "checked by a fail-closed preflight at creation instead of a free-form prompt string". A automação agendada é validada quando é criada, e não quando dispara.

A Leitura executiva do cap. 02 ganha o exemplo positivo que faltava para a exigência de vocabulário de término. Impacto B, reforçando o A já registrado.

Da página da release 1.4.0 (27/ago), verbatim: "Managed per-user sandbox egress proxy, with manifest-declared direct-exec credential bindings".

As quatro anteriores prendiam a credencial ao destino: WithCredentialOrigin no CompozyOS, secret host binding no OpenClaw, OAuth com escopo de origem no IronClaw, e a telemetria do Claude Code passando a mandar credencial só ao próprio host. Esta vai um passo além — a credencial fica no proxy, e o código em sandbox nunca a recebe, com a ligação declarada em manifesto.

É o mesmo desenho do mascaramento por terminação de TLS que o Claude Code adotou (registrado em 08/ago), agora com o vínculo declarado em vez de implícito. Impacto B no cap. 07 e no apêndice de supply chain.

Mesma release 1.4.0, na seção Fixed: "Provider failures and auth diagnostics reach the model as readable context instead of opaque errors".

Oitava instância da família aberta em 26/ago, e a primeira em que o objeto é o diagnóstico e não o término. O padrão é idêntico: alguma coisa acontece no harness, e o que chega ao modelo é uma forma que não permite decidir o que fazer a seguir. Aqui é erro opaco em vez de conclusão falsa; a consequência é a mesma, porque o modelo precisa raciocinar sobre o que aconteceu e recebe um símbolo sem conteúdo.

Junto, também em Fixed: "Structured finalization stalls are bounded" e "Incremental compaction summary context is preserved". Impacto B no cap. 02, C no cap. 13.

Da 1.4.0: "Durable notification inbox: runs publish authoritative outcomes and actionable gates to a per-user inbox", e ao lado "Background subagents: a parent turn can spawn children that run and deliver on their own".

Duas palavras carregam o item. Authoritative diz que existe um lugar onde o desfecho é o desfecho, o que é a resposta de arquitetura para tudo o que os achados 2 e 4 tratam no nível da mensagem. Actionable gates põe a aprovação pendente no mesmo lugar durável — que é exatamente o preço que o OpenClaw pagou em 26/ago para reconferir autorização na hora do efeito, com aprovação nonce-bound em estado compartilhado.

Com subagentes de fundo entregando por conta própria, a caixa deixa de ser conveniência e vira a estrutura que torna o trabalho assíncrono legível. Impacto B nos caps. 08 e 13, C no cap. 10.

O item de eviction do achado 1 merece linha própria no cap. 04, porque ali o assunto é contrato: "the accepted task and any steering survive the eviction."

O Hermes já tinha a mesma forma na v0.19.0, com "guaranteed N-user-message tail so recent conversation always survives". Dois sistemas, duas garantias explícitas, e classes de conteúdo diferentes — o IronClaw protege a tarefa aceita e a direção dada; o Hermes protege a cauda recente.

O cap. 04 trata compactação como resumo, e discute o que se perde. Nenhuma linha discute o que a compactação promete preservar, que é a pergunta que um contrato responde. Eixo novo. Impacto B.

Ontem eu escrevi que, se não coubesse hoje, esta pergunta seria cortada como cortei o TrueForge. Não coube. Fica o corte, e fica o que cinco dias renderam.

A cadeia é MCPClient → fastmcp.Client → StdioTransport, e a camada de configuração do fastmcp v3 está legível em fastmcp_slim/fastmcp/mcp_config.py. O StdioMCPServer declara command: str, args, env, cwd, e entrega tudo ao transporte sem tocar em resolução de caminho. O fastmcp_slim/fastmcp/client/__init__.py importa de .transports, e esse arquivo devolve 404 no mesmo diretório em que o __init__.py devolve 200 — duas tentativas. Onde PATH é resolvido continua sem resposta, e sai da fila.

O que sobra é melhor que a pergunta. O tipo do ambiente no fastmcp é

env: dict[str, Any] = Field(default_factory=dict)
...
model_config = ConfigDict(extra="allow")  # Preserve unknown fields

e o mesmo campo, no software-agent-sdk que consome essa biblioteca, é dict[str, SecretStr] — o achado de 25/ago. A classificação de segredo é acrescentada pela camada de cima. A biblioteca de protocolo trata ambiente como dado qualquer e ainda preserva campos desconhecidos; quem decide que aquilo é segredo é a integração.

Isso é material do cap. 06 e do cap. 05: garantia de manuseio de segredo é propriedade da integração, e não do protocolo — logo, dois clientes MCP da mesma biblioteca podem ter posturas opostas sem que nenhum viole a spec. Impacto C, e a pergunta original morre valendo mais do que a resposta valeria.

arXiv:2605.26112, From Model Scaling to System Scaling: Scaling the Harness in Agentic AI, de Shangding Gu, submetido em 25/mai/2026. Estava na fila de "quatro papers, nenhum lido" desde 14/ago.

A tese é a nossa, com as palavras dele: "We refer to this shift as scaling the harness: treating the structured execution layer around a foundation model as a first-class object of design, evaluation, and optimization."

Três coisas para o livro, em ordem de peso.

Uma quarta taxonomia para confrontar. A decomposição dele é "the foundation model, memory substrate, context constructor, skill-routing layer, orchestration loop, and verification-and-governance layer". Já tínhamos o H=(E,T,C,S,L,V) de Meng et al. e os quatro eixos do RUCAIBox contra as nossas 12 dimensões. Agora o confronto é a quatro, e este é o único que nomeia governança como camada.

Uma agenda de benchmark que responde ao que o cap. 11 cobra. Verbatim: "We further outline a research agenda for harness-level benchmarks that go beyond one-shot task success to measure trajectory quality, memory hygiene, context efficiency, communication fidelity, verification cost, and safe evolution over time." Seis medidas propostas, e o argumento é o mesmo do cap. 11 — sucesso final de tarefa mede o par modelo+harness e não distingue os dois.

E o terceiro confronto com o corpus em três dias. Ele constrói "CheetahClaws: a Python-native reference harness" e o compara com Claude Code e OpenClaw. Em 28/ago apareceu o Dive into Claude Code, comparando Claude Code com OpenClaw e Hermes Agent. Dois grupos independentes escolheram os mesmos sistemas para ler, e os dois escolheram membros do nosso corpus.

Ressalva honesta: é paper de posição. O abstract não traz resultado quantitativo, e a validação do CheetahClaws eu não li.

Impacto A no cap. 01 e no benchmark; B nos caps. 11 e 14; entrada de bibliografia.

arXiv:2604.21003, The Last Harness You'll Ever Build (Seong, Yin, Zhang, Shi; v1 22/abr/2026, v3 01/mai/2026). Dois níveis: um laço que evolui o harness de uma tarefa com três agentes — executor, avaliador adversarial, evolutor — e um meta-laço que otimiza o próprio projeto de evolução entre tarefas, "so that adapting an agent to a novel domain requires no human harness engineering at all."

O que importa para o cap. 16 é o que ele não traz: é framework teórico, sem sistema implantado avaliado. E isso completa uma escada de evidência que agora dá para publicar inteira:

Seis posições, do teórico ao contraditório empírico. O cap. 16 vinha acumulando um lado só; agora tem material para uma seção que ensina a ler um número de auto-evolução, que vale mais que a lista. Impacto B.

arXiv:2602.07962, LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth (Zeng, Huang, He; 08/fev/2026).

A frase que importa: "LOCA-bench evaluates language agents as a combination of models and scaffolds, including various context management strategies."

Em 04/ago o Radar registrou a Binding Constraint Thesis — variância do harness maior que a do modelo, com inversão de ranking, e uma exigência de disclosure que nenhum membro do corpus cumpre. LOCA-bench é o instrumento correspondente: controla o crescimento do contexto por estado do ambiente, mantém a semântica da tarefa fixa, e varia o scaffold. Achado: o desempenho degrada conforme o estado do ambiente cresce, e estratégias avançadas de gestão de contexto melhoram substancialmente a taxa de sucesso.

É o eval que os caps. 03 e 04 não têm e que o cap. 11 pede pelo nome. Impacto B nos caps. 03, 04 e 11, mais bibliografia.

arXiv:2606.20631, Harnessing Agent Skills: Architectural Patterns and a Reference Architecture for Skill-Mediated LLM Agents (Xia, Zhu, Xing, Lu, Sejdinovic, Xu; 29/mai/2026). Abre definindo: "Agent skills externalise reusable agent-facing behavioural knowledge and guidance as persistent artefacts that can be discovered, activated, and interpreted by LLM agents."

Dez padrões arquiteturais — cinco centrais, cinco de apoio — organizados em quatro camadas de responsabilidade: Supply Chain, Mediation, Execution Control, Evidence & Feedback, com instanciação cruzada em oito sistemas.

Duas consequências. O cap. 12 trata extensibilidade sem vocabulário de camadas, e aqui há um vocabulário validado contra oito sistemas. E o nosso apêndice de supply chain, que nasceu de observação de campo, ganha correspondente acadêmico que trata cadeia de suprimentos como camada de arquitetura em vez de risco anexo.

Casa direto com o que o corpus vinha mostrando: os cinco desenhos de proveniência de plugin, as aprovações do Skill Workshop do OpenClaw, e o "Honor plugin enablement for skills" do goose de ontem. Impacto B no cap. 12 e no apêndice, C no cap. 05.

O README do registro, lido pelo raw, aponta o caminho que eu não tinha procurado:

https://cdn.agentclientprotocol.com/registry/v1/latest/registry.json

Índice em JSON, versão 1.0.0. Contagem direta: 39 agentes e zero extensões. Cada entrada traz id, name, version, description, repository, website, authors, license, distribution e icon.

Com o campo repository, a pergunta que eu vinha errando fica decidível:

Então: três membros do corpus com implementação de primeira parte verificável, um quarto sem procedência declarada, duas pontes escritas pela organização do protocolo e duas por terceiros. Minha contagem de 19/ago dizia "56 agentes, sete do corpus"; a de 20/ago corrigiu para 41 e quatro; agora são 39, com a natureza de cada entrada legível em vez de inferida.

E o README melhora o que uma entrada significa, verbatim: "All agents are verified via CI to ensure they return valid authMethods in the ACP handshake." Desde 19/ago eu vinha escrevendo que entrada no registro é afirmação do registro. Continua sendo, mas a afirmação é verificada por CI no handshake — o que é bem mais que declaração, e menos que implementação completa. A ressalva do cap. 17 fica mais precisa em vez de sumir.

Impacto B no cap. 17.

Ontem registrei ⏳ porque duas leituras discordavam: a página da tag da v0.57.0 do gemini-cli, lida em 26/ago, não trazia entrada de symlink; a lista de releases, lida em 29/ago, atribuía a essa versão um "ensure consistent symlink evaluation in ignore path handling".

Hoje li o changelog inteiro da tag, e são 24 entradas. Nenhuma contém a palavra symlink. A lista tinha misturado a preview v0.58.0-preview.0, que a mesma leitura de 29/ago listava com a mesma linha.

A tag ganha, e a regra que sai daqui já está no contrato, um nível acima: agregador é pista, nunca fonte. A lista de releases é agregadora das páginas de tag, e este é o terceiro tropeço nela em uma semana — datas erradas em 23/ago, contagem estimada em 27/ago, atribuição de versão agora.

O achado fica sem versão: o gemini-cli tratou consistência de symlink em avaliação de caminho ignorado em algum ponto da série 0.57–0.58, com a evidência apontando para a preview. Vale pela vizinhança — mesma semana em que o Claude Code corrigiu quatro defeitos de symlink e de ordem.

E a leitura da tag rendeu três entradas que eu não tinha:

• "fix(core): preserve empty text turns with tools or media" — a família do vazio outra vez, agora no terceiro sistema, ao lado do "empty result" do opencode e do "no output" do Claude Code;
• "[SSR Agent] Issue Fix (22093): Prevent subagents from running when agents mode is disabled" — um modo desligado que não desligava, que é a família da aprovação sem consequência de 26/ago;
• "[SSR Agent] Issue Fix (21477): Prevent indefinite TUI hang by adding execution timeouts".

Impacto C, e o primeiro reforça a tese que subiu para A ontem.

Em 26/ago abri esta tese com quatro instâncias no Claude Code e uma no gemini-cli. Hoje o opencode entra com duas, na v1.18.20 (21/ago), e uma delas usa quase a mesma frase da correção do Claude Code:

• "Surface resumable subagent failures instead of returning an empty result."
• "Surface failed subagent tool calls with a resumable task_id."

"Instead of returning an empty result" contra o "completed with no output" que o Claude Code corrigiu. Dois harnesses, sem relação de código, descrevendo o mesmo defeito com o mesmo vocabulário. E o opencode acrescenta o que falta nos outros: além de dizer que falhou, devolve identificador de retomada, o que transforma o término em estado consultável.

São agora sete instâncias em três harnesses: quatro no Claude Code, duas no opencode, uma no gemini-cli. A tese sobe de B para A no cap. 02 — já não é seção a acrescentar, é a Leitura executiva descrevendo o ciclo com um vocabulário que a evidência mostra insuficiente.

Junto, da mesma família, na v1.18.24 (28/ago): "Bedrock reasoning responses no longer cached as empty messages". O vazio outra vez, agora atravessando para o cache.

A v2.1.251 traz quatro defeitos que são todos de ordem entre a checagem e o uso:

• "Fixed file tools (Read, Write, Edit) following a symlink swapped inside the working directory after the permission check, which could read or write outside the approved location"
• "Fixed Grep and Glob not applying Read(...) deny rules to files reached through a symlinked search path"
• "Fixed the Workflow tool reading (and quoting in errors) a scriptPath outside what the session may read before the permission check ran"
• "Fixed plugin commands declared in a marketplace entry being able to point outside the plugin directory; such paths are now rejected with a path-traversal error"

O primeiro é o caso puro: a permissão foi concedida para um caminho, e o caminho virou outra coisa depois da concessão. Os outros três são variações da mesma pergunta — a regra alcança o objeto pela via por onde ele foi realmente atingido? Por caminho simbólico de busca, não alcançava. Antes da checagem, o arquivo já tinha sido lido. Pela entrada de marketplace, o comando apontava para fora.

Isto fecha, pelo lado negativo, o eixo que abri em 26/ago com o OpenClaw: lá a autorização passou a ser reconferida onde o efeito acontece; aqui está o que acontece quando ela não é. E o goose v1.48.0 (27/ago) dá a regra de composição que falta: "Permission denies take precedence". O Hermes já dizia o mesmo em v0.19.0, com "user-defined deny rules" barrando comando mesmo sob modo permissivo.

Impacto B no cap. 07, com a seção nova sendo a janela entre a checagem e o uso.

O Radar abriu em 14/ago a família configuração como execução de código, com o sandbox.ripgrep que a configuração de projeto podia trocar. A v2.1.251 transforma aquilo em campanha, e vale ler as cinco juntas:

• "Changed server-managed settings that terminate sandbox TLS, route sandbox traffic through your own proxy, inject credentials, or weaken sandbox isolation to require approval before they apply"
• "Changed ANTHROPIC_CUSTOM_HEADERS from managed or project settings to require approval when it sets a credential, org/tenant, routing, or API-behavior header (e.g. Authorization, Host)"
• "Changed project-level .claude/settings.json env to no longer set CLAUDE_CONFIG_DIR, CLAUDE_CODE_TMPDIR, or TMPDIR/TMP/TEMP; set them in your shell, user, or managed settings instead"
• "Fixed project settings being able to enable detailed beta tracing or raw API body logging, and a lower-scope beta tracing endpoint bypassing an OTLP collector pinned by managed settings or a host app"
• "Changed how Bash command output files are created and read back when commands run in the sandbox, so a sandboxed command cannot redirect or replace them"

O padrão é um só: escopo de configuração é fronteira de privilégio, e o escopo mais baixo não pode afrouxar a postura de segurança fixada no mais alto. Repare que a defesa escolhida para o caso mais grave é pedir aprovação da própria configuração, o que é novo — o portão deixa de olhar só o que o agente faz e passa a olhar o que o ambiente do agente declara.

Na v2.1.248 há a forma grossa da mesma ideia: --restricted, que "removes the built-in tools that run commands or code and WebFetch (unless named in --tools), keeps file tools inside the working directory, refuses bypassPermissions, and ignores user, project and local settings files". Uma postura nomeada que, entre outras coisas, ignora os arquivos de configuração.

O cap. 07 trata permissão como política sobre ações e o cap. 12 trata extensibilidade como superfície de código. Nenhum dos dois trata o arquivo de configuração como objeto com escopo, precedência e portão. Impacto B nos dois.

A tese aberta em 23/ago: uma decisão de recusa precisa alcançar o que sobrevive ao turno. Duas amostras desde então, e seis dias procurando a terceira, com dois vizinhos rejeitados por não serem recusa.

Está na v2.1.251, e é limpa: "Improved retry when the model's tool call is malformed: the broken output is now dropped from the retry context, including on Bedrock, Vertex, and Foundry".

A chamada malformada foi rejeitada, e a rejeição passou a alcançar o contexto que sobrevive para a tentativa seguinte. Antes, o harness recusava a chamada e mandava a chamada recusada de volta ao modelo, que é o formato exato das duas amostras anteriores: o token do Codex vazando pelo histórico reproduzido, e a redação da guardrail do SDK da OpenAI que não alcançava o estado persistido.

Três amostras, três sistemas, três camadas — credencial, guardrail e chamada de ferramenta. Vira seção no cap. 08, com nota no cap. 02. Impacto B.

"Fixed Bash permission checks auto-approving commands that assign an arithmetic expression to an integer shell variable (e.g. OPTIND=1/0, RANDOM=2+2); these now prompt for approval" — v2.1.251.

A série continua exatamente onde vive: uma construção do shell que o avaliador de política classificava como inofensiva. Aqui a atribuição aritmética a variável inteira era auto-aprovada, e OPTIND e RANDOM são variáveis com efeito no próprio interpretador. É primo do caso do $PSDefaultParameterValues de 13/ago, onde o comando avaliado era inofensivo e reescrevia o padrão dos seguintes.

Somando: onze casos, quatro sistemas operacionais, três harnesses, três semanas. Impacto B no cap. 07, e o número já é argumento sozinho.

Ontem o eixo ganhou fundamento científico. Hoje ganha medição e duas causas que nenhum capítulo imaginaria.

Medição, na v2.1.251: "Added a per-session prompt-cache line to /cost (hit ratio, misses, tokens re-cached, warm/cold) and a matching prompt_cache object for status line scripts", e "SessionStart resume hooks now receive session staleness and the estimated re-cache cost". O cache deixa de ser propriedade interna e vira número exposto ao operador e ao script.

Causa nova, e ela vem da autenticação, na v2.1.248: "Fixed a prompt-cache miss (and lost extended-thinking context) roughly once an hour in long sessions, caused by tool definitions being re-rendered after an OAuth token refresh".

Causa nova, e esta vem da cobrança: "Fixed the ScheduleWakeup tool definition changing between a session and its --resume when the account had entered usage overage, causing a full prompt-cache miss on the resumed session's first turn". O estado de faturamento da conta mudou o texto de uma ferramenta, e o prefixo caiu.

Junto com a reconexão de LSP de 18/ago, são três causas de invalidação vindas de subsistemas que o livro nem lista como parte do loop. O paper de ontem diz que a colocação do bloco decide o ganho; a engenharia desta semana diz que quem derruba a colocação costuma ser o vizinho. Impacto B no cap. 04, C no cap. 03.

Ainda no eixo, e em outra camada: o Hermes v0.20.6 (27/ago) traz "TTL result caching for web_search/web_extract" — cache de resultado de ferramenta, com TTL, que é o que a spec MCP 2026-07-28 padronizou com ttlMs.

O goose v1.48.0 traz "Sanitize Unicode tags in MCP prompts" (#11453) e "Sanitize hidden Unicode in Bedrock tools" (#11121).

Em 06/ago o Radar registrou, no Claude Code v2.1.221, diálogo de aprovação escondendo parte do comando com tabs e Unicode invisível. Agora um segundo harness sanitiza caractere invisível em duas superfícies distintas: prompt vindo de servidor MCP e descrição de ferramenta no Bedrock.

O eixo é o mesmo e o livro não o tem: o texto que o humano lê e o texto que o modelo lê podem divergir do texto que existe. Impacto B no cap. 07, com nota no cap. 13.

Fechado. O RADAR.md marcava com ⏳ que o Hermes teria migrado para MCP 2.x com suporte a stateless. A página de releases confirma na v0.20.3 (16/ago): "the MCP 2.x SDK migration and 2026-07-28 stateless protocol support", mais catálogos remotos com "50+ live-verified vendor-hosted servers". É o segundo membro do corpus implementando a spec 2026-07-28, depois do Codex 0.147.0, e o primeiro sem opt-in declarado.

Divergência. Em 26/ago eu li a página da tag da v0.57.0 do gemini-cli e registrei que nenhuma entrada mencionava symlink. Hoje a página de releases atribui a essa mesma v0.57.0 a entrada "ensure consistent symlink evaluation in ignore path handling". ⏳ As duas leituras discordam, e eu não sei qual página está certa sobre a atribuição de versão. O fato — o gemini-cli tratou consistência de symlink em avaliação de caminho ignorado — fica registrado sem a versão. Vale pela vizinhança: na mesma semana em que o Claude Code corrigiu quatro defeitos de symlink e ordem, o gemini-cli mexeu no mesmo lugar.

O goose v1.48.0 abre a lista de segurança com "Fail closed on malformed tool visibility" (#11474). O Claude Code v2.1.246 (25/ago) tinha feito o mesmo movimento no shell: "Fixed Bash permission checks to always require approval for malformed commands with a dangling && or \|\| operator".

Duas superfícies diferentes — metadado de visibilidade de ferramenta e sintaxe de comando — e a mesma regra: entrada malformada resolve para o lado restritivo.

Isso responde, com um terceiro dado, a pergunta que o Radar abriu em 16/ago e que o cap. 07 não formula: o que o portão faz quando não consegue decidir? Havia duas respostas opostas em código, lidas com 24h de intervalo — o Kiro Crew falhando aberto na superfície que o próprio código chama de "instruction-injection surface", e o DeepSeek Harness proibindo nominalmente o caminho silencioso. O goose entra do lado do fecho, e o Claude Code mostra que a mesma escolha aparece quando o objeto indecidível é a sintaxe em vez da exceção.

Vira seção com três respostas datadas em vez de duas. Impacto B no cap. 07.

Em 26/ago entrou a credencial de gateway viajando em requisição de telemetria do Claude Code. Hoje somam-se duas:

• goose v1.48.0: "Suppress sensitive OTLP traces" (#11381);
• Claude Code v2.1.251: "Fixed project settings being able to enable detailed beta tracing or raw API body logging, and a lower-scope beta tracing endpoint bypassing an OTLP collector pinned by managed settings or a host app".

Três instâncias, dois harnesses, e as três pelo mesmo caminho: o canal de observabilidade carregando o que o canal de inferência protege. O terceiro caso é o mais completo, porque junta o vazamento ao tema do achado 3 — quem liga o traçado detalhado é a configuração de escopo mais baixo.

O apêndice de supply chain trata do que entra no harness; nenhum capítulo trata do que sai por observabilidade. Impacto B no cap. 07 e no apêndice.

Harness engineering for coding agent users, de Birgitta Böckeler, publicado em 02/abr/2026 no site do Martin Fowler. O Radar tentou ler em 11 e 12/ago e o domínio estava bloqueado. Hoje abriu.

A definição de abertura é a nossa, com outras palavras: "The term harness has emerged as a shorthand to mean everything in an AI agent except the model itself - Agent = Model + Harness." É a quarta convergência independente de definição registrada, depois das duas surveys e do harness da Microsoft, e a de datação mais antiga entre elas.

O que o artigo traz de novo são três eixos que o livro não tem.

Guias e sensores. Verbatim: "Guides (feedforward controls) - anticipate the agent's behaviour and aim to steer it before it acts." e "Sensors (feedback controls) - observe after the agent acts and help it self-correct." O livro organiza o harness por componente — contexto, ferramentas, permissões, verificação. Este eixo organiza por momento do controle, e recorta transversalmente os nossos capítulos: prompt de sistema e política de permissão são guias; teste, linter e eval são sensores. Nada obriga o livro a adotar a taxonomia, mas ela expõe uma pergunta que os capítulos não fazem — para cada componente, ele age antes ou depois do ato do agente?

Computacional e inferencial. Verbatim: "Computational - deterministic and fast, run by the CPU. Tests, linters, type checkers, structural analysis." e "Inferential - Semantic analysis, AI code review, 'LLM as judge'. Typically run by a GPU or NPU. Slower and more expensive; results are more non-deterministic." O cap. 11 discute LLM-como-juiz e discute teste, sem nomear que são classes de custo e determinismo diferentes dentro do mesmo papel.

Harnessability. Verbatim: "Not every codebase is equally amenable to harnessing. A codebase written in a strongly typed language naturally has type-checking as a sensor; clearly definable module boundaries afford architectural constraint rules…" Esta é a que mais incomoda. O livro trata o harness como propriedade do sistema do agente; aqui há uma propriedade do código-alvo que determina quanto harness é possível. Dois harnesses idênticos rendem coisas diferentes em bases de código diferentes, e nenhum capítulo diz isso.

Uma diferença de altitude precisa ficar registrada, porque muda como se cita. O artigo é for coding agent users: harness como o que a pessoa constrói em volta do agente que ela usa. O livro trata do harness como o que o produto traz dentro. As duas leituras usam a mesma equação e olham para lados opostos da fronteira do produto.

Impacto A no cap. 01 (a definição ganha a companhia mais próxima que já teve, e a distinção de altitude precisa entrar), B nos caps. 11 e 14, mais entrada de bibliografia.

O RADAR.md registra desde 13/ago que os fundamentos científicos do cap. 04 não incluem cache, e o item que resolveria isso estava em ⏳ havia semanas, com o motivo escrito na tabela: arxiv.org bloqueado, no sétimo dia de bloqueio.

Lido hoje: arXiv:2601.06007, "Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks", de Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate e Vamse Kumar Subbiah, submetido em 09/jan/2026.

Os números: "prompt caching reduces API costs by 41-80%" e melhora "time to first token by 13-31%" nos três provedores testados. Mais de 500 sessões de agente com prompt de sistema de 10.000 tokens e mais de 10.000 operações de chamada de ferramenta; ablação de 500 a 50.000 tokens de prompt e de 3 a 50 chamadas.

O achado que casa com o eixo é o último. A colocação estratégica dos blocos de cache — conteúdo dinâmico no fim do prompt de sistema, resultados dinâmicos de ferramenta fora — rende mais que cachear o contexto inteiro de forma ingênua, que às vezes aumenta a latência em vez de reduzir.

É exatamente o que as nove ocorrências do eixo vinham mostrando em código, de goose a IronClaw: montagem append-only, escalonamento de fan-out, breakpoints explícitos, e agora a decisão de não pagar prêmio de escrita em chamada de um tiro. O eixo tinha nove evidências de engenharia e nenhuma citável. Agora tem, com método e ablação.

Impacto B nos caps. 04 e 03, e entrada de bibliografia. O item sai de ⏳.

A alegação "98,4% do Claude Code não é IA" está no RADAR.md em ⏳ desde que apareceu, com primária alegada em arXiv 2604.14228. Hoje deu para ler.

O paper é real e é melhor do que a alegação: Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems, de Jiacheng Liu, Xiaohan Zhao, Xinyi Shang e Zhiqiang Shen, v1 em 14/abr/2026 e v2 em 02/jul/2026. Verbatim: "This study describes its architecture by analyzing the publicly available source code and comparing it with two independent open-source AI agent systems, OpenClaw and Hermes Agent, that answer many of similar or even the same design questions."

Comparação arquitetural de três sistemas, e dois deles são do nosso corpus. Isso é confronto de taxonomia com quem leu o mesmo código que a gente leu, o que nenhuma das duas surveys oferece.

Sobre o número: ele não está no abstract. O abstract traz a formulação qualitativa — "most of the code, however, lives in the systems around this loop" — que sustenta a tese do livro sem sustentar a aritmética. Os 98,4% podem estar no corpo; eu li o abstract. O item continua ⏳ como número e vira achado como paper.

Impacto B nos caps. 01 e 14 e no benchmark.

Ontem publiquei que o registro do ACP "começou a receber produto fechado" e que "hoje a página lista mais". A segunda metade não se sustenta, e a primeira precisa de ressalva.

Duas leituras independentes da página, ontem e hoje, devolvem a mesma lista de 40 diretórios de agente na raiz do repositório, fora .github e .protocol-matrix. Em 20/ago eu havia contado 41. Quarenta e quarenta e um são o mesmo registro dentro da margem do meu instrumento. A frase de que a lista cresceu veio de uma estimativa de resumo — "approximately 50+ agent folders" — que eu tratei como número depois de ter escrito, no mesmo parágrafo, que não publicaria número sem contar.

E a ressalva na primeira metade: os nomes de produto fechado (cursor, devin, github-copilot, poolside) estão lá hoje, e eu não tenho evidência de que sejam entradas novas — em 20/ago anotei apenas os sete nomes ligados ao corpus, e deixei o resto da lista de fora. O fato sobre o registro hoje continua de pé; a afirmação de mudança cai.

Quarto erro da mesma família em dez dias, e sempre no mesmo ponto: número tirado de resumo de página em vez de contagem. A linha do RADAR.md de 27/ago fica corrigida.

E um defeito de renderização, achado na conferência. A linha de 26/ago cita verbatim "malformed commands with a dangling && or || operator", e o || dentro de célula de tabela Markdown é separador de coluna: aquela linha vinha renderizando com oito células em vez de seis desde que subiu. Os dois canos passam a ir escapados, que é a forma de a página exibir exatamente o que a fonte diz. Conferido em todas as linhas da tabela: nenhuma outra tem cano solto. O medidor que pegou isso foi uma contagem de colunas por linha, coisa que o build não faz — vale como sugestão de portão, e portão é decisão do editor.

Publicado em 22/ago, o novo roadmap lista cinco prioridades. Três delas batem em capítulo nosso, e uma delas bate no achado de ontem.

A primeira é uma tensão com a spec que acabou de sair. Verbatim: "Modern agentic workloads no longer fit the standard request-and-response pattern." A especificação 2026-07-28 tem como manchete o núcleo stateless, de requisição e resposta — foi essa a mudança que a spec 060 levou para o cap. 06, três semanas atrás. Menos de um mês depois, o roadmap abre trabalho em eventos iniciados pelo servidor e no amadurecimento da extensão Tasks.

Isso tem menos de contradição e mais de arquitetura declarada: o núcleo fica stateless e o estado sobe para as extensões. O problema é que o cap. 06 apresenta o núcleo stateless como o destino, e o roadmap mostra que ele é a base de outra coisa. A Leitura executiva do 06, reescrita na spec 060, já precisa de ressalva.

A segunda é identidade de agente, e chega no dia seguinte ao achado da credencial presa à origem. Verbatim: "The work here covers finalizing Demonstrating Proof of Possession (DPoP) and driving its adoption, and defining an opinionated path for agent identity and delegation through Workload Identity Federation, the ID-JAG grant behind Enterprise-Managed Authorization, and standard token exchange."

Ontem eu registrei quatro implementações independentes de prender a credencial ao destino. O roadmap propõe o andar de cima: o agente deixa de portar credencial emprestada e passa a ter identidade própria, com delegação explícita. Quatro harnesses convergiram numa defesa, e o protocolo está formalizando a causa raiz que a defesa contorna. Isso é cap. 07 e cap. 17 no mesmo item.

A terceira é descoberta progressiva de ferramentas. Verbatim: "We're starting a progressive discovery effort so a server can offer a small entry point and reveal more of its catalog as the conversation narrows." O cap. 05 trata catálogo de ferramentas como lista, e o cap. 03 trata orçamento de contexto sem incluir o custo do catálogo. Aqui os dois se encontram: o catálogo é entrega de contexto, e passa a ter curva de revelação.

Impacto A no cap. 06 (a Leitura executiva recém-reescrita ganha ressalva), B nos caps. 17, 07 e 05.

O contraditório da auto-evolução entrou no Radar em 07/ago com a marca "⏳ abstract não lido na primária (arxiv.org bloqueado pelo egresso)". Hoje foi lido. O arXiv:2607.12227 sustenta as duas exigências que o Radar já havia registrado a partir de fonte secundária, e a conclusão sai assim: "automatic harness evolution does not consistently outperform simple test-time scaling methods and exhibits limited generalization".

As duas críticas metodológicas são: comparação sem orçamento pareado contra test-time scaling, e busca e avaliação compartilhando o mesmo benchmark. Experimentos em Terminal-Bench 2.1 com GPT-5.4 e Claude Opus 4.6. Código publicado.

O item do RADAR.md sai de ⏳ para confirmado, e o critério que o cap. 16 vai adotar deixa de depender de resumo alheio. Impacto B no cap. 16, sem mudança de conteúdo — muda a qualidade da fonte.

O arXiv:2606.09498 — Self-Harness: Harnesses That Improve Themselves — teve v3 em 20/ago, dentro da janela. Três estágios em ciclo: mineração de fraquezas a partir de logs de execução, proposta de modificação mínima, validação por regressão antes de aceitar. Benchmarks: Terminal-Bench-2.0, SWE-bench Verified e AppWorld, com MiniMax M2.5, Qwen3.5-35B-A3B e GLM-5. Resultado reportado: "every final harness improves both held-in and held-out pass rates, with overall relative gains of up to 132%".

O encaixe com o achado 2 é o que importa. Das duas exigências do contraditório, este paper atende uma explicitamente: reporta held-in e held-out, que é a resposta direta à crítica de busca e avaliação no mesmo benchmark. ⏳ A outra exigência — comparação sob orçamento pareado contra test-time scaling — não aparece no abstract que li, e eu não li o corpo do paper.

Registro assim de propósito. Ontem e anteontem o Radar errou por aproximar amostra que não fechava, e o caminho fácil aqui seria dizer que o Self-Harness responde ao contraditório. Ele responde metade, e a metade que falta é justamente a que o contraditório considera decisiva.

Impacto B no cap. 16: a seção de auto-evolução ganha os dois lados e um caso concreto de como se lê um resultado desses.

Também novo para o Radar, embora de junho: arXiv:2606.12882, HarnessBridge: Learnable Bidirectional Controller for LLM Agent Harness, submetido em 11/jun por Wang, Wang, Taylor, Cong, Sun e Wang. A proposta é tratar a interface entre agente e ambiente como política aprendida, com duas projeções: uma comprime a trajetória bruta em informação relevante para a decisão, a outra traduz ação proposta em transição executável ou em sinal de recusa, ancorado no histórico. Treino por instruction tuning, avaliação em Terminal-Bench 2.0 e SWE-bench Verified, com ganho reportado de igualar ou superar harnesses especializados gastando menos token e trajetória mais curta.

O livro inteiro assume que o harness é escrito. O cap. 16 já discute harness que se modifica. Este é o terceiro ponto do espectro: harness cujo comportamento de interface é treinado, e treinado em modelo pequeno com transferência para modelo comercial grande.

Duas coisas para o livro. A projeção de ação que devolve sinal de recusa é uma política de permissão aprendida, o que joga uma pergunta desconfortável no cap. 07 — uma recusa treinada é auditável? E a projeção de observação é compactação por modelo treinado, o que é vizinho direto da questão aberta do cap. 04 sobre migrar compactação para fora do harness.

Impacto B nos caps. 16 e 05, C nos caps. 04 e 07.

Em 20/ago eu corrigi minha própria contagem deste registro para 41 agentes, dos quais quatro de primeira parte do nosso corpus. Hoje a página lista mais, e o que importa está na composição da lista.

Entre os diretórios que consegui ler aparecem nomes como cursor, devin, github-copilot, github-copilot-cli, poolside, antigravity-acp, qwen-code, mistral-vibe e glm-acp-agent, ao lado dos conhecidos goose, opencode, gemini, grok-build, codex-acp, pi-acp, kimi e claude-acp. O README se descreve, verbatim, como "Registry of agents implementing the Agent Client Protocol, ACP".

O ACP nasceu entre harnesses abertos. A presença de produtos comerciais fechados no registro muda o argumento do cap. 17: já não é o protocolo que os abertos usam entre si, é o protocolo que o editor precisa falar para dirigir qualquer agente. Adoção por quem não publica código é evidência de outro tipo.

⏳ Sem contagem nova. O README não declara total, e eu li uma página renderizada em vez de contar a árvore. Depois de errar essa contagem duas vezes, publico a mudança qualitativa e deixo o número para quando eu puder contar direito. Vale também a ressalva de 19/ago: entrada no registro é afirmação do registro, não prova de implementação completa.

Impacto B no cap. 17.

O Claude Code v2.1.246 traz quatro correções que são a mesma correção, em quatro lugares diferentes do harness:

• "Fixed MCP tool calls interrupted by an incoming message in headless/remote sessions being reported to the model as "completed with no output" instead of an explicit interrupted error"
• "Fixed a command interrupted mid-run showing as "Ran 1 shell command" with no sign it was cut"
• "Improved subagent results: a subagent that stops at its maxTurns limit now returns its output marked as partial, with a hint to continue it via SendMessage, instead of appearing finished"
• "Improved non-interactive sessions (-p, SDK, cloud sessions) to automatically continue a response cut off mid-stream by a server error, connection loss, or stall instead of ending with an error"

Interrupção por mensagem, interrupção no meio da execução, corte por limite de turnos, corte por falha de rede. Quatro causas distintas, e em três delas o que chegava ao consumidor — o modelo, na primeira e na terceira; o operador, na segunda — tinha o formato de um término normal.

No mesmo dia, o gemini-cli v0.57.0 (25/ago) corrige o quinto caso pelo lado do estado: "fix(core): rollback entire multi-turn request on cancellation or abort". Aqui o problema não é o rótulo do término, é o resíduo dele — o pedido cancelado deixava metade de si no histórico.

O livro tem esse defeito catalogado no cap. 11, mas do lado do portão: um verde que mente. O que os dois releases mostram é a versão do cap. 02, que é onde ele nasce. O loop precisa de um vocabulário de término tão explícito quanto o de erro. "Terminou" e "foi cortado" são estados diferentes, e um harness que os representa com o mesmo símbolo entrega ao modelo uma premissa falsa sobre o próprio passado.

Vale dizer o que isto tem de desconfortável: é exatamente o defeito da spec 104 deste repositório, onde o tee transformou deploy recusado em passo verde. Eu havia tratado aquilo como acidente de shell. Cinco instâncias em dois harnesses maduros, numa janela de dois dias, dizem que é classe.

Impacto B no cap. 02 e no cap. 13; a Leitura executiva do 02 não se invalida, ganha exigência.

A série que venho acumulando desde 09/ago diz que a política de permissão falha na borda da sintaxe do objeto que ela regula. Hoje entram dois casos, os de número nove e dez, ambos no Claude Code v2.1.246:

• "Fixed Bash permission checks to always require approval for malformed commands with a dangling && or || operator"
• "Added a startup warning for Bash allow rules with a wildcard before the subcommand (e.g. Bash(git * main)), since they also match options inserted before the subcommand"

O primeiro é a borda clássica: um comando sintaticamente quebrado atravessava a checagem. O segundo é novo em espécie, e é o mais interessante dos dez. Bash(git * main) parece dizer "qualquer subcomando do git que termine em main". O curinga também casa com opções inseridas antes do subcomando, o que muda o que a regra autoriza sem mudar uma letra dela. É irmão do caso do --force dentro de comando permitido, registrado em 12/ago.

E a resposta escolhida foi avisar no startup em vez de fechar. A linguagem de política continua aceitando a regra ambígua, e o harness passa a dizer que ela é mais larga do que aparenta. Para o cap. 07 isso é material direto: quando a expressividade da política é a fonte do furo, existe uma terceira saída entre proibir e permitir, que é tornar visível o que a regra realmente cobre.

Impacto B no cap. 07.

Ainda no mesmo release: "Fixed MCP tools marked requiresUserInteraction still offering "Yes, and don't ask again" in their permission prompt; the option wrote an allow rule the tool then ignored".

O usuário concedia, o harness gravava a regra, e a ferramenta continuava perguntando. A concessão virou artefato de configuração sem virar efeito. Vizinho na mesma lista: "Fixed --strict-mcp-config sessions prompting to approve .mcp.json servers they would never load, which left background sessions waiting at startup" — o inverso, uma pergunta feita sobre algo que nunca aconteceria.

Os dois compõem com o cap. 07 e com o cap. 11: um pedido de permissão só é honesto se a resposta tiver consequência, nos dois sentidos. Impacto B no cap. 07.

O OpenClaw 2026.8.1-beta.3 (24/ago) traz três correções que convergem, todas lidas no CHANGELOG.md da tag:

• "Control UI delayed session commands: bind slash-command mutations and confirmed resets to their originating Gateway, recheck current operator scopes after asynchronous work, and retain reset authorization through queued delivery so reconnects cannot target a replacement connection."
• "Browser extension relay security: require canonical 64-character relay secrets and safe WebSocket pairing URLs, and recheck OpenClaw tab-group consent at the extension edge before every authority-bearing existing-tab command."
• "1Password authorization handoff: persist nonce-bound pending approvals in shared plugin state so hook and tool execution across broker instances remain single-use and fail closed."

Três superfícies, uma regra: a autorização vale onde o efeito acontece, e é conferida ali. E o terceiro item mostra o preço disso — para reconferir na hora, a aprovação precisa durar e precisa ser de uso único, o que exige estado compartilhado com nonce.

Isso fecha, pelo lado positivo, a série do 12/ago sobre identidade da chamada aprovada. Impacto B no cap. 07, com nota no cap. 08 (a aprovação como dado persistido é estado de agente).

"Fixed telemetry and metrics requests to Anthropic carrying the API key configured for a third-party gateway (ANTHROPIC_BASE_URL); a credential is now only sent to its own host" — Claude Code v2.1.246.

O padrão já tinha três implementações registradas em sistemas sem relação entre si: o WithCredentialOrigin do CompozyOS, o secret host binding do OpenClaw e o OAuth de MCP com escopo de origem do IronClaw. Agora são quatro, e a quarta chega por um caminho que ninguém tinha listado: telemetria. O vazamento saiu pelo canal de métrica, que herdou a credencial do gateway configurado em vez da própria.

Quatro implementações independentes é o limiar em que o Radar para de tratar algo como coincidência. Impacto B: vira item do cap. 07 com nome próprio, e o apêndice de supply chain ganha o caso do canal secundário.

O goose v1.47.0 (21/ago) traz "Stop paying the prompt-cache write premium on one-shot fast-model calls" (#11179).

Nona ocorrência desde a abertura do eixo em 13/ago, e a primeira que trata cache como decisão de custo por tipo de chamada. As oito anteriores eram correções de invalidação. Chamada de modelo rápido e de um tiro não vai ser reaproveitada, então escrever no cache é despesa sem retorno. Impacto C no cap. 03, alimentando a seção do eixo que já está na fila.

Duas linhas do mesmo goose v1.47.0, que só fazem sentido juntas:

• "Reject context commands for context-owning providers" (#11094)
• "Skip local Stdio/StreamableHttp extension spawn when provider manages own context" (#11203)

Quando o provedor é dono do contexto, o harness deixa de oferecer comandos de contexto e deixa de subir os servidores de extensão locais. A propriedade do contexto passa a determinar a topologia do processo, além do conteúdo do prompt.

O cap. 03 assume, do começo ao fim, que a entrega de contexto é responsabilidade do harness. Aqui há um caso em que ela não é, e a consequência vaza para o cap. 06, porque o servidor MCP local nem chega a existir. Impacto B no cap. 03, C no cap. 06.

Resposta parcial à pergunta da fila, na leitura de mcp/tool.py do software-agent-sdk (6d388103). Ao executar uma ferramenta MCP, o SDK expande referências de segredo nos argumentos da chamada:

expanded_data = expand_variable_references(
    action.data,
    get_secret=secret_registry.get_secret_value,
    check_env=False,  # secrets only — never expand host env vars
    support_unbraced=True,  # also resolve $VAR like the shell
)

Os dois parâmetros do fim são o achado. support_unbraced=True aceita a forma $VAR do shell, e check_env=False recusa alcançar o ambiente do processo. A mesma sintaxe, com dois universos possíveis, e o registro de segredos é o único autorizado. Na volta, _mask_observation mascara o que o servidor devolveu.

Isso completa o achado de ontem por outro caminho: ontem era o tipo do campo de configuração (SecretStr), hoje é o alcance da expansão nos argumentos. Impacto C no cap. 05, com nota no cap. 07.

Sobre a pergunta em si — onde o PATH é resolvido no lançamento do servidor MCP — a leitura mostra onde ela não mora. MCPClient estende fastmcp.Client, e o arquivo se descreve como "Minimal sync helpers on top of fastmcp.Client, preserving original behavior." O lançamento do subprocesso está na biblioteca, fora do SDK. ⏳ A semântica de resolução continua sem resposta: falta ler o transporte stdio do fastmcp, que não está neste clone.

A Agent Plugins 1.0 deixa ao cliente, por escrito, o que fazer com o ambiente do subprocesso. Ontem descobri que a resposta não mora no carregador de plugin, e sim na camada de MCP. Hoje ela apareceu, e tem duas partes.

Primeira: o tipo carrega a classificação. Em mcp/config.py, a declaração do servidor:

env: dict[str, SecretStr] | None = None
...
headers: dict[str, SecretStr] | None = None

O ambiente do processo filho não é dict[str, str]. Cada valor é SecretStr, e o mesmo vale para os cabeçalhos HTTP. A classificação de segredo deixa de depender de disciplina de quem escreve o código e passa a ser propriedade do dado.

Segunda: o padrão de serialização é redigir. O serializador consulta um modo de exposição, e o resolvedor (utils/pydantic_secrets.py) decide assim:

if not context:
    return "redact"
expose_mode = context.get("expose_secrets")
if expose_mode == "plaintext" or expose_mode is True:
    return "plaintext"
if expose_mode == "encrypted" or context.get("cipher") is not None:
    return "encrypted"
return "redact"

Sem contexto, redige. Sem instrução reconhecida, redige. Texto claro exige pedido explícito. São três estados — redact por padrão, encrypted no caminho de armazenamento quando há cifra, e plaintext só sob opt-in nomeado.

Isto responde a pergunta herdada da spec com um desenho, e não com uma omissão: onde o padrão disse "client-managed", este cliente respondeu tipo forte mais falha fechada.

Impacto B para o cap. 07 e para o apêndice de supply chain. E é um item de "o que roubar" com código curto: quando a decisão de segurança pode ser expressa no tipo, ela para de depender de quem lembra dela.

Do mesmo arquivo, a descrição do campo enabled, verbatim:

"Whether this server is exposed to the agent. A disabled server stays fully configured — including its secrets — but is skipped when MCP tools are created and when servers are forwarded to an ACP subprocess."

Desligar não apaga. A configuração e as credenciais continuam ali, e o que muda é a exposição: o servidor deixa de virar tool e deixa de ser encaminhado ao subprocesso ACP.

É uma escolha razoável de usabilidade e uma superfície que o livro não nomeia. O cap. 07 trata permissão como decisão sobre ação; aqui há um estado intermediário — configurado, com segredo, e inativo — que nenhum dos dois capítulos de segurança discute. Quem faz auditoria de credencial precisa saber que "desabilitado" não significa "sem segredo guardado". C, com nota.

Registro também que o ACP aparece de novo, agora como destino de encaminhamento de servidores MCP. É o quarto sistema em que o protocolo aparece em código, e o primeiro em que ele carrega configuração de MCP para um subprocesso.

A fila pedia uma terceira amostra para a tese aberta em 23/ago — uma decisão de política precisa alcançar o que sobrevive ao turno.

O que encontrei hoje é vizinho, e não é a mesma coisa. O modo encrypted existe justamente para o caminho de armazenamento ("storage-path opt-in"), o que mostra o mesmo cuidado: a classificação do segredo acompanha o dado até a persistência. Mas a tese de 23/ago é sobre recusa — conteúdo que uma guardrail barrou e que precisa sumir do estado durável. Aqui não há recusa; há classificação.

Deixo registrado como adjacência, e a tese continua com duas amostras. Forçar esta como terceira seria exatamente o tipo de aproximação que me obrigou a duas correções ontem.

Em 22/ago escrevi que "a Agent Plugins saiu do papel, e o cliente é do corpus", com impacto B. A nota de release dizia "add Agent Plugins manifest loader", e eu li isso como "está em uso".

O registro de formatos diz outra coisa (openhands-sdk/openhands/sdk/plugin/format/__init__.py), verbatim:

"agent_plugins — the AgentPluginsFormat strategy, not registered."

"detect_format returns the first format in _FORMATS whose PluginFormat.detect returns True. Claude Code is the only registered format today and its detect accepts any directory, so it is the universal fallback."

"AgentPluginsFormat is held out of _FORMATS until its mcp.json and client-extension loaders land (#4405): registering it earlier would claim any directory with a root plugin.json and load it with zero MCP servers."

O código está escrito, revisado e mergeado, e deliberadamente fora do despacho. Hoje o SDK detecta apenas o formato do Claude Code.

A correção é minha, e a razão deles é melhor que a minha manchete. Eles se recusam a registrar o formato porque registrá-lo agora anunciaria um suporte que não existe: qualquer diretório com um plugin.json seria reivindicado e carregado sem servidor MCP nenhum. É a disciplina que o Radar passa o dia cobrando de press release, praticada por quem escreve o código — e o motivo está no comentário, não no anúncio.

Impacto revisado: de B para C. A afirmação que sobrevive é mais fraca e mais precisa — a spec tem implementação escrita num membro do corpus, e ela ainda não roda. O apêndice de supply chain ganha um exemplo do que o livro chama de honestidade de maturidade; o item de 22/ago, corrigido no lugar.

Ontem, sobre a mesma release, escrevi que "um carregador que valida contra esquema fechado recusa campo desconhecido em vez de ignorá-lo". Inferência minha a partir da expressão closed schema.

O código diz o contrário (format/agent_plugins.py), verbatim na docstring de load_manifest:

"Violations are fatal except the two the spec marks non-fatal, which are reported and ignored: unknown top-level fields, and a non-object extensions."

E na implementação, o campo desconhecido é registrado em log e removido do dado antes da validação. A maior parte das violações é fatal; estas duas não são, porque a spec as classifica assim.

O desenho é mais interessante do que a minha versão. Não é o cliente decidindo ser tolerante: é o cliente obedecendo à classificação de severidade do padrão. E há um detalhe de manutenção que vale roubar, no comentário: "Known fields come from the schema, so there is no second field list to drift." A lista de campos conhecidos sai do próprio esquema, então não existe segunda lista para divergir.

C, e corrige o meu texto de ontem.

A fila trazia desde 22/ago três perguntas para este código, vindas do que a Agent Plugins 1.0 delega ao cliente: ambiente do subprocesso, resolução de PATH para comando sem caminho, e armazenamento de credencial.

A leitura mostra que elas não se respondem aqui. O subsistema de plugin não lança processo: ele monta mcp_config: dict[str, MCPServer] e entrega ao agente (plugin/plugin.py, add_mcp_config_to). Quem executa é a camada de MCP.

Não é resposta, é endereço melhor. A pergunta muda de "o que o carregador de plugin faz com o ambiente?" para "o que o cliente MCP faz ao lançar um servidor declarado por plugin?", e passa a ter arquivo para procurar. Fica na fila com o alvo corrigido.

A lista voltou a ler corretamente. Releases de agosto: langgraph-sdk==0.4.3 (19/ago), langgraph==1.2.11 (11/ago), langgraph-checkpoint-postgres==3.1.2 e langgraph-checkpoint==4.2.0 (ambas 07/ago).

Nenhum release do core desde o 1.2.11, que já está registrado desde 18/ago. Era exatamente o que eu não pude afirmar ontem, e agora posso. Sem achado novo, e o registro do não-evento importa: silêncio verificado não é o mesmo que silêncio não conferido.

OpenAI Agents SDK v0.22.0, 19 Aug 13:44, verbatim:

"Redacts terminal function-tool output rejected by agent output guardrails from replayable and persisted SDK state."

A saída de ferramenta foi recusada pela guardrail, e o conserto remove esse conteúdo do estado persistido e do replay. Sem isso, o que a política barrou no turno continuaria vivo no registro que o sistema reproduz depois.

É a mesma família do vazamento de bearer token pelo histórico reproduzido que o Codex corrigiu em 09/ago: em ambos, a defesa cobria o caminho quente e não cobria o durável. O cap. 08 trata memória e estado pela durabilidade e pela fronteira entre efêmero e persistente, sem perguntar o que a política de saída deixa entrar ali. O cap. 07 trata a política no momento da chamada.

A pergunta que falta aos dois: uma decisão de recusa precisa alcançar o que sobrevive ao turno? Com dois casos datados e independentes, a resposta é sim, e vira seção. Impacto B.

Do mesmo release, um vizinho: "Isolates usage accounting between independent RunState checkpoints while preserving nested-agent aggregation." Contabilidade de consumo por checkpoint, que conversa com o "include compaction usage in run totals" do release de 16/ago. C para o cap. 11.

Ontem registrei o AST-backed shell command-name resolution com ⏳, porque a frase vinha da lista de novidades. Fui à página da tag. v1.43.0, 21 Aug 09:51, verbatim:

"feat(security): AST-backed shell command-name resolution (#2721 Phase 2b)"

Duas coisas novas em relação a ontem. A citação existe, com número de issue, o que promove o achado de ⏳ para confirmado. E o "Phase 2b" diz que isto não é um conserto avulso: é etapa de um programa de segurança em fases, num membro do corpus.

O cap. 07 ganha, junto com os oito exemplos da série de falhas de sintaxe, uma defesa datada, nomeada e em andamento. Resolver o nome do comando pela árvore sintática, em vez de casar texto, é o conserto de categoria para toda a família.

Da mesma tag, verbatim:

"feat(plugin): add Agent Plugins manifest loader (root plugin.json, closed schema)"

O detalhe que ontem eu não tinha é closed schema. A spec 1.0, lida em 18/ago, define um formato mínimo e delega ao cliente o que não está nela. Um carregador que valida contra esquema fechado recusa campo desconhecido em vez de ignorá-lo, e isso é uma decisão de segurança: campo extra num manifesto de plugin é superfície.

Reforça o item de ontem e afina a pergunta da rodada: já sabemos que este cliente fecha o esquema; falta saber o que ele faz com o ambiente do subprocesso, com o PATH e com a credencial, que é exatamente o que a spec deixou em aberto.

CrewAI 1.15.17 (20/ago), da lista de novidades: "Handle oversized single messages during chunking".

A escada do cap. 04 pressupõe que dá para escolher o que descartar ou resumir entre várias mensagens. Uma mensagem que sozinha estoura o orçamento quebra essa premissa: não há o que priorizar, porque o item indivisível já não cabe.

O capítulo não discute esse caso. É a borda inferior da escada, e ela aparece na prática sempre que uma tool devolve um blob grande de uma vez. C, com nota — a leitura veio de lista de releases, e hoje lista de releases não é fonte confiável neste ambiente. Confirmar por tag antes de subir de nível.

Software Agent SDK v1.43.0 (21/ago), entre as novidades: "Agent Plugins manifest loader with root plugin.json support".

Em 18/ago li a Agent Plugins 1.0 na primária e registrei o que ela não define, verbatim: "Authorization discovery, user interaction, and credential storage are client-managed", "the client chooses the base subprocess environment and MAY inherit, omit, or sanitize ambient variables" e "whether a configured PATH environment value participates in resolving a bare command is client-defined".

O padrão delegou essas decisões ao cliente. Agora existe um cliente, e ele está no nosso corpus. As perguntas deixam de ser hipotéticas: este cliente limpa o ambiente do subprocesso? Este cliente deixa o PATH resolver comando sem caminho? A resposta está em código legível, e é leitura de rodada.

Impacto B para o apêndice de supply chain e o cap. 12, e vira item de fila com endereço.

Do mesmo release: "AST-backed shell command-name resolution", descrito como melhoria de segurança.

Resolver o nome do comando pela árvore sintática em vez de casar texto é a resposta estrutural à série que este Radar acompanha desde 08/ago e que já tem oito casos: a barra final em denyRead, o symlink, o symlink Cygwin, o prefixo de dispositivo NT, a bandeira --force dentro do comando permitido, o template reexpandido, a identidade da chamada aprovada, e o arquivo renomeado.

Todos são a mesma coisa vista de ângulos diferentes: uma política que interpreta o objeto por padrão de texto perde para quem conhece a sintaxe. Analisar a árvore em vez do texto é o conserto de categoria, e é a primeira vez que vejo um membro do corpus descrever a defesa nesses termos.

O cap. 07 ganha, junto com os oito exemplos, o desenho que os resolve. Isso muda a seção de um catálogo de falhas para um argumento com saída. Impacto B.

⏳ A frase vem da lista de novidades da release, não da página individual. O conserto vale a leitura de código na próxima rodada, e a citação precisa ser confirmada antes de ir ao capítulo.

Ontem registrei a migração do Hermes como C, porque a linha vinha do resumo da lista de releases e resumo não vira citação. Fui à página da release. v0.20.3 (16/ago), verbatim:

"the MCP 2.x SDK migration and 2026-07-28 stateless protocol support"

A spec está nomeada pela data. É a primeira adoção de campo do núcleo stateless por um membro do corpus, e ela muda o que o cap. 06 pode afirmar. A spec 060 revisou o capítulo porque a Leitura executiva celebrava justamente o que a 2026-07-28 depreciou; até ontem o argumento disponível era "a especificação mudou". Agora existe um harness que foi atrás.

Promovido de C para B.

Releases, 1.3.0 (19/ago), três itens de interesse:

"Explicit Anthropic cache_control prompt-cache breakpoints on both transports." O eixo de cache aberto em 13/ago tem agora oito ocorrências, e esta é a mais direta de todas: as anteriores tratavam de cache quebrado por efeito colateral — compactação, fan-out, reconexão de LSP, gateway. Aqui o harness decide onde ficam as fronteiras. Deixa de ser restrição sofrida e vira parâmetro de projeto.

"Hosted MCP OAuth supports origin-scoped servers." É a terceira implementação independente do mesmo padrão em nove dias, depois do WithCredentialOrigin do CompozyOS (13/ago) e do "bind each shared-store secret to exact HTTPS destination hosts" do OpenClaw (17/ago). Três sistemas, três códigos, uma tese: alcance de rede e autorização de credencial são eixos separados. Com três primárias, o item de "o que roubar" do cap. 07 deixa de precisar de qualificação.

"Model-bound secrets redacted without rejecting the turn." Redigir e seguir, em vez de recusar. É uma escolha de projeto que o cap. 07 não discute: o que o harness faz quando encontra segredo no caminho — barra a operação ou deixa passar sem o segredo. C, com nota.

E um quarto item que registro sem conclusão: "Telegram linked devices allowing agents to read conversations and act as users". Agir como o usuário é uma afirmação de autoridade, não de integração. ⏳ até leitura da primária sobre que credencial sustenta isso.

A busca trouxe o TrueForge, da TrueFoundry, anunciado como harness de código aberto sob MIT em 19/ago. Triagem no repositório, truefoundry/trueforge:

• TypeScript, não arquivado, 3.291 estrelas / 229 forks → 14,4:1 ✓;
• criado em 2026-07-23, quase um mês antes do anúncio;
• descrição verbatim: "The open-source agent harness - the runtime layer that turns an LLM into a working agent.";
• entre os tópicos declarados: harness-engineering.

Duas notas. A primeira é de método: 19/ago é a data do anúncio, não a do repositório, e o contrato manda verificar quando separado de o quê. A segunda interessa ao cap. 01: o termo que dá nome a este livro aparece como tópico de classificação no repositório de um fornecedor, ao lado de agent e agentic-ai. Soma-se ao HarnessAgent da Microsoft (11/ago) na série de "o campo tem nome". C, candidato à watchlist.

Hermes v0.20.4 (18/ago), verbatim:

"NVIDIA SkillEvaluator Tier 1 advisory scanning on skill installs (license + security checks)"

Três palavras dessa linha carregam o achado.

"Scanning" — nenhum dos quatro desenhos registrados em 17/ago olha para dentro do artefato. O CompozyOS exige digest, que prova identidade e nada diz sobre conteúdo. O OpenClaw exige um gesto explícito. O Claude Code bloqueia por lista. O IronClaw instala por link. Este abre e examina.

"License + security" — a verificação tem dois eixos, e o primeiro é o que o holaOS expôs em 13/ago, quando um repositório que se anuncia open-source trazia licença com restrição de uso comercial. Um instalador que checa licença automaticamente responde a esse problema no ponto de entrada.

"Advisory" — e aqui está o limite. O scanner avisa e não impede. Some-se o "Tier 1", que sugere níveis, e o desenho fica claro: inspeção graduada, decisão do usuário. É o mesmo lugar da curva onde o OpenClaw parou, com informação melhor para quem decide.

O espectro do apêndice de supply chain vai a cinco entradas, e ganha um eixo que ele não tinha. Os quatro primeiros diferem em quanto atrito impõem; este difere em o que se sabe antes de decidir. Impacto B, somando-se ao B→A já registrado para o apêndice.

Vale registrar quem faz a verificação: um terceiro (NVIDIA), não o fornecedor do harness nem o registro de skills. A cadeia de confiança ganha mais um elo, e o cap. 12 não discute quem audita o auditor.

Da página de releases, v0.20.3 (16/ago), na lista de novidades: "MCP 2.x SDK migration with stateless protocol support".

Seria a primeira adoção de campo do núcleo stateless da spec 2026-07-28 por um membro do corpus. O cap. 06 foi revisado na spec 060 justamente porque a Leitura executiva celebrava o que a spec nova depreciou, e uma migração real muda o argumento de "a spec mudou" para "os harnesses estão indo".

⏳ Não confirmei esta linha na página da release individual. Ela vem do resumo da lista de releases, e a regra da casa é que resumo não vira citação. Fica como achado provável, marcado, com a leitura do v2026.8.16.2 no topo da fila. C até a confirmação, B depois dela.

Ontem registrei que o agent.json do registro do ACP declara "license": "proprietary" para o Grok Build, enquanto o nosso apêndice o traz como Apache-2.0. Fui ao repositório.

xai-org/grok-build, verbatim:

"First-party code in this repository is licensed under the Apache License, Version 2.0"

E a distribuição descrita ali é de binários pré-compilados para macOS, Linux e Windows, de um CLI em Rust. O registro do ACP, por sua vez, aponta para um pacote npm: @xai-official/grok@1.0.7.

São artefatos diferentes com nomes diferentes. O repositório de código é aberto; o pacote npm que o registro instala é declarado proprietário por quem submeteu a entrada. O teste de inclusão do cap. 01 §6 pergunta pelo que é inspecionável na data de corte, e isso é o repositório — que segue Apache 2.0, como o apêndice diz. Nenhuma correção necessária.

⏳ O que fica em aberto é a identidade: @xai-official/grok e xai-org/grok-build são o mesmo produto empacotado de duas formas, ou coisas distintas? Não resolvi, e não vou resolver por inferência de nome — foi exatamente esse atalho que produziu os três erros de ontem.

Releases de 20 e 21/ago, em 2.35.6, 2.36.4 e 1.123.75: "End-user credentials resolution for node parameters" e "Chat and MCP trigger authentication validation for end-user credentials".

Num harness embutido, a credencial que o agente usa pode ser a do dono do fluxo ou a de quem disparou a execução, e a diferença decide quem responde pelo que a ferramenta fez. O cap. 15 trata o arquétipo embutido pela forma da tarefa e pelo provedor do modelo, sem tocar em identidade de execução. C, com nota de que o tema aparece agora em dois pontos independentes do mesmo release.

Nenhuma release entre 16 e 21/ago; a mais recente segue a 2026.8.1-beta.2, já no Radar desde 17/ago. Relendo suas notas, um item passou batido: "Trusted-proxy browser pairing: optional auto-approval for Control UI devices from allowlisted proxy identities with non-admin scope caps."

Aprovação automática decidida pela identidade do proxy, com teto de escopo. É a terceira variante do mesmo mecanismo em uma semana: o CompozyOS usa procedência para restringir, o n8n usa para dispensar aprovação, e aqui ela aprova sozinha, mas com limite de alcance. A terceira é a mais interessante das três, porque combina as duas metades. Acrescentado à linha existente do RADAR.md, sem item novo.

Ontem escrevi, a partir de um resumo de busca, que o registro do ACP tem 56 agentes e que sete são do nosso corpus. Marquei ⏳ em duas correspondências feitas por inferência de nome e disse que esse número iria para o capítulo, então precisava estar certo. Fui conferir no repositório. As três afirmações precisam de conserto.

Primeiro: são 41 agentes, não 56. Contagem de diretórios no clone.

Segundo: kimi é outro produto. O agent.json da entrada aponta para github.com/MoonshotAI/kimi-cli. O nosso corpus tem Kimi Code, em MoonshotAI/kimi-code — mesmo fornecedor, repositório diferente. Não é correspondência.

Terceiro, e o mais importante: metade das correspondências é adaptador de terceiro. O que o agent.json de cada entrada mostra:

Então o número honesto é quatro membros do corpus com ACP de primeira parte, e não sete. Dois outros são alcançáveis por ACP porque alguém de fora escreveu a ponte, o que é uma afirmação diferente e mais fraca: diz que o protocolo é fácil de adaptar, não que o fornecedor o adotou.

É a terceira vez em uma semana que a minha contagem de protocolo sai confiante demais — depois do "zero com A2A" corrigido em 17/ago. O ⏳ funcionou: ele estava exatamente nas duas entradas que se revelaram erradas. O que falhou foi tomar um resumo de busca como número.

A leitura corrigida do cap. 17 continua boa, e fica mais precisa: quatro fornecedores do corpus adotaram o ACP, e o ecossistema em volta produziu pontes para outros dois. A adoção tem gradiente, e é o gradiente que o capítulo precisa registrar. Impacto B.

Do README.md, verbatim:

"Authentication Required: This registry maintains a curated list of agents that support user authentication. Users must be able to authenticate themselves with agents to use them. All agents are verified via CI to ensure they return valid authMethods in the ACP handshake."

A parte que eu não tinha ontem é a última. O registro não confia na declaração de quem submete: um job de integração contínua abre o handshake e confere se o agente devolve métodos de autenticação válidos. Uma entrada ali é uma afirmação testada, com o teste rodando.

Isso muda o peso da tabela do achado 1. E é material do cap. 17 por si: um registro de protocolo com conformidade verificada por CI é artefato de governança, e o capítulo trata governança de protocolo pela fundação que o hospeda, não pelo mecanismo que valida quem está dentro. Impacto B, com o apêndice de supply chain de carona — a mesma pergunta de procedência que os quatro desenhos de plugin levantaram em 17/ago, aqui com uma resposta que ninguém tinha dado: verificar por execução.

Claude Code v2.1.236 (19/ago), verbatim:

"Sandbox: on macOS, wildcard read-deny rules (e.g. **/.env) now take precedence inside allowed read regions, cover matched directories' contents, and can't be bypassed by renaming the denied file"

São três defeitos numa frase, e o terceiro é de outra natureza. Os dois primeiros são precedência: a negação perdia para a permissão dentro de uma região liberada, e não alcançava o conteúdo dos diretórios que casavam. O terceiro é sobre o que a regra identifica: ela nomeia um caminho, e um caminho se troca. Quem quisesse ler o arquivo negado renomeava.

É o oitavo caso da série que o Radar acompanha desde 08/ago, e ele fecha o arco com o primeiro: a barra final em denyRead: "~/.aws/". Mesma família, mesmo produto, doze dias, e agora com a variante que interessa ao cap. 07 — uma política que identifica o objeto pelo nome herda a mutabilidade do nome. Isso é seção, e agora tem oito exemplos datados para sustentá-la. Impacto B.

v2.1.237 (20/ago), verbatim:

"Fixed prompt caching for sessions using an LLM gateway or custom base URL"

Sétima causa de quebra de cache registrada desde 13/ago, e a primeira que vem da topologia da conexão: passar por gateway ou trocar a URL base derrubava o cache. Junta-se à reconexão de LSP (18/ago) na mesma categoria — subsistemas vizinhos derrubando o prefixo por efeito colateral. C, reforço do eixo.

Do mesmo release, um item que conversa com o que este repositório fez ontem:

"Added a built-in "Concise" output style: Claude leads with results and skips preamble and narration, while doing the work just as thoroughly."

Liderar com o resultado e cortar preâmbulo e narração é, quase palavra por palavra, o que a §28 da skill humanizer combate. Na mesma semana em que o livro adotou a régua como norma editorial, um harness do corpus embarcou o equivalente como configuração de produto. O cap. 03 trata o prompt de sistema como entrega de contexto e não discute estilo de saída como ajuste exposto ao usuário. C, com nota: é a primeira vez que vejo um harness tratar verbosidade do agente como preferência configurável, e não como característica do modelo.

Eu vinha construindo a leitura do cap. 17 com anedotas: um sistema aqui, outro ali, contados à mão e corrigidos duas vezes por excesso de confiança. O registro oficial do ACP resolve isso com dado, e ele é mantido pela própria organização do protocolo: 56 entradas, e a lista inclui, por nome:

agoragentic-acp, amp-acp, auggie, autohand, claude-acp, cline, codebuddy-code, codex-acp, cortex-code, corust-agent, crow-cli, cursor, deepagents, devin, dimcode, dirac, factory-droid, fast-agent, gemini, github-copilot-cli, github-copilot, glm-acp-agent, goose, grok-build, harn, junie, kilo, kimi, minion-code, mistral-vibe, nova, opencode, pi-acp, poolside, qoder, qwen-code, sigit, stakpak, vtcode

Cruzando com os 21 do nosso corpus (livro/apendice-estudo.md), correspondem sete: goose → Goose · opencode → opencode · codex-acp → Codex CLI · gemini → gemini-cli · grok-build → Grok Build · pi-acp → Pi · kimi → Kimi Code.

Um terço do corpus está registrado como implementando ACP. Some-se claude-acp ("Use Claude Agent SDK from any ACP client", 2.398★ na mesma organização), que não é membro do corpus mas é a referência do livro inteiro.

O que isto faz com o cap. 17. A Leitura executiva apresenta o A2A como a resposta ao agente-para-agente, e eu já a qualifiquei duas vezes esta semana — a segunda para me corrigir, quando descobri que o Hermes embarca A2A desde 03/ago. A formulação honesta agora, com as duas evidências na mesa, é uma terceira e melhor: o ACP tem implementação ampla e verificável entre harnesses de código; o A2A tem declaração ampla entre organizações. São coisas diferentes, medidas por instrumentos diferentes, e o capítulo trata as duas como se fossem a mesma.

Ressalva de método, e ela importa: uma entrada no registro é uma afirmação do registro, não prova de implementação completa. O que vale a mais é que a listagem tem critério — o repositório diz manter "a curated list of agents that support user authentication", exigindo que o agente devolva métodos de autenticação válidos no handshake. E dois dos sete (kimi, pi-acp) eu casei por inferência forte de nome, não abrindo cada entrada.

Impacto B, tendendo a A para o 17 — é a primeira evidência de escala que o capítulo tem sobre adoção de protocolo, e substitui uma contagem minha que já errou duas vezes.

Claude Code v2.1.235 (18/ago), verbatim:

"Fixed Shift+Tab inside the permission prompt's comment field approving the edit and granting session-wide edit permission instead of closing the field"

Leia o que a correção descreve. O usuário está no campo de comentário do próprio diálogo de aprovação — o lugar onde ele escreve por que está negando ou condicionando —, aperta o atalho para sair do campo, e o gesto aprova a edição e libera permissão de edição para a sessão toda.

É a sétima variedade da série que o Radar vem juntando, e a mais desconfortável, porque não está na sintaxe de um caminho nem na identidade de uma chamada: está na interface do portão. O mecanismo de permissão funcionou como projetado o tempo inteiro; quem falhou foi o gesto que o opera. Um portão cuja afordância de "sair daqui" é indistinguível de "autorizar tudo" não é um portão mais fraco — é um portão que o usuário não consegue usar corretamente.

Isso liga o cap. 07 ao cap. 13 num ponto que nenhum dos dois cobre: a permissão é uma decisão humana, e decisão humana passa por interface. O cap. 13 argumenta que o núcleo publica eventos e a superfície renderiza; aqui a superfície não só renderizou como decidiu.

Impacto B para o 07 e o 13.

agentclientprotocol/agent-client-protocol: Apache-2.0, não arquivado, 4,0 mil estrelas / 348 forks (11,5:1 ✓), com GOVERNANCE.md e MAINTAINERS.md — processo declarado, não projeto de um fornecedor só. Do README, verbatim:

"ACP is a protocol intended for broad adoption across the ecosystem; we follow a structured process to ensure changes are well-considered."

E a decisão técnica que interessa ao capítulo:

a versão estável é a 1, e "wire compatibility is determined by the protocolVersion exchanged during initialization, not by crate or schema release versions".

Contraste direto com o MCP, cuja compatibilidade anda por spec datada (2026-07-28) — e cujo release mais recente causou, em campo, o problema de reabertura de stream que o Claude Code corrigiu em 14/ago. Dois protocolos vizinhos, duas políticas de versionamento: negociar na conexão contra datar a especificação. O cap. 17 descreve os dois e não compara as políticas. Impacto B.

v2.1.235 (18/ago), verbatim:

"Fixed whole-prompt-cache invalidation when a language server disconnected or reconnected mid-session"

Causa nova no eixo aberto em 13/ago: reconexão de LSP invalidando o prompt cache inteiro. Não é compactação, não é fan-out, não é montagem — é um subsistema vizinho derrubando o cache por efeito colateral. Sexta semana-sistema do eixo.

E de v2.1.234 (17/ago), verbatim:

"Claude Code now continues your session automatically when a claude.ai usage limit resets; turn it off in /config"

O laço passou a atravessar sozinho uma fronteira que antes exigia humano. É um item pequeno de changelog e uma mudança de categoria: a espera pela cota deixou de ser fim de sessão e virou pausa interna do loop. Cap. 02 e cap. 16. C cada, com nota.

Do mesmo release: "Fixed the Agent tool advertising a general-purpose default in sessions where that agent is unavailable" — C, caps. 05/10 (a ferramenta anunciava capacidade que não tinha).

Ontem escrevi, com base no resumo de busca, que a Agent Plugins 1.0 põe "distribuição, permissão de runtime e confiança fora de escopo", e citei a frase "finding a package is also not the same as trusting or executing it" como se fosse da spec.

Essa frase não está na spec. Ela veio de comentário de terceiro no resumo da busca, e eu a apresentei com aspas ao lado do nome do padrão. Corrigido aqui: a citação sai.

O que a primária diz é mais específico e mais interessante que a paráfrase. Do spec/1.0.0.md, verbatim:

"Agent Plugins v1 defines no OAuth configuration or portable credential-reference fields. Authorization discovery, user interaction, and credential storage are client-managed."

"The client chooses the base subprocess environment and MAY inherit, omit, or sanitize ambient variables."

"Whether a configured PATH environment value participates in resolving a bare command is client-defined."

"Validation and failure handling within an implemented namespace are defined by that client."

E do README: "How the client exposes the skill to users or models is outside the Agent Plugins specification."

Não é uma declaração genérica de "confiança fora de escopo". São decisões específicas e portadoras de risco, delegadas nominalmente ao cliente — e a terceira é a mais afiada: se o PATH participa ou não da resolução de um command sem caminho é indefinido pelo padrão. Isso é o sequestro de PATH, o vetor clássico de execução de plugin, deixado em branco por escrito.

Some-se que o ambiente do subprocesso pode herdar variáveis ambientes — quando o defensive-patterns.md do DeepSeek, lido em 16/ago, diz o oposto como regra ("Spawned commands get a scrubbed env (drop *KEY*/*SECRET*/*TOKEN*/*PASSWORD*)").

O espectro de quatro desenhos registrado ontem fica de pé, e com fundamento melhor: não é que o padrão se omitiu por descuido, é que ele delegou por escrito, item a item. Impacto B→A para o apêndice de supply chain; o cap. 12 cita plugin.json só como formato no Apêndice A.

n8n 2.35.3 (14/ago), verbatim:

"Prevent agent from claiming integration tool call success early"

O agente declarava sucesso de uma chamada de integração antes de ela ter sucedido. É exatamente a tese do cap. 11 — otimizar o sinal em vez do resultado — num harness embutido, em produção, com data e correção. A cena de abertura do capítulo é o agente que faz os testes passarem pulando os testes; isto é o mesmo mecanismo do outro lado da fronteira: o agente que relata o que não aconteceu.

Do mesmo release, o inverso do que li no CompozyOS:

"Skip update approval for workflows created in the same Instance AI session"

O CompozyOS usa a procedência do turno para restringir (turno vindo da rede perde escrita de arquivo). O n8n usa a procedência da sessão para relaxar (workflow criado na mesma sessão de IA dispensa aprovação de atualização). Mesmo mecanismo, direções opostas, e o segundo é uma decisão de usabilidade com consequência de segurança: quem controla a sessão controla o portão.

Impacto B para o 11 e o 15; B para o 07 (o par de procedência).

Ainda: "Recover stuck tool-call UI and MCP timeout progressive update" — C, cap. 06/13.

v0.21.1 (16/ago), verbatim:

"honor exact call approval decisions"

A decisão de aprovação não estava casando com a chamada exata que a originou. É uma subespécie nova da série que o Radar vem juntando: até agora a política falhava na borda da sintaxe do objeto (barra final, symlink, prefixo NT, bandeira, template reexpandido); aqui ela falha na identidade do objeto — aprovar uma chamada e a aprovação valer para outra.

E o item que interessa ao cap. 04:

"include compaction usage in run totals"

A compactação consome tokens e esse consumo não entrava na conta da execução. O cap. 04 discute o custo da escada e a Leitura executiva fala em migrar compactação para o provedor; nenhuma das duas registra que a própria compactação é uma linha do orçamento — e que ela pode ficar fora da medição. Impacto B para 04 e 11.

Menores: "add model call timeouts" (C, cap. 02), "add Modal sandbox resource options" (C, cap. 07 — contenção por recurso, mesmo eixo do cgroup de 14/ago), e "keep model paths POSIX-normalized" + "normalize apply_patch paths as POSIX" (C, cap. 07 — normalização de caminho, a mesma família da semana, agora num framework).

Software Agent SDK v1.42.0 (11/ago), verbatim: "emit LLM and TOOL spans for ACP turns".

Não é adoção nova de protocolo: é o protocolo já suficientemente assentado para virar unidade de observabilidade. Um turno ACP é a coisa que se instrumenta. Reforça a leitura corrigida ontem do cap. 17 — os dois protocolos têm código, em camadas diferentes — e acrescenta que o ACP já chegou à camada de telemetria em pelo menos um sistema.

Do mesmo release: "Fixed goal loop halting on STUCK runs" — STUCK como estado nomeado de execução. O cap. 02 defende rótulo tipado de terminação; "travado" é um rótulo que o livro não lista, e é o segundo sistema de hoje com o conceito (o n8n tem "stuck tool-call UI"). C para o 02, com nota de que dois sistemas independentes nomearam o mesmo estado.

E "Implemented prompt-based evaluation for hooks" — hook cuja decisão vem de um prompt. C para 12 e 11, com desconforto registrado: o cap. 12 argumenta que o retorno do hook é o canal de controle; um hook julgado por modelo herda todos os problemas de confiabilidade do modelo no ponto onde o harness decide.

Três releases lidos: 1.15.16 (14/ago) — "Introduce execution context management with UUID support" e "Record what kind of exception ended a flow"; 1.15.15 (12/ago) — "Report flow outcome, duration, and human-in-the-loop signals"; 1.15.14 (08/ago) — "Split runtime context from coding agent and add project ID".

O tema é um só: saber o que aconteceu. E o item do meio é o mais interessante para o livro — sinais de humano no laço como métrica reportada. Medir quantas vezes o humano precisou intervir é o instrumento que falta ao cap. 11 para falar de autonomia sem retórica. C, com um B latente se aparecer em outro sistema.

LangGraph 1.2.11 (11/ago) — "expose trace_policy on add_node", mais consertos de checkpoint. Mesmo tema, menor. C, cap. 13.

Um wire de press release anunciou em 14/ago que a HarnessRouter "open-sources the world's first unified interface for agent harnesses and the Unified Harness Protocol".

Triagem no repositório, HarnessRouter/harnessrouter: Apache-2.0, Python, não arquivado, criado 2026-08-09, 111 estrelas / 7 forks (15,9:1 — razão boa, número absoluto minúsculo). Descrição verbatim: "the self-hosted, Apache-2.0 edition of the unified interface for agent harnesses. Run Codex, Claude Code, Hermes, and more through one API… Implements the Unified Harness Protocol (UHP), an open standard."

O projeto é real; a alegação é que está inflada. "Primeiro do mundo" para uma camada onde o ACP já tem quatro sistemas com código, e "padrão aberto" para um repositório de nove dias com 111 estrelas. O teste de inclusão do cap. 01 §4 pede adoção ou singularidade arquitetural; a adoção não está lá, e a singularidade é justamente o que o ACP contesta.

Fica na watchlist, não no corpus. E vale como o quinto item da série de press release pago com alegação superlativa que o contrato manda desconfiar — desta vez sem repositório falso por trás, só com adjetivo grande demais. C para o cap. 17.

Venho registrando, desde 13/ago, uma leitura que ficou cada vez mais confiante: "três sistemas novos com ACP em código e zero com A2A", e daí a conclusão de que o ACP é onde está a dor e o A2A é onde está o anúncio.

O Hermes Agent v0.20.0, de 03/ago, página da release lida hoje, verbatim:

"Hermes speaks Agent-to-Agent — A2A v1.0 — A new bundled plugin implements the Agent-to-Agent protocol, so Hermes can discover, talk to, and be driven by other A2A-compatible agents."

E na lista de itens: "A2A v1.0 — Agent-to-Agent protocol plugin (closes #514)" — fechando uma das issues mais antigas do repositório.

grep no nosso repositório: não estava registrado em lugar nenhum — nem no capítulo 17, nem na ficha do Hermes, nem no Radar.

Como a frase era falsa sem ser mentira. Eu escrevi "sistemas novos", numa janela de cinco dias, e o Hermes não é novo nem entra na janela. Literalmente correto. Mas a conclusão que eu construía em cima — implementação acontece no ACP, não no A2A — depende de um universo que eu escolhi sem dizer que estava escolhendo, e o dado que ficou de fora é justamente um membro do corpus implementando A2A nos dois sentidos (descobrir, falar, e ser dirigido).

É o modo de falha que o próprio contrato nomeia: a alegação que confirma um preconceito do Radar é a que mais exige verificação. Ela veio confirmando o meu, por cinco dias, e eu não fui olhar o corpus.

A leitura corrigida do cap. 17 é mais interessante que a errada: os dois protocolos têm código, em camadas diferentes. ACP aparece onde um cliente dirige um agente inteiro (CompozyOS, Kiro Crew, DeepSeek); A2A aparece onde um agente fala com pares de outros fornecedores (Hermes) — e aparece como plugin empacotado, não como núcleo. Impacto B, e a linha do RADAR foi corrigida no lugar.

Somando o que foi lido em primária nos últimos sete dias, existe um espectro — mesmo problema, quatro respostas, ordenadas por rigor:

Do mais estrito ao mais permissivo: exigir hash · exigir gesto explícito com gradiente de atrito · bloquear por lista e reavaliar por sessão · instalar por link.

E a spec que deveria arbitrar se declara fora. A busca de hoje aponta que a Agent Plugins 1.0 (06/ago) padroniza Agent Skills e servidores MCP num diretório com manifesto plugin.json, e deixa distribuição, permissão de runtime e confiança fora de escopo — com os autores registrando que "finding a package is also not the same as trusting or executing it". Não li a spec (⏳); mas o nosso cap. 12 já cita plugin.json como detalhe de formato de um harness, no Apêndice A, e não como padrão com fronteira de escopo declarada.

Isso é material do apêndice de supply chain de outra ordem: hoje ele trata risco de dependência e de registro. O que este espectro mostra é que a decisão de confiança foi empurrada para o harness por omissão do padrão — e que cada um resolveu num ponto diferente da curva atrito × segurança. Impacto B, tendendo a A (o apêndice ganha uma seção comparativa que não existe).

Hermes v0.20.0, verbatim:

"Ghost-skill defense — [SKILL_PRUNED] markers, protected prune, deterministic survival; progress-aware timeouts"

O nome descreve o defeito melhor que qualquer explicação minha: a skill foi podada do contexto e o modelo continua agindo como se ela estivesse lá. A defesa é deixar marca no lugar ([SKILL_PRUNED]), ter poda protegida e sobrevivência determinística — isto é, o que fica não pode depender de sorte.

Do mesmo release, dois vizinhos:

"Proactive tool-result pruning for large-window models; per-turn micro-compaction; N-user tail guarantee"

A cauda intacta que a Leitura executiva do cap. 04 manda roubar aparece aqui como garantia nomeada e parametrizada (N), não como recomendação. E micro-compactação por turno é eixo novo: o capítulo trata compactação como evento raro e caro, disparado por pressão; isto é compactação contínua e barata, em toda volta do loop.

Some-se "Per-model threshold overrides; absolute token threshold (compression.threshold_tokens)" — limiar por modelo, não global.

Impacto B para o cap. 04: são três coisas que o capítulo não tem (o modo de falha ghost skill, a garantia de cauda como parâmetro, e a compactação por turno), e a primeira delas é um defeito nomeado por quem o viveu, que é o tipo de evidência mais barata de citar e mais difícil de inventar.

OpenClaw 2026.8.1-beta.2 (15/ago), verbatim:

"bind each shared-store secret to exact HTTPS destination hosts" — para impedir egresso de texto claro não vinculado.

É o mesmo desenho que li no CompozyOS em 13/ago (WithCredentialOrigin: liberar encaminhamento de credencial "without granting access to private resolved addresses"). Dois sistemas independentes, quatro dias, mesma tese: poder alcançar um host não implica poder mandar o segredo para ele.

Com duas fontes primárias, isso deixa de ser curiosidade de um harness e vira item de "o que roubar" do cap. 07 com lastro. Ainda do mesmo release: "sandboxed browser routes, trusted DNS targets, custom browser origins, and loopback provider endpoints now reject unsafe access paths" — DNS como eixo de confiança, que é o vetor de rebinding e não aparece no capítulo.

Impacto B para o 07.

Hermes v0.20.2 (16/ago): "LiteLLM prompt caching for Claude on OpenAI wire" — cache atravessando protocolo de fio de outro fornecedor. E v0.20.0: "Tool schemas cached on native Anthropic without history loss + consolidated cache-plan internals" — "plano de cache" como conceito interno nomeado.

O eixo aberto em 13/ago tem agora cinco sistemas com trabalho primário de cache em uma semana (goose, Claude Code, MCP spec, e agora Hermes nos dois releases). O cap. 10 segue sem mencionar cache, e o cap. 04 o trata só como restrição. Reforça as duas qualificações já registradas; sem impacto novo.

• IronClaw v1.2.0 (13/ago), estável, com RC2/RC3 em 12/ago: "Windows filesystem publication using atomic rename semantics" (C, cap. 08 — durabilidade de escrita) e "improved account identity preservation for standalone secrets management" (C, cap. 07).
• Hermes v0.20.1 (13/ago) e v0.20.2 (16/ago) são patches de consolidação. As releases afirmam ~656 e ~397 PRs; registro como o que a release diz, não como contagem nossa — não medi o repositório.
• Claude Code: sem release em 15 nem 16/ago (primária conferida ontem).

grep: nenhum está no repositório. 2603.00195 Formal Analysis and Supply Chain Security for Agentic AI Skills — o mais aderente ao achado 2 · 2606.25189 ActPlane: Programmable OS-Level Policy Enforcement for Agent Harnesses — cap. 07 · 2605.21392 VIPER-MCP: Detecting and Exploiting Taint-Style Vulnerabilities in Model Context Protocol Servers — cap. 06 e supply chain.

C, com título e identificador e nada mais. Décimo primeiro dia de arxiv.org bloqueado.

Ontem li no Kiro Crew que o portão da superfície de injeção durável falha aberto: qualquer exceção inesperada em _vet_memory_writes_governance audita a degradação e retorna None, que ali significa permitido.

Hoje, no DeepSeek Harness, o contrato do sandbox diz o oposto, e diz com todas as letras (docs/subsystems/sandbox.md, verbatim):

"ctx.sandbox.confine(argv, policy) returns a ConfinedArgv or throws SandboxUnavailableError with code SANDBOX_UNAVAILABLE when no usable backend exists. … Silent unconfined passthrough is never legal for a confined policy."

E, na descrição da própria costura abstrata:

"confine must return enforcing argv or fail closed at wrap or runner-execution time; silent unconfined passthrough is forbidden."

Os dois casos são a mesma pergunta de projeto — o que o portão faz quando não consegue decidir? — e as respostas são opostas: um devolve "permitido" para não derrubar a chamada; o outro proíbe nominalmente o caminho silencioso e aceita quebrar.

Não são equivalentes em risco. No Kiro Crew a falha aberta está na superfície que o próprio código chama de "instruction-injection surface"; no DeepSeek a regra fechada está na execução de processo. Mas a lição é a mesma e o cap. 07 não a formula: um portão precisa declarar o comportamento no caso indeciso, e esse comportamento é parte do contrato, não detalhe de implementação.

Impacto B para o 07 — é seção, com dois exemplos primários, datados e contraditórios. É o melhor material que o Radar produziu para esse capítulo desde a série de bordas de sintaxe.

O docs/architecture.md diz que tudo é plugin "replaceable from configuration", incluindo o loop. A leitura de hoje mostra que o projeto classifica o que é trocável e o que não é, e usa vocabulário próprio para isso. O README do guard/ (verbatim):

"A guard is a self-contained consumer of core services and extension points, not a swappable capability."

Enquanto o sandbox é, nominalmente, uma "process-sandbox capability family" — e o README avisa que "isolated environments replace complete capability implementations instead of registering here".

Ou seja: existe uma taxonomia entre consumidor de extensão (não trocável) e capacidade (trocável inteira), e o sandbox está do lado trocável. Isso não é uma falha — é a consequência honesta da tese, e é exatamente a pergunta que o cap. 12 deveria fazer e não faz: quais pontos de extensão a segurança pode ocupar?

E liga ao que o Claude Code corrigiu como bug em 13/ago (configuração de projeto trocando o binário do sandbox). Dois harnesses, duas leituras do mesmo fato: num é defeito a consertar, no outro é arquitetura declarada. ⏳ Não verificado: de onde a configuração que troca uma capacidade pode vir — não achei documento de precedência ou confiança de configuração. É a pergunta número um da fila.

Impacto B para 12 e para o apêndice de supply chain.

docs/defensive-patterns.md, primeira frase, verbatim:

"Hard-won bug-class rules: each pattern below is a class of defect that actually shipped or nearly shipped here, stated as the rule that prevents its recurrence."

Compare com a linha de abertura do nosso .specify/memory/checklist-verificacao.md: "Cada item existe porque já falhou uma vez." São o mesmo artefato, com o mesmo critério de admissão, num projeto que não conhece o nosso.

Sete regras, e uma delas é a série desta semana virada norma — "Unlink link-shaped paths":

"A path that may be a symlink or Windows junction is removed with lstatSync().isSymbolicLink() then unlinkSync: unlink deletes only the link and refuses a real directory, so it never follows the link into its target."

Outra é redação de credencial no ambiente de processos filhos: "Spawned commands get a scrubbed env (drop *KEY*/*SECRET*/*TOKEN*/*PASSWORD*) so harness credentials cannot leak into output, env, or spill files" — mais arquivos temporários em diretório 0700, nomes aleatórios e abertura exclusiva 'wx'/0o600, "predictable world-readable paths invite symlink races and disclosure".

Impacto B para o cap. 14 (é convergência independente de forma de artefato, que é o argumento do capítulo) e C para o 11 e o 07.

packages/acp/README.md, verbatim:

"The ACP group exposes harness agents to programmatic clients over the Agent Client Protocol. It is an interoperability transport, not a presentation or human-interaction layer" · "Automation-only ACP server."

E o cliente correspondente vive em subagent/subagent-acp, "because it implements the subagent provider interface".

O CompozyOS e o Kiro Crew usam ACP como clientes, para dirigir agentes de terceiros. O DeepSeek Harness o expõe como servidor, para ser dirigido — e usa o mesmo protocolo, do outro lado, para falar com subagentes fora do processo. É a primeira evidência primária de ACP nos dois sentidos dentro de um mesmo sistema.

Reforça de novo o cap. 17: em cinco dias, três sistemas novos com ACP em código e zero com A2A. Impacto B.

Ontem registrei como ⏳: "permissões/sandbox ausentes do README". O README continua omisso, e o código não. São 48 pacotes, e a contenção ocupa duas famílias:

• packages/interaction/ — "the human-collaboration plane", verbatim: "These are product packages: real interfaces a person drives." Contém user-approval/ ("Coordinates one-shot approval decisions", ctx.approval), permission-presets/ ("Presents and persists user-facing permission presets", ctx.permissionPresets), user-questions/ e tool-ask-user/.
• packages/sandbox/ — "process-sandbox capability family … applies per-session confinement policy to process execution", com sandbox-local/ (backends de plataforma) e sandbox-policy/ ("Resolves durable per-session sandbox policy").

Correção do meu registro de ontem: escrevi que permissão e sandbox estavam "ausentes" e marquei ⏳. O ⏳ estava certo; a palavra "ausentes" estava errada por uma casa — ausentes do README, não do sistema. Um README magro não é evidência de arquitetura magra, e eu quase deixei essa inferência passar em cima do candidato mais forte da semana.

Ontem registrei, sobre o Kiro Crew: "o que o README não diz é a parte cara: quem promove a lição", e deixei ⏳. O código responde, e responde nos dois sentidos — o que faz, e se tem consciência do risco.

src/kiro_crew/mcp_tools/learn.py, a ferramenta anunciada ao modelo, verbatim:

"Save a learned correction or preference that persists across all future sessions. MUST be called when the user corrects you, says 'always do X', 'never do Y', or 'remember that'."

E o handler, na íntegra do caminho de escrita: valida, monta o payload e faz mcp_core._post("/api/lessons", payload). Não há estado pendente. Não há promoção humana. grep por aprovação de lição no src/ inteiro: zero ocorrências. A lição escrita pelo agente vale no turno seguinte de toda sessão futura.

O único portão é uma capacidade de operador, e o comentário que a acompanha (mcp_core.py:769) é notável porque nomeia a ameaça exatamente como o nosso cap. 16 a nomeia:

"A durable memory/lesson write (learn_add → persisted lesson) is an instruction-injection surface: content written here is re-injected into every future session's context. The capabilities.memory_writes gate (default ON in the catalog) lets a policy/profile forbid it for a surface/app (e.g. a sandboxed app must not be able to plant a durable instruction)."

Isto não é descuido: é a outra aposta, feita com o risco escrito no código. O cap. 16 apresenta a divergência ("quem aplica o aprendizado — o agente sozinho ou o humano que promove?") como questão em aberto e recomenda o portão humano (as duas pastas, pendentes/ e ativas/). O Kiro Crew escolhe autonomia com interruptor de operador: ligado por padrão, desligável por perfil, por superfície ou por app — nunca por lição.

E há um detalhe que só a leitura de código dá. O portão falha aberto: em _vet_memory_writes_governance, PlatformCompositionError propaga, mas qualquer outra exceção cai num except Exception que registra uma auditoria de degradação e retorna None — e None, nessa função, significa permitido. É um compromisso deliberado e documentado ("a late-import failure must not hard-fail the stdio tool call"), com trilha; mas o resultado é que a única barreira da superfície de injeção durável cede em caso de erro inesperado, em vez de fechar.

Impacto B para o 16, e é o melhor tipo de B: não invalida a Leitura executiva, dá ao capítulo o contraditório de campo que ele não tinha. A pergunta 3 da Verificação do cap. 16 pede ao leitor que compare os dois designs; agora existe um dos dois, em produção, num fornecedor grande, com o raciocínio no comentário. C adicional para o 07 (portão que falha aberto).

Anteontem (13/ago) a DeepSeek publicou o deepseek-ai/deepseek-harness. Dados da primária (API do GitHub, lidos hoje):

• MIT, TypeScript, não arquivado, criado 2026-08-13 11:56 UTC;
• 106.515 estrelas / 10.226 forks → 10,4:1 ✓;
• descrição verbatim: "DeepSeek Harness: Everything is a Plugin."; tem CONTRIBUTING.md.

A triagem de repositório do contrato manda desconfiar de enxurrada de estrelas em dias, e aqui ela inocenta. A cobertura falava em 27,5 mil estrelas em 13/ago e 88.975 em 14/ago; hoje a primária mostra 106,5 mil. A velocidade é extraordinária — e o sinal do contrato não é a velocidade, é a razão. O caso ultraworkers/claw-code (06/ago) tinha 1,8:1; este tem 10,4:1, dentro do típico de projeto real. Não é o padrão de inflação.

A tese arquitetural veio da secundária e foi verificada na primária — docs/architecture.md, verbatim:

"Every part of the product is a plugin, including the model adapter, the tool registry, the session log, and the agent loop itself, so every part is replaceable from configuration."

É o extremo do eixo do cap. 12. O capítulo argumenta que extensibilidade é "o conjunto de pontos onde terceiros mudam comportamento sem tocar no código" e adverte que cada ponto de extensão é um compromisso que restringe refatoração futura. Aqui tudo é ponto de extensão — o limite superior do argumento, disponível para leitura.

E cobra do cap. 02, que trata o loop como o núcleo que define o harness: se o loop é substituível por configuração, ele deixa de ser a identidade do sistema e vira uma peça entre outras. Isso é matéria de seção, não nota.

Terceiro ângulo, o mais incômodo: "replaceable from configuration" é, como filosofia de projeto, o mesmo eixo que o Claude Code corrigiu como falha em 13/ago (configuração de projeto trocando o binário do sandbox). Um harness inteiro cuja configuração troca o loop é configuração como execução de código arbitrário por desenho. Apêndice de supply chain.

Impacto B para 12, 02 e o apêndice de supply chain; candidato forte ao corpus pelo teste do cap. 01 §4 — tem loop, ferramentas, contexto e controle, e é o primeiro dos candidatos recentes que não é meta-harness.

⏳ Não verificado: permissões/sandbox (ausentes do README), suporte a MCP/ACP/A2A (ausente do README), e se o CONTRIBUTING.md aceita contribuição de fato (o repositório está com 0 issues abertas, o que costuma indicar issues desativadas — não confirmado).

Changelog, v2.1.233 (14/ago).

(a) Reexpansão de argumento como template, verbatim:

"Fixed skill/command argument substitution to prevent argument values from being re-expanded as template markers"

Um valor de argumento contendo marcadores de template era expandido de novo. É a família de hoje — a política falha na borda da sintaxe do objeto que ela regula — pela sexta vez em duas semanas, e a primeira em montagem de prompt em vez de sistema de arquivos ou linha de comando. Interessa ao cap. 03: o montador de contexto é um interpretador, e todo interpretador tem esse bug.

(b) Quarto bypass de validação de caminho da série, verbatim:

"Fixed Windows paths spelled with the NT \??\ device prefix bypassing UNC path validation, closing an NTLM credential-leak vector"

A série de sintaxe de caminho agora tem quatro instâncias, três sistemas operacionais e dois harnesses: barra final em denyRead: "~/.aws/" (08/ago), symlink no gemini-cli (12/ago), symlink Cygwin no Git Bash (13/ago) e prefixo de dispositivo NT (14/ago). E esta vaza credencial, o que a liga ao cap. 08.

(c) Contenção por recurso, não por permissão, verbatim:

"Added opt-in memory cgroup support for Bash tool commands on Linux (CLAUDE_CODE_TOOL_MEMORY_LIMIT) so a runaway build can't stall the session"

Eixo novo para o cap. 07: o sandbox do livro é sobre o que o agente pode tocar; isto é sobre quanto ele pode consumir. Contenção de recurso não aparece no capítulo.

(d) MCP v2 e o custo do núcleo stateless, verbatim:

"Fixed MCP v2 connections endlessly reopening the subscriptions/listen stream against servers that terminate long-held streams on a fixed timeout (e.g. serverless hosts)"

Primeira evidência primária de campo do que a spec 2026-07-28 custa na prática. C para o cap. 06.

(e) Hook que não dispara em uma superfície, verbatim:

"Fixed Notification hooks not firing for permission prompts when running under Claude Desktop or VS Code"

É a tese do cap. 13 falhando: o núcleo publica evento, a superfície renderiza — e aqui o evento não chegava em duas superfícies. C para 13 e 12.

Impacto B para o 07 e o 03; C para 06, 08, 12 e 13.

Don't Break the Cache segue sem leitura. Hoje testei ar5iv.labs.arxiv.org: bloqueado. Já caíram arxiv.org, huggingface.co, researchgate.net, alphaxiv.org, doi.org e agora o ar5iv. Mantido em avaliando, sem afirmação nova.

agentclientprotocol.com entrou hoje na lista de bloqueados. Não é um domínio qualquer: é a especificação do protocolo que dois harnesses lidos nesta semana usam para dirigir agentes. O cap. 17 descreve o ACP a partir de fontes secundárias e da leitura de implementações; a primária segue inacessível. Registrado como limitação do método, não como achado.

Ontem eu fechei a entrada com isto na fila: "depois de Omnigent e holaOS, procurar uma que nomeie protocolo. Duas sem protocolo é padrão; três é tese."

Apareceram duas, e as duas nomeiam protocolo. O placar da categoria agora é:

Dois a dois. Não há padrão de ausência — há duas escolhas de projeto convivendo, e a leitura que importa é outra: dos que nomeiam um protocolo, nenhum escolheu A2A. Os dois escolheram ACP.

Isso reforça, com evidência nova e de outra origem, a qualificação do cap. 17 registrada em 08/ago e ampliada em 09/ago: a ordem de adoção segue a dor, não o anúncio. O caso de uso "um cliente dirigindo vários agentes inteiros" é, no papel, o território do A2A. Na prática, quem construiu escolheu o protocolo agente↔cliente da Zed, porque é ele que resolve o problema real — e a Leitura executiva do cap. 17 apresenta o A2A como a resposta ao agente-para-agente.

Impacto B para o 17, o 14 e o 10.

kirodotdev/KiroCrew, lido hoje na primária: Python, Apache-2.0, não arquivado, 2,865 mil estrelas / 282 forks (10,2:1 ✓), criado em 2026-07-16. Descrição verbatim: "A persistent workspace for development work that self-improves and continues beyond one session."

Do README, verbatim:

"Kiro Crew drives kiro-cli over the Agent Client Protocol"

"The built-in kirocrew-core, kirocrew-cron and kirocrew-computer MCP servers expose task, subagent, learning, messaging, scheduling, and desktop-automation tools."

"An agent session is a logical isolation boundary, not necessarily one OS process."

"Interactive approvals. Review tool requests in the dashboard or a connected messaging channel" · "On Linux and macOS, kiro-cli can run inside namespace or Seatbelt isolation."

O terceiro eixo do critério de inclusão, em cinco dias. O cap. 01 §6 exige código "aberto e inspecionável". Já testamos duas bordas: o Grok Build (10/ago), aberto mas fechado à contribuição — e o critério decidiu certo; e o holaOS (13/ago), com licença que se diz aberta e proíbe uso comercial. Este é um terceiro: o harness é Apache-2.0 de verdade, e o runtime que ele dirige (kiro-cli) é proprietário.

O que é inspecionável aqui é a orquestração — escalonamento, memória, aprovação, coordenação. O loop do agente, não. Para um estudo cuja fonte-base é o código (Princípio II), isso significa que metade do objeto some no meio da leitura, e some exatamente na metade que o cap. 02 descreve.

Nenhuma das três bordas quebra o critério. As três juntas dizem que a palavra "aberto" no §5 está carregando três perguntas diferentes — aberto a contribuir, aberto a usar, aberto a ler até o fim. Impacto B para 01 §5/§6.

Ainda do README do Kiro Crew, verbatim:

"Corrections and task failures become durable lessons. Preferences and project context carry into new sessions" · "Repeated patterns become reusable skills."

É a cena de abertura do nosso cap. 16 descrita como funcionalidade de produto — o agente que não tem onde guardar a correção da semana passada, e o laço que se fecha quando ele escreve a própria regra. E os servidores MCP embutidos expõem learning como ferramenta, ao lado de task e subagent.

O que o README não diz é o que o capítulo argumenta ser a parte cara: quem promove a lição. Há aprovação interativa para tool requests; não há, no README, nada sobre revisão humana da lição antes de ela entrar no contexto de todos os turnos futuros. Se a promoção for automática, é o vetor de prompt injection persistida que o capítulo descreve; se não for, o README omite o freio.

Impacto B para o 16 — não invalida a Leitura executiva, mas o capítulo passa a ter um caso de campo, e a pergunta do freio vira leitura de código na próxima rodada. ⏳ Não verificado: se a promoção de lição exige humano.

Changelog, v2.1.232 (13/ago). O release mais denso de permissão/sandbox da série, e três itens são de classes que o livro não cobre.

(a) A configuração do projeto trocava o binário do próprio sandbox, verbatim:

"Changed sandbox.ripgrep to be honored only from user, managed, and --settings settings; project settings can no longer override the sandbox's ripgrep binary"

Um repositório clonado podia apontar o sandbox para outro executável. É configuração como execução de código, mesma família do plugin marketplace command source de 12/ago, e material direto do apêndice de supply chain: a fronteira de confiança não é só "de onde vem o plugin", é de onde vem a configuração.

(b) Confiança herdada por aninhamento, verbatim:

"Fixed nested git repositories inheriting trust from a parent directory; each repository now requires its own trust confirmation"

Um repositório dentro de um repositório confiável era confiável. O gesto de confiar tinha alcance maior que o objeto confiado.

(c) O quinto caso da série "a política falha na borda da sintaxe do objeto que ela regula", verbatim:

"Fixed a PowerShell permission bypass where variable-writing parameters could silently overwrite $PSDefaultParameterValues and redirect later commands' file access"

E é o caso mais fino de todos. Nos quatro anteriores o problema estava no comando avaliado — a barra final do caminho, o symlink, a bandeira --force. Aqui o comando avaliado é inofensivo e reescreve o padrão dos comandos seguintes. A política olha uma chamada por vez; o ataque age entre elas.

Some-se (d) "Fixed a Windows permission bypass where Git Bash followed Cygwin-style symlinks that path validation saw as regular files" — symlink de novo, terceiro sistema — e (e) "Hardened the Linux filesystem sandbox against a protected-path bypass".

Mais a redação de segredo: nove famílias de token do GitLab (glrt-, gloas-, glptt-, glagent-, glimt-, glsoat-, glcbt-, glft-, glffct-) e redação total dos roteáveis glpat-/gldt-, com o glab ganhando "the same sandbox and credential-path protection as gh".

Impacto B para o 07 e para o apêndice de supply chain; C para o 08 (credencial).

Mesmo release, verbatim:

"Subagent forking is now on by default: a subagent_type: "fork" subagent inherits the full conversation and prompt cache"

Ontem o cache decidia quando um subagente começa (escalonamento de fan-out). Hoje ele decide como o subagente nasce: bifurcar em vez de partir do zero, para herdar o prefixo já pago.

É o terceiro dia consecutivo de evidência primária de que a economia de cache virou força de projeto — e o cap. 10 segue sem mencionar cache uma única vez. A qualificação registrada ontem fica mais forte, não igual: já não é um item de escalonamento, é o modelo de criação de subagente.

Impacto B, tendendo a A para o 10.

Releases, nightlies de 13 e 14/ago:

• "fix(core): rollback entire multi-turn request on cancellation or abort" — cancelamento deixando estado parcial no meio de uma requisição multi-turno. C para o cap. 02, e conversa com o modo de falha de compactação repetida do cap. 04: as duas são operações interrompidas no meio.
• "Evaluation framework enhancements with tool call formatting" e "failure summary integration for evals" — um harness do corpus construindo arnês de eval próprio. C para o 11, e vale observação: é a dimensão mais fraca do corpus inteiro, e este é movimento nela.

Encerro aqui a contagem do "encerrado em 18/jun", que chegou a cinco dias consecutivos de refutação primária. O ponto está feito e virou ruído; volta se houver alegação nova.

A busca por papers devolveu quatro identificadores que não estão no nosso repositório (grep conferido): 2604.21003 The Last Harness You'll Ever Build · 2605.26112 From Model Scaling to System Scaling · 2602.07962 LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth · 2606.20631 Harnessing Agent Skills.

Entram como ⏳ com título e identificador, nada mais — arxiv.org está bloqueado há oito dias e as duas rotas alternativas que eu tinha na fila (researchgate, alphaxiv) também caíram hoje. C, para leitura dirigida na rodada 2026-10.

O LOCA-bench merece nota por endereçar a dimensão do cap. 03/04 com bancada controlada, e o 2604.21003 pelo título ser uma tese forte sobre o cap. 16. Nenhuma dessas leituras é minha ainda — é o que o título sugere, e título não é fonte.

Don't Break the Cache segue sem leitura. Hoje caíram arxiv.org, researchgate.net e alphaxiv.org — as três. Item mantido em avaliando, sem nenhuma afirmação nova. É o fundamento científico que falta ao eixo dos achados 5 e (ontem) 2, e a lacuna já tem três dias de evidência primária empilhada em cima.

O HolaOS estava na fila desde ontem, sem primária. Lido hoje — holaboss-ai/holaOS:

• TypeScript, não arquivado, 6,1 mil estrelas / 520 forks (11,7:1 ✓, acima do 10:1 típico);
• descrição verbatim: "Open-source All in One AI agent workspace. Run any agent — Claude Code, Codex — across your tools (100+ integrations + MCP), apps, browser, and files, with shared memory. Built-in models or BYOK.";
• memória "stored locally, as plain files you can read and edit";
• nenhum protocolo nomeado para dirigir os agentes externos, e nada sobre permissão, sandbox ou política no README além do endereço de segurança.

A licença é onde o item deixa de ser "mais um candidato". O repositório se declara open-source na primeira palavra da descrição, e a busca que me trouxe até ele afirmava MIT. O arquivo LICENSE é Apache 2.0 modificada, com duas restrições que a Apache 2.0 não tem, verbatim:

"you may not use the holaOS source code to provide a hosted service to third parties, or embed holaOS as a component of a product or service that is sold"

"you may not remove or modify the LOGO or copyright information in the holaOS console or applications"

Uma restrição de campo de uso e um travamento de marca. Isso é código-fonte disponível, não código aberto no sentido da OSI — e a licença ainda reserva ao produtor o direito de "adjust the open-source agreement to be more strict or relaxed as deemed necessary".

E aqui o achado vira uma pergunta sobre o livro, não sobre o HolaOS. O critério do cap. 01 §6 foi esclarecido em 10/ago pelo caso Grok Build: exige-se código "aberto e inspecionável na data de corte, não código aberto à contribuição". Pelo critério operacional, o HolaOS entra: a fonte está pública e legível, que é o que o estudo precisa. Mas o §5 abre dizendo "O corpus é de código aberto" — e um leitor que encontre o HolaOS nessa lista vai entender a frase num sentido que a licença não sustenta.

O caso Grok Build resolveu um eixo (aberto à contribuição). Este é outro: aberto ao uso. O critério decide, de novo, sem emenda — mas a palavra no §5 precisa da qualificação, ou o livro afirma sobre o corpus algo que uma das fichas contradiz.

Impacto B para 01 §5/§6 e para o apêndice de supply chain (licença como cláusula de dependência, não só como rótulo). C para 14 — é a segunda amostra da categoria meta-harness, depois do Omnigent de ontem, e a segunda sem protocolo nomeado.

⏳ Data de criação e de lançamento não verificadas: a página não exibiu data de criação no fetch, e nenhuma release foi lida. Não afirmamos quando.

Proposta de contrato (não aplicada). As duas armadilhas nomeadas no AGENTE.md são inflação (o sistema é menos do que dizem) e obituário precoce (é mais do que dizem). Este caso é um terceiro tipo: a autodeclaração de licença, que é o campo mais fácil de checar e o de maior consequência para o teste de inclusão — e que hoje uma secundária errou de forma limpa ("MIT") sobre um repositório que se anuncia "open-source" com restrição de campo de uso. Registro a proposta e não edito o AGENTE.md: mudar o contrato do agente é decisão do editor, pela mesma razão que o cap. 16 dá — quem aprende escreve a lição, quem promove é humano.

Não é um achado, é uma convergência — e ela aparece em duas camadas diferentes no mesmo dia.

Na montagem da requisição. goose v1.46.0 (12/ago), verbatim:

"Cache-safe request assembly with append-only turn context and declared cache semantics" (#11022)

Leia o que a frase compromete: a lista de mensagens deixou de ser estrutura livre e passou a ser append-only por contrato, com a semântica de cache declarada. O harness não está otimizando o cache; está abrindo mão de reescrever o histórico para não invalidá-lo.

No escalonamento da orquestração. Claude Code v2.1.229 (12/ago), verbatim:

"Improved workflow fan-outs to stagger same-prefix sibling agents so subsequent agents read the cached prompt prefix instead of re-paying it (CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS=0 disables)"

Aqui a economia de cache decide quando um subagente começa. Fan-out deixou de ser "dispare todos em paralelo" e virou escalonamento com atraso deliberado, para que o irmão seguinte leia o prefixo que o primeiro pagou.

Na spec do protocolo, o livro já registra: a MCP 2026-07-28 acrescentou ttlMs e cacheScope às respostas de tools/list (cap. 04, seção do estado da arte).

Três camadas, mesma força. E as duas Leituras executivas afetadas não têm esse eixo:

• Cap. 04 trata cache como restrição da compactação ("compactar invalida o prefixo cacheado") e coloca como grande questão aberta a migração da compactação para o provedor. O goose vai na direção oposta: em vez de terceirizar, endurece a própria montagem em torno do contrato de cache. É qualificação da ressalva de 06/ago, não refutação. Impacto B.
• Cap. 10 lista o que importa em orquestração — isolamento de contexto, escolha de coordenação, guardrails, A2A, worktree — e não menciona cache uma única vez (grep conferido hoje: zero ocorrências no capítulo). O custo do fan-out aparece como contexto e como computação; não como prefixo de cache. Isso é eixo faltando, não nota de rodapé. Impacto B, tendendo a A se a próxima rodada achar o mesmo padrão em outro harness.

Mesmo release do Claude Code, verbatim:

"Changed /commit-push-pr so git/gh commands with dangerous flags (--force, --amend, --no-verify, etc.) are no longer auto-approved"

git estava na lista do que roda sem confirmar. O que carrega o risco não é o comando — é a bandeira. Uma allowlist por nome de executável não vê a diferença entre git push e git push --force.

É o quarto caso datado da mesma família em duas semanas, em três harnesses distintos: a barra final em denyRead: "~/.aws/" (08/ago), a fuga por symlink no gemini-cli (12/ago), o isolamento de plugin fail-closed no Codex (09/ago) e agora a bandeira dentro do comando permitido. O padrão já tem nome no Radar — a política falha na borda da sintaxe do objeto que ela regula, não na lógica — e agora tem quatro instâncias e três fornecedores. Impacto B para o cap. 07: material de seção com quatro exemplos, não observação.

Mesmo release, dois itens que o apêndice de supply chain não cobre:

"Added plugin marketplace command sources: a local command (e.g. an IDE) prints the plugin directory, which is re-resolved each session and applied without a restart; mode: "link" uses it in place"

"Added server-supplied Claude Code hook support for self-hosted runner sessions, matching managed-environment behavior"

O primeiro é uma fonte de plugin que não é um endereço, é um comando — e ela é reavaliada a cada sessão, sem reinício. O segundo é hook fornecido pelo servidor, isto é, código de extensão com poder de decisão (cap. 12: o retorno do hook é o canal de controle) chegando pela rede, na sessão de um runner próprio.

Somados ao endurecimento das skills sincronizadas de ontem (v2.1.228), são três superfícies de extensão remota em dois dias no mesmo harness. O apêndice trata registro e dependência; a categoria que falta é procedência de extensão que muda entre sessões. Impacto B para o apêndice de supply chain e para o cap. 12.

Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks (arXiv 2601.06007, jan/2026). grep no repositório: não está na nossa bibliografia.

Não foi lido. arxiv.org (sétimo dia) e huggingface.co bloqueados; a busca oferece researchgate como alternativa, não tentada por orçamento. Duas secundárias independentes concordam no título, no identificador e no ano; nada além disso é afirmado aqui — nem autores, nem números, nem método.

Fica em avaliando, e é a prioridade da fila: seria o fundamento científico do achado 2, num capítulo (04) cujos fundamentos hoje não incluem cache.

• goose v1.46.0 (12/ago) — além do item de cache: "Unrolled agent loop" (#9574) e "Streaming shell output while commands run" (#10808), mais 23 provedores novos. O loop desenrolado é cap. 02 (C, até saber o que "unrolled" significa no código — é leitura de rodada, não de radar); a saída de shell em streaming é cap. 13 (C). E fecha a observação aberta em 12/ago: a cadência do goose sob a AAIF não parou — foram 14 dias, não um abandono.
• opencode v1.18.18 (13/ago) e v1.18.17 (12/ago) — releases; ajustes de system prompt do Kimi e de reasoning effort. C para o cap. 05 (a mesma tese de contrato de ferramenta por família de modelo, do lado do prompt).
• Claude Code v2.1.231 (13/ago) — "Fixed MCP OAuth sign-in failing with a redirect URI mismatch for servers that use a pre-registered OAuth client, such as Slack". C, cap. 06.
• block/goose → aaif-goose/goose — confirmado de novo hoje nos dois fetches, Apache-2.0, não arquivado, 52,7k★/6,0k forks (8,8:1). Já registrado em 11/ago; o item não muda de status, só ganha confirmação independente.

O Omnigent não é novo aqui: entrou em 06/ago como candidato C, a partir de cobertura de julho, e está no benchmark/README.md na linha de Watchlist, escrito assim: "Omnigent (Databricks)".

Hoje foi lido na primária pela primeira vez — omnigent-ai/omnigent:

• Apache-2.0, Python, não arquivado, 8,7 mil estrelas / 1,3 mil forks (6,7:1 — acima do piso de ~5:1, abaixo do 10:1 típico);
• descrição verbatim: "Omnigent is an open-source AI agent framework and meta-harness: orchestrate Claude Code, Codex, Cursor, Pi, and custom agents — swap harnesses without rewriting, enforce policies and sandboxing, and collaborate in real time from any device.";
• o README lista como orquestrados Claude Code, Codex, Cursor, OpenCode, Hermes, Pi e agentes próprios definidos em YAML — cinco dos seis são membros do nosso corpus;
• políticas que "check every action and either allow it, block it, or pause to ask you first"; contenção por process-tree com Windows Job Objects e isolamento de arquivo/rede por bwrap/seatbelt;
• nenhum protocolo nomeado no README para falar com os agentes orquestrados — nem ACP, nem A2A. MCP aparece só como fonte de ferramentas dentro de cada agente.

Correção de atribuição, e desta vez o erro é nosso. A primária não menciona Databricks em lugar nenhum: o dono é a organização omnigent-ai. A palavra entrou no nosso benchmark/README.md vinda de terceiros. Não posso editar o arquivo (escrita só em radar/), então fica registrado como item B: a watchlist do benchmark afirma um dono que a primária não sustenta.

Por que o achado é maior que um candidato a mais. Três coisas que o livro hoje não trata:

• Duas camadas de política empilhadas. O Claude Code já tem portão de permissão; o Omnigent põe outro acima dele. Quem decide quando as duas discordam? O cap. 07 discute o portão do harness, não o portão sobre o harness.
• Orquestração entre harnesses, não entre subagentes. O cap. 10 trata o eixo vertical (mãe → subagentes) e ganhou o lateral em 08/ago (sessões pares). Isto é um terceiro eixo: acima.
• Evidência contra o caminho do protocolo. Este é o caso de uso do ACP em estado puro — um cliente falando com vários agentes — e a implementação não usa protocolo nenhum, usa adaptador por agente. Reforça, com sinal invertido, a tese registrada em 09/ago: a ordem de adoção segue a dor, não o anúncio. Aqui a dor foi resolvida sem esperar o padrão.

Impacto B para 14, 10, 07, 17 e para o teste de inclusão do 01 §4 (um meta-harness é um harness? o critério não responde). Não invalida Leitura executiva.

⏳ A data de lançamento não foi verificada: a busca fala em 08/ago, a cobertura que nos trouxe o item é de 06/jul, e a página do repositório não exibiu data de criação no fetch. Não afirmamos quando.

Changelog do Claude Code, v2.1.228 (11/ago), verbatim:

"Hardened skills synced from claude.ai: they no longer shadow local commands or MCP prompts, their descriptions are sanitized and labeled, and on your machine their bodies don't run ! commands or expand @ files"

Leia a frase pelo que ela implica sobre o estado anterior. Conteúdo de extensão que chega pela rede podia, na máquina do usuário: (a) sombrear comandos locais e prompts de MCP, isto é, sequestrar um nome que o usuário já usava; (b) executar comandos de shell através da sintaxe !; (c) expandir arquivos por @, arrastando conteúdo local para dentro do contexto.

É o modelo de ameaça do apêndice de supply chain descrito por uma correção datada e de primeira mão, no harness mais maduro do corpus. Sombreamento de nome é o vetor menos discutido dos três: não precisa de execução, basta o usuário digitar o comando de sempre.

Impacto B, tendendo a A para o apêndice de supply chain (que hoje trata risco de dependência e de registro, não de conteúdo de extensão sincronizado), mais cap. 12 e cap. 07. Placar de permissão/sandbox segue crescendo: com isto e o item 4, são treze correções da área em cinco semanas no corpus.

Mesmo release, verbatim:

"Changed the Write tool so newer models can overwrite an existing file they haven't read this session, matching the Edit tool's rules; older models still require the read first"

O cap. 05 já sustenta que a interface de edição é treinada, não inventada e que a seleção de ferramentas varia por família de modelo. Isto é um degrau adiante e mais fino: não varia qual ferramenta o modelo recebe, varia a pré-condição de segurança da mesma ferramenta. A regra "leia antes de sobrescrever" existia para conter modelo que apaga o que não leu; ela agora é condicional à confiança na família.

Impacto B para o cap. 05 — é a evidência primária mais limpa até hoje de contrato de ferramenta com comportamento dependente do modelo do outro lado.

Do mesmo release, dois menores: "Fixed session cleanup deleting contents inside a project's memory folder" (C, cap. 08 — faxina de sessão apagando memória de projeto é falha de fronteira entre efêmero e durável) e "Improved compaction progress: the retry countdown and stall hint now appear during compaction" (C, cap. 04 — compactação como evento observável, que o capítulo já defende).

Releases, lidos hoje: v0.55.1 (11/ago, estável), v0.56.0-preview.1 (11/ago), v0.55.0-preview.3 (11/ago) e nightlies em 10, 11 e 12/ago. Repositório não arquivado. Entre as correções da v0.55.1: "symbolic link directory escapes" e renovação de token OAuth.

Duas leituras:

• Cap. 07: fuga de diretório por link simbólico é o mesmo padrão da barra final em denyRead: "~/.aws/" (08/ago) — a regra de caminho parece cobrir e não cobre. Dois harnesses distintos, duas semanas, o mesmo modo de falha: a política de sistema de arquivos falha na borda da sintaxe do caminho, não na lógica. Isso é material de seção, não de nota. Impacto B.
• Apêndice A: quinto dia consecutivo de refutação primária do "encerrado em 18/jun", e a mais forte da série — desta vez não é nightly, é release estável com correção de segurança. Impacto C.

Ontem registrei o item como "Martin Fowler publicou 'Harness engineering for coding agent users'". Hoje, tentando de novo a primária (bloqueada pela segunda vez), encontrei uma cópia de terceiro em repositório público que atribui o texto a Birgitta Böckeler (Thoughtworks), datado de 17/fev/2026, na série exploring gen ai em martinfowler.com/articles/exploring-gen-ai/harness-engineering.html — com a linha de licença "Copyright Martin Fowler (all rights reserved; article content)", que é o padrão do site para textos de outros autores hospedados lá.

São duas secundárias em conflito (a busca de ontem dizia Fowler, abril; esta diz Böckeler, fevereiro, com URL diferente), e nenhuma primária lida. O ⏳ permanece e a redação de ontem estava confiante demais: martinfowler.com é o site — o autor de um artigo lá não é automaticamente o dono do domínio. Corrigido na linha do RADAR.md.

Vale o registro de método: duas correções de atribuição na mesma execução, uma na nossa watchlist (item 1) e uma numa frase minha de ontem. O erro não é do agregador desta vez; é de quem lê rápido.

O paper por trás do "98,4% do Claude Code não é IA" segue sem leitura primária: arxiv.org/abs e /html, export.arxiv.org, huggingface.co/papers, semanticscholar.org e agora web.archive.org — todos bloqueados. Item mantido em avaliando, sem nenhuma afirmação nova.

Fui conferir a hipótese de dormência levantada em 09/ago e encontrei outra coisa. Dois fetches independentes — a lista de releases e a página do repositório — resolvem hoje para aaif-goose/goose, e não para block/goose. Não há aviso de movimentação na página; o redirecionamento é silencioso.

A página, lida hoje: Apache-2.0, não arquivado, 52,7 mil estrelas / 6,0 mil forks (8,8:1 ✓), descrição inalterada ("an open source, extensible AI agent that goes beyond code suggestions…").

Por que isto importa mais do que uma troca de URL. O Radar registrou em 06/ago que o goose virou âncora de fundação na AAIF (Linux Foundation). Aquilo era um anúncio. Isto é o namespace do repositório: a governança saiu do papel e chegou ao endereço. É a diferença entre declarar e executar — a mesma distinção que a edição 0.79 do livro pagou caro para aprender.

O que o livro registra hoje: block/goose em três arquivos — livro/apendice-estudo.md, livro/en/appendix-study.md e benchmark/avaliacoes/goose.md. Os links continuam funcionando pelo redirecionamento, e é justamente por isso que o erro é durável: nada quebra, e o livro apenas nomeia o dono errado.

Impacto B — Apêndice A / apêndice do estudo / ficha do benchmark. Não toca nenhuma Leitura executiva.

A busca trouxe manchetes de que o "Microsoft Agent Framework Harness" teria sido lançado / atingido GA em agosto de 2026. O devblogs.microsoft.com está bloqueado, então fui às duas primárias que passam: o repositório e as releases.

O que a primária diz, verbatim (releases do microsoft/agent-framework):

• dotnet-1.14.0 (21/jul): "[BREAKING] Graduate HarnessAgent" · ".NET: Graduate ToolApprovalAgent"
• python-1.12.0 (21/jul): "Integrate message injection into create_harness_agent" · "Add Agent Harness blog post accompanying samples"
• python-1.11.0 (10/jul): "Integrate message injection into create_harness_agent and the harness console sample"

E o repositório: MIT, Python, não arquivado, 12,7 mil estrelas / 2,1 mil forks (6,0:1 — acima do piso de ~5:1, abaixo do 10:1 típico).

O achado é a terminologia, não o produto. HarnessAgent e create_harness_agent são nomes de tipo e de fábrica na API pública de um framework de fornecedor grande. Até aqui o livro documentava "harness" como termo de praticante, de survey acadêmico e de diretório (quatro definições convergentes, 08/ago). Agora ele é identificador de código que compila. Isso é adoção de vocabulário de outra ordem: um nome em README se troca; um tipo público exportado, não — e a nota que o promove diz [BREAKING].

Impacto B para cap. 01 §4/§6 (o campo tem nome) e cap. 14 (convergência). Não invalida Leitura executiva.

Anexo de A2A, da mesma lista: existe o pacote python-hosting-a2a-1.0.0a260723 (23/jul). Não é uso no corpus, mas é a primeira evidência primária, nesta série do Radar, de código A2A publicado como artefato versionado por um dos grandes. Fica como C para a matriz da rodada 2026-10.

Changelog, lido hoje:

• v2.1.227 (10/ago): "Fixed every Bash command failing under claude-code-action with allowed_non_write_users on GitHub-hosted runners"; o resto é menu de comandos, /tui e desempenho.
• v2.1.226 (08/ago): "Bug fixes and reliability improvements" — sem detalhe.

Impacto C, cap. 07. Vale só como continuidade do placar: a política de permissão que falha fechada demais (tudo quebrando) é o espelho das falhas que abriam demais, registradas em 07 e 08/ago. As duas contam para a mesma tese do capítulo — configuração de permissão é onde os harnesses mais erram.

Releases, 10/ago, verbatim: "Ignore unknown top-level config fields instead of failing config parsing" e "Register projects opened from Home so they are available to the rest of the app".

Impacto C, cap. 12 (extensibilidade). Pequeno, mas é uma decisão de projeto nomeável: configuração de harness passa a degradar em vez de recusar, o que é a escolha certa quando o mesmo arquivo precisa atravessar versões diferentes do binário.

A busca devolveu, em vários lugares, a afirmação de que apenas ~1,6% da base de código do Claude Code seria lógica de decisão de IA, sendo os 98,4% restantes infraestrutura determinística (portões de permissão, pipelines de contexto, camadas de compactação, recuperação, roteamento de ferramenta), com a frase de efeito de que o agente é "um while (true) com uma chamada de modelo dentro". A primária alegada é o arXiv 2604.14228, "Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems" (abr/2026).

Não entra. Tentei quatro rotas de leitura primária e todas foram bloqueadas pelo egresso: arxiv.org/html, export.arxiv.org, huggingface.co/papers e semanticscholar.org. O que li foram resumos de terceiros — e o contrato é explícito: agregador encontra, primária afirma.

Alerta de método, e este é o ponto mais importante da execução. Esta é exatamente a alegação que a §Regras duras manda tratar com mais rigor, não com menos: ela confirma a tese central do livro com um número redondo e citável. Se eu a registrasse como achado, estaria fazendo o que acusei o agregador de fazer em 09/ago. Foi assim que o obituário do gemini-cli quase passou em 07/ago.

Registro também um dado de contexto: grep no repositório do livro não encontra nenhuma menção a 2604.14228, ao título do paper, a "98,4" ou a MBZUAI. Se a primária se confirmar, é material de 1ª ordem para o cap. 01 e para a bibliografia — e potencialmente A, porque um número medido substituiria um argumento retórico na abertura do livro.

Falta: ler o abstract e a metodologia na primária (arXiv 2604.14228), com a lista de autores e a afiliação. Sem isso, nem o número nem a existência do paper são afirmáveis por nós.

A busca retornou martinfowler.com/articles/harness-engineering.html com esse título. O domínio foi bloqueado pelo egresso nesta execução, então título, autoria, data e conteúdo não foram lidos na primária.

Fica registrado pelo que seria: a nomeação da disciplina por uma das vozes de referência da engenharia de software, no site próprio dela — que é primária por definição. Se confirmado, entra em cap. 01 §6 e na bibliografia, e é um dos itens mais fortes já vistos por este Radar para o argumento de que o campo existe e tem nome.

Falta: um fetch do artigo quando o domínio liberar.

Os dois primeiros da fila de ontem eram Kimi Code e Grok Build. O segundo rendeu o achado do dia.

Fonte primária, CONTRIBUTING.md reproduzido na íntegra nesta execução:

"This repository does not accept external pull requests or unsolicited patches.

SpaceXAI develops this software internally. The public tree is published for source transparency and local builds under the terms of the Apache License, Version 2.0."

"No contributor license agreement is offered because external contributions are not accepted."

E a página do repositório, lida hoje: Apache-2.0, Rust, não arquivado, 24,6 mil estrelas / 4,7 mil forks (5,2:1 — logo acima do piso de ~5:1 do contrato, e bem abaixo do 10:1 que ele chama de típico), e 25 commits no histórico visível. A descrição corrente já diz "SpaceXAI's terminal-based AI coding agent" — a empresa mudou de nome, e o Apêndice A ainda registra "xAI".

Por que isso não é o que o crítico diz que é. Circula a etiqueta "open source washing" (bex.co). Não é preciso adotá-la, e é melhor não: o projeto se descreve sozinho, sem eufemismo — "publicado para transparência de fonte e builds locais". Essa é a frase que vale citar, porque é autodescrição verificada, não acusação de terceiro.

E o mais interessante: isto não ameaça a inclusão do Grok Build no corpus — confirma o critério do livro. O cap. 01 §6 exige "código aberto e inspecionável na data de corte", e o Princípio II diz que a fonte-base é o código. O livro lê código; não conta contribuidores. O Grok Build satisfaz o critério exatamente e de propósito. O que o caso acrescenta é uma distinção que o Apêndice A hoje não faz: entre projeto inspecionável e projeto participável. Os 25 commits para uma base grande dizem a mesma coisa por outro lado — publicou-se o código, não a história dele: dá para ler o que é, não como chegou lá.

Impacto B para o Apêndice A (atributo novo por membro: aceita contribuição externa? o histórico é público?), para o cap. 14 (um padrão a mais na cadeia de posturas de abertura, ao lado de "modelo aberto/harness fechado") e para o apêndice de cadeia de suprimentos (você pode ler e bifurcar, não pode influenciar a montante — o risco de fornecedor não some com a licença permissiva). C para o cap. 01 §6, como nota de que o critério escolhido resiste ao caso.

Fonte primária: releases do Kimi Code, @moonshot-ai/kimi-code@0.34.0 (06/ago) — único release da janela; repo com 6,3 mil estrelas / 990 forks (6,4:1 ✓).

Duas linhas valem capítulo:

MCP removido no meio da sessão não desaparece — passa a falhar com aviso. Retirar um servidor MCP da configuração do workspace mantém as ferramentas registradas na sessão ativa e marca as chamadas como falhas com nota de remoção; servidor adicionado no meio só vale em sessão nova ou após /new//reload. É uma decisão de projeto sobre mutabilidade do registro de ferramentas em tempo de execução, e a escolha é a conservadora: o inventário que o modelo foi informado que tem não encolhe em silêncio. Um modelo que recebeu a definição de uma ferramenta e depois a vê sumir sem explicação alucina a chamada; aqui ele recebe uma falha nomeada. Caps. 05 e 06.

Tarefa de subagente passa a exibir o modelo e o nível de raciocínio que usa. É observabilidade onde o benchmark não olha: a dimensão 10 mede se há subagentes e como se isolam, não se dá para saber em que modelo o trabalho delegado rodou. Num harness que escolhe modelo por tarefa, isso é ao mesmo tempo questão de custo e de qualidade — e de auditoria, que é assunto do cap. 11.

Impacto B para os caps. 05/06; C para 10/11, com um candidato a subcritério na rodada 2026-10.

Releases lidos hoje: v0.56.0-nightly.20260810, .20260809, .20260808, mais v0.55.0-preview.2 e v0.54.4 (ambos de 07/ago).

Terceiro dia consecutivo de refutação primária da alegação de que o projeto teria sido encerrado em 18/jun — e a mais forte das três, porque não é contagem de commits nem ausência de banner: é artefato publicado com a data de hoje. Um projeto morto não faz nightly.

C para o Apêndice A; o valor aqui é metodológico e já está no descarte de 07–08/ago.

⏳ Não registrado por falta de corroboração: o resumo da página de releases atribuiu ao nightly de 08/ago um "caretaker triage evaluation framework and judge runner" — que seria material forte para os caps. 16 e 11 (o projeto usando agentes para manter a si mesmo, agora com juiz avaliando esses agentes). Fui ao verbatim de v0.55.0-preview.2 e não corrobora: as notas são um cherry-pick, sem nada de caretaker. Como em 08/ago, o resumo do fetch não é a fonte. Falta: ler as notas do nightly ou a documentação de caretakers no repositório. Fica na fila.

Ontem registrei "ACP em adoção silenciosa" como achado de impacto B, com o argumento de que a leitura do cap. 17 não fazia a distinção de camadas. Fui ler o capítulo hoje. Faz — e com mais precisão do que eu.

O cap. 17 (linha 36) já traz: "Duas confusões a desfazer: (1) 'ACP' designa dois protocolos distintos — o da IBM (comunicação agente-agente, descontinuado em favor do A2A) e o da Zed (agente-editor, vivo e em expansão); neste livro, ACP = Zed." Tem tabela separando os dois, com o da IBM marcado "encerrado — fundido ao A2A (ago/2025)", e até um exercício pedindo ao leitor que explique a diferença.

E a linha 65 diz, desde a rodada frameworks-1: "ACP é o protocolo silencioso mais importante da coorte: 6 de 11 o falam, e três harnesses (OpenClaw, OpenHands, Goose) o usam para orquestrar outros harnesses como subagentes". Eu escrevi "adoção silenciosa" achando que era observação minha. O capítulo usa a mesma palavra, e vai além: ACP como barramento de composição entre harnesses, não só editor↔agente.

Confirmei os dois protocolos na primária, e a confirmação bate com o livro: i-am-bee/acp (IBM/BeeAI) está arquivado desde 27/ago/2025, somente-leitura, com o aviso "ACP is now part of A2A under the Linux Foundation!"; zed-industries/agent-client-protocol segue Apache-2.0 e não arquivado.

O que resta de válido do item de ontem, e só isso: as datas frescas — código ACP em opencode v1.18.14 (05/ago) e goose v1.45.0 (29/jul) — servem como refresh da matriz de adoção do cap. 17 na rodada 2026-10. Isso é C, não B. O item de 09/ago fica rebaixado no RADAR.md, com o motivo escrito.

O achado de MCP do mesmo dia permanece B: o cap. 17 tem colunas de MCP client/server na matriz, mas a matriz não versiona a spec — e agora a versão importa, porque existe uma spec nova de 28/jul com implementação real no Codex 0.147.0.

A mais recente segue sendo a v2.1.226 (08/ago), cujo conteúdo integral é "Bug fixes and reliability improvements". Registrado como eixo vazio — dois dias sem release depois de uma semana com sete.

Este é o achado do dia, e ele só aparece quando se lê release em vez de notícia — nenhuma das três frentes virou manchete.

MCP — o corpus começa a implementar a spec nova. O Codex rust-v0.147.0 (07/ago), literal: "Support the opt-in MCP 2026-07-28 protocol, including paginated discovery, multi-round requests, and non-blocking server startup", com "Upgrade the MCP SDK to 3.0.0". A spec 2026-07-28 entrou no Radar em 01/ago com a ação sugerida "dados de adoção para a matriz (rodada 2026-10)" — este é o primeiro membro do corpus que se pode registrar implementando-a, e implementando por opt-in, o que já diz algo sobre a confiança na transição.

ACP — adoção silenciosa, dentro dos harnesses. Dois membros do corpus mexeram em código ACP em onze dias, e nenhum dos dois anunciou:

• opencode v1.18.14 (05/ago): "Waited for queued ACP session updates before ending a turn"
• goose v1.45.0 (29/jul): "Gate tool-call label enrichment on ACP client capability"

Primária do protocolo, lida hoje: zed-industries/agent-client-protocol — Apache-2.0, 3,9 mil estrelas / 336 forks (11,6:1 ✓), não arquivado, descrição corrente "A protocol for connecting any editor to any agent", e o README declarando que ele "standardizes communication between code editors … and coding agents", com bibliotecas oficiais em Kotlin, Java, Python, Rust e TypeScript. ⏳ a contagem de adotantes não foi verificada: zed.dev e agentclientprotocol.com estão bloqueados, e os números que circulam (25+ agentes, JetBrains desde dez/2025, registro público em jan/2026) vieram de agregador. O que está verificado é melhor que uma contagem: código ACP em duas notas de release de membros do corpus.

A2A — 150+ organizações no papel e, no corpus, um fornecedor preferindo canal próprio. É o achado de ontem visto de outro ângulo: o Claude Code, na mesma janela, construiu mensageria entre sessões (SendMessage/ListAgents, v2.1.224) em vez de adotar protocolo.

A leitura que isto habilita, e que o cap. 17 hoje não faz: três protocolos, três camadas, três velocidades. MCP (agente↔ferramenta) tem spec nova e implementação começando. ACP (editor↔agente) tem adoção silenciosa — entra por dentro, sem anúncio, porque resolve um problema que o usuário sente (usar o agente no editor que já tem). A2A (agente↔agente) tem o maior número de organizações declaradas e a menor evidência de uso no corpus, e o fornecedor mais maduro preferiu canal proprietário. A ordem de adoção não segue a ordem de anúncio — segue a de dor.

Impacto B para os caps. 17 e 06, e dado direto para a matriz de adoção da rodada 2026-10.

Fonte primária: notas literais da tag rust-v0.147.0, publicada em 07/ago. Quatro linhas interessam ao cap. 07, e uma delas ao cap. 08:

• "Enable automatically reviewed approvals with the new --approve-for-me CLI flag." — o portão de aprovação, que o cap. 07 apresenta como o ponto em que o humano entra no laço, passa a poder ser operado por um revisor automático. Não é o --full-auto de antes (ver abaixo): é uma revisão, feita por máquina, no lugar da humana. Casa com o que o Claude Code fez na v2.1.225 ("the model is now told to move on rather than retry" depois de uma recusa do filtro de segurança sobre a própria checagem de permissão): dois harnesses, na mesma semana, movendo julgamento de aprovação para dentro do sistema.
• "Remove the deprecated codex exec --full-auto flag; use --sandbox workspace-write instead." — e este é o movimento oposto, no mesmo release. O modo "tudo liberado" morre, substituído por um nível de sandbox nomeado. Os dois juntos contam a história certa: não se está afrouxando a contenção, está-se trocando o botão binário por gradação e automatizando o julgamento dentro da gradação.
• "Harden plugin isolation and deny network access when policy updates fail." — fail-closed explícito: falhou a atualização de política, corta a rede. É o exemplo citável que o cap. 07 pede quando argumenta que a postura padrão em falha define a contenção.
• "Redact secrets and complete bearer tokens from displayed commands and replayed conversation history." — segredos e bearer tokens completos apareciam em comandos exibidos e no histórico reproduzido. O vazamento não estava no runtime: estava na memória. O cap. 08 trata persistência como problema de continuidade e custo; aqui ela é superfície de exposição — o segredo que passou uma vez pelo terminal fica guardado e volta a ser exibido a cada replay.

Uma quinta linha vai para outro capítulo: "Import Cursor-managed skills and synchronize changes to imported Claude and Cursor conversations without creating duplicates." — interoperabilidade por artefato, não por protocolo: um harness lendo as skills e as conversas de dois concorrentes. Enquanto ACP e A2A padronizam o fio, o Codex padronizou o arquivo do outro. Caps. 12 e 14.

Impacto B (07, 08); C para 12/14.

Fonte primária: releases do opencode, v1.18.15 (07/ago), literal: "Repeated compaction now keeps earlier tool-call history in summaries instead of dropping orphaned results". E, no mesmo release: "Chronological message ordering now stays correct even when imported or legacy message IDs are out of order".

O cap. 04 trata compactação como técnica — o que é, quando disparar, o que preservar. O que falta lá é o que este release entrega de graça: um modo de falha de produção, datado e nomeado. Não é "compactar perde contexto", que é óbvio e genérico. É específico: quando a compactação acontece mais de uma vez, o resumo da segunda passada pode deixar para trás resultados de ferramenta cuja chamada correspondente já saiu do histórico — resultados órfãos. O agente segue com um resumo que menciona uma ação e não tem o que ela devolveu.

É a compactação como operação repetida que quebra, não como operação única — e nenhum capítulo do livro discute a compactação da compactação. Combina com o que a spec 082 já registrou no Prime Agent (histórico completo, inclusive compactações passadas, acessível por programa) e com o que a v2.1.225 do Claude Code corrigiu na mesma semana ("Fixed conversation history breaking on Remote Control session resume after very large conversations were compacted").

Impacto B para o cap. 04: a seção pode ganhar um trecho sobre modos de falha, com três casos datados e independentes.

Fonte primária: releases do OpenHands. v1.11.0 (07/ago): "add a typed agent action for launching local or Cloud child conversations" e "show per-run LLM cost in the Activity Log and exports". v1.10.0 (05/ago): "set Canvas default model to GLM 5.2", "activity log export", "filter the skills page with a faceted rail".

Dois pontos, os dois C: subagente deixa de ser convenção de prompt e vira ação tipada do protocolo interno do agente, com destino local ou em nuvem (cap. 10, dimensão 10); e o GLM 5.2 — o modelo da Z.ai, cujo harness ZCode foi descartado do corpus em 02/ago por ser fechado — passa a ser o padrão de um recurso de um membro do corpus. Modelo aberto atravessa a fronteira que o harness fechado não atravessa: é a mesma tese do padrão "modelo aberto, harness fechado", vista do lado de quem consome. Nota para o apêndice de cadeia de suprimentos.

Último release é o v1.45.0, de 29/jul. Onze dias sem publicar, num projeto que é âncora de fundação (AAIF/Linux Foundation, registrado em 06/ago). Não é sinal de dormência — a cadência histórica do goose não foi medida nesta execução e não se afirma nada sobre ela. Fica registrado como observação a confrontar no refresh do Apêndice A: um projeto sob governança de fundação tem cadência diferente de um projeto de fornecedor? O corpus agora tem os dois tipos e pode responder com dado.

Fonte primária: changelog oficial, v2.1.224 (2026-08-07), citado literalmente:

• "Added cross-session SendMessage: Claude Code sessions can now message each other, on any of your machines, with ListAgents to discover them (macOS and Linux)"
• "Added crossSessionInbound and dialogExpiry settings: cross-session messages sent to a session running with bypassed permissions are held for your approval, and messages to other sessions auto-deliver"
• "Fixed SendMessage reporting "Message sent" when the write to a teammate's inbox had actually failed; failed deliveries are now reported as errors"
• "Added self-hosted environments: claude self-hosted-runner turns your own machines or containers into a place Claude Code web, mobile, and desktop sessions can run, on Team and Enterprise plans"

E na v2.1.225 (2026-08-08): "SendMessage can now start a conversation with your Remote Control sessions on other machines by name". Na v2.1.224 ainda: "Removed the 200-subagent-per-session spawn cap; long-running sessions no longer refuse new agents (concurrency and depth limits still apply)".

Por que isso importa para o livro, e não é só uma feature. O cap. 10 trata orquestração como hierarquia: uma sessão-mãe que gera subagentes e coleta resultados. O que apareceu aqui é lateral — sessões independentes, em máquinas diferentes, que se descobrem por nome e trocam mensagens. Isso é exatamente o problema que o A2A existe para resolver (cap. 17), e o harness mais maduro do corpus o resolveu dentro de casa, com endereçamento e semântica próprios, sem tocar no protocolo da Linux Foundation. Não é hipocrisia nem descuido: é o sinal de que, para o caso "meus agentes, minhas máquinas", o protocolo interoperável não é o caminho de menor resistência — e isso qualifica a tese de convergência do cap. 14 num ponto específico.

Dois detalhes de projeto que valem citação no cap. 07:

• mensagem que chega a uma sessão com permissões desativadas fica retida para aprovação humana. Ou seja: o harness trata mensagem de outro agente como canal de entrada não confiável, e o modo mais permissivo é justamente o que perde a autonomia de aceitar. É o raciocínio de raio de alcance aplicado a uma superfície nova.
• o SendMessage mentia ("Message sent" com a escrita falhando). Falha silenciosa numa primitiva de coordenação: se A pensa que falou e B nunca ouviu, o sistema não trava — ele divergesorrindo. Terceiro caso do padrão que este Radar vem acumulando (o diálogo de aprovação que escondia parte do comando, 07/ago; o envio de e-mail que dizia "enviado", spec 084 do próprio livro).

Impacto B para os caps. 10 (orquestração deixa de ser só vertical), 17 (agente-para-agente fora do protocolo), 13 (o runner auto-hospedado move a fronteira de execução para a máquina do cliente) e 07 (mensagem entre agentes como entrada não confiável). Apêndice A: teto novo na dimensão 10.

Fonte primária: mesmo changelog, v2.1.224 (2026-08-07), literal:

• "Added sandbox credential-masking options: extract and onExtractNoMatch for structured env values, decode: "jwt" with maskClaims for JWT-aware masking, and awsPairs/sigv4 for AWS SigV4 re-signing; these need network.tlsTerminate and are honored only from user, managed, or --settings settings"
• "Fixed sandbox filesystem deny entries written with a trailing slash (e.g. denyRead: "~/.aws/") being silently bypassable on Linux and macOS"
• "Fixed sandbox violation details never appearing in Bash tool results; Claude now sees which file or network access was denied and why"

Três coisas diferentes, e as três interessam:

A capacidade é nova de verdade. O sandbox deixa de apenas bloquear egresso e passa a terminar o TLS e reescrever a credencial em trânsito — mascarar claims de JWT, re-assinar SigV4. Nenhuma das 12 dimensões do benchmark cobre isso: a dimensão 7 mede permissão e contenção, não transformação de credencial na saída. É candidato a subcritério na rodada 2026-10.

O furo é do tipo mais barato de escrever e mais difícil de ver. denyRead: "~/.aws/" — com barra — era silenciosamente contornável. Quem escreveu a regra achou que estava protegido, o sandbox achou que não havia regra, e nada avisou. Um sandbox cuja regra pode falhar em silêncio por causa de uma barra é um argumento do cap. 07 que agora tem fonte oficial e datada.

E o terceiro item é o inverso do segundo: até a v2.1.224, quando o sandbox negava algo, o modelo não era informado do motivo. Contenção que não se explica ao agente contido produz o agente que tenta de novo, do mesmo jeito — o mesmo raciocínio de "falha diagnosticável" que a v2.1.225 aplica ao auto mode ("the action is still denied, but the model is now told to move on rather than retry").

Impacto B para o cap. 07. Somado ao que foi registrado em 07/ago (oito furos de permissão em três semanas), o placar é: o harness mais maduro do corpus corrigiu dez falhas de permissão ou sandbox em pouco mais de três semanas, e na mesma janela ampliou a superfície do sandbox com interceptação de TLS. Não é sinal de imaturidade do produto — é a evidência empírica de que o cap. 07 está certo ao chamar essa camada de a mais difícil de acertar.

Fonte primária lida nesta execução: organização meta-models no GitHub.

Ela tem exatamente um repositório público: meta-model-cookbook — "Developer recipes for Meta Model API — agentic workflows, multi-agent orchestration patterns, and use case examples with cost comparisons", MIT, Python, 71★/9 forks, atualizado 2026-08-08. Nenhum repositório do agente, nenhum do modelo.

Isso fecha, pela primária, o ⏳ que ficou de ontem sobre a parte que mais importa: a Meta publicou receitas de API sob MIT e manteve o harness e o modelo fechados. A frase que o Radar registrou em 07/ago ("modelo aberto, harness fechado") precisa de um ajuste de precisão para o caso da Meta: aqui os dois são fechados, e o que está aberto é o material de adoção. O padrão segue valendo — o valor está no scaffolding — mas o caso Meta é mais radical do que o da Z.ai, não equivalente.

E surgiu um dado que muda a conversa do apêndice de cadeia de suprimentos: o tier de contribuidor. Preço padrão de US$ 1,25/M de entrada e US$ 4,25/M de saída; tier de contribuidor a US$ 0,10/M de entrada e US$ 0,20/M de saída — cerca de 12× mais barato — em troca de a Meta usar prompts e saídas para melhorar os produtos. ⏳ os números não foram lidos na primária (ai.meta.com bloqueado); vêm de cobertura de primeira linha: Engadget · TechCrunch · The Register · VentureBeat · SiliconANGLE.

O preço de um harness passa a ter duas moedas, e a segunda é o seu código. Impacto B para o apêndice de cadeia de suprimentos (é a primeira vez que o Radar vê desconto explícito e tabelado em troca de dado de trabalho) e C para o cap. 07, que trata dado do usuário como questão de permissão, não de precificação.

Fonte primária: RyanAlberts/best-of-Agent-Harnesses, lido nesta execução. CC-BY-SA-4.0, TypeScript/Python/Rust, 498★/34 forks (14,6:1 ✓), 134 commits, ativo.

154 projetos catalogados, re-pontuados semanalmente, com eixos declarados: estrelas (ordenação), simplicidade↔capacidade em quatro faixas, faixa de autonomia (★ para headless-ready), faixa de recuperação (✱ para execução durável) e estado de abertura (✅ OSS · ⚠️ source-available · ❓ incerto). E se publica em três formatos de máquina: harnesses.json, llms.txt e um servidor MCP (io.github.RyanAlberts/agent-harnesses) com as funções recommend, compare, pick_harness e search_harnesses.

Duas leituras, as duas úteis:

A definição. O repositório define harness assim: "A model answers; an agent acts. An agent harness is the runtime that turns one into the other—the model thinks; the harness decides what that thinking is allowed to touch." É a quarta definição independente a convergir com a do cap. 01 — depois da Microsoft ("the scaffolding that turns a language model into an agent", 05/ago), do survey de Meng et al. e do RUCAIBox. E esta acrescenta a parte que o livro insiste em não deixar de fora: o harness decide no que o pensamento pode mexer. É permissão como parte da definição, não como capítulo separado.

O número. 154 projetos que alguém está disposto a chamar de harness, re-pontuados por semana. O cap. 01 §4 defende um teste de inclusão explícito justamente contra isso, e o caso Claw Code (06/ago) mostrou o que acontece sem ele. Um diretório que ordena por estrelas e ainda oferece recommend por MCP é, ao mesmo tempo, a melhor pista de varredura que este Radar já encontrou e um exemplo do problema: agentes passando a escolher harness por ranking de estrelas de outros agentes. Como pista, entra no fluxo de busca; como fonte, não — cada candidato segue passando pela triagem de repositório.

Impacto B para o cap. 01 §4 (quarta definição convergente + evidência de inflação da categoria) e 14/17 (o diretório da categoria servido pelo protocolo da categoria).

⏳ primária inacessível: openreview.net e picrew.github.io bloqueados. Falta a leitura de OpenReview 3hXEPbG0dh para saber quem assina.

O que as listagens dizem: "Agent Harness Engineering: A Survey", submetido 14/mai/2026, modificado 25/mai, em avaliação na TMLR, propondo a taxonomia ETCLOVG — sete camadas (ambiente de execução, interface de ferramentas, gestão de contexto, ciclo de vida/orquestração, observabilidade/operações, verificação/avaliação, governança), com observabilidade e governança como camadas independentes porque "em produção cada uma tem sua própria pilha e um time diferente como dono".

Antes de contar como terceiro, fui conferir se não é o segundo. Primária lida: Gloriaameng/Awesome-Agent-Harness — o survey de Meng et al. registrado em 04/ago é "Agent Harness for Large Language Model Agents: A Survey", 11 autores (Qianyu Meng, Yanan Wang, Liyi Chen, Wei Wu, Yihang Li, Wenyuan Jiang, Qimeng Wang, Chengqiang Lu, Yan Gao, Yi Wu, Yao Hu), Preprints.org DOI 10.20944/preprints202604.0428.v3 (v3 de 09/abr/2026), taxonomia H = (E, T, C, S, L, V) — seis componentes (Execution Loop, Tool Registry, Context Manager, State Store, Lifecycle Hooks, Evaluation Interface), 110+ papers e 23 sistemas, CC-BY-4.0, 322★/21 forks, último push 14/abr/2026.

Título diferente, venue diferente, data diferente, seis camadas contra sete. Mas as letras se sobrepõem muito (E, T, C, …, V), e não pude ler quem assina o da TMLR. Fica ⏳ como possível duplicata, não como achado — e é uma ⏳ de tipo raro neste Radar: o risco aqui não é fonte fabricada, é contar duas vezes a mesma evidência.

Isso qualifica o achado de ontem. Em 07/ago o Radar escreveu que "o argumento de que o campo existe deixa de depender de uma fonte só" porque havia dois surveys independentes. Se o da TMLR for o de Meng et al. re-titulado com a taxonomia expandida, o argumento não fica mais forte — e a tentação de somar surveys precisa ser resistida com o mesmo rigor que se aplica a somar estrelas. Impacto C até a autoria ser lida.

Fonte primária: changelog oficial do Claude Code, lido nesta execução.

Não foi uma correção, foram duas, com três semanas de intervalo:

• v2.1.214 (2026-07-18): "Fixed worktree-isolated subagents redirecting git into the shared checkout via git -C, --git-dir, or GIT_DIR/GIT_WORK_TREE"
• v2.1.222 (2026-08-04): "Fixed worktree-isolated sessions and their subagents being able to run destructive git commands against the main checkout; isolation now applies to file edits and Bash in every session type"

A primeira fechou o vetor das variáveis de ambiente e das flags do git; a segunda revelou que ainda havia caminho, e que o isolamento não valia para todo tipo de sessão. Ou seja: o mecanismo que o livro apresenta como isolamento de subagentes precisou de dois turnos para efetivamente segurar.

E não é um caso isolado. A v2.1.221 (2026-08-04) traz um cacho de furos de verificação de permissão, todos citados textualmente no changelog:

• "Fixed a Bash permission-check bypass where zsh could execute hidden commands in [[ ]] regex conditionals"
• "Fixed permission prompts so commands padded with tabs or invisible Unicode can no longer hide part of the command from the approval dialog" — o diálogo de aprovação mentia para o usuário
• "Fixed workflow scripts being able to use dynamic import() to run code outside the workflow sandbox"
• "Fixed a permission gap where an agent definition's bypassPermissions mode ignored the org bypass-permissions disable policy"

Mais, na v2.1.214: regra Edit(src/**) auto-aprovando escrita em qualquer src/ da árvore, e não só no do diretório corrente; bypass no PowerShell 5.1; comandos acima de 10.000 caracteres escapando da checagem.

Impacto B, para os caps. 07 e 10 — e o valor aqui não é a correção, é o padrão. O cap. 07 argumenta que permissão e sandbox são o componente mais difícil de acertar; agora há evidência datada, oficial e citável de que o harness mais maduro do corpus corrigiu oito furos de permissão em três semanas, incluindo um em que a UI de aprovação escondia parte do comando. O cap. 10 apresenta worktree como o mecanismo de isolamento de subagentes (é o ⭐ do Grok Build na dimensão 9) — a ressalva agora tem fonte: worktree isola arquivos, e só passou a isolar o repositório git depois de duas correções.

⏳ Fonte primária inacessível nesta execução: ai.meta.com e dev.meta.ai estão bloqueados pelo proxy de egresso. O que falta é o post do Zuckerberg e a página oficial do produto.

Cobertura independente de veículos de primeira linha, todos em 2026-08-05/06: Bloomberg · CNBC · TechCrunch · The Register · Engadget · VentureBeat

O que descrevem: agente de terminal, instalado por curl em macOS e Linux, movido pelo modelo Muse Spark 1.2, com subagentes de fundo persistentes, cada um em workspace isolado, e um event log local à prova de crash. Primeiro produto de código do Meta Superintelligence Labs, sob Alexandr Wang.

O que importa para o livro não é o lançamento — é a licença. A Meta, a empresa que construiu sua identidade em IA sobre pesos abertos (Llama), lançou o harness fechado: binário proprietário instalado por script, sem repositório público. E isso é a terceira ocorrência do mesmo padrão já registrado neste Radar:

O caso da Meta é o mais agudo porque contradiz a própria estratégia da casa: abrir o modelo e fechar o harness só faz sentido se o valor tiver migrado do modelo para o scaffolding — que é, literalmente, a tese do livro. Impacto B para os caps. 01 §4 (teste de inclusão: reprova, é fechado), 14 (convergências — o argumento ganha um caso em que a empresa mais pró-abertura do setor fecha justamente esta camada) e para o apêndice de cadeia de suprimentos.

Também absorve o ⏳ de ontem sobre a Meta e um framework chamado "Harness": pode ser este produto sob outro nome, ou o "multi-agent harness" que a cobertura diz estar por vir. Segue ⏳ até a primária — e o nome exato importa, porque seria a 4ª big tech a batizar um produto de "harness".

Fonte primária: RUCAIBox/awesome-agent-harness, lido nesta execução.

"Agent Systems with Harness Engineering" — RUCAIBox (AI Box, Renmin University of China), OpenReview nM5tDHrQsx, 502 referências, atualizado em 2026-05-19. Taxonomia em quatro eixos: evolução da engenharia de harness (interfaces de ação, infraestrutura de workflow, persistência centrada no usuário); design do harness (workflows, memória, bibliotecas de skills, orquestração multiagente); adaptação do modelo (context engineering, treino agêntico); benchmarks representativos.

É distinta do survey de Meng et al. registrado em 04/ago (110+ papers, 23 sistemas, taxonomia H=(E,T,C,S,L,V), DOI Preprints.org). Impacto B para o cap. 01 §6: duas surveys independentes, de grupos diferentes, com taxonomias diferentes, publicadas em meses — o argumento de que o campo existe deixa de depender de uma fonte só. E o confronto de taxonomias fica mais rico: agora são três (a nossa de 12 dimensões, a H=(E,T,C,S,L,V) e a de quatro eixos do RUCAIBox).

⏳ arXiv, HuggingFace e emergentmind bloqueados nesta execução — o identificador aparece consistentemente em três listagens independentes, mas o abstract não foi lido na primária. Falta: leitura do arxiv.org/abs/2607.12227.

"Rethinking the Evaluation of Harness Evolution for Agents" (arXiv 2607.12227). O argumento: os ganhos atribuídos à evolução automática do harness podem ser artefato do modo de avaliar, não evidência de harness melhor. Em Terminal-Bench 2.1, com GPT-5.4 e Claude Opus 4.6, a evolução automática não supera consistentemente test-time scaling simples sob orçamento de feedback e inferência pareado, e generaliza mal em tarefas retidas — porque a busca e a avaliação final compartilhavam o mesmo benchmark.

Impacto B para o cap. 16. O Radar vinha acumulando um lado só dessa história: HarnessX (+14,5% médio, até +44%), Continual Harness, DemoEvolve, Observability-Driven Evolution — todos registrados em 02–04/ago. Este é o contraditório, e com uma exigência metodológica concreta (comparar contra test-time scaling sob orçamento pareado) que o capítulo pode adotar como critério. Vizinhos, para leitura dirigida: TTHE: Test-Time Harness Evolution e Scaling Laws for Agent Harnesses via Effective Feedback Compute — C.

Fonte primária: API do GitHub, consultada nesta execução. Uma cadeia de wires de press release (24-7pressrelease, replicado por FinancialContent) anuncia o Claw Code como "framework de agente de código open source" com "72.000 estrelas nos primeiros dias", "clean-room rewrite da arquitetura do Claude Code", em Python e Rust. Se fosse verdade, seria candidato imediato ao corpus — e hoje já teria 194.982 estrelas, mais que o opencode (165k), o maior do estudo.

O que a API devolve para ultraworkers/claw-code:

• 194.982 estrelas para 109.281 forks — razão de 1,8:1. Projetos reais ficam em 10:1 ou mais (o opencode, com 165k estrelas, não tem 90k forks). Uma razão dessas não acontece por adoção orgânica.
• A descrição do próprio repositório: "An agent-managed museum exhibit, built in Rust with Gajae-Code / LazyCodex — developed and maintained with no human intervention." Ou seja: o projeto se declara peça de exposição mantida sem humano, enquanto o press release o vende como framework de produção.
• Linguagem registrada: só Rust (o release diz "Python e Rust").

Descarte, com motivo forte — e o item vale como achado editorial, não como candidato: é o equivalente em código dos "Kindle self-published de Harness Engineering" registrados em 31/jul. A categoria está sendo inflada por artefatos com métricas compradas e narrativa de wire pago. Impacto B para o cap. 01 §4 (o teste de inclusão como defesa — e agora com um caso concreto de por que estrelas não são evidência) e para o cap. 14. Também é lição de método: a API do repositório é fonte primária; o press release, não — a razão estrela/fork deve entrar como sinal de triagem no contrato.

Fontes: press release da Linux Foundation · site da AAIF · Block A Agentic AI Foundation (AAIF) foi formada em dezembro/2025 (não em 2026) e é ancorada por três projetos doados: MCP (Anthropic), goose (Block) e AGENTS.md (OpenAI). Membros platinum: AWS, Bloomberg, Cloudflare, Google, Microsoft. Governança em dois órgãos (TSC + Governing Board) com assentos técnicos das fundadoras e assentos eleitos pela comunidade — modelo declaradamente emprestado do Kubernetes. O A2A foi para a Linux Foundation antes (jun/2025) e hoje tem um working group na AAIF trabalhando cadeias de confiança entre agentes, declaração de capacidades e rate limiting. Impacto B — dois pontos que o livro precisa acertar: (a) um membro do corpus (goose) é projeto-âncora de fundação, o que muda seu status institucional no Apêndice A; (b) AGENTS.md também foi doado pela OpenAI e é âncora da mesma fundação. A frase do cap. 17 sobre governança precisa distinguir "MCP ancorado na AAIF" de "A2A na LF com working group na AAIF". ⏳ o número "150+ organizações" aparece tanto para a AAIF quanto para o A2A em fontes diferentes — não repetir sem separar (pode ser o mesmo número reaproveitado por agregadores).

Fontes (rastreadores; ⏳ confirmar no changelog oficial): Releasebot · ClaudeLog Entre as correções recentes: "sessões isoladas por worktree e seus subagentes conseguiam rodar comandos git destrutivos contra o checkout principal" e "timeout de stream disparando em gateways ANTHROPIC_BASE_URL apesar de keep-alive". Também: remoção do ultraplan, isolamento de worktree reforçado, tratamento mais seguro de auto-allow. Impacto B (caps. 10 e 07): o livro trata worktree como mecanismo de isolamento de subagentes (é o ⭐ do Grok Build na dimensão 9). O incidente mostra que worktree isola arquivos, não o repositório git — o subagente alcançava o checkout principal. É uma qualificação importante da síntese, com caso real. Para promover, confirmar no changelog oficial.

• Meta estaria construindo um framework de agente chamado Harness, anunciado por Alexandr Wang (Chief AI Officer) no YC Startup School 2026. ⏳ só em agregador (KuCoin) — sem fonte primária da Meta nesta execução. Se confirmar, é a quarta big tech a nomear um produto "harness" (após Microsoft, e as verticalizações de xAI/Moonshot). B se confirmado (caps. 01/14).
• Meta-Harness (Stanford IRIS Lab) — nome colidente, coisa diferente: framework de pesquisa para otimizar autonomamente o scaffolding em torno de um LLM fixo. Vizinho direto do HarnessX registrado em 04/ago. C (cap. 16).
• Omnigent (jul/2026) — framework open source descrito como "meta-harness". C (fila de candidatos).

ai-boost/awesome-harness-engineering — "tools, patterns, evals, memory, MCP, permissions, observability, and orchestration". Mesma proposta da coleção GHDaru/awesome-harness-engineering que ancora a taxonomia do livro. Impacto C — não muda conteúdo, mas é dado de que a organização-por-problema virou convenção (e vale ao editor saber que existe).

Fontes primárias: anúncio do BUILD 2026 · release do Harness · cobertura InfoQ (ago/2026) Datas apuradas (o ⏳ de 02/08 pedia isso): BUILD 2026 em 2–3 de junho anuncia o Agent Harness junto de Hosted Agents, CodeAct e conectores; GA em 22 de julho de 2026. E o detalhe que interessa ao livro está na definição que a própria Microsoft publica:

"An agent harness is the scaffolding that turns a language model into an agent… you need a runtime wrapped around the model – and that runtime is the harness."

É, palavra por palavra, a definição do cap. 01 (harness = scaffolding; agente = modelo + harness). Impacto B, e dos mais valiosos: (a) cap. 01/14 — o vocabulário deixou de ser da comunidade e virou nome de produto de big tech, com definição convergente e independente; (b) o Agent Framework entra na fila de candidatos da categoria frameworks (rodada 2026-10); (c) o produto embarca conectores para o Claude Agent SDK e o GitHub Copilot SDK — mais um elo para o apêndice da cadeia de suprimentos, agora com um framework de big tech consumindo harnesses de concorrentes. Nota de honestidade: a mesma varredura indica que o Agent Framework (guarda-chuva) já estava em GA desde 08/abr/2026; o que ficou GA em julho é o Harness + Hosted Agents. ⏳ confirmar essa separação no changelog oficial antes de citar no livro.

Fontes: arXiv:2603.02277 · ICML 2026 — Oral · repo UKGovernmentBEIS/sandbox_escape_bench Marchand, O Cathain, Wynne, Giavridis, Deverett, Wilkinson, Gwartz, Coppock (Oxford + UK AI Security Institute), mar/2026. Avaliação CTF em Inspect AI com sandbox aninhada (a camada externa guarda a flag e não tem vulnerabilidade conhecida); 18 cenários em três camadas de ataque — orquestração (4), runtime (8) e kernel (6) —, dificuldade 1–5. Achado central: com vulnerabilidades presentes, modelos de fronteira identificam e exploram, e o custo de uma tentativa de escape fica na casa de um dólar. Impacto B (caps. 07 e 11): é exatamente o eval comportamental de segurança que nenhum dos 20 sistemas do corpus tem — o benchmark do livro afirma que "evals comportamentais são o gap mais comum", e agora existe um instrumento público, aceito como Oral em conferência de primeira linha, para medir a dimensão 6. Aceitação em ICML também o qualifica para a bibliografia sem ressalva de preprint.

• The Balkanization of Execution-Security Research for AI Coding Agents (Rashidi, jul/2026): sistematiza 39 papers (2023–2026) em 17 categorias, cada um verificado contra a fonte, e confirma 4 CVEs divulgados e corrigidos que afetam harnesses de produção. A tese é metodológica e incômoda: isolamento, capabilities, políticas, TOCTOU, ameaças de MCP, delegação de identidade, proveniência de execução e egress são publicados isoladamente e quase não se citam entre si. Impacto B (cap. 07 e cap. 11): traz CVEs reais em harnesses — o livro discute superfícies de ataque, mas não cita incidentes confirmados; e a "balcanização" é o argumento de que falta exatamente o que este livro faz (organizar por mecanismo). Artefatos legíveis por máquina disponíveis.
• Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents (Santos-Grueiro, jun/2026): nomeia a "autoridade remanescente" — a capability temporária que continua exposta depois de encerrado o subobjetivo que a justificava — e propõe o PORTICO, monitor de referência que compila um contrato de tarefa em capabilities iniciais, regras de concessão, predicados de fechamento e negações globais; a concessão emite handles ligados a época e o fechamento os remove da próxima interface do planejador, rejeitando replay na execução. Impacto B (cap. 07): conversa diretamente com o modelo de autoridade do IronClaw (aprovações como leases por invocação, avaliado como teto conceitual do corpus) e dá nome acadêmico a uma falha que a avaliação do QM também toca (aprovações que pausam e retomam runs).
• Vizinhos da mesma safra, para a fila: IssueTrojanBench (agentes contra issues maliciosas) e Setup Complete, Now You Are Compromised (instruções de setup como vetor). C.

• Claude Code em v2.1.221 (03/ago) conforme rastreadores de release; entre as novidades recentes citadas: dados de conector MCP ao vivo em artefatos publicados, modo leitor de tela, sessões em background para /fork, e reforços de salvaguarda em WebSearch, spawn de subagentes e execução de Bash. ⏳ conferir no changelog oficial antes de qualquer nota no Apêndice A — a fonte aqui foi rastreador de terceiros. Agent teams consta como research preview desde v2.1.32 (fev/2026). C.
• A2A: v1.0 formalizada em abril/2026; MCP e A2A agora sob a Agentic AI Foundation (AAIF) da Linux Foundation, cofundada por OpenAI, Anthropic, Google, Microsoft, AWS e Block. O cap. 17 registra a governança pela LF; ⏳ a existência da AAIF como guarda-chuva comum aos dois protocolos merece conferência em fonte primária — se confirmada, é atualização de uma frase no cap. 17. C.
• Google ADK 2.0 (estável desde 19/mai/2026, motor de workflow em grafo + Task API): candidato à categoria frameworks, junto com o Agent Framework. C.

Fontes primárias: PR #18186 "anthropic legal requests" no repo do opencode · commit 973715f Cronologia apurada: 09/jan/2026 a Anthropic implanta verificação server-side (tokens OAuth de Pro/Max passam a recusar uso fora do Claude Code) → 19/fev/2026 os Termos de Serviço ganham a seção "Authentication and credential use" proibindo explicitamente tokens de assinatura em ferramenta de terceiros, inclusive via Agent SDK → 19/mar/2026 o opencode remove o plugin opencode-anthropic-auth, o provider do enum e o prompt anthropic-*.txt por pedido legal (511 reações negativas no PR). Justificativa pública da Anthropic: harnesses de terceiros geram "outsized strain" na infraestrutura.

Duas consequências, e a segunda é a que importa:

• O item ⏳ de 2026-08-03 era real, mas o agregador apresentou fato de março como notícia de agosto. Lição de método para o contrato: agregador não datado é fonte suspeita também quanto à data, não só quanto ao conteúdo.
• O Apêndice — A cadeia de suprimentos (edição 0.68, publicado anteontem) tem uma lacuna: ele afirma que "quem consome um harness herda as capacidades, mas não os controles" e que a cadeia é risco herdado — sem registrar que o caso já aconteceu. Este é o primeiro caso documentado de fornecedor revogando acesso e ele atinge dois membros do corpus (opencode e OpenClaw). Melhor ainda para a tese: é revogação do provedor de modelo, um elo acima dos harnesses — a cadeia tem um andar que o apêndice não desenhou. Impacto B (apêndice supply-chain + cap. 12; nota no Apêndice A do opencode: o "agnóstico de provedor" continua verdadeiro por API key, mas o caminho por assinatura morreu).

Fontes: repo oficial Gloriaameng/Awesome-Agent-Harness · dataset no HF · ResearchGate "Agent Harness for Large Language Model Agents: A Survey" — Meng, Qianyu; Wang, Yanan; Chen, Liyi; Wu, Wei; Li, Yihang; Jiang, Wenyuan; Wang, Qimeng; Lu, Chengqiang; Gao, Yan; Wu, Yi; Hu, Yao (2026). Preprint no Preprints.org, DOI 10.20944/preprints202604.0428.v3 — não é arXiv (o ⏳ de ontem supunha arXiv; corrigido). Formaliza o harness como tupla de seis componentes H = (E, T, C, S, L, V), cobre 110+ papers e 23 sistemas numa Harness Completeness Matrix e mapeia 9 desafios abertos; propõe cinco camadas arquiteturais (núcleo de raciocínio; gateway/sessão; contexto e memória hierárquica; instruções/tools/loop; triggers e saídas). Impacto B — é o vizinho metodológico mais próximo do nosso benchmark (matriz de completude ≈ nossas 12 dimensões) e entra em cap. 01 §6 (posicionamento do método) + bibliografia. Confronto obrigatório na leitura: a taxonomia deles versus a nossa — convergência ou divergência é achado dos dois jeitos.

Fontes: arXiv:2605.23950 · versão OpenReview "Stop Comparing LLM Agents Without Disclosing the Harness" defende a Binding Constraint Thesis: em tarefas de horizonte longo entre modelos de capacidade comparável, a variância induzida pelo harness excede a induzida pelo modelo — a ponto de haver inversão de ranking entre modelos ao trocar o harness. Três linhas de sustentação: formalização control-theoretic (harness = controlador de um sistema dinâmico em malha fechada; o LLM = política estocástica), decomposição de variância controlada sobre benchmarks e implantações, e uma proposta de padrão de disclosure de harness para leaderboards. Conclusão dos autores: comparações de leaderboard sem especificação do harness devem ser tratadas como incompletas e potencialmente enganosas. Impacto B (não invalida nada — fortalece): é a citação de peso que faltava para a tese "agente = modelo + harness" do cap. 00/01, e vira material direto do cap. 11 (o disclosure standard é um requisito de eval que nenhum membro do corpus cumpre). Também é argumento para a proposta editorial.

Fontes: arXiv:2606.14249 · github.com/Darwin-Agent/HarnessX (MIT, v0.1.0, Beta) "Foundry" de harnesses: primitivas tipadas compostas por uma álgebra de substituição, adaptadas por um motor de evolução multiagente guiado por traces (AEGIS), fechando o laço harness↔modelo (trajetórias viram tanto edição de harness quanto sinal de treino). +14,5% em média (até +44,0%) em cinco benchmarks (ALFWorld, GAIA, WebShop, τ³-Bench, SWE-bench Verified), com ganho maior onde a baseline é pior. Impacto B — teste de inclusão na rodada 2026-10 (é foundry, não harness de propósito geral: provável entrada na categoria frameworks) e material forte para o cap. 16 (auto-melhoria) — junto com DemoEvolve (evolução de harness guiada por demonstrações humanas quando o reward é esparso) e Harness Handbook (tornar harnesses em evolução legíveis/navegáveis/editáveis — o problema de manutenção que a auto-evolução cria).

Harness Engineering as Categorical Architecture · Harness as an Asset: determinismo via CAAF · Adapting the Interface, Not the Model: Runtime Harness Adaptation. Impacto C — o volume em si é o dado: em duas varreduras, o termo "harness" já rende uma dezena de preprints distintos com taxonomia própria. O campo está nomeando a si mesmo agora (cap. 01/14).

⏳ via agregadores, conferir no changelog oficial: Claude Code 2.1.200+ com auto-mode (execução não assistida), amadurecimento de agent teams e Agent SDK em estabilidade de produção; Codex em 8 milhões de usuários (7× desde fevereiro); opencode com adaptive thinking para usuários de API key. MCP: nada novo além da 2026-07-28 já registrada. Impacto C (Apêndice A na rodada 2026-10).

• Survey "LLM-Agent-Harness" (dataset no HF) — formaliza o harness como objeto arquitetural de primeira classe H = (E, T, C, S, L, V), cobre 110+ papers e 23 sistemas, mapeia 9 desafios abertos. ⏳ id arXiv não confirmado nesta execução. Se confirmado, é o segundo survey do campo (após o da Renmin de maio) e vizinho metodológico direto do nosso benchmark. Impacto B (caps. 01 §6 e 14; bibliografia).
• Code as Agent Harness — o survey-pai da lista YennNing registrada em 2026-08-02, agora com id. C (bibliografia).
• Recursive Agent Harnesses (jun/2026) — harnesses que se aninham recursivamente; conversa com subagentes (cap. 10) e auto-melhoria (16). C.
• SandboxEscapeBench (Marchand et al., 2026) — mede capacidade de fronteira de LLMs para escapar de sandbox de container; é o eval que falta na dimensão 6/10 do benchmark. ⏳ id arXiv a confirmar. B (caps. 07/11).
• DeltaBox — checkpoint/rollback de sandbox em milissegundos para agentes stateful. C (caps. 07/08).
• ClawVM — "memória virtual" gerenciada pelo harness para agentes com estado. C (caps. 04/08).

Fonte primária: blog oficial do Microsoft Agent Framework — anuncia "Agent Harness", Hosted Agents e CodeAct no framework. ⏳ data exata do anúncio (BUILD 2026 ≈ maio; apareceu na varredura de hoje e não estava registrado). Duplo interesse: (a) big tech adotando o vocabulário que dá nome ao livro — dado forte para o cap. 01 e para a tese "a janela do vocabulário está aberta"; (b) o Microsoft Agent Framework como candidato à categoria frameworks na rodada 2026-10. Impacto B (caps. 01/14; benchmark).

• ⏳ opencode teria perdido o login por assinatura Claude Pro/Max após disputa com a Anthropic (chave de API crua seguiria funcionando) — apareceu em comparativo de agregador; sem fonte primária nesta execução. Se confirmado, é impacto B — não pelo fato comercial, mas pelo que ilustra: o apêndice da cadeia de suprimentos (edição 0.68) ganharia seu primeiro caso de fornecedor revogando acesso — o risco da cadeia deixando de ser teórico. Verificar em fonte primária antes de qualquer promoção.
• ⏳ Claude Code: Sonnet 5 como default (1M de contexto), subagentes em background por padrão, Claude in Chrome em GA — via hub de changelogs; conferir no changelog oficial na próxima janela. C (Apêndice A).
• MCP/A2A: sem fato primário novo. A consolidação ACP(IBM)→A2A é de ago/2025, já refletida no cap. 17 (nota: não confundir com o ACP da Zed — Agent Client Protocol — que segue vivo e é a via de integração de 8+ providers no mapa de supply chain).

Fontes: releases oficiais · agregadores de ecossistema — última release v0.86.2 há ~3 meses, mantida pela comunidade, ~44k stars; porém a última minor (0.86.0) é de agosto/2025 — um ano de cadência só de patches. Não invalida a avaliação (commit congelado), mas pede nota de status no Apêndice A na rodada 2026-10: o corpus tem seu primeiro membro em manutenção lenta, e o texto que o trata como "em evolução" merece ajuste. Impacto C (rebaixado de B? — mantido B? → C, sem urgência).

Fonte: VentureBeat (esclarecimento direto: o que é MIT são os pesos do GLM-5.2 no Hugging Face; o ZCode é app desktop gratuito, não aberto). Sem repositório oficial do app. Descarte da candidatura (teste de inclusão exige código aberto); o item permanece como sinal do cap. 14 (vendor de modelo verticalizando no harness — padrão agora com três casos: xAI aberto, Moonshot aberto, Z.ai fechado; a variação de estratégia de abertura é em si um dado).

Fontes: anúncio oficial da YC no X · github.com/yc-software/qm · qm.ycombinator.com O ⏳ de 2026-08-01 cai: a YC confirmou em anúncio próprio (31/jul) que abriu o QM sob MIT — "multiplayer agent harness for work", cloud-first, Slack e web nativos, usado internamente em contabilidade/jurídico/eventos/engenharia (inclusive para construir o próprio QM). Feição relevante ao estudo: triggers (crons/webhooks), memória e arquivos compartilhados, conectores ("company brain"), navegador de agente, artefatos web compartilháveis, sandboxes e loops de código plugáveis — um harness de empresa (multi-tenant por natureza), categoria que o corpus ainda não cobre. Impacto B (cap. 01 §4: teste de inclusão na rodada 2026-10; caps. 08/10/13 conforme leitura do código; a comparação da própria YC com Hermes/OpenClaw posiciona o QM na categoria de agentes pessoais — escalada para "agente de empresa").

Fontes: VentureBeat · SCMP A Z.ai lançou o ZCode, app desktop gratuito que chama de "Agentic Development Environment": conversa do agente ao centro, com gerenciador de arquivos, terminal, painel Git e preview de navegador ao redor; "Goals" em vez de prompts, coordenação multiagente, condução por Telegram/WeChat e sistema de plugins recém-adicionado. A imprensa usa a palavra harness literalmente ("a harness for GLM-5.2"). ⏳ o que é open source é o modelo GLM-5.2 (MIT, HuggingFace/GitHub); o código do ZCode em si não foi confirmado como aberto nesta execução — verificar antes do teste de inclusão. Impacto B (cap. 01 §4 e cap. 15: a categoria ADE — agente com IDE em volta, como o Antigravity — é vizinha do harness embutido; cap. 14: mais um vendor de modelo verticalizando no harness, reforça a convergência).

Fontes secundárias: comparativo sanj.dev · wetheflywheel — última release tagueada v0.86.0 de agosto/2025 (12 meses), e uma issue de janeiro/2026 perguntando abertamente se o projeto entrou em modo manutenção. ⏳ não conferido na fonte primária nesta execução (releases do repo) — mas se confirmado, é exatamente o cenário da cláusula de expiração aplicado a um membro do corpus. Impacto B se confirmado (Apêndice A: status do sistema na rodada 2026-10; cap. 14: exemplo vivo de expiração; a avaliação do benchmark permanece válida — o commit é congelado — mas o texto que trata o Aider como "em evolução" precisaria de nota).

• Parallel Context Compaction for Long-Horizon LLM Agent Serving (mai/2026) — compactação paralela por blocos, ângulo de serving/throughput que o cap. 04 ainda não cobre. C.
• ContextBudget: Budget-Aware Context Management (abr/2026) — gestão de contexto orientada a orçamento; caps. 03/04. C.
• Harness Engineering for Agentic AI Coding Tools: An Exploratory Study (fev/2026) e Agentic Harness Engineering: Observability-Driven Automatic Evolution (abr/2026) — o segundo propõe evolução automática do harness guiada por observabilidade, tema do cap. 16. C.
• Awesome-Code-as-Agent-Harness-Papers — lista curada de um survey "Code as Agent Harness"; útil como fonte de garimpo, não como fonte citável. C.

Versões estáveis inalteradas desde ontem: Claude Code 2.1.220 · Codex CLI 0.146.0 · gemini-cli 0.53.1 (0.54 só em nightly, com session-id rotation e melhorias de caretaker-triage). MCP/A2A: sem fato primário novo após os registros de 2026-08-01. Sem ação.

Fontes: Anthropic — "bringing MCP 2026-07-28 to Claude" · AWS AgentCore Gateway · blog oficial Os 4 SDKs Tier-1 saíram com suporte no dia da publicação; a Anthropic anunciou o rollout no Claude; e a AWS descreve o gateway com tradução de versão — cliente 2025-* chama um servidor 2026-07-28 e recebe respostas no formato antigo, sem migrar. Impacto B (cap. 06: a previsão da spec 060 — "adoção pela coorte entra na matriz na próxima rodada" — já tem dados; o gateway-tradutor é um padrão de migração digno de nota; toca também o cap. 17, depreciação com ponte).

Fonte: explainx sobre o lançamento — ~1.9k stars em 2026-08-01, MIT, Slack e web. ⏳ URL do repositório ainda não confirmada em fonte primária — verificar antes de promover. Impacto B se confirmado (teste de inclusão do cap. 01 §4; interesse extra: harness nascido para Slack conversa com a categoria de agentes pessoais e com o cap. 10).

• AI Agents Do Not Fail Alone: The Context Fails First (jul/2026) — qualidade de contexto como indicador líder de confiabilidade do agente, com 7 critérios avaliáveis (role clarity, guardrails, consistência, schema de tools, grounding, endurecimento a injection, eficiência de tokens). Caps. 03 e 11. B/C — leitura dirigida (arXiv agora acessível).
• Architectural Design Decisions in AI Agent Harnesses — estudo empírico de 70 projetos sobre decisões arquiteturais recorrentes; metodologicamente vizinho do nosso benchmark. Caps. 01/14 + bibliografia. C.

Fonte: press release da Linux Foundation — 150+ organizações, SDKs em 5 línguas, embutido em Azure AI Foundry/Copilot Studio, Bedrock AgentCore e Vertex AI, produção em supply chain/financeiro/seguros. Impacto C (cap. 17: fortalece a linha "consolidando pela governança"; a adoção nos harnesses de produto segue sendo o que a matriz mede — dado para a rodada 2026-10).

• Grok Build (fim de julho): /tutorial de onboarding, e um session picker que retoma sessões de Claude, Codex e Cursor — a compat-poliglota (avaliada como ⭐ na ext-1) continuando a se aprofundar. Caps. 12/14. C.
• Pi: pacote pi-xai-oauth — provedor xAI chegando ao Pi via pacote de terceiros, o mecanismo de extensão funcionando como prometido (e polinização cruzada entre dois membros do corpus). Cap. 12. C.
• Versões correntes registradas: Claude Code v2.1.220 · Codex CLI v0.146.0 · gemini-cli v0.53.0; opencode >165k stars.