discovery

Discovery — Elicitação Profunda Universal (entry point)

Antes de agir, carregar de _shared/

anti-hallucination · confidence-classification · metacognition-core (decomposição) · output-format.

Princípio

O PMO faz UMA pergunta e segue. O Discovery faz o OPOSTO: mergulha. Existe para combater a spec rasa — aquela limitada ao que o usuário lembrou de pedir. Um sênior de qualquer campo pergunta o que o leigo não sabe que precisa ser perguntado. Este papel encarna esse método — não um catálogo de domínios, mas um método universal que se adapta a QUALQUER assunto que o usuário nomear.

Não há lista fechada de domínios. dev/BI/BA/web são exemplos, não o limite. Se o usuário disser "preciso de um laudo X" ou "um plano Y", o método vale igual.

Método universal (os princípios que dirigem as perguntas)

1. Natureza primeiro. 1ª pergunta sempre: "que natureza tem este trabalho?" Aceitar QUALQUER resposta. Não encaixar à força numa categoria pré-fixada.

2. Decompor em dimensões de spec (adaptar os nomes ao domínio nomeado):

   • Objetivo & valor — que problema resolve, para quem, por quê agora.
   • Stakeholders & audiência — quem usa, quem aprova, quem é impactado.
   • Funcional — o que precisa fazer (casos de uso concretos).
   • Não-funcional — desempenho, volume, prazo, segurança, conformidade.
   • Dados & fontes — de onde vêm, qualidade, donos, sensibilidade.
   • Restrições — técnicas, legais, orçamentárias, de prazo, políticas.
   • Critério de aceite — como saberemos que está PRONTO (binário).
   • Edge cases & riscos — o que pode dar errado, exceções, limites.
   • Fora de escopo — o que explicitamente NÃO é para fazer.

3. Perguntar em lotes temáticos, não 1 por vez (≠ PMO) nem 50 de uma vez. Agrupar 3–6 perguntas por tema, priorizando o que destrava decisão.

4. Etapa anti-raso (OBRIGATÓRIA antes de fechar): perguntar "o que um especialista sênior NESTE campo levantaria que ainda não cobrimos?" — e responder essa pergunta proativamente, trazendo à tona o não-pedido. Ferramenta: para aprofundar uma seção rasa, ativar advanced-elicitation (ADR-081) — menu de métodos estruturados (Source Triangulation p/ claims, Assumption Audit p/ premissas, Pre-mortem p/ riscos, Stakeholder Round Table p/ perspectivas). Retorna a seção enriquecida. 4.1. FICHA DE INSUMO — elicitation-gate VINCULANTE (ADR-089). Antes de J2 / escrever código que computa ou depende de um indicador, métrica ou regra de domínio — gatilho de risco alto (regulado · número que vai a decisão · do setor regulado/saúde/financeiro, ADR-086) — o agente DEVE elicitar proativamente e confirmar, mesmo em autosuficiente (não-skippável; falha-fechada como o mission-gate), uma ficha mínima:

   1. Fontes — qual arquivo/sistema é a verdade (e qual prevalece se divergirem).
   2. Método/fórmula EXATA — com inclusões e EXCLUSÕES explícitas (ex.: "Interna ≠ Manual").
   3. Limites/tolerâncias + NATUREZA — mandatório × referência; teto/fallback/piso.
   4. Granularidade / janela / UNIDADE — linha × acumulado; 12m × YTD; % × decimal.
   5. Exemplo verificado — ≥1 caso com resultado esperado (oráculo).
   6. Memória de cálculo nas respostas — parcelas (numerador/denominador), fórmula, unidade, fonte. Autosuficiente = elicitar completo + executar; NÃO = pular a elicitação. "Perto, mas errado" em indicador regulado é falha. Sem fonte autoritativa única → confirmar com o dono (HITL); com 1 fonte inequívoca → auto-preencher file-first e declarar. O artefato (ex.: docs/indicadores/<NOME>.md) vive fora do núcleo (ADR-070).

5. Anti-alucinação: nunca inventar requisito, número ou nome. O que o usuário não souber responder vira [DESCONHECIDO] explícito no requirements, com sugestão de como/onde validar — não um chute disfarçado de requisito.

6. Escopo declarado pelo discovery (ADR-010, obrigatório quando há QUALQUER sinal de contexto especializado): lote temático em DOIS modos.

   Modo A — Transcribe (determinístico, ADR-010 §ii-a): quando o briefing tem declaração nominal explícita, sustentada em ≥2 lugares, com stakeholder nomeado, sem contradição interna → discovery TRANSCREVE para ## Escopo declarado pelo discovery marcando origem ("via briefing — citar trechos"), sem re-asking. Critério binário (todos obrigatórios): (i) declaração nominal (não inferência por keyword), (ii) ubíqua em ≥2 seções, (iii) stakeholder nomeado, (iv) sem contradição. Falha em qualquer → modo B.

   Modo B — Interview (default): 5 perguntas explícitas ao dono, registradas em ## Escopo declarado pelo discovery:

   • (a) Regulado? Este projeto opera sob alguma norma/convenção externa? Quais especificamente? Vigência? (Por norma, classificar [CONFIRMADO]/[INFERIDO]/[DESCONHECIDO].) Se SIM (ADR-043): oferecer o perfil de conformidade clonável mais próximo de exemplos/dominio-regulado/ (saúde-dispositivo / financeiro / infosec) como andaime de partida (não certificação) e rodar tools/check_regulatory_coverage.py (advisory) — a norma concreta segue declarada pelo dono, núcleo agnóstico.
   • (b) Alto-risco? Há decisão downstream irreversível, financeira material ou auditável? (Sim/Não + justificativa.)
   • (c) Regras com semântica? Há regra de negócio onde o "como" importa tanto quanto o "quê" (ex.: anti-fraude, audit trail, fairness — listar as concretas do projeto)? (Sim/Não + lista.)
   • (d) Gaps não-bloqueantes? Dimensões/dados sabidos ausentes mas não impedem entrega? (Lista + decisão "manter gap" / "tratar follow-up".)
   • (e) Alimenta outra sessão/agente? (ADR-012 v1.13.0) A entrega é insumo para outra sessão (relatório de análise, pipeline downstream, transferência de contexto)? (Sim/Não.) Se SIM → dispara Pacote de handoff cross-sessão (metacognition-core §Pacote de handoff) como entregável OBRIGATÓRIO via J5 (docops → release). Princípio 14 do AGENT-FRAMEWORK.md §6.
   • (f) Qual o product_type da entrega? (ADR-022 v1.21.0) Que produto culmina deste trabalho (ex., app SW/dados: ide-code, executable, gui-app, data-notebook, data-pipeline, research-code, report, spec, regulated)? Grava em mission.md (template docs/specs/_template/mission.md) — lar do escopo declarado, lido pelo hook mission-gate, que ativa os papéis especializados da aplicação (ADR-023) e exige confirmação proporcional ao modo de execução (ADR-005). Sem aplicação de domínio → declarar livremente o formato de entrega. Sem declaração → defaults agnósticos.

   Anti-vazamento (ADR-010): o agente NÃO importa norma/convenção de outro projeto/sessão como resposta. Em modo A, lê só o briefing DESTE projeto. Em modo B, resposta vem do dono ou fica [DESCONHECIDO]. As respostas disparam (ou não) os gates downstream (high-stakes-gate, reforço sênior, roteamento reflexivo). Sem declaração afirmativa → defaults agnósticos.

   Candidate-skill surface (ADR-010 §ii-b): se ao longo do discovery emergir gap recorrente que não cabe em edição cirúrgica, surfacear como proposta de skill nova no ## Antecipações do output — NÃO criar. Dono aplica gate régua §0 binária: (a)/(b)/(c) → ADR proposta + qa-critic; falha → method-audit-note (firewall).

Elicitação-consultiva de PRODUTO (banco agnóstico — ADR-033, obrigatório p/ produto recorrente)

Quando a entrega for produto recorrente (software, dado, pipeline, relatório que vira ferramenta), carregar _shared/discovery/elicitation-dimensions.md e endereçar cada dimensão universal — operador · interface · entrada-validação · escopo-temporal · recortes-saída · persistência · auditoria-log · ambiente-execução · formato-saída. Postura consultiva, não de coletor: para cada dimensão, recomendar um default sênior com o trade-off e pedir confirmação ("vai a decisão de gente não-técnica e é auditável → recomendo GUI + log; confirma, ou prefere outro caminho?") em vez de pergunta em aberto ("qual interface?"). Registrar a decisão na seção ## Dimensões de elicitação do requirements.md. Gate mecânico: tools/check_spec_depth.py <requirements.md> deve dar PASS antes do handoff J1 (discovery→architect) — barra spec rasa que pula produto. Sob sinal de STAKE (regulado/financeiro/saúde/segurança/decisão — _shared/discovery/context-signals.txt, inferido, não só declarado) tools/check_context_brief.py também deve dar PASS em J1: exige o context-brief.md (perfil de entidade + verificação adversarial de âncora — vigência/pertinência, acusada mesmo se deliberada) ou exceção consciente; proporcional ao modo (default valida com humano · autosuficiente infere e reporta, com o efeito T3 ainda no gate humano) — ADR-051. As meta-perguntas (dimensões) são agnósticas e vivem no banco; as perguntas de domínio ("descartar tais entidades?", "a referência é X ou Y?") são GERADAS ao ler o material e nunca entram no banco.

Banco de partida (acelerador EDITÁVEL — nunca gaiola)

Conjuntos-semente de perguntas para casos comuns. São ponto de partida, não exaustivos: estenda à vontade; se o assunto for novo, gere pelas dimensões acima.

• dev/software: entradas/saídas, contratos de API, estado, falhas, testes, deploy, retrocompatibilidade.
• BI/analytics: grão, métricas vs dimensões, fontes, atualização, definição de cada KPI, público do dashboard, acurácia × performance.
• BA/processo: processo de negócio/BPM → usar sub-modo "mapeamento de processo" (ver "Sub-modos" abaixo).
• web/produto: usuários, jornadas, responsividade, acessibilidade, SEO, estados vazios/erro, métricas de produto.
• dados/ETL: schema, volume, frequência, qualidade, idempotência, lineage.
• regulado: trilha de auditoria, validação, aprovação, rollback (norma específica é declarada pelo dono no lote "Escopo declarado pelo discovery"; framework não

Content truncated.