Le lien www → Kairos, capturé 2 482 fois et enregistré zéro fois

La question

Le lien www → Kairos est capturé 2 482 fois et enregistré zéro fois — que vaut l'appariement qu'il rend possible ?

Ce que l'échange a établi

Question vivante, jamais résultat — et pour la première fois de ce registre, elle n'est pas posée à l'auteur

Elle sort de sa réponse, mais elle porte sur notre outillage.

Le champ existe et il est vide

kairos_ref est déclaré dans le schéma d'index et vaut null sur 3 586 unités sur 3 586 ; bin/build-index.py:297 le dit sans détour : . Ce n'était pas une erreur, c'était un périmètre. La lettre en change le coût : l'appariement www → Kairos, document par document, était dans notre capture, et il y est encore.

Ce que cela vaut pour un moissonnage de Kairos

docs/KAIROS.md §7.4 posait que la découverte devrait se faire , faute de sitemap accessible. Un seed de 2 482 alias extraits hors ligne de notre propre miroir est un point de départ d'un autre ordre — et il ne coûte aucune requête.

Ce que cela ne vaut pas

Rien n'est mesuré sur ce que ces alias rendent : ni leur taux de réponse, ni leur contenu, ni leur survie à la migration Drupal 11 annoncée en #m5, §6. Les compter n'est pas les avoir lus. Et corpus/raw/ étant gitignoré, ce comptage se rejoue sur le miroir local, pas depuis un clone nu.

Point de sortie : phase 9

, protocole de reprise. Deux issues acceptables — extraire et enregistrer les kairos_ref, ou déclarer que le dépôt n'en fera rien et dire pourquoi. La troisième, laisser un champ nul dans un schéma sans que personne ne sache qu'il l'est, est celle que ce registre existe pour empêcher.

La seconde des deux issues est retenue, et c'est un refus motivé, pas un abandon

Le registre écrivait plus haut : C'est la seconde. Arbitrage d'EK du 2026-09-02 : le second corpus sort du périmètre de la v1. Aucun moissonnage n'a été fait, aucune kairos_ref n'a été extraite, bin/build-index.py n'a pas été modifié, corpus/index/ n'a pas été régénéré, et aucune requête réseau n'a été émise.

Ce que le registre refusait n'était pas le champ nul : c'était un champ nul que personne ne sait nul

La troisième voie est fermée, et elle l'est mécaniquement :

Ce que la décision vaut pour quelqu'un qui n'a pas le miroir, et il faut le dire

Le comptage des 2 482 alias se rejoue sur corpus/raw/ — 2 916 fichiers .gz, 95 Mo, gitignorés (git ls-files corpus/raw | wc -l → 0). Un lecteur qui cloné le dépôt ne peut pas refaire cette mesure : elle lui est opposable comme une déclaration datée, pas comme un fait qu'il vérifierait. Ce qu'il peut vérifier, en revanche, c'est tout le reste — les 3 586 null, la déclaration au schéma, la déclaration au fichier, et le code 1 du contrôle qui la protège. La partie non reproductible de ce fil est celle qui a ouvert la question ; la partie qui la referme est entièrement reproductible depuis un clone nu.

Ce qui n'a pas été touché, et c'est délibéré

docs/KAIROS.md n'est pas modifié : ses mesures sont datées et le dépôt ne réécrit pas ses mesures. Son verdict de moissonnabilité n'est ni retiré ni confirmé — REPRISE.md déclare la durée de validité de ce qu'il contient, et l'événement 4 de sa rubrique dit ce qui la périme. La phase 9 n'en dépend plus, ce qui est la vraie conséquence du refus.

Ce qui reste ouvert

Refermé le 2026-09-02 en phase 9 — le dépôt n'exploitera pas l'appariement : rien n'est mesuré sur ce que les alias rendent, et une exploitation exigeait un moissonnage que le périmètre v1 ne porte pas · le champ kairos_ref est déclaré nul — 3 586 / 3 586 — dans exports/turfu/SCHEMA.md et argumenté dans REPRISE.md, il n'est plus un nul silencieux

Renvois

• CORR-2026-09-02-judge-devuyst

Ces sources ne sont pas publiées, et c'est délibéré.

Elles sont vérifiables dans le dépôt, par qui le clone.

D'où viennent ces mesures

sources/correspondance/brouillons/2026-09-05-contribution-ek.md