Matthieu
83508d0c5a
Le contact principal inline (firstName/lastName/phonePrimary/phoneSecondary/email) est retiré des entités tiers : il vit désormais uniquement dans ClientContact / SupplierContact (onglet Contacts). - M1 (spec-back / spec-front / cahier-test) : contact inline retiré du modèle Client ; RG-1.01 et RG-1.02 marquées supprimées (équivalent RG-1.05 / RG-1.14) ; décisions D1 (recherche) et D2 (export) décrites ; version V1. - M2 (spec-back / spec-front) : contact inline retiré du modèle Supplier dès la conception ; RG-2.01 et RG-2.02 supprimées (équivalent RG-2.04 / RG-2.13) ; version V0.2. Fichiers M2 introduits ici car non encore versionnés sur develop. - docs/specs/M1-clients/refonte-contact/ : décision (README) + tickets (M1 back/front/ specs, M2 specs) + prompts d'implémentation + amendement des tickets M2 existants.
3.4 KiB
3.4 KiB
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
Clientdisparaît ; la normalisation reste surClientContact(etClientAddress.billingEmailpour 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 : date2026-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.mddu dossierrefonte-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èleclient(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).