Notas da versão Eigent v1.0.4: painéis de Skills e Connectors e execuções multiturno estáveis

O Eigent v1.0.4 é uma versão sobre deixar o workspace mais legível. Skills e Connectors eram antes cartões de configuração empilhados; agora são painéis no estilo biblioteca, com visões de coleção reais, páginas de detalhe e um shell de página compartilhado que Home, Skills e Connectors usam.

Abaixo dessa superfície, esta versão fecha um conjunto específico de lacunas que apareceram quando as tarefas passaram a durar mais: instruções perdidas entre turnos encadeados do modelo, checkpoints falhando quando uma tarefa clonava um repositório dentro de um Space, conectores exibindo um estado diferente do runtime que de fato os executaria, e o aplicativo não encerrando por completo ao fechar sua última janela.

---

🧩 Skills e Connectors como painéis de gerenciamento

Gerenciar uma Skill não deveria significar rolar uma página de configurações até achar o cartão certo.

Obrigado a @Douglasymlai por reconstruir Skills e Connectors como superfícies de coleção e detalhe no PR #1896, e a @4pmtong pela revisão.

Skills agora é um painel no estilo biblioteca. Cada Skill abre em uma visão de detalhe própria que mostra de onde ela veio, que acesso possui, se está habilitada e quais arquivos contém. Connectors segue o mesmo modelo: uma visão geral da coleção, um fluxo para adicionar e explorar, e um cabeçalho de perfil com ícone, nome, origem e a ação de instalar ou salvar.

Novidades:

• Painel de biblioteca de Skills — navegue pelas suas Skills como uma coleção, não como uma pilha de cartões de configuração
• Visões de detalhe de Skill — tags de origem e acesso, estado de habilitação e navegador de arquivos em um só lugar
• Coleção e descoberta de Connectors — um caminho mais claro entre explorar conectores disponíveis e configurar um
• Cabeçalho de detalhe do conector — ícone, nome, origem e ação de instalar ou salvar apresentados como um perfil
• Barras laterais de detalhe — o contexto de apoio permanece ao lado do recurso que você está inspecionando

A diferença prática é a inspeção. Você consegue responder "de onde veio esta Skill, o que ela alcança e o que há dentro dela" sem sair da página em que começou.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1896

---

🏠 Um único shell de página para Home, Skills e Connectors

Consistência é um recurso quando você navega pelo mesmo aplicativo todos os dias.

O v1.0.4 unifica Home e Configurações em um único shell de página construído com primitivas compartilhadas: uma barra de ferramentas de coleção, uma trilha de navegação, um trilho de conteúdo e um cabeçalho de retorno na barra lateral. As listas do hub da Home, os estados vazios e as abas de detalhe de Space agora seguem o mesmo layout de coleção usado por Skills e Connectors.

Melhorias:

• Layouts compartilhados — o mesmo cabeçalho, trilha e trilho de leitura em Home, Skills e Connectors
• Listas de coleção consistentes — listas do hub e abas de detalhe de Space seguem um único modelo de layout
• Estados vazios mais claros — uma superfície não configurada se explica em vez de exibir um painel em branco
• Navegação previsível — trilhas e cabeçalhos de retorno se comportam igual em qualquer lugar

Uma vez que o shell é compartilhado, mover-se entre Home, um Space, uma Skill e um Connector deixa de exigir que você reaprenda a página a cada vez.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1896

---

🔁 Trabalho multiturno que mantém suas instruções

Uma tarefa longa é uma cadeia de turnos, e cada turno precisa das mesmas instruções confiáveis.

Obrigado a @4pmtong por corrigir as falhas do Prompt Guard em requisições encadeadas da Responses API no PR #1883.

A primeira requisição da cadeia funcionava, e foi por isso que a regressão passou despercebida. As requisições seguintes reutilizavam previous_response_id, mas as instructions de nível superior não eram levadas adiante automaticamente — então o prompt de agente confiável sumia silenciosamente no meio da execução.

Correções:

• Instruções em cada requisição — o prompt de agente confiável é enviado nas instructions da Responses API a cada turno, não apenas no primeiro
• Sem conteúdo de prompt duplicado — itens system e developer são removidos da entrada depois de promovidos a instructions, evitando tokens e cobrança duplicados
• Prompt Guard intacto — a mensagem de rejeição existente para prompts não confiáveis é preservada

É o tipo de bug que só aparece com a duração. Tarefas curtas pareciam bem; a falha morava no terceiro turno.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1883

---

🧰 Ferramentas com esquemas de parâmetros dinâmicos

Nem toda ferramenta tem forma fixa, e a validação estrita de esquema não deveria rejeitar as que não têm.

Obrigado a @fengju0213 por atualizar camel-ai[eigent] para 0.2.91a7 e renovar o lockfile do backend no PR #1897.

A nova versão do CAMEL inclui o fallback de esquema estrito necessário para parâmetros de ferramenta que contêm mapeamentos abertos. Com ele, PlanningWorktreeToolkit.planning_exit_plan_mode mantém seu additionalProperties com valor de esquema e é emitido com strict: false, evitando uma resposta 400 do provedor e preservando os campos de dicionário dinâmicos de que a ferramenta realmente precisa.

Ferramentas com parâmetros abertos agora funcionam com provedores que impõem esquemas estritos, em vez de falhar no momento da chamada.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1897

---

🌿 Repositórios aninhados dentro de Spaces com Git

O v1.0.3 deu aos Spaces um histórico de versões respaldado por Git. O v1.0.4 faz esse histórico sobreviver a uma tarefa que clona um repositório dentro de um deles.

Obrigado a @4pmtong por dar suporte a repositórios aninhados nos checkpoints do workspace no PR #1902.

O Git reporta um repositório aninhado não rastreado como uma única entrada de diretório, do tipo ?? child-repository/. O pipeline de checkpoint normalizava esse caminho para child-repository, o que fazia a validação de caminhos falhar depois que a clonagem já havia terminado — o resultado da ferramenta era marcado como desconhecido e a execução falhava.

Correções:

• Repositórios aninhados são fronteiras independentes — uma raiz Git aninhada, não rastreada e verificada fica fora do checkpoint e do estado do repositório pai
• Sem gitlink implícito nem edição de arquivos de ignore — o repositório pai não é reestruturado silenciosamente para acomodar o filho
• O estado do pai não muda — HEAD, token de estado e caminhos rastreados permanecem intocados quando o checkpoint termina
• O conteúdo do filho permanece intacto — o repositório aninhado e seus commits são preservados
• A segurança do worktree é mantida — worktrees isolados não são limpos enquanto contiverem um repositório aninhado sem merge

Clonar um repositório dentro de um Space é trabalho de agente comum. Depois desta versão, isso não encerra mais a execução.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1902

---

🔌 Estados de conector que combinam com o runtime

Um conector que informa o estado errado é pior do que um que não informa nada.

Duas correções de @4pmtong tratam os dois lados do mesmo problema.

A busca na web ficava escondida justamente quando precisava ser configurada. Para quem usava um modelo padrão personalizado, a busca na web contava como desconectada até habilitar o Querit ou configurar credenciais do Google Search — e a visão geral de Connectors filtrava todos os conectores integrados desconectados. Como essa linha também é a porta de entrada do painel de configurações, essas pessoas não tinham nenhuma forma de configurá-la. Agora a busca na web permanece visível e mostra seu estado real como Não conectado, enquanto modelos gerenciados mantêm o estado Conectado. A filtragem continua igual para os demais conectores integrados desconectados.

O Slack aparecia como conectado sem estar. No modo hospedado, a interface de configurações tratava a presença de um grupo local de configuração do Slack como uma conexão válida, mas tarefas hospedadas executam ações do Slack pelo Connector Gateway — onde a mesma pessoa pode não ter conexão nenhuma com o Slack. O resultado era um selo de conectado seguido de um erro de conexão não encontrada em tempo de execução. Conectores integrados cujo fluxo de novo usuário pertence ao Connector Gateway agora seguem uma política centralizada: com o Gateway habilitado, o Slack integrado é ocultado da página de Connectors, do seletor de conectores do chat e da seleção de ferramentas de um novo Worker. Com o Gateway desabilitado, o Slack integrado continua disponível para runtimes apenas locais.

Nos dois casos, a execução do toolkit do Slack, a configuração armazenada, a compatibilidade dos Workers salvos e as credenciais dos gatilhos do Slack seguem funcionando.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1890

🔗 PR: https://github.com/eigent-ai/eigent/pull/1892

---

🖥️ Encerramento limpo quando a última janela fecha

Fechar o aplicativo deveria encerrar o aplicativo.

Obrigado a @4pmtong por corrigir o ciclo de vida de encerramento no PR #1891. Fechar a única janela agora encerra o Eigent de forma limpa em todas as plataformas, e desliga o backend local junto.

Correções:

• Um único caminho de saída — o fechamento nativo da janela, o IPC de fechamento e o comando de menu Fechar janela passam todos pelo mesmo fluxo protegido quit-app
• macOS também encerra na última janela — window-all-closed agora encerra no macOS além de Windows e Linux, para que before-quit limpe o backend local
• Desmontagem segura — a referência vinculada a webContents é mantida em vez de lida de um BrowserWindow já destruído
• Objetos destruídos são ignorados — a remoção de listeners é pulada para janelas e web contents destruídos, e as referências do coordenador são liberadas antes da desmontagem

Quem desenvolve ganha o mesmo: npm run dev agora termina em vez de deixar um backend rodando atrás de uma janela fechada.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1891

---

🧹 Tarefas de geração web que terminam de forma confiável

Algumas tarefas de geração web não terminavam. A causa acabou sendo duas coisas ao mesmo tempo.

Obrigado a @4pmtong pela correção segura para a versão no PR #1907.

O Eigent não precisa mais enviar conteúdo gerado ao antigo serviço de deploy remoto, então o Web Deploy Toolkit sai da montagem do Developer Agent do Workforce e do agente único, e as menções a deploy saem do prompt do Developer Agent, da descrição do coordenador do Workforce e das listas de capacidades do fluxo de trabalho. Configurações legadas que ainda pedem web_deploy.enabled=true são ignoradas. web_deploy_toolkit.py e seu suporte histórico de renderização permanecem no código para eventual uso futuro.

A segunda causa era de tempo. O orçamento de checkpoint da limpeza de segundo plano do terminal passa de 5 para 30 segundos, dando espaço para um servidor de preview parado liberar sua concessão de escrita e concluir o checkpoint Git do workspace antes de a execução ser finalizada.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1907

---

⚙️ Guardrails mais rápidos para quem contribui

CI lento é um imposto sobre todo mundo que abre um pull request.

O job de guardrails do frontend costumava levar de 20 a 30 minutos porque rodava a suíte completa do Vitest para o commit base e o do pull request com cache desativado, e depois repetia as falhas contra uma baseline que já continha falhas conhecidas e timeouts de 29 segundos.

Obrigado a @4pmtong por substituir essa comparação de suíte completa por um runner focado no PR #1898.

Melhorias:

• Runner de testes alterados — só os arquivos de teste de frontend adicionados ou atualizados pela mudança são executados
• Verificações rápidas primeiro — tipos, Electron, design system e formatação rodam antes do Vitest
• Execuções superadas são canceladas — um novo push cancela a execução anterior do workflow Test para o mesmo pull request ou branch
• Timeout menor — o orçamento de guardrails do frontend cai de 30 para 15 minutos

Em uma repetição contra a mudança mesclada pelo PR #1891, o runner de testes alterados executou 4 arquivos de teste e 134 testes em 1,07 segundo.

🔗 PR: https://github.com/eigent-ai/eigent/pull/1898

---

🔁 Compatibilidade com o trabalho existente

Spaces, Sessions, tarefas, configurações de Skill, Workers salvos e configurações de conector existentes continuam disponíveis após a atualização para o v1.0.4. A experiência padrão não exige configuração adicional.

Integrações apenas locais são explicitamente preservadas. Com o Connector Gateway desabilitado, o Slack integrado, os Workers salvos e os gatilhos do Slack continuam funcionando, e a configuração armazenada do Slack permanece intocada nos dois modos.

---

❤️ Um workspace que se explica sozinho

O Eigent v1.0.4 entrega:

• Skills como painel de biblioteca com visões de origem, acesso, habilitação e detalhe de arquivos
• Connectors como fluxo de coleção, descoberta e detalhe de perfil
• Um shell de página compartilhado com trilhas, barras laterais, trilhos de conteúdo e estados vazios consistentes em Home, Skills e Connectors
• Instruções de agente confiáveis preservadas entre turnos encadeados da Responses API, sem conteúdo de prompt duplicado
• Compatibilidade com esquemas estritos para ferramentas com parâmetros dinâmicos
• Repositórios Git aninhados tratados como fronteiras independentes nos checkpoints do workspace
• Busca na web que continua visível enquanto ainda precisa de configuração
• Slack apresentado pelo caminho de conector que de fato vai executá-lo
• Encerramento limpo do aplicativo e do backend local quando a última janela fecha
• Conclusão mais confiável de tarefas de geração web e limpeza de processos em segundo plano
• Um guardrail de CI de frontend que roda em minutos em vez de meia hora

O tema desta versão é legibilidade. Um painel diz o que uma Skill alcança. Um estado de conector diz qual runtime vai executá-lo. Um checkpoint diz qual repositório é dono de uma mudança. E uma tarefa que roda por muito tempo mantém as instruções com que começou.

Trabalho que você pode inspecionar é trabalho em que você pode confiar.

🔗 Versão: https://github.com/eigent-ai/eigent/releases/tag/v1.0.4

🔗 Registro completo de mudanças: https://github.com/eigent-ai/eigent/compare/v1.0.3...v1.0.4

Vamos continuar construindo.