8 Commits

Author	SHA1	Message	Date
matthieu	a52e3bec34	[ERP-76 + ERP-68] Validations d'adresse client (RG → 422) + fixtures démo Catalog/Commercial (#41) ... Stack de 2 tickets sur une branche (squash sur `develop`). ## ERP-76 (#500) — Validations d'adresse Client → 422 Les règles d'intégrité de l'onglet Adresse étaient soit non implémentées (RG-1.29), soit rejetées en 500 par les CHECK Postgres (RG-1.06/07/08/11). Elles sont désormais portées par des `Assert\Callback` applicatifs sur `ClientAddress`, qui remontent une **422 Hydra avant la base** ; les CHECK BDD restent en filet de sécurité. - `validateProspectExclusivity` — `isProspect` exclusif de `isDelivery`/`isBilling` (RG-1.06/07/08). - `validateBillingEmailPresence` — `billingEmail` obligatoire ssi `isBilling` (RG-1.11). - `validateCategoryTypes` — refuse une catégorie de type DISTRIBUTEUR/COURTIER sur une adresse (RG-1.29, violation `categories`), via `CategoryInterface` (règle n°1 respectée). Tests `ClientAddressTest` durcis (≥400 → **422 explicite**) + 4 cas RG-1.29. Cahier de test M1 mis à jour. ## ERP-68 (#486) — Fixtures démo Catalog + Commercial (dev only) - `CategoryFixtures` (Catalog) : 12 catégories sur les 4 types. - `ClientFixtures` (Commercial) : 14 clients couvrant les cas RG (dépendant distributeur/courtier RG-1.03, LCR + 2 RIB RG-1.13, Chèque sans RIB, multi-adresses Prospect/Livraison/Facturation RG-1.06/07/08/11, prospect seul, 3 contacts + tél. secondaire RG-1.05/1.02, archivé RG-1.22, onglet Information complet, multi-catégories M2M). Résolution inter-modules via les seuls contrats Shared (`CategoryInterface`, `SiteProviderInterface`). Valeurs brutes normalisées par `ClientFieldNormalizer`. Données conformes aux CHECK BDD **et** aux validators ERP-76. Idempotentes (lookup `companyName`/`name`). **Garde-fou** : les deux fixtures sont no-op en environnement `test` (la base de test reste un socle minimal ; pas de pollution des comptages ni des cleanups FK). ## Bonus — idempotence fixtures `AppFixtures` (admin/alice/bob) rendu idempotent via lookup par username : `doctrine:fixtures:load --append` est désormais rejouable sans erreur sur tout le jeu de fixtures. ## Vérifications - `make test` : **436/436 vert** (0 échec/erreur). - `make php-cs-fixer-allow-risky` OK. - `make db-reset` charge sans erreur ; 2 runs `--append` consécutifs = idempotent (0 doublon ; 7 users / 14 clients / 12 catégories stables). - `admin/admin` intact. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #41 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-06-01 22:14:23 +00:00
matthieu	0e3299300f	[ERP-74] Seed RBAC idempotent (rôles + matrice § 2.7 + demo users) + RG-1.04 + test matrice (#40) ... ## Objectif Seeder le RBAC métier de façon **rejouable et disponible en recette/prod** (commande applicative, pas fixture `require-dev`), durcir RG-1.04, et écrire le test de matrice (rôles enfin existants). ## A. `RbacSeeder` (Core) — source unique anti-drift 4 rôles (`bureau`/`compta`/`commerciale`/`usine`, isSystem=false), matrice § 2.7 (rôle → permissions) et comptes démo, définis en **un seul endroit**. Méthodes idempotentes `ensureRoles` / `attachMatrix` / `ensureDemoUsers`. `commerciale` référence `BusinessRoles::COMMERCIALE` (déjà consommé par RG-1.04). ## B. Commande `app:seed-rbac` (présente en build prod, idempotente, non destructive) - Sans option : rôles + matrice § 2.7. - `--with-demo-users` + `--password=<…>` ou env `RBAC_DEMO_PASSWORD` : 1 compte démo/rôle. **Aucun mot de passe en dur** côté serveur. - Garde-fou : exit non-zéro + invite à lancer `app:sync-permissions` si les codes `commercial.clients.*` manquent. ## C. Fixture dev/test `RbacDemoFixtures` (DRY) Appelle le **même seeder** (`ensureRoles` + `ensureDemoUsers`). La matrice est attachée juste après par l'étape `app:seed-rbac` du makefile (la table `permission` est purgée au moment du `fixtures:load`, donc `attachMatrix` ne peut pas tourner pendant le load). `make db-reset` / `test-db-setup` reproduisent l'état de recette. ## Déploiement (documenté README) Après `migration-migrate` + `app:sync-permissions` : `app:seed-rbac` (prod) ; `app:seed-rbac --with-demo-users --password=…` (recette). ## D. Durcissement RG-1.04 Pour une Commerciale, complétude de l'onglet Information exigée sur **POST + tout PATCH** (suppression de la condition d'intersection). Conséquence : POST Commerciale → 422 (le POST n'expose pas le groupe Information), Admin → 201. Spec § 7 amendée. ## Compta ↔ onglet Comptabilité (§ 2.7) Pour que `compta PATCH accounting → 200` (exigé par la matrice), la security du `Patch /clients/{id}` est élargie à `manage` **OU** `accounting.manage`, et un nouveau **`guardManage`** (mode strict RG-1.28) interdit à un porteur non-`manage` de modifier les onglets principal/Information (→ 403). Approche validée : élargir la security + guard in-processor (pas de nouvel endpoint). ## E. `ClientRBACMatrixTest` Matrice § 2.7 complète via les comptes démo seedés (`app:seed-rbac --with-demo-users`) : bureau / compta / commerciale / usine (200/403 par verbe et par onglet) + RG-1.04 (POST Commerciale 422 / Admin 201). ## Tests `make php-cs-fixer-allow-risky` OK ; `make test` **429 tests verts**. Idempotence vérifiée (rejeu de la commande : 0 rôle / 0 lien / 0 user). `test-db-setup` exécute la nouvelle étape `app:seed-rbac` sans erreur. Cible : `develop`. Squash merge. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #40 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-06-01 21:06:33 +00:00
matthieu	120058049c	test(commercial) : cover RG-1.01..1.29 except role-gated (M1) + polish stack (#38) ... Dernier wagon de la stack back M1. ERP-60 = polish stack + couverture de tests PHPUnit NON dépendante des rôles métier (cf. spec § 7 / § 8.1). ## Phase 0 — polish stack (déjà mergé dans les branches basses via rebase) - ERP-59 : route sidebar `/clients` (au lieu de `/commercial/clients`), cohérente avec `/suppliers`. - One-liner pagination Client abandonné : `pagination_client_enabled: true` est déjà le défaut global → `?pagination=false` marche déjà sur `/api/clients` (décision P7). ## Phase 1 — tests (combler les trous, zéro duplication) 8 nouvelles suites couvrant les RG non encore testées par ERP-55/56/57/58 : - `ClientFormulaireMainTest` — RG-1.02 (téléphone secondaire, max 2). - `ClientAddressTest` — RG-1.06/07/08 + RG-1.11 (CHECK BDD prospect/billing). - `ClientUniquenessTest` — RG-1.15/1.17 (Q4 : SIREN/email NON uniques). - `ClientArchiveTest` — **RG-1.23 : 409 restauration en conflit (gap P1)**. - `ClientAuditTest` — RG-1.27 (created* figés / updatedBy modificateur) + iban/bic présents dans le diff audité. - `ClientMigrationTest` — index partiel unique `uq_client_company_name_active` (1 seul) ; pas d'index siren/email. - `ClientSecurityTest` — 401 anonyme + 403 sans `commercial.clients.view`. - `ClientPatchStrictTest` — RG-1.28 (403 strict mix de groupes, fonctionnel). Cahier de test complet (mapping de TOUTES les RG → test) : `docs/specs/M1-clients/cahier-test-back-M1.md`. ## Délégué à ERP-74 (#493) Matrice RBAC différenciée (bureau/compta/commerciale/usine) + RG-1.04 fonctionnel — exigent les rôles métier seedés après le merge de la stack. ## Gaps documentés (cahier) - RG-1.29 validation écriture (catégorie type sur adresse → 422) non implémentée back (hors § 8.1, ticket test-only). - Violations CHECK adresse → rejet (≥400) sans mapping fin 422 (amélioration possible). ## Vérifs `make db-reset && make php-cs-fixer-allow-risky && make test` → **421 tests OK, 1386 assertions, 0 risky**. Nouveaux tests : 17, 71 assertions. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #38 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-06-01 19:46:39 +00:00
matthieu	56cf492dcc	[ERP-53] Migrer les tables Client + sous-collections + référentiels comptables (#27) ... ## Contexte Ticket Lesstime : **#53** (ERP-53) — premier ticket back du M1 (Répertoire clients). Spec back : `docs/specs/M1-clients/spec-back.md` § 3.2 + § 3.3. ## Implémentation - Migration Doctrine `migrations/Version20260601000000.php` (12 tables) + fixture `CategoryTypeFixtures`. - **4 référentiels comptables** seedés : `tva_mode` (3), `payment_delay` (3), `payment_type` (4), `bank` (3). - **Table `client`** : 31 colonnes (formulaire + Information + Comptabilité + archive + soft-delete + Timestampable/Blamable). - **4 sous-collections** : `client_category` (M2M), `client_contact`, `client_address`, `client_rib` + **3 jointures** d'adresse (`client_address_site`, `client_address_contact`, `client_address_category`). - **4 CHECK** : mutex distributor/broker, contact name, address prospect exclusif, billing email conditionnel. - **1 index partiel unique** : `uq_client_company_name_active` sur `LOWER(company_name) WHERE is_archived=false AND deleted_at IS NULL` (décision Q4 — **pas** d'unicité siren/email). - **Seed `category_type`** : DISTRIBUTEUR / COURTIER / SECTEUR / AUTRE (`ON CONFLICT (code) DO NOTHING` en migration pour la prod, + fixture idempotente pour dev/test purgés). - `COMMENT ON COLUMN` sur **chaque** colonne (convention ERP-67, garde-fou vert). ## RG couvertes (niveau BDD) RG-1.03 (mutex distrib/broker), RG-1.05 (contact name), RG-1.06/07/08 (adresse prospect exclusif), RG-1.11 (billing email), RG-1.16 (unicité company_name — RG-1.15/1.17 supprimées par Q4), RG-1.22 (is_archived + archived_at). ## Écarts assumés vs spec (cf. docblock migration + cahier de test du ticket) 1. **Namespace `migrations/` racine** au lieu de `App\Module\Commercial\…` : vérifié empiriquement que Doctrine 3.9.6 (AlphabeticalComparator → strcmp FQCN) trierait le namespace Commercial **avant** `DoctrineMigrations` → migration client exécutée avant user/category/site → échec FK sur base vide. Le namespace racine garantit l'ordre par timestamp. 2. **DDL aligné Doctrine** : `INT GENERATED BY DEFAULT AS IDENTITY` + `TIMESTAMP(0) WITHOUT TIME ZONE` (et non SERIAL/TIMESTAMPTZ) → forward-compatible avec les entités du ticket 1.1 (schema:update no-op). 3. **Seed `category_type (code, label)` sans `position`** : la table M0 n'a pas de colonne `position` (coquille du pseudo-SQL § 3.3). > **Note ERP-54** : à l'arrivée des entités Client*, `schema:update` droppera leurs COMMENT + l'index partiel. Prévoir l'ajout au `ColumnCommentsCatalog` + recréation de l'index dans `test-db-setup` (pattern `uq_category_name_type_active`). ## Tests - `make php-cs-fixer-allow-risky` ✓ - `make db-reset` ✓ + vérifications psql manuelles (8 cas : CHECK, unicité partielle, archivage, siren/email dupliqués, seeds) - `make test` ✓ — **312 tests OK, 0 régression** --------- Co-authored-by: Matthieu <contact@malio.fr> Co-authored-by: Matthieu <mtholot19@gmail.com> Reviewed-on: #27 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-06-01 15:19:43 +00:00
Matthieu	1d91b4dea9	docs(commercial) : fix § 3.5 incohérence AuditIgnore RIB (aligné sur § 2.5)	2026-05-29 14:23:51 +02:00
matthieu	2866fb8865	[docs] M1 — Répertoire clients : specs front + back (#23) ... ## Contexte Spécifications front + back du **Module 1 — Répertoire clients** (premier module métier Tiers, extension du module `Commercial` existant). Origine : V0 client `.docx` du 22/05/2026 (`M1-reportoire-clients.docx`) + maquette Figma `https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-31898`. Pattern de rédaction : strictement aligné sur `docs/specs/M0-categories/` (spec-front léger + spec-back très détaillé). ## Contenu - `docs/specs/M1-clients/spec-front.md` (289 lignes) — V0 client, structure UI, composants Malio, permissions par rôle, règles de formatage - `docs/specs/M1-clients/spec-back.md` (1056 lignes) — décisions archi, modèle données, migration SQL Postgres, API REST, RBAC matrice complète, 27 RG numérotées, tests à automatiser, 16 HP, liens & dépendances ## Décisions structurantes (validées avec Tristan le 28/05/2026) - **Module** : extension de `Commercial/` (pas nouveau module) - **Catégories Client** : M2M `client_category` + seed `CategoryType` (`DISTRIBUTEUR`, `COURTIER`, `SECTEUR`, `AUTRE`) - **Distributeur / Courtier** : 2 FK auto-référentes nullables sur `client` + contrainte CHECK mutex - **Workflow création** : sauvegarde incrémentale par onglet (POST formulaire principal → PATCH par onglet) - **Onglets « À venir »** (Transport / Statistiques / Rapports / Échanges) : placeholders blancs (frames vides, pas de message texte) - **Archive vs delete** : flag `is_archived` exposé au M1, colonne `deleted_at` préparée mais non exposée (HP M2) - **API adresse** : api-adresse.data.gouv.fr (BAN), appel direct front via `useAddressAutocomplete()` - **Unicité métier** : SIREN + `companyName` + email (indexes partiels Postgres, ignorent archivés et soft-deletés) - **Téléphones** : 2 colonnes plates `phone_primary` + `phone_secondary` - **Export** : XLSX uniquement (controller custom avec `priority: 1`) - **Compta = lecture seule** ⚠ s'écarte du tableau du `.docx` (ligne « Compta = Ajout/Modification Comptabilité uniquement » invalidée) — documenté en HP-M2-10 ## Seed M1 (référentiels comptables) | Référentiel | Valeurs | |---|---| | `tva_mode` | `FRANCE_VENTES`, `EXPORT_VENTES`, `INTRACOM_VENTES` | | `payment_delay` | `J15`, `J30`, `A_RECEPTION` | | `payment_type` | `VIREMENT`, `LCR`, `NON_SOUMISE`, `CHEQUE` | | `bank` | `SG`, `CIC`, `CA` (Société Générale / CIC / Crédit Agricole) | | `category_type` (extension M0) | `DISTRIBUTEUR`, `COURTIER`, `SECTEUR`, `AUTRE` | ## RG ajoutées au-delà du `.docx` - **RG-1.14** : ≥ 1 bloc Contact valide obligatoire (renforcement Tristan) - **RG-1.15/16/17** : unicités SIREN / nom / email - **RG-1.18** : `companyName` UPPERCASE serveur - **RG-1.19** : `firstName` / `lastName` Capitalize serveur - **RG-1.20** : téléphones chiffres seuls en BDD, formatage `XX XX XX XX XX` au front - **RG-1.21** : emails lowercase serveur - **RG-1.22/23** : archivage / restauration + conflit unicité à la restauration ## Permissions RBAC (à synchroniser dans les 3 miroirs au moment du dev) | Permission | Admin | Bureau | Compta | Commerciale | Usine | |---|---|---|---|---|---| | `commercial.clients.view` | ✅ | ✅ | ✅ | ✅ | ❌ | | `commercial.clients.manage` | ✅ | ✅ | ❌ | ✅ | ❌ | | `commercial.clients.accounting.view` | ✅ | ❌ | ✅ | ❌ | ❌ | | `commercial.clients.accounting.manage` | ✅ | ❌ | ❌ | ❌ | ❌ | | `commercial.clients.archive` | ✅ | ❌ | ❌ | ❌ | ❌ | ## Prochaines étapes (hors MR) 1. Revue / validation des specs par Matthieu 2. Création du **TaskGroup Lesstime** `M1 — Répertoire clients` (projet `ERP / Starseed`, projectId=6) 3. Découpage en ~14 tickets (ordre indicatif listé en bas du `spec-back.md`) ## Reviewer suggéré Matthieu (CP MALIO). ## Cible `develop`. --------- Co-authored-by: admin malio <malio@yuno.malio.fr> Co-authored-by: Matthieu <mtholot19@gmail.com> Reviewed-on: #23 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-05-29 09:58:32 +00:00
matthieu	6efe7aa8ea	[ERP-52] Créer le pattern Timestampable + Blamable Shared (#13) ... ## Contexte Ticket Lesstime : [#52](https://project.malio-dev.fr/projects/6/tasks/463) Position dans le groupe M0 : 0.0 (prérequis transverse) ## Implémentation - 2 interfaces (`TimestampableInterface`, `BlamableInterface`) dans `Shared/Domain/Contract/` - 1 trait (`TimestampableBlamableTrait`) dans `Shared/Domain/Trait/` - 1 Subscriber Doctrine (`TimestampableBlamableSubscriber`) dans `Shared/Infrastructure/Doctrine/` - 1 ligne `resolve_target_entities` ajoutée à `config/packages/doctrine.yaml` (`UserInterface` → `User`) - 1 test architecture (`EntitiesAreTimestampableBlamableTest`) garde-fou L3 de la spec § 2.8.bis - 1 test unitaire (`TimestampableBlamableSubscriberTest`) 4 cas ## Décision EXCLUDED (cf. réponse review) Les 4 entités préexistantes (`User`, `Role`, `Permission`, `Site`) sont **whitelistées** dans `EXCLUDED` avec justification par entrée, plutôt que rétrofitées dans ce ticket. Le rétrofit de `User` et `Site` est documenté en **HP-9 / HP-10** (récursion Blamable + migration → décision archi scopée). Doc mise à jour : spec § 2.8.bis, § 9, et `.claude/rules/backend.md`. ## Tests - PHPUnit : 5 nouveaux tests, 0 échec, 0 risky (248 tests / 874 assertions au total) - php-cs-fixer : OK ## Reviewer suggéré - Tristan --------- Co-authored-by: Matthieu <mtholot19@gmail.com> Reviewed-on: #13 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-05-28 09:37:18 +00:00
matthieu	5db644d22e	docs(catalog) : M0 categories specs (back + front) (#12) ... ## Contexte Premier passage du workflow MALIO sur un module concret. Cette MR introduit **uniquement la documentation** (2 specs Markdown) du **Module 0 — Gestion des catégories**. Aucun code applicatif n'est touché. La spec back a été cadrée sur l'archi DDD réelle de Starseed (cf. `.claude/rules/architecture.md` + `backend.md`) après audit du repo (modules `Core`, `Commercial`, `Sites`). Elle introduit aussi un **nouveau module `Catalog`** (bounded context "référentiels partagés") — non créé dans cette MR, il viendra avec les tickets de dev. ## Contenu | Fichier | Lignes | Objet | |---|---|---| | `docs/specs/M0-categories/spec-back.md` | 700 | Spec back v1.1 : modèle data, API REST (5 endpoints + CategoryType lecture seule), 13 RG (RG-1.01 → RG-1.13), validation, autorisation, audit, tests, hors-périmètre | | `docs/specs/M0-categories/spec-front.md` | 113 | Spec front V0 client (validée 2026-05-22) : UI admin (datatable + drawer), 2 champs (Nom + Type), 3 actions (Ajouter / Consulter / Modifier), permissions par rôle | ## Décisions d'archi (auto-validation back-only) Toutes les décisions sont documentées dans `spec-back.md § 2` : - **Module `Catalog`** créé séparément de `Commercial` pour rester réutilisable par les futurs modules Tiers (M-Clients, M-Fournisseurs, M-Prestas) - **IDs INT IDENTITY** (cohérent avec `User`, `Role`, etc.) - **Soft delete** via `deleted_at TIMESTAMP(0) WITHOUT TIME ZONE NULL` — *pattern introduit par ce module* (aucune autre entité Starseed ne le portait) - **Index unique partiel Postgres** sur `(LOWER(name), category_type_id) WHERE deleted_at IS NULL` → unicité case-insensitive parmi non soft-deleted, recréation possible après suppression logique - **Granularité permissions = `view` + `manage`** (aligné sur `core.users.view` + `core.users.manage`) - **Référentiel `CategoryType`** = entité séparée, table vide à la livraison, valeurs seedées plus tard (HP-1) ## Règles métier (RG-1.01 → RG-1.13) Chaque RG est numérotée, stable, testable, et constituera un critère d'acceptation côté ticket Lesstime (cf. `spec-back.md § 7`). Couverture par catégorie : - Autorisation : RG-1.01 (Admin only) - Champ `name` : RG-1.02 (obligatoire), RG-1.03 (trim), RG-1.04 (longueur 2-120) - Champ `categoryType` : RG-1.05 (obligatoire), RG-1.06 (référence valide) - Unicité : RG-1.07 (case-insensitive sur couple, hors soft-deleted) - Liste : RG-1.08 (exclut soft-deleted), RG-1.09 (flag `?includeDeleted=true`), RG-1.10 (tri `name ASC`) - Détail : RG-1.11 (404 si soft-deleted) - Suppression : RG-1.12 (soft delete), RG-1.13 (`deletedAt` non modifiable via PATCH) ## Découpe en tickets Lesstime TaskGroup `#22 — M0 — Gestion des catégories` créé sur le projet **STARSEED**. 9 tickets en backlog : | # | Ticket Lesstime | Effort | Tag | |---|---|---|---| | 0.1 | `#43` Migrer les tables Category et CategoryType | S | Backend | | 0.2 | `#44` Créer les entités Category et CategoryType | M | Backend | | 0.3 | `#45` Implémenter Provider et Processor Category | M | Backend | | 0.4 | `#46` Exposer le référentiel CategoryType en lecture seule | S | Backend | | 0.5 | `#47` Déclarer le module Catalog et synchroniser RBAC | S | Backend | | 0.6 | `#48` Écrire les tests PHPUnit RG-1.01 à RG-1.13 | M | Backend | | 0.7 | `#49` Créer la page Gestion des catégories (datatable + drawer) | L | Frontend | | 0.8 | `#50` Implémenter les composables useCategoriesAdmin et useCategoryForm | M | Frontend | | 0.9 | `#51` Écrire les tests Vitest des composables Catalog | S | Frontend | **Total estimé** : ~15-25h (9 mini-MR de 1-4h). ## Hors-périmètre (HP) Pas codés / pas inclus dans cette spec (cf. `spec-back.md § 9`) : - HP-1 : CRUD du référentiel `CategoryType` (spec dédiée à venir) - HP-2 : Référencement par les Tiers (les FK `category_id` sur Clients/Fournisseurs/Prestas viendront avec leurs modules) - HP-3 : Restauration d'une catégorie soft-deleted - HP-4 : Hard delete - HP-5 : i18n du `name` - HP-6 : Recherche serveur / filtres avancés - HP-7 : Catégories hiérarchiques (parent / enfant) - HP-8 : Seed des rôles métier Bureau / Compta / Commerciale / Usine ## Checklist review Pas de code → review légère, lecture des 2 `.md` suffit. - [ ] Frontmatter YAML cohérent (module, version, dates, validation client, taskgroup, tags) - [ ] Décisions d'archi argumentées (`spec-back.md § 2`) - [ ] Modèle data réaliste (SQL Postgres rédigé directement, pas de pseudo-code) - [ ] API REST complète (codes HTTP succès + erreurs, payloads, exemples) - [ ] RG numérotées et testables (un humain peut écrire un test PHPUnit à partir de chaque RG sans réinventer) - [ ] Mapping rôles MALIO ↔ permissions RBAC clair (cohérent avec règle ABSOLUE n°8 — 3 sources à toucher) - [ ] Hors-périmètre explicite ## Stratégie de merge **Squash merge** vers `develop` (1 PR = 1 commit propre dans l'historique). ## Lien Lesstime - TaskGroup : `#22 — M0 — Gestion des catégories` (projet ERP / Starseed) - Tickets en backlog : `#43` → `#51` > ⚠️ **À faire manuellement après merge** dans l'UI Lesstime : rattacher les 9 tickets au groupe #22 et leur poser leur effort + tag + priorité (bug typing MCP empêche le wire automatique sur des champs `integer` sans `type` explicite dans le schéma). --------- Co-authored-by: Matthieu Tholot <mtholot19@gmail.com> Reviewed-on: #12 Reviewed-by: Autin <tristan@yuno.malio.fr> Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-05-27 09:03:54 +00:00