# 0014 — Les informations de fonctionnement ne se votent pas

> Décision d'Yvv du 2026-11-03 (lot T4). Complète [0009](0009-modules-ordre-et-titre.md) (les
> modules) et [0011](0011-propositions-seed.md) (les Propositions seed). La migration est la
> `0012`. Les textes, avant et après, sont relus dans
> `docs/chantiers/acte-certification/textes-amorce.md`.

**Contexte.** Le seed de l'Acte d'engagement portait, depuis la maquette, trois sections au bas du
document : `formule` (F1 « Formule de vote », F1.1 « Formule du seuil WoT », F1.2 « Paramètres par
défaut », F1.3 « Processus de dépôt officiel »), `inertie` (N1 « Réglage de l'inertie », N1.1
« Niveaux d'inertie ») et `ordonnancement` (O1 « Ordonnancement du document »), chacune avec son
module « ordre des articles » (ADR 0009). Les lots T à T3c ont réécrit F1.1, F1.2 et N1.1 pour
qu'ils disent les règles du moteur. Yvv, 2026-11-03 : « Attention les 3 derniers modules ne sont pas
de votes : ordonnancement, inertie, et formule de vote sont des infos de fonctionnement. Les votes
se font à leur place, et les infos doivent trouver leur place dans l'ux. […] Vire les 3 du bas de
la liste. »

## Décision

**Ce qui sort du document** : les sept articles F1, F1.1, F1.2, F1.3, N1, N1.1, O1, et les trois
modules `ordre.formule`, `ordre.inertie`, `ordre.ordonnancement`. Le document garde cinq
sections (introduction, fondamental, technique, conclusion, annexe) et 27 articles, dont quatre
Propositions seed : I1, E1, E12 « Responsabilité civique » (nouveau, entre E1 et E2) et E2.

**Hors du document, une unité n'est rien pour le vote.** Elle n'est ni lue avec son document
(`docs::load_state` ne lit que les unités sans `retired_at`, et leurs versions), donc ni listée,
ni comptée (`docs::group` : « propositions en cours » ; `overview::modules` : « modules à
voter »), ni mise dans l'ordre d'une section (`DocState::members`), ni publiée (`document.json` et
le Markdown lisent l'état du document ; `publish::waits_for_a_text` et `last_change` l'ignorent).
**Aucun vote futur** : l'API répond 404 à un vote, à la lecture d'une de ses versions, à une
correction, une traduction, une objection faite depuis elle, une proposition sur elle, un
changement d'inertie, un quorum, un ordre (`proposals::guarded` : la version doit être celle d'une
unité du document) ; 400 à un vote groupé qui la nomme (`lines`), à une objection qui la vise
(`other`) et à un nouvel article dans une section sortie (`section`). Rien n'est écrit par ces
refus.

**Une base neuve** naît sans eux : le seed ne les contient plus.

**Une base existante** (la production : Monnaie libre et le groupe d'essai) **n'efface rien**. La
migration `0012` est additive : `units.retired_at` (quand l'unité est sortie) et
`units.retired_reason` (l'amendement qui l'a sortie), les journaux `retirement_amendments` et
`article_amendments`. Le retrait `2026-11-03-fonctionnement-hors-vote`
(`crates/ld-server/src/retire.rs`) est décidé **une fois par document**, pour toutes les unités ou
aucune, et n'écrit que ces deux colonnes : ni leurs versions, ni leurs révisions, ni leurs
traductions, ni la file de publication ne changent. Il n'a lieu que si **aucune personne n'a
laissé de trace** sur l'une d'elles, dans l'une de ses versions, quoi qu'il en soit advenu, et il
dit la première trouvée (raison et code de l'unité) :

| Trace | Raison du refus |
|---|---|
| un vote du serveur, prouvé ou simulé | `votes` |
| une ligne de bulletin, quel que soit son sort | `ballots` |
| une adoption, une version entrée en vigueur ou confirmée, une inertie changée par un vote | `adopted` |
| une version écrite par un membre (texte, retrait, inertie, ordre) | `member_proposal` |
| une révision écrite par une personne, ou d'un genre qu'aucun amendement n'écrit ; une coquille, en attente ou refusée | `corrected` |
| une traduction écrite ou corrigée par un membre | `translation_edited` |
| une objection qui la nomme, levée ou non | `signalled` |
| un quorum fixé (`units.quorum`, `quorum_changes`) | `quorum_set` |

Un amendement du seed n'est pas une trace de personne : F1.1 à sa révision 3, F1.2 et N1.1 à leur
révision 4 (après M6c) ou 5 (après M8) sortent comme les autres. Refusé, rien ne bouge ; la
décision est consignée (`retirement_amendments` : l'issue, la raison, l'unité, les codes sortis)
et dans les journaux. Appliqué là où le document publie (Monnaie libre), une ligne s'ajoute à la
file ; comme toutes, elle attend le premier texte en vigueur (ADR 0011).

Les amendements qui réécrivaient ces textes (`2026-11-02-n1-regles`, `-o1-regles`,
`2026-11-03-f1-1-phrases`, `-f1-2-chiffres`, `-n1-1-chiffres`) sont **dépassés par le retrait**
(`superseded_by`) : le seed ne donne plus leur texte, ils ne se décident plus. Une production
restée à M6c sort donc F1.2 et N1.1 avec le texte de M6c.

## Les textes d'amorce

I1, E1 et E2 prennent les textes d'Yvv du 03/11 par trois amendements gardés de
`seed_amend.rs` sur la Proposition seed elle-même (`Version::SeedProposal`), jamais sur un texte
en vigueur : `2026-11-03-i1-amorce` (suit `2026-10-30-i1-raison-d-etre`), `2026-11-03-e1-amorce`,
`2026-11-03-e2-amorce`. Même garde que tout amendement du seed (une trace de personne refuse,
avec sa raison) ; la ligne d'historique `seed_proposal`, qui ne change aucun texte, est admise
quand l'amendement de Proposition seed l'a écrite, et seulement elle. Les amendements de
Proposition seed (`seed_proposal_amend.rs`) sont dépassés par eux.

E12 entre par un ajout gardé (`crates/ld-server/src/article_amend.rs`, sur le modèle de
`module_amend`), une fois par document : écrit comme une base neuve l'écrit
(`seed::write_unit`), **entre E1 et E2** tant qu'aucun vote n'existe sur l'ordre de la section
(`quorum::voted_units`) et qu'ils s'y suivent — l'ordre en vigueur, qui lit les positions, le dit
aussitôt —, sinon **en fin de section**, comme tout nouvel article. Refus : `code_taken` (une
autre unité porte déjà ce code), `no_section`. Le code E12 suit la famille des engagements (E3 à
E11 existent) ; la place vient de l'ordre de la section, pas du numéro.

## Ce que dira l'interface (lot U3)

Les informations de fonctionnement se montrent **hors du vote** : la formule du seuil, les crans
d'inertie, le quorum, l'ordonnancement, à leur place dans l'écran (Yvv : « les infos doivent
trouver leur place dans l'ux »), d'après les paramètres du moteur et du document, pas d'après
un texte voté. Les vérités que F1.1, F1.2 et N1.1 portaient, chacune vérifiée par un test
(lots T à T3c, `t3c-liste-fermee.md`), en sont la référence ; leurs derniers textes restent dans
`crates/ld-server/tests/fixtures/seed-m8/` et, en production, dans leurs lignes. T4 ne touche pas
`web/`.

## La file de publication

Rien n'y est effacé. Les lignes écrites pour ces textes avant T4 (les amendements de M5 à M8,
« F1.2 », « N1.1 »…) restent telles quelles ; comme toute la file, elles attendent le premier
texte en vigueur (ADR 0011) et partent avec lui : leurs raisons sont des lignes du message de
commit, alors que le contenu publié (`document.json`, le Markdown) ne contient plus ces
articles ; la ligne du retrait, ajoutée à la même file, dit qu'ils sont sortis.

## Le retour arrière

L'image d'avant (`de1b7eb`) ne connaît pas `retired_at` : elle lit les unités sans cette colonne
et les montre de nouveau, **telles qu'elles étaient** (versions, révisions, traductions, ordres
intacts : le retrait n'a écrit que ses deux colonnes). Elle démarre sur la base migrée : les
migrations inconnues sont tolérées (`open_db`). Ce que le retour ne défait pas : E12 reste
(une Proposition seed, que l'image d'avant lit comme les autres), I1, E1 et E2 gardent leurs
textes de T4 (une révision de plus).

**Prouvé** par le test `an_image_that_ignores_the_column_shows_the_rules_of_operation_as_they_were`
(`tests/amorce.rs` : la colonne remise à vide, la vue est celle d'avant), et le 2026-11-03 avec
l'image de `de1b7eb` elle-même, hors du dépôt : une base née du seed de production du 02/11 puis
démarrée par `de1b7eb` (un vote, un article de membre) ; l'image de T4 démarre dessus ; puis
`de1b7eb` de nouveau. Les sept articles et les trois ordres se lisent à l'identique dans les deux
groupes ; aucune ligne d'aucune table n'a disparu ; T4 n'a modifié que `retired_at` et
`retired_reason` (20 unités), et les trois Propositions seed amendées (6 versions, 12
traductions) ; `de1b7eb` relancée n'a rien écrit (une session de lecture). **Sur une copie de la
production**, la même procédure : relever chaque ligne de chaque table (rowid compris) ; démarrer
l'image de T4 sur la copie, sans clé de publication ; relever de nouveau (aucune ligne absente,
aucune colonne changée hors de celles-là) ; démarrer `de1b7eb` sur la copie et comparer
`GET /api/docs/{id}` d'avant et d'après pour F1 à O1 et `ordre.formule`, `ordre.inertie`,
`ordre.ordonnancement`.

Limite : le retrait n'est décidé qu'une fois ; si, après un
retour arrière, quelqu'un agit sur ces articles puis T4 revient, `retired_at` les sort de
nouveau sans relire la garde. Les remettre serait alors une décision (`retired_at` à NULL : une
écriture, pas un effacement).

## Limites connues

- **Une base d'avant M6** (I1, E1, E2 en vigueur, pas Propositions seed) : l'amendement de
  Proposition seed étant dépassé, ils restent en vigueur avec leur texte, et les trois
  amendements d'amorce refusent (`no_seed_proposal`). Aucune base réelle n'est dans ce cas.
- Un article de membre prend le code `N<n>` (`proposals::new_unit`) d'après le nombre de codes
  en `N` du document, unités sorties comprises : en production, N1 et N1.1 restent dans la base
  et aucun code n'est repris ; dans une base neuve, le premier article de membre est N1, sans
  rapport avec l'ancien « Réglage de l'inertie ».