Paiement 2.0.1 — publication vérifiée¶
Publié depuis le poste avec token local, sans CI ni déploiement. Image applicative Boot 4.1.2 / Java 21, dépendances DYNORS stables inchangées. Aucun package Maven ni BOM modifié. Publication horodatée : 2026-11-06T00:02:54.043Z.
Image : registry.gitlab.com/dynors/dynors-paiement/paiement-backend:2.0.1.
Référence immuable :
registry.gitlab.com/dynors/dynors-paiement/paiement-backend@sha256:8b87cf0b63d23809661d59833ec0df340678c53101cc8ddda3f7d8dcd64b5ae8
Source image : 2154d64a2180cf20b429b7a00d762b60a707cea4. JAR SHA-256 : 26516572fd5a5da99989170cf0f729f2eb4ef93a5a2f0e30b975a027ddc54f49. Le tag applicatif v2.0.1 référence cette source ; les reçus et guides complétés sont conservés sur release/paiement-2.0.1.
Correction et compatibilité¶
La collection optionnelle DYNORS_PAIEMENT_DELIVERY_COLLECTION_JSON contient plusieurs portées application|tenant|entité légale, chacune avec ses destinations. Le nom évite une collision entre le binding ENV et la map historique targets. Les documents JSON ambigus ou mal formés sont refusés au démarrage. La table historique reste supportée ; combiner les deux sources est refusé.
Aucun changement de dépendances, migrations SQL, noms d'événements ou routes. Le type de confirmation reste paiement.payment.completed, schéma 1. Le guide consommateur incorpore la clarification documentaire publiée après 2.0.0. La collection ne filtre pas les types d'événements et ne provisionne pas les admissions SLY.
Voir le guide de configuration, le contrat de confirmation et la migration. La 2.0.0 reste immuable.
Preuves¶
- 191 tests sous Microsoft OpenJDK 21.0.11 : aucun échec, erreur ou ignoré ; bootJar et noLegacyGuard réussis avec le numéro stable.
- Injection du JAR stable : gel SIRRAT synthétique → rendu/garde Ops existants → Docker Compose → propriétés Spring. Métacaractères préservés et portées séparées. Ceci ne qualifie pas le circuit complet d'autorisation/exécution SIRRAT.
- Deux images exactes démarrées sur PostgreSQL 17.11 privé avec collection synthétique : UID 10001, readiness/health 200, administration anonyme, bearer invalide et Prometheus anonyme refusés par 401. JRE image Temurin 21.0.13. Le rôle de fixture est non-superuser et sans BYPASSRLS, propriétaire de sa base pour les migrations ; ce banc ne qualifie pas une séparation migrateur/runtime.
- ARM64 natif : environ 23 s pour démarrage et contrôles. AMD64 sous émulation : environ 166 s au second passage. Le premier essai AMD64 a atteint la limite de 180 sondages sans readiness ; il reste enregistré. Le banc a ensuite utilisé une fenêtre de 600 sondages. Ces mesures ne constituent ni un SLA de démarrage ni un benchmark AMD64 natif.
- Une première tentative d'envoi au registre a été interrompue par une coupure réseau ; le renvoi des mêmes images a réussi. Manifests, configurations, attestations et JAR retéléchargés vérifiés ; voir
publication.json,image-qualification.jsonetqualification-attempts.json.
La référence de base Java reste épinglée par digest. Aucun tag latest déplacé. Les preuves 2.0.0 restent conservées séparément.
Avant activation¶
Le template Forge/SIRRAT associé reste à revoir, sur fix/forge-event-templates (voir code.md à la racine de dynors-internal). Sa publication dans un catalogue actif, son intégration et la recette réelle ne sont pas autorisées par la publication Paiement.
Vault/ESO, Auth/PDP/SLY réels, TLS, admissions et éventuelles jonctions, contrat PSP et recette marchande restent à qualifier. Pour DAWALALE, inclure l'appel retour de relecture du statut ainsi que doublons et effet métier transactionnel. Aucun PSP réel, migration de données, parcours refund/payout ou déploiement n'a été exécuté. Le bus conserve sa gate propre.
Release GitLab. Le build MkDocs ne déclenche pas le déploiement GitLab Pages ; ne pas confondre mise à jour des sources et visibilité déjà acquise sur le site.