O orquestrador, o canvas e os merges recusados no Unified Dev 1.1

O Unified Dev 1.1.0 traz um tipo de workspace proibido de editar ficheiros e de fazer commits. O Unified Dev é uma app nativa para macOS que corre agentes de código em worktrees de git: cada tarefa fica com a sua cópia do repositório, o seu branch e o seu agente, e podem correr vários ao mesmo tempo, com Claude Code, Codex, Grok, Cursor ou OpenCode.

Desde a 1.0.0, o histórico regista 50 commits de funcionalidades e 88 de correções, alguns deles apenas para as ferramentas internas de pré-visualização da app.

O workspace orquestrador

Em cada projeto, é possível marcar um workspace como orquestrador, onde fica o agente que planeia e distribui trabalho pelos outros. A app propõe-o quando se cria o primeiro workspace do projeto. A partir daí, o orquestrador aparece no topo da barra lateral, com os restantes por baixo.

Sempre que um workspace arranca nesse projeto, à mão ou por iniciativa de outro agente, o orquestrador é avisado e, se esse workspace tiver uma tarefa, recebe novo aviso quando termina o primeiro turno do novo agente. Nos workspaces que ele próprio inicia, recebe apenas este segundo aviso.

O orquestrador não edita ficheiros nem faz commits, e a proibição aplica-se desde o arranque. O Claude Code começa sem as ferramentas de edição e sem os comandos de git que alteram o repositório:

// Sources/Core/Agent/OrchestratorToolGuard.swift
public static let claudeDisallowedTools: [String] =
    ["Edit", "Write", "MultiEdit", "NotebookEdit"] + OrchestratorShellJudge.gitVerbs.map { "Bash(git \($0):*)" }

Os restantes agentes recebem a mesma regra por outras vias. O Codex passa a pedir permissão, o que o deixa numa sandbox só de leitura, e o Grok nunca recebe --always-approve. Nas conversas, os comandos de shell são avaliados antes de correrem, por isso um git commit ou um redirecionamento para um ficheiro são recusados. O mesmo acontece às ferramentas do bridge que controlam um terminal.

Merges recusados e arquivamento automático

Quando o GitHub recusa um merge, o agente já não se fica pela mensagem de erro, que é igual para um check falhado, um check pendente ou uma review em falta. Lê o estado do pull request e, se o problema for um conflito, um branch atrasado ou um check falhado, corrige, faz push, espera pelos checks e tenta outra vez.

Há limites, e estão escritos nas instruções que o agente recebe:

// Sources/Core/GitHub/MergeInstructions.swift
- **Three rounds at most.** A round is one fix, one push and one merge attempt. If the third
  is refused too, stop and say what GitHub said each time.
- **Thirty minutes of waiting at most**, counting every wait above together: for `UNKNOWN`,
  for a check still running, and after each push. Past it, stop and say what never finished.

As mesmas instruções proíbem usar um --force simples e aligeirar um teste, uma regra de lint ou um workflow só para o check passar. Uma review obrigatória, um pull request vindo de um fork ou um branch que outra pessoa alterou entretanto fazem o agente parar e explicar o que o GitHub respondeu. Isto são instruções: orientam o agente, mas não o travam como a retirada de ferramentas trava o orquestrador.

Depois do merge entra o arquivamento automático. Assim que é feito o merge de um pull request que a app tenha visto aberto, o workspace é arquivado, com a verificação de segurança habitual e sem pedido de confirmação. Está ligado por omissão e pode ser desligado na app ou em cada projeto. Um turno ou um comando em curso adiam o arquivamento. Se o turno for parado à mão, ou se houver trabalho fora do git, o workspace mantém-se e aparece um aviso.

O separador canvas

Há respostas que se leem melhor como página do que como mensagem. Um agente que tenha escrito um relatório pode chamar canvas_show com o caminho do ficheiro, e o ficheiro abre-se num separador ao lado da conversa. O separador atualiza-se quando o ficheiro muda, e também é possível abrir lá um ficheiro a partir do inspetor.

São aceites estes formatos:

// Sources/Core/Presentation/CanvasFile.swift
public static let extensions: Set<String> = [
    "html", "htm", "md", "markdown", "svg", "png", "jpg", "jpeg", "gif", "webp",
]

O ficheiro tem de estar dentro do próprio workspace. Os ficheiros .env e os ficheiros internos do repositório nunca são mostrados, e o agente recebe a indicação de copiar o que quer mostrar para um ficheiro normal.

Outras alterações

O ecrã de gastos ganhou uma secção por conta, ao lado das secções por fornecedor e por projeto. Com mais do que um login do mesmo agente no Mac, cada um tem a sua linha, e um login que já não esteja na máquina surge como gasto histórico.

O texto selecionado numa resposta pode ser citado ou servir para abrir uma conversa paralela.

Os blocos de shell têm agora um botão para os correr no workspace. O estado e os últimos 16 000 caracteres do resultado voltam à conversa, para o agente poder confirmar o que aconteceu.

Por omissão, o merge é agora feito com merge commit, salvo se for escolhido outro método para toda a app ou para um projeto.

Como obter a 1.1

A app requer macOS 26 num Mac com Apple silicon e está na página de releases, e a documentação do bridge indica o que cada tipo de agente pode chamar. Da coordenação ao arquivamento, quem tem vários agentes ativos já não precisa de acompanhar tão de perto cada passo.