ll-skills 1.0.0

package/skills/ll-voltar-do-futuro/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: ll-voltar-do-futuro
+description: Premortem "voltar do futuro" — o projeto já morreu e você narra por quê, atacando o que nunca foi medido, e converte cada morte em um teste barato com critério de aceite numérico. Use quando pedirem premortem/pré-mortem, "o que pode dar errado", "por que isso vai falhar", análise adversarial de um plano, arquitetura ou ideia, validação de premissas não testadas, ou antes de investir em construir algo caro.
+---
+
+# Voltar do futuro
+
+O projeto morreu. Não "pode morrer": morreu, é fato consumado, você viu o corpo. Esse é o
+frame de certeza — pergunta probabilística o cérebro descarta como hipótese remota; fato
+consumado ele explica, e gera causas específicas.
+
+Um projeto quase nunca morre onde foi olhado com rigor. Morre na **fronteira entre a camada
+auditada e a camada que entrou na fé**, porque a confiança conquistada na primeira é
+transferida indevidamente para a segunda. Por isso o exercício começa medindo essa
+assimetria e ataca só o delta. O produto final não é uma lista de riscos: é um conjunto de
+premissas falsificáveis com experimento barato, aceite numérico pré-registrado e decisão
+pré-comprometida.
+
+## Regras invioláveis
+
+1. **Ataque só o delta.** O que já foi auditado com número, amostra e método está fora do
+   alvo. Reprovar de novo o que já passou é conforto disfarçado de rigor.
+2. **Pretérito e cena.** Cada falha traz quem percebeu, por qual canal, quando, qual número
+   apareceu e qual foi o dano de negócio. Se a frase caberia sem alteração em outro projeto
+   qualquer, ela é lugar-comum e sai da lista.
+3. **Citação literal e rastreável, ou ponto cego declarado.** Toda falha cita um trecho
+   literal de um artefato do próprio projeto que já avisava, com o arquivo de origem — ou
+   declara "nenhum artefato menciona este ponto", tratado como agravante de letalidade.
+   Citação inventada destrói o exercício inteiro: jamais parafraseie como se fosse citação,
+   jamais cite arquivo que você não abriu.
+4. **Nenhuma falha sai sem teste acoplado.** Teste com amostra, prazo, custo, aceite
+   numérico, o que ele reprova e o que ele bloqueia. Lista sem teste é pior que lista
+   nenhuma: entrega a sensação de risco endereçado enquanto o plano segue intocado.
+5. **Zero mitigação durante a narrativa.** Enquanto narra, o agente não resolve. Resolver
+   cedo interrompe a geração e produz otimismo.
+6. **5 a 8 falhas, vetores diversos.** Menos de 5 = preparação rasa. Mais de 8 = risk
+   register diluído. Sete versões da mesma falha contam como uma.
+7. **Veredicto duro no bloco (a).** Nada de "embora o time provavelmente perceba a tempo".
+   A nuance vai para o veredicto medido da F5, depois do número.
+
+## Material de apoio
+
+Resolva o **caminho absoluto do diretório desta skill** antes de delegar — subagentes não
+herdam este contexto e precisam do caminho literal nos briefs.
+
+- `referencias/vetores-e-testes.md` — 12 vetores de ataque, anatomia de 8 partes do teste
+  desarmador, padrões de teste por tipo de incógnita, substitutos quando o teste exige
+  terceiros, 5 fatores de letalidade, exemplo trabalhado. Leia antes da F1.
+- `referencias/anti-padroes-e-fundamentos.md` — 17 anti-padrões, checklist de "pronto",
+  fundamentos da literatura. Leia antes da verificação final e ao justificar o método a um
+  humano cético.
+
+## F0 — Inventário: medido × fé
+
+Varra os artefatos do projeto (specs, POCs, ADRs, benchmarks, relatórios, docs de pesquisa)
+e produza `docs/premortem/00-inventario-medido-vs-fe.md`:
+
+1. **Medido** — toda afirmação com **número, amostra e método**, mais o **escopo exato da
+   medição**: qual camada, qual ambiente, qual amostra, qual regime de operação.
+2. **Na fé** — toda afirmação sem medição: bibliografia citada, analogia, projeção,
+   decisões justificadas por "sabemos que", "deve", "esperamos", "assume-se", "é padrão de
+   mercado", e tudo que só existe como desenho.
+3. **Confissões do projeto** — seções de "fora de escopo", "limitações", "não medido",
+   "trabalho futuro", "riscos conhecidos", TODOs e ressalvas de rodapé, cada uma com
+   **citação literal + arquivo:seção**. Esta é a munição mais valiosa do exercício.
+4. **A frase da fronteira** — no formato *"medimos X com rigor; o produto depende de Y; X e
+   Y são coisas diferentes"*. Concreta, com os nomes reais dos componentes.
+5. **A zona de ataque** — o delta, enumerado. E a lista explícita do que fica **fora do
+   alvo** por já ter sido auditado.
+
+> **Checkpoint 1 (humano).** Apresente em ≤ 10 linhas: a frase da fronteira, a zona de
+> ataque, o **horizonte e a data** propostos para a narrativa e as personas escolhidas.
+> O horizonte é o ponto em que o projeto teria *provado* sua tese central — curto demais
+> gera falhas triviais, longo demais gera ficção científica. Peça correção antes de seguir.
+
+**Se existe `docs/` de uma pesquisa de mercado** (skill `ll-pesquisar-mercado`), as premissas
+mapeadas por importância × evidência já são metade da F0: as de alta importância e baixa
+evidência entram direto na coluna "na fé". Use como insumo quando houver; a F0 funciona
+igual sem ela.
+
+## F1 — Narradores paralelos, contexto limpo
+
+Rode **4 a 6 narradores em paralelo, cada um em subagente próprio**, com personas
+distintas. Um único narrador ancora: gera sete variações do primeiro tema que apareceu.
+Este é o análogo digital da escrita silenciosa antes da roda de conversa.
+
+Personas disponíveis (escolha as que o projeto realmente tem): engenharia/dados,
+operação e escala, economia unitária, jurídico/regulatório e dependências externas,
+usuário final e percepção, concorrente/mercado.
+
+Os narradores **não devem ver o raciocínio que produziu o plano** — só os artefatos e o
+dossiê da F0. Cada um grava seu resultado em arquivo e devolve só o caminho: o orquestrador
+lê os arquivos na F2, não os transcritos. Rode-os em Opus.
+
+<brief-modelo-narrador>
+Você é o(a) [PERSONA: ex. engenheiro(a) de dados sênior] de [PROJETO] e voltou do futuro:
+é [DATA/HORIZONTE] e o projeto morreu. Não "poderia morrer" — morreu, é fato consumado,
+você viu o corpo. Sua tarefa é relatar, em pretérito, o que aconteceu.
+
+Contexto: este relato alimenta um premortem que decide, nesta semana, quais testes baratos
+rodam ANTES de qualquer construção. Quanto mais específica e mais dolorosa sua narrativa,
+mais dinheiro e meses ela economiza. Você tem permissão explícita para ser brutal; suavizar
+aqui é o único jeito de falhar nesta tarefa.
+
+Leia, nesta ordem:
+1. [CAMINHO ABSOLUTO]/docs/premortem/00-inventario-medido-vs-fe.md — o que foi medido, o
+   que está na fé, e a fronteira entre os dois.
+2. [CAMINHOS DOS ARTEFATOS RELEVANTES PARA ESTA PERSONA]
+3. [CAMINHO ABSOLUTO DA SKILL]/referencias/vetores-e-testes.md — os 12 vetores de ataque
+   (cubra pelo menos os vetores [N, N, N]) e a anatomia de 8 partes do teste desarmador.
+
+Instruções:
+- Ataque exclusivamente a zona de ataque do dossiê. O que está listado como já auditado
+  está fora do alvo.
+- Escreva 3 a 5 mortes, cada uma como cena concreta: quem percebeu, por qual canal, quando,
+  qual número apareceu, qual foi o dano de negócio. Termine no dano, não no defeito.
+- Para cada morte, cite **literalmente** um trecho de um artefato do projeto que já avisava,
+  com arquivo e seção. Se nenhum artefato menciona o ponto, escreva exatamente "nenhum
+  artefato do projeto menciona este ponto" — isso é um achado, não uma falta. Nunca escreva
+  entre aspas algo que não esteja literalmente no arquivo.
+- Nomeie o viés ou mecanismo que explica por que o aviso, existindo, não foi agido.
+- Não proponha mitigação e não amenize. Proponha apenas o teste barato que desarmaria a
+  premissa, com os 8 componentes da referência.
+
+Contrato de saída — grave em [CAMINHO ABSOLUTO]/docs/premortem/narradores/[persona].md,
+uma seção por morte, exatamente neste formato:
+
+## [título da morte em uma linha, com o número que a define]
+**(a)** [história em pretérito, 1–5 frases, com cena, números e dano]
+**(b)** [citação literal + `arquivo.md` §seção — ou a declaração de ponto cego] + [nome do
+viés que cegou]
+**(c)** [teste: afirmação falsificável, amostra adversarial, ground truth independente,
+aceite numérico, "este teste reprova se ___", prazo e custo, decisão pré-comprometida nos
+dois ramos, e o que ele bloqueia]
+**Confiança:** [alta | média | baixa] — [uma frase sobre o que sustenta ou fragiliza este
+relato]
+
+Limites: não edite nenhum outro arquivo; não leia relatos de outros narradores; não
+proponha roadmap, arquitetura ou solução.
+
+Sucesso: 3 a 5 mortes gravadas no arquivo; nenhuma delas caberia sem alteração em outro
+projeto; toda citação é verificável abrindo o arquivo citado; todo teste tem número no
+aceite e uma frase de reprovação plausível; todo teste cabe em ≤ 2 semanas sem construir
+o produto. Devolva na resposta apenas o caminho do arquivo e os títulos das mortes.
+</brief-modelo-narrador>
+
+## F2 — Consolidação
+
+Leia os arquivos dos narradores. Deduplique (mesma premissa em roupas diferentes vira uma
+falha, com a melhor cena e a melhor citação). Corte lugares-comuns e catástrofes sem
+alavanca de teste. **Verifique cada citação abrindo o arquivo citado** — a que não bater
+literalmente vira declaração de ponto cego ou sai. Chegue a 5–8 falhas, cada uma com os
+três blocos:
+
+<contrato-de-falha>
+**(a) A história concreta da morte.** Pretérito, cena, números, consequência de negócio.
+Uma a cinco frases. Termina no *dano*, não no *defeito*.
+**(b) O aviso que existia + o viés que cegou.** Citação literal do artefato do projeto com
+arquivo de origem (ou "nenhum artefato menciona este ponto"), mais o nome do mecanismo que
+explica por que o aviso não foi agido.
+**(c) O teste barato que desarma.** Amostra adversarial, ground truth independente, aceite
+numérico pré-registrado, "reprova se ___", prazo e custo, decisão pré-comprometida, e o que
+ele bloqueia.
+</contrato-de-falha>
+
+Para calibrar densidade, cena e tom de veredicto, leia o exemplo trabalhado no fim de
+`referencias/vetores-e-testes.md`.
+
+## F3 — Letalidade e TOP 3
+
+Ordene da mais letal para a menos e **marque as três primeiras**. A marcação é o contrato de
+triagem que faz o resultado ser acionável na semana seguinte em vez de virar backlog eterno.
+
+Calibre pelos cinco fatores (detalhados na referência): mata ou machuca; custo de retrofit e
+irreversibilidade; centralidade de dependência; probabilidade **dado que ninguém olhou**;
+tempo até a detecção. *Atraso não é letalidade.*
+
+**Contrato:** os testes do TOP 3, somados, cabem em ~2 semanas e antecedem qualquer
+construção.
+
+## F4 — Síntese
+
+Não termine com lista. Termine com duas coisas:
+
+1. **O diagnóstico transversal** — a única causa-raiz de processo que explica *todas* as
+   falhas ao mesmo tempo.
+2. **A regra que faltou** — uma política de processo enunciável em uma linha, que teria
+   evitado a lista inteira e passa a valer daqui em diante. Verificável ("existe auditoria
+   própria para esta camada? sim/não"), nunca exortativa ("ser mais rigoroso"). É o único
+   entregável do premortem que sobrevive ao projeto.
+
+Grave `docs/premortem/premortem.md`: parágrafo de contexto de quem voltou (com a frase da
+fronteira) → falhas ordenadas com TOP 3 marcados → síntese.
+
+> **Checkpoint 2 (humano).** Apresente o TOP 3 com custo somado dos testes e peça a decisão
+> que só o humano toma: quais testes rodam agora, quem é o dono de cada um e qual a data de
+> retorno. Registre as decisões pré-comprometidas como acordo, não como sugestão.
+
+## F5 — Placar
+
+O premortem só está encerrado quando cada falha tem **veredicto medido**. Ele derruba a
+confiança no plano e depois a reconstrói sobre evidência — parar na metade é teatro.
+
+A execução dos testes é trabalho da skill `ll-desarmar` (ll-skills), que confere cada
+teste contra a anatomia, executa com disciplina "reprova primeiro" e preenche o placar.
+Após o Checkpoint 2, entregue o premortem e nomeie esse próximo passo — invocá-lo é decisão
+do usuário. Só execute os testes você mesmo se o usuário pedir, respeitando o contrato
+abaixo.
+
+Grave `docs/premortem/placar.md`: uma linha por falha, com **vocabulário fechado**:
+
+| Veredicto | Significa |
+|---|---|
+| **DESARMADA** | Teste rodou, aceite passou, **com a fronteira de validade explicitada** (onde vale e onde não vale). Desarmar não é aprovar tudo. |
+| **DESARMADA COM CONDIÇÕES** | Passou no fio, e a passagem depende de uma decisão de desenho que agora vira requisito. |
+| **CONFIRMADA, COM ROTA DE SAÍDA QUANTIFICADA** | O premortem estava certo, e o teste mediu **qual alavanca resolve**. É o resultado de maior valor do exercício: redesenho fundamentado antes de qualquer código. |
+| **EM CURSO** | Teste de duração instalado e rodando, com data de leitura. |
+| **PENDENTE, COM SUBSTITUTO DECLARADO** | Exige terceiros indisponíveis; rodou simulação com o que ela prova e o que não prova escrito, e o item foi reclassificado de bloqueio para validação pré-lançamento. |
+
+Registre também os **achados colaterais**: testes desenhados para falsear premissas
+encontram bugs e cravam decisões de arquitetura que nenhuma revisão de código encontra.
+Isso deve ser esperado e capturado. Números medidos aqui realimentam o índice de pesquisas
+da skill `ll-pesquisar-mercado`, quando ela existir no projeto.
+
+## Verificação antes de entregar
+
+Rode o checklist de "pronto" e os 17 anti-padrões de
+`referencias/anti-padroes-e-fundamentos.md` contra o documento gravado, e reporte ao usuário
+o resultado destas três verificações, que são as que mais falham:
+
+- **Citações**: cada trecho entre aspas foi conferido abrindo o arquivo citado e bate
+  literalmente. Diga quantas conferiu e quantas falhas ficaram sem aviso documentado.
+- **Especificidade**: nenhuma falha sobrevive ao teste do "cabe em qualquer projeto do
+  mundo"; cada uma tem um número na história e um número no aceite.
+- **Orçamento do TOP 3**: os três testes somados, com prazos declarados, dão ≤ ~2 semanas e
+  nenhum deles exige construir o produto.
+
+Reporte também o que ficou fora e por quê. "Não encontrei aviso documentado para as falhas 3
+e 5" é resultado válido e esperado; preencher a lacuna com uma citação plausível não é.

package/skills/ll-voltar-do-futuro/referencias/anti-padroes-e-fundamentos.md

@@ -0,0 +1,201 @@
+# Anti-padrões, critérios de pronto e fundamentos
+
+Material de verificação do premortem `ll-voltar-do-futuro`. Lido antes de entregar o documento
+e sempre que for preciso defender o método diante de um humano cético.
+
+---
+
+## Os 17 anti-padrões
+
+### Do conteúdo das falhas
+
+1. **Falha genérica.** "Pode faltar orçamento", "o time pode não ter experiência", "o mercado
+   pode mudar", "requisitos podem crescer". Teste: se a frase caberia sem alteração em
+   qualquer outro projeto do mundo, ela não é falha — é lugar-comum. Corte ou reescreva com
+   os detalhes deste projeto.
+2. **Catástrofe não acionável.** Pandemia, mudança regulatória global, aquisição do
+   fornecedor. Sem alavanca de teste barato, não entra na lista principal.
+3. **Falha sem número.** Toda história de morte precisa de pelo menos uma quantidade — taxa
+   de erro, custo, tempo, n. Sem número, não há como desenhar critério de aceite.
+4. **Atacar o que já foi auditado.** Reprovar de novo o que já passou é conforto disfarçado
+   de rigor, e desperdiça a única passagem que o exercício tem.
+5. **Citação fabricada.** O modo de falha mais grave para um agente LLM: inventar uma frase
+   "do documento do projeto" que soa plausível. Toda citação é literal e rastreável ao
+   arquivo; na ausência de aviso documentado, dizer isso em voz alta.
+6. **Lista inflada.** Vinte falhas equivalem a zero decisões. 5–8, ordenadas, com TOP 3.
+7. **Ancoragem monotemática.** Sete falhas que são a mesma falha em sete roupas. Cubra
+   vetores distintos: dado, algoritmo, operação, custo, jurídico, humano/percepção, escala.
+
+### Do processo
+
+8. **Risk theater — listar sem desarmar.** O anti-padrão dominante. Uma lista de modos de
+   falha que não muda nada é *pior* que nenhuma lista, porque entrega a sensação de ter
+   endereçado o risco enquanto o plano segue intocado. Regra: nenhuma falha sai do documento
+   sem teste acoplado.
+9. **Mitigação vaga no lugar de teste.** "Vamos monitorar", "teremos cuidado", "adicionaremos
+   validação". Não é falseável, não tem aceite, não tem data.
+10. **Critério de aceite ajustado depois de ver o resultado.** Pré-registre. Se o número ficou
+    no fio (79,7% contra aceite de 80%), diga que ficou no fio e trate como *condição*, não
+    como aprovação.
+11. **Teste que não pode reprovar.** "Verificar se a extração funciona bem." Aceite
+    qualitativo é aceite ausente.
+12. **Teste caro disfarçado.** Se o teste exige construir metade do produto, foi desenhado
+    errado — ou o time está usando o premortem como autorização para começar a construir.
+13. **Rodar o premortem com quem escreveu o plano, no mesmo fio de raciocínio.** Herda a
+    inside view inteira. Exige contexto limpo, persona adversarial e permissão explícita para
+    ser brutal.
+14. **Um único narrador.** Ancoragem garantida. Vários narradores independentes com ângulos
+    diferentes, deduplicados depois — o equivalente digital da escrita silenciosa de Klein.
+15. **Otimismo de cortesia do agente.** LLMs suavizam por padrão ("embora o time
+    provavelmente perceba isso a tempo…"). O bloco (a) não admite ressalva conciliatória; a
+    nuance vai para o veredicto medido, depois.
+16. **Confundir premortem com pessimismo ou com abandono.** O objetivo é converter incerteza
+    em experimento. Falha CONFIRMADA não significa "desistir": significa "redesenhar agora,
+    com o número na mão" — a rota de saída quantificada é resultado de sucesso.
+17. **Não fechar o ciclo.** Premortem sem placar posterior é metade do trabalho. Data de
+    retorno é marcada junto com cada teste.
+
+---
+
+## Critérios de pronto
+
+### O documento de premortem está pronto quando
+
+- [ ] A F0 produziu, por escrito, as duas listas (medido × na fé) e a frase da fronteira
+      ("medimos X; o produto depende de Y; são coisas diferentes").
+- [ ] Há **5 a 8 falhas**, cada uma com os três blocos completos.
+- [ ] **Toda falha é específica deste projeto**: nomeia componentes, números, atores e
+      consequências reais. Nenhuma sobreviveria ao teste do "cabe em qualquer projeto".
+- [ ] **Toda falha tem citação literal e rastreável** de um artefato do projeto que já
+      avisava, **ou** a declaração explícita de que não há aviso algum. Zero citações
+      inventadas — cada uma foi conferida abrindo o arquivo.
+- [ ] **Toda falha nomeia o viés ou mecanismo** que explica por que o aviso não foi agido.
+- [ ] **Toda falha tem teste acoplado** com os 8 componentes: afirmação falsificável, amostra
+      adversarial, ground truth independente, aceite numérico pré-registrado, "reprova se
+      ___", prazo e custo, decisão pré-comprometida nos dois ramos, e o que ele bloqueia.
+- [ ] As falhas estão **ordenadas por letalidade** com **TOP 3 marcados**, justificáveis
+      pelos cinco fatores.
+- [ ] Os testes dos **TOP 3 somam ~2 semanas ou menos** e antecedem a construção.
+- [ ] Os vetores cobertos são **diversos**, e cada seção de "não medido / fora de escopo" dos
+      artefatos ou virou falha, ou tem justificativa explícita de por que é inofensiva.
+- [ ] A síntese entrega **o padrão transversal** e **a regra que faltou**, esta última
+      enunciada como política verificável, não como exortação.
+
+### O ciclo está encerrado quando
+
+- [ ] Cada falha tem **veredicto medido** no vocabulário fechado.
+- [ ] Cada "desarmada" traz a **fronteira de validade** — onde vale e onde não vale — não
+      apenas o "passou".
+- [ ] Cada "confirmada" traz a **alavanca quantificada** e a decisão de desenho que decorre
+      dela.
+- [ ] Os **achados colaterais** (bugs, decisões de arquitetura cravadas pelos testes) estão
+      registrados.
+- [ ] O que continua pendente está listado com dono, e explicitamente reclassificado de
+      *bloqueio* para *validação posterior* — ou mantido como bloqueio.
+
+---
+
+## Fundamentos
+
+### O núcleo: o frame de certeza
+
+Um risk assessment pergunta *"o que pode dar errado?"*. O premortem afirma *"deu errado — por
+quê?"*. A diferença não é retórica: é a passagem de um julgamento probabilístico (que o
+cérebro trata como hipótese remota e educadamente descarta) para uma tarefa explicativa (que
+o cérebro trata como fato consumado e para a qual gera causas específicas). Na formulação de
+Klein: diferente de uma sessão de crítica típica, em que se pergunta o que *poderia* dar
+errado, "o premortem opera sob a suposição de que o 'paciente' morreu, e portanto pergunta o
+que *deu* errado".
+
+- **Klein, G. (2007), "Performing a Project Premortem", HBR 85(9), 18–19.** Formaliza o
+  exercício: o time é briefado no plano, assume que ele fracassou redondamente, e cada
+  participante gera razões plausíveis para a morte.
+- **Mitchell, Russo & Pennington (1989), "Back to the future", JBDM 2(1), 25–38.** Origem do
+  *prospective hindsight*, base do número mais citado da técnica (**~30% de aumento na
+  capacidade de identificar corretamente razões para resultados futuros**). *Nota de
+  honestidade:* esse "30%" é a atribuição que Klein faz ao estudo; o artigo original manipula
+  duas variáveis — perspectiva temporal e certeza do desfecho — e encontra o efeito forte na
+  **certeza do desfecho**. Isso reforça o método: o que carrega o efeito é assumir que a coisa
+  aconteceu, não apenas se projetar no futuro.
+- **Veinott, Klein & Wiggins (2010), ISCRAM.** n=178, cinco condições, plano real de resposta
+  a epidemia. O premortem reduziu a confiança no plano cerca do dobro do efeito de gerar
+  prós/contras — e, **depois de gerar soluções, a confiança voltou a subir mais** na condição
+  premortem. O premortem não é pessimismo: é um ciclo destrói-e-reconstrói.
+- **Klein, Koller & Lovallo (2019), "Bias busters: Premortems", McKinsey Quarterly.** O
+  mecanismo organizacional: líderes são superconfiantes e ancoram num único caminho; membros
+  do time evitam falar por medo de parecerem negativos. O premortem torna a dissidência a
+  tarefa designada, não um ato de coragem.
+
+### Os vieses que a técnica desarma
+
+- **Falácia do planejamento / viés de otimismo** — Kahneman & Tversky (1979): subestimamos
+  prazo, custo e risco e superestimamos benefícios, porque adotamos a *inside view*. A cura é
+  a *outside view* (Lovallo & Kahneman, 2003) e o *reference class forecasting* de Flyvbjerg
+  (2006, 2008), cuja base empírica é brutal: ~92% dos megaprojetos estouram orçamento, prazo
+  ou ambos; sobrecustos médios de 45% (ferrovias), 34% (pontes/túneis) e 20% (rodovias),
+  estáveis há 70 anos.
+- **Viés de confirmação** — Wason (1960); Nickerson (1998). Existindo um plano, toda evidência
+  é lida como apoio a ele. O premortem inverte o alvo da busca.
+- **Groupthink** — Janis (1972). O premortem torna a dissidência obrigatória e, na versão em
+  grupo, anônima na primeira rodada.
+- **Disponibilidade e transferência indevida de confiança** — medir o fácil e chamá-lo de "o
+  todo". É o vetor dominante em projetos com uma camada bem auditada.
+
+### Vizinhança metodológica
+
+| Técnica | O que faz | Como difere |
+|---|---|---|
+| **Risk register / matriz probabilidade×impacto** | Enumera riscos pontuados | Trabalha em modo possibilidade, produz abstrações genéricas, raramente tem dono, teste ou prazo. É inventário; premortem é narrativa causal |
+| **Key Assumptions Check** (Heuer & Pherson, 2010/2019) | Explicita e questiona premissas implícitas | Complementar e ideal como **preparação**: a lista de premissas não medidas é a munição do narrador — é a F0 |
+| **Structured Self-Critique** (Pherson) | O time vira seu crítico mais duro | Evolução formalizada do premortem para análise de inteligência |
+| **Red teaming / advogado do diabo** (Zenko, 2015) | Adversário dedicado ataca o plano | Red team ataca *de fora e no presente*; premortem ataca *de dentro e do futuro*, com acesso a premissas internas que o adversário externo não conhece |
+| **Análise de Hipóteses Concorrentes** (Heuer, 1999) | Avalia evidência contra múltiplas hipóteses | Diagnóstico, não antecipação de falha |
+| **Discovery-Driven Planning** (McGrath & MacMillan, 1995) | Checklist de premissas + reverse income statement + financiamento por marcos | Fornece a disciplina do "depois": sucesso = máximo de aprendizado pelo mínimo de gasto |
+| **Leap-of-faith assumptions / MVP** (Ries, 2011) | Isola as premissas que sustentam o negócio | Mesma filosofia; o premortem é o gerador de candidatas |
+| **Riskiest Assumption Test** (Higham, 2016; Bland & Osterwalder, 2019) | Constrói só o suficiente para testar a maior incógnita | É exatamente o **destino** de cada falha. Assumption mapping (importância × evidência) é a ordenação formal da letalidade |
+| **Kill criteria** (Duke, 2018/2022; McKinsey, 2019) | Sinais pré-comprometidos que mandam parar | Duke é explícita: um premortem só é bom se você estabelece kill criteria e se compromete com as ações ao ver esses sinais |
+| **Strong inference** (Platt, 1964) e falsificacionismo (Popper) | Hipóteses concorrentes + experimento crucial | É a epistemologia do teste desarmador: o teste vale pelo que consegue *reprovar* |
+| **Chaos engineering / GameDays** (Basiri et al., 2016) | Injeta falha em produção | É o premortem executado continuamente sobre um sistema vivo |
+
+### A tese em uma linha
+
+O premortem funciona porque **transforma incerteza em narrativa, narrativa em premissa
+falsificável, e premissa falsificável em experimento barato com critério de aceite
+pré-comprometido**. Um premortem que para na narrativa é teatro; um que começa na lista de
+riscos nunca chega a ser específico o bastante para virar experimento.
+
+---
+
+## Referências
+
+- Basiri, A. et al. (2016). "Chaos Engineering." *IEEE Software* 33(3).
+- Bland, D. J., & Osterwalder, A. (2019). *Testing Business Ideas*. Wiley.
+- Duke, A. (2018). *Thinking in Bets*. Portfolio. / (2022). *Quit*. Portfolio.
+- Flyvbjerg, B., Holm, M. S., & Buhl, S. (2002). "Underestimating Costs in Public Works
+  Projects: Error or Lie?" *JAPA* 68(3).
+- Flyvbjerg, B. (2006). "From Nobel Prize to Project Management: Getting Risks Right."
+  *Project Management Journal* 37(3), 5–15.
+- Heuer, R. J. (1999). *Psychology of Intelligence Analysis*. CIA CSI.
+- Heuer, R. J., & Pherson, R. H. (2010; 3ª ed. 2019). *Structured Analytic Techniques for
+  Intelligence Analysis*. CQ Press.
+- Higham, R. (2016). "The MVP is dead. Long live the RAT."
+- Janis, I. L. (1972). *Victims of Groupthink*. Houghton Mifflin.
+- Kahneman, D. (2011). *Thinking, Fast and Slow*. FSG.
+- Kahneman, D., & Tversky, A. (1979). "Intuitive prediction: Biases and corrective
+  procedures."
+- Klein, G. (2007). "Performing a Project Premortem." *HBR* 85(9), 18–19.
+- Klein, G., Koller, T., & Lovallo, D. (2019). "Bias busters: Premortems: Being smart at the
+  start." *McKinsey Quarterly*, abr. 2019. (e "Knowing when to kill a project", jun. 2019)
+- Lovallo, D., & Kahneman, D. (2003). "Delusions of Success." *HBR*, jul. 2003.
+- McGrath, R. G., & MacMillan, I. C. (1995). "Discovery-Driven Planning." *HBR*, jul–ago 1995.
+- Mitchell, D. J., Russo, J. E., & Pennington, N. (1989). "Back to the future: Temporal
+  perspective in the explanation of events." *JBDM* 2(1), 25–38.
+- Nickerson, R. S. (1998). "Confirmation bias: A ubiquitous phenomenon in many guises."
+  *Review of General Psychology* 2(2), 175–220.
+- Platt, J. R. (1964). "Strong Inference." *Science* 146(3642), 347–353.
+- Popper, K. (1934/1959). *The Logic of Scientific Discovery*.
+- Ries, E. (2011). *The Lean Startup*. Crown Business.
+- Tetlock, P., & Gardner, D. (2015). *Superforecasting*. Crown.
+- Veinott, E. S., Klein, G., & Wiggins, S. (2010). "Evaluating the effectiveness of the
+  PreMortem technique on plan confidence." *ISCRAM 2010*, Seattle.
+- Zenko, M. (2015). *Red Team*. Basic Books.