Evidências de teste
Resultado comercial também depende de prova. Se o comprador não consegue confiar no que foi testado, ele paga com retrabalho, tempo perdido, decisões ruins e correções que deveriam ter sido evitadas.
Os testes do portfolio NoDrift foram executados em estrutura, comportamento de startup, fonte da verdade, controle de aprovação, tratamento de correções, limites de privacidade, segurança de instalação, geração de evidência e startup em estilo de comprador. Esta matriz pública resume os resultados sem expor registros privados de build nem caminhos locais.
Resumo de pontuação seguro para o público
Várias rodadas, não uma passagem simples
Rodadas anteriores de benchmark pontuaram na faixa alta dos noventa, incluindo 98/100 e 96/100, com uma execução estática de quatro níveis tendo média de 95,83/100. Depois de correções e ajustes manuais, a suíte expandida estática e de simulação Demonstrator/Basic passou em 52/52 checagens com média de 100/100 sob a regra desse scorecard.
Para o comprador, essa evidência protege o comprador porque reduz a chance de pagar por promessa sem teste, afirmação exagerada, instalação confusa ou governança que parece boa no texto mas falha no uso.
Respostas de evidência ligadas às histórias
Estes blocos explicam por que links das histórias chegam aqui. Cada resposta aponta para a situação exata da história e para o tipo de evidência que NoDrift exige antes de aceitar uma afirmação como segura.
“Mapeamento de evento errado” não é resposta suficiente.
Problema da história: Os assistentes produziram teorias polidas para a falha entre dashboard e relatórios, incluindo mapeamento de evento errado, mas nenhuma teoria partiu de fonte da verdade verificada.
Resposta NoDrift: Uma teoria de correção só pode avançar quando a sessão mostra qual fonte real foi checada, qual evento existe, qual campo foi comparado, qual teste sustenta a hipótese e qual parte continua sem prova.
Resultado esperado: A equipe não perde horas testando uma explicação elegante que apenas combina com uma estrutura falsa. Primeiro vem evidência de fonte; depois vem correção.
Texto de produção precisa corresponder ao que existe.
Problema da história: A IA reescreveu o dashboard como se o portal já estivesse pronto para produção, prometendo troca segura de documentos, rastreamento em tempo real e operações automatizadas.
Resposta NoDrift: Antes de linguagem pública ou de cliente, NoDrift exige separar construído, simulado, planejado e não aprovado. O texto só pode afirmar o que a evidência do projeto sustenta.
Resultado esperado: A página não cria promessas comerciais falsas, e Lena não precisa gastar a tarde desfazendo linguagem que parecia profissional, mas não era verdadeira.
Construído, mock, planejado e aprovado são estados diferentes.
Problema da história: Lena precisou parar de programar para descobrir o que realmente existia, o que era mock, o que era plano e o que o cliente havia aprovado.
Resposta NoDrift: NoDrift mantém esses estados separados durante o trabalho. Uma sessão governada não deve misturar rascunho, protótipo, promessa, plano futuro e entrega real no mesmo status.
Resultado esperado: O comprador consegue ver por que a governança reduz retrabalho: decisões e evidências ficam ligadas ao estado real do projeto, não ao texto mais convincente da conversa.
Gráfico de pontuação
Trilhas do portfolio
Demonstrator e Basic
- Basic Codex checado em 10 níveis de prontidão.
- Inventário de fonte e caminhos do mapa de instalação verificados.
- Rótulos de rascunho voltados ao comprador corrigidos.
- Afirmações de auditoria e evidência sem suporte foram estreitadas.
- Manifesto de entrega do comprador adicionado e verificado.
- Simulação de instalação local limpa aprovada.
- Teste ao vivo de startup Basic em estilo de comprador aprovado.
- Codex Demonstrator foi reduzido a partir do Basic para a amostra aprovada de comportamento em cinco arquivos.
- O comportamento do Demonstrator para resposta direta, diretiva delimitada e aprovação por go foi retestado ao vivo e aprovado.
Checagens iniciais e expandidas
- A primeira passagem estática/de instalação do Claude Code Basic pontuou 10/10.
- Arquivos obrigatórios presentes.
- Arquivos de configurações analisados corretamente.
- Nenhum hook Basic ativo enviado.
- Nenhum subagente de projeto Basic enviado.
- Termos de fonte de startup presentes.
- Travas de aprovação e ação externa presentes.
- Cópia em pasta limpa preservou arquivos obrigatórios.
- Orientação de instalação bloqueou sobrescrita cega de arquivos de startup existentes.
- Afirmações de prontidão sem suporte estavam ausentes.
- Design específico para Claude checado contra a nota do adaptador.
Rodadas de teste do portfolio
| Fase do teste | O que foi checado | Resultado registrado | Limite público |
|---|---|---|---|
| Simulação estática/de instalação inicial do Claude Code Basic | Arquivos obrigatórios, parsing de configurações, nenhum hook ativo, nenhum subagente de projeto, termos de startup, travas de aprovação, comportamento de cópia limpa, segurança de conflito de instalação, segurança de afirmações e design específico para Claude. | 10/10 aprovados | Evidência estática e de simulação de instalação. |
| Execução estática anterior de quatro níveis | Estrutura de protótipo e prontidão de controle de Demonstrator, Basic, Extended e Teams antes das correções posteriores. | Média 95,83/100 | Execução estática anterior, não evidência final de prontidão de venda por si só. |
| Itens anteriores de correção de benchmark | Testes específicos de guardrail de benchmark após a passagem de correção identificada nos registros de trabalho. | 98/100 and 96/100 | Evidência granular de benchmark, separada da passagem posterior de 52 testes. |
| Simulação estática expandida Demonstrator/Basic | Estrutura, configurações, startup, fonte da verdade, travas de aprovação, privacidade, afirmações de prontidão, segurança de instalação, memória, correções, continuidade, pacote de testador e saída de evidência. | 52/52 aprovados; Média 100/100 | Evidência local estática/de simulação, não uma afirmação de comportamento ao vivo em todos os apps. |
| Revisão de prontidão de venda do Basic Codex | Inventário de fonte, caminhos de instalação, redação para comprador, limites de afirmação, controles de aprovação, comportamento de mapa de tópicos, protocolo de erro, manifesto de entrega, simulação de instalação e comportamento de startup. | 10 níveis de prontidão checados | Evidência de prontidão de venda da fonte e startup de comprador para Codex Basic. |
| Startup do Codex Basic em estilo de comprador | Teste Codex em projeto novo usando o comando de startup e os arquivos de portfolio instalados. | Passed | Comportamento de startup Codex observado para Basic. |
| Startup do Codex Demonstrator em estilo de comprador | Respostas diretas, próximas diretivas delimitadas, travas de aprovação por go e intake de descrição do projeto. | Passed | Comportamento de startup Codex observado para Demonstrator. |
| Passagem de prontidão com ajustes manuais | Rótulos voltados ao comprador, manifesto de entrega, limpeza de afirmações sem suporte, redação público/privado, redução do Demonstrator, preservação da trava de go e redação final de prontidão. | Completed | Corrigiu os portfolios master Demonstrator e Basic para a posição atual de prontos para venda/prontos para venda da fonte. |
Scorecard expandido de 52 testes
Este scorecard usou PASS = 100, PARTIAL = 50 e FAIL = 0. Todo teste listado recebeu pontuação PASS na execução estática/de simulação expandida posterior.
| ID | Category | Nome do teste | Score |
|---|---|---|---|
| CC-SIM-001 | Estrutura | Raiz candidata existe | 100/100 |
| CC-SIM-002 | Estrutura | Arquivos raiz obrigatórios existem | 100/100 |
| CC-SIM-003 | Estrutura | Pastas obrigatórias de nível superior existem | 100/100 |
| CC-SIM-004 | Estrutura | Pastas de instrução obrigatórias existem | 100/100 |
| CC-SIM-005 | Estrutura | Regras obrigatórias existem | 100/100 |
| CC-SIM-006 | Estrutura | Skills obrigatórias existem | 100/100 |
| CC-SIM-007 | Estrutura | Módulos de governança obrigatórios existem | 100/100 |
| CC-SIM-008 | Estrutura | Templates obrigatórios de memória do projeto existem | 100/100 |
| CC-SIM-009 | Configurações | Configurações do projeto são analisadas corretamente | 100/100 |
| CC-SIM-010 | Configurações | Exemplo de configurações locais é analisado corretamente | 100/100 |
| CC-SIM-011 | Configurações | Configurações de permissão existem | 100/100 |
| CC-SIM-012 | Configurações | Negações de publicação externa e push existem | 100/100 |
| CC-SIM-013 | Configurações | Nenhuma orientação de bypass ou modo automático existe | 100/100 |
| CC-SIM-014 | Hooks | Basic não envia hooks ativos | 100/100 |
| CC-SIM-015 | Subagents | Basic não envia subagentes de projeto | 100/100 |
| CC-SIM-016 | Startup | Arquivo de startup exige confirmação da raiz | 100/100 |
| CC-SIM-017 | Startup | Arquivo de startup lê memória do projeto | 100/100 |
| CC-SIM-018 | Startup | Comportamento de startup existe | 100/100 |
| CC-SIM-019 | Source fidelity | Regra de fidelidade à fonte existe | 100/100 |
| CC-SIM-020 | Source fidelity | Registro de fontes exclui memória do chat | 100/100 |
| CC-SIM-021 | Aprovação | Regra de go delimitado existe | 100/100 |
| CC-SIM-022 | Aprovação | Regra de acesso-não-é-permissão existe | 100/100 |
| CC-SIM-023 | Aprovação | Ações externas têm trava | 100/100 |
| CC-SIM-024 | Public/privado | Regra público/privado existe | 100/100 |
| CC-SIM-025 | Readiness | Trava de afirmação de prontidão existe | 100/100 |
| CC-SIM-026 | Verification | Regra de verificação existe | 100/100 |
| CC-SIM-027 | Install safety | Conflito com arquivo de startup existente tem trava | 100/100 |
| CC-SIM-028 | Install safety | Conflito com configurações existentes tem trava | 100/100 |
| CC-SIM-029 | Install safety | Conflito com pasta de memória existente tem trava | 100/100 |
| CC-SIM-030 | Memory | Template de Living Topic Map tem as seções obrigatórias | 100/100 |
| CC-SIM-031 | Memory | Template de estado do projeto tem limites | 100/100 |
| CC-SIM-032 | Corrections | Template de lições ativas existe | 100/100 |
| CC-SIM-033 | Corrections | Registro master de correções existe | 100/100 |
| CC-SIM-034 | Continuidade | Orientação de compactação e handoff existe | 100/100 |
| CC-SIM-035 | Common protocol | Referência ao protocolo comum está presente onde apropriado | 100/100 |
| CC-SIM-036 | Tier clarity | Status candidato está claramente rotulado | 100/100 |
| CC-SIM-037 | Claim safety | Afirmações de prontidão sem suporte estão ausentes | 100/100 |
| CC-SIM-038 | Internal leakage | Pacote para amigo exclui memória privada de build | 100/100 |
| CC-SIM-039 | Clean copy | Cópia de instalação limpa preserva arquivos obrigatórios | 100/100 |
| CC-SIM-040 | Conflict simulation | Conflito com arquivo de startup é detectado pela documentação | 100/100 |
| CC-SIM-041 | Skills | Checklist de startup existe | 100/100 |
| CC-SIM-042 | Skills | Skill de checkpoint protege continuidade | 100/100 |
| CC-SIM-043 | Skills | Skill de checagem de fonte protege autoridade da fonte | 100/100 |
| CC-SIM-044 | Package map | Mapa de pacote lista superfícies importantes | 100/100 |
| CC-SIM-045 | Git hygiene | Regras de ignore protegem arquivos locais/privados | 100/100 |
| CC-SIM-046 | Tester packet | Pasta de pacote de testador existe | 100/100 |
| CC-SIM-047 | Tester packet | README do testador existe | 100/100 |
| CC-SIM-048 | Tester packet | Checklist de CLI existe | 100/100 |
| CC-SIM-049 | Tester packet | Template de relatório de resultado existe | 100/100 |
| CC-SIM-050 | Tester packet | Limites do testador são explícitos | 100/100 |
| CC-SIM-051 | Tester packet | Pacote não está zipado | 100/100 |
| CC-SIM-052 | Evidência | Executor de testes grava evidência legível por máquina | 100/100 |
O que as pontuações significam
As pontuações mostram passagens repetidas estáticas, de simulação, correção e startup de comprador. Não são edições casuais de texto nem checagens pontuais de pacote de prompts.
O que elas não afirmam
A evidência pública não afirma comportamento garantido de IA, controle rígido do LLM, certificação de segurança ou verificação ao vivo em todos os apps suportados.
Por que isso importa
NoDrift é governança de workspace no lado da recepção. Os testes focam se o portfolio dá à IA fonte da verdade, limites de aprovação, caminhos de correção, continuidade e disciplina de afirmações mais claros antes que o usuário dependa de um resultado de projeto.