Icon-batch presentation

Quando uma sessão precisa mostrar ao owner um conjunto de ícones candidatos pra ele escolher, faz do mesmo jeito, toda vez: ícones gerados conforme a engenharia de ícones, persistidos como batch durável, e apresentados na galeria de triagem padrão. Nunca uma folha PNG montada à mão, nunca IDs que mudam entre iterações, nunca sem checar legibilidade em claro e escuro.

Esta é uma policy de processo (não de pixels): a aparência de cada ícone é governada pelas specs de specs/icons/; esta policy governa como a leva é produzida, guardada e revisada. As três coisas são invariantes; a ferramenta de superfície é trocável (R5).

O que era o defeito

Sessões apresentavam ícones como imagens PNG montadas ad-hoc. Resultado recorrente (observado 2026-06-13 na eleição do ícone do Karavan): cards cortados extrapolando o canvas, IDs renumerados entre levas (o owner perdeu a referência do candidato que tinha aprovado), nenhuma checagem de contraste claro/escuro, e qualidade abaixo das levas que o Imago já produzia. O meta/brand/icons/candidates/ (source-of-truth) e o Imago (produto-banco) já existiam — faltava a regra que obriga usá-los.

Regras

• R1 — Engenharia antes da apresentação (não-negociável). Todo

  candidato é gerado conforme specs/icons/products.kmd (R1–R7: frameless, silhueta única, gradiente vertical luz-de-cima, glyph branco ≥3:1 ou figura-fundo, mono-hue, normalização) + inscribed-glyph.kmd + ui-symbols.kmd + paleta KDS (themes/verge.kmd). Antes de mostrar, rodar kicon validate em cada candidato; zero warnings de contraste/silhueta. Apresentar ícone que não passou na validação é violação — o owner não é o validador da engenharia.

• R2 — Toda leva é um batch durável. Antes de apresentar, escrever a

  leva em meta/brand/icons/candidates/<target>-<style>-<YYYY-MM-DD>/ com manifest.toml ([batch] + um [[icons]] por candidato) e icons/NN-<slug>.svg, conforme candidates/README.kmd. A leva é durável a partir desse commit — não vive só em ~/temp/ nem num PNG no chat. Registrar a row em candidates/README.kmd (Active batches).

• R3 — IDs estáveis entre iterações. O ID de um candidato (n/slug

  no manifest, refletido no card) nunca muda depois de apresentado. Iterar uma leva = adicionar novos IDs e marcar os velhos como reprovados, não renumerar. Quando o owner aprova um ID, esse ID é a âncora — recriá-lo com outro número ou outro prefixo perde a escolha dele. (Foi o erro k1→r1 de 2026-06-13.)

• R4 — bank.meaning no vencedor. Quando uma leva elege um vencedor,

  o manifest ganha um bloco [winner] com represents / concept / rationale / engineering (imago#026-b). É o que torna o batch legível por humano e ingerível pelo Imago depois.

• R5 — Superfície de revisão padrão (ponteiro trocável). A leva é

  apresentada na galeria de triagem padrão, nunca numa folha PNG ad-hoc. A galeria dá: filtros (em-disputaaprovadosreprovados/ lixeira), aprovarreprovarexcluir, IDs estáveis visíveis, fundo claroescuromeio-a-meio, e modal de comparação. Implementação corrente: o gerador meta/brand/icons/triage/triage-gen.py (ponte temporária, self-contained HTML). Destino: os murais por-módulo do Imago na conta do owner (imago#030 + #032) — quando entrarem, a ponte é removida e este ponteiro passa a apontar pro Imago. A superfície muda; R1–R4 não.

• R6 — Cards de referência. Quando a escolha precisa se diferenciar

  de ícones oficiais existentes (ex.: a vertical nova vs. o pino do Koder Maps), incluir esses ícones como cards de referência não-selecionáveis na galeria (--reference "Label=path"), pra comparação lado-a-lado. O owner pediu isso explicitamente na eleição do Karavan.

• R7 — Artefatos de revisão em ~/temp. O HTML gerado e qualquer

  render vivem em ~/temp/<subdir>/ (policies/scratch-location.kmd), nunca na raiz da home nem versionado. Só o batch (R2) é committado; a galeria é derivável dele a qualquer momento.

• R8 — Não duplicar a superfície (reuse-first). A ponte de triagem é

  a única superfície interina; não criar uma segunda nem entrincheirar triagem num kicon (que é gerador build-time, não UI) — isso duplicaria o Imago e violaria reuse-first.kmd. Evoluções de superfície vão pro Imago (#032), não pra novas ferramentas paralelas.

Fluxo canônico (uma sessão gerando uma leva)

1. Gerar N candidatos conforme a engenharia (R1); kicon validate cada.
2. Escrever o batch durável em candidates/<id>/ + manifest (R2R3R4).
3. triage-gen.py --batch-dir candidates/<id> --out ~/temp/<id>.html

   [--reference … quando R6 se aplica].

4. Avisar o owner com o path/URL da galeria; ele tria.
5. Eleito o vencedor: bloco [winner] (R4), pipeline oficial de ícone

   (canônico + variantes + landing + release), conforme os gatilhos de specs/icons/.

Testes

• T1 — Uma leva apresentada sem batch correspondente em

  candidates/ → FAIL R2.

• T2 — Dois candidatos da mesma campanha com o mesmo ID lógico

  apontando pra SVGs diferentes entre iterações → FAIL R3.

• T3 — kicon validate em qualquer candidato apresentado retorna

  warning de contraste/silhueta → FAIL R1.

• T4 — Galeria gerada por triage-gen.py abre self-contained

  (sem rede), renderiza todos os candidatos + cards de referência, e persiste estado por batch id → PASS R5/R6.

• T5 — HTMLPNG de revisão committado no repo (fora de `~temp/`)

  → FAIL R7.

Sunset

Quando imago#030 + #032 entrarem (murais por-módulo + loop de revisão Claude-Code → mural na conta do owner): remover meta/brand/icons/triage/, trocar R5 pra apontar pro Imago, e migrar as levas legadas como murais iniciais (imago#032 já prevê a migração).