# Archive des registres — d'où vient chaque fichier, et comment on le sait

La charte, section 11.3, conserve dix ans les **versions successives de la charte et
des registres**, pour l'auditabilité de la méthode. La section 14 les rend accessibles
à une adresse stable. Une version de registre archivée n'est pas une copie de travail :
c'est la pièce contre laquelle une analyse ancienne se rejoue. Si elle diverge du
registre qui a réellement produit cette analyse, elle ne prouve plus rien — elle
donne au contraire une fausse assurance, ce qui est pire que son absence.

Chaque entrée porte donc sa provenance et la manière dont l'identité a été établie.
Un fichier archivé sans cela est un fichier qu'on doit croire sur parole.

---

## Comment l'identité a été établie, et pourquoi pas autrement

**Ce qui a été fait.** L'empreinte affichée sur `pactem.io/registre` a été relevée
par WebFetch, puis comparée à l'empreinte du fichier du dépôt, calculée localement.
Les deux valeurs coïncident, donc le fichier archivé est celui que le service
publie — octet pour octet.

**Pourquoi les octets n'ont pas été transportés.** WebFetch convertit la page en
Markdown avant de la rendre : appelé sur `pactem.io/registre/registry_4C.json`, il a
rendu 39 583 signes pour un fichier de 49 278 octets. Il ne transporte donc pas les
octets, il les résume — s'en servir comme d'un canal de copie aurait produit un
fichier plausible et faux. Ce qu'il transporte fidèlement, en revanche, est une
valeur courte et vérifiable : l'empreinte que le serveur calcule **à l'affichage sur
le fichier qu'il sert réellement**.

**Pourquoi cette comparaison vaut mieux qu'une copie.** Les deux empreintes sont
produites par deux chemins indépendants — le serveur, sous Linux, avec le code de
`routes/publications.js` ; le poste, sous Windows, avec `Get-FileHash`. La règle 24
interdit de conclure d'une concordance entre deux mesures qui partagent leur défaut ;
ici elles ne partagent ni la machine, ni le code, ni le système de fichiers. Une
copie transportée, elle, n'aurait été confrontée à rien.

**Ce que cela n'établit pas.** Que le registre servi soit *le bon*. Cette archive
constate une identité, pas une légitimité : c'est le journal de calibration
(`registry/CALIBRATION_LOG.md`) qui porte la seconde.

---

## Les entrées

### `registry_4C_1.3.0.json`

| | |
|---|---|
| Version de registre | `1.3.0` |
| Publiée le | 2026-07-30 |
| Archivée le | 15 août 2026 |
| Source | `https://pactem.io/registre/registry_4C.json` |
| Page qui porte l'empreinte | `https://pactem.io/registre` |
| Empreinte SHA-256 du fichier | `2e0e11e7123a7fa088c2efdbf2bc4340463f3d4f2ca9e1975a283b56ffa7847d` |
| Sceau du registre (`content_hash`) | `7a6099fffad5cc0b8dc08ef3c3fe7d0f283173dab5c9837a7524780237be8254` |
| Octets | 49 278 |

L'empreinte relevée sur la page servie et l'empreinte mesurée sur le fichier
coïncident. Le sceau, lui, porte sur le **contenu canonicalisé privé du champ
`content_hash`** : les deux valeurs diffèrent, et c'est normal — un champ ne peut pas
contenir sa propre empreinte.

### `registry_4C_1.3.1.json`

| | |
|---|---|
| Version de registre | `1.3.1` |
| Publiée le | 2026-09-11 |
| Archivée le | 15 septembre 2026 |
| Source | `pactem-sources/registry/registry_4C.json`, commit `e93ef44` de ce dépôt — la source de vérité depuis le 13 septembre 2026, le sens de copie étant `pactem-sources` d'abord, le moteur ensuite |
| Comment l'identité a été établie | `cmp` octet pour octet entre le fichier déposé à la racine du moteur et la source ; puis `scripts/verifier-archive-registre.js` — sceau recalculé identique des deux côtés, archive identique octet pour octet au fichier servi |
| Empreinte SHA-256 du fichier | `329678381a9b9734b4abeffec67864abe1bf8a8f41394dcaf4513a22c5767162` |
| Sceau du registre (`content_hash`) | `e7d227ad37d3863847731646cb22c477a4bdabb36749269b8021861bf2b3b339` |
| Octets | 51 643 |

Onze champs textuels changés par rapport à 1.3.0 — dix énoncés de silence, un énoncé
de branche — aucun prédicat, aucun niveau, aucun `silence_regime` : voir
`registry/CALIBRATION_LOG.md`, entrée 1.3.1. Le fichier `registry_4C_livraison_2026-07-30_a7d47b10.json`
de la source (le registre livré, jamais servi) n'est pas repris ici : cette archive ne porte que
des versions servies.

---

## Ce qui garde cette archive

`scripts/verifier-archive-registre.js`, exécuté à chaque passage de la chaîne
d'intégration et **avant chaque déploiement**. Il compare le sceau du registre servi
à celui de l'archive de la même version, **recalculés l'un et l'autre** à partir du
contenu — jamais lus dans le champ `content_hash`, qu'un fichier altéré porterait
tout aussi bien. Un octet modifié d'un côté ou de l'autre le fait rougir, et une
sonde le prouve à chaque exécution des preuves du harnais.

Ce contrôle rend le registre **immuable à version constante** : modifier le registre
sans changer son numéro de version devient impossible en silence.