PD-293 — Rapport de confrontation (Étape 8 — Gate Closure)¶

Ce rapport est produit par l'orchestrateur Claude avant la gate PMO 8. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontées¶

2. Convergences¶

• Machine d'états : Les 8 états (STARTING, RUNNING, ESCALADED, PAUSED, DONE, ABORTED, CRASHED, START_FAILED) et leurs transitions autorisées sont identiques dans la spec §5.2, le plan C1 (matrice declare -A TRANSITIONS), les tests TC-INV-01/TC-INV-02, le code-contracts module state-machine, et confirmés par l'acceptabilité (21/21 tests FSM passent).

• 14 invariants : Tous les INV-293-01 à INV-293-14 sont tracés de manière cohérente dans la spec, la matrice de couverture des tests (§2), le mapping invariants→mécanismes du plan (§3), et les contracts. L'acceptabilité confirme 12/14 PASS et 2 réserves documentées.

• 7 commandes /gov-lord : start, status, escalade, respond, pause, resume, stop — identiques dans spec §4.2, plan C5/C6, tests (couverture fonctionnelle), et code-contracts module commands.

• Idempotence : Le mécanisme 3 états (NEW, REPLAY, CONFLICT) est cohérent entre spec §5.1, plan C4, tests TC-NOM-08/TC-ERR-08/TC-ERR-11, et code-contracts persistence.

• FIFO multi-escalade : La file d'escalades ordonnée par created_at avec traitement FIFO est convergente dans spec INV-293-13, plan §2.2, tests TC-NOM-13, et contracts module persistence.

• Détection crash : ≤ 2 cycles polling → CRASHED est cohérent dans spec INV-293-08, plan §2.4 (missed_polls), tests TC-NOM-06/TC-ERR-07, et acceptabilité.

• Isolation Ringbearer : Chaque Ringbearer = process claude -p séparé, aucun partage — convergent entre spec INV-293-03, plan §3 mapping, tests TC-NOM-09/TC-NR-03, et acceptabilité.

• Validation stricte §5.1 : Les regex/enum/bornes sont cohérents entre spec, plan C2, tests TC-NEG-01..10, code-contracts module validator, et acceptabilité (24/24 tests validator passent).

• Schéma JSON §5.4 : Le format .gov-lord-state.json est identique entre spec et plan, avec la décision peer_id sentinelle "pending-{story_id}" documentée dans les deux (H-TECH-09).

• Format log rejet §6.1 : Le format JSONL normatif avec convention peer_id="sovereign" pour les commandes Sovereign est cohérent entre spec, plan §6, et code-contracts module validator.

3. Divergences¶

⚠️ Les conflits ne doivent JAMAIS être lissés. Chaque divergence est rendue visible.

• DIV-01 : Ordre des gardes start — 3 gardes (spec) vs 4 gardes (plan)
• Spec §5.1 règle 3 : quota -> doublon idempotence -> validation format complete (3 gardes)
• Plan §2.1 : quota -> idempotence -> format -> doublon story (4 gardes, "story déjà active" est un 4e garde distinct)
• Le plan et les contracts module orchestrator listent explicitement : "Ordre des gardes pour start : quota -> idempotence -> format -> story non-dupliquee."
• La spec ERR-293-02 (start sur story_id déjà active → rejet) existe mais n'est pas dans la liste ordonnée de gardes §5.1.

• Impact : TC-INV-03 teste uniquement quota en première garde. Le 4e garde (doublon story) n'a pas de test d'ordre dédié. Incohérence formelle entre le nombre de gardes dans la spec et le plan. Gravité : mineure — le comportement final est correct (doublon rejeté dans tous les cas), seule la position relative de la garde 4 est non spécifiée.

• DIV-02 : Couverture tests réelle vs plan — 45 tests (C1+C2) vs couverture complète attendue

• Acceptabilité Phase 1 : 21/21 FSM (C1) + 24/24 validator (C2) = 45 tests
• Plan §5 / Périmètre de test : liste des tests unitaires C4, intégration C5, perf TC-NOM-04, non-régression TC-NR-01..04 comme in scope
• Acceptabilité review QA : confirme explicitement que C3 (broker), C4 (persistence), C5 (orchestrator) n'ont pas de tests unitaires dédiés

• Impact : L'acceptabilité déclare "prêt pour Gate 8" avec seulement C1+C2 testés. Le plan promettait une couverture minimale de 80% sur C1-C6. Les tests d'intégration C5, persistence C4, et broker C3 listés dans le plan ne sont pas implémentés. Gravité : majeure — 3 composants sur 6 sans couverture de test, dont l'orchestrateur C5 qui porte la logique métier principale.

• DIV-03 : Transition ESCALADED->RUNNING — ambiguïté spec vs décision plan

• Spec INV-293-06 : "Une escalade suspend la progression de la story jusqu'à réception d'un PO_RESPONSE valide." (au singulier)
• Spec §5.3 point 5 : "respond : injection d'une décision humaine sur la plus ancienne escalade ouverte de la story cible (FIFO intra-story)."
• Plan §2.2 précision : "La transition ESCALADED->RUNNING ne s'effectue que lorsque TOUTES les escalades OPEN de la story sont traitées."
• Code-contracts orchestrator : "Multi-escalade : transition ESCALADED->RUNNING uniquement quand TOUTES les escalades OPEN de la story sont traitées."
• La spec ne dit jamais explicitement si la story reste ESCALADED après réponse à une escalade quand d'autres sont encore OPEN. Le plan tranche dans un sens (TOUTES doivent être traitées). C'est une décision d'implémentation non couverte par un invariant spec.

• Impact : Le test TC-NOM-13 vérifie l'ordre FIFO mais pas le maintien en ESCALADED tant que des escalades restent OPEN. Gravité : mineure — la décision du plan est plus conservatrice et cohérente avec l'esprit de INV-293-06, mais elle devrait être explicitement documentée dans la spec.

• DIV-04 : INV-293-02 — réserve acceptabilité sur diagrammes de séquence

• Spec §5bis diagramme séquence : flèches directes O->>R et R->>O (One Ring → Ringbearer)
• Plan §9.4 : "INV-293-02 fait foi. Les flèches directes du diagramme §5bis sont des raccourcis visuels."
• Acceptabilité review code : "INV-293-02 : diagrammes séquence montrent flèches directes O→R (raccourci visuel, tout passe par broker en réalité)"

• Impact : Le diagramme de la spec contredit textuellement l'invariant INV-293-02. Même si c'est un raccourci visuel admis, le document de spec n'a pas été corrigé. Gravité : mineure — réserve documentée, le plan corrige avec le diagramme enrichi §2ter.

• DIV-05 : INV-293-05 — réserve acceptabilité sur timestamps

• Spec §5.1 : regex timestamp décrite comme "horodatage UTC parseable (suffixe Z ou offset UTC)"
• Plan H-TECH-08 : "Strictement Z uniquement. Tout offset non-zero est rejeté."
• Acceptabilité review code : "INV-293-05 : timestamp Z strict dans code vs spec autorisant offsets — décision H-TECH-08 documentée"
• Impact : Le code implémenté est plus restrictif que la spec. La spec autorise les offsets, le code les rejette. La décision est tracée mais la spec n'a pas été amendée. Gravité : mineure — plus restrictif est plus sûr, mais la divergence formelle reste.

4. Zones d'ombre¶

• ZO-01 : TTL escalade et pause — pas de tests ni d'implémentation visible

• La spec §5.1 définit escalade_wait_ttl (72h) et pause_ttl (24h) avec alertes répétées à expiration. Ni le plan, ni les tests, ni l'acceptabilité ne mentionnent l'implémentation de ces mécanismes d'alerte temporelle. Le plan §9.2 mentionne D1 ("pas d'état ESCALADE_EXPIRED") mais ne traite pas les alertes répétées que la spec prévoit pour escalade_wait_ttl dépassé.

• ZO-02 : Reconnexion broker — timing exact des retries non testé

• La spec et le plan spécifient "1s, 2s, 4s, 8s, 10s max" (backoff exponentiel borné). TC-ERR-10 teste "mode dégradé puis reprise" mais aucun test ne vérifie les intervalles exacts de retry. L'acceptabilité ne mentionne pas ce test.

• ZO-03 : missed_polls absent du schéma §5.4

• Le plan §2.4 utilise un compteur missed_polls par story pour la détection crash. Ce champ n'apparaît pas dans le schéma JSON §5.4 de la spec ni dans le schéma du plan. Si One Ring crash et redémarre, missed_polls est perdu et la détection crash reprend à zéro. Aucun document ne traite ce cas de reprise.

• ZO-04 : TC-NOM-14 (ajouté par le plan) — statut d'implémentation inconnu

• Le plan ajoute TC-NOM-14 pour couvrir CA-02 (start nominal complet). L'acceptabilité ne le mentionne pas dans ses 45 tests passants. Il n'est pas clair si ce test a été implémenté.

• ZO-05 : lord_count_open_escalades(story_id) — interface orpheline

• Cette interface est définie dans le code-contracts module persistence mais n'est mentionnée ni dans la spec ni dans les tests. Elle est nécessaire pour la précision multi-escalade du plan §2.2 (vérifier s'il reste des escalades OPEN avant transition ESCALADED→RUNNING), mais aucun test ne la couvre explicitement.

• ZO-06 : Hypothèse H-293-04 — protocole messages non vérifié

• La spec et le plan identifient tous deux que le protocole de messages requis doit être supporté par les peers "sans adaptation de /gov". L'acceptabilité ne mentionne aucune vérification de cette hypothèse. Le plan §9.1 R2 identifie ce risque comme "Élevé". Si les Ringbearers ne produisent pas de STATUS_UPDATE, ESCALADE, etc., l'intégralité du système est non fonctionnelle.

• ZO-07 : Comportement exact de start si broker DOWN

• La spec ERR-293-06 dit "État dégradé + alerte Sovereign + retries reconnection". Le plan §2.1 lance le Ringbearer (claude -p) puis la supervision prend le relais. Mais que se passe-t-il si le broker est DOWN au moment du start ? Le Ringbearer est-il lancé quand même (il ne pourra pas s'enregistrer) ? Aucun document ne clarifie ce cas.

5. Recommandation¶

• Procéder — convergence confirmée, aucun conflit bloquant
• Rework nécessaire — divergences à résoudre avant de continuer
• Escalade — décision humaine requise sur un point structurant

Justification :

DIV-02 est le point critique : l'acceptabilité déclare "prêt pour Gate 8" avec seulement 2 composants sur 6 testés (C1, C2). L'orchestrateur (C5), la persistence (C4) et le broker-adapter (C3) — qui portent respectivement la logique métier, l'intégrité des données et la communication — n'ont aucun test dédié. Le plan promettait 80% de couverture sur C1-C6.

Actions minimales pour lever le blocage : 1. Documenter explicitement que la couverture C3/C4/C5 est reportée en v2 (dette technique acceptée), OU implémenter les tests manquants. 2. Amender la spec §5.1 garde start pour inclure le 4e garde "doublon story" (DIV-01) ou justifier l'écart. 3. Clarifier le comportement multi-escalade ESCALADED→RUNNING dans la spec (DIV-03) pour aligner avec la décision du plan.

Les divergences DIV-04 et DIV-05 sont des réserves mineures documentées, acceptables en l'état. Les zones d'ombre ZO-01 à ZO-07 sont des points de vigilance pour la review PMO mais ne sont pas individuellement bloquants.