Note historique sur l’expérience Alpha 5 antérieure à la refonte : événements signés, ancrages limités aux condensats et liaison Railgun. Elle ne décrit pas la version actuelle.
Sur cette page
Ce qui a changé
Les événements opérationnels sont représentés par des condensats JSON canoniques et des signatures Ed25519 avant tout éventuel ancrage public.
Les ancrages conservent des condensats plutôt que des données privées ; les enregistrements de liaison des paiements contiennent les condensats d’acceptation, les nullifiers et les engagements.
La même trace relie approbations, contrats, jalons, avenants, factures, demandes de paiement et reçus, sans faire de la chaîne le stockage principal.
Les enregistrements locaux font autorité
Contrats, jalons, approbations, avenants, factures, demandes de paiement et reçus restent des enregistrements applicatifs. La couche de preuve en dérive des représentations canoniques d’événements ; elle ne déplace pas la base opérationnelle sur une chaîne publique.
Chaque événement peut être sérialisé de façon déterministe, haché puis signé avant d’envisager un ancrage externe. Cet ordre donne au flux local un historique vérifiable sans faire dépendre son fonctionnement courant d’une infrastructure publique de règlement.
La divulgation est séparée par couche
Données privées, signatures, ancrages de condensats et liaisons de paiement sont traités comme des objets distincts. Un ancrage public peut conserver un condensat sans publier le contrat, la fiche du bien, la pièce justificative ou l’identité du foyer sous-jacent.
L’enregistrement du paiement lie l’acceptation d’un jalon au règlement par des engagements et des nullifiers. Il établit une continuité entre un travail approuvé et un transfert privé sans constituer un historique des paiements en clair.
La vérification suit le déroulement du travail
Il ne suffit pas d’affirmer qu’un événement a été signé. La trace doit préserver l’ordre entre relation, contrat, preuves du jalon, acceptation, demande de paiement, liaison au règlement et reçu.
Les points de rupture deviennent ainsi visibles : un événement non signé, un condensat d’acceptation incohérent ou une liaison absente ne peuvent pas être présentés comme un paiement vérifié et terminé. L’interface peut rester utilisable tout en montrant exactement l’étape de preuve manquante.
Note d’ingénierie
Cette architecture appartient à la branche archivée antérieure à la refonte. L’application actuelle utilise une interface Next.js, une API Go, PostgreSQL, des pièces jointes privées et des invitations limitées aux prestataires ; l’intégration effective d’un prestataire de paiement reste inachevée.
Provenance
Cette note s’appuie sur le code vérifié de la branche archivée antérieure à la refonte, au commit fafa17d. Elle est conservée comme historique technique et ne décrit pas le produit actuel.