Gobernar un Agente de IA con AsciiDoc: Mi Estrategia Eager/Lazy para Sesiones de Opencode sin Fuga de Contexto

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

title Evolución de las Sesiones — De la Sesión 1 a 150+
legend top
    |= Couleur |= Projet |
    | <#4CAF50> | cheroliv.com |
    | <#2196F3> | plantuml-plugin |
    | <#FF9800> | bakery-plugin |
    | <#9C27B0> | magic-stick |
endlegend

concise "Sesiones Activas" as S

@S
0 is ".md brute"
1 is "Migración\nAsciiDoc"
10 is "Eager/Lazy\nformalizado"
62 is "Regla de seguridad\n(site.yml)"
87 is "Análisis de\ncontexto"
109 is "Optimización\n-60% tokens"
133 is "133 sesiones\n240 tests PASS"

S@0 -> S@1 : Session 1\n(cheroliv.com)
S@1 -> S@10
S@10 -> S@62 : Session 62\n(plantuml-plugin)
S@62 -> S@87 : Session 87\n(Cry 4 help)
S@87 -> S@109 : Session 109\n(API Key Pool)
S@109 -> S@133 : Session 133\n(Aujourd'hui)

@enduml

@startuml
skinparam defaultTextAlignment center
skinparam wrapWidth 200

package "Raíz del Proyecto (Eager - Auto-cargado)" {
    component "<b>AGENT.adoc</b>\nReglas absolutas\nEstructura y Convenciones" as AGENT
    component "<b>PROMPT_REPRISE.adoc</b>\nMisión de la sesión N\nResumen N-1" as PROMPT
    component "<b>INDEX.adoc</b>\nPunto de entrada\nReglas + Sesiones" as INDEX
    component "<b>*_ESSENTIALS.adoc</b>\nContexto de negocio\ncrítico" as ESS
}

package ".agents/ (Lazy - Cargado bajo demanda)" {
    component "<b>sessions/N-*.adoc</b>\nArchivos detallados\nDecisiones y Output" as SESS
    component "<b>SESSIONS_HISTORY.adoc</b>\nTabla recapitulativa\nFecha/Tipo/Score" as HIST
    component "<b>PROCEDURES.adoc</b>\nPlantillas de fin de sesión\n6 pasos\n" as PROC
    component "<b>*_REFERENCE.adoc</b>\nArquitectura completa\nReferencias técnicas" as REF
    component "<b>COMPLETED_TASKS_ARCHIVE</b>\nTareas terminadas\nPor mes" as ARCH
    component "<b>AGENT_MODUS_OPERANDI.adoc</b>\nDocumentación de estrategia\nMetodología" as MOD
    component "<b>*_REFERENCE.adoc</b>\nBoot tests, A/B partition\nContextos específicos" as SPEC
}

AGENT --> PROMPT : "Referencias"
AGENT --> INDEX : "Referencias"
INDEX --> SESS : "Índice"
INDEX --> HIST : "Índice"
INDEX --> PROC : "Referencia"
INDEX --> ARCH : "Referencia"
INDEX --> REF : "Referencia"
PROMPT --> SESS : "Archivo N-1"
PROMPT --> ESS : "Contexto de negocio N"

@enduml

----
----
----
----
| magic-stick    | Session 23 | SCRIPT_VERIFICATION.adoc | 2026-04-27 |
| bakery-gradle  | Session 11 | TEST_COVERAGE_ANALYSIS   | 2026-04-27 |
| cheroliv.com   | Session 9  | TEST_COVERAGE_ANALYSIS   | 2026-04-27 |
| plantuml-gradle| Session 133| TEST_COVERAGE_ANALYSIS   | 2026-04-23 |
| jhipster-gradle-plugins | Session 1 | TEST_COVERAGE_ANALYSIS | 2026-04-28 |
----

Por favor, proporcione el texto que desea traducir del francés al español.`*_ESSENTIALS.adoc`** -- Un añadido reciente (Sesión 109, plantuml-plugin) para optimizar aún más el contexto Eager. En lugar de cargar 200 líneas de contexto empresarial en el grupo de claves API, cargo 50 líneas de lo esencial, y las otras 150 líneas permanecen en LAZY en`*_REFERENCE.adoc`.

Resultado medido: paso de**~25k tokens EAGER a ~10k tokens**(ganancia del 60%). El agente ya no necesita recordatorios que consumen energía.

==== El Eslabón Perdido : `opencode.json

Debo confesarles una cosa que casi olvidé documentar. Por encima de todos estos archivos .adoc, hay un pequeño archivo JSON sin el cual nada funciona. Se llama`opencode.json`y hace seis líneas. Literalmente seis líneas.

[source,json]
----
{
  "$schema": "https://opencode.ai/config.json",
  "instructions": [
    "AGENT.adoc"
  ]
}
----

Este es el archivo que le dice a Opencode: «Al iniciar, carga`AGENT.adoc`automáticamente. » Sin él, el agente es una página en blanco exactamente como lo describía al inicio del artículo. Con él, el agente ya tiene entre las manos las reglas absolutas, la arquitectura del proyecto y los comandos esenciales — antes incluso de que yo diga hola.

Descubrí por casualidad la importancia de este archivo. Sobre`bakery-plugin`, no existía. Me preguntaba por qué el agente estaba sistemáticamente más « perdido » en este proyecto que en los otros. Las reglas absolutas estaban bien dentro de`AGENT.adoc`— pero`AGENT.adoc`nunca estaba cargado. El agente solo leía lo que yo le decía que lea, manualmente, en cada sesión. Era la sesión 11 de`bakery-plugin`cuando me di cuenta de la ausencia del`opencode.json`. Lo creé — y la sesión 12 comenzó como las demás.

Este archivo es tan obvio para mí ahora que ni siquiera lo tenía en cuenta. Un error clásico del desarrollador que conoce demasiado su herramienta. Hoy, lo creo sistemáticamente *antes*`AGENT.adoc`. Es la primera piedra.

==== La dualidad de `INDEX.adoc

Otra sutileza que merece ser explicitada :`INDEX.adoc`vive en`.agents/`— una carpeta que he presentado como `LAZY`. Sin embargo, la enumero como `EAGER` en todas mis tablas. Hay una tensión aparente aquí.

La realidad de campo: los archivos`.agents/INDEX.adoc`están bien cargados automáticamente al inicio de la sesión, al mismo nivel que`AGENT.adoc` et `PROMPT_REPRISE.adoc`Ellos están en`.agents/`Por razones de organización — no invadir la raíz — pero su comportamiento es EAGER.

sobre`plantuml-plugin`, `INDEX.adoc`tiene 200 líneas y contiene las reglas absolutas *completas* con su historial (las lecciones de las sesiones pasadas), los EPICs con puntuaciones, y el portafolio de proyectos. Es el documento que el agente consulta para saber « dónde estamos». Sobre`bakery-plugin`, hace 150 líneas con la hoja de ruta y las sesiones recientes.

La redundancia voluntaria entre`AGENT.adoc` et `INDEX.adoc`Puede sorprender. Las reglas absolutas están presentes en ambos. ¿Por qué? Porque cumplen dos funciones diferentes: en`AGENT.adoc`, son *explicativas* (el storytelling de la regla, la lección aprendida); en`INDEX.adoc`, ellas son *ejecutivas*(la regla desnuda, sin justificación, para una consulta rápida). El agente lee`AGENT.adoc`una vez para *comprender* ; él vuelve a leer`INDEX.adoc`à cada sesión para *aplicar*. Dos usos, dos formatos.

[plantuml, format=svg, id=diag-dualite-agent-index, alt="Comparaison entre AGENT.adoc (narratif) et INDEX.adoc (exécutif)"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Dualidad AGENT.adoc ←→ INDEX.adoc
left to right direction

rectangle "AGENT.adoc\n(Raíz — EAGER)" as AGENT #E3F2FD {
  rectangle "📖 **Formato Narrativo**\nEl storytelling de la regla\nla lección aprendida, el contexto" as NARR
  rectangle "�🏗️ **Arquitectura Completa**\nEstructura del proyecto, componentes\nBacklog detallado US" as ARCHI
  rectangle "📋 **Reglas Explicatives**\n¿Por qué existe la regla?\nHistorial del incidente" as EXPL
}

rectangle "INDEX.adoc\n(.agents/ — EAGER)" as INDEX #E8F5E9 {
  rectangle "�⚡ **Formato Ejecutivo**\nLa regla desnuda, sin justificación\nConsulta rápida" as EXEC
  rectangle "📊 **Roadmap & EPICs**\nTabla resumen\nProgreso, Puntuación, Prioridad" as ROAD
  rectangle "�🌐 **Portafolio de proyectos**\nVisión transversal\n5 proyectos sincronizados" as PORT
}

AGENT --> INDEX : "Agent lee AGENT.adoc\n1 vez para **comprender**"
INDEX --> AGENT : "Agent vuelve a leer INDEX.adoc\nCada sesión para **aplicar**"

note bottom of AGENT
  Taille max : 200 lignes
end note

note bottom of INDEX
  Taille max : 200 lignes
  Source de vérité en cas de divergence
end note

@enduml
----

Esta redundancia asumida es una elección de diseño. Consume ~50 líneas adicionales de tokens EAGER — pero garantiza que el agente siempre tenga las reglas a la vista, incluso en el formato conciso que facilita la obediencia inmediata.

=== Los Archivos LAZY: El Manual del Propietario

Estos archivos viven en`.agents/`y solo se leen cuando el agente los necesita. Constituyen la verdadera riqueza del método, porque acumulan el conocimiento del proyecto sin contaminar el contexto actual.

[plantuml, format=svg, id=diag-agents-tree, alt="Arborescence complète du dossier .agents/"]
----
@startuml
skinparam folderBackgroundColor #E3F2FD
skinparam folderBorderColor #1565C0
skinparam fileBackgroundColor #FFF3E0
skinparam fileBorderColor #EF6C00

folder ".agents/" as ROOT {
  file "INDEX.adoc\n(EAGER -- 200 líneas)" as IDX #E8F5E9
  file "AGENT_SESSION_MANAGER.adoc\n(Sesión de plantilla)" as ASM
  file "SESSION_CHECKLIST.adoc\n(¿Cuándo cambiar?)" as CHK
  file "PROCEDURES.adoc\n(6 pasos + LAZY/EAGER)" as PRO
  file "SESSIONS_HISTORY.adoc\n(Toutes sessions)" as HIS

  folder "sesiones/" as SESS {
    file "1-chore-migration.adoc" as S1
    file "109-formalización-lazy.adoc" as S109 #FFECB3
    file "133-epic11-article.adoc" as S133
    file "... +130 otros" as SMORE
  }

  folder "archivos/" as ARCH {
    file "COMPLETED_TASKS_2026-04.adoc" as CTA
    file "SESSIONS_HISTORY_83-95.adoc" as SHIST
    folder "sessions_resúmenes/" as SUM {
      file "SESSION_64_SUMMARY.adoc" as SU64
      file "SESSION_73_SUMMARY.adoc" as SU73
      file "..." as SUMORE
    }
    folder "prompts_archive/" as PARCH {
      file "PROMPT_REPRISE_S65.adoc" as PR65
      file "PROMPT_REPRISE_S75.adoc" as PR75
      file "..." as PMORE
    }
  }
}

IDX --> SESS : "Índice"
IDX --> HIS : "Índice"
IDX --> ARCH : "Referencia"

note right of S109
  Session 109 =
  Formalisation stratégie
  LAZY/EAGER
  Token : ~25k → ~10k
end note

@enduml
----

El árbol anterior muestra la estructura real de la carpeta`.agents/`sobre`plantuml-plugin`, el proyecto más maduro. Observe la profundidad en tres capas: archivos raíz (metadatos), carpeta`sessions/`(archivos cronológicos), y expediente`archives/`(agregaciones y resúmenes). Es esta profundidad la que transforma la gobernanza de un simple archivo TODO en una**memoria organizacional completa**.

**.agents/sessions/{N}-{título}.adoc**Los archivos detallados de cada sesión. Actualmente :

* `plantuml-plugin`:**133 sesiones archivadas**(de la sesión 1 al 133)
* `bakery-plugin`:**11 sesiones**
* `magic-stick` : **23 sesiones**
* `cheroliv.com`:**9 sesiones formales**+ 7 sesiones pre-sistema reconstituidas retroactivamente

Cada archivo contiene el contexto completo de la sesión, las decisiones tomadas, los problemas encontrados y su resolución, los comandos ejecutados y su salida.

**.agents/SESSIONS_HISTORY.adoc**-- Un cuadro resumen de todas las sesiones con una puntuación. Ejemplo sobre`cheroliv.com`:

----

| -6 | 2025-05 | chore | Initialisation projet Gradle/JBake | 7/10 |  1 | 2026-04-25 | chore | Migration gouvernance agent | 8/10 |  7 | 2026-04-27 | debug/fix | Correction publishSite | 9/10 |  8 | 2026-04-27 | analyse | Analyse article 0108 | 7/10

**.agents/COMPLETED_TASKS_ARCHIVE_{mois}.adoc**-- Las tareas completadas archivadas por mes, para no sobrecargar el backlog activo. Cuando una historia de usuario está completa, se mueve aquí. El backlog sigue siendo legible: máximo 10 ítems activos.

**.agents/PROCEDURES.adoc**-- Plantillas detalladas del procedimiento de fin de sesión. Larga, pero leída una sola vez por el agente cuando aprende el método. Luego, el procedimiento se vuelve mecánico.

**.agents/AGENT_MODUS_OPERANDI.adoc**-- La documentación estratégica completa. Sobre`plantuml-plugin`, este archivo hace**900+ líneas**y se llama en realidad`AGENT_METHODOLOGIES.adoc`— cambié el nombre entre la redacción de este artículo y su implementación efectiva. Este tipo de divergencia de naming es inevitable en un sistema artesanal que evoluciona. Lo importante es la convención de nomenclatura: si el archivo documenta la *méthode*, comienza por`AGENT_`o un prefijo explícito. Documenta la metodología Eager/Lazy, los patrones a seguir, los anti-patrones a evitar. Es LAZY porque un agente no necesita volver a leer toda la estrategia en cada sesión, solo cuando hay ambigüedad.

**`*_REFERENCE.adoc`** -- Las referencias técnicas específicas del proyecto. Sobre`magic-stick`, dos archivos LAZY densos :

* `AB_PARTITION_REFERENCE.adoc`(147 líneas) -- Arquitectura de partición A/B GPT, scripts`update-system.sh`, tamaños estimados, mecanismo de rollback
* `BOOT_TEST_REFERENCE.adoc`(144 líneas) -- Procedimiento QEMU + VNC para probar el arranque de la ISO sin hardware físico, lista de verificación BIOS/UEFI, limitaciones CI/CD

Sobre`plantuml-plugin`</think> </think>

* `ARCHITECTURE.adoc`(134 líneas) -- Estructura de las 11 clases de datos, puntos de atención (trampas a evitar), comandos de prueba optimizados
* `API_KEY_POOL_REFERENCE.adoc`-- Detalles completos del pool de claves (LAZY mientras que`ESSENTIALS`está EAGER)

== Los Agentes Especializados : Un Equipo Virtual

La gobernanza no se limita a archivos pasivos. He formalizado de**roles de agentes especializados**en archivos LAZY dedicados, que definen el flujo de trabajo esperado según el tipo de tarea.

|===
|agente |Archivo |rol |Proyecto |**CODIFICAR** |`CODER.adoc` |Implementación FTL/CSS/JS, etiquetas semánticas, criterios de accesibilidad |cheroliv.com |**Maestro SCRUM** |`SCRUM_MASTER.adoc` |Planificación EE. UU., desglose en sub-tareas, detección de dependencias |cheroliv.com |**PlantUML Diseñador** |`PLANTUML_DESIGNER.adoc` |Creación de diagramas, sintaxis PUML, integración JBake |cheroliv.com
|===

El archivo`CODER.adoc`sobre`cheroliv.com`contiene reglas concretas : _Un solo`<h1>`por página_, _Prefijar los caminos con`${content.rootpath}`_, _Declarar el idioma`<html lang="${content.lang!"fr"}">`_. Estas convenciones, escritas una vez, se respetan automáticamente por el agente desde la sesión 1.

El archivo`SCRUM_MASTER.adoc`impone una estructura de entregable:**Objetivo**, **Tareas**(coordenadas con asignación)**Criterios de aceptación**, **Riesgos**. Cuando pido un plan de acción, el agente produce esta estructura sin que yo se la haya pedido. La gobernanza**programa**el agente.

==== Cuando los agentes especializados se vuelven indispensables

La creación de los agentes especializados sigue una curva natural. Al comienzo de un proyecto, no los necesitas —`AGENT.adoc`basta ampliamente. Pero cuando el proyecto crezca (digamos, más de 20 sesiones), dos señales deben alertarle:

1. El agente mezcla las convenciones de dos dominios distintos (ej: sintaxis PlantUML y reglas CSS)
2. Pasas más tiempo corrigiendo al agente sobre convenciones que ya le has explicado 5 veces

Sobre`cheroliv.com`, llegó a la sesión... 1. Sí, desde el principio. Porque este proyecto es un sitio web con tres lenguajes (FTL, CSS, JS), contenido AsciiDoc, y diagramas PlantUML — tres áreas que no tienen nada que ver. El agente CODER necesita conocer los tamaños de fuente y las media queries; el agente PLANTUML_DESIGNER necesita conocer la sintaxis`@startuml`. Sin separación, el agente CODER me proponía diagramas, y viceversa. El caos.

Sobre`jhipster-gradle-plugins`, he creado dos agentes especializados adaptados al desarrollo de plugins Gradle :`PLUGIN_DEVELOPER.adoc` et `BACKLOG_MANAGER.adoc`. El primero codifica todas las convenciones Kotlin/Gradle (no`!!`, clases de datos para los modelos,`@TaskAction`para las tareas). El segundo sabe que`persistence`debe ser estable antes de que`assistant`no comienza su desarrollo — una dependencia crítica en un mono-repo.

El error que no se debe cometer : crear demasiados agentes demasiado temprano`plantuml-plugin`Esperó la sesión 108 antes de formalizar un agente especializado para el conjunto de claves API. Antes de eso, el contexto del negocio se encontraba en`AGENT.adoc`. La regla empírica: un agente especializado se justifica cuando su dominio de negocio supera las 100 líneas de documentación.

==== Convención de Nomenclatura de Sesiones

Un detalle que parece fútil pero que se vuelve crítico cuando se alcanzan 100 sesiones. ¿Cómo nombrar los archivos de archivo?

He aprendido a mis expensas que una convención es necesaria — cuatro proyectos, cuatro formatos diferentes al principio, y ya no sabía orientarme. Hoy, la convención que he estabilizado es :

----

{N}-{type}-{sujet-kebab-case}.adoc

Ejemplos concretos:

* `1-chore-migration-gouvernance-agent.adoc`— sesión 1, tipo tarea
* `10-solidification-tests.adoc`— sesión 10, sin tipo explícito (el sujeto basta)
* `036-debug-graphify-symlink-epic9.adoc`— sesión 36 con número de 3 dígitos para la ordenación

El número de sesión es el criterio de ordenación principal. Los proyectos que utilizan números de tres cifras (001, 036, 133) evitan los problemas de ordenación lexicográfica cuando se supera 99. Esto es lo que ahora utilizo en`magic-stick`:`001-init-projet.adoc`, `036-debug-graphify-symlink-epic9.adoc`.

El tipo es opcional y se deriva de las palabras clave de la sesión (debug, feature, refactor, docs, chore, test). El asunto en kebab-case es la parte más importante: debe permitir recuperar una sesión sin abrir el archivo. Si te preguntas « ¿cuál fue la sesión en la que se corrigió el timeout de las pruebas de integración? », la respuesta es`124-fix-timeout-integration-test.adoc`.

Para las sesiones históricas reconstituidas (proyectos nacidos antes de la gobernanza), utilizo números negativos. Sobre`cheroliv.com`, las sesiones -6 a 0 cubren todo el historial pre-gobernanza del proyecto. Y para las sesiones « no documentadas » o perdidas, creo una entrada en`SESSIONS_HISTORY.adoc`sin archivo correspondiente, con una puntuación`?`. Es más honesto que fingir.

[plantuml, format=svg, id=diag-naming-convention, alt="Arbre de décision pour le nommage des fichiers de session"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Convención de Nomenclatura de Sesiones
start

:Une session se termine;
note right: Trigger "final de la sesión"

if (Session antérieure\nà la gouvernance ?) then (oui)
  :Numéro **NÉGATIF**\n-6, -5 ... 0;
  note right: Historique\nreconstitué
  :Suffixe : reconstitution;
else (non)
  :Numéro **POSITIF**\nsur 3 chiffres si > 99;
  note right: 001, 036, 133\npour le tri lexicographique

  :Détecter le **TYPE**;
  if (Mots-clés trouvés ?) then (oui)
    :debug / feature / refactor\ndocs / chore / test;
  else (non)
    :Omettre le type\n(le sujet suffit);
  endif

  :Formuler le **SUJET** en kebab-case;
  note right
    Ex: fix-timeout-integration-test
    Doit permettre de retrouver
    sans ouvrir le fichier
  end note
endif

:Nom final : {N}-{type}-{sujet}.adoc;
note right
  • 1-chore-migration-gouvernance.adoc
  • 036-debug-graphify-symlink.adoc
  • 124-fix-timeout-integration-test.adoc
  • 133-epic11-article-blog-kg.adoc
end note

if (Session documentée ?) then (oui)
  :Créer archive dans sessions/;
  :Ajouter ligne SESSIONS_HISTORY\navec score X/10;
else (non)
  :Ajouter ligne SESSIONS_HISTORY\navec score **?**\n**sans archive**;
  note right: L'honnêteté\nplutôt que le vide
endif

stop
@enduml
----

==== TEST_COVERAGE_ANALYSIS.adoc` — El Paso 5 Detallado

El paso 5 del procedimiento de fin de sesión es el más misterioso. Dice « Actualizar`TEST_COVERAGE_ANALYSIS.adoc`si se han añadido o modificado las pruebas. » Pero, ¿qué aspecto tiene este archivo?

sobre`plantuml-plugin`, ha evolucionado de unas pocas líneas a una estructura completa. Aquí está su forma estabilizada:

[source]
----
= Analyse de Couverture de Tests

== Suivi des Tests
|===
| Classe de test | Type | Tests | Statut | Dernière MAJ
| PlantumlServiceTest | unit | 45/45 | ✅ PASS | 2026-04-23
| ApiKeyPoolTest | integration | 15/15 | ✅ PASS | 2026-04-20
|===

== Historique par Session
| Session | Tests ajoutés | Tests modifiés | Couverture
| 133     | 0             | 2              | 100%
| 132     | 5             | 0              | 100%
|===
----

El interés no es el archivo en sí — es la obligación de *notar* lo que ha cambiado. Sin este paso, después de 50 sesiones, ya no sabes qué pruebas cubren qué. El agente tampoco. El archivo se convierte en el único repositorio de verdad sobre la cobertura de pruebas del proyecto.

Para los proyectos sin pruebas tradicionales (como`magic-stick`que prueba scripts bash), el paso 5 se sustituye por`SCRIPT_VERIFICATION.adoc`. El mecanismo es el mismo: un archivo que sigue el estado de validación de los scripts. Adapta el paso 5 a tu proyecto, pero nunca lo omitas. Es la red de seguridad que evita la regresión silenciosa.

[plantuml, format=svg, id=diag-dualite-agent-index, alt="Comparaison entre AGENT.adoc (narratif) et INDEX.adoc (exécutif)"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Dualidad AGENT.adoc ←→ INDEX.adoc
left to right direction

rectangle "AGENT.adoc\n(Raíz — EAGER)" as AGENT #E3F2FD {
  rectangle "📖 **Formato Narrativo**\nLa narrativa de la regla\nla lección aprendida, el contexto" as NARR
  rectangle "🏗️ **Arquitectura Completa**\nEstructura del proyecto, componentes\nBacklog detallado US" as ARCHI
  rectangle "📋 **Reglas Explicativas**\nPor qué existe la regla\nHistorial del incidente" as EXPL
}

rectangle "INDEX.adoc\n(.agents/ — EAGER)" as INDEX #E8F5E9 {
  rectangle "⚡ **Formato Ejecutivo**\nLa regla desnuda, sin justificación\nConsulta rápida" as EXEC
  rectangle "📊 **Hoja de ruta y EPICs**\nTabla resumen\nProgresión, Puntuación, Prioridad" as ROAD
  rectangle "🌐 **Portafolio de Proyectos**\nVista transversal\n5 proyectos sincronizados" as PORT
}

AGENT --> INDEX : "Agente lee AGENT.adoc\n1 vez para **comprender**"
INDEX --> AGENT : "Agente relee INDEX.adoc\ncada sesión para **aplicar**"

note bottom of AGENT
  Taille max : 200 lignes
end note

note bottom of INDEX
  Taille max : 200 lignes
  Source de vérité en cas de divergence
end note

@enduml
----

[plantuml, format=svg, id=diag-session-flow, alt="Flux d'une session type avec Eager/Lazy et agents"]
----
@startuml
skinparam backgroundColor #FEFEFE

start

:Début session;
note right: L'agent est une page blanche

:Chargement EAGER auto;
note right
  * AGENT.adoc (règles absolues)
  * PROMPT_REPRISE.adoc (mission N)
  * INDEX.adoc (état projet)
end note

if (Mission claire ?) then (oui)
  :Exécution directe;
else (non)
  :Charge LAZY sur demande;
  note right
    * SESSIONS_HISTORY.adoc (contexte passé)
    * sessions/{N-1}-*.adoc (décisions)
    * *_REFERENCE.adoc (architechture)
  end note
endif

:Délégation agent spécialisé ?;

if (CODER ?) then (oui)
  :Lit CODER.adoc;
  :Suit conventions FTL/CSS;
elseif (SCRUM Master ?) then (oui)
  :Lit SCRUM_MASTER.adoc;
  :Structure livrable imposée;
elseif (PlantUML ?) then (oui)
  :Lit PLANTUML_DESIGNER.adoc;
  :Syntaxe PUML + intégration;
else (non)
endif

:Travail de la session;

:Fin de session (trigger utilisateur);

:Procédure 6 étapes;
note right
  1. Archive sessions/N-*.adoc
  2. Maj PROMPT_REPRISE.adoc (N+1)
  3. Maj SESSIONS_HISTORY.adoc
  4. Maj INDEX.adoc
  5. Maj TEST_COVERAGE (si applicable)
  6. Maj COMPLETED_TASKS_ARCHIVE.adoc
end note

:Checklist [✅] x 6;

stop
@enduml
----

El diagrama de arriba muestra el ciclo de vida completo de una sesión. El punto clave es la bifurcación después de la carga EAGER: ya sea la misión es suficientemente clara para ejecutar directamente (80% de los casos), o el agente carga el LAZY para resolver una ambigüedad (20% de los casos). Es esta discriminación la que ahorra los tokens.

== El Procedimiento de Fin de Sesión: La Regla de Oro

[plantuml, format=svg, id=diag-agents-tree, alt="Arborescence complète du dossier .agents/"]
----
@startuml
skinparam folderBackgroundColor #E3F2FD
skinparam folderBorderColor #1565C0
skinparam fileBackgroundColor #FFF3E0
skinparam fileBorderColor #EF6C00

folder ".agents/" as ROOT {
  file "INDEX.adoc\n(EAGER -- 200 líneas)" as IDX #E8F5E9
  file "AGENT_SESSION_MANAGER.adoc\n(Plantilla de sesión)" as ASM
  file "SESSION_CHECKLIST.adoc\n(Cuándo cambiar)" as CHK
  file "PROCEDURES.adoc\n(6 etapas + LAZY/EAGER)" as PRO
  file "SESSIONS_HISTORY.adoc\n(Todas las sesiones)" as HIS

  folder "sesiones/" as SESS {
    file "1-chore-migration.adoc" as S1
    file "109-formalisation-lazy.adoc" as S109 #FFECB3
    file "133-epic11-article.adoc" as S133
    file "... +130 otros" as SMORE
  }

  folder "archivos/" as ARCH {
    file "TAREAS_COMPLETADAS_2026-04.adoc" as CTA
    file "SESSIONS_HISTORY_83-95.adoc" as SHIST
    folder "sesiones_resúmenes/" as SUM {
      file "SESSION_64_SUMMARY.adoc" as SU64
      file "SESSION_73_SUMMARY.adoc" as SU73
      file "..." as SUMORE
    }
    folder "prompts_archive/" as PARCH {
      file "PROMPT_REPRISE_S65.adoc" as PR65
      file "PROMPT_REPRISE_S75.adoc" as PR75
      file "..." as PMORE
    }
  }
}

IDX --> SESS : "Indexe"
IDX --> HIS : "Indexe"
IDX --> ARCH : "Referencia"

note right of S109
  Session 109 =
  Formalisation stratégie
  LAZY/EAGER
  Token : ~25k → ~10k
end note

@enduml
----

Sin este procedimiento, la estrategia Eager/Lazy no sirve de nada. Es ella quien transforma el trabajo de la sesión en información persistente. Se ejecuta**a petición explícita del usuario**(palabras clave : "fin de sesión", "me voy", etc.), y ella está**obligatorio**-- ninguna excepción, ninguna omisión.

El archivo`SESSION_CHECKLIST.adoc`define las métricas de sesión ideal:

* Duración: 15-30 minutos
* Archivos modificados: 1-3 máximo
* Intercambios LLM : 5-10 mensajes
* Contexte tokens : < 50k

Y hay signos de que hay que cambiar de sesión : _El LLM repite errores ya corregidos_, _Más de 3 archivos modificados en paralelo_, _Conversación > 50 mensajes_. La regla de oro :**Vale más 5 sesiones de 20 minutos que una sesión de 2 horas con debugging caótico.**

=== El flujo de los 6 pasos (Silenciosamente)

[plantuml, format=svg, id=diag-end-session-flow, alt="Flux de la procédure de fin de session"]
----
@startuml
skinparam defaultTextAlignment center
skinparam wrapWidth 200
skinparam activityBackgroundColor #E3F2FD

start
:L'utilisateur dit "fin de sesión";
note right: Mots-clés déclencheurs

:Agent détecte le trigger;

:Étape 1\nCréer archive\n`.agents/sessions/N-*.adoc`;
note right: Tout le contexte de la session

:Étape 2\nMettre à jour\n`PROMPT_REPRISE.adoc`;
note right: Mission N + critères d'acceptation N+1

:Étape 3\nMettre à jour\n`SESSIONS_HISTORY.adoc`;
note right: Ligne récap : # / Date / Type / Sujet / Score

:Étape 4\nMettre à jour\n`INDEX.adoc`;
note right: État courant, roadmap, fichiers modifiés

:Étape 5\nMettre à jour\n`TEST_COVERAGE_ANALYSIS.adoc`;
note right: Si tests ajoutés ou modifiés

:Étape 6\nMettre à jour\n`COMPLETED_TASKS_ARCHIVE.adoc`;
note right: Archiver tâches terminées

:Afficher la checklist de confirmation;
note right: Vérifier que chaque [✅] est mérité

stop
@enduml
----

=== Los Resultados de 150+ Sesiones

Esto es lo que produce este procedimiento aplicado sistemáticamente en mis cuatro proyectos:

**plantuml-plugin**:

* **133 sesiones**desde el inicio del proyecto
* **240/240 pruebas aprobadas**(100% cobertura) -- EPICs 1-7 completados
* **57 escenarios Cucumber BDD**validados
* Regla de seguridad sobre los archivos de configuración surgida de un error real (Sesión 2 bakery-plugin)

**panadería-plugin** :

* **11 sesiones**en dos semanas
* Migración de Supabase a Firebase completada (9 pruebas corregidas)
* EPIC 6 (publishProfile) funcional en producción
* Regla 0 creada :`publishToMavenLocal`obligatorio después de cada modificación

**palo mágico** :

* **23 sesiones**para construir un sistema live Xubuntu con partición A/B
* Primera ISO generada en la sesión 10
* Pruebas de arranque QEMU + VNC formalizadas (documentación LAZY de 144 líneas)
* CI/CD SourceForge funcional

**cheroliv.com**:

* **9 sesiones formales**+ reconstitución de 7 sesiones pre-sistema
* Artículo 0101 (OpenCode PATH) publicado
* Article 0108 (éste) reescrito después del análisis de sus deficiencias
* Gobernanza completa migrada de Markdown a AsciiDoc

=== La lista de verificación final

Tras la ejecución silenciosa de los 6 pasos, el agente debe mostrar una lista de verificación de confirmación:

✅ Procédure de fin de session exécutée 📋 Checklist :

**Regla absoluta**: ningún paso puede marcarse`[✅]`si el archivo no ha sido efectivamente modificado y verificado.

== La Guía de Bootstrap: Día 1, Sesión 0

Estás convencido del método. Quieres aplicarlo a un nuevo proyecto. ¿Por dónde empezar?

Viví este momento el 28 de abril de 2026. Abro Opencode en`jhipster-gradle-plugins`, mi mono-repo de dos plugins Gradle JHipster. Es un proyecto que ya existe — el código está allí, las tareas Gradle funcionan. Pero el agente de gobernanza ? Cero. Página blanca. Como`plantuml-plugin`A su sesión 1, hace varios meses.

Este es el procedimiento exacto que seguí, y que seguiré para todo nuevo proyecto. Tenga en cuenta el orden — es importante.

[plantuml, format=svg, id=diag-bootstrap, alt="Flux de bootstrap en 6 étapes pour initialiser la gouvernance agent sur un nouveau projet"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 250
skinparam activityBackgroundColor #E8F5E9

title Bootstrap Gobernanza — Día 1, Sesión 0
start
:Étape 0\nCréer **opencode.json**\n(6 lignes, instructions: AGENT.adoc);
note right: Le pont qui charge\nAGENT.adoc automatiquement

:Étape 1\nCréer les dossiers\n**mkdir -p .agents/sessions/ .agents/archives/**;
note right: Les conteneurs vides\navant que l'agent écrive dedans

:Étape 2\nCréer **AGENT.adoc**\n(200 lignes, règles absolues);
note right: Le fichier maître\nStructure minimale v1

:Étape 3\nCréer **PROMPT_REPRISE.adoc**\nMission session 1 (max 70 lignes);
note right: Ce que l'agent doit\nfaire à la prochaine session

:Étape 4\nCréer **.agents/INDEX.adoc**\nRègles exécutives + roadmap;
note right: Point d'entrée EAGER\ndans le dossier LAZY

:Étape 5\nCréer les fichiers LAZY structurants\n6 fichiers : SESSIONS_HISTORY, CHECKLIST, etc.;
note right
  • SESSIONS_HISTORY.adoc
  • SESSION_CHECKLIST.adoc
  • PROCEDURES.adoc
  • AGENT_SESSION_MANAGER.adoc
  • TEST_COVERAGE_ANALYSIS.adoc
  • Agents spécialisés (si besoin)
end note

:Étape 6\nAjouter le projet au Portefeuille\nMettre à jour TOUS les INDEX.adoc existants;
note right: Maintenance transverse\nObligatoire mais fastidieuse

:✅ Bootstrap terminé\nSession 1 prête;
note right: 20 minutes investies\nDes centaines économisées

stop
@enduml
----

=== Paso 0 : Crear `opencode.json

Este es el primer archivo. No`AGENT.adoc`, no`INDEX.adoc`.`opencode.json`primero, por una razón simple: si creas`AGENT.adoc`Al principio, olvidarás crear el puente que lo carga automáticamente. Lo he hecho sobre.`bakery-plugin`, yo sé de lo que hablo.

=== Paso 1: Crear las Carpetas

[source,bash]
----
mkdir -p .agents/sessions .agents/archives
----

Dos carpetas vacías.`sessions/`recibirá los archivos de cada sesión.`archives/`recibirá los COMPLETED_TASKS_ARCHIVE mensuales. Estos directorios deben existir *avant* de que el agente necesite escribir en ellos. Un agente que debe crear el directorio ET el archivo al mismo tiempo, es un agente que puede fallar silenciosamente.

=== Paso 2: Crear `AGENT.adoc` — El Archivo Maestro

Estructura mínima para la primera versión (crecerá) :

[source]
----
= {NOM_PROJET} — Directives Agent

[CAUTION]
----

[plantuml, format=svg, id=diag-naming-convention, alt="Arbre de décision pour le nommage des fichiers de session"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Convención de nomenclatura de sesiones
start

:Une session se termine;
note right: Trigger "fin de sesión"

if (Session antérieure\nà la gouvernance ?) then (oui)
  :Numéro **NÉGATIF**\n-6, -5 ... 0;
  note right: Historique\nreconstitué
  :Suffixe : reconstitution;
else (non)
  :Numéro **POSITIF**\nsur 3 chiffres si > 99;
  note right: 001, 036, 133\npour le tri lexicographique

  :Détecter le **TYPE**;
  if (Mots-clés trouvés ?) then (oui)
    :debug / feature / refactor\ndocs / chore / test;
  else (non)
    :Omettre le type\n(le sujet suffit);
  endif

  :Formuler le **SUJET** en kebab-case;
  note right
    Ex: fix-timeout-integration-test
    Doit permettre de retrouver
    sans ouvrir le fichier
  end note
endif

:Nom final : {N}-{type}-{sujet}.adoc;
note right
  • 1-chore-migration-gouvernance.adoc
  • 036-debug-graphify-symlink.adoc
  • 124-fix-timeout-integration-test.adoc
  • 133-epic11-article-blog-kg.adoc
end note

if (Session documentée ?) then (oui)
  :Créer archive dans sessions/;
  :Ajouter ligne SESSIONS_HISTORY\navec score X/10;
else (non)
  :Ajouter ligne SESSIONS_HISTORY\navec score **?**\n**sans archive**;
  note right: L'honnêteté\nplutôt que le vide
endif

stop
@enduml
----

1. LEER el archivo completo
2. VERIFICAR git ls-files
3. SOLICITAR confirmación
4. ESPERAR "sí

== Proyecto

**Nombre**: ... **pila**: ... **Documentación**: AsciiDoc

== Reglas Absolutas

=== 0. ENTORNO DE DESARROLLO

Comandos esenciales...

=== 1. COMMITS/GIT

[plantuml, format=svg, id=diag-session-flow, alt="Flux d'une session type avec Eager/Lazy et agents"]
----
@startuml
skinparam backgroundColor #FEFEFE

start

:Début session;
note right: L'agent est une page blanche

:Chargement EAGER auto;
note right
  * AGENT.adoc (règles absolues)
  * PROMPT_REPRISE.adoc (mission N)
  * INDEX.adoc (état projet)
end note

if (Mission claire ?) then (oui)
  :Exécution directe;
else (non)
  :Charge LAZY sur demande;
  note right
    * SESSIONS_HISTORY.adoc (contexte passé)
    * sessions/{N-1}-*.adoc (décisions)
    * *_REFERENCE.adoc (architechture)
  end note
endif

:Délégation agent spécialisé ?;

if (CODER ?) then (oui)
  :Lit CODER.adoc;
  :Suit conventions FTL/CSS;
elseif (SCRUM Master ?) then (oui)
  :Lit SCRUM_MASTER.adoc;
  :Structure livrable imposée;
elseif (PlantUML ?) then (oui)
  :Lit PLANTUML_DESIGNER.adoc;
  :Syntaxe PUML + intégration;
else (non)
endif

:Travail de la session;

:Fin de session (trigger utilisateur);

:Procédure 6 étapes;
note right
  1. Archive sessions/N-*.adoc
  2. Maj PROMPT_REPRISE.adoc (N+1)
  3. Maj SESSIONS_HISTORY.adoc
  4. Maj INDEX.adoc
  5. Maj TEST_COVERAGE (si applicable)
  6. Maj COMPLETED_TASKS_ARCHIVE.adoc
end note

:Checklist [✅] x 6;

stop
@enduml
----

=== 1b. ARCHIVOS DE CONFIGURACIÓN — REGLA ABSOLUTA DE SEGURIDAD

Nunca aplastar...

=== 2. EXÁMENES AL FINAL DE LA SESIÓN

Prohibición formal...

=== 3. PROCEDIMIENTO DE FIN DE SESIÓN

Las 6 etapas obligatorias...

== Gestión del Contexto — LAZY/EAGER

Archivos EAGER / Archivos LAZY...

[plantuml, format=svg, id=diag-end-session-flow, alt="Flux de la procédure de fin de session"]
----
@startuml
skinparam defaultTextAlignment center
skinparam wrapWidth 200
skinparam activityBackgroundColor #E3F2FD

start
:L'utilisateur dit "fin de sesión";
note right: Mots-clés déclencheurs

:Agent détecte le trigger;

:Étape 1\nCréer archive\n`.agents/sessions/N-*.adoc`;
note right: Tout le contexte de la session

:Étape 2\nMettre à jour\n`PROMPT_REPRISE.adoc`;
note right: Mission N + critères d'acceptation N+1

:Étape 3\nMettre à jour\n`SESSIONS_HISTORY.adoc`;
note right: Ligne récap : # / Date / Type / Sujet / Score

:Étape 4\nMettre à jour\n`INDEX.adoc`;
note right: État courant, roadmap, fichiers modifiés

:Étape 5\nMettre à jour\n`TEST_COVERAGE_ANALYSIS.adoc`;
note right: Si tests ajoutés ou modifiés

:Étape 6\nMettre à jour\n`COMPLETED_TASKS_ARCHIVE.adoc`;
note right: Archiver tâches terminées

:Afficher la checklist de confirmation;
note right: Vérifier que chaque [✅] est mérité

stop
@enduml
----

=== Paso 3 : Crear `PROMPT_REPRISE.adoc` — La Misión Sesión 1

Un archivo que dice explícitamente: « Esta es la sesión 1, misión por definir. » Máximo 70 líneas, con una sección Sesión 0 (resumen del bootstrap) y una sección Sesión 1 (prioridades por definir con el usuario).

=== Paso 4: Crear `.agents/INDEX.adoc` — El Punto de Entrada

El archivo que contendrá las reglas absolutas (versión ejecutiva) y la tabla de sesiones. Para el bootstrap, enumera las reglas 0 a 3 en su formato conciso, el portafolio de proyectos (incluyendo el nuevo proyecto con un emoji 🆕), y la hoja de ruta vacía lista para ser completada.

=== Paso 5: Crear los archivos LAZY estructurantes

En orden :

1. `.agents/SESSIONS_HISTORY.adoc`— una tabla con solo la sesión 0
2. `.agents/SESSION_CHECKLIST.adoc`— la plantilla « Cuándo cambiar de sesión
3. `.agents/PROCEDURES.adoc`— el procedimiento completo de los 6 pasos + EAGER/LAZY
4. `.agents/AGENT_SESSION_MANAGER.adoc`— la plantilla de archivo
5. `.agents/TEST_COVERAGE_ANALYSIS.adoc`— el cuadro de seguimiento de pruebas, vacío al inicio

Si su proyecto tiene un dominio de negocio complejo (como`jhipster-gradle-plugins`con su mono-repo persistence/assistant), cree los agentes especializados ahora:

1. `.agents/PLUGIN_DEVELOPER.adoc`— las convenciones de código y el límite de dependencias (si plugin)
2. `.agents/BACKLOG_MANAGER.adoc`— la estructura de planificación y los riesgos identificados

No cree agentes que no vaya a utilizar. Un agente sin convenciones concretas para codificar es un archivo muerto que contamina.`.agents/`.

=== Paso 6 : Agregar el Proyecto al Portafolio de TODOS los Proyectos

Es el paso que olvidamos sistemáticamente. Cada`INDEX.adoc`de cada proyecto contiene una tabla « Portafolio de Proyectos » que enumera TODOS los proyectos con la misma metodología. Cuando creas un nuevo proyecto, debes:

1. Añadir una línea en el portafolio del nuevo proyecto (lógico)
2. Añadir una línea en el portafolio de TODOS los proyectos existentes — sí, todos

En mis cuatro (ahora cinco) proyectos, eso significa abrir los`INDEX.adoc` de `magic-stick`, `bakery-gradle`, `cheroliv.com`, `plantuml-gradle`y allí añadir la línea`jhipster-gradle-plugins | Session 1 | ... | 2026-04-28 🆕`. (just a period).

</think>

.

Es tedioso. Es manual. También es la única forma de garantizar que, cualquiera que sea el proyecto en el que estás trabajando, el agente sepa cuáles otros proyectos existen y cuál es su estado. En la sesión 012 de`magic-stick`, el agente detectó dos inconsistencias en la cartera —`bakery-gradle`tenía su COMPLETED_TASKS_ARCHIVE atrasado, y`plantuml-gradle`Tenía un desfase entre su documentación de procedimiento (5 pasos) y su ÍNDICE (6 pasos). Sin esta tabla transversal, estas incoherencias habrían permanecido invisibles.

[plantuml, format=svg, id=diag-portfolio-graph, alt="Graphe du portefeuille de projets — références croisées entre INDEX.adoc"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam nodeBackgroundColor #E3F2FD

title Portafolio de Proyectos — Referencias Cruzadas INDEX.adoc
node "**magic-stick**\nSesión 037\nSCRIPT_VERIFICATION" as MS #E1BEE7
node "**bakery-gradle**\nSesión 11\nPRUEBA_COBERTURA" as BG #FFE0B2
node "**cheroliv.com**\nSesión 10\nTEST_COVERAGE" as CH #C8E6C9
node "**plantuml-gradle**\nSesión 133\nTEST_COVERAGE" as PG #BBDEFB
node "**jhipster-gradle**\nSesión 1 🆕\nTEST_COVERAGE" as JG #FFCDD2

MS --> BG : INDEX.adoc référence
MS --> CH : INDEX.adoc référence
MS --> PG : INDEX.adoc référence
MS --> JG : INDEX.adoc référence 🆕

BG --> MS : INDEX.adoc référence
BG --> CH : INDEX.adoc référence
BG --> PG : INDEX.adoc référence
BG --> JG : INDEX.adoc référence 🆕

CH --> MS : INDEX.adoc référence
CH --> BG : INDEX.adoc référence
CH --> PG : INDEX.adoc référence
CH --> JG : INDEX.adoc référence 🆕

PG --> MS : INDEX.adoc référence
PG --> BG : INDEX.adoc référence
PG --> CH : INDEX.adoc référence
PG --> JG : INDEX.adoc référence 🆕

JG --> MS : INDEX.adoc référence
JG --> BG : INDEX.adoc référence
JG --> CH : INDEX.adoc référence
JG --> PG : INDEX.adoc référence

note bottom of JG
  Quand on ajoute un projet :
  • 4 INDEX.adoc à mettre à jour
  • 1 ligne par portefeuille
  • Coût : 5 minutes
end note

legend bottom
  |= Couleur |= Projet |
  | <#E1BEE7> | magic-stick — ISO Linux live |
  | <#FFE0B2> | bakery-gradle — Plugin JBake |
  | <#C8E6C9> | cheroliv.com — Site personnel |
  | <#BBDEFB> | plantuml-gradle — Plugin IA |
  | <#FFCDD2> | jhipster-gradle — Mono-repo JHipster |
endlegend

@enduml
----

[plantuml, format=svg, id=diag-bootstrap, alt="Flux de bootstrap en 6 étapes pour initialiser la gouvernance agent sur un nouveau projet"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 250
skinparam activityBackgroundColor #E8F5E9

title Gobernanza Bootstrap — Día 1, Sesión 0
start
:Étape 0\nCréer **opencode.json**\n(6 lignes, instructions: AGENT.adoc);
note right: Le pont qui charge\nAGENT.adoc automatiquement

:Étape 1\nCréer les dossiers\n**mkdir -p .agents/sessions/ .agents/archives/**;
note right: Les conteneurs vides\navant que l'agent écrive dedans

:Étape 2\nCréer **AGENT.adoc**\n(200 lignes, règles absolues);
note right: Le fichier maître\nStructure minimale v1

:Étape 3\nCréer **PROMPT_REPRISE.adoc**\nMission session 1 (max 70 lignes);
note right: Ce que l'agent doit\nfaire à la prochaine session

:Étape 4\nCréer **.agents/INDEX.adoc**\nRègles exécutives + roadmap;
note right: Point d'entrée EAGER\ndans le dossier LAZY

:Étape 5\nCréer les fichiers LAZY structurants\n6 fichiers : SESSIONS_HISTORY, CHECKLIST, etc.;
note right
  • SESSIONS_HISTORY.adoc
  • SESSION_CHECKLIST.adoc
  • PROCEDURES.adoc
  • AGENT_SESSION_MANAGER.adoc
  • TEST_COVERAGE_ANALYSIS.adoc
  • Agents spécialisés (si besoin)
end note

:Étape 6\nAjouter le projet au Portefeuille\nMettre à jour TOUS les INDEX.adoc existants;
note right: Maintenance transverse\nObligatoire mais fastidieuse

:✅ Bootstrap terminé\nSession 1 prête;
note right: 20 minutes investies\nDes centaines économisées

stop
@enduml
----

=== Lo que el Bootstrap Cuesta

Todo esto lleva 20 minutos. Veinte minutos una sola vez, para no perder más veinte minutos al principio de cada sesión. El ROI es inmediato: a partir de la sesión 2, el agente retoma donde dejaste la sesión 1.

sobre`jhipster-gradle-plugins`, este bootstrap me tomó exactamente 18 minutos — de`mkdir .agents/`al último`INDEX.adoc`actualizado en la cartera de`magic-stick`. La sesión 1, que seguirá, comenzará con un agente que ya conoce la estructura del mono-repo, los comandos Gradle, y el límite crítico entre`persistence/`(lightweight) y`assistant/`(pesado). Veinte minutos bien invertidos.

== Los 4 (ahora 5) proyectos, 5 gobernanzas, 1 método

El sistema Eager/Lazy no es un boilerplate copiado y pegado. Cada proyecto ha adaptado el método a sus especificidades.

=== cheroliv.com : Sitio personal

**Especificidad**: Contenido editorial, accesibilidad WCAG 2.1 AA, JBake estático. **Adaptación**Seis épicas priorizadas (P0-P4), agentes especializados (CODER, SCRUM_MASTER, PLANTUML_DESIGNER), criterios de aceptación transversales sobre la accesibilidad. **regla emblemática**:`./gradlew serve`obligatorio, prohibición formal del script`jbake.sh`externo.

=== bakery-gradle : El Plugin Multiusos

**Especificidad**: Plugin Gradle con tareas de publicación, generación de código Firebase, análisis YAML. **Adaptación**: Regla 0 (publishToMavenLocal), regla de seguridad sobre los archivos de configuración reforzada por el incidente del`site.yml`, EPIC 9 y 10 en la configuración de varios archivos. **Regla emblemática**:`publishToMavenLocal`después de cada modificación del código fuente del plugin.

=== plantuml-gradle: El Plugin IA

**Especificidad**: Integración LangChain4j, generación de diagramas PlantUML mediante LLM, pruebas con claves API en la nube. **adaptación**: Documentación LAZY densa (ARCHITECTURE, API_KEY_POOL_REFERENCE, DATASET_FINETUNING), EPICs numerados (1-11 terminados, 107+ en curso), separación EAGER/LAZY optimizada (ganancia de 60% de tokens). **Regla emblemática**: Archivos`*_ESSENTIALS.adoc`(50 líneas) vs`*_REFERENCE.adoc`(ilimitado) para el pool de claves de API.

=== magic-stick : El Sistema Live

**Especificidad**: Construcción de ISO Linux live (Xubuntu), particionado GPT A/B, CI/CD con SourceForge. **Adaptación**: Referencias técnicas LAZY complejas (AB_PARTITION, BOOT_TEST), SCRIPT_VERIFICATION.adoc como paso 5 específico (no pruebas tradicionales, sino verificación de scripts bash). **Regla emblemática** : `isoTestAB`omitido en CI (ejecutores no privilegiados), pruebas reservadas para entornos locales con Docker`--privileged`.

== Reglas Absolutas Transversales

Algunas reglas críticas que aparecen en el archivo`AGENT.adoc`Eager y se aplican a todas las sesiones en todos los proyectos:

**Entorno de dev**

* ✅ Utilizar el comando propio del proyecto`./gradlew serve`, `./gradlew functionalTest`, etc.)
* �❌ Prohibido utilizar scripts externos no versionados

**Git**

* �✅ Solo lectura autorizada (`git status`, `git diff`, `git log`)
* �❌`git add`, `git commit`, `git push`Prohibidos sin permiso explícito
* �❌`git commit --amend`prohibido salvo que las condiciones se cumplan meticulosamente

**Archivos de Configuración**

* ❌ Nunca sobrescribir un archivo de configuración con un`Write`completo cuando un`Edit`parcial basta
* �❌ Nunca reemplazar valores sensibles por valores ficticios
* ❌ Verificar`git check-ignore` et `git ls-files`antes de cualquier modificación

**pruebas**

* �❌ Nunca lanzar pruebas en el procedimiento de fin de sesión sin permiso explícito

**herramientas prohibidas**

* ❌`TodoWrite` et `Task`-- la gobernanza se hace a través de los archivos AsciiDoc, no mediante herramientas externas

== Los Anti-Patterns : Lo que 150+ sesiones me han enseñado

Con el tiempo, algunos errores se han convertido en patrones tan predecibles que puedo enumerarlos como anti-patrones — trampas en las que probablemente caerá cualquier nuevo proyecto. Estos son, ordenados por frecuencia.

[plantuml, format=svg, id=diag-antipatterns, alt="Les 7 anti-patterns de la gouvernance agent — arbre des pièges à éviter"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 180

title Los 7 anti-patrones — Lo que 150+ sesiones me enseñaron
left to right direction

rectangle "⚠️ anti-patrón" as ROOT #FFCDD2 {

  together {
    card "**1. Agente sin**\n**opencode.json**" as AP1 #FFEBEE {
      (AGENT.adoc jamais chargé)
      (→ 20 min perdues/session)
    }

    card "**2. Demasiados agentes**\n**Demasiado temprano**" as AP2 #FFEBEE {
      (5 agents stubs vides)
      (→ L'agent hésite)
      (→ Seuil : 100 lignes\nou 5 règles concrètes)
    }

    card "**3. PROMPT_REPRISE**\n**Fantasma**" as AP3 #FFEBEE {
      (Mission a dérivé)
      (→ PROMPT_REPRISE\nne reflète pas la réalité)
    }
  }

  together {
    card "**4. Archivo**\n**Vacío**" as AP4 #FFEBEE {
      (Template rempli de\nplaceholders "todo")
      (→ « à compléter plus tard »\nn'arrive jamais)
    }

    card "**5. Cartera**\n**Fantasma**" as AP5 #FFEBEE {
      (Nouveau projet créé)
      (→ Pas ajouté aux\n4 autres INDEX.adoc)
      (→ Agent croit avoir\n4 projets, en fait 5)
    }

    card "**6. Redundancia**\n**Oculta**" as AP6 #FFEBEE {
      (Même backlog copié-collé)
      (→ AGENT.adoc et INDEX.adoc\ndivergent)
      (→ Règle : INDEX.adoc\n= source de vérité)
    }
  }

  card "**7. Sesión demasiado**\n**larga**" as AP7 #FFEBEE {
    (2h, 85 messages, 12 fichiers)
    (→ LLM répète erreurs corrigées)
    (→ Aurait dû splitter il y a 45 min)
  }
}

note right of AP7
  **Règle d'Or**
  5 × 20 min
  >
  1 × 2 heures

  Respecter SESSION_CHECKLIST
end note

@enduml
----

=== Anti-Pattern 1 : El agente sin `opencode.json

Es el error número uno. Ha escrito un magnífico`AGENT.adoc`de 200 líneas, pero nunca se carga automáticamente. El agente arranca desnudo. Pasas 20 minutos recontextualizándolo — exactamente lo que el método está supuestamente diseñado para evitar.

*Síntoma* : El agente plantea preguntas básicas sobre la estructura del proyecto mientras que todo está en`AGENT.adoc`. *Corrección* : Crear`opencode.json`con el bloque`instructions: ["AGENT.adoc"]`. Verificar que el archivo exista en el directorio de trabajo de Opencode.

=== Anti-Pattern 2 : Demasiados agentes demasiado pronto

En la sesión 2 de tu proyecto, creas 5 agentes especializados. Ninguno tiene contenido real, son todos stubs. Resultado :`.agents/`está contaminado de archivos vacíos, y el agente duda sobre cuál cargar.

*Síntoma* : Archivos de agente que contienen únicamente « Por definir » o una estructura vacía de 10 líneas. *Corrección* : Un agente especializado se justifica cuando su dominio de negocio supera las 100 líneas o codifica al menos 5 reglas concretas. Por debajo, el contenido cabe en`AGENT.adoc`.

=== Anti-Pattern 3 : El PROMPT_REPRISE Fantasma

`PROMPT_REPRISE.adoc`está actualizado... pero solo al final de la sesión, cuando el agente ejecuta el procedimiento. Mientras tanto, la misión real de la sesión se ha desviado — hemos corregido un bug imprevisto en lugar de implementar la feature planificada. El`PROMPT_REPRISE.adoc`de fin de sesión no refleja lo que *realmente* pasó.

*Síntoma* : La sección « Prioridades » de`PROMPT_REPRISE.adoc`menciona una característica que no ha sido tocada, mientras que has pasado la sesión en un bug crítico. *Corrección* : Actualizar`PROMPT_REPRISE.adoc`en tiempo real cuando la sesión se desvía de su misión inicial. No espere el procedimiento de fin de sesión para documentar el cambio de rumbo. 30 segundos de edición durante la sesión valen más que un`PROMPT_REPRISE`mentiroso.

=== Anti-Pattern 4 : El Archivo Vacío

El procedimiento de finalización de sesión crea el archivo... pero el agente, ansioso por mostrar su lista de verificación, completa la plantilla con marcadores de posición.`{detail}`devient « Detalle por completar más tarde ». Este « más tarde » nunca llega.

*Síntoma*: Archivos de sesión que contienen las palabras « TODO », « por completar », o secciones vacías. *Corrección* : La regla absoluta dice que ninguna etapa puede ser marcada [✅] si el archivo no ha sido realmente modificado. Aplíquela a usted mismo: relea el archivo antes de mostrar la lista de verificación. Si una sección está vacía, rellénela ahora.

=== Anti-Pattern 5 : Cartera Fantasma

[plantuml, format=svg, id=diag-portfolio-graph, alt="Graphe du portefeuille de projets — références croisées entre INDEX.adoc"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam nodeBackgroundColor #E3F2FD

title Portafolio de Proyectos — Referencias Cruzadas INDEX.adoc
node "**magic-stick**\nSesión 037\nVERIFICACIÓN_DE_SCRIPT" as MS #E1BEE7
node "**bakery-gradle**\nSesión 11\nCOBERTURA_DE_PRUEBAS" as BG #FFE0B2
node "**cheroliv.com**\nSesión 10\nCOBERTURA_DE_PRUEBAS" as CH #C8E6C9
node "**plantuml-gradle**\nSesión 133\nCOBERTURA_DE_PRUEBAS" as PG #BBDEFB
node "**jhipster-gradle**\nSesión 1 🆕\nCOBERTURA_DE_PRUEBAS" as JG #FFCDD2

MS --> BG : INDEX.adoc référence
MS --> CH : INDEX.adoc référence
MS --> PG : INDEX.adoc référence
MS --> JG : INDEX.adoc référence 🆕

BG --> MS : INDEX.adoc référence
BG --> CH : INDEX.adoc référence
BG --> PG : INDEX.adoc référence
BG --> JG : INDEX.adoc référence 🆕

CH --> MS : INDEX.adoc référence
CH --> BG : INDEX.adoc référence
CH --> PG : INDEX.adoc référence
CH --> JG : INDEX.adoc référence 🆕

PG --> MS : INDEX.adoc référence
PG --> BG : INDEX.adoc référence
PG --> CH : INDEX.adoc référence
PG --> JG : INDEX.adoc référence 🆕

JG --> MS : INDEX.adoc référence
JG --> BG : INDEX.adoc référence
JG --> CH : INDEX.adoc référence
JG --> PG : INDEX.adoc référence

note bottom of JG
  Quand on ajoute un projet :
  • 4 INDEX.adoc à mettre à jour
  • 1 ligne par portefeuille
  • Coût : 5 minutes
end note

legend bottom
  |= Couleur |= Projet |
  | <#E1BEE7> | magic-stick — ISO Linux live |
  | <#FFE0B2> | bakery-gradle — Plugin JBake |
  | <#C8E6C9> | cheroliv.com — Site personnel |
  | <#BBDEFB> | plantuml-gradle — Plugin IA |
  | <#FFCDD2> | jhipster-gradle — Mono-repo JHipster |
endlegend

@enduml
----

*Síntoma* : El recuento de proyectos en los portafolios no corresponde a la realidad. *Corrección* : Guioniza la actualización de la cartera, o al menos mantén una lista de verificación post-bootstrap que incluya « Actualizar la cartera de todos los proyectos existentes ». Es el paso más tedioso del método, y por lo tanto el que más se omite.

=== Anti-Patrón 6 : La Redundancia Oculta

Copias y pegas el mismo backlog de 50 líneas en`AGENT.adoc` et `INDEX.adoc`. En la siguiente sesión, actualiza uno pero no el otro. Sus dos archivos EAGER entran en conflicto.

*Síntoma* : Desviaciones entre los EPICs listados en`AGENT.adoc`y aquellas en`INDEX.adoc`. *Corrección* : La redundancia debe ser *asumida y acotada*.`AGENT.adoc`contiene el backlog detallado con historias de usuario.`INDEX.adoc`contiene ÚNICAMENTE la tabla resumen de los EPICs (nombre, progreso, prioridad). Si las dos divergen, es`INDEX.adoc`que sirve como referencia — porque es él quien se actualiza al final de cada sesión. Documente esta regla en su`AGENT.adoc` En caso de divergencia entre AGENT.adoc y INDEX.adoc, INDEX.adoc es la fuente de verdad.

=== Anti-Pattern 7 : La Sesión Demasiado Larga

Usted ignora las señales del`SESSION_CHECKLIST.adoc`. 2 horas, 85 mensajes, 12 archivos modificados. El agente está en bucle, usted también. Usted habría debido cambiar de sesión hace 45 minutos.

*Síntoma*: El LLM repite errores ya corregidos, el contexto de tokens supera los 80k, has modificado a la vez`persistence/` et `assistant/`en la misma sesión. *Corrección* : El`SESSION_CHECKLIST.adoc`Existe por una razón. Respetalo. La regla de oro no es una sugerencia. 5 sesiones de 20 minutos > 1 sesión de 2 horas.

== ¿Por qué AsciiDoc?

He elegido AsciiDoc por varias razones pragmáticas que tienen un impacto directo en la eficiencia de la gobernanza :

1. **Estructura semántica rica**: secciones, tablas, advertencias, atributos de documento. Un agente lee mejor un documento estructurado que un fondo de texto.
2. **Atributos de documento**(`:jbake-type:`, `:jbake-status:`) que permiten definir metadatos legibles tanto por máquinas como por humanos.
3. **Compatibilidad con JBake**: mi sitio estático es generado por JBake, que trata nativamente AsciiDoc. Los archivos de gobernanza y los artículos de blog comparten el mismo formato. Mi artículo de blog *sobre* la gobernanza está escrito en el mismo formato que la gobernanza misma.
4. **Longevidad**AsciiDoc es un formato de documentación técnica probado, con una especificación estable.

== Resultado : Una Continuidad sin Costura

Desde que puse este sistema en marcha, pasar de una sesión Opencode a otra se ha vuelto fluido. El agente continúa exactamente donde lo dejé, sin que tenga que volver a contextualizar nada.

Las decisiones tomadas en la sesión 3 son accesibles desde la sesión 133. El backlog permanece coherente en cinco proyectos simultáneos. Las reglas de seguridad (en particular sobre git y los archivos de configuración) se respetan porque están omnipresentes en el archivo Eager.

Los números hablan :

* **150+ sesiones archivadas**en total
* **60% de tokens EAGER ahorrados**después de la optimización (Session 109)
* **Cero recordatorio necesario**sobre el contexto empresarial del grupo de claves API
* **100% de los tests PASS**sobre plantuml-plugin (240/240)
* **Una sola catástrofe**(Session 2 bakery-plugin) que dio origen a la regla de seguridad absoluta

Es un**sistema artesanal**, construido con las herramientas del oficio (AsciiDoc, git, Gradle), sin dependencia de una plataforma propietaria. Refleja mi convicción fundamental:**un desarrollador creíble construye y utiliza sus propias herramientas**.

== Enlaces

* Mi sitio : [cheroliv.com](https://cheroliv.com)
* El proyecto`bakery-gradle`: [github.com/cheroliv/bakery-gradle-plugin](https://github.com/cheroliv/bakery-gradle-plugin)
* El proyecto`plantuml-gradle`: [github.com/cheroliv/plantuml-gradle-plugin](https://github.com/cheroliv/plantuml-gradle-plugin)
* El proyecto`magic-stick`: [github.com/cheroliv/magic-stick](https://github.com/cheroliv/magic-stick)
* El proyecto`cheroliv.com`: [github.com/cheroliv/cheroliv.github.io](https://github.com/cheroliv/cheroliv.github.io)

---

El código que escribimos para nosotros mismos es el laboratorio del código que enseñamos a los demás.

**Archivos de configuración**

* ❌ Nunca sobrescribir un archivo de configuración con un`Write`completo cuando un`Edit`parcial basta
* ❌ Nunca reemplazar valores sensibles por valores ficticios
* ❌ Verificar`git check-ignore` et `git ls-files`antes de cualquier modificación

**Tests**

* ❌ Nunca lanzar pruebas en un procedimiento de fin de sesión sin permiso explícito

**Herramientas Prohibidas**

* ❌`TodoWrite` et `Task`-- la gobernanza se realiza mediante los archivos AsciiDoc, no mediante herramientas externas

== Los Anti-Patterns: Lo Que Más de 150 Sesiones Me Han Enseñado

En perspectiva, ciertos errores se han convertido en patrones tan previsibles que puedo enumerarlos como anti-patrones — trampas en las que cualquier nuevo proyecto probablemente caerá. Aquí los tienes, ordenados por frecuencia.

[plantuml, format=svg, id=diag-antipatterns, alt="Les 7 anti-patterns de la gouvernance agent — arbre des pièges à éviter"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 180

title Los 7 antipatrones — Lo que 150+ sesiones me han enseñado
left to right direction

rectangle "⚠️ ANTI-PATRONES" as ROOT #FFCDD2 {

  together {
    card "**1. Agente sin**\n**opencode.json**" as AP1 #FFEBEE {
      (AGENT.adoc jamais chargé)
      (→ 20 min perdues/session)
    }

    card "**2. Demasiados agentes**\n**Demasiado pronto**" as AP2 #FFEBEE {
      (5 agents stubs vides)
      (→ L'agent hésite)
      (→ Seuil : 100 lignes\nou 5 règles concrètes)
    }

    card "**3. PROMPT_REANUDACIÓN**\n**Fantasma**" as AP3 #FFEBEE {
      (Mission a dérivé)
      (→ PROMPT_REPRISE\nne reflète pas la réalité)
    }
  }

  together {
    card "**4. Archivo**\n**Vacío**" as AP4 #FFEBEE {
      (Template rempli de\nplaceholders "IVA incluido")
      (→ « à compléter plus tard »\nn'arrive jamais)
    }

    card "**5. Cartera**\n**Fantasma**" as AP5 #FFEBEE {
      (Nouveau projet créé)
      (→ Pas ajouté aux\n4 autres INDEX.adoc)
      (→ Agent croit avoir\n4 projets, en fait 5)
    }

    card "**6. Redundancia**\n**Oculta**" as AP6 #FFEBEE {
      (Même backlog copié-collé)
      (→ AGENT.adoc et INDEX.adoc\ndivergent)
      (→ Règle : INDEX.adoc\n= source de vérité)
    }
  }

  card "**7. Sesión Demasiado**\n**Larga**" as AP7 #FFEBEE {
    (2h, 85 messages, 12 fichiers)
    (→ LLM répète erreurs corrigées)
    (→ Aurait dû splitter il y a 45 min)
  }
}

note right of AP7
  **Règle d'Or**
  5 × 20 min
  >
  1 × 2 heures

  Respecter SESSION_CHECKLIST
end note

@enduml
----

=== Anti-Pattern 1: El agente sin `opencode.json

Es el error número uno. Has escrito un magnífico`AGENT.adoc`de 200 líneas, pero nunca se carga automáticamente. El agente arranca desnudo. Pasas 20 minutos recontextualizándolo — exactamente lo que el método debería evitar.

*Síntoma* : El agente plantea preguntas básicas sobre la estructura del proyecto mientras que todo está en`AGENT.adoc`. *Corrección*: crear`opencode.json`con el bloque`instructions: ["AGENT.adoc"]`. Verificar que el archivo existe en el directorio de trabajo de Opencode.

=== Anti-Pattern 2 : demasiado agentes demasiado temprano

En la sesión 2 de tu proyecto, creas 5 agentes especializados. Ninguno tiene contenido real, todos son stubs. Resultado :`.agents/`está lleno de archivos vacíos, y el agente duda qué cargar.

* Síntoma* : Archivos de agente conteniendo únicamente « Por definir » o una estructura vacía de 10 líneas. *Corrección*: Un agente especializado se justifica cuando su dominio profesional supera las 100 líneas o codifica al menos 5 reglas concretas. Por debajo, el contenido cabe en`AGENT.adoc`.

=== Anti-Pattern 3 : El PROMPT_REPRISE Fantasma

`PROMPT_REPRISE.adoc`actualizado... pero solo al final de la sesión, cuando el agente ejecuta el procedimiento. Mientras tanto, la misión real de la sesión se ha desviado — se ha corregido un error imprevisto en lugar de implementar la característica planificada. El`PROMPT_REPRISE.adoc`de fin de sesión no refleja lo que *realmente* pasó.

*Síntoma* : La sección « Prioridades » de`PROMPT_REPRISE.adoc`menciona una feature que no ha sido tocada, mientras que has pasado la sesión en un bug crítico. *Corrección* : Actualizar`PROMPT_REPRISE.adoc`en tiempo real cuando la sesión se desvía de su misión inicial. No esperar el procedimiento de fin de sesión para documentar el cambio de rumbo. 30 segundos de edición durante la sesión valen más que un`PROMPT_REPRISE`falso.

=== Antipatrón 4: el archivo vacío

El procedimiento de fin de sesión crea el archivo... pero el agente, ansioso por mostrar su lista de verificación, llena la plantilla con marcadores de posición.`{detail}`se convierte « Detalle por completar más tarde ». Este « más tarde » nunca llega.

* Síntoma* : Archivos de sesión que contienen las palabras « TODO », « por completar », o secciones vacías. *Corrección* : La regla absoluta establece que ningún paso puede marcarse [✅] si el archivo no ha sido realmente modificado. Aplíquelo usted mismo: revise el archivo antes de mostrar la lista de verificación. Si una sección está vacía, complétela ahora.

=== Anti-Patrón 5 : La Cartera Fantasma

Creas un nuevo proyecto con una gobernanza perfecta. Pero olvidas añadirlo al portafolio de los otros proyectos. Tres semanas después, abres una sesión sobre`magic-stick`y el agente te dice que tienes 4 proyectos. Tienes 5. El agente no lo sabe.

*Síntoma* : El recuento de proyectos en las carteras no corresponde a la realidad. *Corrección* : Escriba el script de actualización del portafolio, o al menos mantenga una checklist post-bootstrap que incluya « Actualizar el portafolio de todos los proyectos existentes ». Es el paso más tedioso del método, y por lo tanto el más frecuentemente omitido.

=== Anti-Pattern 6 : La redundancia oculta

Copia y pega el mismo backlog de 50 líneas en`AGENT.adoc` et `INDEX.adoc`. En la sesión siguiente, actualizas uno pero no el otro. Tus dos archivos EAGER se contradicen.

*Síntoma* : Discrepancias entre los EPICs enumerados en`AGENT.adoc`y esas en`INDEX.adoc`. *Corrección* : La redundancia debe ser *asumida y acotada*.`AGENT.adoc`contiene el backlog detallado con historias de usuario.`INDEX.adoc`contiene ÚNICAMENTE el cuadro resumen de los EPIC (nombre, progreso, prioridad). Si los dos divergen, es`INDEX.adoc`que tiene validez — porque es él que se actualiza al final de cada sesión. Documenta esta regla en tu`AGENT.adoc`: « En caso de discrepancia entre AGENT.adoc e INDEX.adoc, INDEX.adoc es la fuente de verdad.

=== Anti-Patrón 7 : La Sesión Demasiado Larga

Usted ignora las señales del`SESSION_CHECKLIST.adoc`. 2 horas, 85 mensajes, 12 archivos modificados. El agente está en bucle, tú también. Deberías haber cambiado de sesión hace 45 minutos.

*Síntoma* : El LLM repite errores ya corregidos, el contexto de tokens supera los 80k, has modificado tanto`persistence/` et `assistant/`en la misma sesión. *Correction* : El`SESSION_CHECKLIST.adoc`Existe por una razón. Respétalo. La regla de oro no es una sugerencia. 5 sesiones de 20 minutos > 1 sesión de 2 horas.

== ¿Por qué AsciiDoc?

He elegido AsciiDoc por varias razones pragmáticas que tienen un impacto directo en la eficacia de la gobernancia :

1. **Estructura semántica rica**: secciones, tablas, advertencias, atributos de documento. Un agente lee mejor un documento estructurado que un fondo de texto.
2. **Atributos de documento**(`:jbake-type:`, `:jbake-status:`) que permiten definir metadatos legibles por máquinas y por humanos.
3. **Compatibilidad con JBake**: mi sitio estático es generado por JBake, que procesa nativamente AsciiDoc. Los archivos de gobernanza y las entradas de blog comparten el mismo formato. Mi entrada de blog *sobre* la gobernanza está escrita en el mismo formato que la gobernanza misma.
4. **longevidad**: AsciiDoc es un formato de documentación técnica probado, con una especificación estable.

== Resultado: Una continuidad sin costuras

Desde que instalé este sistema, pasar de una sesión de Opencode a otra se ha vuelto fluido. El agente retoma exactamente donde lo dejé, sin que tenga que recontextualizar nada.

Las decisiones tomadas en la sesión 3 son accesibles en la sesión 133. El backlog sigue siendo coherente en cinco proyectos simultáneos. Las reglas de seguridad (especialmente en git y los archivos de configuración) se respetan porque están omnipresentes en el archivo Eager.

Los números hablan:

* **150+ sesiones archivadas**en total
* **60% de tokens EAGER ahorrados**después de la optimización (Sesión 109)
* **Cero recordatorio necesario**sobre el contexto de negocio del grupo de claves API
* **100% de las pruebas PASS**en plantuml-plugin (240/240)
* **Una sola catástrofe**(Sesión 2 bakery-plugin) que dio origen a la regla de seguridad absoluta

Es un**sistema artesanal**, construido con las herramientas del oficio (AsciiDoc, git, Gradle), sin dependencia de una plataforma propietaria. Refleja mi convicción fundamental :**un desarrollador creíble construye y utiliza sus propias herramientas**.

== enlaces

* Mi sitio : [cheroliv.com](https://cheroliv.com)
* El proyecto`bakery-gradle`: [github.com/cheroliv/bakery-gradle-plugin](https://github.com/cheroliv/bakery-gradle-plugin)
* El proyecto`plantuml-gradle`: [github.com/cheroliv/plantuml-gradle-plugin](https://github.com/cheroliv/plantuml-gradle-plugin)
* El proyecto`magic-stick`: [github.com/cheroliv/magic-stick](https://github.com/cheroliv/magic-stick)
* El proyecto`cheroliv.com`:[github.com/cheroliv/cheroliv.github.io](https://github.com/cheroliv/cheroliv.github.io)

---

*El código que escribimos para nosotros es el laboratorio del código que enseñamos a otros.*
----

**`*_ESSENTIALS.adoc`** -- Una adición reciente (Sesión 109, plantuml-plugin) para optimizar aún más el contexto Eager. En lugar de cargar 200 líneas de contexto de negocio sobre el pool de claves API, cargo 50 líneas de lo esencial, y las otras 150 líneas permanecen en LAZY en`*_REFERENCE.adoc`Please provide the text you would like me to translate.

Resultado medido: paso de**~25k tokens EAGER a ~10k tokens**(ganancia del 60%). El agente ya no necesita recordatorios que consumen mucha energía.

==== El Eslabón Perdido: `opencode.json

Debo confesarle una cosa que casi olvido documentar. Por encima de todos estos archivos .adoc, hay un minúsculo archivo JSON sin el cual nada funciona. Se llama`opencode.json`y tiene seis líneas. Literalmente seis líneas.

[source,json]
----
{
  "$schema": "https://opencode.ai/config.json",
  "instructions": [
    "AGENT.adoc"
  ]
}
----

Es este archivo el que le dice a Opencode: «Al iniciar, carga`AGENT.adoc`automáticamente». Sin él, el agente es una página en blanco exactamente como lo describía al principio del artículo. Con él, el agente ya tiene en sus manos las reglas absolutas, la arquitectura del proyecto y los comandos esenciales, incluso antes de que yo diga hola.

Descubrí la importancia de este archivo por casualidad. En`bakery-plugin`, no existía. Me preguntaba por qué el agente estaba sistemáticamente más «perdido» en este proyecto que en los otros. Las reglas absolutas estaban efectivamente en`AGENT.adoc`— pero`AGENT.adoc`nunca se cargaba. El agente solo leía lo que yo le decía que leyera, manualmente, en cada sesión. Era la sesión 11 de`bakery-plugin`cuando me di cuenta de la ausencia del`opencode.json`. Lo creé — y la sesión 12 comenzó como las demás.

Este archivo es tan evidente para mí ahora que ya ni siquiera pensaba en él. Un error clásico del desarrollador que conoce demasiado su herramienta. Hoy en día, lo creo sistemáticamente *antes*`AGENT.adoc`. Es la primera piedra.

==== La Dualidad de `INDEX.adoc

Otra sutileza que merece ser explicitada:`INDEX.adoc`vive en`.agents/`— una carpeta que presenté como `LAZY`. Sin embargo, la listo como `EAGER` en todas mis tablas. Hay una tensión aparente aquí.

La realidad del terreno: los archivos`.agents/INDEX.adoc`se cargan automáticamente al inicio de la sesión, al igual que`AGENT.adoc` et `PROMPT_REPRISE.adoc`. Están en`.agents/`por razones de organización — para no invadir la raíz — pero su comportamiento es EAGER.

Sobre`plantuml-plugin`, `INDEX.adoc`tiene 200 líneas y contiene las reglas absolutas *completas* con su historial (las lecciones de sesiones pasadas), los EPICs con puntuaciones y la cartera de proyectos. Es el documento que el agente consulta para saber «en qué punto estamos». Sobre`bakery-plugin`, tiene 150 líneas con la roadmap y las sesiones recientes.

La redundancia voluntaria entre`AGENT.adoc` et `INDEX.adoc`puede sorprender. Las reglas absolutas están presentes en ambos. ¿Por qué? Porque cumplen dos funciones diferentes: en`AGENT.adoc`, son *explicativas* (el storytelling de la regla, la lección aprendida); en`INDEX.adoc`, son *ejecutivas* (la regla pura, sin justificación, para una consulta rápida). El agente lee`AGENT.adoc`una vez para *comprender*; vuelve a leer`INDEX.adoc`en cada sesión para *aplicar*. Dos usos, dos formatos.

[plantuml, format=svg, id=diag-dualite-agent-index, alt="Comparaison entre AGENT.adoc (narratif) et INDEX.adoc (exécutif)"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center

title Dualidad AGENT.adoc ←→ INDEX.adoc
left to right direction

rectangle "AGENT.adoc\n(Raíz — EAGER)" as AGENT #E3F2FD {
  rectangle "📖 **Formato Narrativo**\nEl storytelling de la regla\nla lección aprendida, el contexto" as NARR
  rectangle "🏗️ **Arquitectura Completa**\nEstructura del proyecto, componentes\nBacklog detallado US" as ARCHI
  rectangle "📋 **Reglas Explicativas**\nPor qué existe la regla\nHistorial del incidente" as EXPL
}

rectangle "INDEX.adoc\n(.agents/ — EAGER)" as INDEX #E8F5E9 {
  rectangle "⚡ **Formato Ejecutivo**\nLa regla pura, sin justificación\nConsulta rápida" as EXEC
  rectangle "📊 **Roadmap & EPICs**\nCuadro resumen\nProgreso, Puntuación, Prioridad" as ROAD
  rectangle "🌐 **Portafolio de Proyectos**\nVista transversal\n5 proyectos sincronizados" as PORT
}

AGENT --> INDEX : "El agente lee AGENT.adoc\n1 vez para **comprender**"
INDEX --> AGENT : "El agente relee INDEX.adoc\ncada sesión para **aplicar**"

note bottom of AGENT
Tamaño máx.: 200 líneas
end note

note bottom of INDEX
Tamaño máx.: 200 líneas
  Source de vérité en cas de divergence
end note

@enduml
----

Esta redundancia asumida es una elección de diseño. Consume ~50 líneas adicionales de tokens EAGER — pero garantiza que el agente siempre tenga las reglas a la vista, incluso en el formato conciso que facilita la obediencia inmediata.

=== Los Archivos LAZY: El Manual del Propietario

Estos archivos residen en`.agents/`y solo se leen cuando el agente los necesita. Constituyen la verdadera riqueza del método, ya que acumulan el conocimiento del proyecto sin contaminar el contexto actual.

[plantuml, format=svg, id=diag-agents-tree, alt="Arborescence complète du dossier .agents/"]
----
@startuml
skinparam folderBackgroundColor #E3F2FD
skinparam folderBorderColor #1565C0
skinparam fileBackgroundColor #FFF3E0
skinparam fileBorderColor #EF6C00

folder ".agents/" as ROOT {
  file "INDEX.adoc\n(EAGER -- 200 líneas)" as IDX #E8F5E9
  file "AGENT_SESSION_MANAGER.adoc\n(Plantilla de sesión)" as ASM
  file "SESSION_CHECKLIST.adoc\n(Cuándo cambiar)" as CHK
  file "PROCEDURES.adoc\n(6 pasos + LAZY/EAGER)" as PRO
  file "SESSIONS_HISTORY.adoc\n(Todas las sesiones)" as HIS

  folder "sessions/" as SESS {
    file "1-chore-migration.adoc" as S1
    file "109-formalisation-lazy.adoc" as S109 #FFECB3
    file "133-epic11-article.adoc" as S133
    file "... +130 otros" as SMORE
  }

  folder "archives/" as ARCH {
    file "COMPLETED_TASKS_2026-04.adoc" as CTA
    file "SESSIONS_HISTORY_83-95.adoc" as SHIST
    folder "sessions_summaries/" as SUM {
      file "SESSION_64_SUMMARY.adoc" as SU64
      file "SESSION_73_SUMMARY.adoc" as SU73
      file "..." as SUMORE
    }
    folder "prompts_archive/" as PARCH {
      file "PROMPT_REPRISE_S65.adoc" as PR65
      file "PROMPT_REPRISE_S75.adoc" as PR75
      file "..." as PMORE
    }
  }
}

IDX --> SESS : "Índice"
IDX --> HIS : "Índice"
IDX --> ARCH : "Referencia"

note right of S109
Sesión 109 =
Formalización estrategia
LAZY/EAGER
Token : ~25k → ~10k
end note

@enduml
----

El árbol anterior muestra la estructura real de la carpeta`.agents/`sobre`plantuml-plugin`, el proyecto más maduro. Note la profundidad en tres capas: archivos raíz (metadatos), carpeta`sessions/`(archivos cronológicos) y carpeta`archives/`(agregaciones y resúmenes). Es esta profundidad la que transforma la gobernanza de un simple archivo TODO en una**memoria organizacional completa**Please provide the text you would like me to translate.

**.agents/sessions/{N}-{titre}.adoc**-- Los archivos detallados de cada sesión. Actualmente:

* `plantuml-plugin`Please provide the text you would like me to translate.**133 sesiones archivadas**(de la sesión 1 a 133)
* `bakery-plugin`Please provide the text you would like me to translate.**11 sesiones**
* `magic-stick`Please provide the text you would like me to translate.**23 sesiones**
* `cheroliv.com`Please provide the text you would like me to translate.**9 sesiones formales**+ 7 sesiones pre-sistema reconstituidas retroactivamente

Cada archivo contiene el contexto completo de la sesión, las decisiones tomadas, los problemas encontrados y su resolución, los comandos ejecutados y su output.

**.agents/SESSIONS_HISTORY.adoc**-- Una tabla resumen de todas las sesiones con una puntuación. Ejemplo en`cheroliv.com`Please provide the text you would like me to translate.

| -6 | 2025-05 | chore | Initialisation projet Gradle/JBake | 7/10
|  1 | 2026-04-25 | chore | Migration gouvernance agent | 8/10
|  7 | 2026-04-27 | debug/fix | Correction publishSite | 9/10
|  8 | 2026-04-27 | analyse | Analyse article 0108 | 7/10

----
{N}-{type}-{sujet-kebab-case}.adoc
----

Ejemplos concretos:

* `1-chore-migration-gouvernance-agent.adoc`— sesión 1, tipo chore
* `10-solidification-tests.adoc`— sesión 10, sin tipo explícito (el sujeto es suficiente)
* `036-debug-graphify-symlink-epic9.adoc`— sesión 36 con número de 3 dígitos para la clasificación

El número de sesión es el criterio de ordenación principal. Los proyectos que utilizan números de 3 dígitos (001, 036, 133) evitan los problemas de ordenación lexicográfica cuando se supera el 99. Es lo que utilizo ahora en`magic-stick`Please provide the text you would like me to translate.`001-init-projet.adoc`, `036-debug-graphify-symlink-epic9.adoc`Please provide the text you would like me to translate.

El tipo es opcional y se deriva de las palabras clave de la sesión (debug, feature, refactor, docs, chore, test). El asunto en kebab-case es la parte más importante: debe permitir encontrar una sesión sin abrir el archivo. Si se pregunta «¿cuál era la sesión en la que corregimos el timeout de las pruebas de integración?», la respuesta es`124-fix-timeout-integration-test.adoc`Please provide the text you would like me to translate.

Para las sesiones históricas reconstruidas (proyectos nacidos antes de la gobernanza), utilizo números negativos. Sobre`cheroliv.com`, las sesiones -6 a 0 cubren toda la historia previa a la gobernanza del proyecto. Y para las sesiones «no documentadas» o perdidas, creo una entrada en`SESSIONS_HISTORY.adoc`sin archivo correspondiente, con una puntuación`?`. Es más honesto que fingir.

[plantuml, format=svg, id=diag-naming-convention, alt="Arbre de décision pour le nommage des fichiers de session"]
----
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam wrapWidth 200

title Convención de Nomenclatura de Sesiones
start

:Une session se termine;
note right: Trigger "fin de sesión"

if (Session antérieure\nà la gouvernance ?) then (oui)
  :Numéro **NÉGATIF**\n-6, -5 ... 0;
  note right: Historial\nreconstituido
  :Suffixe : reconstitution;
else (non)
  :Numéro **POSITIF**\nsur 3 chiffres si > 99;
  note right: 001, 036, 133\npara la ordenación lexicográfica

  :Détecter le **TYPE**;
  if (Mots-clés trouvés ?) then (oui)
    :debug / feature / refactor\ndocs / chore / test;
  else (non)
    :Omettre le type\n(le sujet suffit);
  endif

  :Formuler le **SUJET** en kebab-case;
  note right
fix-timeout-integration-test
Debe permitir encontrar
sin abrir el archivo
  end note
endif

:Nom final : {N}-{type}-{sujet}.adoc;
note right
  • 1-chore-migration-gouvernance.adoc
  • 036-debug-graphify-symlink.adoc
  • 124-fix-timeout-integration-test.adoc
  • 133-epic11-article-blog-kg.adoc
end note

if (Session documentée ?) then (oui)
  :Créer archive dans sessions/;
  :Ajouter ligne SESSIONS_HISTORY\navec score X/10;
else (non)
  :Ajouter ligne SESSIONS_HISTORY\navec score **?**\n**sans archive**;
  note right: La honestidad\nen lugar del vacío
endif

stop
@enduml
----

==== TEST_COVERAGE_ANALYSIS.adoc` — El Paso 5 Detallado

El paso 5 del procedimiento de cierre de sesión es el más misterioso. Dice «Actualizar`TEST_COVERAGE_ANALYSIS.adoc`si se han añadido o modificado pruebas. » Pero, ¿cómo es este archivo?

Sobre`plantuml-plugin`, ha evolucionado de unas pocas líneas a una estructura completa. He aquí su forma estabilizada:

[source]
----
= Analyse de Couverture de Tests

== Suivi des Tests
|===
| Classe de test | Type | Tests | Statut | Dernière MAJ
| PlantumlServiceTest | unit | 45/45 | ✅ PASS | 2026-04-23
| ApiKeyPoolTest | integration | 15/15 | ✅ PASS | 2026-04-20
|===

== Historique par Session
| Session | Tests ajoutés | Tests modifiés | Couverture
| 133     | 0             | 2              | 100%
| 132     | 5             | 0              | 100%
|===
----

El interés no es el archivo en sí — es la obligación de *anotar* qué ha cambiado. Sin este paso, después de 50 sesiones, ya no sabes qué pruebas cubren qué. El agente tampoco. El archivo se convierte en el repositorio único de verdad sobre la cobertura de pruebas del proyecto.

Para los proyectos sin pruebas tradicionales (como`magic-stick`que prueba scripts de bash), el paso 5 se sustituye por`SCRIPT_VERIFICATION.adoc`El mecanismo es el mismo: un archivo que sigue el estado de validación de los scripts. Adapte el paso 5 a su proyecto, pero nunca lo omita. Es la red de seguridad que evita la regresión silenciosa.

Si su proyecto no tiene *ningún* test —ni unitario, ni funcional, ni script— cree de todos modos el archivo vacío con una sección «Tareas pendientes: definir una estrategia de prueba». Es un marcador que le recordará a su yo futuro que este tema no ha sido abordado.

[plantuml, format=svg, id=diag-session-flow, alt="Flux d'une session type avec Eager/Lazy et agents"]
----
@startuml
skinparam backgroundColor #FEFEFE

start

:Début session;
note right: El agente es una página en blanco

:Chargement EAGER auto;
note right
* AGENT.adoc (reglas absolutas)
* PROMPT_REPRISE.adoc (misión N)
* INDEX.adoc (estado del proyecto)
end note

if (Mission claire ?) then (oui)
  :Exécution directe;
else (non)
  :Charge LAZY sur demande;
  note right
* SESSIONS_HISTORY.adoc (contexto pasado)
* sessions/{N-1}-*.adoc (decisiones)
* *_REFERENCE.adoc (arquitectura)
  end note
endif

:Délégation agent spécialisé ?;

if (CODER ?) then (oui)
  :Lit CODER.adoc;
  :Suit conventions FTL/CSS;
elseif (SCRUM Master ?) then (oui)
  :Lit SCRUM_MASTER.adoc;
  :Structure livrable imposée;
elseif (PlantUML ?) then (oui)
  :Lit PLANTUML_DESIGNER.adoc;
  :Syntaxe PUML + intégration;
else (non)
endif

:Travail de la session;

:Fin de session (trigger utilisateur);

:Procédure 6 étapes;
note right
1. Archivar sesiones/N-*.adoc
2. Act. PROMPT_REPRISE.adoc (N+1)
3. Act. SESSIONS_HISTORY.adoc
4. Act. INDEX.adoc
5. Act. TEST_COVERAGE (si aplica)
6. Act. COMPLETED_TASKS_ARCHIVE.adoc
end note

:Checklist [✅] x 6;

stop
@enduml
----

El diagrama anterior muestra el ciclo de vida completo de una sesión. El punto clave es la bifurcación después de la carga EAGER: o bien la misión es lo suficientemente clara para ejecutarse directamente (80% de los casos), o bien el agente carga LAZY para resolver una ambigüedad (20% de los casos). Es esta discriminación lo que ahorra tokens.

== El Procedimiento de Fin de Sesión: La Regla de Oro

=== Por qué es imprescindible

Sin este procedimiento, la estrategia Eager/Lazy no sirve para nada. Es este el que transforma el trabajo de la sesión en información persistente. Se ejecuta**a petición explícita del usuario**(palabras clave: "fin de sesión", "me salgo", etc.), y ella es**obligatorio**-- ninguna excepción, ninguna omisión.

El archivo`SESSION_CHECKLIST.adoc`define las métricas de sesión ideal:

* Duración: 15-30 minutos
* Archivos modificados: 1-3 máximo
* Intercambios de LLM: 5-10 mensajes
* Contexto de tokens: < 50k

Y señales de que es necesario cambiar de sesión: _El LLM repite errores ya corregidos_, _Más de 3 archivos modificados en paralelo_, _Conversación > 50 mensajes_. La regla de oro:**Es mejor hacer 5 sesiones de 20 minutos que una sesión de 2 horas con debugging chaos.**

=== El Flujo de los 6 Pasos (Silenciosamente)

[plantuml, format=svg, id=diag-end-session-flow, alt="Flux de la procédure de fin de session"]
----
@startuml
skinparam defaultTextAlignment center
skinparam wrapWidth 200
skinparam activityBackgroundColor #E3F2FD

start
:L'utilisateur dit "fin de sesión";
note right: Palabras clave activadoras

:Agent détecte le trigger;

:Étape 1\nCréer archive\n`.agents/sessions/N-*.adoc`;
note right: Todo el contexto de la sesión

:Étape 2\nMettre à jour\n`PROMPT_REPRISE.adoc`;
note right: Misión N + criterios de aceptación N+1

:Étape 3\nMettre à jour\n`SESSIONS_HISTORY.adoc`;
note right: Línea resumen: # / Fecha / Tipo / Asunto / Puntuación

:Étape 4\nMettre à jour\n`INDEX.adoc`;
note right: Estado actual, hoja de ruta, archivos modificados

:Étape 5\nMettre à jour\n`TEST_COVERAGE_ANALYSIS.adoc`;
note right: Si se han añadido o modificado tests

:Étape 6\nMettre à jour\n`COMPLETED_TASKS_ARCHIVE.adoc`;
note right: Archivar tareas completadas

:Afficher la checklist de confirmation;
note right: Verificar que cada [✅] sea merecido

stop
@enduml
----

=== Los Resultados de 150+ Sesiones

Esto es lo que resulta de aplicar este procedimiento sistemáticamente en mis cuatro proyectos:

**plantuml-plugin**Please provide the text you would like me to translate.

* **133 sesiones**desde el inicio del proyecto
* **240/240 pruebas PASADAS**(100% cobertura) -- EPICs 1-7 terminadas
* **57 escenarios de Cucumber BDD**validados
* Regla de seguridad sobre los archivos de config nacida de un error real (Session 2 bakery-plugin)

**bakery-plugin**Please provide the text you would like me to translate.

* **11 sesiones**en dos semanas
* Migración de Supabase → Firebase completada (9 pruebas corregidas)
* EPIC 6 (publishProfile) funcional en producción
* Regla 0 creada:`publishToMavenLocal`obligatorio después de cada modif

**varita-mágica**Please provide the text you would like me to translate.

* **23 sesiones**para construir un sistema live de Xubuntu con partición A/B
* Primera ISO generada en la sesión 10
* Pruebas de boot de QEMU + VNC formalizadas (documentación LAZY de 144 líneas)
* CI/CD SourceForge funcional

**cheroliv.com**Please provide the text you would like me to translate.

* **9 sesiones formales**+ reconstitución de 7 sesiones pre-sistema
* Artículo 0101 (OpenCode PATH) publicado
* Artículo 0108 (este) reescrito tras el análisis de sus deficiencias
* Gobernanza completa migrada de Markdown a AsciiDoc

=== La Lista de Verificación Final

Tras la ejecución silenciosa de los 6 pasos, el agente debe mostrar una lista de verificación de confirmación:

✅ Procédure de fin de session exécutée
📋 Checklist :
[✅] 1. Archive session N créée
[✅] 2. PROMPT_REPRISE.adoc mis à jour pour session N+1
[✅] 3. SESSIONS_HISTORY.adoc mis à jour
[✅] 4. INDEX.adoc mis à jour
[✅] 5. TEST_COVERAGE_ANALYSIS.adoc mis à jour (si applicable)
[✅] 6. COMPLETED_TASKS_ARCHIVE.adoc mis à jour

mkdir -p .agents/sessions .agents/archives

= {NOM_PROJET} — Directives Agent

[CAUTION]

@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam nodeBackgroundColor #E3F2FD

title Cartera de Proyectos — Referencias Cruzadas INDEX.adoc
node "**magic-stick**\nSesión 037\nSCRIPT_VERIFICATION" as MS #E1BEE7
node "**bakery-gradle**\nSesión 11\nTEST_COVERAGE" as BG #FFE0B2
node "**cheroliv.com**\nSesión 10\nTEST_COVERAGE" as CH #C8E6C9
node "**plantuml-gradle**\nSesión 133\nTEST_COVERAGE" as PG #BBDEFB
node "**jhipster-gradle**\nSesión 1 🆕\nTEST_COVERAGE" as JG #FFCDD2

MS --> BG : INDEX.adoc référence
MS --> CH : INDEX.adoc référence
MS --> PG : INDEX.adoc référence
MS --> JG : INDEX.adoc référence 🆕

BG --> MS : INDEX.adoc référence
BG --> CH : INDEX.adoc référence
BG --> PG : INDEX.adoc référence
BG --> JG : INDEX.adoc référence 🆕

CH --> MS : INDEX.adoc référence
CH --> BG : INDEX.adoc référence
CH --> PG : INDEX.adoc référence
CH --> JG : INDEX.adoc référence 🆕

PG --> MS : INDEX.adoc référence
PG --> BG : INDEX.adoc référence
PG --> CH : INDEX.adoc référence
PG --> JG : INDEX.adoc référence 🆕

JG --> MS : INDEX.adoc référence
JG --> BG : INDEX.adoc référence
JG --> CH : INDEX.adoc référence
JG --> PG : INDEX.adoc référence

note bottom of JG
Cuando se añade un proyecto:
• 4 INDEX.adoc para actualizar
• 1 línea por cartera
• Coste: 5 minutos
end note

legend bottom
  |= Couleur |= Projet |
  | <#E1BEE7> | magic-stick — ISO Linux live |
  | <#FFE0B2> | bakery-gradle — Plugin JBake |
  | <#C8E6C9> | cheroliv.com — Site personnel |
  | <#BBDEFB> | plantuml-gradle — Plugin IA |
  | <#FFCDD2> | jhipster-gradle — Mono-repo JHipster |
endlegend

@enduml