Sprint 5 : integration et production -- securite, performance, API publique, documentation

Backend: rate limiter, security headers, blockchain cache service avec RPC,
public API (7 endpoints read-only), WebSocket auth + heartbeat, DB connection
pooling, structured logging, health check DB. Frontend: API retry/timeout,
WebSocket auth + heartbeat + typed events, notifications toast, mobile hamburger
+ drawer, error boundary, offline banner, loading skeletons, dashboard enrichi.
Documentation: guides utilisateur complets (demarrage, vote, sanctuaire, FAQ 30+),
guide deploiement, politique securite. 123 tests, 155 fichiers.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Yvv
2026-02-28 15:12:50 +01:00
parent 3cb1754592
commit 403b94fa2c
31 changed files with 4472 additions and 356 deletions

View File

@@ -5,9 +5,11 @@ description: Guide des documents de reference sur Glibredecision
# Documents de reference
## Principe
## Qu'est-ce qu'un document de reference ?
Les documents de reference sont les textes fondateurs de la communaute Duniter/G1. Ils sont **modulaires** : chaque document est compose d'items individuels (clauses, regles, verifications, preambules, sections) qui peuvent etre modifies independamment par proposition et vote.
Un document de reference est un **texte fondateur** de la communaute Duniter/G1. Il peut s'agir d'une licence monetaire, d'un engagement que les membres s'engagent a respecter, d'un reglement interieur ou d'un texte constitutif. Ces documents definissent les regles, les valeurs et le fonctionnement de la communaute.
Ce qui rend Glibredecision unique, c'est que ces documents sont **modulaires** et sous **vote permanent** : chaque document est compose d'items individuels (clauses, regles, verifications, preambules, sections) qui peuvent etre modifies independamment par proposition et vote. La communaute peut faire evoluer ses textes de maniere continue, sans procedure lourde ni periode speciale.
## Types de documents
@@ -18,6 +20,38 @@ Les documents de reference sont les textes fondateurs de la communaute Duniter/G
| Reglement | Reglement interieur d'un organe | Reglement du Comite Technique |
| Constitution | Texte constitutif fondamental | -- |
## Structure : Document, Items et Versions
Un document est organise selon une structure a trois niveaux :
```
Document (ex: Licence G1 v2.0.0)
|
+-- Item 1 (clause 1 : Preambule)
| |-- Version 1.0 (texte courant)
| |-- Version 1.1 (proposition en attente)
|
+-- Item 2 (regle 2.1 : Conditions d'adhesion)
| |-- Version 1.0 (texte courant)
|
+-- Item 3 (verification 3.1 : Distance rule)
|-- Version 1.0 (texte courant)
|-- Version 1.1 (proposition rejetee)
|-- Version 1.2 (proposition en vote)
```
### Document
Le document est le conteneur. Il possede un titre, un type, un numero de version semantique (ex: `2.0.0`), un statut et une description.
### Item
Chaque item est une unite modulaire du document : une clause, une regle, une verification, un preambule ou une section. Chaque item a une position hierarchique (ex: "1", "1.1", "3.2") et un texte courant.
### Version
Chaque modification proposee a un item cree une nouvelle version. La version contient le texte propose, un diff automatique par rapport au texte courant, et la justification de l'auteur. Les versions suivent un cycle de vie : proposee, en vote, acceptee ou rejetee.
## Consulter un document
1. Rendez-vous dans la section **Documents**.
@@ -53,6 +87,14 @@ La proposition cree une nouvelle **version** de l'item. Cette version passe ensu
Plusieurs versions peuvent etre proposees simultanement pour un meme item. Lorsqu'une version est acceptee, toutes les autres versions en attente sont automatiquement rejetees.
::
## Vote permanent sur les items
Les documents actifs sont sous **vote permanent** : il n'y a pas de periode speciale pour proposer des changements. A tout moment, un membre authentifie peut proposer une modification a n'importe quel item.
Chaque item peut avoir un **protocole de vote specifique** qui definit les parametres de seuil (duree, majorite, gradient, criteres Smith/TechComm). Si aucun protocole specifique n'est defini, le protocole par defaut du document s'applique.
Le vote permanent garantit que les textes fondateurs peuvent evoluer de maniere continue et organique, en refletant en permanence la volonte de la communaute.
## Examiner et accepter/rejeter une version
Les membres habilites (selon le protocole de vote associe) peuvent examiner les versions proposees :
@@ -106,7 +148,7 @@ Le document est en vigueur et sous **vote permanent**. Tout membre authentifie p
### Archive (archived)
Le document a ete archive dans le **Sanctuaire**. Son contenu est fige et preservee de maniere immuable via :
Le document a ete archive dans le **Sanctuaire**. Son contenu est fige et preserve de maniere immuable via :
- Un hash SHA-256 pour garantir l'integrite.
- Un stockage sur IPFS pour la distribution decentralisee.
@@ -114,6 +156,14 @@ Le document a ete archive dans le **Sanctuaire**. Son contenu est fige et preser
Un document archive ne peut plus etre modifie. Pour le consulter, rendez-vous dans la section Sanctuaire.
## Statuts des documents
| Statut | Description |
| --------- | ------------------------------------------------ |
| Brouillon | En cours de redaction, non soumis au vote |
| Actif | Document en vigueur, sous vote permanent |
| Archive | Document archive dans le Sanctuaire, plus modifiable |
## Archiver un document dans le Sanctuaire
Pour archiver un document actif (necessite une authentification) :
@@ -132,14 +182,52 @@ Pour archiver un document actif (necessite une authentification) :
L'archivage est une operation irreversible. Une fois archive, le document ne peut plus etre modifie.
::
## Statuts des documents
| Statut | Description |
| --------- | ------------------------------------------------ |
| Brouillon | En cours de redaction, non soumis au vote |
| Actif | Document en vigueur, sous vote permanent |
| Archive | Document archive dans le Sanctuaire, plus modifiable |
## Versionnage
Chaque document possede un numero de version semantique (ex: `2.0.0`). Chaque modification adoptee peut entrainer une mise a jour de version selon l'importance du changement.
## Exemple concret : modifier un article de la Licence G1
Prenons un exemple complet de bout en bout. Vous souhaitez modifier la regle de distance (item 3.1) de la Licence G1 pour preciser une condition supplementaire.
### 1. Trouver l'item
- Rendez-vous dans **Documents** et ouvrez la **Licence G1**.
- Faites defiler jusqu'a l'item **3.1 -- Distance rule** et cliquez dessus.
### 2. Consulter le texte courant
- Lisez le texte en vigueur et l'historique des versions precedentes.
- Verifiez que votre modification n'a pas deja ete proposee par quelqu'un d'autre.
### 3. Proposer votre modification
- Cliquez sur **Proposer une modification**.
- Redigez votre nouveau texte. Par exemple, ajoutez une precision sur le nombre de pas de distance autorise.
- Dans le champ **Justification**, expliquez pourquoi : "La regle actuelle ne precise pas le cas ou un membre est a la limite exacte de la distance maximale. Cette modification clarifie que la distance est inclusive."
- Soumettez votre proposition.
### 4. Le diff est genere
Le systeme genere automatiquement un diff montrant les differences :
```diff
- Le membre doit respecter la regle de distance WoT.
+ Le membre doit respecter la regle de distance WoT. La distance
+ maximale est inclusive : un membre a exactement 5 pas est conforme.
```
### 5. Examen et vote
- La communaute peut consulter votre proposition, lire votre justification et examiner le diff.
- Si un processus de decision est lance, une session de vote est creee.
- Les membres votent selon le protocole de vote associe a cet item.
### 6. Resultat
- **Si acceptee** : votre texte remplace le texte courant de l'item 3.1. Toutes les autres propositions en attente pour cet item sont automatiquement rejetees. Le numero de version du document peut etre mis a jour.
- **Si rejetee** : le texte courant reste inchange. Votre proposition est archivee avec le statut "rejetee" pour transparence.
### 7. Archivage
Si la modification est suffisamment importante, le document mis a jour peut etre archive dans le Sanctuaire, creant une trace immuable de cette evolution.