Taxonomía

KX-S15. Cierra la colisión que estaba anotada en el #### Abierto de este archivo: kx-life (el proyecto de contenido) y kx-life-agent (la bóveda entera) se diferenciaban por un sufijo y se confundían al nombrarlas. La bóveda personal pasa a kx-innie y la corporativa a kx-outie. Con eso kx-life deja de tener con qué colisionar y no hay que renombrar el proyecto, que era la alternativa cara (tocaba rutas en todas las skills, todos los CLAUDE.md y los scripts de la página).

La veta es Severance, y ya estaba en el sistema sin haber sido adoptada como veta. innie y outie entraron el 26.07 como la rama de limpieza, y son las palabras del show, donde nombran la separación entre el yo que existe en el trabajo y el yo de afuera. El sistema tiene otras dos vetas activas (teoría de sistemas, de donde salió autopoiesis; y espacial, de donde salieron inner rim y outer rim), y esta ganó porque el show es exactamente sobre la relación entre estos dos agentes.

Lo importante de la decisión es el mapeo, porque había dos lecturas y son opuestas. Se evaluaron las dos:

| Lectura | Innie es | Estado |
|---|---|---|
| **La de estas skills, elegida** | Lo que se queda hacia adentro, para uno mismo. Entonces `kx-innie` es la bóveda personal y `kx-outie` la corporativa | **Elegida** |
| La canónica de Severance | El yo que solo existe adentro del trabajo. Entonces `kx-innie` habría sido la corporativa | Descartada |

Se eligió la del sistema por encima de la del show, y el argumento es de eje único. La lectura de Severance separa trabajo de no-trabajo; la de las skills separa privado de hacia-afuera. Si se adoptaba la del show, innie habría significado «trabajo» en la raíz del disco y «para uno mismo» en las skills: la misma palabra con dos ejes, que es exactamente lo que este archivo prohíbe. Con la lectura elegida, el eje es uno solo en todo el sistema: hacia adentro es para mí, hacia afuera es para otros. La bóveda personal es self-archivo; el agente corporativo produce para alguien más.

Se había propuesto aceptar la lectura del show anotando la ambigüedad como excepción razonada. La decisión de Teo la vuelve innecesaria, y eso es mejor que la propuesta: no hay excepción que mantener.

Estado: las referencias de adentro de la bóveda están actualizadas; el renombre de las dos carpetas madre queda pendiente de ejecución en Agentic System/renombrar-a-innie-outie.ps1. Windows bloquea la carpeta de trabajo de un proceso vivo, así que hay que correrlo con Obsidian y todas las sesiones de Claude Code cerradas. Mismo mecanismo y misma limitación que el renombre del 26.08.16.

Cierra KX-T38 en su parte de naming de los agentes, que venía parcialmente superada desde el 26.08.16.

KX-S15, paso 5. La regla de que los ids no se reusan nunca, ni cuando el objeto se depreca ya existía y aplicaba a KX-P{NN}, KX-T{NN} y compañía. Lo que se agrega es que también aplica a los slugs de módulo, que hasta hoy no habían tenido que probarlo porque ningún módulo se había deprecado.

Los dos casos: modulo-base (era kx atlas system) y system-factory (era kx system factory module) quedaron deprecado al fusionarse en el objeto nuevo sistema. Los archivos siguen en kx-modulos/ con fechaFin, y los slugs no vuelven a usarse para nada.

Una consecuencia que conviene ver, porque es el tipo de cosa que se olvida: un slug deprecado sigue apareciendo en el código. NIVEL_ARQUITECTURA_DE_MODULO de lib/kx.ts mapea los tres (sistema, modulo-base, system-factory) a la misma capa, y el hub los filtra a mano. No es un olvido: los objetos deprecados se muestran, así que las vistas los tienen que poder ubicar. Pero significa que deprecar un slug no lo saca del código, solo lo saca del futuro.

Vale registrarlo porque es una ambigüedad vieja que la fusión terminó de exponer. modulo-base era el slug del objeto del Atlas, heredado de cuando el módulo raíz se llamaba kx core module y su documento publicado se llamaba «Módulo Base». Ya en el 26.07.26 se había anotado que eran dos cosas y que conviene no mezclarlas.

Después de la fusión quedan así, y las dos siguen existiendo:

| Qué | Es | Dónde |
|---|---|---|
| El slug `modulo-base` | Un objeto de módulo **deprecado** | `kx-modulos/modulo-base.md` |
| El documento «Módulo Base» | Contenido escrito, vivo, publicado como par textual y mapa | `/kx/modulo-base/`, más `kx-documentos/kx-d01` |

Y los dos Modulo Base - ....md de la bóveda son la fuente de ese documento, no del objeto: viven en 02 - diseño/contexto-origen/ desde el 26.08.17.

KX-S14. Esto revierte una decisión del 26.08.01, y conviene que se lea como reversión y no como novedad. Esa decisión decía: «kx-tareas con estado y tipo ya cubre los tres cajones que Teo pensaba como separados: activos son abierta, cerrados son cerrada, e ideas son las de tipo pensar sin prioridad. Dos listas de pendientes es el patrón que mata backlogs.»

El argumento era bueno y el mecanismo nunca funcionó. Teo lo reportó así: «el sistema solo entendía de tareas y decisiones», y por eso «no podía introducir ideas al sistema». Peor todavía, tenía un efecto que nadie previó: si dictaba un system journal, quedaba obligado a implementarlo en ese momento, porque no había dónde dejar algo dicho sin que se volviera pendiente.

Qué falló, concretamente. pensar sin prioridad no es una idea: es una tarea cuyo alcance no está claro, que es otra cosa. Y aunque el casillero hubiera servido, seguía compartiendo tablero con lo pendiente, así que la idea se leía como deuda cada vez que se miraba el backlog.

El riesgo que la decisión original quería evitar sigue en pie y no se resolvió, se aceptó: dos listas pueden terminar en que ninguna sea confiable. Lo que lo hace tolerable ahora es que las dos listas tienen ciclos de vida distintos de verdad (estado_idea no se parece a estado), no son la misma cosa partida en dos por comodidad. Si en tres meses las ideas están llenas de cosas que en realidad eran tareas, esta es la entrada a revisar.

KX-S14. Las tareas suman escala: proyecto o tarea. El motivo es que el tablero ponía a la misma altura diseñar una página entera y ajustarle el contexto a una skill, y Teo lo describió como abrumador, que es el síntoma de un backlog que dejó de servir.

Es perpendicular a tipo y las dos preguntas son distintas. tipo contesta quién puede desbloquearla; escala contesta si hay energía para agarrarla hoy. Teo describió el uso exacto: entre semana, con poca energía, las cosas chiquitas; el fin de semana, agarrar algo nuevo.

Se descartó una escala de tres (proyecto, implementación, tarea), que era lo que el dictado sugería con «dos o tres capas». El nivel del medio no tiene criterio de corte propio y es donde se acumulan los ítems que nadie quiere clasificar. El uso real que Teo describe es binario, así que la escala lo es.

El campo es opcional a propósito: lo cerrado no necesita la distinción, y obligarlo habría significado clasificar dieciocho tareas ya resueltas para nada.

Cuarto prefijo de instancia del sistema, junto a KX-S{NN} (system journal), KX-I{NN} (jornada de implementación) y los de pieza y tarea. Correlativo global, en el frontmatter, no en el nombre del archivo: mismo mecanismo que los otros tres.

Se registra porque la letra elegida es lo primero que se va a querer cambiar y conviene tener anotado que se miró. C de context, y estaba libre: las letras tomadas eran S, I, M, P, T y F. La alternativa era KX-X{NN} para no comprometer la letra buena, y se descartó por lo de siempre, que un id opaco se paga en cada lectura.

activo significa en producción y en uso de verdad, pero todavía en calibración, con cosas por agregar. finalizado significa estable, sin nada pendiente.

La distinción importa porque casi todo el sistema está en activo y muy poco en finalizado, y colapsarlos haría que el dashboard mienta en la dirección optimista, que es la peor.

Un input dictado tan corto o cortado que no se entiende no es una tarea todavía: es una cita cruda esperando triage. Tener un tipo para eso evita las dos salidas malas: inventar qué quiso decir, o descartarlo.

No por tamaño ni por dificultad. La pregunta útil cuando se mira el backlog un sábado es quién puede mover cada cosa, y eso habilita el dato accionable: cuántas decisiones de Teo están bloqueando cuántas tareas de construcción.

Ver Mapa de Capas.md para el razonamiento completo. Se registra acá porque es una decisión de vocabulario y este es su lugar canónico.

Los cuatro valores (explorar, decidir, especificar, descargar) salen del sistema. Ver Mapa de Instancias.md para el porqué y la consecuencia.