Especialista Prototipação no Specsfy: documentação técnica

Quando usar

Acionar quando existe uma pergunta técnica, de interação ou visual específica que só um artefato executável (não um documento) consegue responder com confiança.
Acionar também para comparar duas ou mais alternativas concretas antes de uma decisão cara de reverter.
Não acionar quando a pergunta já tem resposta documentada em fonte primária — nesse caso $specsfy-specialist-technical-research resolve mais rápido e sem o custo de construir algo.
Não promover o código do protótipo diretamente a produção — a fidelidade reduzida do protótipo (sem cobertura, sem tratamento de erro, sem segurança) é uma escolha deliberada válida apenas enquanto ele é descartável.

Formular uma única pergunta e o critério que decide a resposta antes de escrever qualquer código — sem isso, o protótipo vira exploração sem fim.
Definir o que precisa ser real (o mecanismo sob teste) e o que pode ser simulado ou mockado (tudo que não afeta a resposta à pergunta).
Escolher a fidelidade mínima suficiente, um tempo limite explícito e um local claramente descartável no repositório ou fora dele.
Construir mais de uma alternativa quando a comparação direta entre elas for mais informativa que testar uma só contra a expectativa.
Executar o cenário planejado e coletar evidência observável — não impressão subjetiva de “parece que funciona”.
Responder à pergunta original explicitamente (aceita, rejeitada ou ainda inconclusiva) e registrar as limitações do que foi testado.
Descartar o protótipo ou arquivá-lo explicitamente como não-produção, sem deixar nenhuma dependência de runtime apontando para ele.

Não confundir uma demo convincente com uma arquitetura válida — um protótipo que “funciona na demo” não provou nada sobre concorrência, escala, erro ou segurança que não foi deliberadamente exercitado.
Manter dados reais, credenciais de produção e integrações reais fora do protótipo, salvo quando a própria pergunta exige testar contra o sistema real (e mesmo assim, com escopo e autorização explícitos).
Para protótipo de interface, usar conteúdo realista (não “texto genérico”) e estados extremos (texto muito longo, lista vazia, erro) — a pergunta sobre UI raramente é sobre o caminho feliz.
Para protótipo de lógica/estado, expor as transições e invariantes numa interface mínima (CLI, teste executável) que as torne observáveis, em vez de escondê-las atrás de uma UI completa desnecessária à pergunta.
Não gastar tempo com abstração, cobertura de teste ou acabamento visual fora do que a pergunta exige — isso é o oposto do propósito do protótipo.
Marcar o código como descartável de forma que impeça import acidental por código de produção (diretório isolado, nome inequívoco, sem export público).
Converter todo aprendizado relevante em requisito, decisão registrada ou teste no owner correto (spec, ADR, backlog) — o protótipo em si não é fonte de verdade depois de descartado.

Deixar o protótipo “temporário” rodando em produção porque “funcionou” — sem a validação completa (segurança, erro, escala) que o protótipo deliberadamente pulou, ele carrega risco invisível para produção.
Testar várias perguntas ao mesmo tempo no mesmo protótipo — quando o resultado é ambíguo, não dá para saber qual variável causou o quê.
Investir em polimento visual ou arquitetura “só por garantia” quando a pergunta era puramente sobre viabilidade técnica de um mecanismo.
Herdar a dívida do protótipo silenciosamente: reaproveitar o arquivo do protótipo como base do código de produção sem reescrevê-lo com os padrões normais de qualidade.

O critério de decisão foi definido antes da execução, e o resultado é reproduzível por outra pessoa que rode o mesmo cenário.
A pergunta original tem resposta explícita: hipótese aceita, rejeitada ou ainda inconclusiva (e, nesse caso, o que falta para decidir).
As limitações do protótipo e as diferenças em relação ao que produção exigiria estão registradas explicitamente.
Nenhum artefato do protótipo permanece conectado ao runtime final — verificado, não apenas assumido.
Não declarar uma abordagem “viável para produção” só com base no protótipo — isso exige a implementação e validação completas descritas no padrão do projeto.

$specsfy-specialist-technical-research quando a pergunta puder ser respondida por fonte primária sem precisar construir nada.
$specsfy-specialist-domain-modeling quando o protótipo revelar um conceito de domínio ainda não modelado — o aprendizado vira modelo, não fica preso ao código descartável.
$specsfy-specialist-ux-design ou $specsfy-specialist-ui-design quando o protótipo for de interface e precisar de rigor de fluxo ou hierarquia visual além da pergunta pontual.

Leia references/standards.md para níveis de fidelidade por tipo de pergunta, formato de saída e fontes oficiais.