O que só o dono decide ou testa. As IAs propõem, com critérios e uma recomendação; enquanto a decisão não sai, nada disso muda no jogo.
~~Uma chave só para o servidor? (12/10, P93)~~ DECIDIDO em 13/10 (P106): aceitar também a sessão is_admin. O Comandante pediu "unifique as contas"; a sessão vale em todas as rotas, o token do dono segue como chave de emergência (não depende do banco). Segue o texto original:
O painel do servidor aceita só o token do dono (metricas-token.txt, que só existe no PC dele); o painel de chassis do Gemini (#259, no ar) usa a sessão de uma conta is_admin. Hoje cada painel tem a sua chave e as rotas não se cruzam. Decidir: manter assim (recomendado: reiniciar o servidor com a chave que só existe no PC dele é mais forte), aceitar também a sessão is_admin nas rotas /admin/estado e as outras (uma linha em server/admin.ts), ou o contrário.
Enxugar a papelada? (13/10, Claude, a pedido do Comandante: "tenho a impressão de que temos muitas regras")
Medido nas minhas entregas de hoje: a documentação é de 15 a 25% dos bytes de cada PR (6.800 a 15.200 B de doc contra 28 a 97 mil B de código); cada PR repete o mesmo fato em até sete arquivos (ESTADO_ATUAL, ROADMAP, ORDENS, STATUS_REAL, HISTORICO, PAINEL_ADMIN, DEPLOY); ESTADO_ATUAL.md tem 1.500 linhas e o HISTORICO 2.700 (o Passo Zero manda ler os dois); todo PR começa no topo dos mesmos arquivos, então dois agentes batem em conflito (aconteceu hoje no #292); e a regra de formato do ROADMAP só reprovou depois de 6 min de check. As regras de engenharia (G1/G2, G14, R2, R13) não atrapalham: são o que segura a qualidade. Proposta (o dono decide): (1) um fato, um lugar: ORDENS (o que ele pediu e o estado) e STATUS_REAL (o que funciona) viram a verdade; o ESTADO_ATUAL encolhe para "agora / próximo" (≤ 100 linhas, sobrescrito, o ensaio de cada PR vai no corpo do PR); (2) as entradas novas entram no fim, ou em um arquivo por agente, para acabar com o conflito; (3) um npm run docs:check de 1 s (o formato do ROADMAP e das ORDENS) antes do check de 6 min; (4) o Passo Zero cai para três leituras fixas e o resto por tarefa. Nada disso foi mudado: o AGENTS.md só se edita com registro e decisão do dono.
O PC de casa sem memória hospeda o servidor de jogo (09/10, medido)
A máquina tem 6 GB e vive com 300–500 MB livres (navegadores, ChatGPT, Antigravity, Defender, três agentes de código); o servidor chegou a 9 MB residentes e uma entrada demorou 59 s (12 s minutos depois; 1,4 s quando a máquina estava calma). O SSD é um SATA de entrada que desacelera sob paginação. Um jogador de verdade desistiria. Decidir: (a) tirar o servidor desta máquina (VPS pequena; o código e o túnel já estão prontos, DEPLOY.md); (b) manter aqui e dar folga (mais RAM, ou fechar o ChatGPT e abas do navegador enquanto o servidor estiver aberto ao público); (c) manter como está só para testes do dono. Enquanto isso o servidor só serve para teste com poucos amigos.
Armas elementais (pedido do dono, 09/10)
Metralhadora rotatória, elétrica (choque, lentidão, atordoamento no tiro bem dado), lança-chamas e gelo. Plano, números de partida, custo de rede e divisão de trabalho em ARMAS_ELEMENTAIS.md; o dono respondeu em 09/10 ("tiro bem dado" = cabeça ou 3 acertos seguidos em 1,4 s; atordoamento de 0,8 s com imunidade de 4 s; fogo e gelo se anulam; Mech grande resiste): sim a todas. Só fogo no cenário segue sem resposta (padrão: não; a porta fica aberta). Ordem: contrato dos efeitos de estado (#199, feito) → rotatória (#200, feito) → elétrica (PR-C, feito) → lança-chamas → gelo; tela e som com o Gemini em paralelo (o dono cola o pedido da seção 7 no chat dele). Codex só depois, para os efeitos 3D (hoje na auditoria de desempenho).
Nome do jogo: AVARIA (11/10; era SINGULARIA desde 07/10)
Em teste só no título da capa do jogo, a pedido do Comandante ("Singularia não ficou bom; Avaria tem mais a ver e é mais bacana de ler"). O resto segue CYBERMECH (aba do navegador, carregamento, Hangar, linha de versão, site, URLs, chaves do localStorage, nome da pasta de documentos). O dono decide se gosta; se sim, a troca geral vira um passo à parte (com migração do localStorage e redirecionamento das URLs). Do dono, fora do código: busca de marca no INPI (classes 9 e 41), busca em Steam/itch/lojas e compra do domínio. Detalhe em HISTORICO_DE_DECISOES.md, 07/10.
Drones e torres na partida
A banda aperta antes do formato: a sala cheia de hoje (12 robôs) já usa 6,2 KB/s dos 8,0 KB/s disponíveis por jogador. Decidir: drone por jogador (não cabe hoje), um drone por esquadrão, ou habilidade com recarga; e se vale o pacote que barateia (registro curto de unidade leve + estado a 5 Hz + trilha pré-calculada, com a conta no METAGAME.md, § 8.1). Zonas de cura/resfriamento já implementadas (Claude, 27/09, combat/Zone.ts): custam 0 B, valem também no online. Torres seguem pendentes: precisam de vida/calor num estado curto e disparo por evento (§ 9).
Hospedagem do servidor
Dono (26/09): começar com o PC de casa 24 h. Falta decidir o domínio do endereço fixo: um domínio só do jogo na Cloudflare (recomendado, ~R$ 40/ano) ou levar o DNS do selvamkt.com.br para a Cloudflare (grátis, mas mexe no site da Selva MKT). Oracle ou VPS depois, com o mesmo código. Seguem abertas: mira assistida no PvP e bots nas salas (MULTIPLAYER.md, seção 10).
Mira assistida no multiplayer
Hoje é só do toque e só contra bots. Com gente de verdade, toque x mouse na mesma sala precisa de regra: manter (padrão dos jogos de tiro no celular), reduzir contra humanos ou separar salas por tipo de controle. Decidir na Fase 4.
Separação simulação × render × efeitos
Proposta e criteria de aceitação em MULTIPLAYER.md, seção 9. Recomendação: tiro do jogador e yaw pela simulação antes da M4; o resto quando memória do servidor ou correções visíveis pedirem.
Universo (UNIVERSO.md, seção 7)
Brasil no centro, no contexto dos BRICS, já decidido. Premissa, roteiro, quanto de CTI entra (só textos ou também mecânicas) e nomes dos consórcios: com o dono, no chat do SERAFIM. Nada muda no jogo antes do aval.
Bots contra bots
Hoje os bots só caçam o jogador. No modo "todos contra todos" eles deveriam se enfrentar também: basta passar todos os Mechs em BotSystem.targets.
Câmera de abate no PvP
O corte offline segue o bot que matou. No online isso revelaria a posição do adversário durante 3 s. Decidir: liberar como ferramenta de conteúdo, atrasar/limitar a visão, ou manter ausente em partidas competitivas. Até a decisão, o online conserva a câmera normal e STATUS_REAL.md marca AUSENTE.
Revisão do status do servidor (#106)
Corrigir duas arestas do PR #105: impedir cadeias duplicadas de polling quando visibilitychange ocorre durante fetch, e definir a política de CSP para o /status de um ?servidor= explícito. O cache de 1 s e a ausência de tráfego com aba oculta foram aprovados.
Colossus-01: arma e encontro
O dono fechou escala 3 e 14 m. Faltam a assinatura de arma, a máquina de fases, valores de combate e a forma do modo assimétrico; o próximo PR do Codex inicia pelo encontro offline determinístico.
Mech de tripulação (piloto + 1–2 artilheiros nas armas direcionais do Colossus)
Pedido do dono (29/09), priorizado por ele: "Colossus jogável (solo) primeiro" — feito (ver ÚLTIMA SESSÃO FEZ). Este item é a etapa 2: vários jogadores num corpo só. Ainda não tem contrato de rede nem decisão de arquitetura (G6 diz que Mech remoto não roda o character controller — precisa decidir quem simula o quê). Não iniciado.
Estilos de jogo como eixo da evolução (dono, 06/10)
O dono quer armas e robôs configurados para que, ao evoluírem, abram mais jeitos de lutar: tankar e combate próximo, rush e lutar até o fim, ataque furtivo e jogadas como as do xadrez. Hoje só os bots têm estilos (PERSONAS em BotController.ts: brabo, fujão, manso, soldado); para o jogador, a evolução é uma escada só (TIERS) e o chassi não evolui. Texto completo e caminho sugerido no ROADMAP.md. Decidir: quais estilos entram primeiro; se a evolução é por arma, chassi ou piloto; se a furtividade vale no online (custa banda, G11). Relacionado à linha abaixo.
Chassis: os números têm papel, a forma ainda não (10/10)
Os 10 chassis agora têm números distintos e um papel cada (CHASSIS_PAPEL, ChassisPapeis.test.ts). O que continua com o dono: escolher o primeiro arquétipo de forma (quadrúpede, esteira, canhão no lugar da cabeça, quatro braços; ROADMAP, "variedade estrutural") e jogar e dizer se os papéis estão certos (os números são proposta).
Framework modular de chassis/peças além do Hangar de armas
Pedido do dono (29/09): "criar, editar, evoluir (ou estragar)" os robôs à gosto do jogador — hoje o Hangar só cobre armas por braço (loadout.ts); trocar/editar chassi, peças e evolução persistente é maior. Progresso parcial: o catálogo de chassis cresceu (Arara-B1, Onça-B2, Colossus-01, além de Vector-09/Andróide), então já dá para *escolher* entre mais modelos — mas ainda não dá para o jogador *criar/editar* um chassi próprio nem evoluí-lo com o tempo. Não iniciado; precisa de escopo antes de construir (afeta rede, persistência de conta, balanceamento).
Modelagem dos chassis: pipeline híbrido, primeiro chassi de verdade no ar (GÊNESIS-01, 30/09)
Decisão (ver HISTORICO_DE_DECISOES.md, 29/09): sai do 100% procedural depois do teto real provado (protótipo tanque/barril, "pilha de moeda"); entra malha gerada por IA (Tripo3D). Feito: GLTFLoader + SkeletonUtils.clone no ponto de montagem do rig (importedMechRig.ts, importedMechAssets.ts), GÊNESIS-01 escolhível no Hangar e jogável numa partida de verdade — ver ÚLTIMA SESSÃO FEZ. Ainda em aberto: nome/ficha definitivos (hoje empresta 100% do Vector-09), fluxo pra gerar/receber mais chassis assim (hoje é manual: dono gera no Tripo, manda o arquivo, eu rigo o código em volta), orçamento de download por chassi (cada .glb ~3 MB).
Aliados na Arena online (rede)
Feito offline (30/09, ver ÚLTIMA SESSÃO FEZ). Falta só o servidor: ArenaRoom.ts desliga allies de propósito porque o roster de rede não sabe descrever um aliado pros outros jogadores ainda (ficariam invisíveis, fora de sincronia). STATUS_REAL.md marca AUSENTE no online até o roster aprender.
Vídeo promocional por prompt/botões no /mesa
Feito (29/09): a mesa já tinha o formulário; ganhou "gerar por IA" (escreve o roteiro a partir de uma frase, ancorado nos fatos do projeto) e a cena clipe (mistura gameplay real gravado no F9 com as cenas desenhadas, cortado por ffmpeg). Ver FERRAMENTAS.md.
Gerenciar as imagens do site sem código (deletar, reordenar, trocar)
Pedido do dono (29/09), depois de achar 3 fotos idênticas na landing (causa real: capture() falhando em silêncio — corrigido no mesmo PR, agora falha alto e nunca mais publica foto errada) e pedir um carrossel: o carrossel entrou (scripts/landing.mjs, gira sozinho entre as capturas que existirem). O que falta é maior — um jeito de escolher/ordenar/remover imagens sem editar SHOTS no código. Hoje as capturas são 100% automáticas (o robô entra no jogo e fotografa a cada deploy); um painel de curadoria manual é uma ferramenta nova, não uma correção. Não iniciado; precisa de decisão (onde mora a lista — arquivo versionado editável por formulário local, ou algo mais) antes de construir.
Publicar de um branch põe código não mergeado no ar (14/10, Qwen)
O npm run publicar-site publica o HEAD da pasta onde roda — é assim que o atualizador publica a main da worktree do servidor, e é o que permite publicar à mão de qualquer pasta. O risco ficou visível hoje: o publish das 20:02:35 (14/10) foi do 8cb80d5, o HEAD da pasta principal, que estava no branch qwen/o-mapa-da-praia, e não da main — o log passou a avisar quando isso acontece, mas avisar não impede. Decidir: (a) recusar publicar quando o HEAD não é a origin/main (com --forcar para quem sabe o que faz — recomendado, alinha com a regra 14: só o merge publica); (b) deixar como está, agora com o aviso no log; (c) publicar sempre a origin/main (a pasta não escolhe mais, --se-mudou compara com ela).