Fusion de la tête du chantier (924a40d : lots B2 et F) dans le lot D

Les deux côtés gardés partout. Aux coutures :
- une objection (redit / contredit) porte sur deux articles, jamais sur un module ;
  un ordre ne se corrige pas, ni par son auteur ni par un autre ; une coquille du
  titre suit le chemin de F (l'auteur du titre, un administrateur pour le titre
  de départ, ou 3 jours), et documents.title suit à l'application ;
- votable() couvre les modules ; leurs totaux passent par shown_tally, à l'écran
  et dans document.json ;
- « Modules à voter » ne compte plus une version retenue par une objection (test
  vu rouge) ; la liste du groupe la compte toujours parmi les propositions en cours ;
- le panier : une fonction pour les articles et les modules, avec les versions
  retenues de F ; un nouvel article se propose dans une section, à sa fin, et peut
  répondre à une objection ;
- migrations 0007 (modules) puis 0008 (objections) ;
- C25 et C26 supportent un groupe d'essai où une voix suffit (dès 16 membres).

Boucle : fmt, clippy -D warnings, cargo test (227), svelte-check 0, vitest 55,
build, e2e 35 / 35 (C1–C33 et M1).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/adr/0003-corriger-n-est-pas-voter.md

@@ -1,5 +1,9 @@
 # 0003 — Corriger n'est pas voter
 
+> Complétée par [0010](0010-objections-et-coquilles-validees.md) (2026-10-31) : la règle de la
+> coquille ne change pas ; la coquille d'un autre attend son auteur (un administrateur pour un
+> texte du seed), ou 3 jours, et en vigueur seule une coquille validée change le texte.
+
 **Contexte.** « Ça ne peut pas devenir un système qui nécessite un vote pour corriger une
 coquille. » Mais une correction ne doit pas pouvoir changer le sens d'un texte voté — et tout
 membre peut corriger un texte en vigueur, qui est republié aussitôt.
@@ -24,7 +28,7 @@ ou de fond), jamais contre la correction précédente :
   ligne et tabulation) sont refusés partout où l'on écrit ; un titre tient sur une ligne.
 
 Sinon c'est **du fond** : nouvelle révision d'une proposition ouverte (par son auteur), votes
-antérieurs « à reconfirmer », signalements levés ; refusé sur un texte en vigueur ou de départ.
+antérieurs « à reconfirmer », réponse aux objections qui l'attendent (0010) ; refusé sur un texte en vigueur ou de départ.
 L'écriture ne vaut que sur le texte jugé : un texte entré en vigueur ou changé entre-temps
 donne un conflit. Les brouillons s'éditent librement.
 

docs/adr/0004-contradictions-signalees.md

@@ -1,5 +1,11 @@
 # 0004 — Contradictions : signalées par les personnes, bloquantes
 
+> **Remplacée** par [0010](0010-objections-et-coquilles-validees.md) (2026-10-31) : le
+> signalement devient l'objection « contredit », à côté de « redit » ; elle retient la dernière
+> arrivée des deux versions, qui ne se vote plus jusqu'à sa levée ; l'auteur répond, la personne
+> qui objecte lève ou réitère, et sans réponse de sa part sous 3 jours elle est levée. Les
+> signalements existants sont devenus des « contredit » (migration 0008).
+
 **Contexte.** « Il faut que 2 unités modulaires ne puissent pas passer en vigueur si elles se
 contredisent. » La contradiction est une question de sens : aucune règle ne la détecte sans
 se tromper, et l'IA est écartée pour l'instant.

docs/adr/0007-inertie-cinq-crans.md

@@ -66,7 +66,9 @@ s_k = M_k + (1 − M_k)·(1 − p̃^G_k)   ⇔   G_k = ln(1 − (s_k − M_k)/(1
 - **C reste un plancher** : à T ≤ C, R = C + B^W ; une seule voix ne fait jamais passer un
   texte dans Monnaie libre ;
 - le groupe d'essai (W = 2, C = 1) : la référence vaut 100 %, ramenée à 50 % ; G reste fini ;
-  il faut les deux voix, à tout cran.
+  il faut les deux voix, à tout cran. Cette garde tient à B^W : dès 16 membres, 0,1^W passe sous
+  la précision du calcul (1 + 10⁻¹⁶ = 1), et une voix seule suffit alors, C valant 1. Monnaie
+  libre n'est pas concernée (C = 50).
 
 Les réglages de la formule disent les deux, dans cet ordre (lot D) : la mesure telle quelle — sa
 part est celle de la valeur elle-même, une médiane de 2,5 votants sur 4 fait 62,5 %, jamais

docs/adr/0008-vote-par-transaction.md

@@ -3,7 +3,9 @@
 > Complète [0002](0002-vote-permanent.md) (vote permanent) et [0006](0006-acces-connect-trustinwallet.md)
 > (accès). Décision d'Yvv du 2026-10-30 (revue, L9) ; le format du bulletin, la voie du
 > portefeuille et les réglages sont les choix par défaut d'orch (Q5, Q6, Q7), isolés pour être
-> changés sans toucher au reste.
+> changés sans toucher au reste. Corrigé le 2026-10-31 après la relecture indépendante de
+> `74f96be` (lot B2) : finalité, recherche filtrée et paginée, tâche de fond, plafond, bulletin
+> Ğecko, bulletins lâchés, reçu.
 
 **Contexte.** Jusqu'ici, un vote était une ligne écrite par le serveur pour la session connectée.
 Dans Monnaie libre, l'électorat W est la toile de confiance, mais la connexion Ğ1
@@ -77,27 +79,55 @@ fait signer par l'extension de portefeuille du navigateur (interface standard `i
 l'offrent), avec **polkadot-api chargé au seul moment de signer**, et l'envoie à un nœud Ğ1
 (`LD_VOTE_NODES`). Sans portefeuille dans le navigateur : **Ğecko**, par un lien et un QR code
 `g1://<compte>?amount=0.1&comment=ld1:<H>` (un virement commenté, ce que Ğecko sait faire) ;
-ce bulletin-là n'est lié à aucun compte, et la page attend.
+ce bulletin-là n'est lié à aucun compte : seul un commentaire **payé** le tranche (voir la
+confirmation), et le serveur le guette, la page ouverte ou non.
+
+La page joint un nœud **avant** de demander la signature (comme polkadot-api, qui lit le nonce
+et le runtime) : un nœud muet ne reçoit jamais rien, la page le dit et lâche le bulletin.
 
 ### La confirmation — `crates/ld-server/src/ballots.rs`, `indexer.rs`
 
-Le serveur lit l'indexeur (duniter-squid, `LD_INDEXERS`) :
+Le serveur lit l'indexeur (duniter-squid, PostGraphile, `LD_INDEXERS`) :
 
 ```graphql
-query Ballot($hash: String!) {
-  txComments(condition: {hash: $hash}, orderBy: BLOCK_NUMBER_ASC, first: 20) {
+query Ballot($hash: String!, $filter: TxCommentFilter, $after: Cursor) {
+  squidStatus { height }
+  txComments(condition: {hash: $hash}, filter: $filter,
+             orderBy: [BLOCK_NUMBER_ASC, ID_ASC], first: 50, after: $after) {
+    pageInfo { hasNextPage endCursor }
     nodes { id blockNumber remark
       author { id identity { index name isMember } }
       transfersByCommentId { nodes { fromId toId amount } } } }
 }
 ```
 
-`hash` = `0x` + blake2b-256 des octets de la remarque. Il garde la première occurrence, dans
-l'ordre de la chaîne, qui ne vient pas d'un autre compte que celui lié, puis exige :
+`hash` = `0x` + blake2b-256 des octets de la remarque. Le `filter` ne demande que ce qui peut
+trancher : pour un bulletin lié, `{authorId: {equalTo: <compte lié>}}` ; pour un bulletin Ğecko,
+`{transfersByCommentId: {some: {toId: {equalTo: <compte des votes>}, amount:
+{greaterThanOrEqualTo: "<montant>"}}}}`. Les commentaires viennent dans l'ordre de la chaîne,
+**50 par page, page après page** (au plus 20 pages par lecture), jusqu'à celui qui tranche :
+des copies ne masquent jamais le vrai commentaire (l'ancienne requête s'arrêtait à 20 ; la
+remarque « Merci » en compte déjà 26 sur la chaîne).
+
+**La finalité.** L'indexeur sert la meilleure chaîne, blocs pas encore définitifs compris.
+`squidStatus` n'expose que `name`, `height` et `hash` (pas de `finalizedHeight`) ; `height` est
+le dernier bloc définitif traité. Relevé le 2026-10-31 sur indexer.duniter.org, par
+`{ squidStatus { height } blocks(orderBy: HEIGHT_DESC, first: 1) { nodes { height } } }` :
+`height` reste **3 blocs** derrière le plus récent bloc servi (3 407 340 contre 3 407 343, puis
+3 407 342 contre 3 407 345…), les 2 à 3 blocs de la finalité de Duniter v2. Seul un commentaire
+d'un bloc ≤ `height` compte, ou refuse ; au-dessus, le bulletin attend.
+
+Le moteur (`ld_engine::ballot::judge`) juge à nouveau ce qui revient. Un indexeur qui ignorerait
+le filtre ne change d'abord que le nombre de pages, mais au-delà de 1 000 copies nues placées
+avant le vrai commentaire (20 pages de 50), celui-ci n'est plus lu et le bulletin reste en attente
+(relecture de `7ffa4fd`) : cas théorique, un PostGraphile sans ce filtre répond par une erreur. Il garde le premier commentaire, dans l'ordre de la
+chaîne, qui n'est pas une copie : pour un bulletin lié, un commentaire d'un autre compte est une
+copie ; pour un bulletin Ğecko, **un commentaire sans le virement est une copie** (une remarque
+seule ne coûte rien à envoyer). Puis il exige :
 
 1. la remarque exacte ;
 2. dans la même transaction, un virement **du signataire vers le compte des votes**, d'au moins
-   le montant ;
+   le montant (`transfer` sinon — seulement pour un bulletin lié : son propre compte s'est trompé) ;
 3. une identité Ğ1 au signataire (`no_identity` sinon) ;
 4. que cette identité soit **membre maintenant** (`not_member` sinon) — par la règle de
    trustinWallet.
@@ -107,12 +137,20 @@ avec le bloc et le rang de l'évènement ; le balayage d'adoption tourne aussit
 demandé le bulletin voit ces votes comme « ton vote » — et seulement ceux de ses bulletins : une
 autre session ne voit jamais ce qu'a voté la même identité ailleurs.
 
-Le serveur relit l'indexeur pour chaque bulletin en attente toutes les 10 secondes (tâche de
-fond) et quand la page demande (au plus une lecture toutes les 3 secondes par bulletin). Un
-bulletin non vu en **24 heures** est lâché. Cas d'erreur, chacun testé : indexeur muet (le
-bulletin reste en attente), signataire non membre ou sans identité (refusé, et dit), mauvais
-montant ou mauvais destinataire (refusé), déjà confirmé (rien ne change), révision changée entre
-temps (le vote porte sur la révision votée : « à reconfirmer »).
+**La tâche de fond** passe toutes les 10 secondes et lit **50 bulletins en attente au plus, le
+moins récemment lu d'abord** (jamais lu, puis la plus ancienne lecture) : chaque bulletin en
+attente est lu au moins toutes les ⌈n / 50⌉ passes, que la page l'attende ou non (un code Ğecko,
+une fenêtre fermée). Une lecture de l'indexeur prend 0,5 à 2,1 s (mesuré le 31/10), donc une passe
+de 50 bulletins dure 25 à 100 s : il faudrait de l'ordre de 40 000 à 170 000 bulletins en attente
+pour qu'un seul ne soit pas lu dans ses 24 heures. La page, elle, fait lire son bulletin au plus toutes les 3 secondes.
+
+Un bulletin non vu en **24 heures** est **lu une dernière fois à son échéance**, puis lâché ;
+s'aucun indexeur ne répond, ou si son commentaire attend un bloc définitif, il reste en attente
+et relu, une heure au plus. Cas d'erreur, chacun testé : indexeur muet (le bulletin reste en
+attente), signataire non membre ou sans identité (refusé, et dit), mauvais montant ou mauvais
+destinataire (refusé si lié, ignoré si Ğecko), copie nue ou mal payée d'un bulletin Ğecko
+(ignorée), bloc pas encore définitif (en attente), déjà confirmé (rien ne change), révision
+changée entre temps (le vote porte sur la révision votée : « à reconfirmer »).
 
 ### Le dernier fait foi
 
@@ -122,9 +160,24 @@ un bulletin plus récent sur la chaîne. « Retirer mon vote » est un bulletin
 `none`. Les transactions d'un même compte gardent l'ordre de ses envois (le nonce) ; le désordre
 ne vient que de l'ordre de lecture de l'indexeur, et la règle l'absorbe.
 
-Un bulletin que le portefeuille n'a pas signé (refus, fonds insuffisants, compte absent) est lâché
-aussitôt par la page (`DELETE /api/ballots/{id}` : `expired`, raison `dropped`), pour ne pas
-rester « en attente » une journée. Jamais un bulletin confirmé.
+### Lâcher ou garder un bulletin
+
+**Rien n'est parti** : la page lâche le bulletin aussitôt (`DELETE /api/ballots/{id}` :
+`expired`, raison `dropped`), pour ne pas le montrer « en attente » une journée. C'est le cas :
+- d'un refus du portefeuille, d'un compte absent, de fonds insuffisants ;
+- d'un nœud muet **avant** la signature (la page joint le nœud d'abord) ;
+- d'une fenêtre fermée avant la signature ; si le portefeuille demande encore à ce moment (sa
+  propre fenêtre peut rester ouverte), le bulletin attend sa réponse : refusé, il est lâché ;
+- d'un refus de la chaîne : rejet du nœud (transaction invalide), ou transaction incluse mais
+  défaite (le virement a échoué, `batchAll` défait tout : aucune remarque).
+
+**La transaction a pu partir** — signée, puis le nœud ou le portefeuille se tait — : le bulletin
+est gardé, et la tâche de fond le guette jusqu'à son échéance. Un **code Ğecko** montré est gardé
+aussi, fenêtre fermée : on peut payer plus tard, depuis le téléphone. Jamais un bulletin confirmé
+n'est lâché.
+
+« Ton vote », sous l'article : un bulletin en attente demandé **avant** un vote confirmé sur la
+même ligne ne s'y montre plus ; un bulletin demandé après, si.
 
 ### Le vote groupé
 
@@ -132,7 +185,14 @@ Un panier : article par article ; « tout pour » / « tout contre » pour une s
 document — jamais pour un article dont plusieurs versions sont en concurrence : l'interface le
 montre, on choisit sa version. Puis **un geste** : une écriture (groupe géré), ou **une
 transaction** (chaîne) pour toutes les lignes, au même prix qu'une seule (0,1 Ğ1 par transaction,
-pas par ligne ; 200 lignes au plus, 20 bulletins en attente par session).
+pas par ligne ; 200 lignes au plus).
+
+**Le plafond vaut par identité, quelle que soit la session** : 20 bulletins au plus à la fois,
+en attente **ou lâchés depuis moins d'une heure** — lâcher un bulletin ne libère pas sa place
+aussitôt (la relecture avait créé 100 bulletins et 3 500 lignes en une session, par `DELETE`).
+La tâche de fond **purge** les bulletins lâchés, lignes comprises : un jour après qu'un
+portefeuille ne les a pas signés, une semaine après qu'ils n'ont pas été vus à temps (sous
+l'article, il le dit d'ici là). Un bulletin lâché n'a jamais compté : rien d'un vote ne se perd.
 
 ### Ce que voit la chaîne
 
@@ -140,13 +200,39 @@ Qu'un compte (et son identité) a envoyé 0,1 Ğ1 au compte des votes avec une r
 tel bloc : **qui a voté et quand, jamais quoi** — ni le document, ni le nombre de lignes, ni les
 choix. Le solde du compte des votes est public : il dit combien de votes ont été envoyés.
 
+Recoupée avec les totaux affichés en direct, la chaîne peut laisser deviner un choix (un total
+qui bouge juste après un vote) : une décision d'Yvv attend (secret par paliers, ou totaux en
+direct). En attendant, les totaux affichés passent par une seule fonction,
+`DocState::shown_tally` (et `shown_evaluation`), où une publication par paliers se branchera ;
+l'adoption lit `tally`. Deux lectures n'y passent pas encore et lisent les totaux en direct :
+l'aperçu des propositions bien cotées (`docs.rs`, `unit_states` et `proposal_states`) et les
+textes publiés (`publish.rs`). Elles s'y brancheront avec la décision d'Yvv.
+
 ### Ce que sait le serveur
 
 Les bulletins, leurs lignes, leurs sels, la session qui les a demandés et l'identité qui les a
 signés : il sait qui a voté quoi, comme pour un vote direct, et ne montre que les totaux. Il ne
 peut pas inventer un vote d'une identité (il faudrait sa signature sur la chaîne) ; il pourrait en
 taire un. Chaque vote compté se vérifie contre la chaîne en recalculant H depuis les lignes et le
-sel — ce que personne d'autre ne peut faire tant que les sels restent au serveur.
+sel.
+
+### Le reçu
+
+La note de recherche promet que chacun peut vérifier son propre vote avec son sel. Le serveur
+rend donc le bulletin **à l'identité qui l'a demandé, et à elle seule** (404 pour toute autre) :
+
+- `GET /api/ballots/{id}/receipt` — le reçu, à télécharger (`recu-vote-<date>-<id>.json`) : le
+  document, le compte lié, les lignes (version, révision, choix, et pour lire : l'article et son
+  titre), le sel, la forme canonique, H, la remarque, son empreinte pour l'indexeur, et où en est
+  le bulletin (état, bloc, évènement, signataire, identité comptée) ;
+- `GET /api/ballots` — son historique, le plus récent d'abord (sans les bulletins jamais signés).
+
+L'interface les montre dans la fenêtre de vote (« Télécharger ton reçu », « Tes bulletins ») et
+sur la page **« Tes bulletins »** (`/bulletins`), qui **vérifie un reçu dans le navigateur**, sans
+rien demander au serveur : elle recalcule la forme canonique et H (`web/src/lib/receipt.ts`, mêmes
+vecteurs que le moteur) et dit si le reçu donne bien sa remarque — à chercher dans l'historique
+de son portefeuille, ou sur la chaîne au bloc indiqué. Garder son reçu pour soi : avec le sel,
+n'importe qui recalculerait le choix.
 
 ### Les réglages (Q7) — `crates/ld-server/src/config.rs`
 
@@ -166,7 +252,9 @@ Migration `0006`, additive : `ballots` (le bulletin, son sel, H, `0x`+blake2b-25
 le compte et le montant du moment, l'état `pending | confirmed | refused | expired`, la raison,
 l'identité qui a voté, le signataire, le bloc, le rang, l'évènement, ce qui est entré en vigueur,
 les dates) et `ballot_lines` (version, révision, choix). `votes` gagne `source` (`server` par
-défaut : tous les votes d'avant restent tels quels), `block`, `event_index`, `ballot_id`.
+défaut : tous les votes d'avant restent tels quels), `block`, `event_index`, `ballot_id`. Les
+corrections du 2026-10-31 n'ajoutent pas de migration ; la purge efface les bulletins lâchés
+(`expired`) passé leur délai, jamais un bulletin confirmé ni refusé, jamais un vote.
 
 ## Coût
 
@@ -178,10 +266,21 @@ défaut : tous les votes d'avant restent tels quels), `block`, `event_index`, `b
   indexeurs se configurent ; lire les évènements sur un nœud serait l'étape suivante.
 - Le droit de vote se vérifie **au moment de la confirmation sur la chaîne** : un membre sorti
   de la toile ensuite garde ses voix.
-- Par Ğecko, le bulletin n'est lié à aucun compte : un autre compte qui recopierait la remarque
-  et la ferait inclure avant (en payant 0,1 Ğ1) prendrait ce bulletin — ses lignes compteraient
-  pour lui. Par l'extension, le bulletin est lié au compte et la copie est ignorée.
-- Un paiement Ğecko fait après 24 heures ne compte pas (il est perdu pour le vote).
+- Par Ğecko, le bulletin n'est lié à aucun compte. **Une copie nue de la remarque** (sans
+  virement, gratuite) **est ignorée** : elle ne refuse plus le bulletin. Seul un commentaire payé
+  le tranche. **Reste possible, la variante « prise par une copie payée »** : un autre compte qui
+  voit la remarque (dans la file des transactions, ou sur l'écran) et fait inclure avant une
+  copie **payée** (0,1 Ğ1 vers le compte des votes) prend ce bulletin — ses lignes comptent pour
+  lui, le paiement de la personne arrive après et ne compte plus. Elle coûte 0,1 Ğ1 à qui la tente
+  et se voit sur la chaîne ; un compte sans identité qui paie la copie fait refuser le bulletin
+  (`no_identity`). Par l'extension, le bulletin est lié au compte et toute copie est ignorée.
+- Par Ğecko, un virement d'un mauvais montant ou vers un autre compte laisse le bulletin en
+  attente (au lieu d'un refus), jusqu'à son échéance : on ne distingue pas une erreur d'une copie.
+- Un bulletin est lu une dernière fois à son échéance (24 heures) : ce qui est alors sur la
+  chaîne, en bloc définitif, compte encore ; un paiement Ğecko plus tardif est perdu pour le vote.
+- Une identité Ğ1 créée par un vote sur la chaîne, jamais connectée ici, ne retient pas son nom
+  face à une personne qui arrive par un lien d'équipe (comme tout membre de la toile qui n'est
+  jamais venu) ; une identité Ğ1 qui s'est connectée le garde.
 - polkadot-api : environ 180 Ko (66 Ko compressés) chargés au moment de signer seulement ;
   `node_modules` grossit d'environ 77 Mo (son outillage).
 - La chaîne montre la participation de chacun (qui a voté, quand, combien de fois).

docs/adr/0009-modules-ordre-et-titre.md

@@ -85,6 +85,23 @@ personne traduise le nouveau. Le titre du document dans les autres langues suit
 fraîches ou à revoir (`doc_title::sync`, rejoué aussi à chaque mise en file de publication : une
 coquille ou une traduction du titre en vigueur s'y reporte).
 
+### Face aux objections et aux coquilles des autres (ADR 0010)
+
+- **Une objection** (« redit », « contredit ») porte sur deux versions d'articles, jamais sur un
+  module : un titre ou un ordre ne se répète ni ne se contredit au sens d'un article
+  (`objections::raise` n'admet que des textes ; test
+  `the_generic_writing_stops_at_a_module_and_an_order_is_never_corrected`).
+- **Un ordre ne se corrige pas** (`409 order_fixed`), ni par son auteur ni par un autre : pas de
+  coquille d'un autre sur un ordre. **Une coquille du titre** suit le chemin de toute coquille :
+  celle d'un autre attend l'auteur du titre (un administrateur pour le titre de départ) ou
+  3 jours ; appliquée, elle republie, et `documents.title` suit.
+- `DocState::votable` couvre les modules comme les articles ; les totaux d'un module se lisent
+  par `shown_tally`, à l'écran et dans `document.json`.
+- **« Modules à voter »** ne compte pas une version retenue par une objection : personne ne peut
+  la voter tant qu'elle est retenue (un article dont la seule version ouverte est retenue sort
+  du compte, et y revient à la levée). La liste du groupe la compte toujours parmi les
+  propositions en cours, ouvertes.
+
 ### Publication
 
 `fr.md` ne change pas de forme : les articles dans leur ordre en vigueur, sous le titre en

docs/adr/0010-objections-et-coquilles-validees.md

@@ -0,0 +1,124 @@
+# 0010 — Objections « redit » / « contredit », coquilles validées, messagerie
+
+> Remplace [0004](0004-contradictions-signalees.md) (contradictions signalées) et complète
+> [0003](0003-corriger-n-est-pas-voter.md) (corriger n'est pas voter), dont la règle de la coquille
+> ne change pas. Décisions d'Yvv du 2026-10-30 (revue) ; la messagerie dans l'application et la
+> coquille d'un texte du seed validée par un administrateur sont les choix par défaut d'orch.
+> Lot F, 2026-10-31.
+
+**Contexte.** Le signalement de contradiction (0004) bloquait l'entrée en vigueur sans dire à
+qui revenait le geste suivant, et une coquille corrigée par n'importe qui changeait le texte
+d'un autre sans lui demander. Yvv, 2026-10-30 :
+
+- « Faudrait un "redit" en option avec "contredit" → faut rendre plus explicite que l'objection
+  doit être levée par l'auteur de la dernière arrivée pour être une proposition votable. Pour ce
+  qui constitue une répétition → modifier l'article cible ; pour une contradiction → reformuler.
+  → ping messagerie TrustinWallet → Lever l'objection ou Réitérer l'objection ; si pas de
+  réponse sous 3j, alors "levée". »
+- « Corriger coquille → ping auteur pour valid → idem 3j ça passe auto, mais auteur a toujours
+  la main tant que c'est pas le texte en vote. Sinon seule une coquille validée corrige le texte
+  en vote. » (« le texte en vote » : le texte en vigueur.)
+
+## Décision
+
+### Les objections — `crates/ld-engine/src/objection.rs`
+
+- Une objection dit qu'une version **redit** une autre (elle la répète) ou la **contredit**,
+  motif à l'appui (10 à 600 signes). Elle porte sur deux versions de texte de deux articles
+  différents, ouvertes ou en vigueur — jamais deux textes en vigueur (`both_in_force`).
+- Elle retient **la dernière arrivée** des deux (date de soumission, à défaut de création, puis
+  l'ordre d'écriture) ; **jamais un texte en vigueur** : si la dernière arrivée est en vigueur,
+  c'est l'autre qui est retenue. La version retenue est fixée quand l'objection est faite.
+- Tant que l'objection tient, la version retenue **ne se vote plus** (vote direct, vote groupé,
+  bulletin de la chaîne : `409 objection`) et **n'entre pas en vigueur**. Les votes déjà faits
+  restent ; un bulletin scellé avant l'objection et confirmé après compte, sans la faire entrer.
+- Une personne n'a qu'une objection debout sur une même paire (`objection_exists`).
+- **L'auteur de la version retenue répond** : pour une redite, il **modifie l'article visé**
+  (une proposition liée à l'objection, sur l'article de l'autre version, partie de son texte) ;
+  pour une contradiction, il **reformule** (une révision de fond de sa version, ou une
+  proposition liée sur son propre article). Une révision de fond de l'une ou l'autre des deux
+  versions vaut réponse ; une coquille, non. Une version du seed n'a pas d'auteur : tout membre
+  du groupe peut y répondre par une proposition liée.
+- Une réponse donne la main à **la personne qui objecte** : un message lui demande de **lever**
+  ou de **réitérer** dans les **3 jours** ; sans geste de sa part, l'objection est **levée** à
+  l'échéance. Un seul tour à la fois : une autre réponse pendant son tour ne change ni le
+  message ni l'échéance. Réitérer rend la main à l'auteur (tour suivant, sans échéance pour lui).
+- Lever : la personne qui a fait l'objection, à tout moment, ou un administrateur de
+  trustinWallet. Réitérer : elle seule. Retirer une des deux versions met fin à l'objection.
+  Une levée relance l'adoption : la version libérée entre en vigueur si ses voix suffisent.
+- Règles d'accès : `trustin_access::lifts_objection`, `reiterates_objection`.
+
+| Qui | Quoi | Effet | Échéance |
+|---|---|---|---|
+| tout membre du groupe | faire une objection « redit » ou « contredit » | la dernière arrivée (jamais un texte en vigueur) ne se vote plus ; message à son auteur | — |
+| l'auteur de la version retenue (tout membre pour une version du seed) | modifier l'article visé (redit) ou reformuler (contredit) | la main passe à la personne qui objecte ; message « lever ou réitérer » | 3 jours pour elle |
+| la personne qui objecte | lever | la version se vote de nouveau, et entre en vigueur si ses voix suffisent | — |
+| la personne qui objecte | réitérer | la main revient à l'auteur ; message « réponds à nouveau » | aucune pour l'auteur |
+| personne | (3 jours sans geste après une réponse) | levée « 3 jours sans suite » | — |
+| un administrateur | lever | levée « par un administrateur » | — |
+| l'auteur | retirer sa version | l'objection prend fin | — |
+
+### Les coquilles validées — `crates/ld-engine/src/correction.rs`
+
+La règle de la coquille (0003, `edit.rs`) ne change pas ; ce qui change, c'est qui la laisse
+entrer.
+
+- Sur **son propre texte** (l'auteur de la version ; un administrateur pour un texte du seed),
+  la correction s'applique tout de suite, comme avant.
+- Sur **celui d'un autre**, elle **attend** : un message à l'auteur de la version (aux
+  administrateurs qui ouvrent le groupe, pour un texte du seed) avec **valider / refuser** ; sans
+  réponse sous **3 jours**, elle s'applique d'elle-même.
+- **Tant que le texte n'est pas en vigueur, l'auteur garde la main** : il peut revenir sur une
+  correction appliquée (révision « correction retirée ») ou appliquer finalement une correction
+  refusée, tant que le texte est celui sur lequel elle a été écrite.
+- **En vigueur, seule une correction validée change le texte** : elle attend la validation (ou
+  l'échéance, qui vaut validation), et un refus est définitif.
+- Deux corrections en attente sur un même texte : chacune est jugée contre le texte voté ; à
+  l'application, la correction doit tomber sur le texte qu'elle a lu — sinon (une autre
+  correction, une révision de fond ou un retrait est passé entre-temps) elle est **périmée**
+  et l'interface demande de recharger.
+- Les traductions restent éditoriales : elles ne passent pas par une validation.
+- L'historique dit qui a écrit la correction et qui l'a validée (ou qu'elle est passée à
+  l'échéance) ; la correction en attente se lit, avec son diff, dans « Détails ».
+- Règle d'accès : `trustin_access::answers_typo`.
+
+| Qui | Quoi | Effet | Échéance |
+|---|---|---|---|
+| l'auteur de la version (un administrateur pour un texte du seed) | corriger une coquille | appliquée tout de suite, les votes restent | — |
+| tout autre membre | corriger une coquille | en attente ; message à l'auteur (aux administrateurs pour un texte du seed) | 3 jours, puis appliquée |
+| l'auteur (ou un administrateur pour le seed) | valider / refuser | appliquée / laissée de côté | — |
+| l'auteur, texte pas encore en vigueur | revenir au texte d'avant, ou appliquer finalement | la main reste à l'auteur | — |
+| texte en vigueur | — | seule une correction validée (ou passée à l'échéance) le change ; un refus est définitif | — |
+
+### La messagerie — `crates/ld-server/src/messages.rs`
+
+Une boîte **« Messages »** dans l'application, au menu, avec le nombre de non-lus (une pastille
+sur le bouton du menu en mobile) ; pas de courriel. Un message porte un objet (une objection, une
+coquille), son texte — dit par l'interface, dans la langue de la personne —, les gestes que
+l'objet lui demande **maintenant** (répondre, lever ou réitérer, valider ou refuser) et son
+échéance ; un message traité n'offre plus de geste et dit ce qu'il est devenu. Chacun ne lit
+que les siens (`trustin_access::reads_message`) ; agir sur l'objet lit ses messages. Un message
+ne se montre que tant que la personne ouvre le groupe dont il parle.
+
+### Les échéances — `crates/ld-server/src/deadlines.rs`
+
+Trois jours (`ANSWER_DAYS`). Le balayage d'adoption (toutes les 5 minutes) passe les
+échéances, et une fois au démarrage : une échéance passée pendant un arrêt est prise dès la
+reprise. L'horloge du serveur est injectable (`AppState::clock`) : les tests l'avancent, sans
+attendre ; la route `/api/dev/clock` n'existe qu'avec la connexion de développement.
+
+### La migration 0008
+
+Additive. Les signalements gardent leur table (`signals`) et y gagnent le genre, la version
+retenue, le tour, l'échéance, la réponse et la cause de la levée ; chaque signalement existant
+devient un **« contredit »** sans perte : levé, il le reste (par son auteur, un administrateur
+ou une révision, selon `lifted_by`) ; debout, il retient la dernière arrivée selon la règle
+ci-dessus (s'il visait deux textes aujourd'hui tous deux en vigueur, il ne retient rien et se
+lève à la main). Aucun message n'est créé pour le passé. S'y ajoutent les tables `typos` (les
+corrections des autres) et `messages`, et sur les révisions la correction d'origine et qui l'a
+validée.
+
+**Coût.** Une version retenue attend son auteur aussi longtemps qu'il ne répond pas : c'est la
+dernière arrivée, c'est à elle de s'expliquer. Une personne qui réitère sans fin garde une
+version hors du vote : un administrateur peut lever. Une coquille d'un autre met jusqu'à trois
+jours à paraître, et sur un texte du seed elle attend un administrateur.

docs/adr/README.md

@@ -8,9 +8,10 @@ pas une décision : on en écrit une nouvelle qui la remplace, et on le note dan
 | [0001](0001-rust-svelte.md) | Rust + Svelte, une image, SQLite | 2026-10-21 |
 | [0002](0002-vote-permanent.md) | Vote permanent : marge du texte en place et plancher C | 2026-10-21 |
 | [0003](0003-corriger-n-est-pas-voter.md) | Corriger n'est pas voter | 2026-10-21 |
-| [0004](0004-contradictions-signalees.md) | Contradictions : signalées par les personnes, bloquantes | 2026-10-21 |
+| [0004](0004-contradictions-signalees.md) | Contradictions : signalées par les personnes, bloquantes (remplacée par 0010) | 2026-10-21 |
 | [0005](0005-publication-git.md) | Publication par file d'envoi vers un dépôt git | 2026-10-21 |
 | [0006](0006-acces-connect-trustinwallet.md) | Accès : connect.monnaie-libre.fr, invitations, trustinWallet | 2026-10-21 |
 | [0007](0007-inertie-cinq-crans.md) | Inertie à cinq crans, calée sur la participation du groupe (complète 0002) | 2026-10-30 |
 | [0008](0008-vote-par-transaction.md) | Le vote par transaction sur la chaîne Ğ1 : bulletin scellé, confirmation par l'indexeur, le dernier fait foi | 2026-10-30 |
 | [0009](0009-modules-ordre-et-titre.md) | Les modules : l'ordre des articles de chaque section (inertie 2), le titre du document (inertie 4) | 2026-10-31 |
+| [0010](0010-objections-et-coquilles-validees.md) | Objections « redit » / « contredit », coquilles validées, messagerie (remplace 0004, complète 0003) | 2026-10-31 |