LEB Security proposta
Uma das duas trilhas da próxima série do LEB: achar e corrigir vulnerabilidades num sistema que funciona, sem quebrá-lo. A tarefa é defensiva: o agente recebe o sistema e o contrato dele, e as verificações de ataque são do avaliador e não viajam no pacote. Como o LEB funciona hoje, e no que os níveis dele diferem, está na página Benchmark.
Ainda não há resultados. Esta página diz em que pé a série está e o que vai aparecer aqui. Nada nela é uma nota.
O que esta trilha mede
Achar e corrigir vulnerabilidades num sistema que funciona, sem quebrá-lo. Uma correção só conta quando todas estas condições valem:
- o ataque de referência e as variações dele deixam de funcionar;
- o usuário legítimo mantém a função;
- os contratos do manifesto continuam valendo.
Desligar uma função, recusar toda requisição ou responder erro a toda entrada não é correção. A compatibilidade continua na nota: uma correção que fecha o buraco e quebra o sistema é uma entrega ruim. Os falsos positivos são medidos em código correto que parece arriscado.
As notas Default e Security de uma configuração aparecem lado a lado e nunca são somadas.
Em que pé está a série
A próxima série é uma proposta: o desenho dela foi decidido em 12 de outubro de 2026, e os textos normativos (a especificação, o protocolo, a pontuação e os níveis) são escritos depois que um piloto validar o processo. Ela não muda nada no LEB-100 nem no LEB-300, cujos resultados continuam como foram publicados. Ainda não há placar.
Os sistemas de referência
Cada trilha é medida em vários sistemas de referência, e cada sistema gera as duas trilhas: dois perfis de plantio do mesmo código limpo. A mesma letra é o mesmo sistema. O piloto terá 3 sistemas; o conjunto de avaliação, cerca de 6.
| Sistema | Domínio | Stack | Instância | Estado |
|---|---|---|---|---|
| A | Gestão de condomínio (CondoDesk) | Java 21 · Maven · PostgreSQL | LEB-S-300-A | Em autoria |
Como um caso roda
Um caso é um sistema, uma trilha e uma configuração de agente.
- 5 execuções por caso, e todas contam.
- O modelo pedido fica travado no cliente, na conversa principal e em cada subagente, para que nenhum substituto possa responder.
- Um laboratório automático roda cada caso, da restauração da máquina ao arquivamento da evidência.
O que será publicado
Para cada configuração e trilha:
- a qualidade das entregas avaliáveis, com o intervalo de incerteza;
- a taxa de conclusão com o modelo pedido;
- a nota esperada por tentativa agendada;
- bloqueios (no início e durante o trabalho), trocas de modelo, orçamento esgotado e falhas de laboratório, cada um contado à parte.
O gabarito
O gabarito de uma instância é publicado no GitHub junto com a instância, antes da primeira execução, e as máquinas que rodam os agentes não alcançam o GitHub. Cada execução registra também o corte de treino do modelo, para o que um modelo pode ter visto no treino.
Comparação
Uma nota da próxima série nunca é posta ao lado de uma do LEB-100 ou do LEB-300.
Para ler mais
- O desenho da série
docs/new-series-design.md - O sistema A
systems/300-A/ - A pasta da instância
instances/LEB-S-300-A/