A régua de arquitetura da casa

Instrumento de leitura de arquitetura, escrito em 01/10/2026 a pedido do founder. Quem usa isto é um agente que não leu a conversa onde a régua foi encomendada. Tudo que você precisa para dar uma nota está neste arquivo.

O que esta régua é, e o que ela não é

Esta régua mede. Ela não proíbe.

A distinção é a razão de ela existir. O founder quer arquitetura que deixe os agentes trabalharem por intuição, "sem que eles precisem seguir regras rígidas" — e a aposta é que uma metáfora física central faz isso melhor que qualquer lista de proibições, porque um agente que entendeu que o projeto é uma oficina acerta sozinho onde colocar a peça nova. Regra manda; metáfora ensina. Uma régua que virasse lista de proibições destruiria justamente o que ela foi feita para medir.

Há prova de campo disso, e ela é o achado mais forte de todo o levantamento que precedeu esta régua: o repositório da casa que escreveu a lei da linguagem ubíqua é o que mais a viola, e o que melhor a cumpre nunca escreveu lei nenhuma.

• ~/ved/clag/CLAUDE.md:214-221 legisla: "O vocabulário que o produto fala é o vocabulário da arquitetura. […] Um domínio que o produto nomeia e a arquitetura não representa é dívida conceitual." Há até um dicionário com nomes proibidos (clag/docs-conceitos/VOCABULARIO.md). E é nesse mesmo repositório que vivem as cinco únicas classes Manager/Controller da família inteira — clag/public/src/clag/node-manager.js:28, clag/public/src/clag/node-loop-manager.js:31, clag/bin/clag-executor.js:1256. O VOCABULARIO.md:34 define "loop de nó" como conceito da casa, e o código que o implementa se chama NodeLoopManager.
• ~/ved/clag-player não tem lei de vocabulário. Tem um JSON Schema executável de 2312 linhas (site/formato/v1/esquema.json) que se declara a fonte — "Este esquema é a FONTE: docs/FORMATO.md é derivado dele, e o validador recusa o que ele não descreve" (esquema.json:4) — e um validador que roda (site/formato/v1/validador.js). O resultado é um diretório inteiro de ofício: palco.js, cortina.js, bastidores.js, ensaio.js, veu.js, mira.js, marcas.js, agulha, elenco, ceu.js.

A conclusão que atravessa a régua inteira: lei sem gate é intenção; estrutura que recusa o errado é arquitetura. Quando você for pontuar, dê peso ao que é executável — um validador, um teste de fronteira, um schema que reprova — e desconte o que é só declaração. Está escrito nos critérios 4 e 10, e é a razão de a régua medir em vez de mandar.

Consequência prática para quem avaliar: nota baixa é um achado, não uma acusação. Um projeto que tirou 1 em desenhabilidade está dizendo que ninguém consegue desenhá-lo, o que é informação acionável sobre o futuro dele. E o contrário também vale: não invente nota alta para ser gentil, porque régua que não distingue não decide nada.

A tese que organiza os critérios

Os dez pontos que o founder nomeou não são dez coisas independentes. São uma cadeia causal, e foi assim que agrupei:

         ┌──────────────────────────────────────────────────────────────┐
         │  A. A METÁFORA     existe? é física? é uma só?                │
         └───────────────────────────┬──────────────────────────────────┘
                                     │ se não existe, nada abaixo pontua alto
         ┌───────────────────────────▼──────────────────────────────────┐
         │  B. O ALCANCE      chega na pasta, no arquivo, na classe,     │
         │                    no dado, na conversa?                      │
         └───────────────────────────┬──────────────────────────────────┘
                                     │
         ┌───────────────────────────▼──────────────────────────────────┐
         │  C. A FORMA        as peças são peças? separadas? inteiras?   │
         └───────────────────────────┬──────────────────────────────────┘
                                     │
         ┌───────────────────────────▼──────────────────────────────────┐
         │  D. A PROVA        dá para desenhar? o desenho se contradiz?  │
         └──────────────────────────────────────────────────────────────┘

A ordem importa ao pontuar: a camada D verifica as camadas A–C. Um projeto que tira 3 em metáfora e 3 em alcance mas que ninguém consegue desenhar tem inconsistência na própria avaliação — volte e reveja as notas de cima, porque provavelmente a metáfora é bonita no README e não está no código.

O que eu juntei, separei e acrescentei está no fim do arquivo, com o motivo de cada caso.

Como pontuar, em geral

Toda escala é 0 a 3, com o mesmo significado de degrau em todos os critérios:

Três regras que fazem duas varreduras diferentes convergirem na mesma nota:

1. Nota sem evidência arquivo:linha não vale. Se você não consegue citar onde viu, a nota é a de baixo. Isso elimina a maior fonte de divergência entre avaliadores, que é pontuar pela impressão geral do README.
2. Conte, não impressione. Vários critérios pedem contagem (quantas pastas de primeiro nível carregam nome físico, quantos nomes o mesmo conceito tem, quantos arquivos com nome de abstração). Faça a contagem e escreva o número. Dois avaliadores que contam chegam ao mesmo lugar; dois que sentem, não.
3. Gate vale mais que declaração. Quando o projeto afirma um princípio e também o prova com algo executável (validador, teste de fronteira, schema que recusa), isso sustenta nota 3. Quando só afirma, o teto é 1 — mesmo que a afirmação seja eloquente. A régua inteira depende dessa distinção, pelo motivo exposto na abertura.

O medidor de cinco segundos

Rode isto na raiz do projeto, antes de pontuar qualquer coisa:

find . -path ./node_modules -prune -o -type f \
  -iregex '.*\(manager\|service\|handler\|util\|helper\|processor\|controller\|factory\|provider\|adapter\|wrapper\|engine\).*' -print

E a versão por identificador, que pega o que o nome de arquivo esconde:

grep -roE '\b(function|const|let|class)\s+\w*(Manager|Service|Handler|Util|Helper|Processor|Controller|Factory|Provider|Adapter|Wrapper)\w*' src/ 2>/dev/null

Escreva os dois números no relatório, separando código do projeto de dependência de terceiro. Não é veredito — projeto grande tem borda legítima, e pipeline importado de node:stream/promises não é escolha de ninguém. Mas é o dado mais objetivo desta régua, e remove quase toda a divergência entre avaliadores.

Calibre pelos números reais da casa, que são o parâmetro dos degraus:

Camada A — A metáfora

Critério 1 — Metáfora central

O que pergunta: existe uma imagem única que explica o funcionamento da obra inteira, e não só de um pedaço dela?

Onde olhar:

• README.md, docs/ e o CLAUDE.md do projeto — se a metáfora está declarada, está ali.
• A lista de pastas de primeiro nível (ls -d */). É o teste mais rápido que existe: as pastas de um projeto com metáfora central lidas em sequência contam uma história; as de um projeto sem ela listam categorias técnicas.

Que evidência conta: a frase onde a metáfora está dita (arquivo:linha), mais a lista de pastas como prova de que ela não é só frase.

Um caso que vale conhecer antes de pontuar: a metáfora pode ser real e nunca declarada. Em ~/ved/asset-pipeline-dashboard não existe nenhum documento que diga "a metáfora é X" — não há docs/metafora.md, e buscar por "metáfora" ou "vocabulário" no README só devolve usos técnicos. Mesmo assim o vocabulário físico é dos mais consistentes da casa (acervo, oficina, esteira, porta, estante, lixeira, bancada, corredor, galeria, ficha, peça, osso, corpo, encaixe, céu). A frase mais próxima de uma declaração é um título: docs/editores.md:1 — "# Editores — o acervo guarda, quem edita mora fora".

Como pontuar esse caso: a metáfora operante conta, mesmo sem declaração — nota alta é legítima, porque os agentes que trabalham ali de fato herdam a intuição. Mas o relatório deve dizer que ela é inferível e não enunciada, e "escrever a frase" costuma ser a ação de 1 hora mais barata do relatório inteiro. O que não conta é a metáfora que só existe na sua cabeça de avaliador: se você precisou inventá-la para escrever o relatório, a nota é 0 ou 1 e o relatório diz isso.

Como é o bom. ~/ved/video-mocap — a obra inteira é uma esteira de leitura do corpo humano: entra um vídeo por uma porta, passa por estações que leem partes do corpo, cada quadro recebe um juízo, o que estava torto é reparado, e sai um pacote de humano pela entrega. O README.md:46-50 desenha o percurso em uma linha, e cada estágio dessa linha é uma pasta de verdade:

vídeo  →  quadros  →  pose por quadro  →  juízo  →  reparo  →  animação  →  pacote  →  acervo
          └ captura/ ──────────────────┘  └ juizo/ ────────┘   └ animacao/ ┘ └ pacote/ ┘ └ acervo/

Como é o ruim. Um projeto cujas pastas de primeiro nível são api/, services/, utils/, models/, helpers/, config/. Essa lista é a mesma em qualquer projeto do mundo — descreve a tecnologia, não a obra. Lida em sequência não conta história nenhuma, e é por isso que um agente que cai nesse repositório não tem intuição de onde pôr a peça nova: toda peça caberia em services/.

O caso intermediário mais instrutivo da casa é ~/ved/clag: public/src/palco/ e public/src/gesto/ são metáfora pura, tools/ e providers/ são abstração, e a raiz de public/src/ é um despejo de cerca de 90 arquivos bilíngues sem subdivisão — cinto-do-editor.js ao lado de mode-controller.js, mira.js ao lado de persist.js, marcas-na-tela.js ao lado de inspector.js. Há ainda sete pastas docs-* no mesmo nível e um deletion-vault/ com código morto versionado. Esse é o retrato do degrau 2 descendo para 1.

Escala:

Critério 2 — Fisicalidade da metáfora

O que pergunta: a metáfora é um objeto do mundo, que se pode pegar na mão, ou é um conceito abstrato vestido de metáfora?

Este é o critério que o founder tratou como central, e tem razão: a fisicalidade é o que torna a metáfora comunicável sem explicação. Um humano e uma IA que ouvem "osso", "bancada", "esteira" constroem a mesma imagem. Já "gerenciador", "fluxo", "contexto" cada um preenche com o que quiser — e a conversa segue parecendo alinhada quando não está.

O teste: o nome tem massa, forma e lugar? Posso apontar para ele numa fotografia?

Dois casos que enganam:

• Abstração com nome bonito. "Orquestrador", "maestro", "regente" parecem concretos mas são o mesmo manager — descrevem função de coordenação, não objeto. Um maestro é uma pessoa, não uma peça da obra. Se o nome descreve quem manda em vez de o que é, é abstração.
• Físico de verdade, mas de outra obra. Um projeto financeiro cujas peças se chamam "osso" e "esqueleto" tem fisicalidade sem pertinência. Nota alta exige que o objeto físico seja o objeto daquele trabalho.

Como é o bom. Duas evidências, de projetos diferentes:

~/ved/video-mocap levou a fisicalidade até o nome de arquivo: porta/armazem.mjs, porta/esteira.mjs, entrega/boneco.mjs, limpeza/chao.mjs, teto/ancorar.py, maos/armadilha.mjs, maos/territorio.mjs, limpeza/faxina.mjs. E até o vocabulário de domínio: o punho que o detector não acha vira âncora (README.md:77-79), e as validações que barram leitura ruim são portões (README.md:87-93). O entrega/README.md:38 nomeia o rosto em peças — "lábios, pálpebras, pupilas, sobrancelhas, queixo".

~/ved/asset-pipeline-dashboard declara o objeto físico na primeira linha útil de cada módulo, o que faz o repositório se explicar sozinho:

• src/esteira.js:1 — // A ESTEIRA — o corpo entra uma vez, sai no leque de orcamentos.
• src/oficina.js:1 — // A OFICINA — o que um corpo custa pra quem vai desenha-lo
• src/routes/porta.js:2 — // A PORTA — subir um corpo com UMA chamada
• src/corpo-canonico.js:2 — // O CORPO CANONICO — quem veste as capturas de movimento.
• src/galeria-publica.js:2 — // A GALERIA — o que uma PESSOA ve quando abre o endereco
• test/corredor.js:3 — // O CORREDOR — roda TODAS as provas de texto numa linha

Como é o ruim. Três formas, em ordem de gravidade:

1. A metáfora que nunca chegou a uma região. ~/ved/video-mocap/x/ reúne diagnósticos (x/diag-74.mjs, x/diag-cadeia.mjs, x/diag-camera.mjs). x não é objeto nem gesto — é gaveta. trabalho/ e miolo/ estão no mesmo caso. Calibração honesta: até o melhor exemplo da casa tem pontos onde a metáfora não chegou, e é isso que separa 3 de perfeição inexistente.
2. O nome do projeto contra o próprio conteúdo. ~/ved/asset-pipeline-dashboard serve assets.did.lu, é chamado "o acervo" por todos que o consomem (ez3d/src/acervo.js, video-mocap/acervo/leitor.mjs), e o miolo fala corpo, peça, oficina, bancada, lixeira. O nome do repositório é o único artefato que ainda diz "pipeline dashboard" — duas abstrações empilhadas sobre um interior inteiramente físico.
3. O healthcheck que esquece o nome da casa. No mesmo projeto, server.js:271 responde { status: 'ok', service: 'assets' } — a borda chama de service o que o repositório chama de acervo. Vale como exemplo porque mostra onde a erosão começa: na superfície que ninguém lê como parte da obra.

Escala:

Camada B — O alcance

Critério 3 — Alcance da metáfora na estrutura

O que pergunta: até onde a metáfora desce? Chega na pasta, no arquivo, na classe, no nome da coluna do banco, na rota da API?

Este é o critério que o founder formulou com mais precisão: "o quão longe vai essa metáfora, se ela realmente se configura em classes, objetos, módulos, pastas". Metáfora que para no README é marketing interno; metáfora que chega no schema do banco é arquitetura.

Os cinco degraus de profundidade. Avalie cada um e escreva quais alcançou:

1. Documentação — README, docs.
2. Comentário — a palavra aparece explicando o código, mas não batiza nada.
3. Pastas e arquivos — os nomes no disco.
4. Código — nomes de classe, função, tipo, variável de domínio.
5. Dado e borda — nome de tabela, coluna, campo de JSON, rota HTTP, evento, MIME type.

O degrau 5 é o que mais separa projeto com arquitetura de projeto com boa documentação. É também o mais caro de mudar depois, porque dado publicado tem consumidor — razão pela qual pesa mais na nota.

O par calibrador da casa — mesmo projeto, mesma época, destinos opostos. Em ~/ved/asset-pipeline-dashboard, dois conceitos igualmente centrais e igualmente físicos:

O próprio projeto sabe: test/integracao-estante.js:5-7 — "A estante é a tela que mostra os PROJETOS como projetos […] Ela não tem porta própria: lê a mesma listagem que todo editor lê." Use esse par para calibrar: mesma casa, mesmo autor, mesmo tipo de conceito — um foi até o banco, o outro parou na tela. É a diferença entre degrau 5 e degrau 3 sem nenhuma subjetividade.

E o degrau 2, que é uma armadilha: no mesmo projeto, "balde" é a palavra física para bucket e aparece em public/app.js:3621 e docs/editores.md:290 — mas no código é bucket (src/gcs.js). Palavra que só vive em comentário não conta como alcance; conta como intenção.

Como é o bom. ~/ved/asset-pipeline-dashboard chega ao degrau 5 em várias frentes: rota pública GET /api/esteiras (server.js:297); /estante, /lixeira, /varredura como rotas de front (server.js:392); MIME type próprio application/vnd.did.acervo.arvore+json (docs/tipos-da-casa.md:241); categoria de banco 'peca-de-humano' (migrations/026_peca_de_humano.sql:127); migrações que nomeiam o conceito (022_ceu_como_categoria.sql, 025_humano_como_categoria.sql). No ~/ved/video-mocap, o desfecho de cada quadro é vocabulário do projeto e não do framework: BOM / REPARADO / LACUNA (README.md:30-34).

Como é o ruim. O caso típico: o README fala em "oficina" e "bancada", e o código tem src/services/WorkbenchService.ts, src/models/WorkbenchEntity.ts, tabela workbench_items com coluna status_id. A metáfora chegou ao degrau 1, virou substantivo no 3 e morreu no 4–5, onde governa o vocabulário do framework. Um agente ali raciocina em Service e Entity, não em bancada.

Onde a metáfora costuma morrer, e isso é informação, não falha. Em ~/ved/asset-pipeline-dashboard ela domina o domínio e evapora na infraestrutura: src/db.js, src/gcs.js, src/auth.js, src/validate.js, src/catalog.js são inglês técnico, e as nove tabelas mais antigas também (assets, asset_parts, collections, projects…), enquanto as três de outubro/2026 são português (editores, chaves_de_edicao, devolucoes_de_editor). O projeto virou de vocabulário no meio da vida, e as duas eras coexistem. Em ~/ved/almost-humanoid o corte é diferente e mais revelador: a camada que atravessa fronteira é física (src/rig/canonical-bones.js, src/envelope/pecas.js, packages/player/src/ragdoll.js, stride.js) e a camada interna é genérica (src/storage/, src/ui/, src/app/, src/import/animation-pipeline.js, src/authoring/effector-manager.js:113). Ou seja: o contrato é físico, o maquinário é abstrato — provavelmente deliberado, mas não declarado em nenhum doc. Dizer onde fica esse corte é parte do relatório.

Escala:

Critério 4 — Linguagem ubíqua

O que pergunta: o mesmo conceito tem um nome, em todo lugar — código, banco, documentação, tela, e a conversa entre dois projetos?

É o critério que o founder ligou diretamente ao trabalho com IA, e o mecanismo é concreto: cada sinônimo é uma tradução que todo leitor — humano ou agente — faz de cabeça, e toda tradução é chance de erro. Um projeto com três nomes para a mesma coisa gasta parte de cada conversa resolvendo qual é qual.

Onde olhar:

• Pegue os 5 a 8 conceitos centrais. Para cada um, procure todos os nomes (grep -ri) em código, schema/migrations, docs e rotas.
• Compare o nome na tela com o nome no código. Divergência de idioma tem desculpa (inglês no produto, PT-BR interno é doutrina da casa); o que conta como falha é dois nomes na mesma língua.
• git log dos nomes: renomeação parcial é a origem mais comum de sinônimo.
• Procure o gate. Existe teste, validador ou schema que recusa o nome errado? É o que separa nota 3 de nota 1, pelo motivo da abertura.

Que evidência conta: a tabela de sinônimos, com as ocorrências de cada lado (arquivo:linha). Escreva o número: "dos 7 conceitos centrais, 5 têm nome único".

Como é o bom. ~/ved/video-mocap combinou o vocabulário e o repetiu: "pacote de humano" é o nome da saída no README.md:3, na régua de pronto (docs/REGUA.md:19) e é a pasta pacote/. "Juízo" é o veredito, a pasta juizo/ e o conceito de domínio com três desfechos nomeados. Quem chega ali aprende o vocabulário uma vez e ele vale em todo lugar.

Como é o ruim — e aqui está o achado que mais importa. O exemplo mais caro da casa está documentado pelo próprio projeto que o sofreu. ~/ved/clag-cenas/test/em-dia-com-o-tocador.test.mjs:1-18:

"Em 24/09 uma auditoria descobriu que o manual desta mesa afirmava que o verbo som não existia. Ele existia havia semanas. […] A causa não foi o parágrafo. Foi que a mesa estava presa numa versão velha da ferramenta e NADA avisava. […] Duas semanas de gente escrevendo obra com meio vocabulário. Havia um agravante que escondeu a distância: A MESA E O TOCADOR CONTAM EM ESCALAS DIFERENTES. A mesa pina cena-v (a versão da PEÇA); o tocador pina v (a versão do REPOSITÓRIO inteiro). 'cena 0.19.0' e '0.390.0' parecem distantes um abismo e são, na verdade, vizinhos."

Duas semanas de trabalho humano com metade do vocabulário, por divergência de nomenclatura de versão. Esse projeto consertou com um gate (o teste citado). Os vizinhos não: clag-vista e pico-clag seguem pinados em clag-player#v0.46.0 contra v0.88.0 do clag-mostra — 42 versões de distância, sem gate equivalente. Ao avaliar qualquer projeto da família, verifique isso e diga o número.

Outros três sintomas que vale procurar explicitamente:

• O comentário em português explicando a coluna em inglês. Em ~/ved/asset-pipeline-dashboard/migrations/006_collections.sql:193-197, a tabela se chama asset_parts, a coluna se chama papel (português), e o comentário diz "Slug da peca dentro do asset" — três vocabulários em cinco linhas. O conceito central do projeto é "peça" na doc (docs/processos/montar-humano.md:45) e parts na rota pública (/projects/:p/assets/:a/parts/:slug).
• O mesmo nome para duas coisas. No mesmo projeto, "projeto" significa a pasta-balde e a obra, e o código sabe: public/app.js:3619-3627 documenta a ambiguidade em comentário em vez de resolvê-la. Pior: "corpo" é o arquivo 3D em src/routes/porta.js:2 e o request body em src/routes/porta.js:26 — mesmo arquivo, dois sentidos.
• O conceito com quatro dialetos atravessando projetos. O osso do mesmo esqueleto é leftUpperArm (VRM, almost-humanoid/src/rig/canonical-bones.js:1-16), LeftArm (Mixamo, video-mocap/formato/FORMATO.md §2), braco-direito (PT-BR kebab, almost-humanoid/docs/CCP-MANIFEST-1.5.md) e mixamorigHead (asset-pipeline-dashboard/src/corpo-canonico.js:16-18). Há duas traduções independentes entre o mesmo par (video-mocap/animacao/canonico.mjs e almost-humanoid/src/import/mixamo-adapter.js), carregando a mesma armadilha documentada em duplicata, e nenhum teste cruzado que compare os dois mapas.

Escala:

Camada C — A forma

Esta camada mede o que a engenharia clássica chama de modularidade, isolamento e coesão. A inflexão que o founder pede: aqui essas três coisas não são virtudes em si — são medidas de quão bem a metáfora foi executada. Um módulo é bom quando é uma peça: tem contorno, pode ser pego, pode ser trocado.

Critério 5 — Modularidade

O que pergunta: o projeto é feito de peças que se pode nomear, contar e trocar uma por uma?

Onde olhar:

• Fronteiras declaradas: package.json (workspaces), pyproject.toml, go.mod, ou a divisão de pastas quando não há ferramenta.
• O teste da troca: escolha a peça mais pesada (o motor, o detector, o renderizador) e conte quantos arquivos fora dela mudariam para substituí-la.
• Documentação que declare a intenção de troca é evidência forte — significa que alguém pensou no contorno antes.
• Troca que já aconteceu vale mais que qualquer declaração.

Como é o bom. ~/ved/video-mocap/README.md:44-46 declara o desenho e o motivo: "O pipeline é uma sequência de processos com entrada e saída em disco. Cada um é trocável sozinho: o dia em que um modelo melhor aparecer, troca-se a pasta, e nada mais muda." E o projeto exerceu: o motor de captura foi trocado (MediaPipe Holistic → SAM 3D Body) e a troca ficou contida em captura/ (README.md:62-66). Peça trocada sem o resto saber é a prova de que o contorno era real.

O mecanismo que torna isso possível merece nota: o estado é o disco, não um banco. ~/ved/video-mocap/esteira/contrato.mjs:19-33 — "A esteira não guarda 'a etapa 3 está feita' num banco. Ela olha se esqueleto.json existe. […] apagar um arquivo é como se pede pra refazer." Sobreviver a reinício sai de graça, e cada etapa é trocável porque a fronteira dela é um arquivo.

Como é o ruim. O módulo que só existe no diagrama: pastas separadas, mas import de cada uma para dentro das outras. Sintoma de detecção rápida: um utils/ ou core/ que todo mundo importa — não é módulo, é tecido conjuntivo, e cola as peças que o diagrama diz separadas.

O caso grave que a casa tem, e que vale procurar nos vizinhos: em ~/ved/clag existem três implementações independentes do mesmo flowgraph — public/src/work-mode-flowgraph.js + flowgraph-panel.js (browser), clag-addon-blender/flowgraph/ (Blender) e clag-vista/site/vendor/painel-do-fluxo/ (a peça da família). E duas implementações independentes de landmark → osso entre almost-mocap/public/lib/pose-rig.js:1-14 e almost-humanoid/src/mocap/landmark-to-effectors.js:1-25. Três respostas para o mesmo problema não é modularidade — é a ausência dela, vista de longe.

Escala:

Critério 6 — Isolamento

O que pergunta: o que acontece dentro de uma peça fica dentro dela? Quem usa precisa saber como ela funciona por dentro?

Onde olhar:

• O que cruza a fronteira: importar o contrato da vizinha é normal; importar o miolo é vazamento.
• Estado compartilhado: global, singleton, config que várias peças escrevem, tabela que duas atualizam.
• O teste do que o consumidor sabe: ele precisa conhecer qual modelo, biblioteca ou versão foi usada por dentro? Se sim, a implementação vazou para o contrato.
• Existe teste de fronteira? É o gate deste critério.

Como é o bom. ~/ved/video-mocap/README.md:38-42 enuncia o princípio e nomeia o mecanismo: "Este produto não importa, não chama e não mora dentro de nenhum outro. Ele segue três especificações escritas fora dele — o pacote de humano, o contrato do acervo, o contrato de job da farm — e nada mais. Quem consome o resultado não sabe como ele foi feito, e essa ignorância é a interface."

Essa última frase é o enunciado mais limpo de isolamento que existe na casa, e é a redação que eu usaria para calibrar o degrau 3: a ignorância do consumidor é a interface.

E não ficou na declaração — há três gates:

1. Teste que reprova import indevido. pacote/CONTRATO.md:26-28 — "nenhuma linha de código de lá é importada aqui. Há teste na suíte que reprova se algum módulo do produto importar qualquer coisa que não seja ele mesmo ou o Node" (test/modulos.mjs).
2. A prova de consumo escrita do outro lado da fronteira. acervo/leitor.mjs:14-20 — "Este leitor é escrito do outro lado da fronteira, de propósito. […] Ele não importa nada do resto deste repositório. […] Um escritor que se valida sozinho prova apenas que é coerente consigo mesmo."
3. O contrato mora em terceiro. A especificação do pacote não pertence a quem produz nem a quem consome: vive em ~/ved/almost-humanoid (docs/PACOTE-SCHEMA.md, citado em video-mocap/README.md:36-37). Isso remove a disputa por construção, em vez de resolvê-la por acordo.

Há um quarto padrão, e é o mais sofisticado da casa: o desacoplamento por cópia datada da spec alheia. video-mocap/pacote/CONTRATO.md:3-11 — "A especificação não é deste repositório: ela é do almost-humanoid. Este documento é a cópia datada do que foi lido, e existe por uma razão: sem ele, uma divergência futura entre o que a especificação diz e o que este produto escreve seria invisível — o código aqui continuaria 'certo' contra um contrato que mudou de lugar." O custo está declarado e hoje é real: a cópia foi lida contra a 1.4 e a spec já está em 1.5. Quem avaliar deve dizer o tamanho da defasagem — mas a nota é alta, porque o projeto construiu o lugar onde a divergência aparece.

Mesmo padrão no acervo, do outro lado: ~/ved/asset-pipeline-dashboard/docs/editores.md:8 — "O acervo não edita nada. Ele guarda, versiona e mostra."

Como é o ruim. O crédito na tela escrito à mão no HTML. Se a página diz "lido por MediaPipe" em texto fixo, a tela sabe por dentro quem leu — e no dia em que o motor trocar, a tela mente. ~/ved/video-mocap/docs/REGUA.md:27 trata isso como linha de régua: o crédito tem de vir do procedencia.json, "nunca de texto fixo no HTML".

E o vazamento mais sutil, que vale caçar: referência a doc de um repositório que o projeto não lê, carregada dentro do vendor. O CLAGFILE-SCHEMA.md do repo clag é citado por clag-player/site/vendor/roteirista/index.js:14, clag-vista/site/vendor/painel-do-fluxo/src/documento.js:231 e pico-clag/site/vendor/estante/clag.js:15. Três projetos carregam a referência a um contrato que vive num repositório do qual não dependem.

Escala:

Critério 7 — Coesão

O que pergunta: cada peça trata de um assunto, dizível em uma frase sem usar "e"?

Onde olhar:

• O teste da frase: escreva o que a pasta faz. Se precisa de "e" ligando dois assuntos distintos, a coesão caiu.
• Pastas-gaveta: utils/, helpers/, common/, misc/, core/, shared/, lib/, x/. Toda gaveta é um lugar onde alguém não soube a qual peça aquilo pertencia — e o custo não é o arquivo, é que a próxima pessoa também não vai saber.
• O inverso conta: o mesmo assunto espalhado em três pastas é falta de coesão na outra direção.
• Pasta com um único filho, ou pasta de despejo com dezenas de arquivos soltos sem subdivisão.

Como é o bom. As pastas de ~/ved/video-mocap que resistem ao teste da frase sem "e": maos/ são as mãos; rosto/ é o rosto; juizo/ é o veredito sobre cada quadro; limpeza/ é o conserto do que ficou torto; fila/ é a rodada da madrugada; porta/ é a entrada do celular para a fila. Cada uma é um assunto, dizível em meia linha, e cada uma tem o seu próprio .md. maos/ é o melhor caso, porque tem um problema próprio e não trivial — a mão ocupa 2% da altura do quadro e o detector falha por escala (README.md:74-76). A pasta existe porque o assunto existe, não porque o arquivo precisava de um lugar.

Sinal estrutural forte no mesmo projeto: test/ espelha as pastas 1:1 (test/esqueleto.mjs, test/rosto.mjs, test/maos.mjs, test/juizo.mjs, test/esteira.mjs, test/farm.mjs). Quando a suíte tem a forma da obra, a divisão não é decorativa.

Como é o ruim. No mesmo ~/ved/video-mocap: x/ é gaveta explícita de diagnósticos e o nome admite; trabalho/ tem um único filho (_corpo), o que sugere assunto não resolvido mais que peça. Nenhum dos dois derruba o projeto — e é essa a leitura correta: nota 3 não exige pureza, exige que as exceções sejam poucas e identificáveis.

O caso pesado está em ~/ved/clag: 23 arquivos .js na raiz do repositório, cerca de 90 arquivos soltos em public/src/ sem subdivisão, sete pastas docs- no mesmo nível (docs/, docs-cenarios/, docs-clagfull/, docs-conceitos/, docs-editor/, docs-marcos/, docs-pecas/) e um deletion-vault/ com código morto versionado. O projeto admite: CLAG-MAIN-PRINCIPLES-08-2026.md:5-7 — "A documentação do projeto é grande e ainda não está arrumada."*

Escala:

Critério 8 — Objetos a serviço da metáfora

O que pergunta: quando o projeto cria um objeto (classe, tipo, struct, módulo com estado), ele é uma coisa da metáfora — ou é um pacote de funções com nome de agente?

O founder pediu "arquitetura orientada a objetos para se conectar com a metáfora central", e a inflexão está no para. Não é OO como técnica nem como obrigação: é OO porque um objeto do mundo físico tem estado, comportamento e contorno, e a classe é o que mais se parece com isso no código. Projeto funcional não perde pontos aqui — o que perde pontos é criar objetos que não são coisas.

Onde olhar:

• Liste as classes/tipos centrais. Cada nome é um substantivo que existe no mundo da obra?
• Alarme: nome terminando em -er, -or, Manager, Service, Handler, Controller, Processor, Factory, Helper, Arbiter, Manipulator. Essas classes quase sempre têm método e nenhum estado — são funções agrupadas, e o nome descreve quem age em vez do que é.
• O inverso: a peça que é claramente uma coisa do mundo mas está implementada como funções soltas e um dicionário passado de mão em mão.

Como é o bom. ~/ved/video-mocap nomeia as coisas, não os agentes: entrega/boneco.mjs, porta/armazem.mjs, porta/esteira.mjs, leitura/esqueleto_mhr.py, teto/ancorar.py, maos/territorio.mjs. A ausência de um CaptureManager ou PoseProcessor num projeto deste tamanho não é acidente. Em ~/ved/clag-player/site/player/, a ordem de boot é escrita como sete passos de teatro e cada passo é um arquivo: palco.js:1 — "O PALCO — do documento lido à cortina aberta, na ordem certa, uma vez"; cortina.js:1 — "A CORTINA — o que a tela mostra enquanto a obra monta"; orgaos.js:1 — "OS ÓRGÃOS DECLARADOS — o que toda obra tem e nenhuma obra escreve diferente".

Como é o ruim. O trio que aparece junto: XManager, XService, XHelper para o mesmo conceito X. Três objetos, nenhum deles uma coisa, e a divisão entre eles não corresponde a nada do mundo — então ninguém sabe em qual pôr o método novo, e a resposta vira costume local em vez de intuição.

Casos reais, para calibrar: clag/public/src/clag/node-loop-manager.js:31 (NodeLoopManager, implementando um conceito que o VOCABULARIO.md:34 define como "loop de nó"); clag/bin/clag-executor.js:1256 (LiveSessionManager); almost-humanoid/src/authoring/effector-manager.js:113 (EffectorManager); almost-humanoid/packages/player/src/attachment-manager.js (AttachmentManager); almost3d/humanoid-sandbox/src/pose/bone-arbiter.js (arbiter — árbitro de osso é agente, não peça) e humanoid-manipulator.js.

Escala:

Camada D — A prova

As duas perguntas desta camada verificam as três camadas acima. Se falharem num projeto que pontuou alto em A–C, as notas de cima estão otimistas.

Critério 9 — Desenhabilidade

O que pergunta: um avaliador que leu o repositório consegue desenhar a arquitetura como objetos físicos ligados, sem inventar peça e sem deixar peça de fora?

O founder ligou desenhabilidade a metáfora, e a ligação é direta: só se desenha o que tem forma. Mas desenhabilidade é mais que consequência — é o teste mais duro dos outros critérios, porque desenhar obriga a decidir onde cada peça começa e termina, e é aí que a arquitetura que só funciona em prosa desmonta.

Como se observa — faça o desenho. Ele é parte obrigatória do relatório (seção 3). Ao desenhar, registre três tipos de atrito, que são os achados deste critério:

1. Peça sem corpo — algo que o código tem e que você não consegue desenhar como objeto, porque não é uma coisa (utils/, core/, providers/, Manager). Desenhe como caixa cinza sem forma e diga no relatório que não tem equivalente físico.
2. Ligação que não existe no mundo — duas peças ligadas no código por uma relação que não faz sentido entre os objetos correspondentes (a estante que chama o método do boneco).
3. Peça invisível — algo que o desenho precisa para fazer sentido e que não existe no código, porque hoje está implícito numa convenção de nome de arquivo ou num "sabe-se que".

Que isto fique explícito, porque muda a postura de quem avalia: onde o desenho não fecha, o achado é da arquitetura, não do desenhista. Não suavize o desenho para ele ficar bonito. Um desenho com três caixas cinzas e uma seta tortuosa é relatório melhor que um diagrama limpo que mentiu.

Como é o bom. Arquitetura que o próprio projeto já desenhou em texto e que se traduz diretamente em objetos: a esteira de ~/ved/video-mocap/README.md:46-50 tem estações em sequência, e README.md:145-157 mostra a fila local submetendo trabalho a um nó da farm — com as duas pontas e a ligação explícita. Desenhar isso (porta, esteira, estações, pacote, acervo) não exige inventar nada. A ordem de boot do clag-player é o mesmo caso em outro domínio: palco, cortina, bastidores, ensaio, quadro zero.

Como é o ruim. O projeto cujo desenho só pode ser a lista de pastas em caixas, ligadas por setas que significam "importa". Isso não é desenho de arquitetura, é grafo de dependência — e a diferença é que o grafo existe em qualquer projeto, inclusive nos que não têm arquitetura nenhuma.

Uma pista forte de que o desenho vai fechar: o projeto já tem diagrama em texto no README (ASCII, tabela de estágios) e cada caixa dele corresponde a uma pasta real. Quando essa correspondência existe, o desenho é transcrição. Quando não existe, você vai descobrir no desenho o que a leitura não mostrou — que é justamente o valor deste critério.

Escala:

Critério 10 — Ausência de contradições internas

O que pergunta: o projeto se contradiz — consigo mesmo ou com os vizinhos que ele toca?

Os cinco tipos de contradição, em ordem de quanto custam:

1. Dois donos do mesmo dado. Duas peças (ou dois repositórios) escrevem o mesmo formato e não há uma que manda. É a mais caras das cinco, porque divergem em silêncio.
2. Duas versões do mesmo contrato. O mesmo schema definido em dois lugares; o mesmo tipo declarado em dois repos; o mesmo campo em dois endereços.
3. Doc que contradiz código. O README descreve comportamento que o código não tem mais.
4. Metáfora que se contradiz. Duas imagens incompatíveis no mesmo projeto — parte oficina (bancada, peça, encaixe), parte escritório (protocolo, despacho). Nenhuma errada isolada; juntas, destroem a intuição que a metáfora deveria dar.
5. Vocabulário que se contradiz entre vizinhos. A mesma coisa com nome diferente nos dois lados de uma fronteira. Toda conversa entre as duas equipes (ou os dois agentes) paga esse pedágio.

Que evidência conta: as duas ocorrências, cada uma com arquivo:linha, e uma frase dizendo qual deveria ganhar. Contradição relatada sem os dois lados não é verificável e não entra.

Como é o bom. Resolver a contradição pela posse do contrato, como já descrito no critério 6: a spec do pacote de humano não mora em quem produz nem em quem consome. Ou declarar a dívida com regra de precedência explícita, que é a segunda melhor saída: ~/ved/almost-humanoid/src/envelope/pecas.js:69-85 — "ossos É ENDEREÇO LEGADO, e ele está nesta lista por NECESSIDADE medida. O campo nasceu aqui, em pecas.ossos, no acervo […] e está PUBLICADO assim no boneco de massinha. O 1.5 o move pro lugar certo (proporcao.ossos)" — com proporcao vencendo (docs/CCP-MANIFEST-1.5.md:379). Dois endereços vivos para o mesmo dado é contradição tipo 2; a diferença é que esta tem dono, motivo medido e precedência escrita. Nota 2, não 0.

Como é o ruim — o caso que o founder já nomeou, com a premissa corrigida. Ele disse: "hoje quando se fala em clag há o formato do arquivo clagproject e há o pico-clag". O terreno é pior que isso, e quem avaliar a jornada do clag precisa saber disto antes de começar: há três formatos vivos, e dois dividem a mesma extensão com schemas incompatíveis.

Dois arquivos com o mesmo sufixo e taxonomias incompatíveis: kind: "asset" de um lado é tipo: "corpo" do outro, spawn é entra, position é posicao (clag-player/docs/FORMATO.md:41). E o quarto formato foi declarado morto por um projeto enquanto outro continua escrevendo nele: clag-player/docs/FORMATO-ANTERIOR.md:5 diz "que já não se escreve", e clag-cenas/projetos/ofic/ofic.clag.json:2 escreveu nele em 25/09/2026. A mesa do diretor produz o formato que o tocador considera legado.

Mais contradições da mesma família, todas verificáveis:

• Dois editores do mesmo produto, zero código em comum. clag/public/src/ (desktop/web, ~90 arquivos, express+pg) e pico-clag/site/ (VR, vanilla ESM). Nenhum importa o outro, e o pico-clag declara a escolha: "Remontado em terreno livre" (README.md:3).
• Seis pinagens divergentes da mesma peça. clag-player em @did/interatividade#v0.431.0, clag-vista em #v0.423.0, pico-clag em #v0.418.0; e o repo clag — o que o founder chama de engine — não depende da família de peças de jeito nenhum.
• Fronteira testada num repo e inexistente nos outros. clag-cenas/test/fronteira.test.mjs:1-4 "reprova se esta pasta citar, importar ou ler qualquer peça do motor". Nenhum vizinho tem prova equivalente.
• Contrato que declara e executor que ignora. video-mocap/receita/video-mocap.json, campo _comment_platform: "platform ainda nao e lido por ninguem, entao esta declaracao nao muda o comportamento de hoje — ela para de MENTIR sobre o requisito." Custou "uma noite", segundo o próprio comentário.
• Duas moradas para a mesma procedência, com o risco escrito. video-mocap/pacote/CONTRATO.md §12: "A extensão privada deve esvaziar, não coexistir. O dia em que procedência estiver em meta e também na extensão é o dia em que as duas começam a divergir, e a divergência será silenciosa."
• Ilhas mortas sem estarem marcadas. ~/ved/almost-mocap (4 meses sem commit) e ~/ved/almost3d (nenhuma costura com a jornada) seguem vivos no disco sem APOSENTADO.md — enquanto video-mocap/fila/APOSENTADO.md mostra que a casa tem o gesto. E almost3d/humanoid-sandbox/ declara-se laboratório de outro repositório, com pose-pipeline.js duplicado em dois caminhos do mesmo projeto.
• Doc errada, código certo. video-mocap/entrega/README.md lista glb.mjs duas vezes com descrições diferentes; no disco são entrega/glb.mjs e entrega/prova/glb.mjs. Tipo 3, barato de consertar, e exemplo de achado que não deve inflar a gravidade.

Escala:

O formato do relatório

Cada varredura entrega um documento, com estas seções, nesta ordem, com estes títulos. A rigidez do formato existe por uma razão só: cinco relatórios com a mesma espinha podem ser lidos em paralelo e comparados critério a critério. Dentro de cada seção, escreva como se escreve nesta casa — raciocínio, não formulário.

1. A metáfora em uma frase

Abra com a metáfora central do projeto hoje:

<projeto> é <objeto ou lugar físico> onde <o que acontece, em meia linha>.

Se a metáfora é operante mas nunca foi declarada, diga isso — é o caso do acervo, e a frase que falta costuma ser a ação mais barata do relatório. Se não houver metáfora, a primeira linha diz sem rodeio ("<projeto> não tem metáfora central hoje: as peças são nomeadas por função técnica"). Não invente uma para preencher o campo — a ausência é o achado mais importante que o relatório pode trazer, e inventá-la esconde exatamente o que o founder quer ver.

2. Notas

Tabela única, dez linhas, na ordem dos critérios:

Mais: a soma (0–30), os dois números do medidor de cinco segundos, e uma linha dizendo qual camada puxou o resultado para baixo. A soma não é veredito sobre o projeto; é o que permite comparar cinco relatórios de manhã.

3. O desenho

Um diagrama em SVG ou HTML onde cada peça é um objeto do mundo e cada ligação é uma que existe no código. Não é fluxograma de caixas com nome de pasta: as caixas são coisas.

Regras que o tornam instrumento e não ilustração:

• Peça com equivalente físico: caixa com o nome do objeto.
• Peça sem equivalente físico: caixa cinza, e ela aparece na seção 4.
• Ligação: só as que existem no código (import, chamada, arquivo em disco, mensagem, registro em banco, chamada HTTP). Rotule com o que passa (o pacote, o quadro, a pose), não com "usa".
• Ligação que o desenho precisou mas o código não tem: linha tracejada, e também vira achado.

O desenho acompanha o relatório como arquivo e publicado (did-publish), porque é a peça que o founder vai olhar primeiro e caminho local não se abre no celular.

4. Onde o desenho não fechou

Os atritos dos três tipos do critério 9: peça sem corpo, ligação que não existe no mundo, peça invisível. Uma linha cada, com arquivo:linha. Esta seção costuma ser a mais valiosa do relatório inteiro — é onde a arquitetura confessa.

5. Contradições

Duas subseções: internas (dentro do projeto) e com os vizinhos (os outros projetos da jornada). Cada contradição com os dois lados (arquivo:linha cada), o tipo (1 a 5 do critério 10) e uma frase dizendo qual deveria ganhar. Sem os dois lados, não entra.

6. Ações propostas

De 3 a 7 ações. Mais que sete é lista de desejos, e ninguém executa. Cada uma:

Horas são estimativa de trabalho de agente, não de humano. Ordene por nota que move por hora gasta — a ação mais barata que move mais critério vem primeiro. Ação que não move nenhum critério desta régua não entra, por boa que seja: é assunto de outro tópico.

Dê preferência, quando empatar, à ação que constrói um gate em vez da que escreve uma regra. A abertura desta régua explica por quê: na casa, a lei sem gate não pegou, e o gate sem lei pegou.

7. O que eu não consegui avaliar

Lista curta e honesta: repositório não encontrado, código em máquina que não é esta, parte do sistema sem acesso, pasta compartilhada com trabalho de outra sessão em voo. Relatório que esconde o que não viu induz a decisão errada, e decisão errada é o custo real de uma varredura covarde.

O que eu juntei, separei e acrescentei

O founder nomeou dez pontos. Entreguei dez critérios, mas não são os mesmos dez — e as mudanças são consequência do raciocínio dele, não gosto meu.

Separei a metáfora em duas (1 e 2). Ele falou de "metáfora central" e de "fisicalidade" no mesmo movimento, mas são perguntas independentes, e um projeto pode passar numa e falhar na outra: existe metáfora central abstrata (um projeto todo organizado em torno de "fluxo"), e ela é pior que nenhuma, porque parece ter arquitetura. Juntas num critério, esse caso tiraria nota média e desapareceria. Separadas, aparece como 3 em metáfora e 0 em fisicalidade — o diagnóstico certo.

Separei o alcance (3) da linguagem ubíqua (4). Ele tratou a linguagem ubíqua como consequência da metáfora, e é. Mas as falhas têm naturezas diferentes: alcance é a metáfora não descer fundo; linguagem ubíqua é o mesmo conceito ter vários nomes no mesmo nível. Um projeto pode ter a metáfora chegando ao banco e ainda chamar a mesma coisa de três nomes — foi o que o levantamento achou no acervo, onde o conceito central é "peça" na doc, papel na coluna e parts na rota pública. Medir junto esconderia isso, que é o que mais atrapalha agente.

Desdobrei "modular, isolamento e coesão" em três (5, 6, 7) em vez de um bloco. Ele os citou como conjunto, e a tentação era fazer um critério "boa engenharia". Não serve: os sintomas não se confundem e as ações de conserto são diferentes. Modularidade falha quando a peça não sai sozinha; isolamento falha quando o consumidor sabe demais; coesão falha quando a peça trata de dois assuntos. Um projeto com pastas-gaveta mas fronteiras limpas tira 3 em isolamento e 1 em coesão, e essa diferença diz exatamente onde trabalhar.

Reformulei a orientação a objetos (8) como "objetos a serviço da metáfora". Ele pediu "OO para se conectar com a metáfora central", e o para é a cláusula que importa. Como critério de OO puro, isto puniria projeto funcional sem motivo e premiaria quem enche o repositório de classes — inclusive de Manager, que é o oposto do que ele quer. Medindo "os objetos são as coisas da metáfora?", o critério premia o que ele descreveu e pune o ServiceManager com a mesma régua.

Acrescentei dois critérios, ambos derivados do que ele disse. A desenhabilidade (9) ele nomeou como desejo ("queria ver o quão desenhável é a arquitetura"); virou critério com escala e artefato obrigatório, porque é o único dos dez que não se responde lendo — é preciso tentar desenhar, e é no desenho que a arquitetura que só funciona em prosa desmonta. As contradições (10) ele pediu como achado, sem escala; dei escala e cinco tipos nomeados, porque "ache contradições" sem tipologia produz cinco relatórios que acharam cinco classes diferentes de coisa e não se comparam.

O que acrescentei por conta, e por quê — três coisas.

O medidor de cinco segundos. Não está na fala dele. Entra porque o levantamento mostrou que esse comando separa os projetos da casa com uma nitidez que nenhuma leitura subjetiva alcança: 1 arquivo no acervo (e é vendor) contra providers/, tools/ e cinco *Manager no clag. Duas varreduras que rodam o mesmo comando não divergem.

A regra "gate vale mais que declaração". Esta é a mais consequente, e não é minha opinião: é o que o terreno mostrou. O repositório que escreveu a lei da linguagem ubíqua é o que mais a viola; o que melhor a cumpre escreveu um validador em vez de uma lei. Como a régua inteira existe para medir se a arquitetura guia a intuição sem regras rígidas, ignorar essa evidência seria medir com os olhos fechados. Então ela entrou nos critérios 4, 6 e 10, e na ordenação das ações.

A seção 7 do relatório, "o que eu não consegui avaliar". Cinco varreduras vão rodar de madrugada, sem ninguém para desbloquear, e algumas vão encontrar repositório ausente, pasta compartilhada com outra sessão em voo, ou código fora desta máquina. Sem um lugar para declarar isso, o relatório ou mente por omissão ou trava. Com o lugar, a lacuna fica visível e vira a próxima ação — a mesma lógica do LACUNA que o video-mocap já usa para quadro que ninguém conseguiu ler.

Uma correção de premissa que as varreduras precisam herdar. O founder descreveu o clag como "o formato clagproject e o pico-clag". O disco tem três formatos vivos (dois homônimos e incompatíveis), dez repositórios, dois editores sem código em comum e três repos pico-*. Não é correção da fala dele — é o terreno tendo andado. Quem for avaliar a jornada do clag começa pela tabela do critério 10 em vez de pela premissa de um formato só, e isso economiza a primeira hora.

O que deliberadamente ficou fora: estética, gosto, qualidade de interface, mérito de produto. Arquitetura aqui é assunto técnico, e esta régua não opina sobre nada que seja julgamento humano.

Uma nota para quem for pontuar

A régua tem dez critérios e soma 30, e isso cria um risco que vale dizer em voz alta: a tentação de tratar o número como veredito. Não é. O número existe para comparar cinco relatórios numa mesa de manhã. O que vai mudar decisão são a seção 1 (a metáfora, ou a falta dela), a seção 4 (onde o desenho não fechou) e a seção 6 (as ações). Se você tiver pouco tempo, gaste-o nessas três e deixe a tabela de notas para o fim.

E uma última: os projetos citados aqui como exemplo de "ruim" são exemplos de pontos ruins em projetos bons. ~/ved/video-mocap aparece nas duas colunas de propósito, e o ~/ved/clag é a família mais ambiciosa da casa. A régua mede arquitetura, não mérito — e um projeto que tira 14 hoje com uma metáfora clara tem mais futuro que um que tira 22 sem nenhuma.