ANALYZE: classifique o gap, avalie, escolha UMA unidade

Por que “uma unidade delimitada” é estrutural, não estilístico

Uma unidade delimitada é a menor mudança que é independentemente verificável no boundary real. O limite é o que permite ao VERIFY (lição 6) fazer uma afirmação limpa: este teste passou de pulado para verde, este endpoint agora devolve 400, nada mais mudou. Se uma unidade junta dois comportamentos, uma falha fica ambígua — você não consegue dizer qual metade regrediu sem desfazer tudo. Escolher uma, portanto, não é conselho de produtividade; é o que mantém o proof gate significativo e o loop depurável.

ANALYZE consome a saída do LEARN e nada mais

O ANALYZE só pode raciocinar sobre fatos fundamentados — o retrato que o LEARN estabeleceu. Ele não vai olhar de novo (isso foi o LEARN) e não edita (isso é o EXECUTE). Se uma avaliação precisa de um fato que você não tem, isso é um sinal para voltar ao LEARN, não para chutar. Manter os passos separados é o que impede que “análise” vire silenciosamente “comecei a consertar”.

A saída é uma decisão somada às suas razões

Uma passada de ANALYZE concluída produz uma unidade escolhida e uma justificativa curta e legível: em qual balde cada gap caiu, como os principais candidatos foram avaliados, e por que este venceu. Essa justificativa é observabilidade — ela cai no LOOP-LOG.md para que o humano possa ler a decisão sem ter de derivá-la de novo (lição 7).

O teste para cada balde

On-scope: o contrato done-when (lição 2) exige isso? Se sim, e não está bloqueando nada urgente, é trabalho normal na fila. Do-now: a unidade atual seria impossível ou não confiável sem isso? Um runner de testes quebrado, uma dependência faltando, um baseline vermelho que você senão confundiria com a sua própria quebra — esses passam na frente porque envenenam o VERIFY. Needs-user: existe uma bifurcação genuína que só o humano pode resolver — uma escolha de produto, uma ação irreversível, uma ambiguidade que o escopo não fixou? Então é um repasse, pronto para decisão (lição 9), não um chute. Out-of-scope: é real mas fora desta meta? Estacione onde não vai se perder, e siga em frente.

Out-of-scope é registrado, nunca descartado em silêncio

“Fora de escopo” não quer dizer “ignore”. Um item estacionado é anotado (uma nota no backlog, um ticket de follow-up) para que a trilha de observabilidade fique honesta e nada real evapore. O loop pode não fazer algo; ele não pode fingir que não viu.

Needs-user é o único balde que pode bloquear o humano

Todo o resto roda AFK. O contrato da suíte inteira é que o humano apenas observa — ele lê o log, não executa. A única exceção é uma bifurcação needs-user: o loop pausa e repassa uma pergunta pronta para decisão (nunca um chute meio construído). Esse repasse é o único ponto em que um humano está no caminho, e é deliberadamente raro.

O quadro é um classificador um-de-quatro

Cada gap é um objeto com um campo col restrito aos quatro baldes. As colunas na tela não são a fonte da verdade — o array é — então um cartão fisicamente não pode estar em dois baldes e as contagens nunca desviam. Isso espelha a disciplina exatamente: classificação é uma função de um gap para uma única categoria, não um achismo. A contagem de “acionáveis agora” soma as duas primeiras colunas, porque esses são os únicos gaps que merecem uma avaliação na próxima seção.

De onde isto retoma a partir da lição 3: o quadro do LEARN terminou com observações confirmadas; este quadro pega esses mesmos itens e atribui um balde a cada um. Confirme primeiro (LEARN), classifique depois (ANALYZE) — os dois quadros são os dois passos, em ordem.

Os cinco eixos

Encaixe — quão diretamente a unidade serve ao done-when. Uma unidade que satisfaz diretamente uma linha do contrato pontua alto; um “seria legal ter” tangencial pontua baixo mesmo que seja tentador. Risco — a chance de quebrar outra coisa ou inchar além do seu limite (risco alto é ruim, então conta contra). Prova — quão limpo o VERIFY consegue confirmar isso no boundary real: uma unidade com um teste esperando pontua alto; uma cuja única prova é “parece certo” pontua baixo. Bloqueio — há algo que impede de começar agora mesmo (um fato faltando, uma bifurcação needs-user, uma suíte de testes não rodada)? Um bloqueio ativo pode vetar uma unidade que de resto seria ótima. Próximo — quanto concluí-la destrava depois; uma unidade pequena que abre o caminho para mais três pesa acima da sua categoria.

Por que Risco é o eixo que as pessoas leem errado

Iniciantes avaliam unidades por empolgação (“isso seria legal”). A rubrica força em vez disso as perguntas sem glamour: consigo provar, vai quebrar o build, está mesmo destravado. Uma unidade de Encaixe alto com um Bloqueio ativo não é a próxima jogada — o bloqueio é. Essa reordenação é a maior parte do valor de avaliar.

A rubrica é uma heurística, não uma fórmula

Você não está somando os eixos num número preciso; está usando-os para tornar o trade-off legível. Uma unidade com Encaixe estelar mas sem Prova deveria te deixar nervoso, e a rubrica é o que traz isso à tona antes que você afunde uma passada nela. O scorecard na próxima seção torna a pesagem tangível.

Dois eixos independentes, como variante × tamanho

Cada cartão carrega suas avaliações cruas em atributos data (data-fit, data-risk, data-proof). Ordenar reordena os cartões pelo eixo escolhido e acende o líder — exatamente como uma galeria de componentes deixa você comparar uma variante ao longo de um eixo de tamanho. A ordenação “geral” usa uma pontuação simples e legível: Encaixe e Prova somam, Risco subtrai, e um Bloqueio ativo limita o resultado. O cartão A vence não por ser o mais ambicioso, mas por ser o mais entregável agora: Encaixe alto, Prova alta, Bloqueio zero.

Os cartões perdedores não estão errados — estão em outro lugar

O cartão B é a clássica armadilha de scope-creep: uma melhoria real que incha o risco e não prova nada que o guard já não prove. O cartão C é genuinamente valioso mas vive em needs-user — é um repasse, não a unidade desta passada. Avaliar não só acha o vencedor; te diz por que cada perdedor é estacionado ou repassado, que é a justificativa que cai no log.

Uma ponderação legível, não uma caixa-preta

A pontuação é deliberadamente simples para você poder prevê-la: value = Fit + Proof − Risk, limitada a 0–100. Acima de ~120 cru ela lê “escolher agora” (verde), no meio “talvez”, e baixo “adiar”. O slider de Bloqueio é especial — acione-o e o veredito é forçado a adiar independente do resto, porque um bloqueio ativo significa que a unidade literalmente não pode começar. Esse veto duro codifica a regra mais afiada da rubrica: um bloqueio vence uma pontuação alta toda vez.

function score(fit, risk, proof, blocked) {
  if (blocked) return { v: 0, verdict: 'defer' };  // hard veto
  const v = clamp(fit + proof - risk, 0, 200);
  return { v, verdict: v >= 120 ? 'go' : v >= 70 ? 'maybe' : 'defer' };
}

Mova os botões para o preset do guard e você cairá fundo no verde; mova para o preset da reescrita do índice e Risco alto somado a Prova baixa o arrastam para adiar — os mesmos vereditos que os cartões alcançaram, agora pelas suas próprias mãos.

Delimitar pela provabilidade, não pela ambição

As três unidades melhorariam o RHG. O desempate é o proof gate: a unidade A mapeia um-para-um num teste existente, então o VERIFY consegue fazer uma afirmação inequívoca. A unidade C junta seis comportamentos, então uma falha é um mistério e o humano que observa não consegue dizer o que mudou. A preferência do loop pela menor mordida provável não é timidez — é o que mantém cada passada depurável e cada afirmação honesta. A unidade C não é rejeitada; ela é re-moldada em seis unidades enfileiradas, uma por endpoint irmão, cada uma sua própria passada futura.

A abstração tem uma “regra do dois”

A unidade B extrai um helper antes de existir um segundo chamador, o que é generalidade especulativa — risco sem retorno presente. Se o LEARN tivesse mostrado dois endpoints já precisando do guard hoje, o reúso de B seria real e sua avaliação subiria. A rubrica só dá crédito ao reúso que você consegue apontar, não ao reúso que você imagina.

O que fazer em cada quadrante

Superior esquerdo (alto encaixe, baixo risco) — escolha agora; este é o ponto ideal. Superior direito (alto encaixe, alto risco) — o trabalho importa mas a mordida é grande demais ou perigosa demais; divida em unidades menores e prováveis e escolha a fatia mais segura. Inferior esquerdo (baixo encaixe, baixo risco) — preenchimento inofensivo; é seguro mas não move o done-when, então espera. Inferior direito (baixo encaixe, alto risco) — evite; muito perigo por pouco valor. A matriz é uma primeira passada rápida; Prova, Bloqueio e Próximo depois desempatam entre os sobreviventes.

Por que a reescrita do índice fica no inferior direito

Ela pontuou Encaixe baixo (o guard já satisfaz a linha do contrato) e Risco alto (toca todo chamador sem teste esperando). Esse é o quadrante de evitar — não porque seja uma má ideia para sempre, mas porque como a unidade desta passada é a pior troca no quadro.

A abordagem é parte do ANALYZE, não do EXECUTE

Escolher como construir a unidade ainda é análise — muda Risco e Prova, então pertence antes de qualquer código ser escrito. Os três diagramas vêm em um único SVG inline; a tablist troca qual <g data-diagram> é mostrado e reescreve a legenda e o aria-label, com foco itinerante por setas conforme o padrão de abas do WAI-ARIA. Para o RHG, a abordagem A vence do mesmo jeito que a unidade A venceu: maior Encaixe e Prova, menor Risco. O decorator só vira a decisão certa quando um segundo chamador real existe; o middleware exagera o escopo e arrasta rotas que não têm query nenhuma.

O plano é moldado em torno do proof gate

Note que a última fase não é “entregue” — é “passe na barra de saída”. A barra de saída é um gate mensurável: um teste específico indo de pulado para verde, o resto da suíte permanecendo verde, o endpoint devolvendo 400. “Parece certo” não é um gate. Moldar a unidade assim no momento do ANALYZE significa que o EXECUTE sabe precisamente o que é sucesso, e o VERIFY (lição 6) tem uma coisa inequívoca para provar. A barra de marcos é uma pequena tablist conduzida por estado por passo; numa execução real esses estados refletiriam o tracker ao vivo, não o plano como escrito.

Uma unidade, quatro pequenos passos — ainda uma unidade

Reproduzir → adicionar guard → tirar skip do teste → provar não são quatro unidades; é a forma interna de uma mudança delimitada. Cada passo é uma leitura ou uma edição mínima que constrói rumo a um único desfecho provável. Essa é a diferença entre um plano para uma unidade e um plano de projeto.

Acesse você mesmo

A justificativa do ANALYZE vive no arquivo de observabilidade da execução — tipicamente LOOP-LOG.md na raiz do repo. Leia-o com sed -n '1,40p' LOOP-LOG.md ou salte para a última passada com grep -n "ANALYZE" LOOP-LOG.md | tail -1. Ele é append-only: cada passada adiciona seu bloco de classificar / avaliar / escolher para que o histórico de decisões seja auditável.

Crucialmente não há comandos de edição aqui — uma passada de ANALYZE é decisão pura. Se você algum dia vir uma mudança de arquivo atribuída ao ANALYZE, o passo vazou para o EXECUTE; esse é o boundary que o loop mantém limpo (lição 5). E qualquer fato externo em que uma avaliação se apoiou é fundamentado do único jeito permitido — o Bright Data CLI (lição 11), nunca a memória, nunca WebSearch/WebFetch.

A passada, como ela cai para o humano observar

Todo o sentido é uma decisão legível que o humano lê sem refazê-la (a observabilidade sobre a qual a suíte roda — lição 7). Só decisão; cada avaliação tem uma razão, cada gap encaminhado tem um destino.

# ANALYZE result — fix/empty-query
chosen unit : add empty-query guard (inline, /search)
rationale   : Fit 92 · Risk 18 · Proof 95 · blocker none
handoff     : status code 400 vs 422 → decision-ready to user
parked      : index-layer rewrite → backlog#214
deferred    : 5 sibling endpoints → one unit each, later passes
files changed: 0   # ANALYZE never edits