Checklist d'implementation du risque client

Statut documentaire : tutorial — voir Maturité et preuves.

Utiliser cette checklist avant de considerer l'exemple reproduit.

[ ] La configuration application active le package de risque.
[ ] Le manifest expose des identifiants stables et uniques pour Customer, RiskRequest, RiskIndicator, RiskReviewProcess et RiskDecision.
[ ] La configuration memoire charge et resout tous les concepts avant activation de la persistance.
[ ] Les liens demande-client et indicateur-demande sont des relations conceptuelles avec projections explicites si necessaire.
[ ] Les contraintes client obligatoire, plage de score et finalisation sont appliquees hors couche visuelle.
[ ] Les actions publiees ont des noms metier stables et des parametres types.
[ ] RiskReviewProcess possede la coordination multi-objets/asynchrone.
[ ] Les transitions significatives emettent des evenements semantiques.
[ ] La vue de revue utilise DataSet/DataSource/DataCursor et garde les evenements UI locaux par defaut.
[ ] Seules les actions stables sont exposees comme services.
[ ] Authentification, autorisation, validation et etat du processus restent controles a la publication.
[ ] Le contexte IA est borne aux donnees/actions conceptuelles autorisees.
[ ] L'approbation humaine est encodee dans le processus lorsqu'elle est requise.
[ ] Les tests couvrent chargement, modele, actions, evenements, processus, vues, services, parite .NET local/RPC et garde-fous IA.
[ ] Les tests d'evolution protegent role paths, signatures d'action et noms d'evenements.

Si tous les points passent, un developpeur peut reconstruire cette architecture depuis le site sans dependance a une etape manquante dans le livre declaratif.