PD-283 — Revue d'acceptabilité (post-correction)¶

1. Références¶

• Spécification : PD-283-specification.md
• Tests contractuels : PD-283-tests.md
• Acceptabilité existante : PD-283-acceptability.md
• Date de revue : 2026-03-09
• Reviewer : ChatGPT (auditeur indépendant, temperature 0.1)

2. Suivi des écarts (append-only)¶

[2026-03-09] — Suivi S-01¶

• Statut précédent : OUVERT
• Statut actuel : OUVERT
• Justification factuelle :
• purgeStale() existe dans temp-file-manager.ts (lignes 121-136) mais n'est toujours pas invoqué au début de startExport() dans orchestrator.ts (lignes 84-224).
• Seul purgeAll() est appelé dans les blocs d'erreur (lignes 216, 261, 368) — nettoyage réactif, pas proactif.
• Conséquence : après un crash applicatif, des fichiers clairs temporaires issus d'un export précédent peuvent persister en sandbox jusqu'au prochain export échoué.
• Le stub documenté mentionne STUB: PD-XXX — aucune story Jira de destination n'est assignée.
• Preuve de vérification :
• Aucun commit correctif postérieur à 4090913 (docs(PD-283): acceptability step 7).
• Lecture directe de orchestrator.ts : purgeStale absent du flux startExport().
• INV-283-05 reste en RESERVE.

[2026-03-09] — Suivi S-03¶

• Statut précédent : OUVERT
• Statut actuel : OUVERT
• Justification factuelle :
• integrityHash est validé en format uniquement (regex ^[a-f0-9]{64}$ dans schemas.ts lignes 26-29).
• Aucune comparaison entre le hash du fichier téléchargé/déchiffré et integrityHash fourni par l'API.
• L'intégrité repose exclusivement sur HTTPS (transport security), sans vérification applicative.
• orchestrator.ts processOneProof() (lignes 278-313) : télécharge et déchiffre mais ne hash jamais le contenu pour comparaison.
• file-downloader.ts : aucune logique de vérification de hash.
• Le stub documenté mentionne STUB: PD-XXX — aucune story Jira de destination n'est assignée.
• Preuve de vérification :
• Aucun commit correctif postérieur à 4090913.
• Lecture directe des fichiers sources : aucune invocation de hash sur le contenu téléchargé.

[2026-03-09] — Suivi T-01¶

• Statut précédent : OUVERT
• Statut actuel : OUVERT
• Justification factuelle :
• file-downloader.ts (lignes 13-23) : le statut HTTP 403 est détecté comme URL_EXPIRED et lève une ExportError.
• file-downloader.ts (lignes 25-30) : URL_EXPIRED est classé comme erreur non-retryable (isNonRetryableError).
• Aucune logique de refresh automatique des URLs signées (pas de rappel à POST /exports/complaint-file).
• Le flux F-03 (CA-03) de la spécification exige un refresh API automatique puis reprise — ceci n'est pas implémenté.
• Le stub documenté mentionne STUB: PD-XXX — aucune story Jira de destination n'est assignée.
• Preuve de vérification :
• Aucun commit correctif postérieur à 4090913.
• TC-NOM-04 (URL refresh) : non implémenté dans la suite de tests — le test vérifie uniquement la propagation correcte de l'erreur, pas le refresh.

3. Verdict d'acceptabilité (courant)¶

Verdict actuel : ⚠️ ACCEPTÉ AVEC RÉSERVES Date : 2026-03-09 Motif synthétique : 3 écarts MAJEURS ouverts (S-01 purgeStale, S-03 integrityHash, T-01 URL refresh) — tous documentés comme limitations v1 mais sans story Jira de destination assignée (stubs PD-XXX). Les 13 invariants de sécurité sont couverts (1 avec réserve INV-283-05). 191/191 tests passent. Coverage 77.18% avec justification des fichiers à faible couverture.

4. Historique des verdicts¶