cada categoría se dibuja según su driver ontológico
KX-S07, y es el criterio que le da forma a todas las vistas pendientes de esta área. Teo lo pidió en esos términos: las categorías del sistema no se diagraman todas igual, sino dependiendo del driver ontológico de esa categoría. Una tabla no es la forma correcta de mostrar un flujo, y un grafo no es la forma correcta de mostrar una enumeración cerrada.
| Categoría | Su driver | Forma que le corresponde | |---|---|---| | Módulos | pertenencia y madurez | tarjetas agrupadas por estado | | Piezas | tipo cruzado con módulo | tabla densa filtrable más matriz tipo × módulo | | Flujos | secuencia y actor | cursograma por carriles, uno por actor | | Instancias | etapa del ciclo de vida | matriz instancias × etapas | | Cuadrantes | partición del espacio | grilla de dos ejes | | Taxonomía | enumeración cerrada | listas de valores con su leyenda | | Stack e integraciones | dependencia funcional | tarjetas, con "¿se rompe un pipeline si lo saco?" respondido | | Tareas | quién puede desbloquearla | columnas por tipo, con los bloqueos como aristas | | System journals, jornadas, log | tiempo | timeline vertical | | El sistema entero | dependencia | grafo, con toggle actual / proyectado |
Lo que esto descarta: la vista genérica. La tentación de resolver diez categorías con un listado configurable y filtros distintos es real y sale más barata, pero borra justo la información que hace útil a cada vista. La matriz de instancias por etapas no es un listado con filtros, es otra cosa.
El detalle por página está en Plan de Hub Kx - Atlas y Autopoiesis.md §4 y §5.