CVH: Canonical Vocabulary Harness · Profile v0.3

> Working title: o naming definitivo é decisão do operador (§11).

0. Tese

O método existe antes deste documento. Ele emergiu de forma tácita e foi reproduzido de modo independente em dois projetos de domínios opostos: BI executivo de vendas (MAPA) e plataforma lúdico-agêntica (Sotão): convergindo para a mesma estrutura profunda: vocabulário canônico como SSOT, contenção comportamental do LLM, evidência determinística reconciliável, lifecycle com gate de operador. Este profile formaliza o "modelo do que já é", incorpora as melhorias identificadas na análise de 2026-06-09 e estabelece a régua de benchmark para validar a reprodução do método em qualquer projeto novo desde o Day-0.

Resposta de engenharia ao paradoxo de Polanyi ("sabemos mais do que podemos dizer"): o conhecimento tácito do operador não precisa ser *explicado* para ser transferido: precisa ser contratado. Cada invariante abaixo converte um hábito em contrato verificável por máquina. Behavioral contract, não interpretabilidade: o harness não abre a caixa do modelo nem da intuição; ele contém ambos por contratos observáveis.

A v0.2 fecha a sessão com a camada que faltava: os fatores que pautam o modelo de trabalho do operador: visão concêntrica, atomicidade, idempotência (mais o determinismo que sempre esteve declarado): promovidos de hábito tácito a princípios explícitos (§1), dos quais os invariantes derivam. Inclui também a correção decorrente no seed (planos como seções de um único arquivo, nunca arquivos separados), a representação visual do modelo (§4), o Operator Gateway com janela de execução e protocolo de interação (§8), a ponte semântica direcional (I2) e o roadmap de continuidade (§10).

1. Princípios P1–P4: a camada acima dos invariantes

Os invariantes I1–I10 não são uma lista arbitrária: derivam de quatro princípios que o operador aplicava tacitamente e que esta análise nomeou. Princípios definem *por que* o método funciona; invariantes definem *o que* verificar.

P1: Concentricidade (topologia da verdade)

A verdade tem um centro e anéis de projeção: nunca fragmentos pares.

Autoridade radial: conflito resolve sempre para dentro; verificação aponta sempre para o anel interno. Segmentação física só é legítima por natureza (declaração estável vs estado mutável: por isso o centro tem exatamente dois arquivos), nunca por domínio: fragmentar a verdade é exatamente onde se perde o controle. Corolário de contexto: o anel 0 é injetado inteiro e por contrato no modelo: estado binário (tem o grafo ou não tem): eliminando os três não-determinismos da fragmentação: retrieval seletivo, resolução cross-file e diluição de atenção (lost in the middle).

P2: Atomicidade (granularidade das unidades)

O que entra, entra inteiro ou não entra. O termo é o átomo semântico (@id); a transação do rito é tudo-ou-nada (não existe termo "meio ingerido"); o componente agêntico expõe I/O schema fechado, com mustOwn como declaração de atomicidade de responsabilidade; o contexto é atômico (P1). Evidência pré-existente nos projetos: o framework adotado no Sotão chama-se literalmente Atomic Agents; o cro:EvidenceLabel do MAPA exige cada label "deterministic, replayable, version-stamped".

P3: Idempotência (segurança da repetição)

f(f(x)) = f(x): repetir qualquer passo converge ao mesmo estado e nunca duplica efeito. Evidência pré-existente: o contrato MCID do MAPA declara "replay, idempotent writes, and audit" e fixa o par de idempotência (mcid + operation name); o downloader do Sotão é idempotente por construção (skip-if-exists + checksum). Corolário estrutural novo: F3 depende de P3: "prosa derivada" só é verificável porque a geração é idempotente: o validador *regenera* a projeção a partir de vocabulary@versão e compara byte a byte com o artefato em disco. Sem geração idempotente, paridade de prosa seria opinião editorial; com ela, é diff mecânico.

P4: Determinismo (previsibilidade)

Mesmo input → mesmo output, no caminho da verdade. LLM fica fora desse caminho: o driftGuard é P4 aplicado à era agêntica; fórmulas, manifests, checksums e gates ficam dentro. A composição fecha: P4 garante o resultado; P3 garante que repetir não estraga; P2 garante que não há estado intermediário observável; P1 garante onde a verdade mora. A soma é convergência segura: a propriedade que permite a qualquer agente, humano ou IA, re-executar qualquer passo do harness sem medo. O método tolera agentes não por confiança, mas porque o terreno é replay-safe.

Derivação dos invariantes

Posicionamento: sistemas declarativos convergentes

P1+P2+P3+P4 é o fundamento do controller pattern (declared state → observed state → diff → reconcile, com apply idempotente) que sustenta Kubernetes, Terraform, GitOps e event sourcing: os sistemas que a indústria considera os mais confiáveis já construídos. Os 5 eixos do MAPA: Declared, MAPPED, Delta, Cause signal, Action route: são um reconciliation loop aplicado a vendas em vez de infraestrutura. O método redescobre o padrão por caminho próprio e o aplica a domínios onde ele não é aplicado: este é o argumento central de defensabilidade do profile.

2. Fundação: application profile sobre padrões

O CVH é um application profile (no sentido DCMI/DCAT-AP): combinação declarada de vocabulários padrão + extensões próprias de governança agêntica.

Camadas:

1. Padrão (reconhecimento externo): schema.org (DefinedTermSet/DefinedTerm), dcterms (proveniência documental), prov (PROV-O, agência humana e IA), skos (terminologia canônica multilíngue). Máxima aderência aqui; é o que torna o vocabulário legível por qualquer consumidor RDF-aware, agente ou LLM treinado nesses corpora. 2. Proprietária (o método): namespace do projeto ({prefix}:) carregando exclusivamente as extensões de governança: driftGuard, moduleBoundary, lifecycle com reativação, rito de ingestão. É a IP do operador; é o que este profile protege e versiona.

Regras de fundação:

- F1. O namespace do projeto MUST ser um IRI resolvível sob domínio do operador (https://{domain}/ns/{project}#) desde o Day-0. A publicação do conteúdo pode vir depois (nível L3), mas o IRI nunca muda: corrige o gap cro: [REDACTED-APP]: do MAPA na raiz. - F2. Autoria em YAML-LD; publicação em JSON-LD. Mesma árvore, serialização dupla, zero retrabalho. - F3. Prosa normativa (policies em MD, system prompts, READMEs de agente) é projeção derivada do vocabulário, nunca fonte. Todo artefato derivado MUST portar header generated-from: {vocabulary @id}@{version}, e a geração MUST ser idempotente (P3) para permitir verificação por regeneração + byte-compare. Inversão do estado atual do Sotão, onde a lei em prosa é fonte e o registry segue: origem direta do drift docs/raiz encontrado. - F4. Concentricidade operacional (P1): o centro do projeto tem exatamente dois arquivos: o canônico (anel 0, vocabulary.yaml) e o de controle (anel 1, registry/harness). Todo o resto é projeção (anel 2) ou superfície (anel 3). Edição humana/agêntica existe apenas nos anéis 0–1; no anel 0, apenas pelo rito. Posição deste documento na topologia: o profile é norma do método (camada meta, leitor primário humano: está para os vocabularies instanciados como a ISO 25964 está para um thesaurus concreto); cada vocabulary.yaml é o anel 0 machine-readable do seu projeto; a forma machine-readable do próprio profile é entrega N3 (§10).

3. Invariantes: o modelo do que já é

Notação RFC 2119 (MUST/SHOULD/MAY). Cada invariante registra a evidência nos dois projetos comprovados e o delta incorporado por esta análise. Legenda de status: ✓ estrutural · ◐ prosa/implícito · ✗ ausente.

I1: Declaração precede uso (SSOT-first)

Todo termo, enum, status ou conceito referenciado por código, payload, UI ou agente MUST existir como entrada declarada (@id) no vocabulário antes do primeiro uso. Termo definido "por uso" (Literal solto, string mágica, chave ad-hoc) é drift por definição.

- MAPA: vocabulary.yaml + cross-check validate.mjs Wave 7: ✓ - Sotão: termos definidos por uso em 3 fontes paralelas (registry JSON, lei em prosa, Literal[...] Pydantic): ◐ - Delta: nenhum. É o invariante-raiz; os demais o servem.

I2: Identidade language-neutral + projeção lexical

O @id MUST ser language-neutral. Cada conceito MUST declarar exatamente 1 skos:prefLabel por language tag ativa (pt-BR, en) no ato da ingestão. Superfícies projetam: operator-facing → prefLabel@pt-BR; payload/event/identificador → @id (ou en). Apelidos em skos:altLabel; typos e legado em skos:hiddenLabel. Strings idênticas nas duas tags são válidas (nomes próprios: ex.: MCID).

- MAPA: parcial: schema:alternateName sobrecarregado (mistura idioma com variação) + campo ad-hoc cro:operatorFacingLabelPtBR: ◐ - Sotão: prosa de prompt ("answer in Brazilian Portuguese and preserve project technical terms in English"): ◐ - Delta: promovido de prosa/ad-hoc a regra estrutural verificável. Fundamento: princípio onomasiológico (conceito primeiro, termos como projeções: SKOS/ISO 25964/TBX). Efeito econômico: desambiguação migra de runtime O(termos × superfícies × consultas), não-determinística, para ingest-time O(1) por termo, verificável. - Extensão (fechamento 090626): ponte semântica direcional: labels são pareados; sentenças são ponteadas, não duplicadas: duplicação integral dobraria a superfície de drift e o custo de sincronização (I10). Cada termo declara seu idioma nativo (sourceLanguage, com default no scheme); descriptions normativas usam en-US como pivot (língua de orientação dos modelos: coerente com term:interaction-language-protocol); o termo MUST portar skos:definition no idioma oposto ao nativo, escrita *para* o leitor da outra língua, nunca tradução literal. Exemplos canônicos: pt-BR nativo "vendedor" → definition@en "a vendedor is a seller in the Brazilian sales context; sales teams are composed of vendedores"; en nativo "SSOT" → definition@pt-BR "Fonte Única de Verdade (Single Source of Truth): registro canônico com regras estritas de certificação". Declarado machine-readable em term:semantic-bridge-rule: explícito para qualquer agente robot que consuma o arquivo.

I3: Contenção comportamental do LLM (driftGuard)

Nenhum output executivo ou operacional MAY derivar de termos não declarados, campos ad-hoc ou interpretação livre de LLM. LLM não substitui cálculo determinístico, registry, harness nem consentimento do operador. Verdade MUST ser rastreável à cadeia: conceito declarado → fórmula/evidência determinística → proveniência → gate.

- MAPA: cro:driftGuard: ✓ - Sotão: HARNESS_POLICY ("LLM nao substitui calculo deterministico, registry, harness ou consentimento do operador") + system prompt do Atomic Agent ("Never treat LLM interpretation as KPI or asset truth") + evidence.py: ✓ (distribuído em prosa+código) - Delta: unificado como cláusula única declarada no vocabulário; prompts e policies derivam dela (F3). Convergência ✓/✓ independente = evidência forte da estabilidade do padrão mental.

I4: Fronteiras de posse (moduleBoundary)

Responsabilidades críticas MUST declarar dono único via mustOwn / mustNotOwn. O módulo de verdade determinística nunca delega interpretação ao LLM; o agente explica, não recalcula.

- MAPA: cro:moduleBoundary → reconciliation_core.py: ✓ - Sotão: evidence.py como dono exclusivo da verdade; agente consome via context provider: ✓ em arquitetura, ✗ em declaração: ◐ - Delta: Sotão declara a fronteira que já pratica.

I5: Lifecycle com gate de operador e rota de reativação

Status MUST ∈ {proposed, active, archived}. Promoção de proposed exige aval do operador. Remoção ou arquivamento sem registro visível em backlog é vetado; item arquivado MUST portar backlog_visibility + reactivation_path (ou justificativa de impossibilidade técnica).

- MAPA: shelfStatus 3 estados + soft warnings do validador: ◐ (sem rota de reativação) - Sotão: toggle + discontinued_backlog + reactivation_path + veto explícito na lei: ✓ versão mais forte - Delta: o profile adota a versão Sotão. Primeiro ganho concreto do benchmark cruzado: cada projeto detinha a forma mais forte de um invariante diferente (ver I6).

I6: Proveniência tipada incluindo agentes IA

Atores humanos, processos e agentes IA MUST ser declarados como prov:Agent. Cada entrada do vocabulário SHOULD portar dcterms:creator. Sessões de agente SHOULD portar correlation id opaco (padrão MCID: ULID/UUIDv7, emitido uma vez na fronteira do envelope e propagado).

- MAPA: cro:agent:operator-rc1, cro:agent:claude-canonical-registry, cro:agent:codex-v0-reset + dcterms:creator por entrada: ✓ versão mais forte - Sotão: copilot_session_id solto na evidência: ◐ embrião - Delta: Sotão herda o padrão MAPA. Segundo ganho do benchmark cruzado: simetria perfeita com I5: a transferência flui nos dois sentidos.

I7: Enums são CodeLists registrados

Toda enumeração fechada usada em código (Literal, enum, lista de policies) MUST derivar de um codelist: declarado. A cópia no código é cache; o vocabulário é fonte; o validador (I10) verifica paridade entre ambos.

- MAPA: cro:CodeList + cro:codelist:*: ✓ - Sotão: allowed_ingestion_policies (JSON) ∥ lista na lei (MD) ∥ asset_decision/focus (Pydantic Literals): três cópias sem check cruzado: ✗ - Delta: o drift real encontrado (duplicação JSON/MD) vira caso de teste obrigatório do validador.

I8: Hierarquia operador-decisor

Operações destrutivas, mudança de rota arquitetural, fuga de escopo fixado e alto impacto na engine MUST ter aval explícito do operador ROOT. O vocabulário declara o termo de aprovação canônico e seus deprecated terms.

- MAPA: cro:term:operator-approval (com deprecação explícita de ratificar/retificar): ✓ - Sotão: lei explícita na HARNESS_POLICY: ✓ (prosa) - Delta: nenhum estrutural; Sotão registra como termo. Convergência ✓/✓: o método codifica a própria hierarquia de decisão do operador.

I9: Evidência determinística reconciliável

Toda fonte de dados MUST gerar manifest + checksum + summary determinístico. Reconciliação mecânica contra a matriz original é obrigatória: "sem reconciliação automática, fonte é lápide" (tese do operador, 2026-05-10). Ruído conhecido (ex.: 404 capturado) MUST ser classificado e preservado como evidência, nunca promovido nem apagado.

- MAPA: cro:ValidationSource + coverage_gate + silent_behavior: ✓ - Sotão: report_reconciled.csv + CHECKSUMS.sha256 + reconciliation_summary.json + classes known_404_noise/wrong_level_capture: ✓ - Delta: nenhum. Invariante mais maduro nos dois lados; coração empírico do método.

I10: Paridade entre superfícies verificada por máquina

Registry ↔ policy em prosa ↔ TUI ↔ enums de código ↔ docs MUST ser verificados por um validador de paridade rodando como gate. O validador MUST ser ele próprio uma feature registrada no registry (ingestion_policy: EVAL): a lei se autofiscaliza. Cópias duplicadas de documentos (raiz vs docs/) entram no escopo.

- MAPA: validate.mjs Wave 7: ◐ (não cobre prosa derivada) - Sotão: ✗: e o custo já se materializou: duas cópias divergentes do SOTAO_ASSET_CONSULTANT.md com o pyproject.toml apontando para a defasada; template da lei usa ${__STATUS__REGISTRO_NUMERICO_DE_EVENTOS__} enquanto a chave real é status_registro_numerico_de_eventos. - Delta: invariante formalizado por esta análise: generaliza o validate.mjs e fecha a classe de drift que I1–I9 não cobrem sozinhos. Verificação radial: cada anel contra o anel interno (P1).

4. Representação visual: topologia e loop de autoevolução

Par visual deste documento: cvh-model.svg. Painel A: a topologia concêntrica (P1) com autoridade radial. Painel B: o loop que torna o harness auto-enriquecido e retroalimentado: cada interação (feature nova, drift capturado, evidência de benchmark) reentra pelo rito; o núcleo versiona; as projeções regeneram de forma idempotente; o runtime devolve evidência determinística que realimenta o ciclo. A evolução é orgânica (só pelo rito, nunca por atalho), sistêmica (pelos anéis, com autoridade radial) e autoevolutiva (resultados do benchmark entram como evidência I9 e podem alterar o próprio vocabulário: e o próprio profile, via §9: dentro das próprias regras).

Versão portável do loop (renderiza em GitHub/GitLab):

flowchart LR  A["entrada<br/>termo · feature · drift · evidência"] --> B["rito de ingestão<br/>P2: atômico, tudo-ou-nada"]  B --> C["validador de paridade<br/>P4 determinístico · P3 re-executável"]  C --> D{"aval do operador<br/>I8: gate humano"}  D --> E["anel 0 atualizado<br/>vocabulary @v+1"]  E --> F["projeções regeneradas<br/>P3 idempotente · diff = 0"]  F --> G["runtime · agentes<br/>anel 3: contexto por contrato"]  G -- "evidência I9 · benchmark §7" --> A

5. Contrato Day-0: nascimento de projeto

Mínimo Pareto antes da primeira feature, em ordem de execução:

1. Reservar IRI do namespace https://{domain}/ns/{project}#: F1 2. Instanciar vocabulary.yaml a partir do seed (arquivo vocabulary.seed.yaml deste pacote): I1 3. Declarar driftGuard + moduleBoundary raiz: I3, I4 4. Declarar codelists fundacionais: shelf-status (com reactivation_path) e ingestion-policies: I5, I7 5. Declarar prov:Agent do operador + template de agente IA: I6 6. Ativar invariante bilíngue + ponte semântica (termos autodescritivos já inclusos no seed; defaultSourceLanguage no scheme): I2 7. Validador de paridade mínimo (mesmo ~50 linhas) registrado como feature EVAL: I10 8. Marcar policies em prosa e system prompts como derivados: header generated-from: {vocabulary}@{version}: F3

Tudo além disso: publicação L3, MCP resource, llms.txt, /.well-known/: é progressivo e não bloqueia o Day-0.

6. Régua de maturidade + scorecard (o benchmark)

Scorecard 2026-06-09:

Leitura pelos invariantes: a convergência independente em I3, I8 e I9 (✓/✓) evidencia que o padrão mental é estável e reprodutível; as assimetrias (I5 forte no Sotão, I6 forte no MAPA) provam que o benchmark cruzado gera valor nos dois sentidos. Leitura pelos princípios: P2–P4 convergem ✓/✓ nos dois projetos (Atomic Agents/MCID, checksums, driftGuard duplo); P1 é a assimetria decisiva: MAPA ✓ (um canônico), Sotão ◐ (três fontes paralelas): e explica por que os gaps do Sotão se concentram exatamente em I1, I7 e I10, os invariantes que servem P1.

7. Protocolo de benchmark no projeto novo

O experimento que valida o método como *reprodutível* (não apenas repetido):

- Métrica primária: tempo-até-L2 partindo do seed. Hipótese do operador a testar: ≤ 1 sessão de trabalho. - Secundárias: (a) nº de drifts capturados pelo validador nas primeiras N semanas: no Sotão, baseline retroativo já conhecido: ≥ 3; (b) % de termos novos que entraram pelo rito de ingestão vs fora dele: alvo 100%; (c) zero termos definidos por uso: check mecânico: Literal/string mágica sem @id correspondente. - Controle: retrofit dos gaps no MAPA e no Sotão com custo medido. A comparação retrofit vs nascença é o argumento econômico do profile. - Registro: resultados entram no vocabulário do próprio projeto como evidência (dcterms: + summary determinístico), fechando o ciclo I9 sobre o próprio método.

8. Rito de ingestão: a recorrência como enforcement

O gate que converte a "recorrência de ingestão de novos termos": antes a principal fonte de drift: no ponto único de enforcement:

novo termo/feature  → classificar (codelist:ingestion-policies)  → declarar no vocabulário:      @id language-neutral      + skos:prefLabel @pt-BR + skos:prefLabel @en   (I2)      + sourceLanguage (ou default do scheme)        + skos:definition no idioma oposto: a ponte  (I2 ext.)      + status: proposed                              (I5)      + dcterms:creator (humano ou prov:Agent IA)     (I6)  → refletir nas superfícies exigidas (registry, TUI, prosa derivada)  (F3)  → validador de paridade passa                       (I10: gate mecânico)  → aval do operador                                  (I8: gate humano)  → status: active

Arquivamento segue o caminho inverso com reactivation_path obrigatório (I5). A transação é atômica (P2) e o replay é seguro (P3): re-submeter um termo já ingerido converge, não duplica.

Executor do rito: Operator Gateway (TUI ROOT)

O rito precisa de um executor canônico: o script TUI do operador (start.sh, modo 700, acesso ROOT, local-only) atua como middleware entre o operador e os anéis 0–1: gate de entrada do loop (ingestão pelo rito, aprovações I8, promoções de lifecycle) e gate de saída (evidência I9, status, backlog com rotas de reativação). Padrão phase-gate orchestration (cf. GSD: spec → plan → execute com verificação entre fases). A precisão que preserva P1: o gateway media, não possui: nenhum estado vive nele; é o único ponto de escrita *interativa* no centro, e toda escrita que executa é atômica (P2) e replay-safe (P3). A lei do Sotão já o prefigurava ("toda nova feature precisa refletir em opção equivalente no TUI ROOT"; "remoção vetada sem backlog visível pelo TUI"); o profile o promove de espelho obrigatório a executor do rito.

Ciclo operacional: a janela de execução

Destilação do fluxo do operador (marco zero → selo):

1. Abertura: operador abre o projeto e inicia o gateway (start.sh): vê níveis de serviço e revisa a tarefa planejada 2. Alinhamento: operador ↔ agente de desenvolvimento: refatora, itera, planeja; o agente valida proposta e estrutura em conformidade com este profile, com acesso à SSOT (anel 0 injetado por contrato) 3. Evento de entrada: prompt de fase (ex.: gsd-plan-exec phase 1): o agente carrega as dependências: nível de serviço do TUI + área-alvo mapeada para a janela 4. Janela tipada: a atividade roda dentro de uma janela TUI descrita pela tupla Status(Phase) : Type : Category : Service : Feature, onde cada componente MUST resolver para @id declarado (Type ∈ codelist:ingestion-policies; Category/Service/Feature ∈ termos de domínio). Descritor com componente não declarado não abre janela: I1 aplicado em runtime 5. Gate TDD: janela inicia RED (RED = start do ciclo TDD); GREEN é atestado, não automático: concedido apenas SE status atual/nível de serviço, revisão do plano, critério de sucesso e plano de execução forem cumpridos: nunca por testes verdes isoladamente (gate determinístico, P4) 6. Worktree: mesma worktree, mesma janela; nova worktree encerra a atividade e o TUI reinicia na worktree criada sob a mesma convenção (atomicidade de workspace, P2; re-execução converge, P3) 7. Fechamento e bump: Bump_Version DEPENDE de GREEN + encerramento formal da janela (TUI kill/close/restart via gateway): o bump sela uma janela atomicamente fechada, nunca uma viva (P2); evidência I9 + status registrados pelo gate de saída; o restart do TUI re-injeta o anel 0 atualizado na próxima janela: a retroalimentação reentra no loop (§4) mecanicamente

Protocolo de interação: convenções de expediente

Regras de discurso do expediente operador↔agente, declaradas como termos no vocabulário (complementam I2, que governa *dados*; estas governam *discurso*):

- Idioma (term:interaction-language-protocol): interação com o operador em pt-BR; raciocínio interno e documentação técnica do agente na língua de maior assertividade algorítmica e menor índice de regressão do modelo: binding funcional, hoje en-US; se outra língua alcançar pontuação igual ou superior, a regra a segue. Termos técnicos sempre em EN (Harness, SSOT, Leverage). - Tropicalização (term:tropicalization-br): grounding regional default para fatos de negócio: mercado BR/LATAM, BRL/R$, notação compacta pt-BR (1.2Mi · 990.9k), America/Sao_Paulo GMT-3: aplicado a goal, MVP, rodada seed, estágio e programas de investimento; enquadramento internacional só sob pedido explícito. - Decisão (term:operator-decision-protocol): o operador aprova e decide a direção; incerteza vira menu seletivo de ≥ 3 opções; em modo grill-me (sabatina engajada pelo operador), até 10 itens por domínio. Inversão de hierarquia é violação de protocolo (I8).

9. Governança do próprio profile

Este documento tem @id, versão e shelfStatus, e MUST evoluir pelo próprio rito que prescreve: mudanças entram como proposed, passam por verificação de consistência entre princípios e invariantes e exigem aval do operador. Cada projeto declara schema:isBasedOn {profile-IRI}@{versão}: o que torna scorecards comparáveis entre projetos e ao longo de versões. Histórico: v0.1 → v0.2 nesta mesma sessão, pelo próprio processo (proposta → análise → aval pendente), demonstrando o §9 em ato.

10. Roadmap: próximos passos naturais

Ordem recomendada: N0 e N1 podem correr em paralelo; N2 destrava N3; N4 só após dois scorecards ≥ L2: evidência antes de tese pública, anti-hype por construção (pilar 1 da filosofia do operador).

11. Naming: decisão aberta do operador

Working title: CVH: Canonical Vocabulary Harness. Opções na mesa: (a) manter CVH; (b) VGH: Vocabulary-Governed Harness; (c) nome de marca próprio, no padrão da casa (CODEX, Sagan, Cérebro Cativo): candidato natural dado o ecossistema VCIA e o potencial de publicação como método. O @id definitivo segue o nome escolhido; até lá, os placeholders permanecem.