PD-264 — Rapport de confrontation (Gate 5 — AMBIGUITY)¶

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

1. Sources confrontees¶

2. Convergences¶

2.1 Modele de donnees¶

• Spec SS5, Plan TASK-1, CC-264-01 : Les trois documents convergent sur nonce BYTEA NOT NULL (16 octets), CHECK constraint octet_length(nonce) = 16, index unique anti-rejeu. Aucun ecart.

2.2 Architecture de validation nonce¶

• Spec SS3 (garde d'entree), Plan TASK-4 (NonceValidationService), CC-264-04 : La garde d'entree fail-closed est decrite de maniere identique dans les trois documents. La requete sans nonce n'entre jamais dans l'automate.

2.3 Invariants et criteres d'acceptation¶

• Spec SS6/SS7 (14 INV, 12 CA), Plan SS12 (checklist), CC (invariants par module) : Le plan fournit une checklist pre-Gate 5 avec couverture 14/14 INV et 12/12 CA. Chaque invariant est mappe a au moins une TASK et un TC. Les code contracts reprennent les invariants pertinents par module.

2.4 Automate d'etats¶

• Spec SS3 (transitions autorisees/interdites), Plan SS2 (flux nominal/rejet), Tests TC-264-10/TC-264-11 : Les 4 transitions autorisees et 5 transitions interdites sont identiques dans tous les documents. L'etat RESPONSE_REJECTED in-memory est confirme dans le plan (R06) et les tests.

2.5 Securite — temps constant¶

• Spec SS8 (INV-264-04, protocole TC-264-07), Tests TC-264-07, Plan TASK-3/TASK-6 : Le protocole statistique est identique : Welch t-test + Mann-Whitney U, N=100000, alpha=0.01, Cliff's delta < 0.147. Procedure d'escalade coherente (rerun unique puis audit obligatoire).

2.6 Non-regression PD-55¶

• Tests SS3 (5 NR), Plan TASK-6 (mapping NR) : Les 5 tests de non-regression couvrent les 3 interfaces PD-55 impactees (persistance, append-only, Merkle) et les 2 proprietes transversales (immutabilite, transitions). Couverture coherente.

2.7 Atomicite ACCEPTED -> PERSISTED (INV-264-13)¶

• Spec SS6 INV-264-13, Tests TC-264-19, Plan SS2 (flux crash), CC-264-05 : Tous les documents convergent sur le scope borne : atomicite DB uniquement (transaction englobante), post-commit asynchrone pour append-only/Merkle, reconciliation PD-55 en cas d'echec.

2.8 Hors perimetre¶

• Spec SS4, Plan SS10 : Les exclusions sont strictement identiques (client QTSA complet, rotation certificats, nouvelle TSA externe, retention 10 ans).

2.9 Interoperabilite¶

• Spec INV-264-10, Tests TC-264-14, Plan TASK-6 : openssl ts -verify comme outil de reference. Le plan precise l'usage de fixtures DER reelles (pas auto-generees), ce qui renforce le constat R11 de Gate 3.

2.10 Verification formelle Prolog¶

• Spec CA-264-10, Tests TC-264-15, Plan TASK-7 : Objectif 18/18 coherent. Le plan precise les fichiers Prolog concernes.

3. Divergences¶

DIV-01 — Migration : desactivation temporaire du trigger d'immutabilite¶

• Spec SS5 : Mentionne la migration de VARCHAR(64) nullable vers BYTEA NOT NULL mais ne precise PAS la desactivation du trigger trg_timestamp_token_immutable.
• Plan TASK-1 SS9.2 : Detaille explicitement la necessite de DROP TRIGGER / CREATE TRIGGER dans la migration, car la Phase A fait un UPDATE bloque par le trigger.
• CC-264-01 : Liste comme forbidden de "laisser le trigger desactive apres la migration" mais ne mentionne pas la strategie de desactivation temporaire.
• Impact : Faible. Le plan clarifie un point d'implementation que la spec n'avait pas besoin de detailler. La contrainte CC est coherente (trigger reactif post-migration). Pas de conflit reel, mais la spec devrait etre explicite sur cette operation DDL si elle se veut exhaustive.

DIV-02 — Nonces de remplissage pour tokens existants (0x00...00)¶

• Spec SS5 : Ne mentionne PAS de strategie pour les tokens existants avec nonce = NULL.
• Plan TASK-1 Phase A : Propose de remplir les nonces NULL avec E'\\x00000000000000000000000000000000' (16 octets de zeros).
• Plan SS9.1 : Reconnait que ces nonces ne sont pas conformes INV-264-01 (pas de CSPRNG) mais les considere acceptables car anterieurs au contrat PD-264.
• Impact : Moyen. Le nonce 0x00...00 est un choix d'implementation non contractualise par la spec. Si deux tokens pre-PD-264 ont tous deux nonce = NULL, ils recevront le meme nonce 0x00...00, ce qui violerait la contrainte UNIQUE. Le plan ne traite pas ce cas de collision potentielle.

DIV-03 — Tests de migration (TC-MIG-*) absents du document de tests¶

• Tests : Ne contiennent PAS de TC-MIG-01, TC-MIG-02, TC-MIG-03. Les 18 TC + 5 NR ne couvrent pas la migration.
• Plan TASK-6 : Definit 3 TC de migration supplementaires (TC-MIG-01/02/03) en reponse au constat R02 de Gate 3.
• CC-264-06 : Mentionne "3 TC-MIG validant la migration DDL".
• Impact : Moyen. Les TC-MIG sont une addition du plan non presente dans le cahier de tests officiel. La matrice INV/CA du document de tests ne les inclut pas. Formellement, le cahier de tests est incomplet par rapport aux engagements du plan.

DIV-04 — Niveau de detail sur le worker de reconciliation PD-55¶

• Spec SS6 INV-264-13 : Reference le "worker de reconciliation PD-55" pour le rattrapage post-commit.
• Plan H-03 : Identifie explicitement l'hypothese que "le worker de reconciliation PD-55 ne fait pas d'hypothese sur le format du nonce (VARCHAR vs BYTEA)" avec mention "a verifier dans le code du worker".
• Impact : Moyen. Si le worker PD-55 lit ou compare le nonce en format specifique (ex: string hex), la migration BYTEA cassera la reconciliation. Le plan identifie le risque mais ne confirme pas la verification.

DIV-05 — Convention exit code TC-264-07 ESCALADE¶

• Tests TC-264-07 : Decrit le protocole statistique et la procedure d'escalade (rerun unique, puis audit obligatoire) mais ne precise PAS la convention d'exit code CI.
• Plan TASK-6 : Definit une convention detaillee : exit code 0 + artifact pour premier echec, exit code 1 + artifact pour deuxieme echec, stage CI separe security-timing avec allow_failure conditionnel.
• Impact : Faible. C'est un detail d'integration CI que les tests n'avaient pas vocation a specifier. Mais la convention devrait etre documentee quelque part de maniere contractuelle pour eviter toute ambiguite a l'implementation.

DIV-06 — Convention nightly TSA retry¶

• Tests TC-264-17 : Decrit "job nightly ; acces TSA qualifiee" et "token verifie et archive avec metadonnees probatoires horodatees" mais ne precise PAS la politique de retry ni le comportement si TSA indisponible.
• Plan TASK-6 : Definit retry 3x avec backoff exponentiel, skip avec artifact diagnostique si TSA indisponible, status unstable si skip.
• Impact : Faible. Detail d'implementation CI. Coherent avec le constat R07 de Gate 3.

4. Zones d'ombre¶

ZO-01 — Collision de nonces de remplissage (lien avec DIV-02)¶

Si plusieurs tokens pre-PD-264 ont nonce = NULL, la Phase A de migration leur attribue tous le meme nonce 0x00...00. La Phase C cree ensuite un index UNIQUE sur nonce. L'index unique echouera si plus d'un token a un nonce NULL.

Le plan ne traite pas ce scenario. Solution potentielle : generer un nonce unique (meme non-CSPRNG) pour chaque token existant, ou utiliser un hash de id comme differenciateur. Mais ceci n'est ni dans la spec ni dans le plan.

ZO-02 — Schema SQL complet de timestamp_tokens¶

• Spec SS5 : Reconnait explicitement que "le schema SQL complet de timestamp_tokens n'est pas fourni" et que "le nom exact de la contrainte/index existant et la convention de nommage SQL ne sont pas fournis".
• Plan TASK-1 : Choisit le nom idx_timestamp_token_nonce pour l'index unique et chk_nonce_length pour le CHECK, mais ne precise pas si ces noms suivent une convention projet existante.
• Impact : Faible. Noms raisonnables mais non valides formellement par une convention documentee.

ZO-03 — Verification effective du trigger type-agnostic (H-02)¶

• Plan Phase 0 Go/No-Go : Affirme "verifie : le trigger est bien inconditionnel".
• Plan H-02 : Repete cette affirmation.
• Aucun document ne fournit le code source du trigger pour verification independante. Le plan affirme un fait sans le prouver dans le corpus documentaire.
• Impact : Faible. L'affirmation est probablement correcte (trigger RAISE EXCEPTION inconditionnel est le pattern standard), mais la preuve n'est pas dans le dossier.

ZO-04 — Bibliotheque statistique pour TC-264-07¶

• Plan TASK-6 : Mentionne "bibliotheque npm (ex: simple-statistics ou implementation inline Welch t-test)" sans tranchement definitif.
• Impact : Faible. Choix d'implementation mineur. Mais si la bibliotheque choisie ne supporte pas Cliff's delta, il faudra une implementation inline supplementaire.

ZO-05 — Fichiers Prolog existants¶

• Plan TASK-7 : Reference formal-verification/prolog/rfc3161-rules.pl avec la mention "ou emplacement equivalent".
• L'emplacement exact des fichiers Prolog n'est pas confirme dans le corpus. Le score actuel (17/18) n'est pas justifie par un artefact dans le dossier.
• Impact : Faible. Risque de decouverte tardive d'un emplacement different ou d'un format incompatible.

ZO-06 — Scope exact de la verification statique TC-264-08¶

• Tests TC-264-08 : Mentionne "commande d'analyse statique (grep/AST) en CI" sans preciser l'outil exact ni la configuration.
• Plan TASK-6 : Mentionne "grep crypto.randomBytes(16)" comme verification statique.
• Un simple grep pourrait ne pas couvrir les indirections (import rename, wrapper, etc.).
• Impact : Faible. Un grep sur le chemin nonce est probablement suffisant vu le perimetre restreint du module.

5. Recommandation¶

• Proceder — convergence confirmee, aucun conflit bloquant

Justification : Les quatre documents sont fortement convergents sur les 14 INV, 12 CA, 18 TC et 7 TASK. La checklist INV/CA du plan est complete (26/26). Les divergences identifiees sont principalement des clarifications d'implementation (DIV-01, DIV-05, DIV-06) ou des additions legitimes du plan par rapport aux constats Gate 3 (DIV-03).

Points d'attention pour le reviewer Gate 5 :

1. DIV-02 / ZO-01 (prioritaire) : La strategie de nonce de remplissage 0x00...00 pour les tokens existants peut causer une violation de l'index UNIQUE si plusieurs tokens ont nonce = NULL. Le plan doit soit confirmer qu'il n'y a pas de tokens existants (H-01 non confirme), soit proposer une strategie de nonces uniques differenciables.

2. DIV-03 : Les TC-MIG ne sont pas dans le cahier de tests officiel. Le reviewer peut considerer ceci comme une lacune formelle du cahier de tests ou comme un enrichissement acceptable du plan.

3. DIV-04 / H-03 : La verification que le worker de reconciliation PD-55 est compatible avec le changement VARCHAR -> BYTEA est identifiee comme necessaire mais non confirmee.