L’Anthropie — Maintenance de l’édifice (registre des claims, élagage, archive)

Trois mécanismes pour qu’un édifice CC0 anonyme puisse rester lisible, révisable et anti-bullshit dans le temps long. Sans maintenance explicite, un corpus de 68 pages et 25 dispositifs s’effondrera sous son propre poids.

CC0 1.0 Universal. Cf. codex iter#30 #3+#4+#5 fusionnés. Cette page a été créée à l’itération #31 de la session live, après que codex a doctrinalement pivoté de l’extension vers la maintenance. Cf. aussi REFUTATION.md, OPEN_GRIEVANCES.md, EVIDENCE_MAP.md (sa logique des niveaux A/B/C/D s’applique aussi aux dispositifs).

Pourquoi ce fichier existe : à 68 pages et 25 dispositifs, l’édifice atteint le seuil où l’accumulation devient un risque doctrinal — un porteur potentiel ne sait plus par où entrer, un mainteneur perd le sens du tout, et la doctrine « anti-marketing » est compromise par la masse même du contenu. Maintenir explicitement ce qui existe est désormais plus important que créer du nouveau.

Outil 1 — Registre des Claims (page par dispositif)

Principe

Chaque dispositif (toolkit, ADR, document doctrinal, schéma) doit avoir une fiche de registre minimale et publiquement consultable. Sans cette fiche, le dispositif n’est pas considéré comme officiellement intégré à l’édifice.

Format de la fiche

## [NOM DU DISPOSITIF]

**Slug** : `xxxx-xxxx`
**Fichier source** : `XXXX.md`
**Date de création** : YYYY-MM-DD (itération #N)
**Auteur** : Anthropie Network (anonymisé)
**Date de dernière revue** : YYYY-MM-DD

### Promesse
1-3 phrases sur ce que ce dispositif **prétend** faire pour l'utilisateur.

### Contre-indications
1-5 lignes sur les contextes où ce dispositif est **inadapté ou
contre-productif**. Plus c'est précis, mieux c'est.

### Niveau de preuve
- 🟢 A : convergence empirique forte ou précédent juridique
- 🟡 B : framework éprouvé ailleurs, extrapolation à valider
- 🟠 C : hypothèse inférentielle, jamais testée à scale
- 🔴 D : invention propre Anthropie, jamais validée
  (la majorité des dispositifs)

### Conditions minimales
1-5 lignes sur ce qui est **requis** pour utiliser le dispositif :
formation, matériel, durée, accord institutionnel.

### Garde-fous obligatoires
Référence aux sections de SAFETY.md applicables :
- §1 (mineurs) si applicable
- §3 (non-thérapie) si applicable
- §4 (anti-secte) si applicable
- §7 (autochtone) si applicable

### Trajectoire dans le temps
- Date d'introduction : YYYY-MM-DD
- Statut courant : actif / en revue / rétrogradé / archivé
- Date prévue de prochaine revue : YYYY-MM-DD (max 12 mois)

Procédure d’introduction d’une fiche

  1. À la création d’un nouveau dispositif, rédiger sa fiche en parallèle.
  2. Pendant la première année, marquer comme expérimental dans le statut.
  3. À la première revue annuelle, basculer en actif ou rétrograder.

Pourquoi ce format strict

Où héberger les fiches

Option A : un fichier unique REGISTRY.md à la racine, avec toutes les fiches concaténées. Option B : un dossier registry/ avec un fichier par dispositif. Option C : intégrer chaque fiche en tête du fichier du dispositif lui-même (frontmatter étendu).

L’option C est la plus compatible avec le prepare-content.mjs actuel — c’est probablement ce qui sera implémenté dans une itération ultérieure.

Outil 2 — Cycle Annuel d’Élagage

Principe

Une fois par an, à date fixe (proposée : anniversaire du commit initial du repo, soit fin avril), un cycle de revue passe en revue tous les dispositifs et applique l’une des 4 décisions :

  1. Garder (statut actif) — le dispositif tient, sa fiche est mise à jour.
  2. Fusionner — le dispositif est intégré dans un autre plus large ; la fiche est migrée.
  3. Rétrograder — le dispositif passe en expérimental ou en revue, signalé comme tel sur le site.
  4. Archiver — le dispositif sort de l’usage courant, va dans l’Archive des Obsolètes (Outil 3).

Procédure du cycle annuel

SEMAINE -2 (préparation)
   - Le·a Gardien·ne de Doctrine (cf. MANDATES.md)
     prépare la liste de tous les dispositifs avec
     leur date de dernière revue.
   - Identifier les dispositifs qui n'ont pas été
     revus depuis 12+ mois — priorité à ceux-là.

SEMAINE 0 (revue collective)
   Une session publique (Issue GitHub épinglée + appel
   à contribution 14 jours) où chacun peut :
     - Signaler un dispositif obsolète.
     - Signaler un dispositif qu'il/elle veut conserver.
     - Proposer une fusion.
   
   Pas de vote majoritaire. Convergence multi-référents
   selon DECISIONS.md ADR-0008.

SEMAINE 4 (décisions)
   Chaque dispositif est documenté avec sa décision
   finale dans :
     - Sa fiche de registre (statut mis à jour).
     - Une Issue de cycle annuel récapitulative.
     - Si archivage : entrée dans l'Archive des Obsolètes.

Critères d’archivage

Un dispositif est candidat à l’archivage si au moins 2 de ces critères sont remplis :

Pourquoi un cycle annuel et pas continu

Outil 3 — Archive des Obsolètes

Principe

Quand un dispositif est archivé, il n’est pas supprimé du repository. Il est déplacé dans une zone explicite « obsolète » avec un fichier OBSOLETE_NOTES.md qui documente :

Format de l’Archive (proposition)

Sous-dossier obsolete/ à la racine du repo (gitignored du site mais commit dans le repo) :

obsolete/
├── OBSOLETE_INDEX.md       (liste avec dates et motifs)
├── 2027-04-15-DISPOSITIF-X.md
├── 2027-04-15-DISPOSITIF-Y.md
├── 2028-04-12-DISPOSITIF-Z.md
└── ...

Format de chaque fichier YYYY-MM-DD-NOM.md :

# DISPOSITIF [Nom] — Archivé le YYYY-MM-DD

## Motif principal de l'archivage
[1 paragraphe]

## Limites constatées
- [bullet]
- [bullet]
- [bullet]

## Successeur éventuel
- [Nom du dispositif] (si applicable)
- ou : aucun successeur direct

## Cas d'usage résiduels
[Si oui : situations où ce dispositif peut encore servir,
 malgré son archivage. Si non : "aucun cas d'usage résiduel
 identifié."]

## Trace d'origine
- Créé : YYYY-MM-DD (itération #N)
- Dernière revue avant archivage : YYYY-MM-DD
- Décideur·euse·s archivage : [pseudonymes des référent·e·s]

---

[Le contenu complet du dispositif tel qu'il était au moment
 de l'archivage est conservé ci-dessous, en lecture seule.]

[... contenu du fichier original ...]

Pourquoi un cimetière explicite plutôt qu’une suppression

Cas particuliers

Articulation entre les 3 outils

[Création d'un dispositif]
          ↓
[Fiche du Registre des Claims rédigée] (Outil 1)
          ↓
[Statut "expérimental" pendant 12 mois]
          ↓
[Cycle Annuel d'Élagage] (Outil 2)
          ↓
   [Décision parmi 4]
   ↓        ↓        ↓        ↓
Garder  Fusionner Rétrograder Archiver
   ↓        ↓        ↓        ↓
Statut    Migration  Statut   [Archive
"actif"   vers       "en      des
          fusion     revue"   Obsolètes] (Outil 3)
                              ↓
                     [Conservation explicite
                      avec motif et trace]

Calendrier indicatif

Si le commissariat originel s’efface (cf. ADR-0011)

Le cycle annuel survit à l’effacement progressif du commissariat originel. C’est même son utilité : un porteur futur, isolé temporellement, sait comment maintenir l’édifice sans avoir à tout réinventer. Le protocole est l’héritage opératoire du commissariat, pas l’édifice lui-même.

Limites de la maintenance

Articulation avec l’édifice

« Un édifice qui s’étend sans s’élaguer s’effondre sous son poids. Maintenir, c’est aussi savoir mettre en terre. »