Especialista Pesquisa técnica no Specsfy: fluxo e validação

Quando usar

Acionar quando uma decisão de arquitetura, biblioteca ou abordagem depende de um fato técnico que ninguém confirmou com fonte primária.
Acionar também para comparar alternativas antes de uma decisão cara de reverter, ou para verificar se um comportamento assumido ainda é válido na versão atual de uma dependência.
Não acionar para reconfirmar uma escolha já decidida só para produzir justificativa — isso é viés de confirmação, não pesquisa.
Combinar com $specsfy-specialist-software-architecture quando a pesquisa embasar diretamente uma decisão estrutural registrável em ADR.

Formular a pergunta específica, a decisão que ela vai suportar, o escopo e a recência necessária (comportamento de hoje, ou histórico é suficiente?).
Definir de antemão que evidência confirmaria ou refutaria cada alternativa — sem isso, qualquer resultado parece confirmar a hipótese inicial.
Priorizar, nesta ordem: especificação/standard, documentação oficial versionada, código-fonte e changelog oficiais, experimento reproduzível no ambiente alvo, e só então fonte secundária.
Verificar versão, data de publicação e aplicabilidade ao ambiente real observado no projeto — um comportamento documentado para outra versão não é evidência para a versão em uso.
Triangular toda afirmação crítica para a decisão com uma segunda fonte independente, e executar experimento controlado quando a documentação não resolver a dúvida.
Separar explicitamente fatos confirmados, inferências (prováveis mas não confirmadas), riscos e lacunas que permanecem sem evidência.
Sintetizar com links diretos à fonte, próximos à afirmação específica que sustentam, e a implicação concreta para a decisão em jogo.

Não usar snippet de fórum, blog pessoal ou resposta de IA genérica como autoridade sobre comportamento de API quando existe fonte primária acessível — usar como pista para onde procurar a fonte primária, não como citação final.
Citar a página e a seção específica da fonte próxima da afirmação, não um link genérico para a home da documentação.
Sintetizar preservando o contexto necessário para a decisão, evitar transcrição extensa que apenas desloca o trabalho de leitura para depois.
Registrar versão e data de qualquer fonte cujo comportamento pode mudar entre releases — sem isso, a conclusão expira silenciosamente.
Quando duas fontes conflitam, declarar o conflito explicitamente em vez de escolher uma silenciosamente sem justificar por que ela prevalece.
Não criar um research.md paralelo à fonte normativa do projeto, a pesquisa é indexada e vive no local que a spec do projeto consumidor define.
Tratar benchmark publicado por fornecedor da própria tecnologia como evidência interessada — útil como ponto de partida, nunca como conclusão final sem reprodução independente.

Pesquisar depois de já ter decidido, buscando apenas confirmação — a pergunta formulada no passo 1 já nasce enviesada (“por que X é melhor”, em vez de “X ou Y, e sob que critério”).
Citar “a documentação diz” sem link nem versão — torna a afirmação impossível de reverificar quando o comportamento mudar.
Copiar benchmark de marketing de um fornecedor como se fosse medição neutra do ambiente do projeto.
Resolver uma pergunta com múltiplas fontes conflitantes escolhendo a que confirma a preferência inicial, sem registrar que havia conflito.

Cada conclusão que sustenta a decisão tem evidência direta e rastreável (link + versão + data), não apenas afirmação de memória.
As fontes usadas correspondem à versão e ao runtime real do projeto consumidor, não a uma versão genérica ou desatualizada.
Experimentos executados são reproduzíveis por outra pessoa e não alteram produção nem dado real.
Lacunas e incerteza residual estão explícitas na síntese final, não escondidas atrás de uma conclusão mais confiante do que a evidência permite.
Não apresentar uma hipótese não triangulada como fato — linguagem que implica certeza sem a evidência correspondente é proibida.

$specsfy-specialist-domain-modeling usa fontes externas para alinhar conceitos sem substituir o vocabulário validado do domínio.
$specsfy-specialist-prototyping transforma incerteza técnica em experimento descartável com hipótese e critério de parada.
$specsfy-specialist-software-architecture quando a pesquisa embasar uma decisão estrutural registrável em ADR.
$specsfy-specialist-laravel-package-manager quando a pesquisa precisar confirmar documentação, versão ou instalação de um pacote Composer Laravel.
$specsfy-specialist-debugging quando a “pesquisa” for, na verdade, investigar por que um comportamento observado diverge do documentado — nesse caso o diagnóstico de causa raiz é o objetivo, não a comparação de alternativas.

Leia references/standards.md para a hierarquia de fontes, a matriz de avaliação de evidência e o formato de síntese.