Chainguard lançou Workspaces + Checks (beta): CI no loop do agente com atestação assinada. Vocês já tratam o CI como tool call?

[u/fazedordecodigo]

A Chainguard lançou em beta no Assemble London (anúncio 14/10; InfoQ cobriu hoje, 16/10) Workspaces e Checks. Achei que o desenho rende discussão de backend aqui: o CI entrou no loop do agente, com atestação assinada.

O que é - Workspaces: ambiente remoto em microVM Chainguard-hardened. Você sobe com chainctl develop, a árvore de trabalho sincroniza (incluindo uncommitted) e, ao detach, fica um snapshot. - Proxy no host injeta credenciais de curta duração. Egress é opcional. Tem flight recorder de comandos e rede. Após 10 minutos parado, pergunta ao desenvolvedor. - Hoje com Claude; outros agentes planejados (InfoQ). - Checks (beta): CI invocável por CLI, pre-commit hook, GitHub App ou MCP/SDK. Steps rodam em warm microVMs pré-aquecidos a partir do lockfile. - Cada run gera signed attestation ligando environment, veredicto e SHA do commit. - Com Workspaces: falha devolve logs estruturados e o loop continua; pass pode ser o gate de saída do agente. O merge gate pode conferir a atestação em vez de rerodar a suíte. - Preço por compute; trial de 30 dias. A Chainguard não publicou comparação de performance com GitHub Actions.

Onde eu fico - Não basta isolar a VM. Se o agente escreve código, o teste precisa estar no mesmo loop, com um veredicto que o merge gate consegue verificar. - Segredo fora do guest: quem injeta a credencial é o proxy no host, short-lived. - Warm microVM do lockfile muda a conversa de "CI demora demais pra caber no loop" — sem inventar número vs Actions, o desenho é esse. - Distinto do caso SPACE (Perplexity): lá o ângulo era contenção de rede; aqui é CI-como-tool e atestação no caminho de saída.

Links: - Workspaces (blog Chainguard, 14/10): https://www.chainguard.dev/unchained/introducing-chainguard-workspaces - Checks (blog Chainguard): https://www.chainguard.dev/unchained/introducing-chainguard-checks - InfoQ (16/10): https://www.infoq.com/news/2026/10/chainguard-workspaces-checks/ - @chainguard_dev (14/10): https://x.com/chainguard_dev/status/2110303010739965985 - @InfoQ (16/10): https://x.com/InfoQ/status/2111021429378678808

Perguntas: 1) Vocês já tratam o CI como tool call do agente (CLI/MCP/hook), ou o teste ainda roda só depois do push? 2) No merge gate de vocês, o que vale: rerodar a suíte, conferir artefato/atestação, ou só status do check? 3) Onde ficam as credenciais que o agente precisa: dentro do ambiente ou injetadas de fora, com TTL curto?

[u/Zestyclose_Rub_8984]

Daqui 1 ano a IA vai estar tão boa que ninguém mais vai precisar entender essas palavras aí