@imenam/mcp-organizer 0.0.0-stage → 1.0.2

package/README.md

@@ -1,3 +1,548 @@
-# Temporary Holding Version
-
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+# mcp-organizer
+
+Gestionnaire de tâches multi-utilisateur piloté par un agent. Les membres organisent leurs tâches dans des espaces personnels et communs, sur un site web ; les demandes qu'ils adressent à l'IA (idées, remarques, reviews de test, messages) sont déposées dans une file d'attente qu'un agent, connecté en MCP avec un jeton, traite quand on le lui demande. Chacune de ses actions est journalisée et annulable.
+
+Le serveur n'appelle aucun modèle de langage : l'intelligence vient de l'agent connecté.
+
+Un seul paquet, deux modes :
+
+| Commande | Mode |
+|---|---|
+| `mcp-organizer --server` | **Site** : processus web permanent, derrière un reverse proxy (nginx). Il détient la base, sert l'interface, son API et l'API des agents (`/api/agent/*`). |
+| `mcp-organizer` | **MCP** (stdio) : serveur MCP de l'agent, sans base ni logique métier. Configuré par `ORGANIZER_URL` et `ORGANIZER_TOKEN`, il relaie chaque appel d'outil à l'API des agents du site. Il peut tourner sur n'importe quelle machine, notamment dans une gateway de mcp-gateway-manager. |
+
+Autres commandes : `--setup` (installation du site : `.env`, unité systemd, bloc nginx, premier compte), `--set-user` (compte), `--backup` (sauvegarde de la base et des pièces jointes), `--claude-setup-mcp` (entrée `.mcp.json` du mode MCP), `--watch` (veilleur de notifications de l'agent, lancé par son outil `Monitor`), `--version`, `--help`. Chaque mode et chaque commande chargent leur code à la demande.
+
+Prérequis : Node.js 20 ou plus récent.
+
+## Installer le site
+
+Le site s'installe par clonage du dépôt, sur la machine qui l'héberge (Linux avec systemd et nginx pour un site exposé) :
+
+```bash
+git clone <dépôt> /opt/mcp-organizer && cd /opt/mcp-organizer
+npm ci
+npm run build
+npm run setup
+```
+
+Les scripts `npm run setup`, `npm run server`, `npm run set-user` et `npm run backup` lancent `node dist/src/index.js` avec l'option du même nom ; leurs arguments se passent après `--` (`npm run setup -- --help`).
+
+`--setup` pose les questions, refuse une réponse invalide en disant pourquoi, puis :
+
+1. écrit le fichier `.env` du site (`<package>/.env`, ou le fichier de `--dotenv=<chemin>`), avec les droits 600 sous Linux ;
+2. écrit dans le dossier de sortie (`<package>/deploy`, ou `--output-dir=<chemin>`) l'unité systemd `mcp-organizer.service` et le bloc nginx `mcp-organizer.nginx.conf`, remplis avec les réponses ;
+3. crée le premier compte (voir « Premier compte ») ;
+4. affiche les commandes qui restent à lancer en root.
+
+Il n'écrit aucun fichier système : copier l'unité et le bloc, recharger systemd et nginx restent des gestes de l'administrateur.
+
+| Question | Option | Défaut |
+|---|---|---|
+| URL publique | `--public-url=<url>` | aucun. En `https://` ; `http://` n'est admis que pour un essai local (`localhost`, `127.0.0.1`). Son chemin éventuel devient `ORGANIZER_BASE_PATH`. |
+| Port d'écoute | `--port=<n>` | aucun (4800 proposé) |
+| Adresse d'écoute | `--host=<adresse>` | `127.0.0.1` |
+| Adresse du client lue dans `X-Forwarded-For` | `--trust-proxy=oui\|non` | aucun (oui proposé : nginx écrit l'en-tête). Refusé avec une adresse d'écoute hors de la boucle locale (voir « Sécurité »). |
+| Répertoire de données | `--data-dir=<chemin>` | `<package>/.organizer-data` ; écrit en chemin absolu |
+| Clé Groq (dictée) | `ORGANIZER_SETUP_GROQ_API_KEY`, ou `--no-groq` | dictée désactivée. Avec une clé, le setup écrit `ORGANIZER_TRANSCRIBE_MODEL=whisper-large-v3-turbo`. |
+| URL SMTP | `ORGANIZER_SETUP_SMTP_URL`, ou `--no-smtp` | e-mail désactivé |
+| Expéditeur des e-mails | `--mail-from=<adresse>` | aucun, requis avec SMTP |
+| Premier compte | `--admin-email=<adresse>`, `--admin-name=<nom>`, `ORGANIZER_SETUP_ADMIN_PASSWORD` | requis tant qu'aucun compte n'existe |
+
+Options de l'unité systemd : `--install-dir=<chemin>` (racine du dépôt, par défaut celle où tourne le setup), `--service-user=<compte>` (par défaut `mcp-organizer`), `--node=<chemin>` (par défaut le Node qui exécute le setup). `npm run setup -- --help` les liste toutes.
+
+**Mode non interactif** : avec `--non-interactive`, ou quand l'entrée n'est pas un terminal, rien n'est demandé. Chaque valeur vient de son option, ou de la variable `ORGANIZER_SETUP_<NOM>` correspondante (`--public-url` → `ORGANIZER_SETUP_PUBLIC_URL`), sinon du `.env` existant, sinon du défaut du tableau ; une valeur requise absente arrête le setup en la nommant. Les secrets (clé Groq, URL SMTP, mot de passe) ne se passent jamais en argument : saisis sans écho en mode interactif, ils viennent sinon de `ORGANIZER_SETUP_GROQ_API_KEY`, `ORGANIZER_SETUP_SMTP_URL` et `ORGANIZER_SETUP_ADMIN_PASSWORD`. Une option de secret (`--admin-password=…`, `--groq-api-key=…`, `--smtp-url=…`) est refusée.
+
+```bash
+ORGANIZER_SETUP_ADMIN_PASSWORD='…' ORGANIZER_SETUP_SMTP_URL='smtps://…' \
+npm run setup -- --non-interactive \
+  --public-url=https://organizer.example.com --port=4800 --trust-proxy=oui \
+  --data-dir=/var/lib/mcp-organizer --no-groq --mail-from='Organizer <organizer@example.com>' \
+  --admin-email=admin@example.com --admin-name='Prénom Nom'
+```
+
+Le setup refuse, sans rien écrire, une option inconnue ou répétée, une valeur invalide, et les combinaisons incohérentes : `--trust-proxy=oui` avec une adresse d'écoute qui n'est pas la boucle locale (`localhost`, `127.x.x.x`, `::1`), `--no-groq` avec une clé Groq, `--no-smtp` avec `--mail-from`, `--mail-from` sans serveur SMTP, `--admin-name` ou un mot de passe sans compte désigné alors que des comptes existent. Il fait relire la configuration obtenue par la validation du site avant d'écrire.
+
+**Relancer le setup** reconfigure une installation : les valeurs du `.env` existant sont proposées par défaut (et conservées en mode non interactif ; Entrée conserve un secret, « - » le retire). Le fichier est fusionné : commentaires et variables que le setup ne gère pas restent tels quels, chaque variable gérée est réécrite à sa place, et `ORGANIZER_ADMIN_EMAIL` / `ORGANIZER_ADMIN_NAME` / `ORGANIZER_ADMIN_PASSWORD` sont retirées (le compte vit en base). Quand des comptes existent, le compte est facultatif.
+
+**Fichiers produits** :
+
+- `mcp-organizer.service` : `node <dépôt>/dist/src/index.js --server --dotenv=<.env>`, sous le compte dédié, redémarrage sur échec, durcissement (`NoNewPrivileges`, `ProtectSystem=strict` avec écriture limitée au répertoire de données, `ProtectHome=read-only`, `PrivateTmp`, `PrivateDevices`, aucune capacité sauf `CAP_NET_BIND_SERVICE` pour un port inférieur à 1024, familles d'adresses limitées), journaux dans journald.
+- `mcp-organizer.nginx.conf` : redirection du port 80 vers HTTPS, `listen 443 ssl http2` (et `[::]:443`) avec les chemins de certificat Let's Encrypt, `Strict-Transport-Security`, proxy vers `HOST:PORT` (la boucle locale quand le site écoute sur toutes les interfaces) avec `Host`, `X-Real-IP`, `X-Forwarded-For`, `X-Forwarded-Proto` et `X-Forwarded-Host`, `client_max_body_size 26m` (pièces jointes de 20 Mo et dictée de 25 Mo, enveloppe du formulaire comprise, comme la limite du site), `/api/` jamais mis en cache (`Cache-Control: no-store`). Publié sous un chemin (`https://exemple.com/organizer`), le bloc retire le préfixe avant de joindre le site et redirige `/organizer` vers `/organizer/`.
+
+**Version de nginx** : 1.9.5 au minimum. Le bloc active HTTP/2 par `listen … ssl http2`, compris par toutes ces versions, dont celles de Debian 12 (1.22) et d'Ubuntu 24.04 (1.24). À partir de nginx 1.25.1, `nginx -t` signale cette forme comme dépréciée (simple avertissement) ; la directive `http2 on;` qui la remplace n'existe pas avant 1.25.1.
+
+**Étapes suivantes**, affichées par le setup avec les chemins de l'installation :
+
+```bash
+useradd --system --no-create-home --shell /usr/sbin/nologin mcp-organizer
+chown -R mcp-organizer:mcp-organizer /var/lib/mcp-organizer
+chown root:mcp-organizer /opt/mcp-organizer/.env && chmod 640 /opt/mcp-organizer/.env
+cp deploy/mcp-organizer.service /etc/systemd/system/
+systemctl daemon-reload && systemctl enable --now mcp-organizer
+certbot certonly --nginx -d organizer.example.com
+cp deploy/mcp-organizer.nginx.conf /etc/nginx/sites-available/mcp-organizer
+ln -s /etc/nginx/sites-available/mcp-organizer /etc/nginx/sites-enabled/mcp-organizer
+nginx -t && systemctl reload nginx
+```
+
+**Lancement à la main** (essai local, ou sans systemd) : le site écoute sur `HOST:PORT` et sert l'interface (`gui/dist`) et l'API (`/api/*`) dans un seul processus Hono. Il s'arrête proprement sur `SIGINT` / `SIGTERM`.
+
+```bash
+npm run server                                # lit <package>/.env
+npm run server -- --dotenv=/etc/mcp-organizer.env
+```
+
+Il refuse de démarrer, avec un message qui dit quoi corriger, quand `PORT` ou `ORGANIZER_PUBLIC_URL` manque ou est invalide, quand `ORGANIZER_BASE_PATH` ne correspond pas au chemin de l'URL publique, quand `ORGANIZER_TRUST_PROXY` vaut autre chose que `1`, quand le port est déjà pris, ou quand le premier compte demandé par `ORGANIZER_ADMIN_*` est incomplet.
+
+## Premier compte
+
+Les comptes se créent sur invitation uniquement : il n'y a pas d'inscription libre. Le premier compte se crée de l'une de trois façons :
+
+- **Setup** : `--setup` le crée à l'installation, avec le même code que `--set-user`. L'adresse vient de `--admin-email`, le nom de `--admin-name`, le mot de passe d'une saisie sans écho avec confirmation, ou de `ORGANIZER_SETUP_ADMIN_PASSWORD` en mode non interactif. Tant qu'aucun compte n'existe, ce compte est requis ; ensuite, il est facultatif, et une adresse existante voit son mot de passe remplacé. Le mot de passe n'est écrit dans aucun fichier.
+- **Commande** :
+
+  ```bash
+  npm run set-user -- [email] [--name="Prénom Nom"]
+  ```
+
+  Crée un compte actif avec son espace personnel, ou remplace le mot de passe d'un compte existant, qui redevient actif (ses sessions ouvertes sont fermées) ; les invitations d'un compte encore invité restent en attente dans ses « Invitations reçues ». Le mot de passe est saisi sans écho, avec confirmation, et ne se passe jamais en argument. L'adresse vient de l'argument, sinon de `ORGANIZER_ADMIN_EMAIL`, sinon d'une question. Le nom affiché vient de `--name`, sinon de `ORGANIZER_ADMIN_NAME`, sinon d'une question ; il est obligatoire pour créer un compte, et facultatif pour un compte qui en a déjà un (il le remplace). En mode non interactif (`--non-interactive`, ou entrée qui n'est pas un terminal), le mot de passe vient de `ORGANIZER_ADMIN_PASSWORD`, et une adresse ou un nom manquant fait échouer la commande avec la marche à suivre. La commande lit le même `.env` que le site (`--dotenv` compris) et écrit dans son répertoire de données.
+- **Variables d'environnement** : au démarrage du site, si la table des comptes est vide et que `ORGANIZER_ADMIN_EMAIL` et `ORGANIZER_ADMIN_PASSWORD` sont définies, le compte est créé (actif, avec son espace personnel) avec le nom `ORGANIZER_ADMIN_NAME`. Sans ce nom, le site refuse de démarrer et dit quelle variable définir : aucun nom n'est déduit de l'adresse. Les variables peuvent ensuite être retirées : le compte vit en base.
+
+Tant qu'aucun compte n'existe, le site refuse toute connexion et indique comment en créer un : la commande d'une installation par clonage (`node dist/src/index.js --set-user <email> --name="Prénom Nom"`, dans le dossier du site), celle du paquet npm (`npx -y @imenam/mcp-organizer --set-user …`, qui exige les modules natifs construits, voir « Via une gateway de mcp-gateway-manager ») et les variables `ORGANIZER_ADMIN_*`. Chaque utilisateur change ensuite son nom affiché et son mot de passe dans les Paramètres.
+
+## Connecter un agent (mode MCP)
+
+Un agent se connecte au site avec un **jeton d'agent** (voir « Jetons d'agent ») : un utilisateur le crée dans Paramètres > Agents, pour un espace dont il est membre. L'agent voit alors les demandes de tous les membres de cet espace et agit avec les droits du créateur du jeton.
+
+Le mode MCP est un serveur stdio léger : il n'ouvre aucune base, ne charge aucun module natif (`better-sqlite3`, `argon2`) et n'a aucune logique métier. Chaque outil est un appel HTTPS à l'API des agents du site, avec le jeton dans `Authorization: Bearer`. Une instance correspond à un jeton, donc à un utilisateur et un espace.
+
+| Variable | Rôle |
+|---|---|
+| `ORGANIZER_URL` | URL publique du site (`ORGANIZER_PUBLIC_URL` du site), par exemple `https://organizer.example.com`. **Obligatoire.** |
+| `ORGANIZER_TOKEN` | Jeton d'agent `org_…`. **Obligatoire.** |
+| `MCP_LOG_DIR` | Facultatif : répertoire où écrire `server.log` en plus de stderr. |
+
+Le mode MCP tient sa configuration de son seul environnement, fourni par l'agent (bloc `env` de `.mcp.json`) ou par la gateway : il ne lit aucun fichier `.env`, pas même celui du paquet, sauf celui que désigne explicitement `--dotenv=<fichier>`.
+
+Sans `ORGANIZER_URL` ou `ORGANIZER_TOKEN`, ou avec une URL invalide, le mode MCP refuse de démarrer et dit quoi renseigner. `ORGANIZER_URL` doit être en `https://` ; `http://` n'est admis que pour un site de la machine locale (`localhost`, `127.0.0.1`, `::1`), le jeton circulant sinon en clair. Le mode MCP ne suit jamais une redirection : si le site en répond une, l'outil échoue en nommant l'adresse visée (« … answered with a redirect (HTTP 301) to … Use the final https URL of the site … ») sans y envoyer le jeton ; indiquez alors l'URL finale du site, son `ORGANIZER_PUBLIC_URL`. Un refus du site (jeton absent, inconnu, révoqué ou expiré, propriétaire qui n'est plus membre, demande hors de l'espace…) et un site injoignable reviennent à l'agent comme une erreur d'outil (`isError: true`) avec un message utile.
+
+### Directement, dans un projet
+
+À la création d'un jeton, la GUI affiche l'entrée `.mcp.json` à copier. La commande suivante l'écrit aussi, dans le dossier du projet où l'agent travaille :
+
+```bash
+npx -y @imenam/mcp-organizer --claude-setup-mcp [--force] --url=https://organizer.example.com --token=org_…
+```
+
+Elle écrit l'entrée `mcp-organizer` de `<dossier>/.mcp.json`, ou l'ajoute à un fichier existant en conservant les autres serveurs. Elle échoue sans rien écrire quand une option est inconnue, quand `--url` ou `--token` manque ou est invalide (URL http(s) sans paramètres ; jeton commençant par `org_`), quand `.mcp.json` est illisible, n'est pas du JSON, n'est pas un objet ou a un `mcpServers` qui n'est pas un objet, ou quand l'entrée existe déjà sans `--force`.
+
+```json
+{
+  "mcpServers": {
+    "mcp-organizer": {
+      "command": "npx",
+      "args": ["-y", "@imenam/mcp-organizer"],
+      "env": {
+        "ORGANIZER_URL": "https://organizer.example.com",
+        "ORGANIZER_TOKEN": "org_…"
+      }
+    }
+  }
+}
+```
+
+Le jeton est un secret : `.mcp.json` ne se partage pas et ne se versionne pas. Il se révoque depuis Paramètres > Agents.
+
+### Via une gateway de mcp-gateway-manager
+
+Dans une gateway, déclarez un serveur MCP stdio de commande `npx`, d'arguments `-y @imenam/mcp-organizer`, avec `ORGANIZER_URL` et `ORGANIZER_TOKEN` dans son environnement, le jeton en variable secrète. Dans l'éditeur JSON d'une gateway du dashboard :
+
+```json
+{
+  "mcpServers": {
+    "organizer-refonte": {
+      "command": "npx",
+      "args": ["-y", "@imenam/mcp-organizer"],
+      "route": "/organizer-refonte",
+      "env": {
+        "ORGANIZER_URL": "https://organizer.example.com",
+        "ORGANIZER_TOKEN": { "secret": true, "value": "org_…" }
+      }
+    }
+  }
+}
+```
+
+Dans le `mcp-servers.json` d'une gateway `mcp-http-gateway` lancée seule, la route s'écrit `"MCP_SERVER_ROUTE": "/organizer-refonte"` dans `env`, et le jeton en clair. Les outils sont alors appelés en `POST /organizer-refonte/tools/<outil>` (corps JSON : les arguments de l'outil), ou par le relais `mcp-http-gateway --mcp` (`call_tool` avec `route`, `tool_name` et `arguments`) ; les erreurs du site reviennent telles quelles, avec `isError: true`.
+
+- **Un jeton par déclaration** : chaque déclaration correspond à un jeton, donc à un espace. Pour exposer plusieurs espaces, déclarez une instance par jeton, chacune sous sa route.
+- **Modules natifs** : `npx` (comme `npm install`) installe tout le paquet, y compris `better-sqlite3` et `argon2`, qui ne servent qu'au site. npm 12 bloque leurs scripts d'installation (avertissement `install-scripts … not covered by allowScripts`), car le champ `allowScripts` du paquet ne vaut que pour l'installation par clonage. Le mode MCP ne charge jamais ces modules : il fonctionne sans rien approuver. Le site, lui, s'installe par clonage (voir « Installer le site »). Lancés depuis une installation npm dont les scripts ont été bloqués, `--server`, `--set-user`, `--setup` et `--backup` s'arrêtent avant toute écriture avec un message qui l'explique (« better-sqlite3 n'a pas de module natif compilé ») et donne les deux issues : installer par clonage, ou lancer `npm install-scripts approve better-sqlite3` puis `npm rebuild better-sqlite3` dans cette installation.
+- **Instructions** : la gateway relaie les outils mais pas le champ `instructions` du serveur. Les descriptions des outils et le résultat de `claim_request`, qui rappelle comment traiter chaque type de demande, suffisent à l'agent pour suivre la boucle (voir « Boucle de travail de l'agent »).
+
+### Les outils
+
+Les outils MCP sont destinés à l'agent ; leurs schémas JSON sont écrits à la main et leurs descriptions disent quand les utiliser. Ils travaillent tous sur l'espace du jeton. Les outils d'écriture exigent `request_id`, une demande `processing` prise par ce même jeton. Une tâche se désigne par sa clé (`ORG-41`) ou son identifiant, un membre par son identifiant ou son adresse e-mail.
+
+| Outil | Route de l'API des agents | Rôle |
+|---|---|---|
+| `list_requests` | `GET requests` | Demandes de l'espace par statut (`pending` par défaut, ou `all`) : en attente de la plus ancienne à la plus récente, les autres statuts de la plus récente à la plus ancienne ; avec auteur, type, tâche de contexte et, en cours, si ce jeton les a prises |
+| `claim_request` | `POST requests/:id/claim` | Prend une demande pour ce jeton (atomique) et renvoie son contexte : texte, auteur, tâche ou idée de contexte (et, pour une review, les résultats du testeur point par point), arbre de l'espace, membres, idées récentes |
+| `get_context` | `GET context` | Espace du jeton : nom, préfixe, membres, arbre des tâches, idées récentes |
+| `get_task` | `GET tasks/:ref` | Détail d'une tâche : champs, parents, assignés, tags, description, checklist ou points de vérification (avec leurs identifiants), sous-tâches, commentaires récents, pièces jointes |
+| `search_tasks` | `GET tasks?query=…` | Recherche par mots (titre, description, clé) et filtres (statut, priorité, type, assigné) |
+| `create_task` | `POST tasks` | Tâche, sous-tâche ou sous-sous-tâche (`parent`), standard ou test |
+| `update_task` | `PATCH tasks/:ref` | Titre, description, statut, priorité, type, parent, position dans la colonne (`after_task`), tâche vérifiée par un test (`tested_task_id`, clé ou identifiant ; `null` la retire) |
+| `set_assignees` | `PUT tasks/:ref/assignees` | Remplace les assignés (testeurs d'un test) ; les nouveaux assignés sont notifiés |
+| `set_tags` | `PUT tasks/:ref/tags` | Remplace les tags (créés au besoin) |
+| `edit_checklist` | `POST tasks/:ref/checklist` | Ajoute, renomme, coche ou supprime des éléments de checklist ; ajoute, renomme ou supprime des points de vérification d'un test (tout ou rien) |
+| `add_comment` | `POST tasks/:ref/comments` | Commentaire de l'agent ; assignés et commentateurs précédents notifiés |
+| `create_idea` / `update_idea` | `POST ideas`, `PATCH ideas/:id` | Idée dans la boîte à idées ; reformulation, archivage |
+| `promote_idea` | `POST ideas/:id/promote` | Crée une tâche à partir d'une idée et marque l'idée promue |
+| `complete_request` | `POST requests/:id/complete` | Termine la demande avec la réponse à l'auteur |
+| `fail_request` | `POST requests/:id/fail` | Termine la demande en échec avec la raison |
+| `enable_notifications` | `GET notifications` | Exécuté par le mode MCP lui-même : dépose le relais du veilleur et rend l'appel `Monitor` à faire (voir « Notifications de l'agent ») |
+
+Chaque écriture enregistre une action dans le lot de la demande (avec le jeton), crée une version de l'entité (avec le jeton), alimente le journal des changements et les notifications. Une erreur dit à l'agent quoi faire ensuite (« call claim_request on it first », « Call search_tasks to find it »…).
+
+### Boucle de travail de l'agent
+
+L'agent traite la file quand l'utilisateur le lui demande, ou quand son veilleur lui annonce une demande (voir « Notifications de l'agent ») ; les `instructions` du serveur présentent les concepts (espace, tâche, demande, lot, portée), les notifications et la boucle :
+
+1. `list_requests` ;
+2. `claim_request` sur la plus ancienne (`get_context` montre l'espace à tout moment) ;
+3. lectures avec `get_task` et `search_tasks` ;
+4. actions avec les outils d'écriture, en passant toujours le `request_id` ;
+5. `complete_request` avec une réponse courte dans la langue de l'auteur (ou `fail_request`), puis retour à l'étape 1 jusqu'à ce que la file soit vide.
+
+Règles de traitement rappelées à l'agent : une **idée** se rattache à une tâche ou sous-tâche existante (sous-tâche, élément de checklist, commentaire), devient une nouvelle tâche si elle est actionnable et assez prioritaire, ou va dans la boîte à idées ; une **review de test** se réinjecte dans les tâches existantes (statut, checklist, commentaires, priorités) ou donne une tâche par problème ; une **remarque** ou un **message** appelle toute action utile ; une **promotion d'idée** se fait avec `promote_idea`.
+
+**Portée** : une demande vise l'espace où elle est écrite (l'espace ouvert dans l'interface) ; une review de test vise donc l'espace de sa tâche, une promotion d'idée l'espace de l'idée. Un jeton couvre un espace : son agent voit et traite les demandes de tous les membres de cet espace, avec les droits du propriétaire du jeton, et seulement là. Une demande prise par un jeton n'est traitée que par lui ; si l'agent s'arrête en cours de route, un membre la « Libère » depuis l'interface. Le jeton est revérifié à chaque appel ; quand son propriétaire quitte l'espace ou en est retiré, ses jetons sur cet espace sont révoqués et refusés dès l'appel suivant.
+
+### Notifications de l'agent
+
+L'agent peut être prévenu en temps réel des demandes qui passent en attente, sur le modèle de mcp-messenger. Le site ne pousse rien : un veilleur, sur la machine de l'agent, l'interroge en attente longue, et chaque ligne qu'il écrit réveille l'agent.
+
+1. En début de session, l'agent appelle `enable_notifications`. Le mode MCP lit sur le site le jeton, son espace, le nombre de demandes en attente et l'état du veilleur (`GET notifications`), écrit le **relais** puis rend l'appel `Monitor` exact : commande `npx -y @imenam/mcp-organizer --watch <id du jeton>`, `timeout_ms` 1 800 000.
+2. L'agent lance cette commande avec `Monitor`. Le veilleur est un processus du shell de la session, pas un enfant du mode MCP : il ne reçoit pas le bloc `env` du `.mcp.json`. L'identifiant du jeton, passé en argument, est public (ce n'est pas sa valeur) : il sert seulement à retrouver le relais.
+3. Le **relais** est un fichier `~/.mcp-organizer/watch/<sha256(id du jeton)>.json` en 0600, qui porte l'URL du site et le jeton ; la valeur du jeton n'apparaît donc jamais dans la conversation. Il est écrit par `enable_notifications`, jamais au démarrage, et supprimé à l'arrêt du mode MCP qui l'a écrit en dernier ; un relais de plus de 7 jours est purgé. `ORGANIZER_STATE_DIR` déplace le répertoire (`<ORGANIZER_STATE_DIR>/watch`), pour les tests. Sans relais, le veilleur refuse de démarrer et dit d'appeler `enable_notifications`.
+4. Le veilleur appelle `GET requests/wait?watcher=true` en boucle : chaque appel reste ouvert jusqu'à 50 s et répond dès qu'une demande de l'espace passe en attente (création, ou libération par un membre). Le curseur rendu, repassé en `since`, rattrape les demandes arrivées entre deux appels. Une panne réseau ou du site est réessayée avec un délai de 1 s à 30 s.
+5. Pour chaque demande, une ligne sur stdout : `[organizer] idea · Bob Martin — "Un mode sombre" · ORG-4 (<id de la demande>)` (type, auteur, extrait, tâche de contexte, identifiant). L'agent se réveille et la traite par la boucle de travail, en commençant par `claim_request`. Les demandes déjà en attente quand le veilleur démarre ne sont pas annoncées : `enable_notifications` en donne le nombre, `list_requests` les liste.
+6. Un refus du site (jeton révoqué, expiré, propriétaire retiré…) arrête le veilleur après une dernière ligne `[organizer] notifications stopped: <raison>`.
+
+L'hôte arrête un `Monitor` au bout de 30 minutes au plus : l'agent relance alors le même appel `Monitor`, sans rappeler `enable_notifications`.
+
+**Présence** : le site tient en mémoire, par jeton, les attentes en cours de son veilleur, avec un délai de grâce de 2 minutes entre deux attentes. `enable_notifications` répond « already live » quand un veilleur est déjà armé (en armer un second doublerait chaque notification), et la page Agent de l'interface affiche « à l'écoute » à côté du jeton.
+
+### API des agents
+
+`/api/agent/*` sert le mode MCP ; n'importe quel client HTTP peut l'appeler avec un jeton.
+
+- **Authentification** : `Authorization: Bearer org_…`, revérifiée à chaque requête (jeton non révoqué, non expiré, propriétaire actif et toujours membre de l'espace) ; le dernier usage du jeton est mis à jour. Les cookies sont ignorés et le contrôle d'origine des modifications ne s'applique pas : sans cookie, une page tierce ne peut rien faire au nom d'un utilisateur.
+- **Codes** : 401 pour un jeton absent, inconnu, révoqué (y compris au départ de son propriétaire) ou expiré (avec `WWW-Authenticate: Bearer`) ; 403 pour un propriétaire inactif ou qui n'est plus membre, une tâche ou une idée d'un autre espace, ou une demande prise par un autre jeton ; 404 pour une demande, une tâche ou une route inconnue ; 409 pour un état qui interdit l'action (demande en attente ou close) ; 400 pour des paramètres invalides ; 500 pour une erreur interne, avec un message générique et une référence (voir « Sécurité »). Le corps d'une erreur est `{ "error": "<message qui dit quoi faire>" }`.
+- **Réponses** : `{ "text": "…", "data": { … } }`. `text` est le résultat rédigé pour l'agent (celui que renvoie l'outil) ; `data` porte les mêmes informations structurées, validées par les schémas zod de `shared/schemas/agent-tools.schema.ts`, partagés par le site et le mode MCP.
+- **Attente longue** : `GET requests/wait?timeout_seconds=<1-50>&since=<curseur>&watcher=true` rend les demandes de l'espace passées en attente depuis `since`, sinon attend la prochaine, au plus `timeout_seconds` (30 par défaut) ; `data` porte les demandes, le curseur suivant et `timedOut`. `watcher=true` compte l'attente dans la présence du veilleur du jeton. `GET notifications` donne le jeton, son espace, le nombre de demandes en attente et l'état du veilleur.
+- **Paramètres** : les noms des arguments des outils (`request_id`, `after_task`…) ; dans le chemin pour la tâche (`:ref`), l'idée et la demande, dans la requête pour un `GET`, dans le corps JSON sinon.
+
+## Configuration
+
+Le setup écrit cette configuration ; elle se modifie aussi à la main. Le site et ses commandes (`--set-user`, `--backup`) lisent au démarrage le fichier `<package>/.env` s'il existe, dont les valeurs priment sur l'environnement du processus. L'option `--dotenv=<chemin>` désigne un autre fichier, qui doit alors exister ; les tests l'utilisent pour ne jamais lire la configuration du développeur. Une variable vide est traitée comme absente. Le mode MCP, lui, ne lit pas `<package>/.env` (voir « Connecter un agent »).
+
+| Variable | Rôle |
+|---|---|
+| `PORT` | Port d'écoute. **Obligatoire.** |
+| `HOST` | Adresse d'écoute. Par défaut `127.0.0.1` : le site n'est joignable que par le reverse proxy de la machine. |
+| `ORGANIZER_PUBLIC_URL` | URL que les utilisateurs ouvrent, par exemple `https://organizer.example.com`. **Obligatoire.** Son origine est la seule admise pour une modification ; en `https://`, le cookie de session porte `Secure` ; elle sert de base aux liens des e-mails. |
+| `ORGANIZER_BASE_PATH` | Chemin sous lequel le reverse proxy publie le site, par exemple `/organizer` (le proxy retire ce préfixe). Il fixe le `<base href>` de l'interface et le `Path` du cookie, et doit être le chemin de `ORGANIZER_PUBLIC_URL`. Sans lui, le site est publié à la racine. |
+| `ORGANIZER_TRUST_PROXY` | `1` : l'adresse du client est la dernière entrée de `X-Forwarded-For`, écrite par le reverse proxy. Vide : l'en-tête est ignoré et l'adresse est celle de la connexion. Seulement avec un `HOST` de la boucle locale (voir « Sécurité »). |
+| `MCP_ORGANIZER_DATA_DIR` | Répertoire de données ; à défaut `MCP_DATA_DIR`, puis `<package>/.organizer-data`. Il contient `organizer.db`, `attachments/` et `logs/`. |
+| `MCP_LOG_DIR` | Répertoire des journaux ; à défaut `<données>/logs`. Les journaux vont aussi sur stderr. |
+| `GROQ_API_KEY` | Clé de l'API Groq, pour la dictée vocale. |
+| `ORGANIZER_TRANSCRIBE_MODEL` | Modèle de transcription Groq (`whisper-large-v3-turbo`). |
+| `SMTP_URL` | Serveur d'envoi des e-mails : `smtp://utilisateur:motdepasse@hote:587` ou `smtps://…`. |
+| `MAIL_FROM` | Expéditeur des e-mails, par exemple `Organizer <organizer@example.com>`. |
+| `ORGANIZER_ADMIN_EMAIL`, `ORGANIZER_ADMIN_NAME`, `ORGANIZER_ADMIN_PASSWORD` | Premier compte, créé au démarrage si aucun compte n'existe (voir « Premier compte »). |
+
+Exemple de `.env` :
+
+```ini
+PORT=4800
+ORGANIZER_PUBLIC_URL=https://organizer.example.com
+ORGANIZER_TRUST_PROXY=1
+MCP_ORGANIZER_DATA_DIR=/var/lib/mcp-organizer
+GROQ_API_KEY=gsk_…
+ORGANIZER_TRANSCRIBE_MODEL=whisper-large-v3-turbo
+SMTP_URL=smtps://organizer:motdepasse@smtp.example.com:465
+MAIL_FROM=Organizer <organizer@example.com>
+```
+
+Sans `GROQ_API_KEY` ou sans `ORGANIZER_TRANSCRIBE_MODEL`, la dictée est désactivée : le journal le signale au démarrage, `GET /api/settings` renvoie `transcription.enabled: false` avec la raison, et le bouton micro de l'interface est désactivé avec cette raison en infobulle. Aucun modèle n'est choisi par défaut.
+
+Sans `SMTP_URL` ou sans `MAIL_FROM`, l'envoi d'e-mail est désactivé : le journal le signale au démarrage, chaque invitation renvoie `emailSent: false` avec la raison (l'interface l'affiche à côté du lien à transmettre), et la page Paramètres le dit sous les notifications. Le lien affiché à l'invitant est formé par l'interface à partir de l'adresse de la page ouverte.
+
+`ORGANIZER_TEST_GROQ_BASE_URL` est **réservée aux tests** : elle remplace l'URL de base de l'API Groq (`https://api.groq.com/openai/v1`) par celle d'un serveur Groq simulé. Elle ne fait pas partie de la configuration d'une installation.
+
+### Derrière nginx
+
+Le bloc produit par `--setup` (voir « Installer le site ») est la référence. Un bloc écrit à la main doit transmettre `X-Forwarded-For` et `X-Forwarded-Proto` (avec `ORGANIZER_TRUST_PROXY=1`), accepter des corps de 26 Mo (`client_max_body_size 26m`) et ne pas mettre `/api/` en cache. Pour publier sous un chemin : `location /organizer/ { proxy_pass http://127.0.0.1:4800/; … }`, avec `ORGANIZER_BASE_PATH=/organizer` et `ORGANIZER_PUBLIC_URL=https://exemple.com/organizer`. Le site pose lui-même ses en-têtes de sécurité (voir « Sécurité ») ; nginx apporte HTTPS et `Strict-Transport-Security`.
+
+## Sécurité
+
+Le site est fait pour être exposé derrière un reverse proxy HTTPS.
+
+- **Écoute** : `127.0.0.1` par défaut ; seul le reverse proxy de la machine le joint.
+- **Origine des modifications** : toute requête `POST`, `PUT`, `PATCH` ou `DELETE` sur `/api/*` exige `Sec-Fetch-Site: same-origin` ou un en-tête `Origin` égal à l'origine de `ORGANIZER_PUBLIC_URL` ; sinon elle reçoit un 403 avant d'atteindre l'API. Une page d'un autre site ne peut donc rien modifier avec la session d'un utilisateur. L'API des agents (`/api/agent/*`) en est exemptée : elle ignore les cookies et n'accepte qu'un jeton dans `Authorization`.
+- **Connexion** : les tentatives de `POST /api/auth/login` sont comptées sur une fenêtre glissante de 15 minutes, par adresse IP (20 au plus) et par couple (adresse IP, adresse e-mail) (5 au plus). Une tentative est comptée dès son arrivée, avant la vérification du mot de passe, et décomptée si la connexion réussit : des tentatives envoyées en parallèle ne dépassent pas la limite. Au-delà, la tentative reçoit un 429 « Trop de tentatives de connexion. Réessayez dans N minutes. » avec `Retry-After`, même avec le bon mot de passe. Le compteur par couple empêche un tiers de bloquer un compte depuis sa propre adresse : son titulaire reste admis depuis la sienne.
+- **Adresse du client** : celle de la connexion ; avec `ORGANIZER_TRUST_PROXY=1` seulement, la dernière entrée de `X-Forwarded-For`, celle qu'écrit le reverse proxy (un client peut ajouter des entrées en tête, pas en fin). Cela suppose que le site ne soit joignable que par le proxy : un site qui écoute sur une adresse publique (`HOST=0.0.0.0`…) reçoit aussi des requêtes directes dont le client écrit lui-même `X-Forwarded-For` ; il pourrait ainsi choisir l'adresse vue par le site et contourner la limitation des connexions. `--setup` refuse donc `--trust-proxy=oui` avec une adresse d'écoute hors de la boucle locale.
+- **Erreurs internes** : une erreur inattendue (fichier manquant, base indisponible…) reçoit un 500 au message générique, avec une référence courte (« Erreur interne du site (référence 1a2b3c4d)… », en anglais pour l'API des agents) ; le détail (message, chemins, pile d'appels) ne va que dans le journal du site, sous cette référence.
+- **En-têtes** sur toutes les réponses : `Content-Security-Policy` (`default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data: blob:; font-src 'self' data:; media-src 'self' blob:; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'`), `X-Content-Type-Options: nosniff`, `X-Frame-Options: DENY`, `Referrer-Policy: same-origin`, `Cross-Origin-Opener-Policy` et `Cross-Origin-Resource-Policy: same-origin`, `Permissions-Policy` (micro pour le site seul, ni caméra ni géolocalisation). Les téléchargements de pièces jointes portent `Content-Disposition: attachment` et `Cache-Control: private, no-store`.
+- **Mots de passe** : 8 caractères minimum, hachés en argon2id avec des paramètres fixés (19 Mio, 2 passes, 1 fil). Une adresse inconnue est vérifiée contre un hash factice, pour un temps de réponse identique. Le changement de mot de passe exige l'ancien et ferme les autres sessions du compte.
+- **Sessions** : cookie `organizer_session` opaque (32 octets aléatoires), `HttpOnly`, `SameSite=Lax`, `Path` égal au chemin de base (`ORGANIZER_BASE_PATH`, sinon `/`), `Secure` quand `ORGANIZER_PUBLIC_URL` est en HTTPS. La base ne stocke que son hash sha256. Expiration après 14 jours sans activité ; fermeture à la déconnexion, quand le compte n'est plus actif et quand le mot de passe change.
+- **Liens d'accès** : jeton de 32 octets, stocké haché, valable 7 jours, à usage unique. Un lien d'invitation est rattaché à son invitation et n'accepte qu'elle ; il ne fonctionne plus une fois le compte activé.
+- **Agent** : aucune action hors de l'espace de son jeton, jamais dans l'espace personnel d'un autre utilisateur, et seulement pour une demande prise par ce jeton.
+- **Jetons d'agent** : 32 octets aléatoires, stockés hachés (sha256), montrés une seule fois ; limités à un espace, révocables, éventuellement expirants, revérifiés à chaque usage (compte actif, appartenance à l'espace), révoqués quand leur propriétaire quitte l'espace ou en est retiré.
+- **Mode MCP** : `ORGANIZER_URL` en `https://` hors de la machine locale, aucune redirection suivie : le jeton ne part que vers l'URL configurée.
+- **Secrets** : la clé Groq et l'URL SMTP ne sont jamais renvoyées à l'interface.
+
+## Exploitation
+
+### Mise à jour
+
+```bash
+cd /opt/mcp-organizer
+npm run backup -- /var/backups/mcp-organizer/avant-maj.db
+git pull
+npm ci
+npm run build
+systemctl restart mcp-organizer
+```
+
+Les migrations de la base s'appliquent au démarrage du site. Une nouvelle variable de configuration se pose en relançant `--setup`, qui conserve les valeurs en place.
+
+### Sauvegarde
+
+```bash
+npm run backup -- /var/backups/mcp-organizer/organizer-2026-10-18.db [--force]
+```
+
+La commande lit le même `.env` que le site (`--dotenv` compris) pour trouver le répertoire de données, et s'exécute site en service : la base est copiée par l'API de sauvegarde de SQLite, qui produit un instantané cohérent pendant les écritures. Le résultat est un fichier SQLite autonome (sans fichier `-wal`), vérifié par `integrity_check`. Les pièces jointes que cet instantané référence sont ensuite copiées dans le dossier `<fichier>.attachments/`, à côté, sous leur nom de stockage ; les fichiers plus récents que l'instantané n'y figurent pas.
+
+Elle refuse une destination existante (le fichier ou son dossier `.attachments`), sauf avec `--force` qui les remplace. Une pièce jointe référencée mais introuvable fait échouer la sauvegarde, qui ne laisse alors aucun fichier. Hors Windows, le fichier de la base est créé avec les droits 600 et le dossier des pièces jointes avec les droits 700, dès leur création : la sauvegarde contient les empreintes des mots de passe et des jetons, et n'est lisible que par son propriétaire, y compris pendant son écriture.
+
+**Restauration**, site arrêté :
+
+```bash
+systemctl stop mcp-organizer
+cp organizer-2026-10-18.db /var/lib/mcp-organizer/organizer.db
+rm -f /var/lib/mcp-organizer/organizer.db-wal /var/lib/mcp-organizer/organizer.db-shm
+rm -rf /var/lib/mcp-organizer/attachments
+cp -r organizer-2026-10-18.db.attachments /var/lib/mcp-organizer/attachments
+chown -R mcp-organizer:mcp-organizer /var/lib/mcp-organizer
+systemctl start mcp-organizer
+```
+
+Le `.env` n'est pas dans la sauvegarde : il contient les secrets (clé Groq, URL SMTP) et se conserve à part.
+
+## Développement
+
+```bash
+npm install
+npx playwright install chromium   # une fois
+npm run build        # compile vers dist/, construit gui/dist
+npm test             # tests node --test sur dist/test/*.test.js
+npm run test:e2e     # parcours Playwright (Chromium), après npm run build
+npm start            # lance le mode MCP compilé (npm start -- --server pour le site)
+```
+
+Interface seule, en développement : `cd gui && npm run dev` (les appels `/api/*` exigent le site) ; `npm run lint` (dans `gui/`) lance oxlint. `package.json` et `gui/package.json` se modifient uniquement par des commandes npm ; la version est portée par `npm run release`.
+
+### Architecture
+
+#### Deux modes, une base
+
+- Le **site** (`src/server/`) est un seul processus Hono (`@hono/node-server`) : `start.ts` lit la configuration (`config.ts`), ouvre la base, crée le premier compte et écoute ; `app.ts` pose les protections (en-têtes, contrôle d'origine, limitation des connexions, taille des corps), lit les formulaires multipart, appelle le routeur de l'API (`src/gui-api.ts`, où les droits sont vérifiés) et sert `gui/dist` en injectant `<base href>`.
+- L'**API des agents** (`src/agent-api/`) est montée dans le même serveur, sous `/api/agent/*` : `router.ts` résout le jeton puis appelle la route ; les routes (`requests.ts`, `tasks.ts`, `checklist.ts`, `ideas.ts`) portent la logique des outils, avec `src/core/agent.ts` (demande prise par le jeton, résolution des tâches et membres de l'espace, contexte, résumés des actions).
+- Le **mode MCP** (`src/mcp/`) dialogue avec le client MCP sur stdio (stdout est réservé au JSON-RPC, les journaux vont sur stderr) : `tools.ts` définit les outils (schémas JSON, descriptions) et leur route, `client.ts` appelle le site avec `fetch`, `start.ts` lit `ORGANIZER_URL` et `ORGANIZER_TOKEN` et relaie chaque appel. Il n'importe ni la base ni les modules natifs.
+- `src/index.ts` lit la ligne de commande, charge le `.env` et importe le mode demandé.
+
+#### Persistance SQLite partagée
+
+`better-sqlite3`, mode WAL, clés étrangères actives, attente des verrous de 5 s. La base `<données>/organizer.db` est la seule source de vérité, détenue par le site ; les commandes comme `--set-user` l'ouvrent sur le même répertoire de données, et chaque processus voit les écritures des autres. La prise d'une demande est une mise à jour conditionnelle dans une transaction exclusive : un seul jeton l'obtient, et la demande lui est réservée (`claimedByTokenId`).
+
+Le schéma est versionné par `PRAGMA user_version` (`src/core/migrations.ts`) ; les migrations s'appliquent au démarrage dans des transactions exclusives, une seule fois même si deux processus démarrent ensemble. Une base plus récente que le code est refusée.
+
+Toute écriture passe par `store.mutate(actor, fn)` (`src/core/store.ts`) : l'acteur est un utilisateur ou l'agent (un jeton, pour une demande `processing` prise par ce jeton, avec l'identité du propriétaire du jeton) ; `fn` s'exécute dans une transaction exclusive ; à sa sortie les invariants sont vérifiés sur l'état final (profondeur des tâches, membres des espaces, assignés membres, espace cible des demandes, actions de l'agent limitées à son espace cible…), puis les versions et le journal sont écrits ; une erreur annule tout.
+
+#### Journal des changements
+
+Chaque mutation ajoute à la table `changes` une ligne par entité touchée (`seq` croissant, espace, utilisateur concerné, tâche concernée, auteur). `GET /api/changes?since=<seq>` renvoie les lignes des espaces de l'utilisateur et de ses notifications : c'est ce que l'interface interroge toutes les 3 s. Le journal étant en base, il couvre les écritures de tous les processus.
+
+#### Historique
+
+- **Versions** : chaque modification d'une tâche ou d'une idée en crée un instantané (champs, assignés, tags) avec son auteur. Le menu ⋯ d'une tâche ouvre son historique et restaure une version (nouvelle version au nom de l'utilisateur).
+- **Annuler une action de l'agent** : l'état courant de l'entité doit être celui que l'action a laissé ; sinon le refus nomme l'auteur de la modification (« La tâche ORG-41 a été modifiée depuis par Julie Laurent… »), sans fusion devinée. Une création est supprimée, une suppression recréée, une modification ramenée à l'état d'avant, position dans la colonne comprise (un réordonnancement s'annule ; si la position d'alors est occupée par une autre tâche de la même colonne, l'annulation est refusée plutôt que marquée sans effet).
+- **Annuler un lot** : toutes les actions non annulées, de la plus récente à la plus ancienne, dans une seule transaction : un refus annule tout.
+
+### Arborescence
+
+```
+src/index.ts          ligne de commande : aide, version, .env, choix du mode ou de la commande
+src/server/           mode site : configuration, serveur Hono, protections, limitation des connexions
+src/mcp/              mode MCP (stdio) : instructions, définitions des outils, client HTTP du site,
+                      enable_notifications (notifications.ts) et relais du veilleur (watch-handoff.ts)
+src/agent-api/        routes /api/agent/* : logique des outils de l'agent, authentifiée par jeton
+src/gui-api.ts        routes /api/* de l'interface
+src/cli/              --setup (setup.ts), --set-user (set-user.ts), --backup (backup.ts),
+                      --claude-setup-mcp (setup-mcp.ts), --watch (watch.ts), saisies au terminal (prompt.ts)
+src/deploy/           fichiers écrits par --setup : .env fusionné (env-render.ts), unité systemd et bloc nginx (templates.ts)
+src/core/             base SQLite, migrations, store, comptes, espaces, tâches, tests, pièces jointes,
+                      notifications, e-mail, dictée, file de l'agent, jetons d'agent, historique, .env, journaux, entrée .mcp.json
+shared/schemas/       schémas zod communs au serveur et à l'interface
+shared/logic/         logique pure commune (préfixes, initiales, rangs fractionnaires, bilan d'un test, création du premier compte)
+gui/                  SPA Vite + React 19 + zustand, routage par hash
+test/                 tests node --test (test/launch.ts : lancement hermétique du site et du mode MCP)
+e2e/                  parcours Playwright sur le site réel ; captures dans e2e/screenshots/
+```
+
+### Tests
+
+Les tests ne lisent jamais la configuration du développeur : `test/launch.ts`, partagé par les tests node et les parcours e2e, lance chaque processus avec `--dotenv=<fichier vide du répertoire temporaire>` et vide toutes les variables de configuration héritées du shell. Le site de test est lancé en `--server` sur un port libre de `127.0.0.1`, avec `ORGANIZER_PUBLIC_URL=http://127.0.0.1:<port>` ; les outils sont appelés par un client MCP réel sur le mode MCP, relié à ce site par un jeton créé par l'API de l'interface (`ORGANIZER_URL`, `ORGANIZER_TOKEN`). Un test vérifie, sur une copie du package dont le `.env` détourne le répertoire de données, que ce `.env` n'atteint pas un processus lancé par les tests (et qu'il l'atteindrait sans `--dotenv`).
+
+**Tests node** : migrations, invariants, versions, journal des changements, connexions concurrentes ; comptes (amorçage avec nom obligatoire, `--set-user` et `--name`, connexion, sessions, liens d'accès, invitations, droits, e-mail) ; profil ; jetons d'agent (affichage unique, configuration du mode MCP, hash seul en base, révocation, expiration, perte d'appartenance, espace hors de portée) ; `--claude-setup-mcp` (entrée du mode MCP, `--url` et `--token` obligatoires, fusion, `--force`, options inconnues ou invalides, fichier illisible laissé intact) ; `--setup` (`.env`, unité systemd et bloc nginx écrits, premier compte créé, `.env` existant fusionné, publication sous un chemin, valeurs incohérentes ou manquantes refusées sans rien écrire, valeurs dotenv citées, site démarré depuis le `.env` écrit) ; `--backup` (copie de la base d'un site en service et de ses pièces jointes, restaurable ; destination existante refusée sans `--force` ; pièce jointe manquante qui ne laisse aucun fichier ; répertoire sans base refusé) ; `.env` et `--dotenv` ; tâches, tâches de test, pièces jointes, notifications, boîte à idées, dictée avec un serveur Groq simulé, historique et annulation ; chaque outil appelé par un client MCP du SDK sur le mode MCP relié à un site de test, jeton inconnu, révoqué ou expiré, site injoignable, espace hors portée, demande prise par un autre jeton, deux jetons de deux membres sur le même espace commun (prise atomique), mode MCP sans `ORGANIZER_URL` / `ORGANIZER_TOKEN`, mode MCP qui ne charge aucun module natif (crochet de résolution qui les bloque), `ORGANIZER_URL` en http refusée hors de la machine locale, redirection du site refusée sans y envoyer le jeton, `.env` du paquet ignoré par le mode MCP (lu avec `--dotenv`) ; commandes du site arrêtées avec la marche à suivre quand better-sqlite3 n'a pas de module natif (crochet de résolution qui simule l'échec) ; `list_requests` sur plus de 100 demandes closes (les plus récentes d'abord) ; jetons révoqués au départ ou au retrait de leur propriétaire, et migration qui révoque ceux des anciens membres ; erreurs internes au message générique ; sauvegarde privée pendant son écriture (droits observés hors Windows, test ignoré sous Windows) ; `--setup` qui refuse `--trust-proxy=oui` avec une écoute hors de la boucle locale, bloc nginx en `listen 443 ssl http2` ; notifications de l'agent (présence et délai de grâce du veilleur, ligne d'une demande, `GET notifications`, attente longue réveillée par une demande créée ou libérée, curseur qui rattrape une demande arrivée entre deux attentes, expiration, jeton inconnu, durée hors limites ; `enable_notifications` puis veilleur `--watch` réel qui écrit une ligne par nouvelle demande, sans le jeton dans la conversation, « already live » une fois armé, arrêt sur jeton révoqué, refus de démarrer sans relais) ; API des agents en HTTP direct (401 et 403 explicites, cookies ignorés, écriture sans `Origin`, réponses validées par les schémas partagés) ; site : `--help` (qui cite `--setup` et `--backup`) et `--version`, refus de connexion sans compte avec les commandes d'une installation par clonage et du paquet npm, démarrage refusé sans `ORGANIZER_PUBLIC_URL` ou `PORT` ou avec un chemin de base incohérent, SPA et `<base href>`, cookie (`Path`, `Secure` en https), formulaires multipart et 413 ; protections : modification refusée sans origine ou d'une origine étrangère, en-têtes de sécurité, limitation des connexions par couple (IP, e-mail) et par IP, rafale de tentatives parallèles limitée, compte non bloqué par un tiers, `X-Forwarded-For` ignoré sans `ORGANIZER_TRUST_PROXY` et pris en compte avec.
+
+**Parcours e2e** (site compilé en `--server`, port libre, répertoire de données temporaire, premier compte créé par `ORGANIZER_ADMIN_*`). Chaque page est surveillée : une exception ou une erreur de console, dont toute violation de la CSP, fait échouer le parcours.
+
+- écran de connexion sans compte : commandes `node dist/src/index.js --set-user …` et `npx -y @imenam/mcp-organizer --set-user …` ;
+- connexion refusée puis réussie, création d'un espace commun, invitation, activation du compte invité par le lien dans un second navigateur ; invitation d'un second espace rejointe depuis « Invitations reçues », ancien lien refusé ;
+- tâches, sous-tâches et sous-sous-tâches, glisser-déposer entre colonnes et dans une colonne (persisté), assignation notifiée chez l'assignée ;
+- tâche de test à deux testeurs, résultats, review soumise qui crée une demande traitée par l'agent ; testeuse désassignée puis retirée, résultats conservés en lecture seule ;
+- idée saisie dans l'interface → demande en attente → traitement par un client MCP réel sur le mode MCP, avec un jeton créé par l'API de l'interface (tâche créée, statut et priorité changés) → réponse, actions, jeton qui a traité la demande et dernier passage de l'agent visibles → annulation d'une action puis du lot, tâche retirée du tableau de bord ; demande restée en cours libérée depuis la page Agent puis reprise ; jeton dont le veilleur attend affiché « à l'écoute », réveillé par une demande ;
+- portée : les agents de Julie (un jeton sur son espace personnel, un sur l'espace commun) ne voient que les demandes de leur espace et ne lisent ni ne modifient l'espace personnel de Matthieu, sur lequel elle ne peut pas créer de jeton ;
+- panneau assistant, « Modifiée par l'agent · Annuler » et restauration d'une version ;
+- boîte à idées : promotion manuelle et promotion confiée à l'agent ;
+- commentaires notifiés aux assignés et aux commentateurs précédents, préférence désactivée ;
+- deux utilisateurs, deux agents : Matthieu et Julie créent chacun leur jeton dans Paramètres > Agents et y relient un client MCP réel sur le mode MCP ; les deux agents de l'espace commun voient les demandes des deux membres ; l'agent de Matthieu traite l'idée de Julie, qui annule ses actions depuis la page Agent ; le jeton personnel de Julie est refusé hors de son espace ; le jeton de Julie, révoqué pendant qu'elle traite une demande, est refusé à l'appel suivant avec un message qui dit quoi faire ; la demande restée en cours est libérée depuis la page Agent et reprise par l'agent de Matthieu ;
+- Paramètres : création d'un jeton montré une seule fois, configuration du mode MCP copiée, jeton absent de la page ensuite, révocation, nom affiché et mot de passe ;
+- dictée : faux micro de Chromium et serveur Groq simulé.
+
+Les attentes portent sur l'état de la page ou de l'API, jamais sur un délai fixe. Les captures (1440 px de large, 900 px de haut sauf les détails de tâche, à la hauteur de leur maquette ; données proches des maquettes) sont écrites dans `e2e/screenshots/` : `01-tableau-de-bord`, `02-detail-tache-standard`, `03-detail-tache-de-test`, `04-saisir-une-idee`, `05-panneau-assistant`, `06-agent`, `06-agent-deux-agents`, `08-idees`, `09-menu-espaces`, `09-membres`, `09-invitations-recues`, `10-connexion`, `10-connexion-aucun-compte`, `11-parametres`, `11-parametres-jeton-cree`, `11-parametres-agents`, `12-notifications`, et quelques états intermédiaires.
+
+## Fonctionnement
+
+### L'interface
+
+Thème sombre, épuré, une seule action principale par écran. L'interface se rafraîchit en interrogeant `GET /api/changes` toutes les 3 s, sans connexion permanente, et ne recharge que les données touchées ; les écritures de l'agent, faites par l'API des agents, apparaissent ainsi.
+
+| Écran | Contenu |
+|---|---|
+| **Connexion** | Carte unique : e-mail, mot de passe, « Se connecter ». |
+| **Activation** (`#/activation/<jeton>`) | Lien d'invitation : nom affiché, mot de passe, confirmation ; l'activation ouvre la session. |
+| **Coquille** | Barre latérale : sélecteur d'espace (menu : espaces, « Invitations reçues » quand il y en a, signalées par un point sur le sélecteur, « Membres », « Nouvel espace commun »), Tableau de bord, Idées, Agent avec le nombre de demandes en attente, utilisateur en bas (Paramètres, Déconnexion). En-tête : titre, recherche, cloche, bouton principal « Saisir une idée ». Bulle de l'assistant en bas à droite. |
+| **Tableau de bord** | Kanban à quatre colonnes figées (À faire, En cours, En revue, Terminé) avec glisser-déposer (statut et ordre, souris ou clavier), « Ajouter une tâche » en bas de colonne, onglet « Liste », menu « Filtrer » (type, priorité, assigné, tag). Une carte montre le titre, la priorité si elle est Haute ou Critique, l'icône d'un test et ses KO, l'avancement des sous-tâches et les avatars ; une tâche terminée se réduit à son titre. |
+| **Détail d'une tâche** (`#/task/<id>`) | Une colonne : fil d'Ariane, titre, ligne statut · priorité · assignés · menu ⋯ (tags, type, tâche testée, historique, suppression) ; « Modifiée par l'agent il y a … · Annuler » ; description markdown ; pièces jointes ; checklist ; Kanban des sous-tâches (avec le nombre de sous-sous-tâches) ; commentaires. |
+| **Détail d'un test** | Même gabarit avec « Test », la ligne « Teste ORG-41 … », la barre de bilan et « 9/12 vérifiés · 2 KO », un onglet par testeur, puis un onglet en lecture seule par ancien testeur (désassigné ou parti de l'espace), un résultat par point (OK, KO, Bloqué, À vérifier, avec commentaire), « Ma review » avec dictée et « Soumettre la review », reviews des autres testeurs repliées avec l'état de leur demande. |
+| **Saisir une idée** | Modale : texte, micro, « Envoyer » ; « L'agent la classera à son prochain passage ». |
+| **Assistant** | Panneau latéral : contexte « À propos de ORG-41 » (tâche ouverte), fil des demandes de l'utilisateur et des réponses de l'agent, statut, « Modifier · Annuler » en attente, « Libérer » en cours, nom du jeton qui traite ou a traité la demande (son propriétaire en infobulle), « N actions · Annuler ». |
+| **Agent** (`#/agent`) | État des agents de l'espace, rechargé toutes les 30 s : chaque jeton actif qui le couvre, son propriétaire et son dernier passage (point allumé s'il date de moins de 10 min), ou « à l'écoute » quand son veilleur de notifications est armé, ou « Aucun agent sur cet espace · Ajouter un agent » (lien vers Paramètres) ; « Filtrer » ; demandes En attente (crayon et croix au survol), En cours (jeton qui l'a prise, « Libérer »), Traitées (jeton qui l'a traitée ; elles se déplient : réponse, actions avec « Annuler », « Tout annuler »), Annulées repliées. |
+| **Idées** (`#/idees`) | Liste avec ajout rapide, idées classées par l'agent, « Promouvoir » ; tiroir « Promouvoir en tâche » : « Laisser l'agent la formater », ou « la remplir moi-même » (titre, type, priorité). |
+| **Membres** | Modale : invitation par adresse, membres et rôles, invitations en attente (renvoyer, révoquer, lien à copier quand l'e-mail ne part pas), renommer ou supprimer l'espace. |
+| **Invitations reçues** | Modale ouverte depuis le menu du sélecteur d'espace : pour chaque espace qui invite l'utilisateur, l'auteur de l'invitation, « Refuser » et « Rejoindre » (qui ouvre l'espace). |
+| **Notifications** | Menu sous la cloche : non lues d'abord, phrase courte, extrait du commentaire, « Tout marquer comme lu » ; un clic ouvre la tâche. |
+| **Paramètres** (`#/parametres`) | Profil (nom affiché, mot de passe avec l'ancien) ; Agents (jetons : nom, espace, dernier usage, état ; « Créer un jeton », « Révoquer ») ; Notifications (assignation / commentaire × application / e-mail, avec la raison quand les e-mails ne partent pas). |
+
+« Créer un jeton » demande un nom, un espace parmi ceux de l'utilisateur et une expiration facultative (7 jours, 30 jours, 90 jours, 1 an), puis affiche une seule fois le jeton et « Copier la configuration », qui copie l'entrée `.mcp.json` du mode MCP prête à coller (voir « Jetons d'agent »). Le presse-papiers exige HTTPS ou localhost ; sinon la page dit pourquoi la copie échoue.
+
+### Espaces, membres et droits
+
+- Chaque compte actif a un **espace personnel** (« Personnel »), créé à son activation, dont il est le seul membre.
+- Un **espace commun** a un propriétaire et des membres. Son préfixe de tâches (`RSV` dans `RSV-12`) est dérivé de son nom et reste modifiable à la création.
+- **Inviter** une adresse (propriétaire) : un compte actif devient membre immédiatement ; une adresse inconnue reçoit un compte `invited` et un lien d'activation à usage unique, valable 7 jours, envoyé par e-mail et affiché à l'invitant. Un compte `invited` peut être invité par plusieurs espaces : chaque invitation a son propre lien, et inviter l'adresse depuis un autre espace ne révoque pas le lien déjà envoyé.
+- **Un lien n'accepte que son invitation** : il active le compte (nom affiché, mot de passe, espace personnel) et fait rejoindre l'espace qui l'a émis, lui seul. Les autres invitations restent en attente : une fois connecté, l'utilisateur les accepte ou les refuse dans « Invitations reçues ». Une fois le compte actif, ses autres liens d'activation ne fonctionnent plus et le disent.
+- Une invitation se **renvoie** (nouvelle échéance ; nouveau lien, qui remplace celui de cette invitation seulement, tant que le compte n'est pas activé ; pour un compte déjà actif, l'invitation l'attend dans « Invitations reçues ») ou se **révoque** (son lien ne fonctionne plus). Une invitation expirée n'apparaît plus dans « Invitations reçues » tant qu'elle n'est pas renvoyée.
+- Le propriétaire renomme, supprime l'espace et retire des membres ; un membre peut quitter l'espace. Un membre encore assigné à une tâche doit en être désassigné d'abord ; ses résultats et reviews de test restent en historique, en lecture seule.
+
+| Action | Qui |
+|---|---|
+| Voir un espace, ses membres et ses invitations ; lire et modifier ses tâches, idées, commentaires | Membres de l'espace |
+| Modifier ou supprimer un commentaire | Son auteur |
+| Saisir ses résultats et sa review sur une tâche de test | Ses testeurs (assignés) |
+| Inviter, révoquer, retirer un membre, renommer, supprimer l'espace | Propriétaire |
+| Accepter ou refuser une invitation | Son destinataire, connecté |
+| Voir une demande, la modifier ou l'annuler en attente, la libérer quand l'agent l'a prise | Membres de l'espace où elle est écrite |
+| Voir les actions de l'agent et les annuler | Membres de l'espace de la demande : tous dans un espace commun, le propriétaire seul pour son espace personnel |
+| Agent | Droits du propriétaire du jeton, limités à l'espace du jeton, pour une demande prise par ce jeton |
+
+Un non-membre reçoit la même réponse qu'un espace ou une tâche inexistants (404) ; un membre qui tente une action réservée au propriétaire reçoit un refus (403). Les droits sont vérifiés dans la transaction de l'écriture : un membre retiré par un autre processus entre-temps est refusé.
+
+### Tâches
+
+- Une **tâche** porte un numéro propre à l'espace (`ORG-41`, jamais réutilisé), un titre, une description markdown, un statut, une priorité (Basse, Moyenne, Haute, Critique), un type (standard ou test), des assignés (membres de l'espace) et des tags (créés au premier usage).
+- **Sous-tâches** sur deux niveaux : tâche > sous-tâche > sous-sous-tâche, dans le même espace, sans cycle.
+- **Ordre** : chaque colonne (espace, parent, statut) est ordonnée par un rang fractionnaire, pris au milieu des deux voisines ; la colonne est renumérotée quand leur écart devient trop faible. La checklist et les points de vérification suivent la même règle.
+- **Pièces jointes** : 20 Mo au plus, stockées sous `<données>/attachments/<id>` ; supprimer une pièce jointe, sa tâche ou son espace efface le fichier.
+- **Tâches de test** : des points de vérification à la place d'une checklist ; chaque testeur saisit son propre résultat par point (`ok`, `ko`, `blocked`, `untested`) et un commentaire. Le bilan d'un point est KO si un testeur a trouvé un KO, sinon Bloqué, sinon OK, sinon à vérifier. Un test peut désigner la tâche qu'il vérifie. La review se rédige en brouillon puis se soumet : elle est figée et crée une demande `test_review` qui vise l'espace de la tâche.
+
+### Demandes
+
+- **Types** : `idea` (« Saisir une idée »), `message` (panneau assistant, avec la tâche ouverte pour contexte), `remark`, `test_review` et `idea_promotion`.
+- **Cycle** : `pending`, puis `processing` quand l'agent la prend, puis `done` avec sa réponse ou `failed` avec la raison. Une demande en attente se modifie ou s'annule (`cancelled`). Une demande restée `processing` (agent arrêté en cours de route) se **libère** : un membre de son espace la repasse `pending`, et un agent pourra la reprendre ; les actions déjà faites restent dans son lot. Rien ne la libère automatiquement.
+- **Lot** : chaque écriture de l'agent pour une demande est une action numérotée, avec l'état de l'entité avant et après et un résumé (« Statut En cours → En revue », « Assigné à Julie Laurent »).
+
+### Notifications
+
+- **Assignation** : un utilisateur ajouté aux assignés d'une tâche est notifié, sauf s'il s'assigne lui-même.
+- **Commentaire** : notifie les assignés de la tâche et ceux qui l'ont déjà commentée, sauf l'auteur.
+- L'auteur d'une notification est un utilisateur ou l'agent (avec la demande pour laquelle il agit).
+- **Préférences** (toutes activées par défaut) : assignation et commentaire, chacun dans l'application et par e-mail. L'e-mail part du site après la validation de la transaction, y compris pour les actions de l'agent (le mode MCP n'envoie rien), avec un lien vers la tâche ; son issue (`emailedAt`, ou `emailError` avec la raison) est enregistrée.
+
+### Boîte à idées
+
+- Idées manuelles (ajout rapide) et idées classées par l'agent (`create_idea`).
+- **Promotion manuelle** : titre, type et priorité ; la tâche est créée dans « À faire » avec l'idée pour description, et l'idée sort de la liste active.
+- **Promotion confiée à l'agent** : une demande `idea_promotion` ; une idée a au plus une promotion ouverte, pendant laquelle la promotion manuelle est refusée.
+- Une idée s'archive et se désarchive ; on ne promeut ni une idée archivée, ni une idée déjà promue.
+
+### Jetons d'agent
+
+- Un **jeton** se crée dans Paramètres > Agents. Il couvre **exactement un espace** : l'espace personnel de son créateur ou un espace commun dont il est membre.
+- Il vaut `org_` suivi de 32 octets aléatoires en base64url. Il n'est affiché qu'une fois, à sa création ; la base n'en garde que le hash sha256 et le début (`org_` et 8 caractères), qui sert à le reconnaître.
+- La création renvoie aussi l'entrée `.mcp.json` du mode MCP : `npx -y @imenam/mcp-organizer` avec `ORGANIZER_URL` (l'URL publique du site) et `ORGANIZER_TOKEN` (le jeton).
+- Un jeton est vérifié à chaque usage : il ne doit être ni révoqué ni expiré, son propriétaire doit avoir un compte actif et être toujours membre de l'espace couvert. Chaque usage accepté met à jour son « dernier usage ».
+- État affiché : actif ; expiré ; **révoqué**, par son propriétaire ou quand celui-ci quitte l'espace ou en est retiré (dans la même transaction que le départ : une nouvelle invitation ne le fait pas revivre, il faut créer un nouveau jeton) ; inactif quand le compte de son propriétaire n'est plus actif. Seul son propriétaire voit, révoque un jeton ; la révocation est immédiate et définitive.
+- Les membres d'un espace voient, sur la page Agent, le nom et le propriétaire des jetons actifs qui le couvrent et leur dernier passage, ainsi que le jeton qui a pris ou traité chaque demande ; jamais leur valeur.
+
+### Dictée vocale
+
+Le navigateur enregistre le micro en webm (MediaRecorder) et envoie l'enregistrement à `POST /api/transcribe` (25 Mo au plus). Le site appelle `POST https://api.groq.com/openai/v1/audio/transcriptions` (`Authorization: Bearer <GROQ_API_KEY>`, multipart `file`, `model`, `language=fr`, `response_format=json`) et renvoie le texte, inséré au curseur. Une erreur de Groq remonte telle quelle, avec son code et son message ; un 401 de Groq ne ferme pas la session.
+
+### API de l'interface
+
+| Route | Rôle |
+|---|---|
+| `GET /api/health` | État du serveur et `accountsExist` |
+| `POST /api/auth/login`, `POST /api/auth/logout`, `GET /api/auth/me` | Connexion (limitée, voir « Sécurité »), déconnexion, utilisateur connecté |
+| `GET` / `POST /api/access-links/:token` | Validité d'un lien ; activation (nom affiché, mot de passe) |
+| `PATCH /api/profile`, `POST /api/profile/password` | Nom affiché ; mot de passe `{ currentPassword, newPassword }` (les autres sessions sont fermées) |
+| `GET` / `POST /api/spaces`, `PATCH` / `DELETE /api/spaces/:id` | Espaces ; création d'un espace commun ; renommage, suppression |
+| `GET /api/spaces/:id/members`, `DELETE …/members/:userId`, `POST …/leave` | Membres et invitations ; retrait ; départ |
+| `POST /api/spaces/:id/invitations`, `POST …/invitations/:id/resend`, `DELETE …/invitations/:id` | Invitation, renvoi (`link` nul pour un compte déjà actif), révocation |
+| `GET /api/invitations`, `POST /api/invitations/:id/accept`, `POST /api/invitations/:id/decline` | Invitations reçues par l'utilisateur connecté ; acceptation ; refus |
+| `GET` / `POST /api/spaces/:id/tasks` | Arbre des tâches (filtres `type`, `priority`, `assignee`, `tag`) ; création |
+| `GET` / `PATCH` / `DELETE /api/tasks/:id`, `POST /api/tasks/:id/move` | Détail, modification, suppression ; déplacement Kanban `{ status, afterId }` |
+| `PUT /api/tasks/:id/assignees`, `PUT /api/tasks/:id/tags` | Assignés ; tags |
+| `POST /api/tasks/:id/checklist`, `PATCH` / `DELETE /api/checklist/:id`, `POST /api/checklist/:id/move` | Checklist |
+| `POST /api/tasks/:id/checkpoints`, `PATCH` / `DELETE /api/checkpoints/:id`, `POST …/move`, `PUT …/result` | Points de vérification et résultats |
+| `PUT /api/tasks/:id/review`, `POST /api/tasks/:id/review/submit` | Brouillon de review ; soumission |
+| `POST /api/tasks/:id/comments`, `PATCH` / `DELETE /api/comments/:id` | Commentaires |
+| `POST /api/tasks/:id/attachments` (multipart, champ `file`), `GET` / `DELETE /api/attachments/:id` | Pièces jointes |
+| `GET` / `POST /api/spaces/:id/ideas`, `PATCH /api/ideas/:id`, `POST /api/ideas/:id/promote`, `POST /api/ideas/:id/delegate` | Idées, archivage, promotion manuelle, promotion confiée à l'agent |
+| `GET` / `POST /api/spaces/:id/requests`, `GET` / `PATCH /api/requests/:id`, `POST /api/requests/:id/cancel`, `POST /api/requests/:id/release` | File de l'agent (`pendingCount` compte toutes les demandes en attente, au-delà des 200 renvoyées ; `agents` liste les jetons actifs de l'espace avec leur dernier usage ; chaque demande porte `agent`, le jeton qui l'a prise) ; dépôt, détail avec les actions du lot, modification et annulation en attente, libération d'une demande en cours |
+| `POST /api/agent-actions/:id/undo`, `POST /api/requests/:id/undo` | Annulation d'une action ; d'un lot |
+| `GET /api/tasks/:id/versions`, `POST /api/tasks/:id/versions/:version/restore` | Versions d'une tâche ; restauration |
+| `GET /api/notifications`, `GET …/unread-count`, `POST …/:id/read`, `POST …/read-all` | Notifications |
+| `GET` / `PUT /api/settings` | Préférences de notification ; disponibilité de l'e-mail et de la dictée |
+| `GET` / `POST /api/tokens`, `POST /api/tokens/:id/revoke` | Jetons d'agent de l'utilisateur ; création `{ name, spaceId, expiresInDays }` (renvoie une seule fois `value` et `mcpJson`, l’entrée `.mcp.json` du mode MCP) ; révocation |
+| `POST /api/transcribe` (multipart, champ `file`) | Dictée |
+| `GET /api/changes?since=<seq>` | Changements des espaces de l'utilisateur et de ses notifications |
+
+Toutes les routes exigent une session, sauf la santé, la connexion, la déconnexion et les liens d'accès. Un segment de chemin mal encodé (`%` invalide) reçoit un 400 ; un corps de plus de 25 Mo, un 413.