Fatiar valor e isolar incerteza

Imagine a especificação: “supervisores devem aprovar ordens de serviço e sincronizar a decisão com o ERP”. Um corte comum cria cinco tickets: banco, backend, API, frontend e testes. Cada especialista parece ocupado, mas nenhuma parte isolada permite a um supervisor aprovar uma OS. Integração e regra de negócio só aparecem no fim, quando corrigir custa mais.

Outro corte entrega primeiro: “um supervisor autorizado aprova uma OS pendente individual; o sistema persiste a decisão, exibe o novo estado e registra auditoria”. Esse ticket atravessa várias camadas, mas apenas na largura necessária. Ao concluí-lo, existe comportamento demonstrável e uma hipótese de arquitetura foi testada de ponta a ponta.

Vocabulário para enxergar o trabalho

Uma fatia vertical entrega uma parcela estreita de comportamento através das camadas necessárias. Uma fatia horizontal termina uma camada — “criar todo o schema” — sem entregar uma jornada. Vertical não significa “incluir obrigatoriamente cada camada”: se o valor é uma API para outro sistema, talvez não exista UI. A pergunta é: que comportamento novo uma pessoa ou consumidor consegue observar e verificar ao terminar este ticket?

Um tracer bullet é uma primeira fatia vertical especialmente fina. Como um projétil traçante torna visível a trajetória, ele confirma cedo que as fronteiras principais conectam: identidade chega à regra, a regra grava, a resposta volta e a evidência aparece. Ele não precisa ter toda a variedade, escala ou acabamento da feature final; precisa percorrer o caminho real. O relato da Agile Alliance sobre vertical slicing contrasta histórias que atravessam componentes com cortes por frontend, backend e banco.

Um blocking edge liga um ticket ao trabalho que precisa terminar antes dele. A frontier é o conjunto de tickets ainda abertos cujos blockers já terminaram. Não é “tudo que parece prioritário” nem “todo ticket sem alguém designado”. É uma propriedade calculável do grafo.

No estado inicial, P-01 e T-01 formam a frontier. Dois agentes podem executá-los em contextos separados se não compartilham arquivos ou estado de forma perigosa. T-02 ainda não está livre, por mais importante que seja.

Anatomia de um ticket vertical

Um ticket deve caber em um contexto coerente e responder, sem depender da conversa original:

T-02 — Supervisor aprova uma OS pendente individual

Valor: reduzir o fluxo manual de aprovação de uma única OS.
Blocked by: T-01, P-01

Inclui:
- policy de supervisor e estado PENDING;
- transição APPROVED com versionamento otimista;
- endpoint POST /work-orders/{id}/approval;
- botão e feedback de conflito na tela individual;
- evento de auditoria com actor, workOrderId e timestamp;
- testes nominal, sem permissão, outro tenant e versão conflitante.

Exclui: lote, delegação, modo offline e substituição do ERP.

Demonstração: supervisor aprova OS 742; operador comum recebe 403;
duas aprovações concorrentes produzem uma mudança e um conflito.

Aceite: observações acima falham no commit-base e passam após a mudança.
Rollback: ocultar ação por flag; manter dados e evento já gravados.

O ticket não dita todos os arquivos nem inventa uma arquitetura antes da exploração do repositório. Ele fixa comportamento, interfaces relevantes, riscos, fora de escopo e prova. Critério que já passa no commit-base não prova a mudança. Critério cuja implementação pertence a outro ticket revela corte malfeito.

Tamanho: nem épico, nem poeira

“Implementar aprovação completa, lote, delegação e ERP” mistura decisões demais. “Criar enum APPROVED” é pequeno, mas não entrega valor nem feedback sozinho. Um bom ticket possui coesão: seu conjunto de alterações é necessário para uma única demonstração.

Use estas perguntas:

1. uma sessão nova entende objetivo e limites apenas lendo o ticket e os context pointers?
2. há uma demonstração ou teste que pertence integralmente a este ticket?
3. o aceite pode falhar antes da implementação?
4. o ticket pode ser integrado verde sem esperar uma camada futura?
5. se ele falhar, o rollback é compreensível?

Se todas as respostas forem sim e o trabalho ainda couber numa execução coerente, não o quebre apenas para aumentar a contagem. A documentação atual da skill to-tickets reconhece a atomização excessiva como falha comum e recomenda pular o fatiamento quando toda a mudança cabe num contexto.

Da spec à frontier, passo a passo

1. Extraia jornadas e invariantes

Comece por verbos do domínio: visualizar, aprovar, negar, sincronizar, recuperar. Separe invariantes — autorização por tenant, uma única transição, auditoria — de variantes futuras. Uma jornada pequena com seus controles forma candidata a tracer bullet.

2. Identifique incertezas, não tarefas imaginárias

“Criar integração ERP” é amplo. A incerteza real pode ser: “o conector preserva idempotency key quando há timeout depois do commit?”. Se essa resposta muda o desenho, crie um experimento antes do ticket dependente. Se a documentação e um teste já respondem, apenas registre a evidência; não construa protótipo ornamental.

3. Escreva a demonstração antes das camadas

“Supervisor aprova OS 742 e um operador é negado” força a incluir domínio, persistência, API, UI e auditoria necessários. “Fazer o backend” permite terminar sem usuário nem consumidor observando algo. A demonstração guia o corte; as camadas são consequência.

4. Desenhe blockers reais

Uma dependência existe quando o segundo ticket não pode ser implementado ou verificado corretamente antes do primeiro. Preferência de ordem não é blocker. Detecte ciclos: se A depende de B e B de A, os cortes ou contratos estão errados. GitHub Issues suporta sub-issues e dependências nativas, conforme a documentação oficial; arquivos Markdown também funcionam, desde que preservem as arestas.

5. Calcule a frontier e limite paralelismo

Selecione apenas tickets sem blockers abertos. Depois verifique conflito operacional: dois itens livres no grafo ainda podem editar a mesma migração. Paralelismo serve trabalho separável; não transforma dependência implícita em independência.

6. Reavalie após cada entrega

Fechar um ticket abre outros e pode invalidar suposições. Atualize blockers, decisão de protótipo e critérios. Backlog não é uma fotografia imutável da primeira conversa.

A exceção: mudança larga e incompatível

Renomear status para status_code de uma vez pode quebrar aplicativo, relatórios e conector ERP. Nenhuma fatia vertical fica verde se todos os consumidores precisam mudar atomicamente. Use parallel change, também chamado expand–migrate–contract. A descrição original de Danilo Sato no site de Martin Fowler divide a mudança incompatível em três fases:

1. Expand: adicione status_code sem remover status; aceite ou produza ambos segundo contrato explícito.
2. Migrate: faça backfill idempotente, mova leitores e escritores em lotes observáveis e compare divergências.
3. Contract: somente depois de provar zero leitores/escritores antigos durante a janela definida, remova status.

Cada fase deve poder ser implantada e revertida. Durante migrate, o custo é sustentar dois formatos e evitar divergência. A fase não pode durar indefinidamente: defina owner, telemetria e data de contração. A orientação sobre evolução de bancos reforça migrações versionadas junto ao código e compatibilidade entre schema e aplicação.

Feature flag pode selecionar o caminho novo, mas não torna schema incompatível seguro nem substitui autorização. Se a remoção ocorre na mesma release da adição, consumidores antigos perdem a janela compatível e o método não foi aplicado.

Protótipo descartável: uma pergunta, uma resposta

Um protótipo neste método é código experimental para reduzir uma incerteza que conversa ou documentação não resolvem. Seu contrato contém:

• pergunta discriminante;
• hipótese;
• fixture ou dataset controlado;
• ambiente e versão;
• métrica e limiar decididos antes;
• timebox e condição de parada;
• riscos e coisas que ele deliberadamente não prova;
• destino da decisão e destino do código.

Exemplo: “com 20 mil OS sintéticas, a tabela virtualizada mantém p95 de atualização abaixo de 100 ms no notebook-alvo?” Isso testa uma combinação fixa. “Qual biblioteca é melhor?” mistura critérios. “Construir a tela completa” não tem parada natural.

O protótipo pode ignorar autenticação, persistência e tratamento completo apenas porque está isolado, usa dados sintéticos e nunca receberá tráfego real. Esses atalhos são precisamente a razão para não promovê-lo. Se surge a vontade de adicionar arquitetura final, cobertura completa e compatibilidade, a pergunta já foi respondida ou estava grande demais.

Antes e agora na skill de Matt Pocock

“Descartável” tradicionalmente sugeria apagar o código e preservar apenas a conclusão. Na documentação vigente em 9 de agosto de 2026, a skill prototype preserva o experimento numa branch prototype/<nome> que nunca é mesclada em main; o ticket aponta para ela como evidência executável. A decisão validada entra na spec, ADR ou implementação.

Portanto, descartável significa sem obrigação de produção. O código pode ser eliminado conforme política de retenção ou preservado isoladamente para reprodução; em ambos os casos, não recebe testes, segurança e operação retroativamente por inércia. Essa política é específica do fluxo de Matt, não lei universal.

Handoff: mover estado vivo, não o chat inteiro

Quando o protótipo roda em contexto separado, o próximo contexto precisa saber o que perguntar e depois devolver a resposta. Um handoff contém objetivo, estado atual, decisões, evidências referenciadas, riscos, bloqueios, próximo passo e condição de parada. Specs, tickets, ADRs, diffs e relatórios já existentes são apontados por caminho; não copiados.

Objetivo: decidir semântica de retry do ERP para T-02.
Feito: fixture reproduziu timeout após commit.
Decisão: reutilizar eventId em toda tentativa da mesma aprovação.
Evidência: prototype/erp-idempotency@a14c9e, report.json.
Não provado: SLA e comportamento do ERP produtivo.
Próximo: incorporar contrato em T-02 e criar teste de integração.
Parada: encerrar se uma OS remota existir após duas tentativas.

A skill atual handoff compacta a conversa em arquivo temporário, referencia artefatos e remove segredos. Esse nome e /handoff pertencem ao ecossistema do autor. Em Codex, Claude Code ou outro harness, o equivalente pode ser um resumo estruturado, uma tarefa delegada ou um documento manual.

Skills não são comandos universais

/to-tickets, /prototype e /handoff são interfaces das skills de Matt Pocock. Instalação, invocação automática e comportamento podem mudar por versão e harness. O método independente de fornecedor é:

Necessidade	Artefato portável	Implementação possível
dividir spec	tickets verticais + grafo de blockers	to-tickets, issues manuais, script próprio
eliminar incerteza	protocolo + experimento isolado + decisão	prototype, spike manual, notebook descartável
trocar contexto	estado vivo + referências + próximo passo	handoff, resumo do agente, documento temporário

Não instrua alguém a digitar /to-tickets sem verificar se a skill existe. Ensine primeiro o artefato e seu critério de qualidade; a automação vem depois.

Condições de parada

• Fatiamento para quando cada ticket tem valor demonstrável, aceite que falha no base commit, blockers acíclicos e tamanho coerente. Se tudo cabe numa sessão, um ticket basta.
• Protótipo para quando a pergunta foi respondida, o limiar foi medido, a hipótese foi refutada ou o timebox mostrou que a pergunta precisa ser dividida. Ele não continua para “aproveitar o embalo”.
• Handoff para quando outro contexto consegue executar o próximo passo lendo o documento e seus pointers, sem pedir o histórico completo.
• Migração para de coexistir quando telemetria e verificação mostram que nenhum consumidor depende do contrato antigo e rollback foi reavaliado.

Falhas, diagnóstico e controles

• Ticket por camada: pergunte “o que posso demonstrar?”; sem resposta comportamental, refaça o corte.
• Dez tickets para uma mudança curta: agrupe por demonstração; coordenação pode superar o valor.
• Frontier com trabalho bloqueado: derive blockers do tracker e detecte ciclos; não use impressão visual.
• Protótipo virou produto: retire tráfego e credenciais, preserve apenas decisão/evidência, implemente novamente sob contrato de produção.
• Migração nunca contrai: atribua owner, prazo e métrica de uso antigo; dívida de compatibilidade também custa.
• Handoff enorme: substitua cópias por context pointers e remova logs, segredos e decisões já duráveis.
• Dois agentes livres colidem: blockers lógicos não capturam disputa por arquivo/ambiente; serialize ou isole em worktrees.

Segurança, privacidade e custo

Tickets devem nomear autorização, tenant e efeitos, não deixar segurança para um “ticket final”. Protótipos usam dados sintéticos ou minimizados, credenciais falsas, rede restrita e ambiente descartável. Branch experimental não é cofre: nunca grave segredos ou dados pessoais. Handoff passa por redaction.

O custo de contexto cresce com tickets gigantes; o custo de coordenação cresce com tickets microscópicos. Protótipo reduz desperdício apenas quando a pergunta altera uma decisão. Registre tempo, chamadas e oportunidade evitada; “experimentar tudo” não é pesquisa eficiente.

Critérios de aceite e exercício

Você domina o procedimento quando consegue transformar uma spec em um grafo sem ciclos; explicar a demonstração de cada ticket; calcular a frontier; identificar uma mudança que exige expand–migrate–contract; escrever um protótipo com uma só hipótese; e entregar um handoff curto que aponta para evidências.

Como exercício, use a aprovação de OS descrita neste capítulo. Produza quatro a sete tickets, incluindo um tracer bullet, uma decisão de ERP e a migração de status. Desenhe blockers. Para cada ticket, escreva uma observação que falha antes e passa depois. Em seguida, justifique por que criar todas as tabelas e configurar todo o frontend não são fatias verticais. Execute o Caderno de campo para validar o grafo e reproduzir o protótipo.

Recuperação ativa

1. Por que “supervisor aprova uma OS individual” é vertical, mesmo atravessando várias camadas?
2. Qual é a diferença entre prioridade e blocking edge?
3. Como calcular a frontier de um grafo de tickets?
4. O que sobrevive a um protótipo descartável e o que não entra em produção?
5. Por que remover status na mesma release que cria status_code quebra expand–migrate–contract?
6. O que um handoff deve referenciar em vez de copiar?
7. Quando /to-tickets não deve ser apresentado como instrução executável?

Fontes e relações

As descrições de to-tickets, prototype e handoff refletem o repositório oficial de skills de Matt Pocock revisado na data deste capítulo. Elas são fontes primárias para essas skills, não prova universal de eficácia. Parallel change é documentado no catálogo de Martin Fowler, e dependências nativas são descritas pela documentação do GitHub.

Use Da intenção à especificação antes deste livro e Concluir significa provar depois. Fatiamento controla o escopo; testes e revisão ainda precisam provar a implementação.