Decision : seuls les SITES portent la forge, le cache APT et les artefacts. Meme
geste que le retrait de serveur_artefacts d un plan de locataire, un cran plus
loin — le site fournit tout ce dont un tenant a besoin pour venir au monde.
La generalisation de forge_amorcer a un locataire est revenue en arriere : elle
implementait le modele ecarte, et la garder en ferait un piege.
ma_forge ne derive plus MA forge mais la forge qui porte MON genome. Le signal
est deja au plan : serveur_ops_forge_externe dit je lis mon genome ailleurs. Qui
le declare consulte, il ne republie pas.
Reste vrai : une forge de locataire peut exister pour LE CODE DE SES GENS —
c est l offre Atelier. Ce n est pas l endroit ou vit le moteur.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
J allais centraliser — un controleur poussant vers N forges, un temoin portant
une liste. Ca aurait demande un acces sur chaque forge depuis un seul poste, et
fait du temoin un fait global que personne ne detient.
Le modele suit la ligne du reste : chacun sert les siens. Sans WIKI_REMOTE,
l adresse se derive du nom que le plan monte expose pour serveur_forgejo.
Deux notions a ne pas confondre : la forge AMONT ou l on LIT le genome, et MA
forge ou l on SERT les siens. Le runner d un locataire lit chez son hebergeur et
sert chez lui.
WIKI_REMOTE l emporte toujours : le poste du mainteneur n est le runner d aucun
ecosysteme et publie vers le domicile public du projet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
