BigMaxRedutor v10.2 — Estado Atual
Linhagem do código
VersãoFasePrincipais característicasv10 → v10.1Estabilizaçãocovered_t voltou para uint16_t (uint8_t saturava em b>255)v10.1 → v10.2Esta entregaAnti-platô: orçamento adaptativo, tabu, LAHC, kick early, telemetria
Arquitetura em camadas
O solver opera em três camadas concêntricas, cada uma cobrindo o que a anterior não cobre:
1. PDO Workers (paralelo, 8 threads) — exploração ampla. Cada worker faz worker_pdo com adaptação de j_max via AdaptivePDOJ. Aceita Δ=0 desde sempre. Produz diversidade de configurações para alimentar a próxima camada.
2. TLS-Dir (single-thread, sequencial) — refinamento local. Recebe a melhor configuração dos workers, faz busca local dirigida com:

(novo v10.2) Orçamento adaptativo de movimentos laterais: max(50, custo×2), capado em 500. Em v10.1 era hardcoded em 5.
(novo v10.2) Tabu list (deque + hashset, 128 entradas) com hash incremental por XOR — previne ciclos durante random walk em platô
(novo v10.2) Fase LAHC (Late Acceptance Hill Climbing) entre platô e micro-greedy: buffer circular de 500 custos, aceita movimento se cost ≤ max(atual, hist[head]), sem schedule de temperatura
Micro-greedy 1-swap exaustivo + 2-swap dirigido (mantido de v10.1) como último recurso

3. RecordBreaker loop (top-level) — escape de bacias profundas. Quando TLS-Dir trava:

(novo v10.2) Kick adaptativo: dispara após 3 rounds se custo > 10; mantém 8 rounds se custo baixo (vale insistir na busca local)
Smart_shrink + greedy_extend como mecanismo de perturbação
Restart completo a cada 3 kicks (greedy_initial puro)

Telemetria (novo v10.2)
TLSTelemetry acumula 8 contadores por chamada de TLS-Dir, propagados para MetricsLog (.jsonl):
lateral_accepts        — Δ=0 aceitos (random walk produtivo)
lateral_rejects_tabu   — Δ=0 rejeitados por tabu (evidência de ciclos evitados)
lahc_invocations       — quantas vezes LAHC entrou em ação
lahc_escapes           — ... e quantas escapou do platô
micro_greedy_calls     — 1-swap exaustivo invocado
micro_greedy_success   — ... com sucesso
two_swap_calls         — 2-swap dirigido invocado
two_swap_success       — ... com sucesso
Impressos no fim de cada chamada e no JSON de métricas. Sem isso, era impossível auditar empiricamente o comportamento do solver — agora é direto.
Validação empírica observada
No log do cenário V=24, K=9, T=7, M=9, b=1242 (Round 7):

TLS-Dir produziu cascata de 90+ melhoras consecutivas (221 → 131) — comportamento que v10.1 não conseguia
lat_ok=426 significa 426 movimentos laterais produtivos numa única chamada — random walk em platô realmente funcionando
LAHC=3/34 — escapes raros mas reais; quando acontecem, destravam o solver
KICK adaptativo disparou em ~22 minutos em vez de ~60 minutos com config v10.1

Limitações conhecidas
Algumas observações honestas extraídas dos logs:

mg1_success = 0 em todos os logs vistos: o micro-greedy 1-swap nunca acerta. Sinaliza que problemas onde TLS-Dir trava genuinamente exigem encadeamento de múltiplas trocas com piora intermediária — terreno de SA com schedule, que não está em v10.2
A primeira chamada de TLS-Dir pós-shrink frequentemente fica improdutiva (configuração ainda não diversificada). É a chamada após o PDO workers passar que tipicamente produz progresso. Sugere que faz sentido considerar inverter ordem na fase imediata em versões futuras
Para records consagrados de longa data (como 1249 em V=24K9T7M9 desde 2021), v10.2 é estatisticamente improvável de melhorar em horas de execução. Para parâmetros onde o "Known design" é mais frágil ou inexistente, é solver competitivo

Arquivos do projeto
ArquivoStatusNotasbigmax_types.hModificadoVersão v10.2, struct TLSTelemetry, novas constantesbigmax_worker.hModificadoTabuList, kset_hash, LAHC, orçamento adaptativobigmax_solver.hModificadoAcumulador tls_telem_totalbigmax_solver.cppModificadoKick adaptativo, propagação de telemetriabigmax_checkpoint.hModificadoOverload record(...) com TLSTelemetrybigmax_cover.hInalteradoMotor de cobertura (LRU cache, radix sort)bigmax_greedy.hInalteradoGreedy initial/extend/shrink/replacemain.cppInalteradoSetup interativo, signal handlers
Para usar
Compilação: Visual Studio Release | x64 | C++20, sem dependências externas. Validado com g++ 13.3 -Wall -Wextra (sem warnings) e MSVC (compilação em ~7s, sem warnings).
Checkpoints e arquivos record_*.txt da v10.1 são lidos sem alteração — formato compatível.
Caminho futuro plausível (se quiser revisitar)
Sugestão:
v10.3 (SA controlado no TLS-Dir) — aceitação probabilística de Δ<0 com exp(Δ/T), T calibrado para ~30% de aceitação inicial. Ataca diretamente o sintoma mg1_success=0. ~30 linhas de código.
v10.4 (VNS estendido) — permitir expansão temporária acima de b durante busca local, depois shrink de volta. Explora vizinhança que kick simples não acessa.
Logs estruturados em pandas — análise post-mortem das jsonl para entender em que regime de custo cada técnica funciona melhor.
Esses são pontos para retomar quando/se fizer sentido. v10.2 é entrega completa por si só.