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.
48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
# Prompt d'implémentation — M1 · Ticket 2/3 (Frontend)
|
|
|
|
Projet **Starseed** (Nuxt 4 / Vue 3 Composition API / TypeScript / @malio/layer-ui).
|
|
Lis `CLAUDE.md` et `.claude/rules/frontend.md` avant de coder. Commentaires en français,
|
|
code en anglais, 4 espaces d'indentation.
|
|
|
|
## Mission
|
|
|
|
Retirer le **bloc « contact principal »** (Nom, Prénom, Téléphone, Téléphone 2, Email) des
|
|
écrans Client (création / consultation / modification) et de tout le code associé (types,
|
|
mappeurs, validations, i18n). Les contacts restent gérés par l'onglet **Contacts**
|
|
(`ClientContactBlock`, inchangé).
|
|
|
|
Spec détaillée : `docs/specs/M1-clients/refonte-contact/M1-ticket-02-front.md` (lis-la en
|
|
entier + le `README.md` du dossier). Ce ticket dépend du ticket back (l'API ne porte plus
|
|
les 5 champs sur `client`).
|
|
|
|
## Étapes
|
|
|
|
1. Explorer `frontend/modules/commercial/` : `pages/clients/new.vue`, `[id]/edit.vue`,
|
|
`[id]/index.vue`, `types/clientForm.ts`, `types/clientConsultation.ts`,
|
|
`utils/clientEdit.ts`, `utils/clientConsultation.ts`, `i18n/locales/fr.json`.
|
|
2. Supprimer le bloc principal des 3 écrans + l'état réactif `main.firstName/lastName/email`,
|
|
`mainPhones`, `prefillFirstContact()`.
|
|
3. Adapter `isMainValid` : ne dépend plus que de `companyName` (+ relation/catégories selon
|
|
l'existant). La garantie « ≥ 1 contact valide » reste portée par l'onglet Contacts.
|
|
4. Nettoyer les types (`MainFormDraft`, `ClientDetail`) et les mappeurs (`mapMainDraft`,
|
|
`buildMainPayload`, `clientConsultation`).
|
|
5. Retirer les clés i18n `form.main.firstName/lastName/email/phonePrimary/phoneSecondary/addPhone` ;
|
|
vérifier par recherche qu'aucune vue ne les utilise plus. **Garder** `form.contact.*`.
|
|
6. Mettre à jour les specs Vitest (`clientFormRules`, `clientEdit`, `clientConsultation`).
|
|
|
|
## Garde-fous
|
|
|
|
- `useApi()` uniquement ; composants `Malio*` uniquement ; pas d'état tableau dans l'URL.
|
|
- Ne touche pas `ClientContactBlock.vue`, l'onglet Contacts, ni la liste/répertoire.
|
|
- Pas de normalisation front (le serveur normalise).
|
|
|
|
## Vérification finale
|
|
|
|
```bash
|
|
make nuxt-test # Vitest vert
|
|
make dev-nuxt # port 3004 — golden path manuel
|
|
```
|
|
|
|
Golden path à vérifier dans le navigateur : créer un client (entreprise + 1 contact dans
|
|
l'onglet Contacts), le consulter, le modifier — sans aucun bloc contact inline.
|