docs : review complète du projet (REVIEW.md + TICKETS.md)

2026-06-11 11:18:27 +02:00
parent c02f999a32
commit bfd77a1ca1
2 changed files with 777 additions and 0 deletions
@@ -0,0 +1,343 @@
+# Tickets correctifs — Projet Inventory
+
+> Liste de tâches issues de la review du 2026-06-11 (`REVIEW.md`).
+> Chaque ticket est autonome : contexte, ce qu'il faut faire, fichiers concernés.
+> Commence par les P0, puis P1, etc. Convention de commit : `fix(T-XXX) : description courte`.
+
+---
+
+## P0 — Urgents (sécurité)
+
+### T-001 — Révoquer et retirer les credentials de `.mcp.json`
+**Pourquoi :** le fichier `.mcp.json` est dans git et contient le mot de passe admin MCP de production (`A123`) et un token Lesstime valide. Toute personne avec accès au dépôt (ou à son historique) peut se connecter aux deux systèmes. Supprimer le fichier ne suffit pas : git garde l'historique — il faut **changer les secrets**.
+**À faire :**
+1. Changer le mot de passe du profil `admin-default-profile` sur `inventory.malio-dev.fr` (et choisir un vrai mot de passe, pas `A123`).
+2. Régénérer le bearer token Lesstime côté Lesstime.
+3. Sortir le fichier de git sans le supprimer du disque :
+   ```bash
+   git rm --cached .mcp.json
+   echo ".mcp.json" >> .gitignore
+   ```
+4. Créer `.mcp.json.example` avec des placeholders :
+   ```json
+   {
+       "mcpServers": {
+           "inventory": {
+               "type": "http",
+               "url": "https://inventory.malio-dev.fr/_mcp",
+               "headers": {
+                   "X-Profile-Id": "<PROFILE_ID>",
+                   "X-Profile-Password": "<PASSWORD>"
+               }
+           }
+       }
+   }
+   ```
+5. Remettre les nouveaux secrets dans ton `.mcp.json` local (désormais ignoré).
+**Fichiers :** `.mcp.json`, `.gitignore`, `.mcp.json.example` (nouveau)
+
+### T-002 — Supprimer `create_test_user.php` et vérifier la prod
+**Pourquoi :** ce script de debug, commité à la racine, crée un compte `ROLE_ADMIN` avec `admin@admin.com` / `admin123` — un mot de passe devinable en quelques essais. S'il a déjà tourné en production, un compte admin faible existe peut-être en ce moment.
+**À faire :**
+1. Vérifier en prod qu'aucun profil `admin@admin.com` n'est actif :
+   ```sql
+   SELECT id, email, is_active, roles FROM profiles WHERE email = 'admin@admin.com';
+   ```
+   S'il existe : le désactiver ou changer son mot de passe immédiatement.
+2. Supprimer le script :
+   ```bash
+   git rm create_test_user.php
+   ```
+3. (Optionnel) Si le besoin « créer un admin de dev » existe encore, créer une commande Symfony `app:create-admin` qui prend le mot de passe en argument — ne jamais le hardcoder.
+**Fichiers :** `create_test_user.php`
+
+### T-003 — Changer le mot de passe PG prod et archiver les scripts `*-prod-*.php`
+**Pourquoi :** 9 scripts dans `scripts/` contiennent le mot de passe de la base de production en clair (`fermerecette`). Ce sont des scripts de réparation one-shot qui ont déjà servi : ils n'ont plus de raison d'être dans le dépôt avec des secrets dedans.
+**À faire :**
+1. Changer le mot de passe de l'utilisateur PG concerné sur le serveur de prod.
+2. Archiver les scripts (le dossier `_archives/` est déjà dans le `.gitignore`) :
+   ```bash
+   mkdir -p _archives/scripts-prod
+   git rm scripts/check-prod-values.php scripts/check-prod-audit-dates.php \
+     scripts/check-prod-missing-piece-cfs.php scripts/check-prod-orphaned-detail.php \
+     scripts/fix-prod-all.php scripts/fix-prod-recreate-and-migrate.php \
+     scripts/migrate-orphaned-custom-fields.php scripts/restore-custom-field-values.php \
+     scripts/verify-prod-health.php
+   # (les copies locales peuvent aller dans _archives/scripts-prod si tu veux les garder)
+   ```
+3. Si l'un d'eux doit rester utilisable : remplacer les credentials en dur par `getenv('DATABASE_URL')`.
+**Fichiers :** `scripts/*-prod-*.php`, `scripts/migrate-orphaned-custom-fields.php`, `scripts/restore-custom-field-values.php`
+
+---
+
+## P1 — Importants
+
+### T-004 — Ajouter une CI qui lance tests et lint
+**Pourquoi :** aujourd'hui, rien ne lance les tests automatiquement : la CI Gitea ne fait que tagger et builder l'image Docker, et le hook pre-commit est contourné avec `--no-verify` (trop lent). On peut donc livrer en prod avec des tests rouges sans aucune alerte.
+**À faire :**
+1. Créer `.gitea/workflows/ci.yml` :
+   ```yaml
+   name: CI
+   on:
+     pull_request:
+     push:
+       branches: [develop]
+   jobs:
+     backend:
+       runs-on: ubuntu-latest
+       services:
+         postgres:
+           image: postgres:16-alpine
+           env:
+             POSTGRES_USER: root
+             POSTGRES_PASSWORD: root
+             POSTGRES_DB: inventory_test
+           ports: ["5432:5432"]
+       steps:
+         - uses: actions/checkout@v4
+         - uses: shivammathur/setup-php@v2
+           with: { php-version: '8.4', extensions: 'pdo_pgsql, intl' }
+         - run: composer install --no-interaction --prefer-dist
+         - run: vendor/bin/php-cs-fixer fix --dry-run --diff --allow-risky=yes
+         - run: php bin/console doctrine:schema:create --env=test
+           env: { DATABASE_URL: "postgresql://root:root@localhost:5432/inventory_test" }
+         - run: vendor/bin/phpunit
+           env: { DATABASE_URL: "postgresql://root:root@localhost:5432/inventory_test" }
+     frontend:
+       runs-on: ubuntu-latest
+       steps:
+         - uses: actions/checkout@v4
+         - uses: actions/setup-node@v4
+           with: { node-version: 22 }
+         - run: npm ci
+           working-directory: frontend
+         - run: npx eslint .
+           working-directory: frontend
+         - run: npx nuxi typecheck
+           working-directory: frontend
+         - run: npm run build
+           working-directory: frontend
+   ```
+   > Adapter les détails (version PHP exacte, env de test) au premier run — l'important est que les 4 vérifications (cs-fixer, PHPUnit, ESLint, typecheck) tournent.
+2. Dans Gitea, marquer ce workflow comme requis pour merger une PR vers `develop`.
+**Fichiers :** `.gitea/workflows/ci.yml` (nouveau)
+
+### T-005 — Définir une limite de taille d'upload à tous les niveaux
+**Pourquoi :** aucune limite n'est choisie nulle part. Conséquence double : en prod, nginx applique son défaut de **1 Mo** (les gros PDF sont sans doute rejetés avec une erreur brute), et côté application rien n'empêcherait de remplir le disque si les limites infra étaient relevées. Décision à prendre : 50 Mo max (à ajuster au métier).
+**À faire :**
+1. Check applicatif dans `DocumentUploadProcessor::handleMultipartUpload()` (après la validation MIME, ligne ~79) :
+   ```php
+   private const MAX_UPLOAD_BYTES = 50 * 1024 * 1024; // 50 Mo
+
+   if ($file->getSize() > self::MAX_UPLOAD_BYTES) {
+       throw new BadRequestHttpException('Fichier trop volumineux (max 50 Mo).');
+   }
+   ```
+2. Même check dans `CommentController::create()` dans la boucle `foreach ($files as $file)` (ligne ~106) — renvoyer `$this->json(['message' => 'Fichier trop volumineux (max 50 Mo).'], 400)`.
+3. `infra/dev/php.ini` — ajouter :
+   ```ini
+   upload_max_filesize = 50M
+   post_max_size = 55M
+   ```
+   Et vérifier que l'image prod (infra/prod/Dockerfile) reçoit la même config.
+4. `infra/prod/nginx.conf` — dans le bloc `server` :
+   ```nginx
+   client_max_body_size 55m;
+   ```
+   (idem dans `nginx-proxy.conf` si le proxy frontal est aussi versionné ici).
+5. Tester : upload d'un PDF de ~5 Mo en local, et vérifier le message d'erreur propre au-delà de 50 Mo.
+**Fichiers :** `src/State/DocumentUploadProcessor.php`, `src/Controller/CommentController.php`, `infra/dev/php.ini`, `infra/prod/nginx.conf`, `infra/prod/Dockerfile`
+
+### T-006 — Corriger le fallback d'URL API du frontend
+**Pourquoi :** si la variable `NUXT_PUBLIC_API_BASE_URL` est vide en prod, tous les appels API partent vers `http://localhost:3000` — c'est-à-dire vers la machine de l'utilisateur. L'app casse silencieusement. Un fallback vide = « même origine », ce qui est le comportement correct.
+**À faire :**
+1. `frontend/app/composables/useApi.ts` ligne 18 :
+   ```ts
+   // AVANT
+   const API_BASE_URL = (publicConfig.apiBaseUrl as string) || 'http://localhost:3000'
+   // APRÈS (chaîne vide = même origine ; useApi ajoute déjà /api)
+   const API_BASE_URL = (publicConfig.apiBaseUrl as string) || ''
+   ```
+2. `frontend/nuxt.config.ts` ligne ~49 : remplacer le fallback `'http://localhost/api'` par `''` (valeur SSR jamais utilisée, SSR off — autant ne pas mentir).
+3. Vérifier en dev que tout fonctionne encore (la variable est définie en dev, donc rien ne doit changer), puis `npx nuxi typecheck`.
+**Fichiers :** `frontend/app/composables/useApi.ts`, `frontend/nuxt.config.ts`
+
+### T-007 — Purger la doc « submodule » (le frontend est dans le monorepo)
+**Pourquoi :** le frontend a été rapatrié dans le repo principal, mais README, DEPLOY, RELEASE et le README frontend décrivent encore le clonage `--recurse-submodules` et le workflow de commit en deux temps. Un nouveau dev (ou toi en incident de prod) suit des étapes qui n'existent plus.
+**À faire :**
+1. `README.md` : lignes 49-50 → `git clone <url-du-repo>` ; section « workflow » lignes ~291-296 → décrire « un seul commit depuis la racine couvre backend + frontend ».
+2. `DEPLOY.md` : supprimer les `git submodule update --init --recursive` (lignes 58, 62, 208).
+3. `RELEASE.md` : supprimer les étapes submodule (lignes 49, 117).
+4. `frontend/README.md` : remplacer la section « submodule » (lignes 150-154) par « ce dossier fait partie du monorepo Inventory ».
+**Fichiers :** `README.md`, `DEPLOY.md`, `RELEASE.md`, `frontend/README.md`
+
+### T-008 — Corriger l'utilisateur PG dans `DEPLOY.md`
+**Pourquoi :** les commandes de DEPLOY.md utilisent `ferme_user` / `fermerecette` — copié-collé du projet Ferme. Le vrai utilisateur est `inventory_user`. En situation d'incident, suivre la doc ferait taper des commandes qui échouent ou visent la mauvaise base.
+**À faire :**
+1. Remplacer les 6 occurrences de `ferme_user` par `inventory_user`.
+2. Remplacer le mot de passe en clair par un placeholder `<mot-de-passe-prod>` (le mot de passe n'a rien à faire dans la doc).
+**Fichiers :** `DEPLOY.md`
+
+### T-009 — Durcir le garde anti path-traversal de `DocumentStorageService`
+**Pourquoi :** le contrôle `realpath()` (qui vérifie que le chemin final est bien dans le dossier de stockage) est sauté quand le fichier n'existe pas, car `realpath()` renvoie `false` dans ce cas. Le risque actuel est faible (le chemin vient de la base, pas de l'utilisateur), mais le contrôle se veut une protection — autant qu'il protège vraiment.
+**À faire :** dans `getAbsolutePath()` (`src/Service/DocumentStorageService.php:28-42`) :
+```php
+// AVANT
+$absolutePath = $this->storageDir.'/'.$relativePath;
+$realPath     = realpath($absolutePath);
+
+if (false !== $realPath && !str_starts_with($realPath, realpath($this->storageDir))) {
+    throw new RuntimeException(sprintf('Path traversal detected: "%s"', $relativePath));
+}
+
+// APRÈS — valider sur le dossier parent, qui existe toujours pour un fichier servi
+$absolutePath = $this->storageDir.'/'.$relativePath;
+$realParent   = realpath(dirname($absolutePath));
+$realStorage  = realpath($this->storageDir);
+
+if (false === $realStorage || false === $realParent
+    || !str_starts_with($realParent.'/', $realStorage.'/')) {
+    throw new RuntimeException(sprintf('Path traversal detected: "%s"', $relativePath));
+}
+```
+Garder le check `str_contains($relativePath, '..')` existant en première ligne. Ajouter un test unitaire avec un chemin contenant `../` et un chemin absolu.
+**Fichiers :** `src/Service/DocumentStorageService.php`, `tests/` (nouveau test)
+
+---
+
+## P2 — Consolidation
+
+### T-010 — Hardening CSRF : header `X-Requested-With` obligatoire sur les écritures
+**Pourquoi :** l'auth est par cookie, et la seule protection contre le CSRF (un site malveillant qui fait faire des requêtes à ton navigateur connecté) est l'attribut `SameSite=Lax` du cookie. Une deuxième barrière peu coûteuse : exiger un header custom, qu'un formulaire HTML cross-site ne peut pas envoyer.
+**À faire :**
+1. Côté front, dans `useApi.ts`, ajouter `'X-Requested-With': 'XMLHttpRequest'` aux headers de toutes les requêtes.
+2. Côté back, créer un listener `kernel.request` qui renvoie 403 si la méthode n'est pas GET/HEAD/OPTIONS, que le chemin matche `^/api` (hors `/api/session/profile` pour le login) et que le header est absent.
+3. Supprimer la clé morte `csrfToken` de `nuxt.config.ts` (elle laisse croire qu'une protection CSRF existe).
+4. Adapter les tests API (`AbstractApiTestCase`) pour envoyer le header.
+**Fichiers :** `frontend/app/composables/useApi.ts`, `src/EventListener/` (nouveau), `frontend/nuxt.config.ts`, `tests/AbstractApiTestCase.php`
+
+### T-011 — Test fonctionnel : l'ID de session change au login
+**Pourquoi :** la protection automatique contre la fixation de session est désactivée (`session_fixation_strategy: none`, choix documenté pour la SPA) et compensée par un `$session->migrate(true)` manuel au login. Si quelqu'un supprime ce `migrate` un jour, plus rien ne protège — un test doit le verrouiller.
+**À faire :** écrire un test API qui : récupère le cookie de session avant login → se loggue → vérifie que l'ID de session a changé. Ajouter un commentaire dans `SessionProfileController::activateProfile()` pointant vers `security.yaml:5`.
+**Fichiers :** `tests/Api/SessionProfileTest.php` (ou équivalent), `src/Controller/SessionProfileController.php`
+
+### T-012 — MCP : remplacer le mot de passe par un token Bearer + HTTPS
+**Pourquoi :** le mot de passe du profil circule en clair dans les headers de chaque requête MCP (et l'URL configurée est en `http://`). Les headers finissent dans les logs des proxys. Un token dédié révocable, transmis en `Authorization: Bearer`, est le pattern déjà utilisé par Lesstime.
+**À faire :** ajouter un champ `mcpToken` (hashé) sur Profile ou une table `api_tokens`, générer via une commande console, adapter `McpHeaderAuthenticator` pour valider le Bearer (garder le rate-limiting), mettre à jour `.mcp.json.example`, et servir `/_mcp` en HTTPS uniquement.
+**Fichiers :** `src/Mcp/Security/McpHeaderAuthenticator.php`, `src/Entity/Profile.php` ou nouvelle entité, migration, `.mcp.json.example`
+
+### T-013 — Maintenance : faire respecter le flag côté backend
+**Pourquoi :** le toggle admin écrit `var/maintenance`, mais seul le **frontend** (middleware) le vérifie. Quelqu'un qui appelle l'API directement (curl, MCP, script) passe à travers. Et le second mécanisme (`maintenance.on` lu par nginx, posé par `deploy.sh`) n'est documenté nulle part.
+**À faire :**
+1. Listener `kernel.request` backend : si `var/maintenance` existe et que l'utilisateur n'est pas admin → 503 JSON (sauf `/api/maintenance/check` et `/api/session/*`).
+2. Documenter les deux niveaux (applicatif vs nginx/deploy) dans `DEPLOY.md`.
+**Fichiers :** `src/EventListener/` (nouveau), `DEPLOY.md`
+
+### T-014 — Résoudre l'incohérence provider/email nullable
+**Pourquoi :** le user provider Symfony charge les profils par `email`, mais l'email est nullable (profils « kiosque »). Ça marche par chance (l'authenticator charge par ID), mais tout futur usage du provider standard cassera sur ces profils.
+**À faire :** décision à prendre — option A : email obligatoire + email technique généré pour les kiosques ; option B : provider custom qui charge par id ou email. Documenter le choix dans `docs/BACKEND.md`.
+**Fichiers :** `config/packages/security.yaml`, `src/Entity/Profile.php`, éventuellement `src/Security/`
+
+### T-015 — Supprimer `@nuxtjs/tailwindcss`
+**Pourquoi :** dépendance non utilisée (le projet utilise `@tailwindcss/vite`, Tailwind 4) qui installe en plus un Tailwind 3 parallèle — bloat et risque de conflit de résolution.
+**À faire :**
+```bash
+cd frontend && npm uninstall @nuxtjs/tailwindcss && npm run build && npx nuxi typecheck
+```
+**Fichiers :** `frontend/package.json`, `frontend/package-lock.json`
+
+### T-016 — Mettre à jour la doc de versioning (`VERSION` → `config/version.yaml`)
+**Pourquoi :** `RELEASE.md` (lignes 17, 50, 80, 82) et l'arbre projet de `CLAUDE.md` référencent un fichier `VERSION` qui n'existe plus — la version vit dans `config/version.yaml`.
+**À faire :** remplacer toutes les références ; vérifier au passage que la description du footer frontend (« lit VERSION au build ») correspond au mécanisme réel.
+**Fichiers :** `RELEASE.md`, `CLAUDE.md`
+
+### T-017 — Sortir les données client de la racine + gitignore défensif
+**Pourquoi :** `customer.json`, `Company (1).json`, `Ensemble simple rotor.pdf` (données client réelles → enjeu RGPD) traînent à la racine, non protégés par le `.gitignore` : un `git add .` distrait les commiterait.
+**À faire :**
+1. Déplacer ces fichiers hors du dépôt (ex. `~/imports/inventory/`). Supprimer aussi `inventory_prod (2).sql.gz` et le `node_modules/` orphelin de la racine.
+2. Ajouter au `.gitignore` racine :
+   ```
+   /node_modules/
+   /*.json
+   /*.pdf
+   ```
+   (les `.json` légitimes du projet sont dans des sous-dossiers ou explicitement trackés — `composer.json` etc. restent suivis car déjà trackés ; pour les nouveaux, `git add -f` reste possible).
+**Fichiers :** `.gitignore`, racine du projet
+
+### T-018 — Uniformiser la gestion d'erreur frontend (état d'erreur au lieu de `console.error`)
+**Pourquoi :** en cas d'échec de chargement, le pattern actuel est `console.error(...)` puis la page s'affiche à moitié vide, sans message. L'utilisateur ne sait pas que quelque chose a raté ni comment réessayer.
+**À faire :** règle : `useApi` est le seul à toaster ; les composables exposent un `error: Ref<string | null>` que la page affiche (bandeau avec bouton Réessayer). Commencer par les 3 pages principales : détail machine (`useMachineDetailData.ts:372,385`), détail composant, détail pièce. Étendre ensuite au reste.
+**Fichiers :** `frontend/app/composables/useMachineDetailData.ts`, `useComponentEdit.ts`, `usePieceEdit.ts`, pages correspondantes
+
+### T-019 — Cacher le résultat de `/maintenance/check` (TTL)
+**Pourquoi :** chaque navigation d'un non-admin déclenche un appel API pour vérifier la maintenance — de la latence sur toutes les transitions de page pour un état qui ne change presque jamais.
+**À faire :** dans `profile.global.ts`, stocker le résultat dans un `useState` avec timestamp et ne re-fetcher que si > 60 s.
+**Fichiers :** `frontend/app/middleware/profile.global.ts`
+
+### T-020 — Détracker `infra/dev/.env.docker.local` + fournir un `.example`
+**Pourquoi :** le fichier est dans le `.gitignore` mais a été commité avant l'ajout de la règle — git continue donc de le suivre. Chaque dev qui le modifie crée du diff, et ses secrets (même de dev) sont versionnés.
+**À faire :**
+```bash
+cp infra/dev/.env.docker.local infra/dev/.env.docker.local.example
+# Dans le .example : remplacer les valeurs par des placeholders <CHANGE_ME>
+# et supprimer les variables JWT_* (inutilisées, cf. T-023)
+git rm --cached infra/dev/.env.docker.local
+git add infra/dev/.env.docker.local.example
+```
+Mettre à jour le README (section installation) pour mentionner la copie du `.example`.
+**Fichiers :** `infra/dev/.env.docker.local`, `infra/dev/.env.docker.local.example` (nouveau), `README.md`
+
+---
+
+## P3 — Nice to have
+
+### T-021 — Décision métier : commentaires (et pièces jointes) en `ROLE_VIEWER` ?
+**Pourquoi :** seule écriture accessible aux lecteurs. Si c'est voulu (« tout le monde commente »), le documenter dans `docs/BACKEND.md` ; sinon passer à `ROLE_GESTIONNAIRE` (`CommentController.php:33`).
+**Fichiers :** `src/Controller/CommentController.php`, `docs/BACKEND.md`
+
+### T-022 — Revoir les pagination max (2000/1000/500)
+**Pourquoi :** `Constructeur` (2000), `ConstructeurCategorie` (1000), `Document` (500) — vérifier le besoin réel du front et redescendre, ou commenter pourquoi.
+**Fichiers :** `src/Entity/Constructeur.php`, `src/Entity/ConstructeurCategorie.php`, `src/Entity/Document.php`
+
+### T-023 — Nettoyer les variables JWT et les secrets `changeme`
+**Pourquoi :** `JWT_SECRET_KEY`/`JWT_PUBLIC_KEY`/`JWT_PASSPHRASE` ne servent à rien (auth session). `APP_SECRET=changeme_…` mérite une vraie valeur aléatoire locale. (Fusionne naturellement avec T-020.)
+**Fichiers :** `infra/dev/.env.docker.local`
+
+### T-024 — Supprimer la config morte de `nuxt.config.ts`
+**Pourquoi :** `csrfToken`, `requestTimeout`, `enableDebug`, `enableAnalytics`, `logLevel` ne sont consommés nulle part — de la config qui ment. (`csrfToken` est déjà traité par T-010.)
+**Fichiers :** `frontend/nuxt.config.ts:56-59`
+
+### T-025 — Nettoyer le Dockerfile dev (blocs Oracle/IMAP/MySQL commentés)
+**Pourquoi :** restes d'un template générique sans rapport avec un projet PostgreSQL.
+**Fichiers :** `infra/dev/Dockerfile:48-53,82-100`
+
+### T-026 — Renommer les 3 utils `.js` en `.ts`
+**Pourquoi :** `documentPreview.js`, `fileIcons.js`, `printTemplates/machineReport.js` sont importés depuis du TypeScript sans types. Tâche mécanique (bon candidat pour Codex).
+**Fichiers :** `frontend/app/utils/documentPreview.js`, `frontend/app/utils/fileIcons.js`, `frontend/app/utils/printTemplates/machineReport.js`
+
+### T-027 — Ajouter `nosniff` + `CSP: sandbox` à `download()`
+**Pourquoi :** `serve()` envoie ces deux headers de protection, `download()` non — asymétrie gratuite.
+**À faire :** copier les deux `headers->set(...)` de `serve()` dans `download()` (`DocumentServeController.php:110-116`).
+**Fichiers :** `src/Controller/DocumentServeController.php`
+
+### T-028 — Smoke test de l'image Docker avant push
+**Pourquoi :** `build-docker.yml` pousse `latest` sans vérifier que l'image démarre.
+**À faire :** entre build et push : `docker run --rm gitea.malio.fr/malio-dev/inventory:${{ gitea.ref_name }} php bin/console about`.
+**Fichiers :** `.gitea/workflows/build-docker.yml`
+
+> **Hors tickets :** la dette d'architecture (smartMatch dupliqué, double flush, `pendingStructure`, God controller à 1121 lignes, `any` ×179…) a déjà son plan d'action chiffré dans `docs/REVIEW_ARCHITECTURE.md`. Recommandation forte : exécuter sa **Phase 1** (4 corrections effort S, sans impact d'interface) avant qu'elle ne prenne encore 3 mois — voir `REVIEW.md` §4.
+
+---
+
+## Résumé
+
+| Priorité | Tickets | Estimation |
+|----------|---------|------------|
+| **P0** | T-001 à T-003 | ~2h (+ rotations de secrets) |
+| **P1** | T-004 à T-009 | ~1,5 j |
+| **P2** | T-010 à T-020 | ~2,5 j |
+| **P3** | T-021 à T-028 | ~0,5 j |
+| **Total** | 28 tickets | ~5 j |
+
+> Commence par **T-001** — tant que les secrets ne sont pas révoqués, tout le reste est secondaire.
+> Pour chaque ticket, fais un commit dédié avec le numéro dans le message (ex. `fix(T-001) : retirer .mcp.json du dépôt`).