/dev-ship — Pronto é estado verificado, não sensação

Task ✅ ≠ feature ✅. Esta skill é a barreira entre "terminei as tasks" e "isso pode ir pra produção". Roda no fim de um PLAN.md ou standalone sobre qualquer diff que o usuário queira fechar.

Processo

1. Verificação dura (must_pass global)

Rode, na ordem, o que o projeto tiver (CLAUDE.md diz quais):

1. Typecheck / build
2. Suite de testes completa (não só os módulos tocados)
3. Lint

Qualquer vermelho para o ship aqui. Vermelho vira fix-task (ou /dev-fix) — nunca "é flaky, ignora".

2. Must-Haves do PLAN.md (goal-backward)

Se existe .plans/<feature>/PLAN.md:

• Truths: cheque cada behavior listado — idealmente via smoke test, não inspeção visual
• Artifacts: cada arquivo existe? min_lines? exports/contains corretos?
• Key Links: rode os regex declarados — devem casar
• Demo script: execute os passos. A feature demonstra em 60s ou não demonstra?

Falhou qualquer um → diagnostique por que a task "completed" não satisfez o goal, crie fix-task no PLAN.md, execute, re-verifique. Loop até verde. Não mascare.

3. Revisão do diff (você é o reviewer agora)

Leia o diff completo da feature (git diff <base>...HEAD ou working tree) com olhos de reviewer, não de autor:

Caçada a restos:

• console.log / print / dbg! de debug, prefixos [DEBUG-*]
• TODO/FIXME/HACK novos sem issue ou justificativa
• Código comentado, imports não usados, arquivos órfãos
• Dependência adicionada que só se usa em 1 linha trocável

Caçada a bugs de autor:

• Edge cases dos Goals que nenhuma task cobriu
• Error paths que engolem erro em silêncio (catch vazio)
• Async sem await / promise solta / race óbvia
• Off-by-one em paginação/slice/loop

4. Lente de segurança (só arquivos tocados)

Não é auditoria completa — é o mínimo que evita vergonha:

• Segredo/chave/token hardcoded? (inclusive em teste e fixture)
• Input externo chegando em query/comando/path sem validação?
• Endpoint novo sem auth/permissão onde os vizinhos têm?
• Dado sensível indo pra log?

Achou algo → severidade + fix antes do ship (ou flag explícito ao usuário se for aceito como risco).

5. SUMMARY.md + arquivamento

Escreva .plans/<feature>/SUMMARY.md:

• O que foi entregue (1 parágrafo)
• Commits envolvidos
• Decisões tomadas durante execução que não estavam no plano (copie de ## Decisions)
• Follow-ups deferidos (o que apareceu e ficou de fora — candidatos a próximo /dev-brainstorm)

Atualize o frontmatter do PLAN.md: status: done.

6. Entrega final

1 mensagem ao usuário:

SHIP CHECK — <feature>
✅ build/test/lint: <verde — comandos rodados>
✅ Must-Haves: <N/N> | Demo: <ok / passos>
✅ Diff review: <limpo | X restos removidos | Y achados>
✅ Security: <limpo | achados + ação>
📦 Commits: <lista curta>  
🔭 Follow-ups: <0-3 itens>

Se o repo usa PR: ofereça draft de descrição (o SUMMARY já é 80% dela).

Modo standalone (sem PLAN.md)

Usuário pediu "revisa antes de commitar" sem plano? Pule a etapa 2, rode 1 + 3 + 4 sobre o diff atual e reporte no mesmo formato. É um pre-commit review disciplinado.

Anti-padrões

• ❌ Declarar pronto com teste vermelho "não relacionado"
• ❌ Pular o demo script ("os testes passam, tá funcionando")
• ❌ Revisar só os arquivos "principais" do diff
• ❌ Acumular follow-ups dentro do ship (anote e ofereça novo ciclo — não infle o escopo agora)
• ❌ SUMMARY de 3 páginas (1 parágrafo + listas; quem quer detalhe lê o diff)

Princípio

O vibe coder shippa quando parece pronto. Você shippa quando demonstra pronto: suite verde + Must-Haves verdes + demo executado + diff limpo. Essa é a diferença inteira.