Board de tarefas

Entregue em 2026-10-25 e já na main. O load-balance, o motor e o servidor do mypanel ganharam ESLint flat (eslint.config.js) e Prettier, com os scripts lint, lint:fix, format e format:check. A regra de fronteira proíbe a rota de importar o ORM, tanto no import estático quanto no import() dinâmico. Ela entrou como aviso, porque a dívida existe: em vez de ninguém perceber, o lint agora lista cada rota que fala direto com o banco. Zerar essa lista e promover a regra a erro, como o render fez, é o passo seguinte. Na mesma entrega vieram o projectService: false explícito, sem o qual os erros de parsing voltam por variável de ambiente, e a saída do eval do logger do load-balance (TB-30).

• Estado: feito
• Apps: load-balance motor mypanel
• Esforço: barato · impacto: alto
• Fase: Fase 1 — Fundação executável
• Origem: recomendação 1 da auditoria
• Evidência no disco: load-balance/backend/eslint.config.js · motor/backend/eslint.config.js · mypanel/packages/server/eslint.config.js

O backend do render já emite a spec (scripts/openapi-spec.ts) e o frontend já declara o @hey-api/openapi-ts, mas ninguém consome a spec. Faltam o openapi-ts.config.ts, a pasta src/api/generated/ e os scripts api:spec, api:gen e api:check. Copie o par do agent-package: o cliente do frontend passa a nascer da API real, e o api:check reprova quando os dois divergem. É trocar a planilha copiada à mão pela consulta ligada na fonte.

• Estado: a fazer
• Apps: render
• Esforço: barato · impacto: médio
• Fase: Fase 2 — Contrato e dados
• Origem: recomendação 2 da auditoria
• Evidência no disco: render/backend/scripts/openapi-spec.ts · render/frontend/package.json · agent-package/frontend/openapi-ts.config.ts

O conta-central, o load-balance e o motor não têm README na raiz. Pior que faltar é descrever o que não existe: o README do frontend do load-balance cita pastas e um stack (Sonner) ausentes, o do frontend do motor descreve Astryx, StyleX e FSD, já removidos, e o components/ui/README.md do conta-central documenta componentes que o barrel não expõe. O backend/README.md do agent-package aponta para um ../AGENTS.md que não entrou no monorepo, e o gate docs:check do render estoura ENOENT dentro do próprio gerador.

Escala medido em 2026-10-26: não é só o docs:check — o npm run test morre também. O gerador lê quatro documentos que não estão no git e não estão ignorados (ausência simples, conferido com git ls-files): agent-package/AGENTS.md, agent-package/README.md, agent-package/CHANGELOG.md e agent-package/backend/docs/mcp-server.md. Em qualquer clone limpa o tests/docs-gen.test.ts cai com ENOENT — a suíte do agent-package não passa na máquina de quem nunca tocou naqueles arquivos à mão (medido: 2 suítes falham onde elas não existem, 1 onde existem). Versionar os quatro resolve o teste e o docs:check de uma vez. Crie os pontos de entrada, regenere os READMEs a partir da árvore real e ponha o docs:check de volta no verde.

• Estado: a fazer
• Apps: conta-central load-balance render motor agent-package
• Esforço: barato · impacto: alto
• Fase: Fase 0 — Estancar
• Origem: recomendação 3 da auditoria
• Evidência no disco: load-balance/frontend/README.md · motor/frontend/README.md · conta-central/frontend/src/components/ui/README.md · agent-package/backend/README.md · agent-package/backend/tests/docs-gen.test.ts · agent-package/backend/scripts/lib/docs-files.ts · render/backend/scripts/lib/docs-gen.ts

A auditoria contava o kit no agent-package: pre-commit com gitleaks, .gitleaks.toml e renovate.json. No monorepo, só o renovate.json chegou; o .pre-commit-config.yaml e o .gitleaks.toml nunca entraram no git da casa. Hoje nenhum app tem varredura de segredo, e o gitleaks que o CLAUDE.md pede não tem config para rodar. Como o monorepo é um repositório só, hook de git e config do Renovate valem por repositório: instale o kit uma vez, na raiz, cobrindo os 6 apps. Foi esse buraco que deixou dois tokens entrarem no .mcp.json (TB-29). No render, resolva também a referência morta ao pre-commit no backend/knip.json.

• Estado: a fazer
• Apps: spaceAI agent-package render
• Esforço: barato · impacto: alto
• Fase: Fase 0 — Estancar
• Origem: recomendação 4 da auditoria
• Evidência no disco: agent-package/renovate.json · render/backend/knip.json · CLAUDE.md

O load-balance (backend e frontend) e o mypanel (server e web) não têm nenhuma das três fechaduras: rodam como root, sem HEALTHCHECK e com base flutuante, e o web do mypanel sobe o nginx:alpine como root. O motor está no meio do caminho: o backend já tem USER e HEALTHCHECK, mas a base não tem digest, e o frontend roda o nginx como root, com a justificativa num comentário. Aplique USER não-root e HEALTHCHECK onde faltam (GET /health/live, como no agent-package), troque o nginx do mypanel pelo nginx-unprivileged e fixe o digest das bases, que é mecânico e sai em lote. Sem healthcheck, o orquestrador nunca sabe quando o container está pronto.

• Estado: a fazer
• Apps: load-balance mypanel motor
• Esforço: barato · impacto: alto
• Fase: Fase 0 — Estancar
• Origem: recomendação 5 da auditoria
• Evidência no disco: load-balance/backend/Dockerfile · mypanel/packages/server/Dockerfile · mypanel/packages/web/Dockerfile · motor/backend/Dockerfile

Os 5 frontends que usam o kit apontam para três refs: a tag v1.13.5 (agent-package, render e motor) e dois SHAs (conta-central e load-balance), que resolvem para duas versões em circulação, 1.13.5 e 1.13.7. Fixe um pin só. A auditoria recomenda a tag v1.13.5, já majoritária; como o conta-central e o load-balance estão na 1.13.7, confira antes o diff de API do createHttpClient e do createQueryClient. Na mesma tarefa, registre /health, /health/live e /health/ready nos 6 backends, com os paths atuais como alias, e escreva no mypanel que ele é a exceção do design system.

• Estado: a fazer
• Apps: conta-central load-balance motor mypanel
• Esforço: barato · impacto: médio
• Fase: Fase 0 — Estancar
• Origem: recomendação 6 da auditoria
• Evidência no disco: conta-central/frontend/package.json · load-balance/frontend/package.json · motor/frontend/package.json

No agent-package e no render, só src/config/ lê process.env, e uma regra de ESLint garante isso. Nos outros 4 backends a leitura está espalhada: cerca de 30 pontos no load-balance e quase 20 diretórios no motor. Concentre as leituras num módulo com schema zod (o motor ainda valida à mão) e ligue a regra de ESLint com lista de pendências, para não quebrar o build de uma vez. Só então gere o .env.example a partir do schema. Trocar uma variável hoje vira caça ao tesouro, e o .env.example do motor tem 92 chaves, tamanho em que é fácil documentar uma que o código nem lê.

• Estado: a fazer
• Apps: load-balance motor mypanel conta-central
• Esforço: médio · impacto: alto
• Fase: Fase 2 — Contrato e dados
• Origem: recomendação 7 da auditoria
• Evidência no disco: load-balance/backend/src/config/env.ts · motor/backend/src/env.ts · mypanel/packages/server/src/config.ts · agent-package/backend/src/config/env.ts

Só o agent-package e o render respondem erro em application/problem+json. Os outros 4 têm cada um o seu formato, e todo cliente HTTP precisa saber com qual backend está falando. Migre os 4 em ordem de esforço: primeiro o conta-central e o mypanel, cujo envelope de erro e mensagem é trivial de converter, depois o load-balance e o motor. Mantenha error e message como apelidos durante a transição, como o agent-package já faz, e faça rota nova nascer no envelope padrão.

• Estado: a fazer
• Apps: conta-central mypanel load-balance motor
• Esforço: médio · impacto: alto
• Fase: Fase 2 — Contrato e dados
• Origem: recomendação 8 da auditoria
• Evidência no disco: agent-package/backend/src/plugins/problem-details.ts · conta-central/backend/src/plugins/errorHandler.ts · load-balance/backend/src/plugins/errorHandler.ts

Só o agent-package e o render medem cobertura (coverage-floor.json) e procuram código morto (knip). Nos outros 4 nenhum config de teste tem threshold, então uma queda de 30 pontos de cobertura passa em silêncio. O mínimo útil não é copiar o piso por diretório: é um test:coverage com threshold global, começando em 40% e subindo, ligado ao gate de cada projeto. Some o knip onde o alvo já é conhecido: o pacote compartilhado morto do mypanel e os scripts .mjs do motor que ficam fora do typecheck.

• Estado: a fazer
• Apps: conta-central load-balance motor mypanel
• Esforço: médio · impacto: médio
• Fase: Fase 1 — Fundação executável
• Origem: recomendação 9 da auditoria
• Evidência no disco: agent-package/backend/coverage-floor.json · agent-package/backend/knip.json · motor/package.json

Três topologias convivem: pacotes irmãos sem workspaces (4 apps), npm workspaces no motor, com três lockfiles, e pnpm workspaces no mypanel, que ainda guarda um package-lock.json ao lado do pnpm-lock.yaml. Com dois locks de gerenciadores diferentes na mesma raiz, nenhum install reproduz a árvore testada. A TB-01 atualizou só o pnpm-lock.yaml, então o package-lock.json do mypanel ficou mais velho. Escreva a decisão num ADR e apague o lockfile que sobra; se a casa não for de workspaces, registre o motor e o mypanel como exceções explícitas.

• Estado: a fazer
• Apps: motor mypanel
• Esforço: médio · impacto: médio
• Fase: Fase 3 — Decisões estruturais
• Origem: recomendação 10 da auditoria
• Evidência no disco: mypanel/package-lock.json · mypanel/pnpm-lock.yaml · motor/package.json

No motor, no conta-central, no load-balance e no mypanel, o frontend espelha as rotas do backend à mão, e o drift já aconteceu: o README do frontend do load-balance descreve pastas que não existem. Depois do render (TB-02), aplique a mesma geração ao REST do motor, que já tem gate de deriva no catálogo WS, e então aos outros 3. Onde gerar ainda for caro, o piso é um teste de paridade entre o catálogo do frontend e as rotas do backend; o load-balance já tem o precedente, topbarModelParity.test.ts.

• Estado: a fazer
• Apps: motor conta-central load-balance mypanel
• Esforço: alto · impacto: alto
• Fase: Fase 2 — Contrato e dados
• Origem: recomendação 11 da auditoria
• Evidência no disco: motor/frontend/src/api/routes.ts · load-balance/frontend/src/api/routes.ts · agent-package/frontend/src/api/generated/

No conta-central, 13 componentes locais em src/components/ui/ fazem sombra ao @nomad/ui oficial: 108 arquivos importam o kit local, contra 37 que importam o pacote. Migre-os para o kit, com no máximo um barrel fino, como o motor faz. Adote features/<domínio>/ nas features novas do render e do mypanel, sem reverter o que existe, e junte as pastas duplicadas do motor: workflow com workflows e webhook com webhooks. É como ter duas pastas, Conta e Contas, no mesmo armário: o defeito é de nome, mas todo mundo abre a errada.

• Estado: a fazer
• Apps: conta-central render mypanel motor
• Esforço: médio · impacto: médio
• Fase: Fase 3 — Decisões estruturais
• Origem: recomendação 12 da auditoria
• Evidência no disco: conta-central/frontend/src/components/ui/ · motor/frontend/src/features/workflow/ · motor/frontend/src/features/workflows/

As pastas do motor se chamavam be e fe e agora se chamam backend e frontend nos scripts e nos workspaces da raiz, nos 3 contexts do compose, no import de teste que tinha quebrado, nos testes que liam paths e no gerador do catálogo. Os nomes de serviço be e fe continuam só dentro do compose. Ficou de fora o WorkingDirectory dos units do systemd, que ainda aponta para .../motor/be: isso é a TB-17.

• Estado: feito
• Apps: motor
• Esforço: barato · impacto: médio
• Fase: fora do roadmap: já estava feita quando ele foi montado
• Origem: verificação em código depois do rename
• Evidência no disco: motor/package.json · motor/compose.prod.yml

A casa tem um documento canônico na raiz, o AGENTS.md, que declara a regra da casa em caixa alta: OS APPS SOBEM JUNTOS, NUM COMPOSE GERAL. OS BANCOS FICAM FORA, NUMA STACK PRÓPRIA. O CLAUDE.md da raiz é o resumo curto que aponta para ele.

• Estado: feito
• Apps: spaceAI
• Esforço: barato · impacto: alto
• Fase: fora do roadmap: já estava feita quando ele foi montado
• Origem: documentos da casa
• Evidência no disco: AGENTS.md · CLAUDE.md

O teste de Dockerfiles do motor reprova se o backend copiar o frontend para dentro da imagem da API: a regex pega os dois nomes, fe e frontend. É o cadeado que impede misturar a cozinha com a sala.

• Estado: feito
• Apps: motor
• Esforço: barato · impacto: médio
• Fase: fora do roadmap: já estava feita quando ele foi montado
• Origem: teste dockerfiles.test.ts
• Evidência no disco: motor/backend/src/config/dockerfiles.test.ts · motor/backend/Dockerfile

O gate autoritativo do motor é o npm run gates da raiz: check-lock da raiz e do frontend, typecheck, lint, test, build e cycles, nessa ordem. Rodar do zero funciona: o npm ci instala as duas workspaces e o gate chega inteiro até test (medido em 2026-10-27, com check-lock, typecheck, lint, build e cycles verdes). O que não fecha é a suíte: o backend leva ~2 h contra o Postgres de dev e é morto pelo timeout antes de terminar, e sobram 18 testes vermelhos por ambiente, por expectativa defasada e por dado. A parte que falta está na TB-33; aqui fica o registro do gate completo rodado do zero, com o output colado na mensagem de merge.

• Estado: a fazer
• Apps: motor
• Esforço: médio · impacto: alto
• Fase: Fase 1 — Fundação executável
• Origem: verificação em código: o gates sem node_modules
• Evidência no disco: motor/package.json · motor/CLAUDE.md

Os dois units versionados no repo, motor-api.service e motor-worker.service, ainda têm WorkingDirectory=/home/myke/projetos/vps/motor/be. Quando a VPS puxar o código novo, a pasta vira backend e os dois serviços não sobem. Corrija os dois arquivos e reinstale os units na VPS. É como mudar de rua e esquecer de avisar o GPS.

• Estado: a fazer
• Apps: motor
• Esforço: barato · impacto: alto
• Fase: Fase 0 — Estancar
• Origem: verificação em código: WorkingDirectory com /be
• Evidência no disco: motor/backend/deploy/motor-api.service · motor/backend/deploy/motor-worker.service

O backend tem um Dockerfile.worker que ninguém usa: nenhum arquivo do repo o cita, e o worker do compose sobe pelo Dockerfile normal, com o comando npm run worker. Decida entre apagar o arquivo ou passar a usá-lo. Arquivo órfão é o que alguém edita achando que vale para produção.

• Estado: a decidir
• Apps: motor
• Esforço: barato · impacto: médio
• Fase: Fase 3 — Decisões estruturais
• Origem: verificação em código: Dockerfile.worker sem referência
• Evidência no disco: motor/backend/Dockerfile.worker · motor/compose.prod.yml

A pasta virou frontend, mas o pacote ainda se chama motor-fe (o do backend se chama motor-agent). Decida se o nome do pacote acompanha a pasta ou fica como está.

• Estado: a decidir
• Apps: motor
• Esforço: barato · impacto: baixo
• Fase: Fase 3 — Decisões estruturais
• Origem: verificação em código: pacote motor-fe
• Evidência no disco: motor/frontend/package.json · motor/backend/package.json

O código do kit está em nomad-ui/, na versão 1.13.7, mas ninguém o consome: os 5 frontends que usam o @nomad/ui baixam do GitHub remoto. Decida se ele vira workspace ou segue como espelho do remoto, com regra de sincronia escrita. Enquanto nada for decidido, o pin é a única fonte de verdade, e mexer em nomad-ui/ é mudança não versionada.

• Estado: a decidir
• Apps: spaceAI
• Esforço: médio · impacto: médio
• Fase: Fase 3 — Decisões estruturais
• Origem: escolha em aberto no AGENTS.md
• Evidência no disco: nomad-ui/package.json · AGENTS.md

A casa pede Node 24 para app novo, e o motor declara >=22.13.0 <23 no engines e constrói em node:22.23-alpine. Decida se migra agora, se agenda a migração ou se congela a exceção por escrito. É como a casa toda no 220 V e um cômodo ainda no 110 V. O conta-central tem a mesma dívida na imagem (node:22-alpine) e cabe na mesma decisão.

• Estado: a decidir
• Apps: motor
• Esforço: alto · impacto: médio
• Fase: Fase 3 — Decisões estruturais
• Origem: engines do motor divergente da casa
• Evidência no disco: motor/package.json · motor/backend/Dockerfile · AGENTS.md

Entregue em 2026-10-26 na branch feature/tb-22-envelope-mcp (ADR-016). As seis gramáticas de resposta fecharam: toda built-in devolve { ok, data | error, meta: { tool, version } }, selado num ponto só — o despacho (mcp/tool-call.ts) — e não em cada wrapper, para a exceção não escapar do envelope. A versão saiu do APP_VERSION global e virou campo obrigatório da tool, publicada nos dois lugares: _meta.version no tools/list e meta.version na resposta. A trava do bump lê um snapshot único (tests/__snapshots__/mcp-tools.json, 236 tools, dois hashes por tool — contract com a prosa, schema sem ela) e a catraca foi travada em 4791 → 4724 avisos. O caminho selado tem teste real pelo POST /mcp (mcp-envelope-seal.test.ts: sucesso, imagem, falha de negócio, exceção de infra e de domínio, mais a prova de que a proxied não é envelopada). O que ficou aberto está no PADRAO-MCP.md §8: recorte em vez de varredura das 236, outputSchema 0 de 236, e as 23 descrições que ainda prometem a forma velha.

• Estado: feito
• Apps: agent-package render
• Esforço: médio · impacto: alto
• Fase: Fase 4 — O padrão MCP da casa
• Origem: medição do agent-package como molde MCP
• Evidência no disco: agent-package/backend/src/mcp/tool-kit.ts · agent-package/backend/src/mcp/tool-call.ts · agent-package/backend/tests/mcp-envelope-seal.test.ts · agent-package/backend/tests/__snapshots__/mcp-tools.json · agent-package/docs/adr/0016-mcp-envelope-unico-e-versao-por-tool.md · PADRAO-MCP.md

O gateway mede a latência de cada tool, mas ninguém conta quantas queries ela gasta, e N+1 é o bug que não aparece no teste e derruba o servidor quando o dado cresce. Some-se a isso a paginação, que discorda de si mesma em 7 arquivos e 8 combinações (medido em 2026-10-25): o guia manda padrão 50 / máximo 200; schemas/pagination.ts usa 500/1000; schemas/knowledge.ts e schemas/skills.ts usam 50/200; schemas/tasks.ts usa 100/1000; o pageShape do render e schemas/render.ts:11 usam 20/100; schemas/render.ts:173 usa 200/200; e routes/render.ts:215 usa 100/200. A lista completa está em PADRAO-MCP.md §8, fora do escopo. Exponha um contador de queries por chamada de tool, em métrica e dentro do envelope (meta.queries), e faça a paginação da casa valer em todo lugar — uma regra só, no guia, com os schemas citando ela.

• Estado: a fazer
• Apps: agent-package render mypanel motor load-balance conta-central
• Esforço: médio · impacto: alto
• Fase: Fase 4 — O padrão MCP da casa
• Origem: medição do agent-package como molde MCP
• Evidência no disco: agent-package/backend/src/mcp/instrument.ts · agent-package/backend/src/schemas/pagination.ts · agent-package/docs/api-guidelines.md

Sete services importam o mcp/, e nomes de tool estão escritos à mão dentro deles: 44 menções a agentpack_*, 22 nomes distintos, em 14 arquivos de services/. A dependência está ao contrário: quem manda é o service, e o mcp/ é o adaptador. A regra de lint barra o service de importar tool, mas não barra o caminho de volta. Inverta a dependência (o service expõe dado, o adaptador descobre) e trave isso na regra.

• Estado: a fazer
• Apps: agent-package
• Esforço: médio · impacto: médio
• Fase: Fase 4 — O padrão MCP da casa
• Origem: medição do agent-package como molde MCP
• Evidência no disco: agent-package/backend/src/services/task-context.service.ts · agent-package/backend/src/services/project-scope.ts · agent-package/backend/eslint.config.js

Nenhum app tem um agente coordenador com prompt próprio. O agent-package tem as instructions do initialize e dois prompts MCP (executar task e handover): é o começo, não o produto. A casa já tem a entidade AgentPrompt e a decisão do dono: cada app tem um coordenador, com o seu system prompt e a documentação das suas tools. Falta a peça escrita, app por app.

• Estado: a fazer
• Apps: agent-package motor render mypanel load-balance conta-central
• Esforço: médio · impacto: alto
• Fase: Fase 4 — O padrão MCP da casa
• Origem: decisão do dono
• Evidência no disco: agent-package/backend/src/mcp/instructions.ts · agent-package/backend/src/mcp/prompts.ts · agent-package/backend/prisma/schema.prisma

A casa pede Swagger em todo backend, gerado a partir das rotas. Dos 6 backends, só o do agent-package e o do render têm. Dos outros 4, três não têm nada (conta-central, load-balance e motor), e o servidor do mypanel tem um /api/docs escrito à mão em src/index.ts, que descreve 17 dos 23 endpoints. Doc escrita à mão envelhece a cada rota nova. Ligue o @fastify/swagger nos 4, com o plugin do agent-package como molde, e aposente o /api/docs manual.

• Estado: a fazer
• Apps: conta-central load-balance motor mypanel
• Esforço: médio · impacto: alto
• Fase: Fase 4 — O padrão MCP da casa
• Origem: decisão do dono
• Evidência no disco: mypanel/packages/server/src/index.ts · agent-package/backend/src/plugins/swagger.ts

O Swagger existe, mas 134 operações estão congeladas na lista FROZEN_PENDING_OPERATIONS desde 2026-09-26: a rota funciona, o contrato não. Além disso, 93 validações (Schema.parse(request.*)) acontecem dentro do handler em vez de na declaração da rota, e o cliente gerado não sabe o que a rota aceita. A lista só pode encurtar, nunca crescer: o openapi-contract.test.ts reprova operação pendente fora dela.

• Estado: a fazer
• Apps: agent-package
• Esforço: alto · impacto: alto
• Fase: Fase 4 — O padrão MCP da casa
• Origem: medição do agent-package como molde MCP
• Evidência no disco: agent-package/backend/tests/openapi-contract.pending.ts · agent-package/backend/tests/openapi-contract.test.ts

O padrão da casa é uma regra de negócio escrita uma vez, com dois adaptadores finos em cima: a rota REST e a tool MCP. O agent-package e o mypanel já são assim. Faltam 4: o motor consome MCP mas não expõe nenhum, o load-balance e o conta-central não têm MCP, e o render expõe tools pelo gateway do agent-package, sem servidor MCP próprio. Comece por um domínio piloto em cada app, depois o resto, medindo o N+1 a cada passo (TB-23).

• Estado: a fazer
• Apps: motor load-balance render conta-central
• Esforço: alto · impacto: alto
• Fase: Fase 4 — O padrão MCP da casa
• Origem: decisão do dono
• Evidência no disco: agent-package/backend/src/mcp/registry.ts · mypanel/packages/server/src/mcp/server.ts

O .mcp.json foi limpo em 2026-10-25 (commit 31f898d): os tokens agora vêm do ambiente, por MYPANEL_MCP_TOKEN e AGENTPACK_MCP_TOKEN, e o arquivo segue versionado como configuração do time. Falta a metade que limpar o arquivo não resolve: os dois tokens em texto puro, o do mypanel e o do agentpack, continuam no histórico desde o primeiro commit (084ec6f), legíveis para quem clona o repositório. O runbook de rotação do agent-package registra a decisão do dono para segredo que entrou no git: não reescrever o histórico, só rotacionar. Revogue os dois tokens, emita novos e registre o incidente numa task do AgentPack.

• Estado: a fazer
• Apps: spaceAI agent-package mypanel
• Esforço: barato · impacto: alto
• Fase: Fase 0 — Estancar
• Origem: execução da TB-01
• Evidência no disco: .mcp.json · agent-package/docs/ops/secret-rotation.md

Feito no mesmo commit da TB-01 (f87345f). O src/utils/logger.ts sondava o pino-pretty com eval('require'): em ESM o require não existe nesse escopo, o eval lançava ReferenceError, o catch devolvia false e o pino-pretty nunca era detectado, nem em dev. Trocado por createRequire(import.meta.url), como o config/logger.ts já fazia. O no-eval do lint novo é erro, e está certo: eval executa código.

• Estado: feito
• Apps: load-balance
• Esforço: barato · impacto: alto
• Fase: Fase 1 — Fundação executável
• Origem: achado do lint da TB-01
• Evidência no disco: load-balance/backend/src/utils/logger.ts

Depois da TB-22 a resposta de sucesso é { ok: true, data }: o que a tool produziu desceu um nível, para dentro de data. 23 descrições em 7 arquivos continuam descrevendo o formato antigo, no topo — o agente lê a descrição, procura o campo e não acha. Exemplos: core/knowledge.ts:70 («Returns { items, total, page, pageSize, pages }»), core/tasks.ts:271, render/catalog.ts:253. A distribuição: core/knowledge.ts (5), core/tasks.ts (6), core/skills.ts (5), core/memory.ts (2), core/prompts.ts (2), core/search.ts (2) e render/catalog.ts (grep -rn "Returns {" src/tools). Não é cosmético: a descrição é contrato publicado, entra no hash da trava do bump e, depois do envelope, mentir sobre a forma é o mesmo defeito que a TB-22 resolveu na gramática. Mexer nelas exige bump de versão e regeneração do snapshot no mesmo commit (npm run test:tool-snapshot).

• Estado: a fazer
• Apps: agent-package
• Esforço: barato · impacto: alto
• Fase: Fase 4 — O padrão MCP da casa
• Origem: dobra da TB-22 (PADRAO-MCP.md §8, item 10)
• Evidência no disco: agent-package/backend/src/tools/core/knowledge.ts · agent-package/backend/src/tools/core/tasks.ts · agent-package/backend/src/tools/core/skills.ts · agent-package/backend/tests/__snapshots__/mcp-tools.json

O mcp-envelope-seal.test.ts da TB-22 prova a forma do envelope com um recorte — cinco casos pelo POST /mcp (sucesso, imagem, falha de negócio, exceção de infra, exceção de domínio). Ele não prova que cada tool do registro obedece: um handler que monte o corpo à mão em vez de passar pelo jsonContent escaparia. Feche com um teste que itere o catálogo e aplique as mesmas asserções a toda built-in — o mesmo registro da trava do bump, então o custo é o da regeneração do snapshot.

• Estado: a fazer
• Apps: agent-package
• Esforço: barato · impacto: médio
• Fase: Fase 4 — O padrão MCP da casa
• Origem: dobra da TB-22 (PADRAO-MCP.md §8, item 8)
• Evidência no disco: agent-package/backend/tests/mcp-envelope-seal.test.ts · agent-package/backend/tests/support/tool-contract-snapshot.ts

O npm run gates do motor roda do zero (a TB-16 provou), mas a suíte é que não fecha. Medido em 2026-10-27: 3078 de 3093 testes de backend verdes em 7346 s (2 h), com 15 falhas em 9 arquivos; e 196 de 197 arquivos de frontend verdes, com 3 falhas. A suíte do backend leva ~2 h contra o Postgres de dev (fileParallelism: false, um arquivo por vez) e é morta pelo timeout da ferramenta antes de terminar — um gate que morre no timeout não reprova nem aprova nada.

As 15 falhas não são a mesma coisa e não se resolvem com um conserto só. 8 são de ambiente: os routes/workflows.l5 e tools/native/workflow.l5 esperam o worker no ar (o próprio arquivo avisa), e o realtime/socket-io/flag-desligada, o engine/abort-entre-processos, o engine/reaper-lideranca e o engine/turn-runner.lease-budget batem em prazo e em Redis. 3 são expectativa defasada: o config/texto-docs espera be/src/plugins/websocket.ts e o arquivo diz backend/src/...; o config/setup-from-org procura um org_config da org de teste canônica que não existe no banco de dev. 3 são de dado (queue/retention-cota-300-executa e workflows/needle-cancel-inflight dependem de fila real e de timing). E 3 são de frontend: ArchitecturePage.test.tsx (a regex fe/src contra o caminho real frontend/src) e chartCategorical.test.ts (timeout de 5 s).

A tarefa é fazer a suíte terminar dentro do limite: preparar o ambiente que os testes assumem (worker no ar, Redis de teste, org de teste semeada), corrigir as expectativas defasadas, e resolver o que for defeito de verdade. Mede-se pelo fim: o npm run gates do motor fecha sozinho, do zero, com o output inteiro colado na mensagem de merge.

• Estado: a fazer
• Apps: motor
• Esforço: médio · impacto: alto
• Fase: Fase 1 — Fundação executável
• Origem: medido no gate de 2026-10-27, na entrega do arquivar de setup
• Evidência no disco: motor/backend/vitest.config.ts · motor/backend/src/routes/workflows.l5.test.ts · motor/backend/src/realtime/socket-io/flag-desligada.test.ts · motor/backend/src/config/texto-docs.test.ts · motor/frontend/src/features/architecture/components/ArchitecturePage.test.tsx · motor/package.json