Governar um Agente de IA com AsciiDoc: Minha Estratégia Eager/Lazy para Sessões Opencode sem Vazamento de Contexto

@startuml
skinparam backgroundColor #FEFEFE
skinparam handwritten false

title Evolução das Sessões — Da Sessão 1 a 150+
legend top
    |= Couleur |= Projet |
    | <#4CAF50> | cheroliv.com |
    | <#2196F3> | plantuml-plugin |
    | <#FF9800> | bakery-plugin |
    | <#9C27B0> | magic-stick |
endlegend

concise "Sessões Ativas" as S

@S
0 is ".md bruto"
1 is "Migração\nAsciiDoc"
10 is "Eager/Lazy\nformalizado"
62 is "Regra de segurança\n(site.yml)"
87 is "Quebra de\ncontexto"
109 is "Otimização\n-60% tokens"
133 is "133 sessões\n240 testes 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 "Raiz do Projeto (Eager - Auto-carregado)" {
    component "<b>AGENT.adoc</b>\nRegras absolutas\nEstrutura & Convenções" as AGENT
    component "<b>PROMPT_REPRISE.adoc</b>\nMissão da sessão N\nResumo N-1" as PROMPT
    component "<b>INDEX.adoc</b>\nPonto de entrada\nRegras + Sessões" as INDEX
    component "<b>*_ESSENTIALS.adoc</b>\nContexto de negócio\ncrítico" as ESS
}

package ".agents/ (Lazy - Carregado sob demanda)" {
    component "<b>sessions/N-*.adoc</b>\nArquivos detalhados\nDecisões & Output" as SESS
    component "<b>SESSIONS_HISTORY.adoc</b>\nTabela recapitulativa\nData/Tipo/Score" as HIST
    component "<b>PROCEDURES.adoc</b>\nTemplates de fim de sessão\n6 etapas\n" as PROC
    component "<b>*_REFERENCE.adoc</b>\nArquitetura completa\nReferências técnicas" as REF
    component "<b>COMPLETED_TASKS_ARCHIVE</b>\nTarefas concluídas\nPor mês" as ARCH
    component "<b>AGENT_MODUS_OPERANDI.adoc</b>\nDocumentação de estratégia\nMetodologia" as MOD
    component "<b>*_REFERENCE.adoc</b>\nBoot tests, A/B partition\nContextos específicos" as SPEC
}

AGENT --> PROMPT : "Referências"
AGENT --> INDEX : "Referências"
INDEX --> SESS : "Índice"
INDEX --> HIST : "Índice"
INDEX --> PROC : "Referência"
INDEX --> ARCH : "Referência"
INDEX --> REF : "Referência"
PROMPT --> SESS : "Arquivo N-1"
PROMPT --> ESS : "Contexto de negócio 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 |
----

**`*_ESSENTIALS.adoc`** -- Uma adição recente (Sessão 109, plantuml-plugin) para otimizar ainda mais o contexto Eager. Em vez de carregar 200 linhas de contexto de negócio no pool de chaves API, carrego 50 linhas do essencial, e as outras 150 linhas permanecem em LAZY em`*_REFERENCE.adoc`Please provide the text you would like me to translate.

Resultado medido: passagem de**~25k tokens EAGER para ~10k tokens**(ganho de 60%). O agente não precisa mais de lembretes que consomem muita energia.

==== O Elo Perdido: `opencode.json

Devo confessar-lhe uma coisa que quase esqueci de documentar. Acima de todos esses arquivos .adoc, há um minúsculo arquivo JSON sem o qual nada funciona. Ele se chama`opencode.json`e tem seis linhas. Literalmente seis linhas.

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

É este arquivo que diz ao Opencode: « Na inicialização, carregue`AGENT.adoc`automaticamente. » Sem ele, o agente é uma página em branco exatamente como eu descrevia no início do artigo. Com ele, o agente já tem em mãos as regras absolutas, a arquitetura do projeto e os comandos essenciais — antes mesmo de eu dizer olá.

Descobri a importância deste arquivo por acaso. Em`bakery-plugin`, ele não existia. Eu me perguntava por que o agente estava sistematicamente mais "perdido" neste projeto do que nos outros. As regras absolutas estavam sim em`AGENT.adoc`— mas`AGENT.adoc`nunca era carregado. O agente lia apenas o que eu lhe dizia para ler, manualmente, a cada sessão. Era a sessão 11 de`bakery-plugin`quando percebi a ausência do`opencode.json`. Eu o criei — e a sessão 12 começou como as outras.

Este arquivo é tão óbvio para mim agora que eu nem sequer pensava mais nele. Um erro clássico do desenvolvedor que conhece demais a sua ferramenta. Hoje, eu o crio sistematicamente *antes*`AGENT.adoc`. É a primeira pedra.

==== A Dualidade de `INDEX.adoc

Outra sutileza que merece ser explicitada:`INDEX.adoc`vive em`.agents/`— uma pasta que apresentei como `LAZY`. No entanto, eu a listo como `EAGER` em todas as minhas tabelas. Há uma tensão aparente aqui.

A realidade do terreno: os arquivos`.agents/INDEX.adoc`são carregados automaticamente no início da sessão, tal como`AGENT.adoc` et `PROMPT_REPRISE.adoc`. Eles estão em`.agents/`por razões de organização — para não invadir a raiz — mas o seu comportamento é EAGER.

Sobre`plantuml-plugin`, `INDEX.adoc`tem 200 linhas e contém as regras absolutas *completas* com seu histórico (as lições de sessões passadas), os EPICs com pontuações e o portfólio de projetos. É o documento que o agente consulta para saber « onde estamos». Sobre`bakery-plugin`, ele faz 150 linhas com o roadmap e as sessões recentes.

A redundância voluntária entre`AGENT.adoc` et `INDEX.adoc`pode surpreender. As regras absolutas estão presentes em ambos. Porquê? Porque cumprem dois papéis diferentes: em`AGENT.adoc`, elas são *explicativas* (o storytelling da regra, a lição aprendida); em`INDEX.adoc`, elas são *executivas* (a regra nua, sem justificativa, para uma consulta rápida). O agente lê`AGENT.adoc`uma vez para *compreender*; ele relê`INDEX.adoc`a cada sessão para *aplicar*. Dois usos, dois 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 Dualidade AGENT.adoc ←→ INDEX.adoc
left to right direction

rectangle "AGENT.adoc\n(Raiz — EAGER)" as AGENT #E3F2FD {
  rectangle "📖 **Formato Narrativo**\nO storytelling da regra\na lição aprendida, o contexto" as NARR
  rectangle "🏗️ **Arquitetura Completa**\nEstrutura do projeto, componentes\nBacklog detalhado US" as ARCHI
  rectangle "📋 **Regras Explicativas**\nPor que a regra existe\nHistórico do incidente" as EXPL
}

rectangle "INDEX.adoc\n(.agents/ — EAGER)" as INDEX #E8F5E9 {
  rectangle "⚡ **Formato Executivo**\nA regra nua, sem justificativa\nConsulta rápida" as EXEC
  rectangle "📊 **Roadmap & EPICs**\nQuadro resumido\nProgressão, Pontuação, Prioridade" as ROAD
  rectangle "🌐 **Portfólio de Projetos**\nVisão transversal\n5 projetos sincronizados" as PORT
}

AGENT --> INDEX : "Agente lê AGENT.adoc\n1 vez para **compreender**"
INDEX --> AGENT : "Agente relê INDEX.adoc\na cada sessão para **aplicar**"

note bottom of AGENT
Tamanho máx.: 200 linhas
end note

note bottom of INDEX
Tamanho máx.: 200 linhas
  Source de vérité en cas de divergence
end note

@enduml
----

Esta redundância assumida é uma escolha de design. Ela consome ~50 linhas adicionais de tokens EAGER — mas garante que o agente tenha sempre as regras diante dos olhos, inclusive no formato conciso que facilita a obediência imediata.

=== Os Arquivos LAZY: O Manual do Proprietário

Esses arquivos ficam em`.agents/`e são lidos apenas quando o agente precisa deles. Eles constituem a verdadeira riqueza do método, pois acumulam o conhecimento do projeto sem poluir o contexto atual.

[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 linhas)" as IDX #E8F5E9
  file "AGENT_SESSION_MANAGER.adoc\n(Template de sessão)" as ASM
  file "SESSION_CHECKLIST.adoc\n(Quando alterar)" as CHK
  file "PROCEDURES.adoc\n(6 etapas + LAZY/EAGER)" as PRO
  file "SESSIONS_HISTORY.adoc\n(Todas as sessões)" 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 outros" 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 : "Referência"

note right of S109
Sessão 109 =
Formalização da estratégia
LAZY/EAGER
Token: ~25k → ~10k
end note

@enduml
----

A árvore acima mostra a estrutura real da pasta`.agents/`sobre`plantuml-plugin`, o projeto mais maduro. Note a profundidade em três camadas: arquivos raiz (metadados), pasta`sessions/`(arquivos cronológicos), e pasta`archives/`(agregações e resumos). É essa profundidade que transforma a governança de um simples arquivo TODO em uma**memória organizacional completa**As you didn't provide any text to translate, please provide the French fragment you would like me to translate into Portuguese.

**.agents/sessions/{N}-{titre}.adoc**-- Os arquivos detalhados de cada sessão. Atualmente:

* `plantuml-plugin`Para configurar o `env`, execute o seguinte comando :**133 sessões arquivadas**(da sessão 1 a 133)
* `bakery-plugin`Por favor, forneça o texto em francês que você deseja que eu traduza.**11 sessões**
* `magic-stick`Please provide the text you would like me to translate.**23 sessões**
* `cheroliv.com`Por favor, forneça o texto em francês que deseja traduzir.**9 sessões formais**+ 7 sessões pré-sistema reconstituídas retroativamente

Cada arquivo contém o contexto completo da sessão, as decisões tomadas, os problemas encontrados e a sua resolução, os comandos executados e o seu output.

**.agents/SESSIONS_HISTORY.adoc**-- Uma tabela resumida de todas as sessões com uma pontuação. Exemplo em`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
----

Exemplos concretos:

* `1-chore-migration-gouvernance-agent.adoc`— sessão 1, tipo chore
* `10-solidification-tests.adoc`— sessão 10, sem tipo explícito (o assunto é suficiente)
* `036-debug-graphify-symlink-epic9.adoc`— sessão 36 com número de 3 dígitos para a triagem

O número da sessão é o critério de ordenação principal. Os projetos que utilizam números com 3 dígitos (001, 036, 133) evitam problemas de ordenação lexicográfica quando se ultrapassa 99. É isso que utilizo agora em`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.

O tipo é opcional e derivado das palavras-chave da sessão (debug, feature, refactor, docs, chore, test). O assunto em kebab-case é a parte mais importante: ele deve permitir encontrar uma sessão sem abrir o arquivo. Se você se perguntar "qual era a sessão em que corrigimos o timeout dos testes de integração?", a resposta é`124-fix-timeout-integration-test.adoc`Please provide the French text you would like me to translate into Portuguese.

Para as sessões históricas reconstituídas (projetos nascidos antes da governança), utilizo números negativos. Sobre`cheroliv.com`, as sessões -6 a 0 cobrem toda a história pré-governança do projeto. E para as sessões "não documentadas" ou perdidas, eu crio uma entrada em`SESSIONS_HISTORY.adoc`sem arquivo correspondente, com uma pontuação`?`. É mais honesto do 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 Convenção de Nomeação de Sessões
start

:Une session se termine;
note right: Trigger "fim de sessão"

if (Session antérieure\nà la gouvernance ?) then (oui)
  :Numéro **NÉGATIF**\n-6, -5 ... 0;
  note right: Histórico\nreconstituído
  :Suffixe : reconstitution;
else (non)
  :Numéro **POSITIF**\nsur 3 chiffres si > 99;
  note right: 001, 036, 133\npara a ordenação 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
Deve permitir encontrar
sem abrir o arquivo
  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: A honestidade\nem vez do vazio
endif

stop
@enduml
----

==== TEST_COVERAGE_ANALYSIS.adoc` — A Etapa 5 Detalhada

A etapa 5 do procedimento de encerramento de sessão é a mais misteriosa. Ela diz « Atualizar`TEST_COVERAGE_ANALYSIS.adoc`se foram adicionados ou modificados testes. » Mas como é este arquivo?

Sobre`plantuml-plugin`, ele evoluiu de algumas linhas para uma estrutura completa. Aqui está a sua 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%
|===
----

O interesse não é o arquivo em si — é a obrigação de *anotar* o que mudou. Sem essa etapa, após 50 sessões, você não sabe mais quais testes cobrem o quê. O agente também não. O arquivo torna-se o repositório único de verdade sobre a cobertura de testes do projeto.

Para projetos sem testes tradicionais (como`magic-stick`que testa scripts bash), a etapa 5 é substituída por`SCRIPT_VERIFICATION.adoc`. O mecanismo é o mesmo: um arquivo que acompanha o estado de validação dos scripts. Adapte a etapa 5 ao seu projeto, mas nunca a pule. Ela é a rede de segurança que impede a regressão silenciosa.

Se o seu projeto não tiver *nenhum* teste — nem unitário, nem funcional, nem script — crie mesmo assim o arquivo vazio com uma seção "A fazer: definir uma estratégia de teste." É um marcador que lembrará o seu eu futuro que este assunto não foi tratado.

[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: O agente é uma página em branco

:Chargement EAGER auto;
note right
* AGENT.adoc (regras absolutas)
* PROMPT_REPRISE.adoc (missão N)
* INDEX.adoc (estado do projeto)
end note

if (Mission claire ?) then (oui)
  :Exécution directe;
else (non)
  :Charge LAZY sur demande;
  note right
* SESSIONS_HISTORY.adoc (contexto passado)
* sessions/{N-1}-*.adoc (decisões)
* *_REFERENCE.adoc (arquitetura)
  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. Arquivar sessões/N-*.adoc
2. Atualizar PROMPT_REPRISE.adoc (N+1)
3. Atualizar SESSIONS_HISTORY.adoc
4. Atualizar INDEX.adoc
5. Atualizar TEST_COVERAGE (se aplicável)
6. Atualizar COMPLETED_TASKS_ARCHIVE.adoc
end note

:Checklist [✅] x 6;

stop
@enduml
----

O diagrama acima mostra o ciclo de vida completo de uma sessão. O ponto chave é a bifurcação após o carregamento EAGER: ou a missão é clara o suficiente para ser executada diretamente (80% dos casos), ou o agente carrega LAZY para resolver uma ambiguidade (20% dos casos). É essa discriminação que economiza tokens.

== O Procedimento de Fim de Sessão: A Regra de Ouro

=== Por que ela é indispensável

Sem este procedimento, a estratégia Eager/Lazy não serve para nada. É ele que transforma o trabalho da sessão em informação persistente. Ele é executado**a pedido explícito do utilizador**(palavras-chave: "fim de sessão", "estou saindo", etc.), e ela é**obrigatório**-- nenhuma exceção, nenhuma omissão.

O arquivo`SESSION_CHECKLIST.adoc`define métricas de sessão ideal:

* Duração: 15-30 minutos
* Arquivos modificados: 1-3 no máximo
* Interações de LLM: 5-10 mensagens
* Contexto de tokens: < 50k

E sinais de que é preciso mudar de sessão: _O LLM repete erros já corrigidos_, _Mais de 3 arquivos modificados em paralelo_, _Conversa > 50 mensagens_. A regra de ouro:**É melhor 5 sessões de 20 minutos do que uma sessão de 2 horas com debugging chaos.**

=== O Flux de 6 Etapas (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 "fim de sessão";
note right: Palavras-chave de gatilho

:Agent détecte le trigger;

:Étape 1\nCréer archive\n`.agents/sessions/N-*.adoc`;
note right: Todo o contexto da sessão

:Étape 2\nMettre à jour\n`PROMPT_REPRISE.adoc`;
note right: Missão N + critérios de aceitação N+1

:Étape 3\nMettre à jour\n`SESSIONS_HISTORY.adoc`;
note right: Linha de resumo: # / Data / Tipo / Assunto / Pontuação

:Étape 4\nMettre à jour\n`INDEX.adoc`;
note right: Estado atual, roadmap, arquivos modificados

:Étape 5\nMettre à jour\n`TEST_COVERAGE_ANALYSIS.adoc`;
note right: Se testes forem adicionados ou modificados

:Étape 6\nMettre à jour\n`COMPLETED_TASKS_ARCHIVE.adoc`;
note right: Arquivar tarefas concluídas

:Afficher la checklist de confirmation;
note right: Verificar se cada [✅] é merecido

stop
@enduml
----

=== Os Resultados de 150+ Sessões

Aqui está o resultado deste procedimento aplicado sistematicamente aos meus quatro projetos:

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

* **133 sessões**desde o início do projeto
* **240/240 testes PASSARAM**(100% de cobertura) -- EPICs 1-7 concluídas
* **57 cenários Cucumber BDD**validados
* Regra de segurança nos arquivos de configuração originada de um erro real (Session 2 bakery-plugin)

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

* **11 sessões**em duas semanas
* Migração Supabase → Firebase concluída (9 testes corrigidos)
* EPIC 6 (`publishProfile`) funcional em produção
* Regra 0 criada:`publishToMavenLocal`obrigatório após cada modif

**bastão-mágico**Please provide the text you would like me to translate.

* **23 sessões**para construir um sistema live Xubuntu com partição A/B
* Primeira ISO gerada na sessão 10
* Testes de boot QEMU + VNC formalizados (documentação LAZY de 144 linhas)
* CI/CD SourceForge funcional

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

* **9 sessões formais**+ reconstituição de 7 sessões pré-sistema
* Artigo 0101 (OpenCode PATH) publicado
* Artigo 0108 (este) reescrito após análise de suas lacunas
* Governança completa migrada de Markdown para AsciiDoc

=== A Checklist Final

Após a execução silenciosa das 6 etapas, o agente deve exibir um checklist de confirmação:

✅ 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 Portfólio de Projetos — Referências Cruzadas INDEX.adoc
node "**magic-stick**\nSessão 037\nSCRIPT_VERIFICATION" as MS #E1BEE7
node "**bakery-gradle**\nSessão 11\nTEST_COVERAGE" as BG #FFE0B2
node "**cheroliv.com**\nSessão 10\nTEST_COVERAGE" as CH #C8E6C9
node "**plantuml-gradle**\nSessão 133\nTEST_COVERAGE" as PG #BBDEFB
node "**jhipster-gradle**\nSessão 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
Ao adicionar um projeto:
• 4 `INDEX.adoc` para atualizar
• 1 linha por portfólio
• Custo: 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