Gauntlet Fps

Gauntlet Loop — CS BRASIL / CORO SOLTO

Por que este loop existe

Um agente sozinho produz um resultado decente e para. Ele para porque ele mesmo é quem julga, e ele conhece toda a razão por trás de cada decisão que tomou — o que o torna excelente em explicar por que o próprio trabalho é aceitável.

O Gauntlet resolve isso com três regras que valem mais que qualquer instrução de estilo:

1. A régua não é negociável. Não é "ficou bom", é "perde ou ganha de um frame de CS2, e por qual medida".
2. Quem constrói nunca dá a nota. O crítico é outro agente, com contexto limpo, que só vê o pixel — nunca a justificativa do builder.
3. O loop não tem número fixo de rodadas. Ele para quando você para, não quando o agente se declara satisfeito.

O que faz a diferença aqui não é o número de agentes — é que cada afirmação carregue um número e um arquivo:linha. Uma crítica que diz "melhore a iluminação" é ruído. Uma que diz "22,7% dos pixels de game-praca_poderes-169-a.png estão em L* < 3 e a causa é bloom.js:18 power=1.25" é trabalho.

Antes de qualquer coisa

Leia, nesta ordem:

1. STATUS.md (em ../progress) — o estado atual, em ≤100 linhas. (Substituiu o topo do HANDOFF-KIMI.md, que virou HANDOFF-KIMI.md (fora da árvore pública) e agora é só histórico — leia de lá quando precisar da causa raiz de uma decisão antiga.)
2. tools/eval/BAR-CONSISTENCIA.md — a régua vigente, com precedência sobre a BAR.md: 25 critérios de consistência e flow. Melhoria visual que quebra o jogo é regressão. 2b. tools/eval/BAR.md — a régua de fidelidade. Look técnico do CS2/Valorant, o que é alcançável em Three.js r160, como os lugares brasileiros retratados realmente são, e o checklist de 25 critérios A1–D4 mensuráveis num frame.
3. tools/eval/ARCH.md — índice do game.js por linha, os levers de cada frente, e a tabela de conflito (quem pode editar qual arquivo/range). É gerado: rode npm run arch antes de ler, ou você lê o índice de ontem.
4. KNOWN-BUGS.md (em ../progress) — os defeitos abertos, com arquivo:linha, causa raiz e passo de reprodução. É onde mora o placar real do quality gate, colado de execução de verdade.
5. docs/docs/stack.md — com o que o jogo é feito (Three.js/WebGL sem build, Astro/Vercel, Supabase) e como o asset é gerado (mint.gg, Tripo3D, Meshy, OpenRouter). Os números dessa página são gerados por npm run docs.
6. git status — o dono revisa antes de commitar. Não commite sem autorização explícita.

Ambiente

Verifique antes de planejar, porque isso muda tudo:

nproc                      # quantos builders dá pra rodar em paralelo
ls /opt/pw-browsers        # chromium do playwright (headless, software rendering)
npm root -g                # onde mora o playwright

Se o repositório estiver na máquina do usuário via bridge e o browser só existir no container, espelhe a árvore para o container e trabalhe lá. Rendering por software (SwiftShader) roda o jogo a ~0,3 FPS — uma captura in-game leva de 4 a 6 minutos por mapa/aspecto. Planeje em torno disso; não trate lentidão como bug.

Servidor de teste (sem depender do astro dev):

node tools/eval/serve.mjs 8123

O ciclo

1. Baseline medido

CHROME_BIN=/opt/pw-browsers/chromium-*/chrome-linux/chrome \
  node tools/eval/gl-shots.mjs /root/shots/base all

Captura todos os mapas registrados × 2 aspectos (16:9 e 3:2 — o dono joga em 3:2) × 4 ângulos, mais as telas de menu. Sem baseline não existe A/B, e sem A/B o loop vira opinião.

2. Críticos adversariais, um por frente

Rode em paralelo, cada um com contexto limpo: gráficos, mapas/fidelidade, armas (visual e feel, notas separadas), UI (menu e HUD, notas separadas), jogabilidade.

O que faz um crítico ser útil:

• Recebe os PNGs e o código, nunca o relatório do builder.
• Entrega nota 0–10 e os N gaps ordenados por (impacto ÷ custo), cada um com: o que se vê no frame que denuncia, a causa em arquivo:linha, e a correção com números.
• Instrução literal que vale repetir: "melhorar a iluminação" é resposta inválida; "SSAO half-res de 8 amostras no composite do bloom.js, raio 0.6m, e chão 8 pontos de L* mais escuro que as paredes" é resposta válida.

Deixe os críticos escreverem scripts Python (PIL está instalado) para medir L*, saturação, contraste e % de blocos chapados. Medir é barato e transforma a crítica em algo que a próxima rodada pode conferir.

3. Builders em paralelo, particionados por arquivo

Use a tabela de conflito do ARCH.md — que é GERADA (npm run arch), justamente porque um índice por linha escrito à mão desatualiza no primeiro commit. Este parágrafo é a prova viva: ele afirmava "o game.js tem 3.234 linhas" e continuou afirmando isso enquanto o arquivo dobrava de tamanho, porque nenhuma régua olhava para ele. Por isso nenhum número de tamanho de arquivo é escrito aqui — rode npm run arch antes de particionar e leia o número de lá. O mesmo vale para a documentação: npm run docs gera, npm run docs:check reprova (está no check:fast).

O game.js é grande e todas as frentes precisam dele — por isso a regra:

Em game.js, use somente a ferramenta Edit. Nunca Write. Outros agentes estão editando outras regiões do mesmo arquivo ao mesmo tempo.

Partição que funciona: gráficos-core (bloom.js, textures.js, renderer) · um agente por map_*.js · armas (weapons.js, vmattach.js, springs.js, fparms.js + ranges de arma no game.js) · UI (style.css, index.astro, HUD) · jogabilidade (bots, movimento, rounds).

Regras que cada builder precisa receber:

• Kill-switch por querystring em toda mudança arriscada (?ao=0, ?fxaa=0, ?water=0…) e degradação segura em quality === 'low'.
• node --check em cada arquivo editado antes de retornar.
• Alvo de 60 fps em GPU de notebook. Nada de SSAO full-res com 32 amostras.
• Comentário em português explicando o porquê — é a cultura do repo e é o que sobrevive ao próximo handoff.