perhapsspy/purpose-first-design

Conception centrée sur l'objectif (Purpose-First Design)

Fonction et finalité

Choisissez la plus petite direction défendable pour une décision de produit ou de planification d'implémentation matériellement ouverte avant que la structure de la solution ne soit fixée. L'objectif définit ce que signifie le succès ; les décisions utilisateur verrouillées, l'autorité, ainsi que les limites de sécurité, de retour arrière, de propriété et opérationnelles requises contraignent la réponse et ne sont jamais des alternatives.

Terminez par une direction provisoire, la plus petite vérification qui pourrait modifier un choix réellement ouvert, ou une question bloquante. Si aucune direction matérielle ne reste ouverte, dites-le brièvement et passez la main sans inventer d'alternatives.

Contrat de décision

• Énoncez uniquement l'objectif et le succès observable nécessaire pour distinguer le choix.
• Séparez les entrées pertinentes pour la décision en LOCKED, EVIDENCE, ASSUMPTION et OPEN. Ne promouvez jamais une décision verrouillée, une contrainte explicite, un périmètre rejeté ou un élément réglé par des preuves dans OPEN. Un échec de vérification ne peut modifier qu'un mécanisme non résolu, pas la signification verrouillée du produit.
• Traitez l'implémentation existante, le précédent, les valeurs par défaut et l'urgence comme des preuves sauf si elles sont explicitement faisant autorité. Comparez uniquement les alternatives qui modifient matériellement la signification, la responsabilité, l'état persistant, la politique, le cycle de vie, le contrat public, le risque accepté ou le couplage difficile à inverser.
• Choisissez la plus petite direction suffisante. N'ajoutez pas de propriétaires, de processus, de mécanismes de retour arrière, de plateformes, de programmes futurs ou de décisions ouvertes à moins que la source ou la direction choisie ne les exige.

Passage de relais

Utilisez d'abord source-owner-audit lorsque l'autorité présente est inconnue. Passez la réalisation réglée — flux de code, état, séquencement, interfaces, gestion des échecs et ordre d'implémentation — à structure-first. Passez l'expression et le packaging réglés à tighten-docs.

Retournez un résumé de décision concis : direction, base changeant la décision, limites verrouillées, hypothèses ou décisions ouvertes réelles, et la prochaine vérification décisive ou workflow propriétaire. Incluez une limite uniquement lorsqu'elle contraint la direction choisie.

Réduction finale

Examinez uniquement le périmètre, les engagements, les hypothèses et les décisions ouvertes introduits par votre réponse. Supprimez tout ce que l'objectif, les limites verrouillées, l'autorité, les preuves ou la direction choisie n'exigent pas. Fusionnez les alternatives uniquement lorsque leur signification produit et les limites requises sont les mêmes.

Ce passage peut réduire mais ne doit pas créer de périmètre, d'engagements, d'hypothèses, de décisions ouvertes ou de relais, et ne doit jamais rouvrir la signification LOCKED. S'il expose une limite obligatoire manquante, énoncez cette limite comme requise plutôt qu'optionnelle. Préservez la complexité nécessaire pour la sécurité, le retour arrière, la propriété, les opérations ou un mode de défaillance démontré.