Instancias

KX-S13. Teo dijo las dos cosas en el mismo dictado y hubo que elegir: «primero me gustaría diseñar la estructura de archivos, carpetas y cosas», y más adelante «por ahí es mejor primero hacer el template» y grabar quince o veinte context journals crudos para que a partir de eso se vaya organizando.

Se eligió el punto medio, y no por conciliador: un andamio mínimo más el template en la misma corrida, y la estructura definitiva la reorganiza la skill de procesado con material real encima.

Qué se descartó y por qué importa. Estructura completa primero produce una taxonomía diseñada contra lo que Teo supone que va a decir, que es un mal input: la carpeta entera existe justamente porque su categorización no es la de manual («no me sirve familia, amigos y trabajo, no tengo ese tipo de categorización en mi vida»), y adivinarla de antemano es volver al manual por otra vía. Template solo, sin nada de estructura deja el material sin dónde caer, y el propio Teo pidió preestructura explícitamente porque son muchas dimensiones y un archivo no alcanza.

La consecuencia hay que tenerla presente al mirar la carpeta: las nueve dimensiones de 01 - dimensiones/ son una hipótesis, no un compromiso. Que se partan, se fusionen o se renombren no es que el andamio haya fallado, es el diseño funcionando. Está escrito así en agente/00 - teo/CLAUDE.md para que una corrida futura no lo lea como deuda.

El bloque ## Intención (de qué hablo, de qué no hablo, qué busco, nivel de compromiso) sale del template. Teo lo pidió explícito: la sesión es agarrar el micrófono y hablar crudo, con muletillas, y cualquier cosa que haya que completar antes de hablar es fricción puesta en el momento en que el sistema no la tolera. Es el mismo principio que ya sostiene que titulo arranque vacío, aplicado al cuerpo.

Es el segundo campo declarado que sale de esta instancia, después de proposito en KX-S02, y las dos veces por el mismo motivo. Vale la pena leerlo como patrón y no como dos hechos sueltos: todo intento de que Teo declare de antemano de qué va a hablar terminó descartado.

La consecuencia hay que mirarla de frente. KX-S02 había dejado a conclusiva y a la cabecera de Intención como las dos únicas señales declaradas que tenía la destilación. Ahora queda una sola, conclusiva, un booleano. Todo lo demás se infiere del texto. Esta corrida (KX-S05) es evidencia de que se puede: la sesión tenía la cabecera vacía y aun así se destiló entera. Pero es una señal menos, y si la inferencia falla en alguna corrida futura, este es el lugar donde está anotado por qué.

KX-T50 había quedado reducida a una sola pregunta: si planificada entraba como campo propio o como cuarto valor de estado. Teo cortó por un lado que no era ninguna de las dos opciones evaluadas: no hay planificada, y de paso tampoco hace falta distinguir destilada de publicada. El campo pasa de tres valores a dos: sin-procesar y procesada.

Qué se descartó y por qué. El esquema de tres pasaba de estado en estado seguido de cerca por cada paso del flujo (dictar, destilar, publicar), pero ningún paso lo leía para nada: no hay una sola página que renderice este campo, la única consumidora real era la skill de destilación buscando estado: dictada (nombre viejo del campo) como gatillo. Publicación ya tenía su propia señal, independiente: si hrefTextual o hrefMapa están completos, está publicada. Mantener un tercer valor solo para eso era redundancia sin lector.

La consecuencia que hay que tener presente: "procesada" no distingue si además ya se implementó o se publicó. Esas dos cosas siguen pasando (son los pasos 4 a 7 del flujo, ver Mapa de Flujos.md), pero no las cuenta este campo. Si en algún momento hace falta filtrar por eso, la señal ya existe en otro lado: produjo (qué se creó) y hrefTextual/hrefMapa (si se publicó).

Mismo día, segunda vuelta. Teo lo pidió después de una pregunta suya sobre si el estado de esta instancia se comparte con el de las stream journals (no: esas usan estado_journal, un campo distinto en un sistema sin colección de página). El renombre saca la ambigüedad de raíz: estado a secas ya lo usan también kx-modulos, kx-piezas y kx-tareas, cada uno con un enum completamente distinto.

No hay riesgo técnico real (cada colección tiene su propio schema de Zod, y los frontmatter de archivos distintos no interfieren entre sí), pero sí hay riesgo humano y de proceso: la destilación lee varias colecciones a la vez y escribe en varias a la vez, y un nombre de campo genérico compartido entre esquemas con significados distintos es exactamente el tipo de cosa que se escribe mal en el archivo equivocado. Ver la convención general en Mapa de Convenciones.md.

Nota, no aplicada acá: kx-modulos, kx-piezas y kx-tareas siguen con estado a secas. La convención nueva es hacia adelante; renombrar esos tres es un cambio más grande, sin pedir todavía.

Se elimina el suggester de cuatro propósitos (explorar, decidir, especificar, descargar) y el campo proposito del frontmatter. Queda un template único.

Qué se descartó y por qué: la propuesta era usar proposito para rutear la destilación por criterio, y agregar un quinto valor implementar. Teo lo desestimó a favor de una sola sesión tratada siempre igual, con el doble HTML, decidiendo después dónde va el contenido según lo que el contenido sea.

La consecuencia hay que tenerla presente: sin proposito, el criterio de extracción se infiere del texto en vez de estar declarado. El campo conclusiva se mantiene como la única señal declarada de nivel de compromiso.

{AA.MM.DD} - kx autopoiesis session[ - {romano}], espejando el template de stream journals. El id KX-S{NN} se mantiene en el frontmatter porque es lo que citan los objetos en su campo origen, pero no está en el nombre del archivo.

Se consumen por destilación, no por relectura, y Claude lee el crudo perfectamente bien. La limpieza se vuelve un paso del pipeline de publicación, no del de captura.