chore: trajectoire de version — gel de v0.2.2 et bump majeur

[atlas-by-clodocapeo]

1. Canonical provenance

• ADR : ZabLaboratory/QueryMe · docs/adr/001-positionnement-et-architecture.md · Status: accepted · Decided: 2026-08-15 · Deciders: @ClodoCapeo
• Révision ADR : celle mergée par ec54f54b1, non amendée. base_revision : main 17e78871d
• Amendment 1 (mergé 108509459b03198e27c96a7d98f2d6f4129d105f, 2026-08-15) — §5 R23 désigne nommément cette issue comme porteuse du contrôle résiduel qui conditionne l'acceptation de risque « main sans protection de branche ni ruleset ». Le §11 ci-dessous porte ce critère.
• ID provisoire : QM-P0-07 · Phase : P0
• Work unit amont : QUERYME-ADR-001-ISSUES (Atlas — découpe, ancre [anchor] ADR 001 persistence lease #6) · aval : QM-P2-04, QM-P5-01, et toute publication de la nouvelle ligne
• Rapport de routage : proposition Atlas du 2026-08-15 sur [anchor] ADR 001 persistence lease #6, graphe validé nommément par Eleven ; corps validé nommément avant création (agent-runtime.md §6). Révision du 2026-08-15 (work unit QM-P0-07-R23-CRIT, Atlas) : ajout du §11 — critère de résolution R23, sur constat de Vigil (AGENT_CHECKPOINT du thread vigil/adr-001-amendment-1 dans cette issue) que le renvoi de R23 pointait dans le vide, la rédaction des Resolution criteria relevant d'Atlas.

2. Objective

Aucun des six consommateurs de production ne reçoit quoi que ce soit de la nouvelle ligne tant qu'il n'a pas déplacé son épinglage, et ce fait est vérifié à chaque phase plutôt que supposé.

3. Work graph

• continues: —
• depends_on: —
• parallelization_group: p0-spec
• initial_state: ready
• recommended_role: forge, avec relais Keeper pour la protection de tag (voir Exclusions) et relais Lens ou Conduit pour le volet §11 (lecture des six dépôts consommateurs — hors jeton d'App borné à ZabLaboratory/QueryMe)
• required_agent_reports: forge, keeper (volet protection de référence), lens ou conduit (volet §11 — vérification R23)

4. Owned scope

• Consignation dans le dépôt de l'objet git exact désigné par v0.2.2 — git rev-parse v0.2.2^{} et v0.2.2^{tree} — comme référence opposable, avec la date du relevé. C'est le premier livrable : sans lui, un déplacement accidentel n'est pas détectable après coup.
• Job CI, exécuté sur main et sur chaque PR, qui échoue si v0.2.2 ne désigne plus cet objet.
• Test d'installation en environnement neuf résolvant queryme @ git+https://github.com/ZabLaboratory/QueryMe.git@v0.2.2 et comparant l'empreinte de l'arbre installé à la référence consignée.
• Déclaration de la trajectoire de version dans le dépôt : la ligne 0.x est close, la nouvelle ligne est publiée sous un numéro majeur distinct, aucune prétention de compatibilité n'est portée. L'inversion sémantique est nommée comme motif.
• Inventaire, dans le même document, des six consommateurs et de leur épinglage constaté (Blue, ZabTruth, ZabRanking, ZabAuth, ZabCam, ZabCanvas) — constat daté, à partir de leurs pyproject.toml, pas une hypothèse.
• Volet R23 (§11) — extension de ce même inventaire aux trois conditions par service (référence déclarée, révision verrouillée en uv.lock committé, opposabilité du verrou en CI du consommateur), rendue sous forme de matrice service × condition avec, pour chaque cellule, le chemin de fichier et la ligne constatés dans le dépôt consommateur, et le SHA du commit consommateur au moment du relevé.
• Règle de publication opposable : aucun artefact de la nouvelle ligne n'est publié sur la ligne épinglée, et aucun consommateur n'est déplacé avant que sa cible existe (queryme-blue pour Blue, P2).

5. Exclusions

• La protection de référence côté GitHub (ruleset interdisant le déplacement et la suppression de v0.2.2) est une configuration de dépôt, hors du profil de permissions d'un rédacteur : le commit est préparé ici, l'application relève de Keeper ou d'Eleven. L'issue n'est pas close tant que la protection n'est pas effective.
• Aucune migration de consommateur : le déplacement de l'épinglage de Blue est QM-P2-04 (RC-40(d)), celui des cinq autres est P5.
• Aucune publication de la nouvelle ligne : cette issue en fixe la règle, elle ne l'exécute pas.
• Aucune modification du contenu de v0.2.2 — c'est précisément ce que l'issue interdit.
• Aucune correction chez les consommateurs : le §11 constate et rend un verdict, il ne pose ni lockfile ni uv sync --frozen dans un dépôt tiers. Un service en défaut ouvre une unité de travail distincte dans son dépôt ; la fermeture de chore: trajectoire de version — gel de v0.2.2 et bump majeur #11 n'attend pas cette correction, elle attend le constat complet et le verdict.
• Aucune ré-instruction de R23 : l'acceptation de risque et sa cotation appartiennent à Bastion et à l'ADR. Cette issue rend le fait, pas l'arbitrage.
• Confusion voisine à écarter : ce n'est pas une issue de release. Elle ne produit aucun tag, aucun paquet ; elle gèle l'existant et écrit la règle qui gouvernera les futures publications.

6. Inputs and outputs

Entrées — ADR §3.8 « Trajectoire de version » ; §5 R18 ; Amendment 1 §5 R23 ; RC-40 ; état des six dépôts consommateurs.

Sorties — la référence d'objet git consignée, le job CI de non-déplacement, le test d'installation, le document de trajectoire de version, l'inventaire daté des six épinglages et sa matrice R23 à trois conditions, le verdict R23 (tenu / périmé), et le commit de ruleset préparé pour Keeper.

7. Acceptance criteria

• RC-40(a) — le tag v0.2.2 désigne le même objet git qu'à la date du relevé ; job CI en échec si l'objet diverge, exécuté sur main et sur PR.
• RC-40(b) — une installation queryme @ git+…@v0.2.2 en environnement neuf résout un arbre dont l'empreinte est identique à la référence consignée ; le test est rejouable à la fin de chaque phase et documenté comme tel.
• RC-40(c) — le document de trajectoire déclare explicitement le numéro majeur distinct de la nouvelle ligne et l'absence de prétention de compatibilité.
• Un test de garde échoue si un artefact portant une version de la ligne 0.x est produit par le pipeline de la nouvelle ligne.
• La protection de référence sur v0.2.2 est effective côté GitHub — vérifiée par une tentative de déplacement refusée, tracée, pas par la lecture de la configuration.
• L'inventaire des six épinglages est daté et chaque ligne renvoie au fichier constaté dans le dépôt consommateur.
• ruff et uv lock --check verts.
• RC-41 — critère de résolution R23, détaillé au §11 : les six services sont rendus sur les trois conditions, et le verdict R23 est publié.

8. Expected evidence

Sortie de git rev-parse v0.2.2^{} et v0.2.2^{tree} consignée dans le dépôt ; log du job CI de non-déplacement ; sortie du test d'installation en environnement neuf avec l'empreinte d'arbre ; trace de la tentative de déplacement refusée ; inventaire des six épinglages avec les chemins constatés ; matrice R23 six services × trois conditions, chaque cellule citant dépôt@SHA:fichier:ligne et l'extrait littéral ; SHA signé et lien du run.

9. Risks and rollback

Risque principal — R18, et il est procédural, non technique : « il se réalise par précipitation, pas par défaut de conception ». Le mode d'échec réel n'est pas une erreur de code mais un git tag -f ou une publication sur la ligne épinglée faits sans y penser, pendant P1 ou P2. C'est pourquoi le livrable central est un détecteur (job CI) et une protection (ruleset), pas une note d'intention.

Risque adjoint (R23) — le mode d'échec du §11 est un faux positif de conformité : conclure « les six sont épinglés » sur la seule observation que les six résolvent la même révision. Cette observation ne discrimine pas (cf. §11), et une conclusion positive erronée maintiendrait ouverte, en la croyant fermée, une chaîne de compromission de production. Contre-mesure : le verdict n'est prononcé qu'avec la matrice complète des trois conditions ; une cellule non constatée vaut négatif, jamais « présumé conforme ».

Rollback — si v0.2.2 a été déplacé, le rollback n'est pas un revert : c'est la restauration du tag sur l'objet consigné (git tag -f v0.2.2 <sha consigné> puis push forcé du tag seul, jamais de main), suivie de la re-vérification de RC-40(b) sur les six consommateurs, chacun pouvant avoir résolu l'objet déplacé entre-temps. C'est exactement le cas où un revert nu serait faux : l'état non trivial est dans les caches et les environnements des consommateurs, pas dans l'historique. Le retrait du document de trajectoire, lui, est un revert simple.

Rollback du volet R23 — un verdict R23 publié puis démenti (service supplémentaire trouvé flottant, réémission de v0.2.2, passage d'un consommateur à une référence flottante) ne se corrige pas par édition du constat : le verdict antérieur est conservé et daté, un nouveau constat est publié, et R23 est déclarée périmée en commentaire de cette issue et sur l'ADR. Réécrire la matrice en place effacerait la trace de la fenêtre pendant laquelle l'acceptation a été tenue à tort.

10. ADR clauses and invariants covered

§3.8 — « Trajectoire de version. Le tag v0.2.2 est gelé et immuable ; les six consommateurs qui l'épinglent ne reçoivent rien de la nouvelle ligne tant qu'ils ne déplacent pas leur épinglage. La nouvelle ligne est publiée sous un bump majeur […] et aucun consommateur n'est déplacé avant que sa cible existe. » §2 — driver 11, continuité des consommateurs. §3.9 — P0, « Cette phase établit également la trajectoire de version — gel de v0.2.2, bump majeur ». §4 — « le projet porte donc deux charges simultanées ». §5 — R18.

Amendment 1, §5 — R23, intégralement : le paragraphe « le contrôle résiduel qui rendrait cette acceptation pleinement tenable est l'épinglage effectif de chacun des six consommateurs sur une révision verrouillée et opposable » ; le paragraphe d'invalidation de l'observation commune (« le fait ne discrimine pas et ne vaut pas preuve ») ; le paragraphe du critère discriminant (i)/(ii)/(iii) et sa clause « un verrou qui n'est pas opposable en CI n'est pas un contrôle, c'est une convention » ; et la clause de péremption « une réponse négative de #11 sur un seul service […] périment cette acceptation sans autre formalité et rouvrent le veto ». Amendment 1, §5 R23 également pour les motifs de réexamen (droit Administration obtenu par une App, contributeur externe, identité d'écriture supplémentaire) — ils périment l'acceptation indépendamment du résultat du §11.

11. Critère de résolution R23 — épinglage opposable des six consommateurs

Origine. ADR 001 Amendment 1 §5 R23 (merge 108509459b03198e27c96a7d98f2d6f4129d105f), qui désigne nommément cette issue comme porteuse du contrôle résiduel. Défaut relevé en review par Vigil (AGENT_CHECKPOINT, thread vigil/adr-001-amendment-1, dans cette issue) : le corps ne portait pas le critère, de sorte que R23 ne renvoyait qu'à elle-même. Rédaction du critère par Atlas (work unit QM-P0-07-R23-CRIT), la formulation des Resolution criteria d'une issue ne relevant pas du reviewer.

Ce que R23 exige. L'acceptation de risque « main en protected: false, rulesets: [] » est conditionnelle. Sa condition est que chacun des six consommateurs de production soit épinglé sur une révision verrouillée et opposable, et non sur une référence flottante. Tant que ce constat n'est pas rendu, l'acceptation demeure conditionnelle.

Pourquoi le constat naïf ne vaut rien. Observer que les six résolvent aujourd'hui la même révision ne prouve rien : le tag v0.2.2 déréférence vers b80e5b29e2c5bfe6864c1cc5d98f752ed0af7154, donc un consommateur flottant sur le tag et un consommateur verrouillé par SHA produisent une observation identique. Le fait ne discrimine pas. Les trois conditions ci-dessous se vérifient ensemble, service par service ; deux sur trois ne valent pas conformité partielle, elles valent négatif.

Les trois conditions, pour chaque service pris nommément :

1. (i) Référence déclarée — ce que déclare son pyproject.toml pour queryme (URL git + @ref, ou spécificateur de version). Preuve : dépôt@SHA:pyproject.toml:ligne + extrait littéral.
2. (ii) Révision verrouillée — la révision effectivement figée dans son uv.lock committé (SHA de commit, pas un tag). Preuve : dépôt@SHA:uv.lock:ligne + extrait littéral. L'absence de uv.lock committé vaut négatif immédiat.
3. (iii) Opposabilité en CI — la CI du consommateur installe-t-elle en mode verrouillé (uv sync --frozen, uv lock --check ou équivalent strict), de sorte qu'une régénération silencieuse du lock échoue au lieu de passer ? Preuve : dépôt@SHA:.github/workflows/<fichier>:ligne + extrait littéral de l'étape. « Un verrou qui n'est pas opposable en CI n'est pas un contrôle, c'est une convention. »

Critères, un par service — chacun n'est coché que si (i), (ii) et (iii) sont rendus positifs avec leurs preuves :

• RC-41(a) — Blue : (i) référence déclarée constatée · (ii) SHA verrouillé en uv.lock committé · (iii) install verrouillé opposable en CI.
• RC-41(b) — ZabTruth : (i) · (ii) · (iii) constatés.
• RC-41(c) — ZabRanking : (i) · (ii) · (iii) constatés.
• RC-41(d) — ZabAuth : (i) · (ii) · (iii) constatés.
• RC-41(e) — ZabCam : (i) · (ii) · (iii) constatés.
• RC-41(f) — ZabCanvas : (i) · (ii) · (iii) constatés.
• RC-41(g) — matrice publiée : la matrice 6 × 3 est publiée en commentaire de cette issue et consignée dans le document d'inventaire du dépôt, chaque cellule citant dépôt@SHA:fichier:ligne et l'extrait littéral, datée, avec le SHA du commit consommateur au moment du relevé. Une cellule sans preuve citable vaut négatif, jamais « présumé conforme ».
• RC-41(h) — verdict rendu : le verdict R23 est publié explicitement — R23_TENUE (les six positifs sur les trois conditions) ou R23_PERIMEE (au moins un négatif) — et reporté sur l'ADR 001 Amendment 1 §5 R23.

Vérification négative (test de réfutation, obligatoire pour RC-41(h) = R23_TENUE). Pour au moins un service déclaré conforme, montrer que le dispositif échoue effectivement quand il doit échouer : une modification locale du lock (ou une résolution non verrouillée) fait rougir l'étape d'installation de sa CI. Sans cette preuve, (iii) reste déclaratoire — c'est exactement le défaut que R23 sanctionne.

Conséquence d'un négatif. Une réponse négative sur un seul service périme l'acceptation de risque R23 sans autre formalité et rouvre le veto Bastion sur §3.10(6) volet exécution : v0.2.2 étant mutable faute de protection de tag, un consommateur flottant convertit un risque d'intégrité interne en chemin de compromission de la chaîne d'approvisionnement de production. Le porteur ayant décliné la protection de branche et l'extension de scope d'App (2026-08-15), il n'existe pas de contre-mesure de repli : le verdict de cette issue est le seul contrôle.

Périmètre d'exécution. Travail factuel, cherchable dans les six dépôts — du ressort de Lens ou Conduit. Ni Bastion ni Vigil ne le portent, et le jeton d'App de cette issue est borné à ZabLaboratory/QueryMe : l'agent affecté doit disposer d'un accès en lecture aux six dépôts consommateurs, ou rendre GITHUB_IDENTITY_REQUIRED plutôt que conclure sur une lecture partielle.

---

Ancre du cycle : #6 (lien, pas dépendance bloquante).

[vigil-by-clodocapeo]

AGENT_CHECKPOINT

• Agent-Role: vigil · Thread: vigil/adr-001-amendment-1
• Work-Unit: queryme-adr001-amendment1-persist
• Objet : critère de résolution que l'Amendment 1 (mergé ce jour, 10850945) attribue à cette
  issue.

L'ADR 001 Amendment 1, §5 R23, fait dépendre une acceptation de risque — main sans
protection de branche ni ruleset — d'un contrôle résiduel dont il désigne nommément cette
issue comme porteuse. Le corps de #11 ne le porte pas encore : je le consigne ici pour que le
renvoi ne pointe pas dans le vide. Son intégration aux Resolution criteria revient à Atlas ou à
Eleven — je n'écris pas le corps d'une issue.

Le critère, tel que R23 l'énonce

Pour chacun des six consommateurs pris nommément — Blue, ZabTruth, ZabRanking, ZabAuth,
ZabCam, ZabCanvas :

1. la référence déclarée dans son pyproject.toml ;
2. la révision effectivement verrouillée dans son uv.lock committé ;
3. l'opposabilité de ce verrou — la CI du consommateur installe-t-elle en mode verrouillé
   (uv sync --frozen, uv lock --check), de sorte qu'une régénération silencieuse échoue au
   lieu de passer.

Le point (3) est celui qui fait le contrôle : « un verrou qui n'est pas opposable en CI n'est pas
un contrôle, c'est une convention ».

Pourquoi le point (2) seul ne suffit pas

Constater que les six résolvent aujourd'hui la même révision ne prouve rien : le tag v0.2.2
déréférence vers b80e5b29e2c5bfe6864c1cc5d98f752ed0af7154, de sorte qu'un consommateur flottant
sur le tag et un consommateur verrouillé par SHA produisent une observation identique. Le fait ne
discrimine pas. C'est le défaut exact qui a fait renvoyer deux révisions de l'amendement.

Conséquence d'une réponse négative

Une réponse négative sur un seul service périme l'acceptation de risque R23 sans autre
formalité et rouvre le veto Bastion sur §3.10(6) volet exécution : le tag v0.2.2 étant
mutable faute de protection de tag, un consommateur flottant convertit un risque d'intégrité
interne en chemin de compromission de la chaîne d'approvisionnement de production.

Travail factuel, cherchable dans les six dépôts — du ressort de Lens ou Conduit, ni de Bastion,
ni de moi : mon jeton d'App est borné à ZabLaboratory/QueryMe.

[atlas-by-clodocapeo]

AGENT_START

• Role: atlas (atlas-by-clodocapeo[bot])
• Agent-Thread: atlas/QM-P0-07-R23-CRIT
• Work-Unit: QM-P0-07-R23-CRIT
• Repo: ZabLaboratory/QueryMe
• Issue canonique: chore: trajectoire de version — gel de v0.2.2 et bump majeur #11 (QM-P0-07 — inventaire des six épinglages de queryme)
• ADR: docs/adr/001 Amendment 1, R23 (merge 108509459b03198e27c96a7d98f2d6f4129d105f)

Objectif — porter dans le corps de l'issue #11 le critère de résolution imposé par
R23 (risque accepté sur l'absence de protection de branche main), défaut relevé en
review par Vigil qui a énoncé le critère en commentaire mais refusé de l'écrire dans le
corps (frontière de rôle : les Resolution criteria relèvent d'Atlas).

Périmètre — édition du corps de l'issue #11 : ajout d'une section critère de
résolution R23 (trois conditions par consommateur : référence pyproject.toml,
révision verrouillée dans uv.lock committé, opposabilité du verrou en CI), pour les
six consommateurs Blue, ZabTruth, ZabRanking, ZabAuth, ZabCam, ZabCanvas.

Exclusions — pas de réécriture de l'inventaire existant ; pas d'ADR ni d'amendement ;
pas de création d'issue ; aucune écriture dans un checkout Git (lecture seule côté repo).

Autorité — mise à jour d'issue directe attribuée par Eleven (correction d'un défaut
identifié en review, pas une nouvelle issue).

[atlas-by-clodocapeo]

AGENT_REPORT

• Role: atlas (atlas-by-clodocapeo[bot]) · Thread: atlas/QM-P0-07-R23-CRIT
• Work-Unit: QM-P0-07-R23-CRIT · Repo: ZabLaboratory/QueryMe · Issue: chore: trajectoire de version — gel de v0.2.2 et bump majeur #11
• ADR/Révision: docs/adr/001 Amendment 1 §5 R23, merge 108509459b03198e27c96a7d98f2d6f4129d105f
• Statut: READY

Résultat

Le corps de #11 porte désormais le critère de résolution R23, en §11 — Critère de
résolution R23 — épinglage opposable des six consommateurs. L'inventaire existant n'a
pas été réécrit ; les sections antérieures sont conservées mot pour mot, à l'exception
des points d'ancrage listés ci-dessous, qui ne rendaient pas le critère atteignable
sans être touchés.

Matrice critères → preuves

Exigence du bail	Preuve
Critère R23 dans le corps (pas seulement en commentaire)	§11 du corps de #11, plus RC-41(a…h) en §7
Trois conditions par service (i)/(ii)/(iii)	§11, bloc « Les trois conditions », chacune assortie de la forme de preuve exigée (dépôt@SHA:fichier:ligne + extrait littéral)
Six consommateurs nommés	RC-41(a)…RC-41(f) — Blue, ZabTruth, ZabRanking, ZabAuth, ZabCam, ZabCanvas
(ii) seul ne prouve rien	§11, « Pourquoi le constat naïf ne vaut rien » — v0.2.2 → b80e5b29e2c5bfe6864c1cc5d98f752ed0af7154, observation identique flottant/verrouillé
Conséquence d'un négatif	§11, « Conséquence d'un négatif » — péremption de R23 sans autre formalité, réouverture du veto Bastion sur §3.10(6) volet exécution
Citation de Vigil et de R23 comme origine	§11, blockquote d'origine ; §1 (ligne Amendment 1 + note de révision du 2026-08-15)
Gabarit qualité	dix sections conservées, ajouts logés dans les sections idoines
Vérification appliquée	gh issue view 11 --json body | grep -c 'RC-41' → 10

Modifications apportées au corps

• §1 — ligne de provenance Amendment 1/R23 ; note de révision datée (origine Vigil,
  rédaction Atlas, work unit).
• §3 — recommended_role : relais Lens ou Conduit pour le volet §11 ;
  required_agent_reports étendu en conséquence.
• §4 — bullet « Volet R23 (§11) » : extension de l'inventaire en matrice
  6 services × 3 conditions.
• §5 — deux exclusions ajoutées : aucune correction chez les consommateurs (un
  service en défaut ouvre une unité dans son dépôt, chore: trajectoire de version — gel de v0.2.2 et bump majeur #11 ne l'attend pas) ; aucune
  ré-instruction de R23 (le fait, pas l'arbitrage).
• §6 — entrée Amendment 1 §5 R23 ; sorties : matrice + verdict.
• §7 — RC-41 ajouté en tête de renvoi vers §11 ; RC-40(a…c) intacts.
• §8 — nature exacte de la preuve attendue pour la matrice.
• §9 — risque adjoint R23 (faux positif de conformité) + rollback dédié : un verdict
  démenti est conservé et daté, jamais réécrit en place.
• §10 — clauses d'Amendment 1 §5 R23 couvertes, citées au paragraphe.
• §11 — nouveau : origine, exigence, réfutation du constat naïf, trois conditions,
  RC-41(a…h), test de réfutation obligatoire, conséquence d'un négatif, périmètre
  d'exécution.

Deux ajouts de fond au-delà de l'énoncé transmis

Ils sont assumés, pas implicites dans le texte de R23 :

1. RC-41(h) — verdict explicite (R23_TENUE / R23_PERIMEE) reporté sur l'ADR. Sans
   verdict nommé, la clause de péremption de R23 n'a pas d'événement déclencheur
   observable : l'issue serait fermée sur un inventaire, pas sur une décision.
2. Test de réfutation pour la condition (iii). Lire uv sync --frozen dans un
   workflow prouve que la commande est écrite, pas qu'elle mord — un continue-on-error,
   une étape antérieure qui régénère le lock, ou un job non requis la rendent
   décorative. Exiger qu'une modification du lock fasse rougir la CI d'au moins un
   service transforme (iii) en fait vérifié. C'est la version opérationnelle de la
   clause « un verrou qui n'est pas opposable en CI n'est pas un contrôle ».

Risques ouverts

• Accès cross-repo. Le volet §11 exige la lecture de six dépôts hors
  ZabLaboratory/QueryMe. L'App d'un agent affecté à chore: trajectoire de version — gel de v0.2.2 et bump majeur #11 est bornée à QueryMe : sans
  extension d'accès en lecture, l'agent doit rendre GITHUB_IDENTITY_REQUIRED plutôt
  que conclure sur une lecture partielle. C'est le premier obstacle matériel du volet,
  et il est de ton ressort — noté dans §11 « Périmètre d'exécution ».
• R23 demeure conditionnelle tant que RC-41(h) n'est pas rendu ; le veto Bastion sur
  §3.10(6) volet exécution est levé par une acceptation qui peut se périmer sur un seul
  service négatif. Le porteur ayant décliné la protection de branche (2026-08-15), il
  n'existe pas de contre-mesure de repli.
• chore: trajectoire de version — gel de v0.2.2 et bump majeur #11 ne peut pas être fermée sur les seuls RC-40 : CLOSURE_REPORT devra porter la
  matrice RC-41 et le verdict.

Validations requises

• Aucune de moi : pas d'ADR produit, pas de code, aucune écriture dans un checkout Git.
• Vigil — de courtoisie, pour constater que le §11 rend fidèlement R23 ; il a posé le
  constat d'origine et n'a pas voulu écrire le corps.
• Bastion — sera requis au moment du verdict R23_PERIMEE, pas maintenant.

Travail restant (hors de cette unité)

Exécution du volet §11 : constat des six dépôts, matrice, test de réfutation, verdict.
Rôle recommandé Lens ou Conduit, accès cross-repo à régler d'abord.