BUILD SCHOOL · DOCTRINE DE PRODUIT

Les règles de Danilson.

Chaque règle renvoie à une décision et une source. Ouvre la note pour comprendre le contexte et appliquer la règle à ton projet.

1. RULE 01

   Inspecter avant de modifier.

   Établis le comportement et les fichiers concernés avant de proposer un changement.

   Note de terrain →
2. RULE 02

   Le serveur possède l’état de paiement.

   Le retour Checkout confirme une navigation ; l’événement signé confirme l’achat et l’entitlement.

   Note de terrain →
3. RULE 03

   L’autorisation vit au point d’accès à la donnée.

   Une interface qui masque une action ne remplace pas le contrôle serveur ou base.

   Note de terrain →
4. RULE 04

   Le modèle de données précède les écrans.

   Les entités, identifiants et règles de propriété rendent les flux cohérents ensuite.

   Note de terrain →
5. RULE 05

   Garde le déterministe quand une erreur doit être justifiée.

   Règles versionnées et traces rendent une décision reproductible.

   Note de terrain →
6. RULE 06

   Une sortie IA a besoin d’un contrat.

   Entrée validée, format de sortie, abstention, fallback et évaluation font partie de la feature.

   Note de terrain →
7. RULE 07

   Prépare les signaux d’exploitation avant le lancement.

   Logs, capture d’erreurs, événements produit et audit répondent à des besoins distincts.

   Note de terrain →
8. RULE 08

   Si le serveur n’a pas besoin d’une donnée, ne la collecte pas.

   Le calcul local peut réduire les données transférées ; les décisions sensibles restent vérifiées côté serveur.

   Note de terrain →
9. RULE 09

   Les pages d’acquisition et le moteur partagent une source de données.

   Une page ne doit pas promettre ce que le produit refusera ensuite.

   Note de terrain →
10. RULE 10

    Une v1 doit tenir face à un vrai usage.

    Auth, paiements, erreurs et récupération comptent autant que le parcours heureux.

    Note de terrain →