El wiki knowledge engine: reglas, directrices y síntesis

Conocimiento que se organiza sola, sobre raíles escritos

Cuando las conversaciones se archivan en una base de conocimiento compartida, la pregunta deja de ser "¿podemos guardar páginas?" y pasa a ser "¿quién puede escribir qué, dónde, con qué voz?". El wiki engine de Simmetric Chat responde con un modelo de instrucciones de tres capas para cada archivo: reglas impuestas por el código, un prompt editorial por archivo portado como dato, y los campos estructurados que describen el comportamiento esperado. El modelo mental que se queda: el schema prompt por archivo es al wiki lo que un CLAUDE.md a un repositorio de código - consultivo de naturaleza, potente en la práctica, nunca una ley.

Este artículo es el recorrido del diseño: las tres capas, qué puede y no puede hacer cada una, la cadena de precedencia cuando discrepan, y las dos skills integradas (wiki_query, wiki_write) que hacen verdadera la mitad legible por la máquina de la promesa.

Capa 1: reglas hard, impuestas por el código

La primera capa es incondicional e independiente de la configuración - lo vigila todo:

1. La guardia del filesystem. validateWritablePath rechaza cualquier destino de escritura fuera de <archiveBase>/wiki/: el chequeo anti-traversal corre primero, luego el del prefijo wiki/. Un destino fuera de wiki/ lanza un error nombrado, y tanto createPage como updatePage llaman a la guardia antes de cualquier write al fichero. raw_sources/ es inmutable por diseño - ningún endpoint de API escribe ahí debajo.
2. El espejo a nivel de prompt. Un bloque siempre activo se añade a cada prompt ligado al archivo, y su redacción refleja la guardia del filesystem (raw_sources/ is immutable). El modelo ni siquiera intenta la salida de wiki/ - y si lo hiciera, el código garantiza que nada aterrice.

La pareja es deliberada: el prompt mantiene honesto al modelo, el código mantiene seguro al sistema. La confianza vive en la segunda propiedad, no en la primera.

Capa 2: el schema prompt por archivo

El schema prompt (schemaPrompt) es un campo consultivo de texto libre persistido en el JSON de configuración del archivo:

• Forma: hasta 10000 caracteres (≈2500 tokens) dentro del esquema de config del archivo - una clave aditiva, cero migraciones.
• Validación: Zod en cada write vía PUT /api/archives/:id/config; un payload sobre el tope se rechaza con un 400 que nombra el campo.
• Contract de lectura: un archivo sin fila guardada lee la config por defecto del esquema (la ruta de primera escritura); los archivos con fila devuelven el blob guardado al pie de la letra. Los blobs legacy sobre el tope se truncan en la inyección con una anotación explícita, nunca recortados en silencio ni re-validados.
• Consultivo por diseño: el bloque entra en los prompts como DATO con una etiqueta consultiva explícita - nunca como una concesión de privilegio a nivel de system prompt. Ninguna sanitización más allá del tope de longitud; las instrucciones contradictorias son un riesgo de calidad aceptado, mitigado por el texto de ayuda y la plantilla en la interfaz.

La capa 2 es donde vive la voz editorial de la organización: convenciones de nombres, estructura de páginas, expectativas sobre fuentes. Es una directriz - y el motor la trata exactamente así.

Capa 3: los campos estructurados

Persona, purpose, scope - la descripción estructurada del archivo - se inyectan en la ruta de los prompts por la configuración existente. Describen valores por defecto; la capa 2 los precede cuando ambos hablan.

La cadena de precedencia

reglas hard (código) > schema prompt (consultivo) > campos estructurados

1. El schema prompt nunca puede preceder a las reglas hard - el prompt declara; el código impone.
2. En conflicto con los campos estructurados, el schema prompt toma la delantera.
3. Un archivo sin schema prompt se comporta como baseline más la regla hard - cero enriquecimiento, cero degradación.

La tercera línea importa para el registro mental del operador: un campo consultivo vacío es una configuración completa, no faltante. No hay secciones de placeholder vacías que ronden los prompts.

Donde aterriza el bloque consultivo

La inyección tiene seams explícitos, cada uno portado en el system prompt de la petición después del bloque de la regla de búsqueda y antes del system prompt del workspace:

• El orquestador del chat (ambas rutas, streaming y no streaming) - la regla hard siempre; el bloque consultivo viaja cuando el archivo lo tiene.
• La pasada de decisión de la pipeline de síntesis - el bloque consultivo lleva ahí el rol SYSTEM, mientras las pasadas previas (retrieval, borrador, juicio de contradicciones) corren sin él por diseño.

wiki_query y wiki_write: los dos integrados

Los builtin wiki_query y wiki_write son skills cuyos caminos de ejecución no hacen ninguna llamada LLM - el camino de escritura genera previews deterministas íntegramente en código. La consecuencia arquitectónica es tajante: una inyección por skill no alcanzaría ningún modelo, así que la única superficie LLM-facing del wiki es el system prompt del orquestador. El comportamiento de escritura del wiki = las tres capas de arriba; las funciones de lectura/escritura = código simple, auditable.

Por qué esta forma se sostiene

Tres propiedades, en combinación:

• Inmutabilidad en la base - raw_sources/ no puede reescribirlo nadie, modelo incluido (la guardia + el bloque siempre activo).
• Disciplina consultiva - la directriz editorial entra como dato etiquetado, auditable en el nivel de edición de config, nunca como privilegio.
• Integradas deterministas - las superficies de lectura/escritura del archivo corren sin modelo, así que las garantías no dependen del juicio del modelo.

La promesa del motor es modesta y carga el peso: el conocimiento se organiza solo sobre raíles escritos, exactamente hasta donde los raíles lo deciden. El operador de Simmetric Chat sigue siendo el autor de los raíles - que es el punto silencioso de todo el diseño.

Para seguir

La guía lleva la referencia del operador - las tablas campo por campo y los contract de endpoints - en /es/docs/wiki-knowledge-engine:

• Wiki knowledge engine - la guía
• Datos de este post: fila FACT-CENSUS.md F-WIKI-1 (la Wiki Schema Layer: escrita, finalizada, verificada contra el código vivo en la gate v0.25)

Provenance: Simmetric Chat docs/WIKI_SCHEMA_LAYER.md (v0.28.1, Phase 187/194), validateWritablePath en packages/server/src/utils/archivePath.ts, los seams de inyección del orquestador, CHANGELOG.md v0.28.1 - en el estado documental fijado por el census (SHA aca5b8ff).