Pensamento Produtivo

O que Pensamento Produtivo faz?

Facilite uma sessão de design estruturada usando o Modelo de Pensamento Produtivo de Tim Hurson e, opcionalmente, escreva-a como um RFC.

Entrada

$ARGUMENTS

• Se a entrada começar com rfc, execute o modo RFC. Qualquer coisa após isso é um título opcional ou caminho de saída.
• Caso contrário, execute o modo interativo, tratando a entrada como a declaração do problema. Se estiver vazia, peça ao usuário para descrever o problema em uma ou duas frases antes de fazer qualquer outra coisa.

Como facilitar

• Fundamente tudo no código. Antes de cada etapa, pesquise e leia os arquivos, esquemas, configurações e documentações relevantes, e cite os caminhos quando depender deles. O valor desta sessão sobre uma conversa no quadro branco é que as conclusões se baseiam no que o sistema realmente faz, portanto verifique em vez de assumir. Para varreduras amplas em muitos arquivos, delegue a um subagente Explore para que o contexto da sessão permaneça focado na discussão.
• Mantenha a carga do usuário leve. Faça no máximo 5 perguntas por turno e acompanhe-as com suas próprias respostas sugeridas com base no que você encontrou, para que o usuário possa responder "sim, mais ou menos, mas…" em vez de começar de uma página em branco.
• Uma etapa por turno. Abra cada etapa com um cabeçalho como Etapa 2 de 6 — O que é sucesso?, execute a etapa, então pare e aguarde. Avance apenas quando o usuário estiver pronto; permita que ele pule, revisite ou salte entre etapas.
• Mantenha um arquivo de anotações contínuo. Após cada etapa, anexe o resultado acordado em <rfc-dir>/<slug>.notes.md (escolha <rfc-dir> conforme descrito no modo RFC, etapa 3). Sessões longas podem ser compactadas ou retomadas posteriormente; o arquivo de anotações é o que permite que o modo RFC, ou uma nova sessão, retome sem perder decisões. Informe ao usuário onde ele está na primeira vez que criá-lo.

As seis etapas

1. Do que se trata?

Objetivo: entendimento compartilhado da realidade atual e do futuro almejado. Explore implementações existentes, pontos de chamada, modelos de dados e histórico recente de git das áreas afetadas. Cubra: o ponto de dor ou gargalo (com evidências como erros, métricas ou código), os módulos e serviços impactados, quem é afetado e como é o estado "resolvido".

2. O que é sucesso? (DRIVE)

Objetivo: critérios pelos quais cada opção será julgada. Proponha um rascunho a partir da Etapa 1 e deixe o usuário corrigi-lo.

• Do (Fazer): o que a solução deve fazer
• Restrictions (Restrições): restrições duras (compatibilidade reversa, orçamentos de desempenho, pilha, conformidade)
• Investment (Investimento): tempo, pessoas e complexidade que a equipe está disposta a gastar
• Values (Valores): princípios de engenharia que desempatam (simplicidade, testabilidade, …)
• Essential outcomes (Resultados essenciais): resultados inegociáveis, mensuráveis quando possível

Capture também as não-metas explícitas.

3. Qual é a pergunta?

Proponha 2 a 3 perguntas "Como poderíamos…" que enquadrem o desafio de forma diferente, por exemplo uma estreita e outra que desafie uma suposição da Etapa 1. O usuário escolhe ou reescreve uma; ela se torna a declaração do problema para o restante da sessão.

4. Gerar respostas

Proponha 2 a 3 abordagens genuinamente distintas, fundamentadas no código, não variações de uma mesma ideia. Para cada uma: um breve esboço, os arquivos ou módulos que ela toca e seu principal risco. Evite julgamentos nesta etapa e convide as próprias ideias do usuário.

5. Forjar a solução

Pontue cada abordagem contra os critérios DRIVE (uma pequena tabela funciona bem), recomende uma e nomeie a troca que está aceitando. Em seguida, fortaleça-a: modos de falha, casos extremos, preocupações com migração, perguntas em aberto. Registre por que as outras opções perderam; isso se torna "Alternativas consideradas".

6. Alinhar recursos

Concorde com o formato da entrega, não com tickets individuais: fases ou marcos e o que cada um torna demonstrável, a parte mais arriscada a provar primeiro, estratégia de feature flag e migração, estratégia de teste, implantação e reversão, e o que monitorar. O detalhamento de tickets virá depois com /task-breakdown, que trabalha a partir do RFC. Por fim, ofereça-se para gerar o RFC.

Modo RFC

1. Encontre a sessão: use a conversa até agora mais o arquivo de anotações, se existir. Se não houver sessão alguma, informe e ofereça-se para iniciar uma: peça a declaração do problema e comece a Etapa 1.
2. Se etapas estiverem faltando, liste quais e pergunte se devem ser preenchidas agora ou se o RFC deve ser redigido com essas seções marcadas como TBD. Não invente decisões que o usuário não tomou.
3. Escolha o local de saída. RFCs, anotações e arquivos de tarefas são documentos de trabalho locais do desenvolvedor: não rastreados por padrão, não commitados com o código. Procure por uma pasta local existente, ignorada pelo git, para eles (verifique .gitignore e .git/info/exclude) e siga sua nomenclatura. Se não houver, proponha .rfcs/YYYY-MM-DD-<slug>.md e adicione .rfcs/ a .git/info/exclude, o que o ignora localmente sem alterar o .gitignore do repositório. Use uma pasta rastreada como docs/rfcs/ apenas se o usuário disser que a equipe commitam RFCs.
4. Escreva o RFC usando templates/rfc.md, preenchendo cada seção a partir da sessão e vinculando afirmações sobre o código aos caminhos de arquivo.
5. Informe ao usuário o caminho e liste quaisquer seções TBD e perguntas em aberto.
6. Ofereça o próximo passo: /task-breakdown <caminho-do-rfc> para transformar o RFC em tickets de 1 ponto de história que a equipe pode assumir.