Exemplo com um pedido real seu. O interview roda NO CHAT, uma pergunta por mensagem; esta página mostra o formato: perguntas ordenadas por blast radius, e o payoff no final.
o pedido vago que dispara o interview
"quero poder editar as idades dos CPs no registro em lote, tipo um slider de 45 a 55 dias"
7 ambiguidades detectadas · ordenadas por impacto na arquitetura · 3 mostradas aqui
a conversa · uma pergunta por vez
case · pergunta 1blast radius: muda o modelo de dados
Editar a idade de um CP que já tem ruptura lançada nessa idade: pode, não pode, ou pode com aviso?
pode semprebloqueia se já rompeupode com aviso
miguel
bloqueia, ruptura lançada é imutável (regra da selagem)
→ essa resposta matou 2 perguntas sobre recálculo de resultados e definiu a validação do backend.
case · pergunta 2blast radius: muda o fluxo de UX
O slider 45-55 vale pro lote inteiro ou é ajuste por CP individual?
lote inteiropor CPos dois
miguel
lote inteiro, o laboratorista define o plano de idades uma vez
case · pergunta 3blast radius: muda escopo
Isso vale só pro range 45-55 ou as idades padrão (7, 14, 28) também viram editáveis?
só o range novotudo editável com padrão sugerido
miguel
tudo editável, mas com os padrões já preenchidos
o que as respostas destravaram
pergunta
decisão que saiu
onde pega
1 · ruptura lançada
Validação no backend: idade com ruptura é imutável
constraint + mensagem na UI
2 · lote vs CP
Controle único no topo do lote, sem edição por linha
UX do /bulk-registration
3 · escopo
Todas as idades editáveis, padrões pré-preenchidos
escopo dobrou de forma consciente, não por acidente
o payoff · o prompt que você teria escrito
Seu pedido, sabendo tudo desde o início
"no /bulk-registration, deixa o plano de idades editável no nível do lote (não por CP), com os padrões 7/14/28 pré-preenchidos e range livre tipo 45-55. Validação no backend: idade que já tem ruptura lançada é imutável, bloqueia com mensagem. Nada de recálculo retroativo."