TEST: exercitar o design-diff - #2
Conversation
Throwaway branch. Two changes with a known expected output: - radius-nav 10 -> 12, which the token layer should catch - Chip padding $space-3 -> $space-4, which touches no token and no component name, so only the structural layer should catch it Not for merge.
Design vs
|
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| "radius-nav": { | ||
| "type": "number", | ||
| "value": 10 | ||
| "value": 12 |
There was a problem hiding this comment.
Regra 7 / §13 — a transcrição deste token ficou para trás
radius-nav passa de 10 para 12 aqui, mas app/globals.css:154 continua com o valor antigo:
/* único radius fora da escala nativa do Tailwind (§6) */
--radius-nav: 10px;O §13 trata a transcrição como parte da mudança de design, não um passo separado — "Se mudou token, transcreva para app/globals.css" — e o §1 define quem manda: "O .pen é sempre quem vence — se o CSS discorda dele, o CSS está errado."
O token é consumido pelo Sidebar Item (cornerRadius: "$radius-nav", confirmado em components.json), então enquanto o CSS não acompanhar, todo item da sidebar renderiza com 2px de raio a menos do que o design pede. Como app/globals.css não está no diff deste PR, não dá para deixar a sugestão na linha certa; a correção é trocar a linha 154 por --radius-nav: 12px;.
Dois acompanhamentos, já que não cabem em linha nenhuma do diff:
- Com
radius-navem 12 ele passa a empatar com$radius-md. A tabela do §6 doDESIGN-SYSTEM.mdainda lista| $radius-nav | 10 |e precisa ser atualizada — ou orounded-navdeixa de se justificar e virarounded-xl. - A outra mudança deste PR (padding do
Chip,$space-3→$space-4) não gera drift hoje: não existecomponents/chip.tsxno repo, nem diretóriocomponents/. Quando o Chip for implementado, o §4 pedepx-4(16px) — nãopx-3.
Testing the diff workflow exposed a hole in the audit next to it. On a PR that only moves the design, the code diff is empty, so the scan reported "no code files" and stopped — leaving the agent to work out on its own which components had shifted. It found the token that changed, because a variable is easy to spot, and missed the Chip, whose padding had moved from $space-3 to $space-4 while components/chip.tsx still said px-3. That is the case that escapes review hardest: nothing in app/ or components/ shows up in the PR to draw the eye, and the code is stale from the moment the design lands. The scan now diffs the .pen against the base whenever it changed and reports two lists: the tokens that moved, with enough context to name them, and the components whose structure moved. The agent gets "check Chip" instead of having to derive it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Design vs
|
Design vs
|
| "radius-nav": { | ||
| "type": "number", | ||
| "value": 10 | ||
| "value": 12 |
There was a problem hiding this comment.
Drift: token mudou no .pen, transcrição no CSS ficou para trás (§13, §6)
$radius-nav passou de 10 para 12 aqui, mas app/globals.css:154 continua:
/* único radius fora da escala nativa do Tailwind (§6) */
--radius-nav: 10px;O §13 ("Quando o design mudar") coloca a transcrição dentro da mesma tarefa: "Se mudou token, transcreva para app/globals.css" — e o §1 fecha a questão: "o .pen é sempre quem vence — se o CSS discorda dele, o CSS está errado."
Como rounded-nav é declarado no @theme a partir desse valor (§6), o erro não aparece em lugar nenhum: compila, renderiza, e fica 2px errado em todo consumidor futuro.
Correção — em app/globals.css:154:
--radius-nav: 12px;(Não dá para deixar o comentário na linha exata: app/globals.css não faz parte do diff deste PR.)
O outro trecho do diff — Chip, padding de $space-3 → $space-4 (12px → 16px) — não tem drift correspondente: não existe components/chip.tsx, nem componente algum ainda (app/ tem só o scaffold do create-next-app). Quando o Chip for implementado, o padding é px-4, não px-3.
Design vs
|
| "radius-nav": { | ||
| "type": "number", | ||
| "value": 10 | ||
| "value": 12 |
There was a problem hiding this comment.
Regra 10 (drift) — token defasado: app/globals.css:154
$radius-nav passou de 10 para 12 aqui, mas a transcrição em CSS continua com o valor antigo:
/* app/globals.css:154 */
--radius-nav: 10px; /* ← deveria ser 12px */O §13 ("Quando o design mudar", passo 2) diz que transcrever o token para app/globals.css é parte da mesma tarefa, não um passo separado — e o §1 fecha: "o .pen é sempre quem vence — se o CSS discorda dele, o CSS está errado". Como --radius-nav é exposto via @theme como rounded-nav (§6), todo consumidor futuro do utilitário nasce com 10px.
Correção em app/globals.css:154:
--radius-nav: 12px;Nota de acompanhamento (não bloqueante): com esse valor, $radius-nav fica idêntico a $radius-md (12), e a tabela do §6 do design/DESIGN-SYSTEM.md ainda lista $radius-nav | 10 — vale atualizar a linha junto para a tabela não continuar autorizando o valor errado.
Design vs
|
| "radius-nav": { | ||
| "type": "number", | ||
| "value": 10 | ||
| "value": 12 |
There was a problem hiding this comment.
Regra 10 (drift) — token mudou no .pen e a transcrição em CSS ficou defasada.
$radius-nav passou de 10 para 12 aqui, mas app/globals.css:154 ainda declara o valor antigo:
/* único radius fora da escala nativa do Tailwind (§6) */
--radius-nav: 10px;O .pen é sempre quem vence — se o CSS discorda dele, o CSS está errado (§13). E a transcrição dos tokens é parte da mesma tarefa, não um passo separado (§1). radius-nav é o único radius fora da escala nativa do Tailwind, então ele existe só como token declarado à mão: nada mais no build corrige essa divergência, e rounded-nav continua renderizando 10px em silêncio.
Correção em app/globals.css:154:
--radius-nav: 12px;$radius-nav passa a valer o mesmo que $radius-md. Isso não autoriza trocar rounded-nav por rounded-xl no JSX — são tokens distintos no .pen (§6), e colapsá-los quebra o rastreio quando um dos dois mudar de novo.
| "radius-nav": { | ||
| "type": "number", | ||
| "value": 10 | ||
| "value": 12 |
There was a problem hiding this comment.
Drift: transcrição do token ficou para trás (regra 10 — componente/valor que diverge do design)
$radius-nav passou de 10 para 12 aqui, mas app/globals.css:154 continua com o valor antigo:
/* app/globals.css:154 */
--radius-nav: 10px; /* .pen agora diz 12 */O §13 é explícito sobre a ordem: o .pen muda primeiro e "se mudou token, transcreva para app/globals.css" — a transcrição é parte da tarefa, não um passo separado. E o §1 fecha a questão sobre quem vence: "o .pen é sempre quem vence — se o CSS discorda dele, o CSS está errado."
Correção em app/globals.css:154:
/* único radius fora da escala nativa do Tailwind (§6) */
--radius-nav: 12px;Por que escapa em review: --radius-nav é o único radius que o §6 manda declarar à mão no @theme, e rounded-nav continua compilando com o valor velho — nada quebra, o Sidebar Item (components.json:1307, cornerRadius: "$radius-nav") só renderiza 2px mais quadrado do que o design. Confirmado contra tokens.json:290-293 ("radius-nav": 12).
radius-nav = 12 o valor agora coincide com $radius-md (12), mas os dois tokens seguem distintos no .pen — mantenha rounded-nav no Sidebar Item em vez de trocar por rounded-xl, senão a próxima divergência entre eles volta a passar batido.
Design vs
|
|
Branch de teste, cumpriu o papel: exercitou as três camadas do design-diff e expôs três defeitos reais no drift. Não vai para merge — ele altera o design de propósito. |
1 participant
Branch descartável. Duas mudanças no
.pencom gabarito conhecido:radius-nav10 → 12 — deve aparecer na camada TokensChip$space-3→$space-4— não mexe em token nem em nome de componente, então só a camada Estrutura deve pegarEsperado: Inventário sem mudança, e os renders do artefato com o Chip mais largo.
Não é para merge.