# gameprod — diário de bordo (LoRA MiniMax H3, assets de jogo)

Início: 2026-09-20. Sucede o `smoothloopv3` na mesma instância (Vast 51594339, RTX 5090).
Disco: overlay 250 GB, **NÃO é volume persistente**. Tudo que importa vai para o HF.

## Decisões fixadas
- Trainer: mesmo pin `ede9ed9f` (fork AkaneTendo25/musubi-tuner, branch minimax-h3).
- Receita: idêntica à v3 do smoothloopv3 (rank/alpha 32, LR 5e-5, AdamW8bit, guidance
  4/sigma/normalized, jitter 0.2, swap 32, SDPA, convrot int8, AdaLN 16, fused qk/rope).
- Modo: `fl2va` (first-last), como o run anterior.
- HF: `AdwolfCzar/minih33-gameprod`, público + gated manual.
- **`--no-comfy` é o padrão** (ver PROGRESSO_smoothloopv3.md, descobertas 38-40):
  usar sempre o checkpoint nativo, sem sufixo.

## O dataset
Mega `UNBnWLCR`, 37.069 arquivos / 4,15 GB. Baixado sem `_inspect`/`_logs`/`_registry`
(QA, 13.727 arquivos): **23.342 arquivos, 3,10 GB, 0 erros, 8m37s a ~5,5 MB/s**.

- **6.422 vídeos** (5.973 mp4 + 226 gif + 223 webm) em **722 packs** de assets
  (pokemon_g1..g9, rpgmaker_spriteface, fx_gigapack, approved_r34, vfx, ...).
- **5.638 sidecars `.txt`** com metadata estruturada: duração, resolução, fundo,
  e a lista de animações com timestamps e contagem de repetições. É exatamente o
  que o perfil `game_production` consome via `{{existing_caption}}`.
- Área: p10 0,279 / mediana 0,364 / p90 0,588 / máx 10,1 MP.
- Duração: p10 5,00 / mediana 7,68 / p75 10,00 / máx 156 s.
- fps: 5.643 a 24; **779 NÃO estão a 24** (10, 12.5, 100, 8.333 fps).

## Descobertas
| # | Achado |
|---|--------|
| 1 | O dataset **já vinha majoritariamente normalizado** (24 fps, 5–12 s). Os limites batem com o perfil `smoothloop_min124` que criei em setembro — já passou por um `captioner convert`. Economizou a etapa de conversão. |
| 2 | **Listar pasta do Mega**: para nós de ARQUIVO a chave do atributo é a XOR-dobrada de 32 bytes (`file_key()`), não `nk[:16]` como nos nós de pasta. Usar `nk[:16]` num arquivo faz 100% dos nomes falharem a decifrar. |
| 3 | `frame_extraction = "full"` pega os **primeiros** F frames (F = maior valor do grid `17k+5` ≤ `min(max_frames, frames_do_video)`), `crop_pos=0`. Não é o vídeo inteiro. |
| 4 | **Por isso é obrigatório cortar ANTES de captionar.** Caption escrita sobre 8,3 s com treino vendo 3 s promete animações que não existem. Pior aqui: o sidecar traz timestamps autoritativos. Solução: corte + nota prefixada no sidecar avisando o recorte. |
| 5 | **Custo por step**: `tokens ≈ 0,00689 × duração_s × área_px`. Medido no dataset inteiro: 384×384 → 7.827 tokens (0,99× do smoothloopv3); 640×640 "480p" → 19.030 (2,42×). **480p e duração inteira são mutuamente exclusivos.** |
| 6 | Relatório seção 7.1 contradiz a premissa dos 5 s: *"a faixa de 5–15 s não é um mínimo obrigatório de duração de todo exemplo de treino"*. O grid aceita 56/73/90/107 frames. |
| 7 | Frames disponíveis têm que sair da **duração × 24**, não do `nb_frames` da fonte — senão os 779 vídeos a 10/12,5 fps são subestimados e caem num bucket curto errado. |
| 8 | O container **não tem `sqlite3` CLI**. O state do captioner (`.captioner.sqlite`) só é legível via Python. Monitor que dependia do CLI ficava mudo. |
| 9 | Contar `*.txt` no diretório **não mede progresso de caption**: os sidecars de metadata já são `.txt`. Usar a tabela `items` do sqlite. |

## Desenho das views (escada inversa, seção 7.2 do relatório)
Área maior ⇄ clipe mais curto, para manter `T_latente × tokens espaciais` constante.
Com `bucket_no_upscale = true` as dimensões são **orçamento**, não esticamento.

| view | orçamento | frames | duração | n | tokens |
|---|---|---|---|---|---|
| v384 | 448×448 (0,20 MP) | 141 | 5,88 s | 1.750 | 7.665 |
| v480 | 640×640 (0,41 MP) | 73 | 3,04 s | 2.750 | 8.783 |
| v780 | 896×896 (0,80 MP) | 56 | 2,33 s | 500 | 13.163 |

**Média ponderada 8.828 tokens/item** vs 7.869 do smoothloopv3 (11,84 s/it) → estimativa
~13 s/it, a ser **medida pela sonda** antes do cache completo.

Atribuição por área da fonte (ordenada), seed 42, seleção round-robin entre os 722
packs para diversidade. Manifesto congelado em `manifest_views.csv` — o cache é
indexado por stem, então re-sortear invalidaria o cache (lição do smoothloopv3).

## Estimativas de custo
- Cache: **~74 GB**, **~8,8 h de GPU** (latentes VAE-bound ~5,6 s/item + TE ~1 h).
- Treino: 5.000 steps × ~13 s ≈ **18 h**.
- Total ~27 h. O run anterior foi 2,9 h de cache + 19,7 h de treino = 22,6 h.
  **Se o objetivo for bater o tempo total, o botão é o número de steps.**

## Pipeline (scripts)
| script | o que faz |
|---|---|
| `gp_analyze.py` | ffprobe de todos os vídeos → `manifest_source.csv` |
| `gp_assign_views.py` | seleciona N, atribui view, corta com ffmpeg, prefixa nota no sidecar |
| `gp_make_tomls.py` | TOMLs de cache/treino a partir da MESMA definição de views |
| `gp_build_probe.py` | conjunto-sonda por hardlink + TOMLs da sonda |
| `gp_pick_samples.py` | escolhe 3 clipes (1 por view, packs distintos, SAR 1:1) |
| `gp_prepare_samples.py` | primeiro frame → PNG na grade de 32, `sample_prompts.txt` |
| `gp_chain.sh` | encadeia tudo destacado; GPU nunca ociosa |
| `gp_caption_progress.py` | progresso do captioning via sqlite |

## Armadilhas reconfirmadas
- `nohup ... &` dentro do Bash tool **morre** junto com a chamada. Usar `setsid`.
- `pgrep -f`/`pkill -f` com padrão que casa a própria linha de comando: auto-detecção.
  Sempre PID exato via `kill -0`.
- `/workspace/.env` não existia nesta máquina; recriado com as 3 chaves.
- O script de treino aborta se o repo do trainer tiver edições locais — o patch do
  `convert_lora.py` foi movido para `/workspace/scripts/convert_lora_h3fix.py`.