Sprint 4 : decisions et mandats -- workflow complet + vote integration
Backend: 7 nouveaux endpoints (advance, assign, revoke, create-vote-session), services enrichis avec creation de sessions de vote, assignation de mandataire et revocation. 35 nouveaux tests (104 total). Frontend: store mandates, page cadrage decisions, detail mandats, composants DecisionWorkflow, DecisionCadrage, DecisionCard, MandateTimeline, MandateCard. Documentation mise a jour. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Yvv
@@ -7,51 +7,166 @@ description: Guide des mandats sur Glibredecision
|
||||
|
||||
## Principe
|
||||
|
||||
Un mandat est une responsabilite attribuee a un membre de la communaute pour une duree determinee, apres validation par vote collectif. Les mandats permettent de formaliser les roles au sein de la gouvernance Duniter.
|
||||
Un mandat est une responsabilite attribuee a un membre de la communaute pour une duree determinee, apres validation par vote collectif. Les mandats permettent de formaliser les roles au sein de la gouvernance Duniter et d'assurer la redevabilite des mandataires.
|
||||
|
||||
## Types de mandats
|
||||
|
||||
| Type | Description |
|
||||
| --------- | ------------------------------------------------------- |
|
||||
| TechComm | Mandat de membre du Comite Technique |
|
||||
| Smith | Mandat lie au role de forgeron (Smith) |
|
||||
| Custom | Mandat personnalise pour tout autre role |
|
||||
| Type | Description | Cas d'usage |
|
||||
| ---------- | ------------------------------------------------------- | --------------------------------------------------------- |
|
||||
| `techcomm` | Mandat de membre du Comite Technique | Administration du reseau, validation des runtime upgrades |
|
||||
| `smith` | Mandat lie au role de forgeron (Smith) | Production de blocs, maintenance de la blockchain |
|
||||
| `custom` | Mandat personnalise pour tout autre role | Tresorier, secretaire, moderateur, etc. |
|
||||
|
||||
Chaque type de mandat peut avoir des criteres de vote specifiques. Par exemple, un mandat `techcomm` peut exiger un critere TechComm (`ceil(CoTecSize^T)`), tandis qu'un mandat `smith` peut exiger un critere Smith (`ceil(SmithWotSize^S)`).
|
||||
|
||||
## Cycle de vie d'un mandat
|
||||
|
||||
Un mandat progresse a travers les etapes suivantes :
|
||||
Un mandat progresse a travers les statuts suivants :
|
||||
|
||||
```
|
||||
Brouillon --> Candidature --> Vote --> Actif --> Rapport --> Termine
|
||||
--> Revoque
|
||||
| |
|
||||
+--> Rejet (si le +--> Revoque (revocation
|
||||
vote echoue) anticipee)
|
||||
```
|
||||
|
||||
| Etape | Description |
|
||||
| Statut | Description |
|
||||
| ------------ | ------------------------------------------------------------ |
|
||||
| Formulation | Definition du mandat, de ses objectifs et de sa duree |
|
||||
| Candidature | Periode de depot des candidatures |
|
||||
| Vote | Vote collectif pour designer le mandataire |
|
||||
| Assignation | Attribution du mandat au candidat elu |
|
||||
| Rapport | Periode de reporting sur l'execution du mandat |
|
||||
| Completion | Fin normale du mandat a echeance |
|
||||
| Revocation | Fin anticipee du mandat (en cas de manquement) |
|
||||
| `draft` | Brouillon initial. Le mandat est en cours de definition et peut etre modifie ou supprime. |
|
||||
| `candidacy` | Periode de depot des candidatures. Les membres interesses se declarent candidats. |
|
||||
| `voting` | Vote collectif pour designer le mandataire. Une session de vote est ouverte. |
|
||||
| `active` | Le mandat est en cours. Le mandataire exerce ses responsabilites. |
|
||||
| `reporting` | Periode de reporting. Le mandataire rend compte de ses actions. |
|
||||
| `completed` | Fin normale du mandat a echeance. Le bilan est archive. |
|
||||
| `revoked` | Fin anticipee du mandat suite a une revocation. |
|
||||
|
||||
## Consulter les mandats
|
||||
## Etapes d'un mandat (mandate_steps)
|
||||
|
||||
1. Rendez-vous dans la section **Mandats**.
|
||||
2. Filtrez par type (techcomm, smith, custom) ou statut.
|
||||
3. Chaque mandat affiche le titulaire, les dates et les etapes.
|
||||
Chaque mandat est compose d'etapes ordonnees qui definissent le processus complet. Les types d'etapes disponibles sont :
|
||||
|
||||
| Type d'etape | Description |
|
||||
| -------------- | ------------------------------------------------------------ |
|
||||
| `formulation` | Definition du mandat, de ses objectifs et de sa duree |
|
||||
| `candidacy` | Periode de depot et d'examen des candidatures |
|
||||
| `vote` | Vote collectif pour designer le mandataire |
|
||||
| `assignment` | Attribution formelle du mandat au candidat elu |
|
||||
| `reporting` | Periode de reporting sur l'execution du mandat |
|
||||
| `completion` | Fin normale du mandat a echeance |
|
||||
| `revocation` | Fin anticipee du mandat (en cas de manquement) |
|
||||
|
||||
Chaque etape possede un statut individuel :
|
||||
|
||||
| Statut | Description |
|
||||
| ----------- | ---------------------------------------------------------- |
|
||||
| `pending` | L'etape n'a pas encore commence |
|
||||
| `active` | L'etape est en cours |
|
||||
| `completed` | L'etape est terminee avec succes |
|
||||
| `skipped` | L'etape a ete ignoree (non applicable) |
|
||||
|
||||
## Comment le workflow avance
|
||||
|
||||
Le workflow d'un mandat avance via l'action **"Avancer"** (endpoint `POST /mandates/{id}/advance`). Le fonctionnement est identique a celui des decisions :
|
||||
|
||||
1. **S'il y a une etape active** : elle est marquee `completed`, et la prochaine etape `pending` est activee.
|
||||
2. **S'il n'y a pas d'etape active** : la premiere etape `pending` est activee. Si le mandat est en `draft`, il passe automatiquement en `candidacy`.
|
||||
3. **Si toutes les etapes sont terminees** : le statut global du mandat avance au statut suivant dans le cycle de vie.
|
||||
|
||||
Les statuts terminaux (`completed` et `revoked`) bloquent tout avancement ulterieur.
|
||||
|
||||
## Creer un mandat
|
||||
|
||||
Les membres authentifies peuvent proposer un nouveau mandat :
|
||||
|
||||
1. Cliquez sur **Nouveau mandat**.
|
||||
2. Renseignez le titre, la description et le type.
|
||||
3. Definissez les dates de debut et de fin.
|
||||
4. Ajoutez les etapes du processus.
|
||||
5. Le mandat passe en phase de candidature puis de vote.
|
||||
2. Renseignez le **titre** : intitule du role ou de la mission.
|
||||
3. Renseignez la **description** : objectifs, responsabilites, criteres de reussite.
|
||||
4. Choisissez le **type de mandat** : `techcomm`, `smith` ou `custom`.
|
||||
5. Optionnellement, liez le mandat a une **decision** existante de type `mandate_vote`.
|
||||
6. **Ajoutez les etapes** dans l'ordre souhaite (formulation, candidature, vote, assignation, reporting, completion).
|
||||
7. Soumettez. Le mandat est cree en statut `draft`.
|
||||
8. Utilisez l'action **"Avancer"** pour demarrer le processus.
|
||||
|
||||
## Candidatures
|
||||
|
||||
Pendant la phase de candidature (`candidacy`), les membres de la communaute peuvent se declarer candidats. La page du mandat affiche la liste des candidats avec leur profil Duniter (adresse SS58, statut WoT, statut Smith/TechComm).
|
||||
|
||||
## Vote pour un mandat
|
||||
|
||||
Quand l'etape de type `vote` est active, une session de vote doit etre creee via l'action **"Creer une session de vote"** (endpoint `POST /mandates/{id}/steps/{step_id}/create-vote-session`).
|
||||
|
||||
La session de vote fonctionne exactement comme pour les decisions :
|
||||
- Snapshot des tailles WoT, Smith, TechComm
|
||||
- Application de la formule de seuil avec inertie
|
||||
- Criteres supplementaires Smith/TechComm selon le protocole choisi
|
||||
- Cloture automatique ou manuelle
|
||||
|
||||
Le resultat du vote determine si le mandat est attribue au candidat elu.
|
||||
|
||||
## Assignation du mandataire
|
||||
|
||||
Apres un vote reussi, le mandataire est assigne au mandat via l'action **"Assigner"** (endpoint `POST /mandates/{id}/assign`). Cette action :
|
||||
|
||||
- Definit le `mandatee_id` : l'identite Duniter du membre elu
|
||||
- Definit les dates de debut et de fin du mandat
|
||||
- Fait passer le mandat en statut `active`
|
||||
|
||||
Le corps de la requete contient l'identifiant de l'identite Duniter du mandataire :
|
||||
|
||||
```json
|
||||
{
|
||||
"mandatee_id": "uuid-de-l-identite-duniter"
|
||||
}
|
||||
```
|
||||
|
||||
## Reporting et redevabilite
|
||||
|
||||
Pendant la phase active du mandat, le mandataire est tenu de rendre compte de ses actions. Quand l'etape de `reporting` est active :
|
||||
|
||||
- Le mandataire peut publier des comptes-rendus via le champ `outcome` de l'etape
|
||||
- Les membres de la communaute peuvent consulter les rapports
|
||||
- Le bilan est archive dans le sanctuaire a la fin du mandat
|
||||
|
||||
## Revocation
|
||||
|
||||
Un mandat actif peut etre revoque de maniere anticipee via l'action **"Revoquer"** (endpoint `POST /mandates/{id}/revoke`). La revocation :
|
||||
|
||||
- Passe le statut du mandat a `revoked`
|
||||
- Met fin immediatement aux responsabilites du mandataire
|
||||
- Archive le motif de revocation
|
||||
|
||||
La revocation est une action de gouvernance qui peut necessiter un vote prealable (decision de type `mandate_vote` avec motif de revocation).
|
||||
|
||||
## Suppression
|
||||
|
||||
Seuls les mandats au statut "brouillon" peuvent etre supprimes. Une fois le processus de candidature lance, le mandat reste dans le systeme pour tracabilite.
|
||||
Seuls les mandats au statut `draft` peuvent etre supprimes via l'action **"Supprimer"** (endpoint `DELETE /mandates/{id}`). Une fois le processus de candidature lance, le mandat reste dans le systeme pour tracabilite.
|
||||
|
||||
## Consulter les mandats
|
||||
|
||||
1. Rendez-vous dans la section **Mandats**.
|
||||
2. Filtrez par type (`techcomm`, `smith`, `custom`) ou par statut.
|
||||
3. Chaque mandat affiche le titulaire, les dates, les etapes et leur statut.
|
||||
4. La page de detail montre le workflow complet avec l'historique des etapes.
|
||||
|
||||
## Exemple : Election d'un membre du Comite Technique
|
||||
|
||||
```
|
||||
1. Formulation -> Definition du poste : responsabilites, duree (1 an), competences requises
|
||||
2. Candidature -> Les membres Smith se declarent candidats pendant 14 jours
|
||||
3. Vote -> Vote WoT avec critere TechComm obligatoire, duree 30 jours
|
||||
4. Assignation -> Attribution du mandat au candidat elu
|
||||
5. Reporting -> Rapport d'activite trimestriel
|
||||
6. Completion -> Fin du mandat apres 1 an, bilan final archive
|
||||
```
|
||||
|
||||
**Deroulement concret :**
|
||||
|
||||
1. Un membre cree un mandat de type `techcomm` avec la description du poste.
|
||||
2. Il ajoute les 6 etapes dans l'ordre.
|
||||
3. Il avance le mandat : l'etape "Formulation" est activee, puis completee.
|
||||
4. Il avance : la phase de candidature s'ouvre. Les candidats se declarent.
|
||||
5. Il avance : l'etape "Vote" est activee. Une session de vote est creee.
|
||||
6. Les membres votent. Le seuil WoT et le critere TechComm doivent etre atteints.
|
||||
7. Si adopte, il avance : l'etape "Assignation" est activee. Le mandataire est designe via l'action "Assigner".
|
||||
8. Il avance : le mandat passe en phase active. Le mandataire exerce ses fonctions.
|
||||
9. A l'echeance, l'etape "Reporting" est activee pour le bilan.
|
||||
10. Il avance une derniere fois : le mandat passe en statut `completed`.
|
||||
|
||||
Reference in New Issue
Block a user