Name-batch presentation

mandatory

Como toda IA apresenta uma LEVA de NOMES candidatos pro owner escolher (aprovar/reprovar/excluir/guardar-pra-reuso). O irmão da icon-batch-presentation, pra nomes em vez de ícones. Três invariantes duráveis: (1) a spec de naming é rodada ANTES de apresentar — colisão exact-match no component-names registry (R2/T3-T5) + regra de slug R4 — então a leva é confiável, não chutada; (2) os candidatos viram um BANCO durável (meta/brand/names/bank.json) com status por nome, e um nome reprovado pra um componente fica `available` e ressurge no próximo; (3) a SUPERFÍCIE de revisão é a página de triagem padrão (hoje name-triage.py serve) — não tabelas ad-hoc no chat toda vez. Resolve o sintoma recorrente: muitas levas de nomes até escolher, nomes bons perdidos, colisões não checadas.

Quando uma sessão precisa mostrar ao owner um conjunto de nomes candidatos pra um componente, faz do mesmo jeito, toda vez: nomes validados pela spec de naming, persistidos num banco durável, revisados na página de triagem padrão. Aplicável a qualquer IA (Claude Code, Codex, Gemini CLI, etc.) no monorepo Koder. É o análogo, pra nomes, da icon-batch-presentation.kmd.

Os três invariantes

1 — Spec de naming rodada ANTES de apresentar (não chutar)

Cada candidato passa por specs/naming/forms.kmd na geração:

  • Colisão exact-match contra registries/component-names.md (R2/T3-T5) e

    contra o próprio banco — só ^[a-z]+(-[a-z0-9]+)*$ (R4.4), exact, sem fonética (R4.5: proximidade NÃO é colisão).

  • Slug computado por R4.1/4.2 (product|service|engine começando com K →

    <bare>; senão koder-<bare>; meta|umbrella → <bare>).

A name-triage.py gen faz isso automaticamente. Nunca apresentar nome sem o veredito de colisão+slug — foi o gap que a /k-arch do produto de medida protetiva (2026-06-19) expôs ao checar tudo na mão.

2 — Os candidatos viram um BANCO durável (não some)

Vão pra meta/brand/names/bank.json (git-versionado) com status por nome. Ciclo: proposed → approved (o escolhido) · rejected · excluded (matar) · available (reprovado aqui mas bom pra outro componente — fica no banco reutilizável). Nomear um componente leva muitas levas; o banco transforma nome-bom- reprovado em ativo reutilizável em vez de reinventar.

3 — A SUPERFÍCIE de revisão é a página de triagem padrão

Hoje python3 meta/brand/names/name-triage.py serve → página web local (aprovarreprovarexcluir/guardar) que persiste no banco na hora, com uma seção "Banco reutilizável" dos available de outros componentes. Ponteiro trocável (pode virar um app Koder servido depois). Não apresentar como tabela ad-hoc no chat toda vez — gera levas inconsistentes e perde os nomes reprovados-mas-bons.

Fluxo padrão (toda IA)

cd meta/brand/names
python3 name-triage.py gen --component <slug> --batch <id> --type product Nome1 Nome2 …
python3 name-triage.py serve     # owner tria na página; decisões gravam no banco

Apresentar ao owner = abrir a página (ou apontá-la). O chat pode resumir os candidatos, mas a escolha acontece na superfície de triagem, persistida no banco.

O que NÃO fazer

  • Apresentar nomes sem rodar colisão/slug (invariante 1).
  • Levas só no chat que somem ao fim da sessão (invariante 2).
  • Folha/tabela ad-hoc diferente a cada vez (invariante 3).