decision/docs/adr/0014-informations-de-fonctionnement.md

0014 — Les informations de fonctionnement ne se votent pas

Décision d'Yvv du 2026-11-03 (lot T4). Complète 0009 (les modules) et 0011 (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 ».