65. Identidade de entidade — seletor de ícone e cor

O que este componente é, para quem lê sem ter visto a sessão que o gerou. Quando um objeto de primeiro nível nasce no produto — um espaço, uma lista, uma carteira de clientes —, alguém precisa dar a ele a identidade visual que passará a representá-lo na sidebar, no breadcrumb e em toda referência cruzada: o quadradinho colorido com um glifo dentro. Este é o controle que produz esse par. Ele não inventa vocabulário: consome dois conjuntos que já eram canônicos e fechados neste sistema — as seis posições de cor de entidade do CP23 (seed-composicao.md) e os 31 glifos do set canônico do §45 (deste arquivo; eram 28 até a v1.38, 30 desde a FV-P5 da v1.39 e 31 desde a GL-R2 da v1.42 — o seletor acompanhou nas duas, em 2026-09-05: §65.12 e §65.13), com os aliases pt-BR/en que o NM1 mandou existir e que, até aqui, só a ⌘K do §39 consumia.

Fronteira com o §62 (seletor de pessoa): pessoa é círculo, entidade é quadrado de raio pequeno. A distinção de forma é anterior a este componente — vem do produto medido (estudo-clickup-completo.md §10b.3) e é a razão de as duas famílias nunca se confundirem numa lista mista. Este §65 herda a regra, não a cria.

Fronteira com o C5 (seletor de entidade colorida), que segue AUSENTE: o §65 é o controle que define a identidade de uma entidade; o C5 é o controle que escolhe entre entidades já existentes. São dois. O C5 continua bloqueado pela PS-P2 (só se abre escrevendo no produto de referência), e este §65 não o fecha — dizer que fecharia seria contar cobertura que não existe.

65.0 Rodada zero — a leitura visual existe, mas é do RESULTADO, não do controle#

A rodada zero deste projeto pergunta, antes de qualquer spec: o arquétipo tem leitura visual do produto de referência? Se não, qual dos três vereditos — não visitado, sem instância, não se aplica?

Veredito duplo, e é preciso dizer os dois:

E o resultado medido é suficiente para decidir, porque o defeito que ele revela é de vocabulário, não de ergonomia: a paleta é aberta e a tinta é branca fixa, e por isso 6 dos 13 ícones de identidade de espaço medidos reprovam, variando de 3,03 a 5,83 contra o piso 4,5. Nenhuma escolha de layout do seletor conserta isso; só o fechamento da classe conserta. O que a visita traria é ergonomia — e ergonomia é o que o RITO abaixo resolve.

Achado que a mesma medição entrega, e que é mais forte que o defeito: dentro do mesmo produto existe a política certa. O ícone amarelo #ffc53d não usa branco: usa tinta escura, e mede 13,31. A política que funciona já mora lá — ela só não foi aplicada ao componente que mais aparece na tela. É o mesmo padrão do C21 (chip de campo personalizado × chip de status).

65.1 RITO — três rodadas encadeadas#

Pisos, e por que são dois:

• 4,50 para o par glifo sobre a cor da posição (SI3). O glifo dentro de um quadrado de 20px é pequeno e carrega significado — é ele que distingue duas entidades que dividem a mesma cor. O que carrega significado em tamanho de texto é medido como texto. É também o piso contra o qual o produto de referência reprova 6 dos 13.
• 3,00 para o indicador de escolha (SI11), que é elemento não-textual (SC 1.4.11).

65.2 Os contratos SI1–SI16#

65.3 A anatomia, e os números medidos#

A paleta (CP23, enumerada nos dois temas — suite-identidade SI3):

Pior par: 5,11; piso 4,50. Os números não mudam entre temas, e é isso que se quer: os tokens --seed-entity-* são invariantes de tema por decisão registrada (gêmeo v1.11), então fundo e tinta são do mesmo par fixo e o par não se rompe na inversão — contrato BT3 do §64. O achado sai impresso no placar em vez de tolerado em silêncio (BT4).

O contraexemplo, impresso na bancada ao lado do canônico (cinco dos treze pares medidos no produto de referência, estudo-clickup-completo.md §8.2):

A grade: 31 glifos em 6 colunas — 5 linhas cheias + 1 célula (bancada v0.4, 2026-09-05; eram 30 em 6 × 5 na v0.3 do mesmo dia, e 28 em 7 × 4 até a v0.2 — ver §65.12 e §65.13). A régua é “linhas inteiras EXCETO a última”, por decisão dele (MANIFESTO §150, verbatim: *“T-SET: glifo novo

• régua da grade aceita última linha incompleta (recomendado)”*). A régua anterior — linhas inteiras, total % colunas == 0 — era consequência de 28 e de 30, não princípio: 31 é primo, e nenhuma grade de 2 a 30 colunas fecha. O que o SI5 exige de verdade é ↓ com destino previsível, e na última linha incompleta o destino previsível é não há célula abaixo, o foco fica — a regra do padrão WAI-ARIA APG para grid (consultado em 2026-09-05: “If focus is on the bottom cell in the column, focus does not move”), aplicada no script da bancada e medida pela guarda SI-OP3c. O gerador segue exigindo pelo menos duas linhas cheias (grade, não fila) e declara a sobra no resumo da geração. O 6 fica: é o desenho do gate de 2026-09-05, e 7 colunas dariam 4 cheias + 3 (mais sobra, no desenho que o 30 já tinha abandonado). Medido no Chrome a 1200 px na regeneração de 2026-09-05, nos dois temas: 31 células de 44 × 44, 6 linhas — 6, 6, 6, 6, 6 e 1 —, nenhuma cortada, nenhum glifo cortado.

Alvo medido: amostra 44×44, célula 44×44. Indicador de escolha medido no pixel: anel de 2px, #0b3330 no claro e #ddece8 no escuro, 13,72 e 12,49 contra as faixas que o encostam.

65.4 Um defeito de instrumento, e um falso positivo evitado — os dois na mesma guarda#

Décimo sexto defeito de instrumento (achado nesta rodada, dentro da suíte, antes de qualquer conserto ser aplicado ao artefato): o parser de cor entendia rgb() e color(srgb …) — as duas formas que os defeitos 5º e 12º já tinham ensinado — e não entendia HEXADECIMAL. getComputedStyle devolve rgb() para propriedades de cor, mas o valor de um token lido por getPropertyValue('--seed-text-primary') volta como está escrito no gêmeo: #242E34. O regex de dígitos casava só o final (34) e devolvia rgb(34, 0, 0).

O número que saiu foi 232,67. Razão de contraste acima de 21 é fisicamente impossível (branco sobre preto), e a guarda emitiu PASS.

Regra nova, e ela vale para toda guarda de contraste do projeto: número fora da faixa física [1,00 … 21,00] não é veredito, é MEDIDOR QUEBRADO. A guarda passa a reprovar a si mesma quando mede fora da faixa, com essa palavra no placar. É a irmã da regra do 15º defeito — guarda que mede fora do controle não declara veredito nenhum; aqui, guarda que devolve número impossível também não.

E o falso positivo, evitado por medição: consertado o parser, a guarda comparou o anel de escolha com a cor da amostra e reprovou o tema escuro em 2,23. Estava prestes a forçar conserto num artefato correto — o que o §64.3 (forma 2) registra como tão caro quanto não ver o defeito. Medido no pixel, os dois não se tocam: entre a amostra e o anel há uma faixa de 2px de surface-raised. O SC 1.4.11 cobra 3:1 contra as cores adjacentes, e adjacente é o que encosta, não o que está por perto.

Correção: a guarda varre a linha de pixels que sai do centro da amostra para fora, localiza a faixa do anel pela cor computada e mede contra as duas faixas que o encostam. Se alguém remover a faixa de respiro, a vizinha passa a ser a própria amostra e a guarda cobra isso sozinha — porque ela mede o que foi pintado, não o que foi declarado.

65.5 A bancada e a suíte#

banco-identidade.html v0.1, gerada por validacao/gen-banco-identidade.py sobre validacao/banco-identidade-template.html. Barra de provas fixa e seletor de largura desde a v0.1 (BT1/BT2). Estados impressos lado a lado (CP31) — o controle é o Estado 1 e é operante.

FONTE ÚNICA DOS GLIFOS, com a fronteira dita: o gerador não copia os 31 desenhos para dentro de si — e, desde a v0.3 (§65.12), nem a lista de nomes: até a v0.2 a lista de 28 era escrita à mão e envelheceu em silêncio no dia em que o set foi a 30. Ele lê banco-icones.html por data-icon (nome, categoria, aliases e desenho), reordena na ordem do §45.3 e aborta se a contagem sair do denominador declarado (31) ou se aparecer categoria fora da tabela — mesma doutrina do tokens_bloco.py, porque lista duplicada é drift esperando data. O certo seria um seed-icones.json, que o NM5 já prevê; enquanto não existe, a dependência fica registrada em SI-P1.

suite-identidade.mjs — 28 PASS · 0 FAIL · 0 [n/a] · 1 medida. Oito das guardas são de operabilidade: elas clicam, digitam e teclam, porque em 2026-08-16 a banco-data.html v0.1 passou em 25 PASS · 0 FAIL com o calendário inoperante.

65.6 Pendências#

65.7 SI17 — a identidade em USO: um bloco único nas OITO telas, e a guarda que mede COMPORTAMENTO#

Escrito em 2026-08-19, ao executar a SI-P4. Esta seção é autossuficiente: presume um leitor que nunca viu a conversa que a gerou.

65.7.1 O que é o .sigla, e qual era o defeito#

O .sigla é o quadrado de identidade de entidade em uso nas telas — 24×24px, raio 6px, glifo svg de 14px, aria-hidden, na barra superior, ao lado do nome da entidade. Ele é o §65 aplicado: o §65.1–§65.6 especifica o seletor de identidade (a bancada banco-identidade.html, onde a pessoa ESCOLHE glifo e cor); o .sigla é o resultado dessa escolha, mostrado no produto.

O contrato escrito, e ele estava no comentário do próprio tela-shell: "o produto escreve 1..6, o DS resolve fundo E tinta". Medido em 2026-08-19, o contrato era FALSO em sete das oito telas:

As consequências, todas de contrato:

1. Em lista, tabela e referencia, escrever data-ident de 1, 2, 3, 5 ou 6 NÃO PINTAVA NADA. A regra base não tinha fundo: o quadrado ficava transparente e o glifo caía sobre a barra.
2. Em detalhe, chat, gantt e quadro a identidade estava CONGELADA na regra base. Não existia valor que o produto pudesse escrever para mudá-la — o que contraria o SI1 (a identidade é um PAR que o produto escolhe).
3. O tela-shell, a única que cumpria o contrato, tinha a tinta do padrão LITERAL (color:#FFFFFF cru) onde cabe --seed-text-on-brand-deep, que vale #FFFFFF nos dois temas. A guarda NV1 não pega este caso: ela caça var(--x, literal), e aqui o literal está sozinho — é a lacuna NV1-c.

O CENSO ANTERIOR ESTAVA INCOMPLETO, e isso é a lição do achado. O §69.6 (auditoria-consumidor.mjs) registrava QUATRO telas. São OITO. As quatro que faltavam — chat, gantt, quadro e referencia — só apareceram quando a guarda SI17 varreu a PASTA inteira em vez de uma lista escrita à mão. É a regra "PLACAR QUE MEDE NOME NÃO MEDE COISA" na sua outra forma: lista escrita à mão mede a lista, não o acervo. Instrumento de ALVO DE PASTA acha o que a lista esqueceu.

65.7.2 O bloco único, e as alternativas descartadas com número#

O Rafael qualificou a unificação como INEGOCIÁVEL, verbatim: "unificar é melhor… precisamos manter o mesmo padrão, isso é inegociável". O que restava era qual forma, e a medição resolveu:

.sigla { width:24px; height:24px; border-radius:6px; flex:none;
  display:flex; align-items:center; justify-content:center;
  background: var(--seed-surface-brand-deep); color: var(--seed-text-on-brand-deep); }
.sigla svg { width:14px; height:14px; }
.sigla[data-ident="1"] { background: var(--seed-entity-1); color: var(--seed-entity-1-ink); }
.sigla[data-ident="2"] { background: var(--seed-entity-2); color: var(--seed-entity-2-ink); }
.sigla[data-ident="3"] { background: var(--seed-entity-3); color: var(--seed-entity-3-ink); }
.sigla[data-ident="4"] { background: var(--seed-entity-4); color: var(--seed-entity-4-ink); }
.sigla[data-ident="5"] { background: var(--seed-entity-5); color: var(--seed-entity-5-ink); }
.sigla[data-ident="6"] { background: var(--seed-entity-6); color: var(--seed-entity-6-ink); }

ALTERNATIVAS DESCARTADAS, com o motivo:

• Padrão transparente (o que lista, tabela e referencia faziam): identidade que SOME quando o produto escreve uma posição que a tela não previu. É o defeito, não o conserto.
• Padrão na posição 1: mudaria a aparência de quem hoje não declara data-ident — e sem necessidade.
• Cor na regra base, como detalhe/chat/gantt/quadro: congela a identidade e contraria o SI1.
• Geometria em token (--seed-radius-3, que hoje vale 6px), como o tela-chat fazia: recusada porque as outras medidas da MESMA anatomia (24px do quadrado, 14px do glifo) são literais, e meia-tokenização é pior que nenhuma — o número passaria a mudar por um lado e não pelo outro. Os três números ficam literais e travados pela cláusula SI17-d.

Os pares, medidos (razão de contraste da tinta declarada sobre a posição):

CORREÇÃO DE NÚMERO, com supersede. A rodada zero escrita em 2026-08-18 (§7-a da abertura daquela sessão, e §91.1 do MANIFESTO) dizia que o padrão media 13,55 sobre #00352F. Está errado: --seed-surface-brand-deep vale #006C62 no claro e #005048 no escuro, não #00352F. Os números certos são 6,32 e 9,37, os dois acima do piso 4,50. A decisão não muda — o valor citado, sim.

65.7.3 Os contratos SI17#

65.7.4 A guarda, e por que ela mede COMPORTAMENTO#

validacao/guarda-si17.mjs — ALVO DE PASTA: varre todo *.html da raiz, e arquivo sem .sigla sai declarado [n/a] NOMEADO, nunca em silêncio. Para cada arquivo e tema, ela abre o artefato no navegador, escreve data-ident de 1 a 6 no elemento real e lê o estilo computado — e compara com o valor computado do token, resolvido por uma sonda no mesmo documento. Token consumido e não definido resolve para transparente: isso sai nomeado como FANTASMA (NV-01), não como comparação de cor.

PROVA DE REPROVAÇÃO — obrigatória, e o caso fundador é o artefato onde o defeito EXISTE. Rodada sobre as cópias anteriores das quatro primeiras telas: 0 PASS · 8 FAIL. Em tela-lista e tela-tabela a SI17-a reprovou 5 das 6 posições (a 4 passa, que é a única declarada) e a SI17-c reprovou o padrão transparente; no tela-shell, que já cumpria a SI17-a, a SI17-c reprovou a tinta literal do padrão. Guarda que não é provada capaz de reprovar não foi consertada: foi cegada.

PLACAR, duas execuções idênticas: guarda-si17.mjs — 16 PASS · 0 FAIL · 86 [n/a], sobre 51 arquivos da raiz × 2 temas, sem teto, sem amostragem e sem exclusão por custo. As 16 folhas medidas são as oito telas × dois temas; os 86 [n/a] são os 43 arquivos sem .sigla, nomeados no placar.

65.7.5 O que a execução tocou, e a prova de que não mudou um pixel#

As oito telas são GERADAS (§64.18: artefato gerado recebe no MOLDE e é regerado com PRÉ-VOO). Foram editados os oito moldes validacao/*-template.html, e as listas NOMES dos oito gen-*.py ganharam os tokens que faltavam — --seed-entity-6, --seed-entity-6-ink e vários -ink em sete dos oito geradores, e --seed-text-on-brand-deep em seis. Sem isso o bloco novo consumiria token FANTASMA e a posição 6 não pintaria em tela nenhuma — o defeito que a SI17-a agora nomeia.

PRÉ-VOO nas oito, comparando o gerado com o disco ignorando comentários: só as linhas pretendidas. PROVA DE INÉRCIA (validacao/prova-inercia.mjs, dois temas × 1440px e 390px): 0 de 26.352.000 pixels diferentes em 32 comparações, em duas execuções. Mudança provada inerte não vai a gate.

Achado de instrumento que saiu daqui: o modo INTEIRA=1 da prova de inércia (página inteira, que nasceu nesta execução) tem RUÍDO PRÓPRIO medido — 8 a 19 pixels na borda direita do tela-shell a 390px, que se reproduzem comparando o arquivo COM ELE MESMO. São os cantos arredondados, antisserrilhados, de um controle que encostava na borda. O número que vale é o do clip de 900px, e o modo de página inteira serve para achar deslocamento abaixo da dobra, não para contar pixel de borda.

65.7.6 Pendência que fica#

65.8 SI18 — o PONTO DE COR de entidade (.ent): spec própria, porque ele NÃO é o §65.7 mal-feito#

Escrito em 2026-08-19. Fecha a quarta decisão do §64.13.4 ("o ponto de cor decorativo ganha spec própria e entra no canônico, para não ficar ad hoc"). Seção autossuficiente.

65.8.1 O que ele é — e por que unificá-lo com o .sigla seria ERRADO#

O .ent é um quadrado de 12×12px, raio 2px, aria-hidden="true", SEM glifo, que aparece ao lado do NOME da entidade na árvore de escopo (a lateral que lista espaços, pastas, clientes e obras). Ele ecoa a cor da entidade; o nome está escrito ao lado.

Ele não é o .sigla do §65.7 mal-feito, e a diferença é de FUNÇÃO:

Por que a distinção importa, e ela é a razão desta spec existir: a auditoria de consumidor (§69) classificou o .ent como "reimplementação do §65". Unificá-los poria glifo em 29 elementos onde ninguém pediu — e o glifo existe no .sigla por uma razão que não vale aqui: lá ele é o segundo canal quando a cor repete acima de seis entidades (CP23) e quando o rótulo some no degrau estreito. No .ent o segundo canal é o próprio nome, que está sempre ao lado e nunca some. Guarda que condena artefato correto força conserto errado — e aqui o "conserto" seria pior que o defeito.

65.8.2 As QUATRO divergências medidas, em 29 elementos e 7 telas#

65.8.3 O contrato SI18, e o bloco único#

.ent { width:12px; height:12px; border-radius:var(--seed-radius-1); flex:none;
  background: var(--seed-surface-brand-deep); }
.ent[data-ident="1"] { background: var(--seed-entity-1); }
/* … 2 a 6, idênticas … */

A cor sozinha não carrega informação aqui — o nome está ao lado —, por isso o elemento é decorativo e aria-hidden. Isso satisfaz a SC 1.4.1 sem precisar de segundo canal.

65.8.4 A guarda, o que ela achou e o que a execução mexeu#

A régua do SI18 é a mesma do SI17: escrever a posição no elemento dentro do navegador e ler o estilo computado. Por isso não nasceu guarda nova: a validacao/guarda-si17.mjs foi PARAMETRIZADA e passou a carregar os dois contratos numa tabela. A regra do projeto é explícita — não duplique guarda; quando dois contratos têm a mesma régua, parametrize.

EXCLUSÃO DECLARADA E IMPRESSA NO PLACAR: banco-composicao.html tem uma classe .ent que é outro componente — um cartão de 36px com glifo, da bancada de composição. Colisão de nome, não de contrato. Ela sai da conta do SI18 nomeada, com o motivo.

ACHADO QUE SÓ A EXECUÇÃO PODIA PRODUZIR: ao trocar o raio literal do tela-referencia pelo token --seed-radius-1, o raio computado caiu para 0px — canto vivo onde havia canto de 3px. O gen-tela-referencia.py não emitia esse token: era FANTASMA. Corrigido na lista NOMES. Token consumido e não definido não pinta — e aqui ele não pintou o canto.

PLACAR: guarda-si17.mjs (SI17 + SI18) — 30 PASS · 0 FAIL · 174 [n/a], 51 arquivos × 2 temas × 2 contratos, em duas execuções idênticas. PROVA DE REPROVAÇÃO: sobre as cópias anteriores, o SI18 reprova as 7 telas nos 2 temas.

O que mudou de pixel, e é pouco de propósito:

Os dois primeiros vão à folha de gate com recorte antes/depois — o gate pode revertê-los.

Validação depois: contraste 14 PASS · 0 FAIL a 1440px e 14 · 0 a 390px · forced-colors FC1 e FC2 14 · 0 cada · BT7 reflow 30 · 0 · 3 nas sete · suite-detalhe 73 · 0 · suite-gantt 43 · 0 · suite-quadro 35 · 0.

65.9 SI-P5 FECHADA — o quadrado da barra superior é a EMPRESA LOGADA, e o ERP é multi-empresa#

Escrito em 2026-08-19, a partir da resposta do Rafael no gate v13.3. Fecha a SI-P5, aberta no §65.7.6 no mesmo dia. Nenhuma das três alternativas que eu havia desenhado foi a escolhida — e é por isso que esta seção existe: a pergunta estava certa, as opções estavam erradas, porque eu havia presumido que aquele quadrado era "mais uma entidade do sistema".

65.9.1 O que eu media, e o que a coisa é#

O .sigla da barra superior aparece em oito telas. Cinco traziam "SEED engenharia"; três traziam "SEED · Operação". As oito usavam a posição de cor 4. Eu tratei isso como uma violação do SI1 (a identidade é um PAR: glifo E cor, nunca um só) e levei a gate três alternativas — duas entidades com cores distintas, uma entidade só, ou glifos distintos na mesma cor.

Resposta do Rafael, verbatim (2026-08-19):

"nenhuma das 3 alternativas. o que ocorre que nao existe SEED operação. Seria SEED energia. nao sei porque gerou exemplo com a palavra operação. pode mudar a cor, se estou certo, a palavra SEED engenharia aparece nesse ponto mostrando que estamos tratando da empresa SEED engenharia, representando a empresa que está logada no sistema, pois o ERP será multi empresa, quando mudamos para SEED energia a cor deve mudar, o glifo pode ser o mesmo. hoje temos essas duas empresas, mas quando tivermos mais, vamos ter outros nomes e mais cores para cada um."

Fato de produto que eu não tinha: o ERP é multi-empresa. Aquele ponto da barra não identifica um projeto, um cliente ou um assunto — identifica a empresa em cujo contexto o usuário está operando neste momento. Hoje são duas (SEED engenharia e SEED energia); haverá mais.

"SEED · Operação" era dado sintético inventado por mim numa sessão anterior, sem correspondência com a empresa real, e sobreviveu porque ninguém tinha olhado aquele canto. Dado sintético que parece plausível é o mais perigoso: ele não é conferido, porque não chama atenção.

65.9.2 O contrato SI17-e — a empresa logada#

Implicação declarada para o ERP: a posição de cor da empresa é campo de cadastro da empresa, não constante de CSS. Quando entrar a terceira empresa, ela recebe a próxima posição livre da paleta fechada de seis (CP23). Da sétima em diante a cor repete e quem distingue passa a ser o nome ao lado — que é exatamente o que o SI1 já previa, e o motivo de o nome nunca poder sumir da barra.

65.9.3 A cor escolhida, e por NÚMERO#

SEED engenharia fica na posição 4 (turquesa profundo #005048) — é a família da marca e não se mexe. Para SEED energia escolhi a posição 3 (azul vivo #01B3E0). A escolha foi por medida, não por gosto: distância de luminância entre cada posição e a posição 4 —

O critério é o mesmo do SI12: quando a informação é "qual dos dois", o canal não pode ser só matiz — tem de sobreviver ao cinza.

65.9.4 O que a execução tocou, e o que ficou provado#

Três moldes (tela-detalhe-template, tela-gantt-template, tela-quadro-template) e seus três geradores. O raio (bolt) saiu; entrou o mesmo glifo de quatro quadradinhos das outras cinco telas, com data-ident="3".

Verificação no navegador, nas oito telas — ident · fundo computado · glifo · rótulo:

As oito com o mesmo glifo — quatro quadradinhos. Recorte antes/depois nos dois temas: bloco D1 da folha render-audit/gate-v134/fechamento.html.

---

65.10 SI19 e SI20 — pessoa é CÍRCULO, empresa é QUADRADO, e cada uma tem DOIS estados (fecha a PS-P6)#

Escrito em 2026-08-19, a partir da resposta do Rafael no gate v13.3. Fecha a PS-P6, que havia nascido no §62.8 quando a medição revogou a PS-P5 (o círculo de iniciais das telas de dado não carregava uma pessoa: carregava um CLIENTE).

65.10.1 O defeito, e o nome que o causou#

As telas tela-tabela (6 linhas) e tela-referencia (5 linhas) traziam, na coluna Cliente, um span.pessoa contendo um span.mini-avatar: círculo de 26px com as INICIAIS do cliente e um ponto de PRESENÇA (disponível / ausente / ocupado) grudado no canto.

Dois erros, e o segundo é filho do primeiro:

1. O nome da classe dizia PESSOA e o conteúdo era EMPRESA. Foi esse nome que fez a PS-P5 nascer errada: eu li .pessoa e escrevi uma pendência mandando migrar aquilo para a paleta de pessoa do §62. A medição derrubou a premissa. Nome mentiroso não é cosmético: ele produz pendência errada, e pendência errada consome sessão inteira.
2. Presença é atributo de GENTE. Ninguém marca a Metalúrgica Andrade como "ocupada". O ponto de presença ali era ruído com aparência de dado.

Resposta do Rafael, verbatim (2026-08-19):

"acho que no caso do cliente, para diferenciar podemos deixar quadrado com glifo, da mesma forma que o usuário pode trocar as letras pela foto, a empresa pode trocar o glifo pela logo. se adicionarmos a logo no cadastro do cliente isso vai ocorrer, ou o proprio cliente se dermos acesso a ele no dia que ele tiver acesso ao painel de cliente, podemo dar acesso a ele trocar a logo, o que influenciará nisso, mas o metodo é modelagem no ERP, o importante é saber o estado."

65.10.2 Os contratos#

A matriz completa dos quatro estados está desenhada e provada em banco-identidade.html, seção "Pessoa é círculo, empresa é quadrado":

Quem escolhe entre os dois estados é o CADASTRO, nunca o componente. É a resposta desenhada à frase do Rafael: "o importante é saber o estado". O desenho está pronto para receber a logo no dia em que o ERP a tiver — ligar o campo não vira redesenho.

65.10.3 INFERÊNCIA DECLARADA: o glifo da empresa é ÚNICO, não um por cliente#

Isto não é decisão do Rafael — é minha, e está aqui separada de propósito. O Rafael decidiu "quadrado com glifo"; eu decidi que o glifo é sempre o mesmo (building, do inventário de 28 do §45) e que quem diferencia um cliente do outro é a POSIÇÃO DE COR.

Razão: um ERP deriva iniciais do nome de uma pessoa (soma de códigos de ponto — SI15), mas não deriva um desenho de uma razão social. Um glifo por cliente teria de ser escolhido à mão, cliente a cliente, e isso é trabalho de cadastro que ninguém faz. Se um dia for decidido o contrário, o glifo nasce como campo do cadastro do cliente, escolhido numa lista de 28 — vira dado, não CSS, e o desenho já está pronto para recebê-lo.

Legibilidade do building a 14×14px foi MEDIDA antes de virar padrão, em 2026-08-19, ampliada 4×, nos dois temas, contra cinco candidatos (home, people, location, growth, substation): lê como prédio, sem empastar as janelas. Glifo de inventário não dispensa medição de legibilidade no tamanho de uso: 24px e 14px são componentes diferentes do mesmo desenho.

65.10.4 O que a execução tocou#

Dois moldes (tela-tabela-template, tela-referencia-template) e dois geradores. A classe .pessoa morreu e virou .org; a classe .mini-avatar deixou de existir; o quadrado é o .sigla do §65.7 — mesmo contrato, mesma guarda, nenhuma classe nova.

As tuplas de dado dos dois geradores encolheram: os campos iniciais e presença foram removidos, e com eles a asserção PRESENCAS. O contrato C2 (três estados de presença) continua vivo e provado no .avatar da barra superior e em banco-pessoa.html — o que morreu foi o uso indevido dele numa empresa, não o contrato.

Alcance da guarda CRESCEU sem que ninguém a editasse: a guarda-si17.mjs mede .sigla varrendo a pasta, então tela-tabela foi de 1 para 7 quadrados medidos e tela-referencia de 1 para 6 — 30 PASS · 0 FAIL · 174 [n/a], pior par de contraste 5,11 (piso 4,50). É o argumento a favor de guarda que varre pasta em vez de ler lista: o acervo cresce e a medida acompanha sozinha.

Recorte antes/depois nos dois temas: blocos A1, A2 e A3 da folha render-audit/gate-v134/fechamento.html.

---

65.11 CC-P8 FECHADA — o ponto de status da legenda deixa de ser um CARACTERE#

Escrito em 2026-08-19. Decisão do Rafael no gate v13.3, verbatim: "troca a bolinha".

Em banco-dataviz-dg.html, cartão "O mês em números", os três marcadores da linha "status da carteira" eram o caractere U+25CF (●) pintado com color. Sendo TEXTO, caíam no SC 1.4.3, que exige 4,50:1. Medidos os seis pares (3 pontos × 2 temas):

O conserto trocou a NATUREZA do elemento, não a cor: virou um quadradinho pintado de 12×12px, raio 2px, aria-hidden, sem caractere nenhum. Sendo objeto gráfico, o critério cabível passa a ser o SC 1.4.11 (3:1) — e os mesmos seis números passam, com o pior par em 3,31. Nenhuma cor mudou. Nada foi maquiado: mudou o que o elemento É, e com isso o critério que a norma manda aplicar.

ALTERNATIVA DESCARTADA: subir a cor até 4,50 mantendo o caractere — descartada porque mudaria a cor do status na carteira inteira para consertar um marcador decorativo, e porque o rótulo textual ao lado ("4 usinas ok") já é quem carrega o significado (DG16: cor nunca sozinha).

POR QUE A CLASSE NÃO É .ent: o .ent do §65.8 é o ponto de cor de ENTIDADE, e a cor dele vem da paleta fechada de seis (CP23). Aqui a cor vem da taxonomia de status (§22). Mesma geometria de propósito — a linguagem de forma é uma só; nome diferente porque a FONTE DA COR é outra. Reusar .ent obrigaria a excluir este arquivo da guarda SI18, e toda exclusão declarada é uma dívida com juros. A classe chama-se .pt-status.

Recorte antes/depois nos dois temas, ampliado 10×: blocos C1 e C2 da folha render-audit/gate-v134/fechamento.html.

65.12 SI-30 (2026-09-05) — o set foi a 30 e o seletor ACOMPANHA: inventário derivado, grade 6 × 5#

Para quem lê sem ter visto a sessão. Em 2026-09-05 a pendência FV-P5 acrescentou dois glifos de domínio ao set do §45 — hard-hat (destaque Obras) e solar-panel-plus (destaque SEED Plus) —, e o set passou de 28 a 30 (v1.39). O changelog da v1.39 registrou a consequência sem executá-la: "o seletor de identidade do §65 segue com os 28 glifos de agosto — 30 não fecha em 7 colunas (6 × 5 fecha)". Esta subseção é a execução. A decisão é consequência, não escolha nova: o seletor mostra o set (SI7 consome os aliases do §45.3; SI6 anuncia “N de TOTAL”), e um seletor com 28 num set de 30 anuncia posição errada e esconde dois glifos que o produto já usa. Aplicada pela sessão pelo critério de melhoria óbvia e exposta a veto do Rafael no mesmo movimento.

O que se achou ao abrir o gerador, e que é mais importante que o número. O INVENTARIO do gen-banco-identidade.py era uma lista de 28 nomes escrita à mão (comentário original: "na ordem em que ele está escrito lá", o §45.3); só os desenhos, categorias e aliases vinham da bancada. É a forma exata de drift que o §65.5 dizia combater — a lista duplicada envelheceu no dia em que a fonte mudou, sem aviso. Correção: o inventário inteiro passa a ser derivado de banco-icones.html (a mesma fonte que a suite-icones.mjs valida na IC-01 e que o gen-destaques-instagram.py já lê) e reordenado na ordem do §45.3 — categoria na ordem da tabela, nome em ordem alfabética dentro dela. Conferido nome a nome: os 28 antigos saem na mesma sequência da lista à mão; hard-hat entra na 6ª posição e solar-panel-plus na 13ª, onde a tabela os escreve; substation (a escolha inicial) passa de 12ª a 14ª. O que fica declarado no gerador é só o denominador TOTAL_GLIFOS = 30, com abort se a bancada trouxer outro número ou categoria fora da tabela — o mesmo número que a IC-01 e o gen-destaques-instagram.py declaram; os quatro lugares mudam no mesmo commit.

A grade: 6 × 5, e por quê. A régua do SI5 é linhas inteiras (total % colunas == 0), não “7 colunas”: o 7 era consequência do 28. Entre os divisores de 30, 6 × 5 é o vizinho imediato do 7 × 4 aprovado no gate de 2026-08-17 (uma coluna a menos, uma linha a mais); 10 × 3 e 15 × 2 esticam a grade na horizontal, 5 × 6 e 3 × 10 na vertical. Célula segue 44 × 44 (SI13). O data-colunas passa a 6 e o limiar da guarda SI-OP3b (“menos que uma linha cheia”) passa a ser lido do DOM, não escrito na suíte.

Placar, com denominador (antes → depois, mesma máquina, 2026-09-05):

Descartado, com o porquê: manter 28 (o seletor mentiria sobre o set e anunciaria posição errada); 7 colunas com sobra (quebra o SI5 — o ↓ da última coluna cai no vazio); derivar do §45.3 deste markdown em vez da bancada (a bancada é o que a IC-01 valida e o que os outros consumidores leem — uma fonte para todos; a tabela do §45.3 segue a fonte humana, e o denominador fixo 30 é o que amarra as duas). O que não muda: a SI-P1 continua aberta (o seed-icones.json do NM5 segue sendo a resposta certa; derivar da bancada reduz o drift, não o acoplamento); os “28” do §65.9 são narrativa datada de 2026-08-19 e ficam como história; o texto do §65.5 sobre a v0.1 é histórico.

Supersede parcial, no mesmo dia — ver §65.13. A régua linhas inteiras desta subseção durou o intervalo entre a FV-P5 e a GL-R2: com 31 glifos (primo) ela passou a linhas inteiras exceto a última, por decisão dele (MANIFESTO §150). O inventário derivado, o denominador único e as alternativas de coluna aqui registradas continuam valendo.

65.13 SI-31 (2026-09-05) — o set foi a 31, 31 é primo, e a régua SI5 passa a “linhas inteiras#

exceto a última” Para quem lê sem ter visto a sessão. No gate do traço (MANIFESTO §150) o Rafael decidiu dois glifos pelos modelos em imagem que anexou: nasce transmission-tower (torre de transmissão, para o destaque Subestações) e o generator é redesenhado sem somar (v1.42, GL-R2). O set do §45 foi de 30 a 31 — e 31 é primo: nenhuma grade de 2 a 30 colunas fecha em linhas inteiras, então a régua SI5 registrada no §65.12 (linhas inteiras, total % colunas == 0) não tinha saída. A folha do gate levou a pergunta como T-SET, e a resposta dele, verbatim: “T-SET: glifo novo + régua da grade aceita última linha incompleta (recomendado)”. Esta subseção é a execução. O que o abort fez, e por que é mérito. O gen-banco-identidade.py v0.3 PAROU em TOTAL_GLIFOS = 30 quando a bancada de ícones foi a 31 — exatamente o comportamento desenhado no §65.12 (“aborta se a bancada trouxer outro número: o set mudou, releia o canon”). Nenhuma bancada de 30 glifos foi gerada sobre um set de 31. A régua nova, e o que ela ainda exige. Linhas inteiras exceto a última: a última linha pode ter de 1 a colunas − 1 células. O gerador continua exigindo (a) pelo menos duas linhas cheias — com uma só, ↓ não teria destino em coluna nenhuma e o SI5 seria letra morta — e (b) a sobra medida por divmod e declarada no resumo da geração (31 em 6 colunas (5 linha(s) cheia(s) + última com 1)). Colunas: 6, as do gate de 2026-09-05; 7 daria 4 cheias + 3 (mais sobra, no desenho que o 30 já tinha deixado); 31 × 1 e 1 × 31 fecham, mas viram fila — o defeito que o SI5 existe para impedir. Teclado na última linha — a decisão e a fonte. Uma linha incompleta cria células sem vizinha abaixo (na penúltima linha, colunas 2 a 6). Duas saídas defensáveis: (1) mandar o foco à última célula existente — era o que o Math.min(i + passo, n − 1) da v0.3 fazia, por acidente de implementação —, ou (2) não mover. Aplicada a (2), pela fonte: WAI-ARIA Authoring Practices Guide (APG, o guia do W3C de como um padrão de interface se opera por teclado e se anuncia à tecnologia assistiva), padrão Grid, seção “Keyboard Interaction”, em w3.org/WAI/ARIA/apg/patterns/grid/, consultado em 2026-09-05: “Down Arrow: Moves focus one cell down. If focus is on the bottom cell in the column, focus does not move.” — e o espelho para Up Arrow. A saída (1) é uma troca de coluna disfarçada de descida, o que o próprio SI5 chama de “seta que mente sobre o layout”; e o APG só admite envolvimento (wrap) como opção de layout grid, nunca salto diagonal. Consequência aplicada junto e exposta a veto: ↑ na primeira linha também deixa de saltar à primeira célula (era o Math.max(i − passo, 0)), e ←/→ nas pontas deixam de reanunciar o par — a tecla é consumida (a página não rola), nada muda, nada se anuncia. Placar, com denominador (antes → depois, mesma máquina, 2026-09-05):

A guarda nova, SI-OP3c. Mede as colunas pelo offsetTop (como o script da bancada), prova por identidade do elemento que ↓ sem destino fica, e por geometria que ↓/↑ com destino mantêm a coluna; com a última linha cheia declara [n/a] — contrato não exercido, não aprovado em vão. Defeito de instrumento na estreia, registrado: a primeira forma comparava getBoundingClientRect antes e depois da tecla e reprovou email → growth (destino certo, mesma coluna), porque focus() numa célula da última linha ROLA a página e o y de viewport diminuiu — o 15º defeito do §74 do MANIFESTO em outra roupa. Corrigida para offsetLeft/offsetTop (coordenadas de layout) com a causa medida, não ajustando o esperado ao obtido. Descartado, com o porquê: tirar um glifo para voltar a 30 (o set é decisão dele, §150; o seletor mostra o set); esperar um 32º glifo (adiar deixaria o SI6 anunciando “de 30” num set de 31 e esconderia a torre que o destaque Subestações já usa); manter o Math.min (troca de coluna sem aviso). O que não muda: a SI-P1 continua aberta (a bancada de ícones segue sendo a fonte enquanto o seed-icones.json do NM5 não existir); substation segue a 14ª (a torre entra na 17ª, depois de transformer); Home/End (battery, growth) inalterados; a paleta e os seis pares (SI3) não foram tocados.