---
fonte: 01-canonicos/seed-componentes.md
versao_da_fonte: v1.43
secao: 65
titulo: "Identidade de entidade — seletor de ícone e cor — **`estável`** (F7.5, 2026-08-16 · **promovido em 2026-08-17 pelo gate visual do Rafael — verbatim: 'aprovado'**) · SI1–SI16 · fecha **C6** · bancada `banco-identidade.html` **v0.4** (31 glifos, 6 colunas: 5 linhas cheias + 1 — §65.12 e §65.13) · `suite-identidade.mjs` **33 · 0 · 0** · **§65.7: SI17, a identidade EM USO, `guarda-si17.mjs` 16 · 0 · 86**"
sequencia: 71 de 98
bytes_do_corpo: 62232
md5_do_corpo: 8cef83e2322f8e40aaae1e4f9ce1d42c
gerado_por: 06-validacao/geradores/gen-camada-ia.py
nota: fatia GERADA — o corpo abaixo é byte a byte o trecho do canônico; edite o canônico, nunca esta fatia. Canônico inteiro em https://ds.seed.eng.br/01-canonicos/seed-componentes.md
---
## 65. Identidade de entidade — seletor de ícone e cor — **`estável`** (F7.5, 2026-08-16 · **promovido em 2026-08-17 pelo gate visual do Rafael — verbatim: "aprovado"**) · SI1–SI16 · fecha **C6** · bancada `banco-identidade.html` **v0.4** (31 glifos, 6 colunas: 5 linhas cheias + 1 — §65.12 e §65.13) · `suite-identidade.mjs` **33 · 0 · 0** · **§65.7: SI17, a identidade EM USO, `guarda-si17.mjs` 16 · 0 · 86**

> **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:**

| O quê | Veredito | Base |
|---|---|---|
| O **controle** (a paleta e a grade de glifos, abertas na criação do espaço) | **NÃO VISITADO** | Ele só abre pelo fluxo de **criação/edição**, que é escrita. A navegação autorizada é **somente leitura** (mesma barreira nomeada da **PS-P2**, que bloqueia C5 e C8) |
| O **resultado** do controle (o quadrado de identidade em uso) | **MEDIDO** | `estudo-clickup-completo.md` §3.2 — *"quadrado 20×20, `border-radius: 5px`, cor própria, inicial em 12px/700"* — e §8.2/§8.3, onde os pares de cor foram medidos um a um |

**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

| Rodada | Fonte | O que trouxe para a spec |
|---|---|---|
| **R1 — canon** | ARIA APG: *Radio Group* e *Grid (layout grid)* | O `grid` existe para **agrupar widgets preservando a semântica dos filhos** e navegar em duas dimensões (setas nas quatro direções, `Ctrl+Home/End`, um único tab stop). O `radiogroup`/`listbox` é o padrão **quando os itens são mutuamente exclusivos**. Como a escolha aqui É exclusiva, o papel é `radiogroup` — e o que se importa do `grid` é só o **teclado bidimensional** (SI5) |
| **R2 — mercado/stack** | Adobe React Aria, *Accessible Color Descriptions* (Spectrum) · Atlassian *color picker swatches* · Salesforce Lightning *Color Picker* | **Valor numérico não é nome acessível.** Verbatim do artigo da Adobe: *"I can't imagine what color that is just by hearing those numbers"* — eles substituíram o anúncio de RGB por descrição legível (algoritmo em OKLCH, 13 matizes base + modificadores). Para uma paleta **fechada de seis**, o algoritmo é desnecessário: **são seis palavras** (SI4) |
| **R3 — normas** | WCAG 2.2: *Understanding SC 1.4.11 Non-text Contrast* · SC 1.4.1 *Use of Color* · SC 2.5.8 *Target Size (Minimum)* · SC 4.1.3 *Status Messages* | **Achado que muda a spec:** o 1.4.11 **não cobre a amostra de cor em si** — a cor ali *é* o conteúdo, e o que se aplica é o **1.4.1**, que exige que a cor não seja o único canal. O que o 1.4.11 **cobra** é o **indicador de estado** (o anel da escolhida) contra as **cores adjacentes** (SI11). Daí a spec ter dois pisos distintos, e não um só |

**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

| # | Contrato | Por quê | Descartado, com o porquê |
|---|---|---|---|
| **SI1** | A identidade é um **PAR**: glifo **e** posição de cor. Nunca só cor, nunca só glifo | Acima de seis entidades a **cor repete** (CP23) e o glifo passa a ser o único distintivo; e na escala de cinza a cor cai antes do glifo | **Inicial da palavra sobre cor**, que é o que o produto de referência faz: duas entidades com a mesma letra e cores próximas ficam idênticas, e a inicial não sobrevive a renome |
| **SI2** | A paleta é **FECHADA** nas seis posições do CP23. Não existe cor livre | Com classe fechada, *"todas as cores passam?"* vira **seis medições**. Com classe aberta é amostra, e amostra sobre classe infinita não prova nada — é a lição que fechou a **PS-P3** | **Roda de matiz / campo hex**: classe infinita. **Medido no produto de referência: 6 de 13 reprovam (3,03–5,83)** |
| **SI3** | Cada posição carrega a **tinta DECLARADA**, não uma tinta calculada em render | Tinta por luminosidade oscila entre vizinhos e é instável na zona de cruzamento (o CP21 já registrou isso). Declarada, o par é auditável antes de existir tela | **Tinta calculada** (C21 do estudo): funciona, mas o cálculo tem de rodar em toda superfície e nenhuma delas prova a outra |
| **SI4** | Toda amostra tem **nome textual**; **hex não é nome** | R2/Adobe: número não descreve cor a quem ouve. Com paleta fechada bastam seis palavras — “turquesa vivo”, “dourado profundo”… | **Hex como `aria-label`** (prática comum e medida como insuficiente); **nome de marca inventado** (“Aurora”, “Cobre”): não é reconhecível fora de quem escreveu |
| **SI5** | As duas escolhas são **`radiogroup`**; a de ícone navega em **GRADE** — ↓/↑ andam **± o número de colunas**, Home/End vão às pontas; na última linha, incompleta desde a v0.4, célula **sem vizinha abaixo não move o foco** (padrão APG grid — §65.13) | A escolha é exclusiva: `radiogroup` é o que leva a exclusividade à AT. Mas a grade é bidimensional, e **seta que anda em fila numa grade mente sobre o layout**: ↓ tem de cair na célula visualmente abaixo | **`role="grid"`** — comunica estrutura e **não** comunica “escolha um”; é o defeito **C130** medido no §62. **`listbox`** — comunicaria seleção, mas o teclado seguiria linear e o sistema já tem o mecanismo de `radiogroup` em SG1/PR2: *um mecanismo, não mais um*. **Salto para a última célula** quando não há vizinha abaixo (o `Math.min` da v0.3) — troca de coluna disfarçada de descida, descartado na v0.4 |
| **SI6** | O nome acessível de cada opção traz a **posição na escala** — “Ícone subestação, 14 de 31”, “Cor turquesa vivo, 1 de 6” | Herda o **PR10**: o rótulo sozinho não diz onde a pessoa está num conjunto que ela não vê | Nome só com o rótulo (não localiza); contagem só no grupo (não acompanha o foco) |
| **SI7** | A busca consome os **ALIASES pt-BR e en** do inventário §45.3, com e sem acento | O **NM1** escreveu que os aliases existem para serem consumidos, e até aqui só a ⌘K os consumia. Quem cria um espaço de subestação digita “subestação”, não `substation` | Busca só pelo nome canônico em inglês (exige saber o vocabulário do set); busca difusa/fuzzy (imprevisível de auditar, e o set tem 31 itens) |
| **SI8** | O filtro **anuncia a contagem** — “7 de 31 ícones” — em região de status (SC 4.1.3) | Filtrar sem anunciar deixa quem não vê sem saber se sobrou algo | Anúncio por `alert` (interrompe); silêncio (o padrão do produto de referência) |
| **SI9** | Busca sem resultado tem **estado de vazio com caminho de volta** que funciona | §25 (estados não-felizes): vazio mudo é beco. E o caminho de volta é **botão**, não instrução | Só texto “nada encontrado” (não devolve ninguém); limpar sozinho ao não achar (destrói o que a pessoa digitou) |
| **SI10** | A prévia mostra o par **no tamanho de uso real** — 20px (sidebar), 32px (cabeçalho) e 48px (o próprio ajuste) | A decisão da pessoa é sobre **como fica na sidebar**, não sobre a amostra ampliada. Glifo que se lê a 48px pode virar mancha a 20px | Prévia só ampliada (esconde o problema que importa); prévia só a 20px (não deixa ver o desenho) |
| **SI11** | O **indicador de escolha** mede **≥ 3,00 contra as cores que o ENCOSTAM**, nos dois temas | SC 1.4.11 cobra o indicador de estado contra o **adjacente**. “Adjacente” é o que encosta — medido no pixel, não suposto (ver 65.4) | Piso 4,5 no anel (é elemento não-textual; exigir 4,5 reprovaria indicador legítimo); nenhum piso (o anel some no tema que ninguém abriu) |
| **SI12** | A escolha tem **DOIS canais** — anel **e** glifo `check` — nunca só cor | SC 1.4.1. Na escala de cinza duas posições de claridade próxima colidem; sob `forced-colors` o fundo do sistema substitui o nosso. **A forma sobrevive aos dois** | Só anel (morre em forced-colors); só opacidade/escala (não é canal para quem não enxerga a diferença) |
| **SI13** | Alvo **≥ 44×44px** em amostra e em célula de glifo | Piso do projeto, acima do SC 2.5.8 (24×24). Grade de 31 células é onde a tentação de encolher aparece primeiro | Célula de 32px “porque cabem mais” (o alvo é o que se erra, não o que se vê) |
| **SI14** | Mudar anuncia **o par completo**, não o campo mexido — “Identidade: subestação em azul profundo.” | As duas escolhas compõem **um** objeto. Anunciar só “azul profundo” obriga quem ouve a montar o par de memória | Anúncio por campo (dois anúncios para uma decisão) |
| **SI15** | A identidade inicial é **DERIVADA do nome e reproduzível** — soma de códigos de ponto —, nunca aleatória | Identidade que dança entre duas gerações do mesmo arquivo é o defeito que o PS8 já proibia para avatar. **E a derivação tem de bater entre as linguagens**: gera em Python, consome em JavaScript | `Math.random()` (nunca reproduz); **`hash()` do Python** (randomizado por processo — `PYTHONHASHSEED`; a armadilha está registrada no §74 do MANIFESTO) |
| **SI16** | **Nunca nasce uma sétima cor**: o seletor não tem “personalizar”, campo hex nem input de cor | É o CP23 literal. E é o que mantém a prova possível: um único caminho para cor livre devolve a classe ao infinito | “Só uma cor extra para o cliente X” — é assim que toda paleta fechada morre |

### 65.3 A anatomia, e os números medidos

**A paleta (CP23, enumerada nos dois temas — `suite-identidade` SI3):**

| Posição | Fundo | Tinta | Medido (claro e escuro) |
|---|---|---|---|
| E1 — turquesa vivo | `#11B0A0` | `#242E34` | **5,11** |
| E2 — dourado vivo | `#D49400` | `#242E34` | **5,30** |
| E3 — azul vivo | `#01B3E0` | `#242E34` | **5,63** |
| E4 — turquesa profundo | `#005048` | `#FFFFFF` | **9,37** |
| E5 — azul profundo | `#006783` | `#FFFFFF` | **6,43** |
| E6 — dourado profundo | `#7B5500` | `#FFFFFF` | **6,68** |

**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):

| Fundo | Tinta | Razão | |
|---|---|---|---|
| `#12a594` | branco fixo | **3,07** | reprova |
| `#f76808` | branco fixo | **3,03** | reprova |
| `#0091ff` | branco fixo | **3,23** | reprova |
| `#ab4aba` | branco fixo | 4,75 | passa |
| `#ffc53d` | **tinta escura** | 13,31 | passa |

**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**.

| Guarda | O que ela faz de fato |
|---|---|
| `SI-OP0` | monta o controle depois da carga em página |
| `SI-OP1` | **clica** numa amostra: escolhe, repinta a prévia e anuncia |
| `SI-OP2` | **clica** num glifo: troca a prévia nos três tamanhos |
| `SI-OP3` | **tecla** ↓ e prova por **geometria** (x mantido, y maior) que desceu uma linha |
| `SI-OP4` | **digita** “subestacao”, “subestação”, “trafo” e “zap” e confere o que sobra |
| `SI9` | **digita** um termo sem resultado, confere o vazio e **clica** no caminho de volta |
| `SI-OP6` | Home/End alcançam as pontas do set |
| `SI15` | **recalcula a derivação em JavaScript** e compara com o que o Python escreveu |

### 65.6 Pendências

| # | Pendência | Por que fica aberta |
|---|---|---|
| **SI-P1** | O gerador depende de `banco-icones.html` como fonte dos 31 glifos (28 até 2026-09-05; 30 e 31 no mesmo dia) | O `seed-icones.json` do **NM5** não existe. Enquanto não existir, gerar a bancada de identidade exige que a bancada de ícones esteja na pasta — acoplamento entre artefatos que **não deveria** existir, e que só some com o arquivo de dados |
| **SI-P2** | ✅ **FECHADA — gate visual APROVADO em 2026-08-17.** O olho achou dois glifos mal desenhados no set do §45 (`recycle`, `growth`), que **passavam em 30 verificações automatizadas**; redesenhados, com supersede no §45.4. A seção é promovida a `estável` |
| **SI-P3** | O **controle** do produto de referência segue **não visitado** | Ele só abre por escrita (mesma barreira da PS-P2). O que falta é **ergonomia comparada**, não vocabulário — o vocabulário está decidido e medido. Reabrir só se a navegação de escrita for autorizada |
| **SI-P4** | ✅ **FECHADA — EXECUTADA em 2026-08-19, sem gate: a mudança foi provada INERTE** (0 de 26.352.000 pixels em 32 comparações, duas execuções idênticas). O bloco do `.sigla` passou a ser **único e idêntico** nas telas que o carregam, e o censo do §69.6 estava **incompleto**: não eram quatro telas, eram **OITO** — `tela-chat`, `tela-gantt`, `tela-quadro` e `tela-referencia` também o reimplementavam e não constavam de lista nenhuma. A execução, o contrato **SI17** e a guarda que o mede estão no **§65.7**. *O `.ent` de 12px sem glifo continua fora: ele não é este §65* |


### 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:**

| tela | posições de cor declaradas | onde a cor morava | `data-ident` no HTML | glifo · rótulo |
|---|---|---|---|---|
| `tela-shell` | as SEIS | regras `[data-ident="N"]` | `4` | quadradinhos · "SEED engenharia" |
| `tela-lista` | **só a `4`** | idem | `4` | quadradinhos · "SEED engenharia" |
| `tela-tabela` | **só a `4`** | idem | `4` | quadradinhos · "SEED engenharia" |
| `tela-referencia` | **só a `4`** | idem | `4` | quadradinhos · "SEED engenharia" |
| `tela-detalhe` | **NENHUMA** | **na regra BASE**, fixa | **ausente** | **raio** · "SEED · Operação" |
| `tela-chat` | **NENHUMA** | **na regra BASE**, fixa | **ausente** | quadradinhos · "SEED engenharia" |
| `tela-gantt` | **NENHUMA** | **na regra BASE**, fixa | **ausente** | **raio** · "SEED · Operação" |
| `tela-quadro` | **NENHUMA** | **na regra BASE**, fixa | **ausente** | **raio** · "SEED · Operação" |

**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:

```css
.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):**

| posição | fundo | tinta | mede |
|---|---|---|---|
| 1 turquesa vivo | `#11B0A0` | `#242E34` | **5,11** |
| 2 dourado vivo | `#D49400` | `#242E34` | **5,30** |
| 3 azul vivo | `#01B3E0` | `#242E34` | **5,63** |
| 4 turquesa profundo | `#005048` | `#FFFFFF` | **9,37** |
| 5 azul profundo | `#006783` | `#FFFFFF` | **6,43** |
| 6 dourado profundo | `#7B5500` | `#FFFFFF` | **6,68** |
| **padrão** `surface-brand-deep` | `#006C62` claro · `#005048` escuro | `#FFFFFF` | **6,32** · **9,37** |

> **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

| # | Contrato | Por quê | Descartado, com o porquê |
|---|---|---|---|
| **SI17-a** | Para cada posição de `1` a `6`, o fundo computado é **exatamente** o valor de `--seed-entity-N` e a tinta o de `--seed-entity-N-ink` | É o contrato do §65 levado à tela. Reprova posição que caia no padrão (a regra não existe) ou fique transparente | Verificar se a REGRA existe no texto: mede implementação, não contrato — regra escrita e sobrescrita por outra folha passaria |
| **SI17-b** | O par medido de cada posição cumpre o **piso 4,50** do SI3 | O SI3 já vale na bancada; sem esta cláusula ele não valeria em tela | Piso 3,00 (é texto/glifo, não indicador de estado) |
| **SI17-c** | **Sem** `data-ident`, o quadrado **ainda pinta** — marca profunda com a tinta dela, nunca transparente | Identidade que some quando o produto escreve fora da faixa é o defeito de origem | Padrão transparente (é o defeito); padrão na posição 1 (muda aparência sem motivo) |
| **SI17-d** | A **geometria** é a mesma nas oito: **24×24px**, raio **6px**, glifo **14×14px** | Sem ela, "unificar" seria só a cor, e o quadrado poderia divergir de tamanho sem ninguém medir | Deixar a geometria livre (era o estado anterior: uma das oito usava token de raio e as demais literal) |

#### 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

| # | Pendência | Por que fica aberta |
|---|---|---|
| **SI-P5** | ✅ **FECHADA em 2026-08-19 pelo gate — e a resposta do Rafael não foi nenhuma das três alternativas que eu tinha desenhado.** Ver **§65.9**: aquele quadrado não é "uma entidade do sistema", é a **EMPRESA LOGADA** num ERP **multi-empresa**. "SEED · Operação" **nunca existiu** — o nome certo é **SEED energia** |

### 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:**

| | `.sigla` (§65.7 · SI17) | `.ent` (§65.8 · SI18) |
|---|---|---|
| tamanho | 24×24px · raio 6px | **12×12px · raio 2px** |
| glifo | **sim**, `svg` de 14px | **não** |
| onde | barra superior, **representando** a entidade ativa | árvore de escopo, **ao lado do nome** de cada entidade |
| o nome está ao lado? | sim, e some a ≤900px (3º degrau do CP15) | **sempre** |
| censo | 8 telas · 1 elemento cada | **7 telas · 29 elementos** |

> **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

| # | Divergência | Onde | Consequência medida |
|---|---|---|---|
| 1 | a cor vinha por **atributo `style` em linha** — `style="background:var(--seed-entity-N)"` | `chat`, `detalhe`, `gantt`, `quadro` (16 elementos) | **o consumidor decidindo mapeamento de cor**, que é exatamente a classe de defeito que a errata **E-CP-01** fechou para o `.sigla` |
| 2 | `data-ident="4"` escrito **sem regra para a posição 4** | `tela-lista` | o ponto ficava **TRANSPARENTE** — medido `rgba(0, 0, 0, 0)`. A entrada "Condomínio Alto da Serra" aparecia **sem ponto nenhum** |
| 3 | raio **literal de 3px** | `tela-referencia` | contra `var(--seed-radius-1)` (2px) das outras seis |
| 4 | regra presa ao **ancestral** (`.no .ent`) | `tela-chat` | o mesmo componente só existia dentro de um lugar |

#### 65.8.3 O contrato SI18, e o bloco único

| # | Cláusula | Por quê | Descartado, com o porquê |
|---|---|---|---|
| **SI18-a** | para cada posição de `1` a `6`, o fundo computado é **exatamente** `--seed-entity-N` | mesmo contrato do SI17: o produto escreve a POSIÇÃO, o DS resolve a COR | `style` em linha (o consumidor decide a cor — é a divergência 1) |
| **SI18-b** | *(não se aplica)* | o componente **não carrega texto**: não há par de contraste a medir | exigir piso de contraste aqui reprovaria desenho correto |
| **SI18-c** | **sem** o atributo, o ponto ainda **pinta** — marca profunda, nunca transparente | ponto que some quando o produto escreve fora da faixa é a divergência 2 | padrão transparente (é o defeito) |
| **SI18-d** | geometria **12×12px, raio 2px, SEM glifo** | sem ela, "unificar" seria só a cor. A cláusula reprova **também** a presença de glifo: é o que separa este componente do §65.7 | raio literal de 3px (divergência 3); prender ao ancestral (divergência 4) |

```css
.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:**

| tela | mudança | pixels |
|---|---|---|
| `tela-lista` | o ponto da posição 4 **passa a pintar** (era transparente) | **144** por tema — exatamente 12×12 |
| `tela-referencia` | raio 3px → 2px em 3 pontos | **60** por tema |
| `chat`, `detalhe`, `gantt`, `quadro`, `tabela` | `style` em linha → `data-ident`; mesma cor computada | **0** |

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

| # | Cláusula | Por que ela existe |
|---|---|---|
| **SI17-e** | O `.sigla` da barra superior identifica a **EMPRESA LOGADA**, não uma entidade de conteúdo. **Cada empresa tem uma POSIÇÃO DE COR própria e exclusiva; o GLIFO é o MESMO para todas.** | Decisão literal do Rafael: *"quando mudamos para SEED energia a cor deve mudar, o glifo pode ser o mesmo"*. O glifo constante diz "isto é o seletor de empresa"; a cor diz **qual** empresa. O **SI1** continua satisfeito: o par existe, e é ele que muda — o que não muda é o **papel** do glifo |

**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 —

| posição | distância de luminância até a 4 | veredito |
|---|---|---|
| **3** — azul vivo | **3,80** | ✅ **escolhida** — a maior distância; sobrevive à escala de cinza |
| 2 — dourado | 3,59 | descartada: o dourado encosta na **regra do ouro** da marca, e havia alternativa melhor **por número** |
| 1 — turquesa vivo | 3,45 | descartada: **mesma família** da marca; leria como "a mesma empresa em outro estado" |
| 5 | 1,46 | descartada: a **1,4** as duas empresas ficam **indistinguíveis em escala de cinza** |
| 6 | 1,40 | idem |

*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:

| telas | ident | fundo | rótulo |
|---|---|---|---|
| `shell`, `lista`, `tabela`, `chat`, `referencia` | **4** | `rgb(0, 80, 72)` | **SEED engenharia** |
| `detalhe`, `gantt`, `quadro` | **3** | `rgb(1, 179, 224)` | **SEED energia** |

*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

| # | Cláusula | Por que ela existe | Alternativa descartada |
|---|---|---|---|
| **SI19** | **A FORMA separa antes da cor: pessoa é CÍRCULO, organização é QUADRADO** de raio 6px | É o canal que sobrevive à escala de cinza, ao olho de longe e ao daltonismo. A distinção de forma é anterior a este componente (§62) — aqui ela vira contrato escrito e medido | separar por cor: reprovada pelo próprio SI12 (dois canais, nunca só cor) |
| **SI20** | **Foto e logo SUBSTITUEM o fundo — nunca se sobrepõem à cor de entidade.** Com imagem, o fundo vira superfície neutra com **fio de 1px** | Contraste de **imagem de terceiro** sobre **cor nossa** é impossível de provar; o que não se prova não entra. Superfície neutra com fio **é** medível, e o fio impede uma logo clara de sumir no tema claro | deixar a cor de entidade atrás da imagem: cria um par não mensurável em cada cliente novo |

**A matriz completa dos quatro estados** está desenhada e provada em `banco-identidade.html`, seção
*"Pessoa é círculo, empresa é quadrado"*:

| | sem imagem | com imagem |
|---|---|---|
| **pessoa** (círculo) | **INICIAIS** derivadas do nome (SI15) | a **FOTO**, substituindo fundo e iniciais |
| **empresa** (quadrado) | **GLIFO** padrão + posição de cor | a **LOGO**, substituindo fundo e glifo |

> *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):

| ponto | tema claro | tema escuro | como TEXTO (piso 4,50) | como FORMA (piso 3,00) |
|---|---|---|---|---|
| ok · turquesa | 4,60 | **3,31** | ❌ escuro reprova | ✅ passa |
| atenção · rosa | **4,08** | 7,47 | ❌ claro reprova | ✅ passa |
| crítica · vermelho | 5,19 | 5,52 | ✅ passa | ✅ passa |

**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):**

| Instrumento | Antes | Depois |
|---|---|---|
| `gen-banco-identidade.py`, 2 gerações | MD5 `294885fa94a9305fab8cf4c82fbc185f` (= committado) | MD5 `a2f5a8591e070c69069c8e2d84839c74`, idêntico nas duas |
| `suite-identidade.mjs` | 32 PASS · 0 FAIL · 0 [n/a] · 1 medida | **32 · 0 · 0 · 1** (mesma contagem; mudam de valor medido SI6 “30 glifos”, SI5-grade “6 colunas”, SI13 “36 opções”, SI-OP3, SI-OP3b, SI-OP4, SI8-filtro “de 30”, SI9 “devolve os 30”, e as 4 derivadas do SI15) |
| `suite-icones.mjs` | 25 · 0 | 25 · 0 |
| `guarda-barra-provas.mjs` | 9 · 0 · 15 [n/a] · 24 alvos | 9 · 0 · 15 · 24 |
| `paridade-previews.py` | 825 · 0 (209 medidos · 15 isentos) | 825 · 0 (209 · 15) |
| medição no DOM (Chrome, 1200 px) | 28 células, 4 linhas, 7 na primeira | **30 células, 5 linhas, 6 na primeira, 0 vazias, 0 cortadas, todas 44 × 44** |

**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):**

| Instrumento | Antes | Depois |
|---|---|---|
| `gen-banco-identidade.py`, 2 gerações | MD5 `a2f5a8591e070c69069c8e2d84839c74` (v0.3) | MD5 `26023b0632d65e7e21b974e839e2617c` (v0.4), idêntico nas duas |
| `suite-identidade.mjs` | 32 PASS · 0 FAIL · 0 [n/a] · 1 medida | **33 · 0 · 0 · 1** (nasce **SI-OP3c**; mudam de valor medido SI6 “31 glifos”, SI13 “37 opções”, SI8-filtro “de 31”, SI9 “devolve os 31”; SI-OP3, SI-OP6 e SI15 inalterados) |
| `suite-icones.mjs` (só leitura) | 25 · 0 | 25 · 0 |
| `guarda-barra-provas.mjs` | 9 · 0 · 15 [n/a] · 24 alvos | 9 · 0 · 15 · 24 |
| `paridade-previews.py` | 825 · 0 (209 medidos · 15 isentos) | 825 · 0 (209 · 15) |
| medição no DOM (Chrome determinista, 1200 px, dois temas) | 30 células, 5 linhas de 6 | **31 células 44 × 44, 6 linhas (6·6·6·6·6·1), 0 cortadas, 0 glifos cortados**; ↓ de `location`, `people`, `phone`, `calendar`, `document` (penúltima linha, colunas 2–6) **fica**; `email` ↓ `growth`; `growth` ↑ `email`; ↑ na primeira linha fica nas 6 colunas |

**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.

