4nk/smart_ide
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
smart_ide/services/docv/enso-docs/features/implementation/TEMPLATE_IMPL.md
Nicolas Cantu bc3c75e15f Add enso docs mirror under services/docv/enso-docs; docv integration docs 
- Copy enso/docs tree to services/docv/enso-docs (refresh via cp -a from enso repo)
- Document mirror and refresh command in services/docv/README.md
- Ignore services/docv/target for local Rust workspace
- Track docv-service-integration, API docv.md, and related doc index updates
2026-04-03 17:26:35 +02:00

2.6 KiB
Raw Blame History

Template — Document d’implémentation technique par zone

Ce template définit la structure d’un document d’implémentation technique pour une zone fonctionnelle. Les sections 2 et 3 s’appuient sur REFERENTIEL_ECRANS_ACTIONS.md pour la liste des identifiants d’écrans et des actions 18.x, et sur la SPEC correspondante pour les règles métier et les endpoints.

Implémentation technique : [Nom de la zone]

Zone : [N°] — [Titre]
Spec fonctionnelle : [lien vers SPEC_xx]
Référentiel : [lien REFERENTIEL section zone]

1. Vue d’ensemble

  • Périmètre technique (front, back, BDD, paramétrage) de la zone.
  • Dépendances (autres zones, clients externes).

2. Écrans (détail technique)

Pour chaque écran du référentiel (identifiant stable) :

[identifiant stable] — [Nom écran]

  • Route(s) : chemin(s) front (ex. app/(auth)/login/page.tsx, route Next.js ou équivalent).
  • Front :
    • Page / composant principal (fichier, rôle).
    • Composants enfants (liste ou arbre court).
    • State : local (useState/useReducer) ou global (store/context), données chargées.
    • Appels API : méthode, endpoint, moment (mount, submit, etc.), mapping réponse.
    • Validation : côté client (WASM ou utils), champs concernés, messages d’erreur (i18n).
    • Paramétrage : clé screen_config (identifiant stable), effet sur visibilité/ordre.
  • Back :
    • Handler(s) : fichier, route HTTP, extraction params/body, appel service, retour JSON/erreur.
    • Service(s) : logique métier, appels repository et/ou clients externes.
    • Repository / modèle : tables, requêtes principales (lecture/écriture).
  • BDD : tables et colonnes concernées (rappel si déjà dans ARCHITECTURE_DOCV_DETAILLEE).
  • Paramétrage : identifiant stable pour screen_config, conditions d’affichage.

(Répéter le bloc pour chaque écran de la zone.)

3. Actions (mapping technique)

Table synthétique : pour chaque action 18.x de la zone, le déclencheur UI, l’appel API ou l’action locale, le handler/service back, et la validation ou contrainte éventuelle.

Action Déclencheur (UI) Appel / action Back (handler, service) Validation / erreur
18.x Bouton/lien/form GET/POST/… endpoint handler → service → repo règle métier, message

4. Points d’attention

  • Erreurs typées, pas de fallback silencieux.
  • Clients externes (ancrage, IA) : uniquement côté back, depuis quels services.
  • i18n : clés utilisées pour libellés et messages d’erreur.