A wiki knowledge engine: regras, diretrizes e síntese

Conhecimento que se organiza sozinho, sobre trilhos escritos

Quando as conversas são arquivadas numa base de conhecimento compartilhada, a pergunta deixa de ser "podemos guardar páginas" e passa a ser "quem pode escrever o quê, onde, com qual voz". O wiki engine do Simmetric Chat responde com um modelo de instruções em três camadas para cada arquivo: regras impostas pelo código, um prompt editorial por arquivo carregado como dado, e os campos estruturados que descrevem o comportamento esperado. O modelo mental que fica: o schema prompt por arquivo é para o wiki o que um CLAUDE.md é para um repositório de código - consultivo de natureza, poderoso na prática, nunca uma lei.

Este artigo é o percurso do projeto: as três camadas, o que cada uma pode e não pode fazer, a cadeia de precedência quando divergem, e as duas skills integradas (wiki_query, wiki_write) que tornam verdadeira a metade legível pela máquina da promessa.

Camada 1: regras hard, impostas pelo código

A primeira camada é incondicional e independente da configuração - ela vigia tudo:

1. A guarda do filesystem. validateWritablePath rejeita qualquer alvo de escrita fora de <archiveBase>/wiki/: o cheque anti-travessia corre primeiro, depois o do prefixo wiki/. Um alvo fora de wiki/ solta um erro nomeado, e tanto createPage quanto updatePage chamam a guarda antes de qualquer write em arquivo. raw_sources/ é imutável por projeto - nenhum endpoint de API escreve ali abaixo.
2. O espelho no nível do prompt. Um bloco sempre ativo é acrescentado a todo prompt ligado ao arquivo, e sua redação espelha a guarda do filesystem (raw_sources/ is immutable). O modelo nem tenta o caminho de fuga de wiki/ - e se tentasse, o código garante que nada pousa.

O emparelhamento é deliberado: o prompt mantém o modelo honesto, o código mantém o sistema seguro. A confiança vive na segunda propriedade, não na primeira.

Camada 2: o schema prompt por arquivo

O schema prompt (schemaPrompt) é um campo consultivo de texto livre persistido no JSON de configuração do arquivo:

• Forma: até 10000 caracteres (≈2500 tokens) dentro do schema de config do arquivo - uma chave aditiva, zero migrações.
• Validação: Zod em cada write via PUT /api/archives/:id/config; um payload acima do teto é rejeitado com um 400 que nomeia o campo.
• Contract de leitura: um arquivo sem linha guardada lê a config padrão do schema (o caminho da primeira escritura); arquivos com linha devolvem o blob guardado à letra. Blobs legacy acima do teto são truncados na injeção com uma anotação explícita, nunca cortados em silêncio nem revalidados.
• Consultivo por projeto: o bloco entra nos prompts como DADO com uma etiqueta consultiva explícita - nunca como concessão de privilégio ao nível de system prompt. Nenhuma sanitização além do teto de tamanho; instruções contraditórias são um risco de qualidade aceitável, mitigado pelo texto de ajuda e pelo template na interface.

A camada 2 é onde vive a voz editorial da organização: convenções de nomes, estrutura de páginas, expectativas sobre fontes. É uma diretriz - e o motor a trata exatamente assim.

Camada 3: os campos estruturados

Persona, purpose, scope - a descrição estruturada do arquivo - são injetados no caminho dos prompts pela configuração existente. Descrevem os valores padrão; a camada 2 os sobrepuja quando os dois falam.

A cadeia de precedência

regras hard (código) > schema prompt (consultivo) > campos estruturados

1. O schema prompt nunca pode sobrepor as regras hard - o prompt declara; o código impõe.
2. Em conflito com os campos estruturados, o schema prompt leva a dianteira.
3. Um arquivo sem schema prompt comporta-se como baseline mais a regra hard - zero enriquecimento, zero degradação.

A terceira linha importa para o registro mental do operador: um campo consultivo vazio é uma configuração completa, não faltante. Não há seções de placeholder vazias rondando os prompts.

Onde o bloco consultivo pousa

A injeção tem seams explícitos, cada um carregado no system prompt do pedido depois do bloco da regra de busca e antes do system prompt do workspace:

• O orquestrador do chat (ambos os caminhos, streaming e não streaming) - a regra hard sempre; o bloco consultivo viaja junto quando o arquivo o tem.
• A passada de decisão da pipeline de síntese - o bloco consultivo leva ali o papel SYSTEM, enquanto as passadas prévias (retrieval, rascunho, juízo das contradições) correm sem, por projeto.

wiki_query e wiki_write: os dois integrados

Os builtin wiki_query e wiki_write são skills cujos caminhos de execução não fazem nenhuma chamada LLM - o caminho de escritura gera previews deterministas inteiramente em código. A consequência arquitetural é nítida: uma injeção por skill não alcançaria nenhum modelo, então a única superfície LLM-facing do wiki é o system prompt do orquestrador. O comportamento de escritura do wiki = as três camadas acima; as funções de leitura/escritura = código simples, auditável.

Por que esta forma se sustenta

Três propriedades, em combinação:

• Imutabilidade na base - raw_sources/ não pode ser reescrito por ninguém, modelo incluído (a guarda + o bloco sempre ativo).
• Disciplina consultiva - a diretriz editorial entra como dado etiquetado, auditável no nível de edição de config, nunca como privilégio.
• Integradas deterministas - as superfícies de leitura/escritura do arquivo correm sem modelo, então as garantias não dependem do juízo do modelo.

A promessa do motor é modesta e carrega o peso: o conhecimento se organiza sozinho sobre trilhos escritos, exatamente até onde os trilhos decidem. O operador do Simmetric Chat continua sendo o autor dos trilhos - que é o ponto silencioso de todo o projeto.

Para continuar

A guia leva a referência do operador - as tabelas campo por campo e os contract de endpoints - em /pt/docs/wiki-knowledge-engine:

• Wiki knowledge engine - a guia
• Fatos deste post: linha FACT-CENSUS.md F-WIKI-1 (a Wiki Schema Layer: escrita, finalizada, verificada contra o código vivo na gate v0.25)

Provenance: Simmetric Chat docs/WIKI_SCHEMA_LAYER.md (v0.28.1, Phase 187/194), validateWritablePath em packages/server/src/utils/archivePath.ts, os seams de injeção do orquestrador, CHANGELOG.md v0.28.1 - no estado documental fixado pelo census (SHA aca5b8ff).