arcodangeandClaude Opus 5
b92da95701
Trois questions indépendantes, tranchées lors du branchement de Kadans sur MinIO (2026-07-26) : qui déclare les buckets d'une app, qui détient les identifiants capables de les créer, et comment l'app lit les siens. La décision de fond est du fondateur : CHACUN SON PÉRIMÈTRE. Une application déclare ses buckets depuis son propre dépôt ; `tools` fournit le serveur, un module de standardisation et un compte de provisionnement — pas la liste. Une première version faisait tout porter par l'infra partagée : à ce rythme, chaque bucket de chaque app devenait une PR sur le dépôt commun. L'ADR consigne aussi les trois identités et leurs portées (root / provisionneur / compte de service), pourquoi la lecture des identifiants est une propriété inconditionnelle de la plateforme plutôt qu'une déclaration par app, et pourquoi les octets ne transitent pas par l'API — avec les conséquences que ça impose (endpoint public, CORS aux origines exactes, pas de basic-auth sur l'ingress S3). Les alternatives écartées sont listées avec leur motif, dont deux que j'avais moi-même proposées et qui étaient plus faibles. Deux limites assumées y figurent : le provisionneur est un secret PARTAGÉ entre rôles CI (sa compromission permet de créer des buckets, pas de lire des objets), et les noms d'actions d'administration MinIO n'ont pas été éprouvés contre le serveur au moment d'écrire. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Factory > Doc
Documentation Factory
Last Updated: 2026-05-31 Status: Production · maintenue activement Related: README racine du dépôt · Collection Ansible
arcodange.factory
C'est quoi ?
Le dossier doc/ rassemble la documentation de la plateforme Arcodange (k3s + Gitea + ArgoCD + OpenTofu + Vault + Postgres, auto-hébergée sur 3 Raspberry Pi). On y trouve deux familles :
- les ADR (records de décisions d'architecture), qui expliquent pourquoi la plateforme est faite ainsi ;
- les runbooks, qui expliquent comment exécuter une procédure opérationnelle de bout en bout.
Note
Convention du dépôt (cf. PR #8) : la documentation vit sous
doc/(singulier). Un ancien dossierdocs/(pluriel) a pu traîner non-suivi par git — ne pas y ajouter de contenu.
Sections
| Section | Ce qu'on y trouve | Statut |
|---|---|---|
| Runbooks | Procédures opérationnelles pas-à-pas (créer une app, etc.) | ✅ |
| ADR | Décisions d'architecture + checklist de mise en place de la plateforme | ✅ |
Légende de statut
✅ actif · 🟡 dégradé/beta · 🔴 critique/EOL · ⚠️ problème connu · ❌ désactivé
Comment éditer cette documentation
- Ajouter une page → la créer depuis le template adéquat et ajouter sa ligne dans la table d'index du
README.mdparent. - Supprimer une page → la marquer Décommissionnée (date) d'abord ; supprimer le fichier et sa ligne d'index ensemble une fois qu'elle est vraiment partie.
- Garder les liens croisés bidirectionnels → quand on lie A→B, ajouter B→A.
- Mettre à jour
Last Updated:en tête de la racine concernée après tout changement de structure.