matthieu
8fae987e15
Auto Tag Develop / tag (push) Successful in 6s
Acte la décision refonte-contact dans les specs : le contact principal inline (firstName/lastName/phonePrimary/phoneSecondary/email) est retiré des entités tiers (Client, Supplier). Les contacts vivent uniquement dans ClientContact / SupplierContact (onglet Contacts). Garantie « >=1 contact nommé » préservée par RG-1.05/1.14 (M1) et RG-2.04/2.13 (M2). - M1 (spec-back/spec-front/cahier) : modèle Client sans contact inline ; RG-1.01/1.02 supprimées ; D1 (recherche) / D2 (export) décrites ; version V1. - M2 (spec-back/spec-front) : FICHIERS NOUVEAUX (non versionnés sur develop), introduits déjà corrigés (Supplier sans contact inline, RG-2.01/2.02 supprimées) ; version V0.2. - docs/specs/M1-clients/refonte-contact/ : décision (README) + tickets (M1 back/front/specs, M2 specs) + prompts + amendement des tickets M2. Lesstime : tâches #103 (M1 back), #104 (M1 front), #105 (M1 specs), #106 (M2 specs) ; tickets M2 #85-#97 amendés. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #54 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
52 lines
3.4 KiB
Markdown
52 lines
3.4 KiB
Markdown
# M1 · Ticket 3/3 (Specs) — Acter la suppression du contact inline dans les specs M1
|
|
|
|
## 1. Objectif
|
|
|
|
Mettre à jour la **documentation fonctionnelle/technique M1** pour refléter la décision :
|
|
le contact principal inline est supprimé du `Client`, les contacts vivent uniquement dans
|
|
`ClientContact`. Les specs sont la **source de vérité** du projet (cf. `workflow.md`) : elles
|
|
doivent décrire le modèle cible, pas l'ancien.
|
|
|
|
> Idéalement réalisé **avant** les tickets 1 et 2 (la spec guide le code), mais peut être
|
|
> fait en parallèle. À minima, ne pas merger le code sans aligner la spec.
|
|
|
|
## 2. Fichiers à modifier
|
|
|
|
| Fichier | Sections concernées |
|
|
|---|---|
|
|
| `docs/specs/M1-clients/spec-back.md` | § 3.1 diagramme E-R (retirer les 5 colonnes du bloc `client`) ; § 3.2 migration SQL `CREATE TABLE client` (retirer `first_name`/`last_name`/`phone_primary`/`phone_secondary`/`email` + leurs COMMENT) ; § 3.4 squelette entité `Client` (retirer les 5 props) ; § 4.3 exemple payload `POST /api/clients` (retirer les 5 champs) ; § 4.1 filtre `?search=` (refléter D1) ; § 4.6 export (refléter D2) ; § 7 RG (voir § 3 ci-dessous) ; § 8 cahier de tests (déplacer RG-1.01/1.02 vers ClientContact). |
|
|
| `docs/specs/M1-clients/spec-front.md` | « Formulaire principal » (l.85-103) : retirer les lignes Nom/Prénom/Téléphone/Téléphone 2/Email ; écrans Consultation / Modification ; règles de formatage. Préciser que les coordonnées se saisissent dans l'onglet Contact. |
|
|
| `docs/specs/M1-clients/cahier-test-back-M1.md` | Retirer / requalifier les lignes RG-1.01 et RG-1.02 (désormais couvertes par RG-1.05 sur `ClientContact`). |
|
|
|
|
## 3. Traitement des règles de gestion
|
|
|
|
- **RG-1.01** (firstName OU lastName obligatoire sur Client) → marquer **supprimée** :
|
|
« Remplacée par RG-1.05 (≥ 1 contact valide) + RG-1.14 (≥ 1 bloc Contact). Le contact
|
|
principal inline n'existe plus. »
|
|
- **RG-1.02** (max 2 téléphones sur Client) → marquer **supprimée du Client** (reste
|
|
applicable aux blocs `ClientContact`).
|
|
- **RG-1.19 / RG-1.20 / RG-1.21** (normalisation) → préciser que le **scope `Client`
|
|
disparaît** ; la normalisation reste sur `ClientContact` (et `ClientAddress.billingEmail`
|
|
pour RG-1.21).
|
|
- Ne **pas renuméroter** les RG existantes (éviter le drift avec le code/tests) : marquer
|
|
« supprimée / requalifiée » en place, avec date et renvoi à la décision.
|
|
|
|
## 4. Forme
|
|
|
|
- Bumper la version des deux specs (`version: V0` → `V1`) dans le frontmatter, avec une
|
|
entrée d'historique : date `2026-06-03`, motif « Suppression du contact inline du Client
|
|
(refonte-contact) », auteur.
|
|
- Ajouter un encadré « Décision » en tête de la section modèle de données, renvoyant au
|
|
`README.md` du dossier `refonte-contact`.
|
|
- Conserver le style des specs (sections numérotées, tableaux RG, exemples JSON).
|
|
|
|
## 5. Critères d'acceptation (DoD)
|
|
|
|
- [ ] `spec-back.md` : aucune mention des 5 colonnes inline dans le modèle `client`
|
|
(E-R + SQL + entité + payload) ; RG-1.01/1.02 marquées supprimées ; D1/D2 décrites.
|
|
- [ ] `spec-front.md` : le formulaire principal ne liste plus les champs de contact ;
|
|
l'onglet Contact est présenté comme seul lieu de saisie des coordonnées.
|
|
- [ ] `cahier-test-back-M1.md` : RG-1.01/1.02 retirées/requalifiées.
|
|
- [ ] Versions bumpées (V1) + historique daté dans les deux specs.
|
|
- [ ] Cohérence vérifiée avec les tickets 1 et 2 (mêmes décisions D1/D2).
|