Falsa segurança e suficientemente bom

O mínimo precisa cumprir um compromisso

Suficientemente bom significa atender aos critérios do recorte declarado com limites conhecidos e risco residual aceitável. Não significa aceitar qualquer coisa porque o prazo acabou. Também não significa esperar por todo aprimoramento imaginável. O trabalho de engenharia consiste em identificar o essencial, produzir evidência adequada e decidir se as lacunas restantes permitem o próximo uso pretendido.

Produto Mínimo Verificável, ou PMV, é o nome usado neste método para um fluxo mínimo realmente executável e avaliável. Um desenho pode ajudar a escolher a interface, mas não demonstra leitura dos dados ou tratamento de falhas. Um teste de uma função pode demonstrar sua regra, mas não comprova sozinho o caminho completo do navegador ao servidor. A evidência deve acompanhar exatamente a afirmação feita.

Caso trabalhado do catálogo

O recorte deste caso é a capacidade catálogo da Oficina Caracol. Seus itens obrigatórios são REQ-001 a REQ-004: listar ativos, não revelar inativos, apresentar estados vazio e inválido e verificar navegação por teclado e feedback acessível. REQ-005 continua obrigatório para a capacidade de reserva e para uma entrega que anuncie o conjunto completo. Retirá-lo deste gate específico não autoriza anunciar reservas prontas.

O código abaixo é uma verificação isolada compatível com o pacote, executável dentro de pratica em contexto de módulo JavaScript. Na preparação desta revisão, o trecho foi executado isoladamente com Node e a asserção passou. Ele confirma essa entrada específica, não a interface nem todos os dados possíveis.

import assert from 'node:assert/strict';
import { listarAtivos } from './src/catalogo.mjs';
const entrada = [{
  id: 'oc-inativo', titulo: 'Serviço em revisão',
  descricao: 'Exemplo didático que não deve ser publicado.', ativo: false
}];
assert.deepEqual(listarAtivos(entrada), []);

Procedimento de suficiência

• Defina a capacidade e seu conjunto de itens obrigatórios antes de avaliar maturidade. Deixe explícitas exclusões e futuras entregas.
• Ligue cada critério a uma verificação e registre versão, ambiente, resultado e limite. Um teste planejado não possui o mesmo estado de um teste aprovado.
• Separe falha impeditiva, lacuna não impeditiva e melhoria desejável. Considere o uso autorizado, não somente o esforço de correção.
• Peça à autoridade responsável que aceite o risco residual das lacunas não impeditivas, com prazo ou gatilho de revisão. Um aluno não deve inventar essa aceitação em nome de outra pessoa.
• Libere apenas o alcance sustentado pelas evidências. Se o pacote é de estudo local, não transforme esse gate em autorização de produção.

Erros e reparos específicos

• Um checklist marcado sem anexar o resultado gera confiança sem sustentação. Reparo: retornar cada marca ao registro que explica a verificação ou recolocá-la como pendente.
• Ocultar uma lacuna para melhorar o veredito elimina a condição de aceitação do risco. Reparo: tornar a lacuna visível e pedir decisão sobre seu impacto.
• Ampliar a publicidade da entrega além do escopo altera o risco sem nova revisão. Reparo: ajustar a afirmação ou ampliar as verificações antes de assumir o compromisso.

Gate e exercício resolvido

O avanço exige critérios obrigatórios atendidos ou exceção explícita não impeditiva compatível com o uso autorizado. Resultado medido, relatório escrito e risco apenas listado não bastam. Se uma evidência obrigatória for invalidada por mudança relevante, reabra a avaliação correspondente.

Exercício: testes de catálogo e servidor passam; o estado vazio aparece; um botão não recebe foco por teclado; animações ainda não foram adicionadas. O grupo quer liberar uma demonstração pública como plenamente acessível. Classifique cada item.