Página

KX-S09, y es el primer trabajo del sistema sobre el sitio público y no sobre /kx/. La premisa no es un bug: la página de ensayos existe, funciona y está deployada, y Teo no la quiere mostrar. Enumeró lo concreto que le molesta (márgenes grandes que dejan la columna chica, la línea horizontal bajo cada heading, los números romanos antes de cada subtítulo, la barra lateral de secciones que corrió el documento a la izquierda, la home plana sin series) y pidió explícitamente no reeditar lo existente sino explorar.

Nueve prototipos, tres familias de tres: lectura de ensayo libre, lectura de ensayo académico, y home. Se descartó rediseñar directo la página buena, que es exactamente el método que produjo la página que ahora no le gusta. El plan completo, con qué explora cada uno de los nueve, está en 02 - diseño/planes y reencuadre/Plan de Rediseño - Pagina de Ensayos.md (KX-T67).

Lo que existe se congela, no se archiva. /essays/ y /essays/{slug}/ quedan intactas y funcionando; los prototipos viven en rutas nuevas bajo /essays/prototipos/. Se descartó archivar a _archive/, que es lo que se hizo con las vistas viejas de /kx/ el 26.08.02: ahí el reemplazo ya estaba verificado en pantalla, que era la condición, y acá todavía no existe.

La dirección estética es la de quotes.astro y linguistic-treats.astro (más glow, más moderno, mismo fondo de papel), como referencia direccional y no como plantilla. Teo lo aclaró textual: no quiere que se copie de eso, quiere que los prototipos sepan hacia qué lado va.

Tres reglas quedan fijas en los nueve, y salen de las molestias concretas: sin línea horizontal bajo los headings, sin números romanos manuales (si hay que numerar lo hace la página, no el markdown), y ninguna columna lateral fija que corra el cuerpo del texto. La tipografía, que Teo también pidió rever, se explora solo en el tercero de cada familia: si las nueve páginas cambian de fuente, no se sabe qué se está mirando.

KX-S09, y sale de revisar las dos páginas que Teo puso como referencia. Lo que quotes.astro y linguistic-treats.astro tienen y la página de ensayos no, además del glow, es modo oscuro con toggle propio: paleta --dqd-* en quotes, 64 reglas theme-dark en linguistic treats. Las dos páginas de ensayos no tienen una sola línea de tema oscuro.

El argumento es de oportunidad y ya se pisó una vez: el 26.07.26 las páginas de área de /kx/ se rompieron en cualquier navegador con tema oscuro del sistema, porque el modo oscuro colgaba de prefers-color-scheme en vez de un toggle que gane en las dos direcciones. Es la misma regla que fijó KX-P22 para /kx/, aplicada ahora al sitio público. Agregarlo sobre nueve páginas ya escritas obliga a repasar las nueve; meterlo en el prototipo cuesta poco.

Se descartó construirlo solo sobre el ganador de cada familia: obliga a elegir el diseño sin ver cómo se comporta en oscuro, que es justo lo que los prototipos existen para evitar.

Hallazgo de la misma revisión, que el rediseño puede aprovechar: el glow de esas páginas vive en el text-shadow del contenido al hacer hover, no en sombras de caja, y cada página tiene su propio hue de acento (verde en quotes, violeta en linguistic treats). Eso abre la posibilidad de que cada serie de ensayos tenga el suyo, y que el agrupamiento se lea sin depender de un título.

KX-S09. Teo planteó abierto cómo presentar un ensayo de 19.000 palabras y las tesis con índice, con la preocupación de que son PDFs de veinte páginas «muy pesados» para cargar en cada página.

La corrección de premisa es la decisión: el peso que preocupa es de PDF, no de texto. 19.000 palabras de HTML son livianas. Entonces el ensayo largo se lee entero en la página, con índice navegable, y el PDF existe como descarga para imprimir o citar (KX-T71).

Se descartaron las dos alternativas: partirlo en una ruta por capítulo (más libro web que ensayo, y rompe el buscar en página) y la ficha con el PDF como documento real (lo más liviano de construir y lo menos legible en celular, que es donde más se lee).

KX-S09. Teo quiere que la home se subdivida «por series, en el sentido de la serialización», porque tiene tipos distintos y no le convence que estén todos juntos. Las tres son las que el dictado nombra, y calzan 1:1 con las dos familias de lectura más cine como caso propio (es el único que pide fotos intercaladas). Entra como campo serie en el schema de essays (KX-T70).

Se descartó agrupar por tema en vez de por formato (economía, cine, sistemas): desacopla cómo se lee de sobre qué es, que suena más limpio, pero deja la home sin ninguna relación con las páginas de lectura.

Lo que las series no resuelven todavía es si una sección navega a su propia página o contiene los ensayos ahí mismo. Teo dijo textual que no lo sabe, y los prototipos C1 y C2 son literalmente las dos ramas de esa duda, más un C3 que él no planteó.

KX-S09. La página de ensayos tiene toda la interfaz en inglés mientras el contenido de Teo está mayormente en castellano. Se mantiene el inglés en los prototipos, por consistencia con el resto del sitio público (quotes, linguistic treats, notes) y porque migrar de idioma es una decisión de sitio entero: meterla adentro de esta corrida contamina la comparación de los nueve prototipos con una variable que no es de diseño.

Queda anotado como cabo suelto, no como decisión cerrada hacia adelante.

KX-S07, segunda vuelta. Corrige el plan del día anterior, que había planificado las páginas del Atlas por tipo de objeto (módulos, piezas, flujos, instancias...). Teo pidió otra cosa, y es mejor: una página por archivo de 00 - matriz/, once en total, espejo 1:1 de la bóveda. Si algo está en Mapa de X.md, está en /kx/sistema/matriz/x/, y no hay ninguna ambigüedad sobre dónde vive qué.

Lo que se descartó: la organización por tipo de objeto, que seguía la forma de las colecciones en vez de la de la Matriz y obligaba a explicar por qué una skill vivía en "piezas" y no en "skills". /kx/sistema/matriz/piezas/ sobrevive, pero como vista transversal, no como columna principal: es el corte que cruza los cinco tipos de una vez.

La consecuencia de fondo: cada área muestra su inventario agrupado por estado (idea, diseñado, construyendo, activo, finalizado), aunque tenga dos objetos. Ver el hueco es el punto, y con pocos ítems se ve mejor que con muchos.

KX-T62, cerrada. Teo lo venía pidiendo desde KX-S06: que las skills dejen la página actualizada al terminar. Al ir a implementarlo apareció que el problema no era el que se había planteado.

Lo planteado era que las skills escribieran HTML. Pero las páginas ya son proyecciones de las colecciones, y las skills ya escriben las colecciones. El hueco real estaba en otro lado: las tres colecciones generadas (kx-eventos, kx-areas, kx-jornadas) se derivan de la bóveda, y las skills escribían la fuente sin correr nunca los generadores. Resultado: la página mostraba el estado viejo aunque la bóveda estuviera perfecta.

Se resolvió en dos capas, y la segunda es la que lo hace confiable:

1. La instrucción: las dos skills tienen ahora un paso explícito de sincronizar. 2. El mecanismo: prebuild encadena los tres generadores, así que un npm run build alcanza. La instrucción puede olvidarse; el hook no.

Para que la capa 2 fuera posible hubo que cambiar los generadores de fallar a saltear con aviso cuando no encuentran la bóveda. El deploy de GitHub Actions clona solo el repo de la página, así que un prebuild que exige la bóveda rompía el deploy. Ahora en CI saltean y se usan los archivos commiteados, que es lo correcto. Verificado simulando CI sin bóveda.

La regla que queda: correr el build siempre que la corrida haya tocado la bóveda, aunque no se haya tocado una línea de hyperlynkx-page. Escribir en el patch notes o en un archivo de la Matriz es un cambio de la página.

Teo pidió que toda la información del Atlas esté en las páginas, condensada. El problema conocido: la prosa vive en la bóveda, que no está en el repo del sitio. Se resuelve con el mismo patrón que ya funcionó para el patch notes: un script parsea los once Mapa de X.md y genera la colección kx-areas (npm run gen:areas). El markdown de la bóveda sigue siendo la fuente; la colección es un espejo commiteado que se regenera a pedido.

Qué extrae y qué no, y esto importa: extrae las secciones de prosa del molde (qué es esta área, convenciones, decisiones fechadas, abierto, inventario) y no extrae las entradas ##### de cada ítem. Esas vienen de las colecciones kx-* como tarjetas. Es la regla de dirección aplicada a la página: el archivo de la Matriz da el porqué, la colección da el qué, y ninguna de las dos repite a la otra.

Se descartaron las dos alternativas: dejar la prosa solo en Obsidian (que es justo lo que Teo quiere dejar de necesitar) y condensarla a mano (que se desincroniza apenas se edite un Mapa de X).

KX-S08. Teo corrigió que su nombre creativo es hyperlynkx, no interlynkx: lo segundo se usó en este sistema por error de dictado. La corrección aplica hacia adelante (en la bóveda, y en el nombre del repo nuevo publicado el mismo día, ver la entrada siguiente). No se renombra nada existente todavía: ni la carpeta local hyperlynkx-page, ni el repo viejo astro-project-v2. Pedido explícito de Teo: no tocar el proyecto ya armado.

Cabo suelto anotado, sin resolver: la cuenta de GitHub ya autenticada en este entorno se llama hyperlynxt (con t), no hyperlynkx (con k). Puede ser una elección deliberada (variante disponible) o el mismo error de dictado propagado a otra plataforma. No se tocó porque cambiar el username de una cuenta ya en uso excede lo pedido en esta sesión.

KX-S08. El repo que vivía como hyperlynxt/astro-project-v2 nunca perdió la identidad del starter de Astro del que salió (nombre faithful-fireball en package.json, README sin tocar): era, literalmente, la copia de un template, aunque cargaba la app real con toda su historia. Teo pidió empezar de cero: un repo nuevo, sin cambiar código, guiado paso a paso.

Se creó hyperlynxt/hyperlynkx-page (público, deploy por GitHub Actions a Pages, mismo workflow static.yml que ya existía). El remote origin local pasa a apuntar ahí; el repo viejo queda de respaldo bajo el remote astro-project-v2-old, sin tocarse (ni archivar ni borrar, decisión explícita de Teo).

El único cambio impuesto por el nombre nuevo es el base path de Astro, porque GitHub Pages sirve cada proyecto bajo /nombre-del-repo/: sin actualizarlo, todos los assets y links internos habrían dado 404. Resultó ser más que las dos líneas de astro.config.mjs que se estimó al principio: el base path estaba además hardcodeado como string literal en unos 39 archivos de src/ (páginas, layouts, y los campos hrefTextual/hrefMapa/ruta de varias colecciones), en vez de leerse de una sola fuente. Se corrigió con un reemplazo mecánico del string exacto en los ~89 usos, verificado uno por uno que todos eran el mismo base path y ninguno otra cosa. Build local limpio (40 páginas, igual que antes del cambio) y deploy verificado en producción: https://hyperlynxt.github.io/proyectos/hyperlynkx-page/ responde 200 en la raíz y en /kx/.

Se descartó mantener el nombre astro-project-v2 en el repo nuevo (que hubiera evitado tocar cualquier código): no resolvía el problema real, que el nombre del repo no significa nada.

Abierto de esta decisión: el patrón de hardcodear el base path como string repetido en cada archivo, en vez de una constante importada, queda anotado como fragilidad real del proyecto, no corregido acá (excede el pedido de esta sesión, que era publicar sin tocar la arquitectura).

KX-S07. /kx/ deja de ser un puñado de vistas sueltas y pasa a ser una constelación de dos áreas: Atlas (/kx/sistema/, ver el sistema) y autopoiesis (/kx/autopoiesis/, cambiarlo). Veintiuna rutas en total, planificadas de una vez en Plan de Hub Kx - Atlas y Autopoiesis.md, que reemplaza al Plan de Hub - Puerta de Entrada del Kx System.md del 26.07.26 (aquel diseñaba una sola página, y su hallazgo central, que lo que hacía falta era una página por área, queda absorbido).

Cuatro cosas se decidieron antes de escribir el plan, y se descartaron sus alternativas:

• /kx/ sigue siendo la raíz, con las dos áreas anidadas adentro. Se descartó una raíz nueva con /kx/ archivado, y también dejar las rutas planas agrupándolas solo en la navegación: si la estructura no está en la ruta, no está.
• Reemplazo total de las siete páginas actuales, que van a _archive/ una vez que su reemplazo esté verificado en pantalla. Se descartó la absorción parcial, y se descartó que las dos estéticas convivan, que era exactamente el problema anotado en Abierto desde el 26.07.26.
• El plan puede proponer colecciones y campos nuevos (kx-jornadas, kx-eventos, kx-instancias, el campo area en tareas), marcados como prerequisito de la página que los necesita. Se descartó limitarse a las nueve colecciones cargadas, que dejaba media constelación sin diseñar. La aprobación de cada una sigue siendo de Teo (KX-T61).
• Se planifica todo antes de escribir una línea de HTML. El plan define pantallas, secciones, datos y componentes; el código lo escribe otro agente después. Pedido explícito de Teo.

La relación entre las dos áreas es asimétrica a propósito, y espeja la que el sistema ya tiene: autopoiesis linkea al Atlas siempre (todo id que aparezca en un evento, tarea, sesión o ciclo es un link a la ficha del objeto), y el Atlas linkea a autopoiesis solo en el bloque de historia al pie de cada ficha. Ese bloque es lo que hace que la integración sea real en vez de dos sitios pegados: contesta "de dónde salió esto" sin que Teo tenga que acordarse.

KX-S07. La unificación del chrome deja de ser un pendiente de higiene y pasa a ser la etapa 0 del plan: nada se construye antes. Sale como pieza propia (KX-P22, en estado disenado) y como tarea (KX-T58).

El argumento es de oportunidad, no de prolijidad: si igual se reescriben las siete páginas, este es el único momento en que centralizar sale gratis. Y el modo oscuro, que estaba anotado acá abajo como imposible, deja de serlo por la misma razón.

Dos detalles que la decisión fija y que no son negociables al implementar. El toggle de tema gana sobre prefers-color-scheme en las dos direcciones: atarlo solo a la preferencia del sistema es lo que rompió el contraste el 26.07.26. Y cada taxonomía tiene su rampa de color propia, sin compartir hues entre taxonomías distintas, porque el mismo verde significando dos cosas es peor que no tener color.

La dirección estética la fijó Teo: técnico y denso en datos como un dashboard de diseño de sistemas, no sobreestetizado. Cero emojis, regla dura: donde iría un emoji va una pastilla de color con su texto.

Decisión estructural, tomada en el plan anterior y confirmada. La alternativa (el dashboard como página editada a mano) se descartó porque rompe la portabilidad del núcleo y convierte cada cambio de estado en una tarea de edición.

El hub viejo (fondo de textura de papel, parchment, tarjetas oscuras) se archiva en src/pages/_archive/kx-hub-old-source/ y se reemplaza por un diseño nuevo: fondo blanco limpio (sin la textura), tarjetas redondeadas con glow de color al hover, acento teal como color primario y cuatro pastel (teal, ámbar, coral, lavanda) cíclicos en las tarjetas de área. Dirección tomada de quotes.astro y linguistic-treats.astro, que ya tenían esta identidad visual para el contenido público del sitio.

Alcance: hub y páginas de área. Extendido el mismo día: KxBase.astro (que usaban las páginas de área) tenía tokens de modo oscuro atados a prefers-color-scheme que, sumados a la textura de papel, rompían el contraste en cualquier navegador con tema oscuro del sistema (tarjetas casi negras, texto ilegible). Reportado por Teo con una captura real. En vez de parchear el bug, areas/[area].astro y areas/index.astro se reescribieron con la estética fresca, igual que el hub. sistema.astro, tareas.astro, anatomia.astro, y los documentos publicados (modulo-base, kx-core) siguen con el estilo anterior: rediseñarlos todos junto hubiera sido demasiado para poder verificar bien cada uno.

El hub /kx/ era la última página del sistema que enumeraba a mano, y ya estaba desincronizada: mostraba cuatro módulos escritos en JSX contra seis reales en la colección. Pasa a ser una proyección, y la regla de la prosa que no enuncia inventario deja de tener excepciones.

Con eso, el orden del hub se invierte: primero retomar (dónde quedé), después bloqueos, y al final navegar. Navegar era lo único que hacía, y es la pregunta menos frecuente.

Plan completo en Plan de Hub - Puerta de Entrada del Kx System.md.

El campo href de kx-modulos es singular y el core module ya tiene dos documentos publicados, cada uno con su par textual y mapa. Se decide una colección kx-documentos con hrefTextual y hrefMapa, y sacar href de kx-modulos.

Se descartó la alternativa (un array de hrefs en el módulo) porque un documento tiene metadata propia (estado, fecha, sesión de origen) que no cabe en un string, y porque es lo que publicar-modulo-kx tendría que escribir.

Para el árbol de carpetas (ver Mapa de Mapas.md): el sitio se buildea en GitHub Actions desde el repo de la página, donde la bóveda no existe. Un fs.readdir funciona local y explota en CI. Un JSON generado a pedido y commiteado funciona en los dos lados, y de paso da diffs de git sobre la forma del sistema.