Mientras trabajábamos, un método apareció

El 15 de septiembre de 2026, a las 09:44:59 de Madrid, fue creado en Drive el documento que hoy gobierna el método de proyectos de Mori. Cuatro segundos después apareció el registro central. El primer proyecto formal de esa etapa consigna su apertura a las 09:50.

Las marcas horarias ofrecen una imagen casi demasiado perfecta: primero un modo de trabajar, después un lugar donde recordar el trabajo y, apenas unos minutos más tarde, el trabajo mismo. La realidad había seguido el orden inverso. El método llegó porque ya estábamos haciendo cosas que podían durar más que una conversación, atravesar varias autorizaciones, desviarse hacia una incidencia y regresar días después bajo la mirada de otra instancia de inteligencia artificial.

No hubo un retiro previo para diseñar una doctrina. Había un estándar que había crecido hasta dificultar su propia lectura, nueve playbooks que mezclaban instrucciones vigentes con historia, un catálogo de respaldos todavía en desarrollo y una infraestructura cuya continuidad comenzaba a importar. Para intervenir sin perder el hilo necesitábamos responder preguntas más sencillas y más exigentes: ¿qué estamos intentando conseguir?, ¿dónde nos detuvimos?, ¿qué fue autorizado?, ¿qué llegó a ejecutarse?, ¿qué se verificó?, ¿qué falta y quién puede decidirlo?

Las respuestas fueron dejando una forma. Mientras trabajábamos, un método apareció.

Una partitura escrita después de empezar

El primer proyecto fue la reorganización del estándar CLI-first. Su fuente ocupaba 93.375 bytes y reunía 19 secciones y 56 subsecciones. Conservaba normas, procedimientos, antecedentes y un changelog cada vez más difícil de recorrer. El objetivo exigía reducir aquel volumen sin extraviar una sola unidad de conocimiento útil.

Ese trabajo ya contenía, en miniatura, varias reglas que después reconoceríamos como propias. El proyecto recibió un identificador estable. Se dividió en fases definidas por resultados. Antes de retirar contenido se creó un punto de recuperación. Los destinos nuevos se construyeron y leyeron de regreso. La reducción se aceptó únicamente después de reconciliar las 75 unidades inventariadas. Al cerrar, el estándar conservaba su identidad, había bajado de 93.375 a 21.324 bytes y toda pieza retirada tenía un destino comprobado.

El mismo día, la normalización de los playbooks aplicó esa disciplina a 764 kilobytes y casi catorce mil líneas de documentación operativa. Siete documentos fueron promovidos conservando sus IDs; dos quedaron intactos porque intervenirlos habría mezclado un cierre documental con desarrollos todavía abiertos. La infraestructura no cambió. El resultado fue una separación más clara entre procedimiento estable, historia, arquitectura y trabajo en curso.

Aquellos proyectos no demostraron que el método estuviera terminado. Demostraron que podía ayudar a terminar algo sin confundir movimiento con conclusión. Ejecutar una fase adquirió un significado distinto de cerrarla. Preparar un cambio dejó de equivaler a aplicarlo. Un código de salida dejó de bastar cuando la pregunta real exigía comprobar identidad, contenido o estado persistido.

La partitura fue escribiéndose después de que la música hubiera empezado. Cada compás intentaba conservar lo que acabábamos de aprender para que la siguiente sesión pudiera entrar a tiempo.

El presente necesitaba una dirección

Una conversación contiene matices, decisiones y memoria reciente. También termina. Una instancia futura puede recibir un resumen, una selección incompleta o ninguna parte del razonamiento que produjo el último paso. La continuidad de Mori no podía descansar en la esperanza de que la próxima inteligencia recordara correctamente lo ocurrido.

El registro central asumió entonces un oficio preciso: localizar cada proyecto, mostrar su estado, señalar sus relaciones y conducir hacia la próxima acción. El documento principal de cada proyecto conservó el presente completo. El registro orienta; el principal gobierna. Esa división evita que un panel resumido adquiera autoridad sobre aquello que sólo puede explicar en pocas palabras.

Los identificadores P-AAAAMMDD-nombre-breve dieron continuidad a trabajos cuyo nombre visible, ubicación o forma documental podían cambiar. Las fases empezaron a describir resultados lógicos, precondiciones, criterios de finalización y evidencia esperada. Las solicitudes de autorización tuvieron que mencionar el proyecto, el número y el título completo de la fase, además de la acción concreta. Así, L’Architetto podía decidir sin reconstruir primero qué significaba una F3 aislada entre muchas otras.

También apareció una regla que parece obvia únicamente después de formularla: el estado vigente debe poder leerse sin reconstruirlo desde la cronología. Las pruebas, errores y alternativas merecen conservarse, pero ninguna debería competir con la respuesta a «¿dónde estamos ahora?». El proyecto guarda su memoria viva; los playbooks reciben, al cierre, sólo el conocimiento estable que sobrevivió a la intervención.

Con el tiempo, esa separación alcanzó otras autoridades. El registro de tareas mantuvo el estado de las tareas; los principales, sus fases y autorizaciones; la bitácora, los hechos materiales de mantenimiento; los playbooks, los procedimientos reutilizables; Drive, los originales vivos; Forgejo, los cortes versionados publicados de manera expresa. Recordar empezó a incluir una segunda disciplina: saber dónde debe vivir cada recuerdo.

La primera forma también se quedó pequeña

El método inicial asignaba un único archivo Markdown a cada proyecto. Para trabajos breves era una solución legible y suficiente. Backup Catalog mostró su límite.

Su principal llegó a 245.876 caracteres y 1.632 líneas lógicas. El diario de ejecución ocupaba la mayor parte, mientras el punto de reanudación cabía en 828 caracteres. Aun así, la próxima acción dependía de auxiliares, autorizaciones y prevalidaciones dispersas entre la historia. La información seguía allí; encontrar el presente comenzaba a exigir la lectura de casi todo el pasado.

El proyecto abierto para resolver ese problema decidió probar antes de reformar. El primer piloto preservó íntegramente 260.737 bytes y permitió reconstruirlos. También fracasó en la prueba decisiva: reanudar seguía exigiendo abrir el original completo. Habíamos demostrado conservación, pero no orientación.

Un segundo piloto separó una cápsula de estado, piezas responsables, diario, recibos y artefactos. Un proceso nuevo, sin el contexto de la conversación que lo había preparado, pudo recorrer registro, principal y dos piezas requeridas: cuatro documentos y 95.582 bytes bastaron para identificar fase, próxima acción, permiso vigente, límites y evidencia. La historia completa siguió siendo reconstruible a partir de 161 unidades y 249.501 bytes.

De esa comparación surgió el modelo híbrido adoptado el 19 de septiembre. Los proyectos simples conservan un archivo único. Un trabajo complejo puede convertirse en expediente cuando una dificultad comprobada de reanudación, integridad o autoridad lo justifica. El tamaño, la cantidad de fases o la preferencia estética no deciden por sí solos. La inteligencia colaboradora debe detectar el problema y proponer; L’Architetto decide y autoriza la transición.

La cápsula tampoco sustituyó a la historia. Le dio al presente una dirección estable y dejó que el pasado siguiera cumpliendo otra función.

Un desvío tenía que saber regresar

Los problemas importantes rara vez avanzan en línea recta. Una fase descubre una dependencia, una verificación abre una incidencia y una reparación termina necesitando su propio conjunto de decisiones. Antes del método, un desvío podía absorber la conversación y dejar el objetivo original reducido a una referencia lejana.

El contrato de retorno apareció para impedir esa desaparición. Cuando una incidencia merece convertirse en proyecto hijo, ambos documentos conservan la relación. El hijo declara de dónde nació, qué condición permitirá regresar, qué resultado entregará y cuál será la acción exacta al volver. El padre mantiene visible la fase detenida y aquello que espera recibir.

El plan maestro convirtió esta regla en una estructura real. De él nacieron el laboratorio compartido, la actualización de seguridad de GLPI, la recuperación verificable de servicios y DAO. Algunos hijos terminaron y devolvieron evidencia; otros quedaron pausados; uno descubrió dentro de sí un problema con identidad suficiente para abrir otro proyecto. En cada caso, el parentesco servía para conservar continuidad, no para heredar autorizaciones.

El propio plan maestro comprobó que planificar tampoco significa adivinar el futuro. Después de completar sus primeras fases, reorganizó las siguientes según lo aprendido: separó prerrequisitos de migración, capacidades portables, trabajo transitorio de Cerberon y decisiones todavía condicionadas a nodos futuros. Conservó el mismo ID, sus contratos y el lugar de reanudación mientras cambiaban la representación documental y la planificación.

Una metodología rígida habría tratado aquella diferencia como desviación. El método de Mori la registró como elaboración progresiva: el presente podía corregir el futuro sin fingir que siempre lo había conocido.

El mapa aprendió a no proclamarse territorio

Cuando proyectos, tareas y consejos empezaron a multiplicarse, apareció Mori’s Work Hub. Reunirlos en una sola vista resolvía una necesidad cotidiana: entrar al trabajo sin consultar primero varios registros extensos.

La centralización produjo una nueva tentación. Una vista cómoda podía terminar compitiendo con las fuentes que resumía. El diseño eligió otra relación: el panel cuenta, enlaza y señala; cada registro conserva sus campos; cada proyecto conserva su estado; cada playbook conserva su procedimiento. Una proyección desactualizada requiere reconciliación, jamás una elección oportunista de la versión más conveniente.

Esta frontera se volvió especialmente importante cuando varias inteligencias, conversaciones y automatizaciones comenzaron a leer el mismo trabajo. Un punto de entrada resulta valioso porque reduce la búsqueda. Su utilidad depende de reconocer que el resumen deriva de otras autoridades y puede necesitar ser actualizado.

El método había empezado para que un proyecto no se perdiera entre conversaciones. Poco después tuvo que aprender a impedir que sus propios mapas fabricaran presentes alternativos.

La prudencia encontró su medida

Durante sus primeras semanas, el método creció sobre todo mediante la incorporación de garantías. Un fallo pedía una nueva comprobación; una carrera, una revalidación; una operación irrepetible, una identidad de ejecución y una protección contra la repetición; una escritura documental, lectura de retorno y conservación de la base anterior.

Ese movimiento protegió cambios importantes. También acumuló suficiente maquinaria como para que una lectura inocua pudiera heredar planes, paquetes, hashes, recibos y arneses concebidos para operaciones irreversibles. En DAO, el aparato de control llegó a convertirse en una fuente visible de fallos y carga de reanudación.

La decisión D-0024 clasificó entonces el trabajo según impacto, irreversibilidad, privilegio, sensibilidad e incertidumbre. Una lectura acotada puede emplear un bloque directo y saneado. Un cambio reversible de bajo riesgo conserva precondiciones, comprobación y recuperación proporcionadas. Los efectos materiales requieren plan, autorización y readback. Las operaciones destructivas, no idempotentes o difíciles de recuperar mantienen sus garantías duras.

El ensayo PRE/POST preparado para medir esa corrección conservó una limitación importante: el PRE exacto no pudo recuperarse, de modo que nunca existió una comparación completa ni un veredicto universal. La proporcionalidad pasó después a las normas transversales mediante una decisión humana separada, apoyada en la experiencia acumulada y con las garantías críticas intactas.

El episodio, desarrollado con mayor detalle en el relato de las manos y del taller que faltaba, corrigió una tendencia del propio método. La prudencia también necesita diseño. Un control aporta valor cuando reduce un riesgo real sin crear una estructura más frágil que el efecto que intenta proteger.

Los parentescos que vimos después

Al mirar retrospectivamente, la forma adquirida por Mori recuerda a metodologías conocidas. Sus fases y puertas encuentran parentesco con Stage-Gate; el gobierno por etapas y la autorización, con PRINCE2; la revisión progresiva del plan, con PMI; la observabilidad, la reversión y la evidencia, con prácticas SRE y DevOps.

La semejanza apareció después de resolver problemas concretos. Ningún marco fue escogido como plantilla inicial. La cápsula única de estado, el contrato de retorno entre proyectos, la separación entre memoria viva y conocimiento estable y el cierre condicionado a evidencia respondieron a dificultades encontradas aquí: sesiones discontinuas, inteligencias distintas, infraestructura real y una autoridad humana que debía conservar decisión y soberanía.

Esa procedencia aconseja modestia. Mori posee un método vigente, capaz de gobernar trabajo real y de corregirse. Su forma seguirá cambiando cuando nuevos proyectos revelen límites mejores que nuestras previsiones. La revisión forma parte de su estabilidad: las reglas conservan identidad, autoridad e historia mientras su diseño aprende.

Una institución mínima para poder continuar

Una herramienta ayuda a completar una acción. Un método empieza a adquirir carácter institucional cuando también obliga a distinguir lo permitido de lo preparado, el resultado de la intención, la evidencia de la memoria y el presente de su historia.

En Mori, esa institución sigue siendo deliberadamente limitada. El método no decide prioridades, no concede autorizaciones y no convierte capacidad técnica en autoridad. L’Architetto conserva esas decisiones. La inteligencia colaboradora investiga, propone, contrasta, ejecuta dentro del alcance concedido y documenta. El proyecto preserva el punto desde el cual otra sesión podrá revisar esas conclusiones en lugar de heredarlas como fe.

La limitación funciona aquí como arquitectura. Hace posible delegar trabajo sin delegar soberanía, aceptar una pausa sin llamarla abandono y abrir un proyecto hijo sin permitir que borre la razón por la que nació. También obliga a reconocer cuándo el procedimiento añadido deja de proteger y empieza a crear deuda de diseño.

El método todavía no ha alcanzado una forma final. Su valor puede medirse mejor en aquello que ya consiguió sostener.

Veintiséis formas de continuar

Al escribir esta entrada, la revisión vigente del registro central es 2026-10-09.r10. Desde la adopción del trabajo por proyectos, el registro ha dado identidad a veintiséis iniciativas. Nueve llegaron a cierre verificado. Tres están activas. Una se encuentra bloqueada por una autorización pendiente. Tres comenzaron y permanecen pausadas por una decisión explícita. Diez poseen alcance y próxima acción, aunque su ejecución todavía no ha empezado. Ningún proyecto figura como descartado.

Nueve proyectos finalizados

• Reorganización del estándar CLI-first: redujo y redistribuyó el estándar preservando las 75 unidades inventariadas.
• Normalización de playbooks operativos: separó verdad vigente, historia y arquitectura en los documentos responsables.
• Actualización de documents en Forgejo desde Drive: publicó y verificó un corte de 51 documentos sin convertir Forgejo en editor cotidiano.
• Reestructuración del modelo documental de proyectos: probó el modelo híbrido, adoptó la cápsula de estado y cerró sin imponer migraciones masivas.
• Reconciliación de autoridad documental: corrigió la deriva entre un original canónico y una copia más reciente, y dejó una puerta general contra futuras sustituciones silenciosas.
• Fichas de recuperación de Authentik, NPM y DNS: consolidó procedimientos y arquitectura de recuperación sin presentar fichas como restauraciones reales.
• Actualización de seguridad de GLPI 11.0.8 a 11.0.9: ensayó recuperación, actualizó y obtuvo verificación automática y humana.
• Continuidad y consolidación del núcleo de Backup Catalog: produjo el corte R7, atravesó pruebas de recuperación y devolvió sus resultados al plan maestro.
• Respaldo local y recuperación verificada de Forgejo y Backup Catalog: comprobó recuperación local de ambos componentes y conservó sus obligaciones residuales en las autoridades correspondientes.

Tres proyectos en progreso

• Plan maestro de avance y consolidación de Mori: continúa en F3.2 y gobierna el regreso a las prioridades que dieron origen a varios desvíos.
• Acceso y sincronización segura de documentación Mori con Obsidian: completó su primera fase y mantiene pendiente la evaluación móvil en laboratorio aislado.
• Recuperación verificable y cobertura de respaldo de servicios de Mori: trabaja sobre Authentik, NPM y AdGuard con pruebas preparatorias verificadas; los respaldos y restauraciones reales abiertos conservan sus propias puertas.

Un proyecto bloqueado

• Glosario y navegación editorial del blog: completó diseño, implementación y publicación aceptada. Su fase final espera autorización específica para promover el corte ya firmado a Forgejo; después deberá resolver proyecciones, artefactos y cierre documental.

Tres proyectos iniciados y pausados

• Punto único de entrada al trabajo de Mori: entregó panel, registros y una sustitución de automatización; espera la confirmación funcional que su propio criterio de cierre exige.
• Laboratorio compartido reproducible y aislado: completó F1 y quedó reservado para una fase posterior del plan maestro, normalmente apagado mientras no exista una intervención.
• Canal de operación directa y supervisada de Mori: llegó a producir operaciones útiles, cerró varias fases con límites explícitos y fue pausado cuando F6 reveló la necesidad de una plataforma separada.

Diez proyectos definidos que aún no comenzaron

• Migración de la identidad Google de Mori.
• Promoción diaria de documentación a Forgejo desde Archivista.
• Portal de acceso a Mori para visitantes externos.
• Ampliación supervisada de Netmox para la gestión de NetBox.
• Separación de identidades, credenciales y privilegios de Archivista.
• Inventario y observabilidad de credenciales de Mori.
• Actualización controlada de Proxmox VE en Cerberon.
• Blog multilingüe de Mori.
• Trabajo de Mori en Homepage mediante API.
• Plataforma de ejecución supervisada, nacida del límite descubierto por DAO y todavía pendiente de su primera fase.

Veintiséis proyectos no describen veintiséis logros equivalentes. El registro conserva precisamente sus diferencias: nueve resultados cerrados, tres trabajos presentes, un bloqueo explícito, tres pausas deliberadas y diez futuros definidos que siguen siendo futuros. Esa capacidad de distinguirlos es parte del resultado.

El método apareció mientras trabajábamos. Desde entonces, también trabaja para que podamos continuar.