gate: traçabilité des dix clearances §3.10

[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
• ID provisoire : QM-P0-10 · Phase : transverse P0 → P3
• Work unit amont : QUERYME-ADR-001-ISSUES (Atlas — découpe, ancre [anchor] ADR 001 persistence lease #6) · aval : toutes les issues de code, chacune par sa surface
• Nature : issue de gate, sans code
• Rapport de routage : proposition Atlas du 2026-08-15 sur [anchor] ADR 001 persistence lease #6, graphe validé nommément par Eleven

2. Objective

Chacune des dix surfaces de §3.10 porte un verdict Bastion explicite — clearance ou veto — rendu avant le code de la phase indiquée, et ce fait est vérifiable en un seul endroit.

3. Work graph

• continues: —
• depends_on: —
• parallelization_group: — (transverse, aucun)
• initial_state: ready
• recommended_role: — (tenue par Eleven ; les verdicts sont rendus par Bastion)
• required_agent_reports: bastion × 10, un par surface

4. Owned scope

Tableau des dix surfaces de §3.10, chacune avec sa phase de gate, les issues de code qu'elle bloque, et l'état de son verdict :

#	Surface	Phase	Bloque	Verdict
1	Signature, révocation, custody, rotation, déterminisme de la signature — porte la portée exacte de RC-3	P0	QM-P0-03, QM-P0-05	—
2	Justificatifs du devkit, isolation multi-tenant des jeux de développement	P3	QM-P3-04	—
3	Auteur de Zapp hostile, chaîne d'approvisionnement du bundle	P3	QM-P3-04, QM-P3-05	—
4	Solidité du jeu d'invariants au regard de la revendication, validité de la partition ternaire, légitimité de présenter I9 comme garantie appliquée	P0	QM-P0-05, QM-P0-06, QM-P0-08 — et « précède tout code et toute communication publique »	—
5	Canaux auxiliaires : substrat, interruption au plafond, refus pour dépassement de débit, observation des réservations, inférence sur relation traversée sans exposition	P1	QM-P1-10, QM-P1-11, QM-P1-14	—
6	Dépôt public — exposition (audit rétroactif de l'historique) et exécution (PR de fork sur runner self-hosted)	P0	QM-P0-09, QM-P2-01	—
7	Sûreté du compilateur	P1	QM-P1-01, QM-P1-02	—
8	Cycle de vie des autorisations et allocations, résistance à la banalisation de l'émission	P1	QM-P1-18	—
9	Évaluation de la fonction de coût sur valeurs d'appelant : débordement, effets de bord, échappement au sens d'I5, solidité de la propriété de majoration — porte RC-38(a), séparément par axe	P1	QM-P1-05	—
10	Intégrité et confidentialité des compteurs, atomicité sur les deux axes conjointement, criticité propre de l'axe de mutation, falsification, dérivation de la sous-clé, partition, réservation orpheline, magasin externe	P1	QM-P1-11, QM-P1-13, QM-P1-16	—

• Lien, pour chaque surface, vers le commentaire portant le verdict Bastion.
• Règle de gate opposable : une issue de code dont la surface n'a pas de verdict n'est pas ouverte au travail.

5. Exclusions

• Aucune instruction de surface : les verdicts sont rendus par Bastion sur ses propres work units, pas ici. Cette issue les recense, elle ne les produit pas.
• Aucun code, aucun test, aucun artefact : c'est un gate.
• Aucune levée de veto : un veto se lève par un correctif ou par une acceptation de risque écrite dans l'ADR, jamais par une mise à jour de ce tableau.
• Confusion voisine à écarter : ce n'est pas un doublon des issues de code. Une issue de code porte les critères techniques de sa surface ; celle-ci porte la preuve que le verdict existe et sa date au regard de la phase.

6. Inputs and outputs

Entrées — ADR §3.10 intégralement ; les work units Bastion ouverts par Eleven.

Sorties — le tableau des dix surfaces avec verdict, date et lien ; l'état de gate de chaque issue de code.

7. Acceptance criteria

• RC-26 — Bastion a rendu une clearance ou un veto explicite sur chacune des dix surfaces, avant le code de la phase indiquée ; dix verdicts tracés, chacun avec son lien.
• Aucune issue de code d'une phase donnée n'a été ouverte au travail avant le verdict de sa surface — vérifié en confrontant la date du verdict à la date du premier commit de l'issue bloquée.
• Le verdict de la surface 4 précède tout commit de code du projet et toute communication publique — contrôle daté, pas déclaratif.
• Un veto encore ouvert apparaît explicitement comme tel, avec les issues qu'il bloque ; aucune surface n'est laissée sans verdict ni marquée « en cours » à la clôture.
• La surface 9 porte deux verdicts distincts, un par axe de coût — l'axe de mutation n'hérite rien de celui d'extraction (RC-38(a)).

8. Expected evidence

Tableau à dix lignes, chacune avec verdict, date, lien vers le commentaire Bastion, et issues bloquées ; matrice date de verdict × date de premier commit pour chaque issue gatée ; pour la surface 9, les deux verdicts par axe.

9. Risks and rollback

Risque principal — R2 et R7 conjointement : « Une revendication de sécurité fausse est pire qu'aucune revendication. » Le mode d'échec de ce gate n'est pas qu'un verdict manque — c'est qu'un verdict soit rendu après le code qu'il devait instruire, ce qui le transforme en ratification. La contre-mesure est que le critère porte sur la date relative, pas sur la présence.

Rollback — sans objet au sens technique : aucun artefact, aucun état. Si un code a été écrit avant le verdict de sa surface et que le verdict est un veto, le rollback n'est pas celui de ce gate mais celui de l'issue concernée, selon sa propre procédure. Ce tableau enregistre alors l'ordre réel, il ne le corrige pas — réécrire une date rendrait le gate inutile.

10. ADR clauses and invariants covered

§3.10 — les dix surfaces, intégralement, avec leur phase de gate ; « Les surfaces suivantes relèvent de Bastion et doivent être instruites avant toute ligne de code de la phase indiquée » ; « La revue adversariale de la revendication elle-même — surface (4) — précède donc tout code et toute communication publique. » §5 — R2, R7. RC-26.

---

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