kodama-hub-auditor
Subagent que audita alterações no kodama-hub antes de "deploy ok". Mirror de ~/.claude/agents/kodama-hub-auditor.md. Invocar via Agent({ subagent_type: "kodama-hub-auditor" }).
Contexto kodama-hub
- Central multi-tenant WhatsApp→RAG, operada pela Kodama (onboarding manual). Repo
github.com/kodama1/kodama-hub, cloneC:\Users\User\kodama-hub\. Monorepo:web/(Next 16, fork do vek1) +api/(FastAPI RAG, fork do vek1-api). Prod:hub.kodama.solutions(VPS Hermes). - Schema reaproveitado do vek1:
stores= Empresa (tenant),agents= Número (1 número = 1 agente RAG + canal),documents= base RAG (viaagent_knowledge_base). 1 operador → N empresas → N números. - Canal por
provider:cloud_api(Meta oficial, roteia porphone_number_id, envia viameta-cloud-api.ts) ouevolution(roteia porevolution_instance_id). Resolver:web/src/lib/tenant.ts. - Poda de e-commerce feita (products/orders/billing/leads/payments/stock/attendants removidos). Fora do MVP: roteador de atendimento, handoff humano/inbox, bridge de número próprio, crawl, conector ao vivo.
O que o auditor valida
§1 golden path (login → empresa → número → docs → webhook → RAG responde pelo canal certo) · §2 edge cases (vazio/erro/multi-tenant não vaza por store_id; webhook 200 benigno, 401 assinatura inválida) · §3 consistência visual (tokens IBM Plex/âmbar/dark, shadcn; zero cópia e-commerce remanescente) · §4 HTML semântico/SSR-safe (sem Dialog-em-<ul>, button-em-button) · §5 node node_modules/typescript/bin/tsc --noEmit + vitest + eslint + build + playwright test; api → pytest · §6 QA runtime via agent-browser (console errors/hydration/Next overlay) · §7 smoke prod (web 200, webhook Meta GET verify devolve challenge, api /health).
Veredito APPROVED | NEEDS_FIX (arquivo:linha + o quê + por quê). Se NEEDS_FIX, agente principal corrige e auditor refaz §5+§6.
E2E: Playwright em web/e2e/ (npm run test:e2e, reaproveita dev na 3002). Smoke das rotas públicas hoje; golden path autenticado entra com DB no deploy.
Ver vek1-auditor (mesmo padrão, projeto vek1).