Décisions architecturales 0.2.0-dev.3

Les décisions sont ajoutées au fil des checkpoints. Les modèles existants sont privilégiés avant toute nouvelle table.

D-000 — Checkpoints indépendants

CONTEXTE : le chantier couvre plusieurs domaines avec migrations et risques différents.

OPTIONS ÉTUDIÉES : un gros développement continu ; checkpoints commitables.

CHOIX : checkpoints A à E, chacun documenté, testé et versionné.

JUSTIFICATION : reprise fiable, absence de régression masquée, dépôt source de vérité.

CONSÉQUENCES : aucun checkpoint suivant ne démarre avant validation du précédent.

DATE/COMMIT : 2026-08-23 / initialisation.

D-001 — Service de création Equipment

CONTEXTE : les routes fiche avancée et wizard construisaient des objets différents et le wizard retrouvait ensuite des équipements par nom.

OPTIONS ÉTUDIÉES : conserver les routes indépendantes ; centraliser la construction dans un service.

CHOIX : core.services.equipment_creation.create_equipment, lot et catégorie facultatifs, retour de l'instance persistée.

JUSTIFICATION : évite les collisions de noms et garantit la même gestion de quantité, parent, localisation et génération préventive.

CONSÉQUENCES : les anciens parcours sont progressivement migrés ; les relations techniques restent hors parent_id.

DATE/COMMIT : 2026-08-23 / checkpoint A en cours.

D-003 — Catégorie et lot facultatifs

CONTEXTE : un inventaire peut être saisi avant que le référentiel de maintenance soit complet.

OPTIONS ÉTUDIÉES : bloquer toute création sans lot ; accepter un équipement incomplet et le compléter plus tard.

CHOIX : la création reste valide sans lot (et sans catégorie dans les parcours wizard) ; un lot fourni est validé et peut déclencher la génération préventive.

JUSTIFICATION : respecter le principe de configuration progressive sans fabriquer de maintenance implicite.

CONSÉQUENCES : l'interface doit pouvoir signaler ultérieurement « Lot non renseigné » ; les relations techniques restent indépendantes.

DATE/COMMIT : 2026-08-23 / checkpoint A.

D-004 — Versionnement du checkpoint A

CONTEXTE : le chantier interdit 0.1.0-dev.13 et demande des versions correspondant à des checkpoints réellement validés.

CHOIX : le checkpoint A validé passe de 0.1.0-dev.12 à 0.2.0-dev.1 ; B, C, D et E restent séparés.

JUSTIFICATION : la création Equipment est consolidée et testée sans nouvelle régression ; les erreurs restantes sont exactement la baseline historique.

CONSÉQUENCES : Docker doit être reconstruit avec la nouvelle version ; aucune migration n'est ajoutée au checkpoint A.

DATE/COMMIT : 2026-08-23 / version commit.

D-002 — Durée d'intervention inconnue

CONTEXTE : Intervention.effective_estimated_duration retournait silencieusement 60 minutes.

CHOIX : retourner 0 si aucune estimation ou moyenne historique n'existe ; DayPlanner affiche alors une tâche sans durée à renseigner.

JUSTIFICATION : ne pas présenter une estimation arbitraire comme une contrainte métier.

CONSÉQUENCES : les statistiques historiques restent inchangées ; les workflows doivent renseigner les interventions planifiables.