Convenciones

KX-S15. La regla de que el nombre de una carpeta de primer nivel dice a qué nivel pertenece ya existía desde el 26.08.15. Lo que se agrega es la contracara, que faltaba: cuando una carpeta cambia de nivel, el nombre tiene que cambiar con ella.

El caso que lo forzó son los dos códigos heredados. 99 - deprecated (KX-M06) llevaba código de módulo sin ser un módulo, y sin tener entrada en Mapa de Modulos.md; agente/01 - sistema/ lo arrastra de cuando era un módulo entre otros y deja de serlo con la fusión. La regla anterior de este archivo decía que a KX-M04 no se le sacaba «porque los ids no se renombran nunca», y ahí estaba el error de razonamiento que conviene dejar escrito: el id y el nombre de la carpeta son dos cosas. Sacar (KX-M06) del nombre no toca el id KX-M06, que sigue vivo, deprecado y sin reusarse. Confundirlos hacía que un nombre de carpeta quedara congelado por una regla que protegía otra cosa.

Se aplicó de una sola vez el mismo día, junto con el renumerado de proyectos/kx-life/ (megathreads de 05 a 04, cerrando el hueco que había dejado system factory al salir) y la partición de outer-rim/ en un inner rim y un outer rim.

Ver el diagnóstico completo y el resto de la reestructuración en 02 - diseño/planes y reencuadre/Plan de Reestructuracion - Jerarquia de la Boveda.md. Los pasos 1 a 3 están ejecutados, del 4 al 6 no.

KX-S14. Teo pidió que cada módulo fuera «un mini ecosistema en sí mismo», con su propio contexto, aclarando dos veces que no quiere encapsularlos ni volverlos independientes. La convención que salió: un Contexto.md al lado del CLAUDE.md de cada módulo, y la separación entre los dos es lo que hace que sirva.

| Archivo | Contesta | Se edita cuando |
|---|---|---|
| `CLAUDE.md` | Cómo funciona este módulo: naming, frontmatter, pipeline | Cambia una convención |
| `Contexto.md` | Qué trae Teo a este dominio: su perspectiva, su voz, qué leyó, qué busca | Teo dicta algo nuevo sobre sí mismo en ese dominio |

Tres argumentos, y el primero es el que decide: el contexto de un módulo solo importa adentro de ese módulo. En ensayos no hace falta saber la relación de Teo con su familia; sí hace falta saber con qué voz escribe. El segundo es de costo, y Teo lo señaló solo: cargar únicamente lo que aplica gasta menos que tener todo en el agente. El tercero es lo que habilita, que es entrar y salir de módulos trabajando con foco.

Se descartó meterlo adentro del CLAUDE.md de cada carpeta, que era gratis mecánicamente porque la convención de CLAUDE.md jerárquico (KX-P11) ya carga la carpeta donde se trabaja. Mezcla dos cosas que se editan por motivos distintos y a ritmos distintos. También se descartó una carpeta de módulos adentro del agente: dejaba todo el contexto junto, y rompía justo el mini ecosistema que se pedía.

Dónde está el límite con el agente, que es la parte que se va a poder equivocar: si el dato describe a Teo en general, va al agente; si describe a Teo en ese dominio, va al módulo. Su voz de escritura va a ensayos, su neurodivergencia va al agente, aunque la segunda explique la primera.

Mientras el contexto personal vivió en 00 - kx atlas system/02 - contexto personal/ (nombre de entonces, hoy _ kx atlas system), la regla fue dura y sin excepciones prácticas: lo llena Teo, la IA no escribe ahí, porque el contexto personal mal parafraseado es peor que vacío. La carpeta se mudó al agente el 26.08.15 y el pipeline de context journals la vuelve inaplicable tal cual estaba: si Teo dicta veinte context journals y nadie los procesa, no hay contexto.

La regla se reencuadra en vez de retirarse, y la diferencia es la fuente del material:

| | Antes | Ahora |
|---|---|---|
| Material dictado por Teo **para** contexto (context journal) | No existía | Se procesa y se escribe |
| Contexto inferido de un system journal, una stream journal o una conversación | Prohibido | **Sigue prohibido** |

El riesgo que la regla original protegía no era que la IA escribiera, era que inventara: que dedujera quién es Teo de material dictado con otro propósito y lo dejara escrito como si él lo hubiera dicho. Eso no cambió.

Y adentro del pipeline se mantiene la restricción de fondo, que ya estaba escrita en la spec de procesar-system-journal para el caso de pedido explícito: se escribe lo más cerca posible de las palabras de Teo. Es el único material de la bóveda donde parafrasear es una pérdida y no una mejora, porque las palabras exactas con las que alguien describe su propia experiencia son el dato.

Teo lo dejó dicho sin ambigüedad: «para el contexto voy a utilizar el modelo de Opus 5». El motivo es de exigencia y no de preferencia: el material se analiza desde la psicología y la neurología académicas, no como una lista de gustos, y la diferencia entre un modelo y otro se paga en calidad de análisis sobre el archivo que después alimenta todo lo demás.

Es la primera convención del sistema que fija un modelo para una tarea, así que conviene acotarla: aplica al procesamiento de context journals y a las dimensiones del agente, no a la bóveda entera. Limpieza, treats y quotes no la necesitan.

Nota de vigencia, porque este es el tipo de convención que envejece sola: nombra un modelo puntual, y un nombre de modelo caduca antes que el criterio. Lo que hay que preservar cuando eso pase es el criterio, que es usar el más capaz disponible.

El criterio de cuándo algo se carga en la Matriz y en las colecciones: en el momento en que se empiezan a crear carpetas y archivos, con el estado más bajo que corresponda (idea o construyendo), y se sube después a medida que Teo diga que está terminado.

La alternativa era esperar a que la cosa estuviera hecha para registrarla. Se descarta porque produce el peor error posible en un sistema que existe para saber dónde estás parado: el Atlas mostraría menos de lo que hay, y justo se comería lo que está en obra, que es lo único que uno necesita ver cuando vuelve el sábado. Que un objeto exista en estado idea no es ruido, es el dato.

Encaja con la distinción entre activo y finalizado que ya está en Mapa de Taxonomia.md, y es la misma preferencia de fondo: que el estado del sistema nunca mienta hacia el lado optimista.

La convención de registrar todo cambio ya existía. Lo que se agrega es el segundo propósito, que cambia qué se espera de ella: además del linaje de actualizaciones y de poder verificar si una corrida se ejecutó o no, el patch notes es lo que contesta en qué estaba trabajando cuando se retoma después de unos días.

Es el mismo dato leído de dos formas, y por eso no compite con la Matriz: la Matriz dice qué existe hoy, el patch notes dice qué se movió último. La consecuencia operativa es que la regla sube de alcance: Teo la quiere en el CLAUDE.md raíz y no solo en el del Atlas, porque aplica a cualquier sesión que toque la bóveda (KX-T54).

Motivo concreto: Teo preguntó si el estado nuevo de los system journals (sin-procesar/procesada) se compartía con el de las stream journals. La respuesta era no (las stream journals usan estado_journal, con su propio catálogo de valores, ni siquiera tienen colección de página), pero la pregunta expuso el problema real: estado a secas ya lo usan kx-modulos, kx-piezas y kx-tareas, cada uno con un enum distinto, y ahora también los system journals.

No hay riesgo técnico. Cada colección tiene su propio schema de Zod, y el frontmatter de un archivo no interfiere con el de otro. El riesgo es humano y de proceso: destilar-sesion-kx lee varias colecciones a la vez y escribe en varias a la vez, y un nombre de campo genérico repetido con significados distintos en cada esquema es justo el tipo de cosa que se termina escribiendo en el archivo equivocado, o con el valor del enum que no corresponde.

La regla: todo campo de lifecycle nuevo (estado, o lo que cumpla ese rol) lleva el tipo de instancia como sufijo namespaced: estado_autopoiesis para los system journals, estado_journal para las stream journals (que ya lo hacía, sin que fuera una regla escrita hasta ahora), estado_jornada para las jornadas de implementación.

Qué NO se tocó. kx-modulos, kx-piezas y kx-tareas siguen con estado a secas. La regla es hacia adelante, sobre lo que se crea de acá en más; renombrar esos tres campos existentes (que tocaría el schema, cada objeto de las tres colecciones, y toda la documentación que los cita) es un cambio bastante más grande, y no se pidió. Queda anotado en "Abierto" por si en algún momento se decide hacerlo.

Preferencia explícita de Teo: los subtítulos grandes no le gustan. Aplica a todo archivo de este módulo, con la excepción de los publicables.

Cada carpeta con convenciones propias lleva su CLAUDE.md, para que una sesión cargue solo lo que necesita en vez de todo el contexto de la bóveda. El raíz se mantiene corto a propósito y funciona como mapa, no como manual.