# 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`).