Workers, QA e preview: o que roda depois do brief

O brief aprovado é o contrato. A partir daí o Manager deixa de perguntar e passa a enfileirar papéis: worker, QA, reviewer, CI. Você continua no mesmo fio da issue — só que o trabalho pesado sai do seu teclado.

Workers no worktree certo

Cada run abre um worktree na branch da issue. Claude, Codex ou Cursor recebem o PRD, as skills do papel e a regra dura: PR pequeno, commits convencionais, nada de merge em main nem escrita no CMS de produção.

O resultado esperado é código no GitHub, não um dump no chat. Se o worker precisa de preview, ele registra a PR; o deploy em si fica para o estágio seguinte.

Playwright nos dois viewports

A suíte sobe o public/ com um server estático (ou aponta para PREVIEW_URL no pipeline). Desktop Chrome e Pixel 7 rodam os mesmos casos: status 200, hierarquia, overflow e ausência de 5xx.

Se o teste verde depende de um seletor frágil da landing antiga, o blog quebrou o contrato — e isso é bom: o QA força o escopo a ficar explícito.

Preview no Cloudflare Pages

O site continua estático. Sem servidor de aplicação, sem login, sem área admin. O preview é a mesma pasta public/ que você serve local com:

npx serve -l 4173 public

Em produção, URLs antigas da landing precisam de decisão explícita (redirect ou aposentadoria). O sitemap e o RSS do blog passam a ser a fonte de verdade para indexação.

O que você ainda aprova

• O brief, antes de qualquer linha de código.
• O preview, antes de promover para produção.

Entre os dois pontos, o Manager orquestra. É isso que significa “agentes por baixo”: você não some do fluxo — só deixa de ser o executor de cada etapa.