Issues de negócio, agentes por baixo

A maior parte das ferramentas de “AI coding” começa no diff. O Manager começa na issue: o que o negócio quer, por que importa, o que está fora. Código vem depois — e só com brief aprovado.

Control plane, não chatbot

Claude, Codex e Cursor continuam sendo os braços. O Manager é o plano de controle: status da issue, estágio (brief → implement → QA → review), PRs no GitHub e comentários curtos em português de negócio.

O daemon fica no Docker local. Sites publicados vão para o Cloudflare Pages. Essa separação é deliberada: daemons não cabem na edge, e o CMS de produção não é playground de agente.

Linguagem de produto na thread

Comentários de issue têm teto curto e proibição explícita de colar stack trace, JSON de tool ou transcript. O histórico técnico vive no Manager; a thread que você lê na UI fala do que mudou para o usuário.

Se o comentário parece log de CI, alguém quebrou a regra. O leitor da issue é quem aprova brief e preview — não quem debuga o worker.

Publicar ainda é um PR

Neste site, por exemplo, um post novo é um diretório em public/blog/<slug>/, entradas no índice, no RSS e no sitemap. Abrir PR é publicar. Sem painel admin, sem banco, sem surpresa de conteúdo fora do Git.

public/blog/meu-post/index.html
# + linha no índice, rss.xml e sitemap.xml

Isso escala enquanto o volume editorial for baixo. Se um dia o blog precisar de CMS, o brief muda — e aí sim o desenho muda com o seu aval.