Phase 2.1b — implémentation préventif et entreprises

Baseline

Version : 0.1.0-dev.10.
Commit de départ : e65e653.
Le dépôt était propre ; les services Docker local (Flask, MariaDB, Adminer) étaient démarrés et /health/ répondait.
Les tests de référence restaient 152 passed, 1 failed, 1 error ; l'échec et l'erreur historiques concernent le lookback/contexte GMAO et son teardown, hors périmètre.

Ce qui est implémenté

Durée et périmètre

LotTask expose maintenant :

duration_mode : unit, fixed ou zone ;
scope_mode : dynamic ou manual ;
executor_type : internal, external_company, department, mixed, undefined.

En mode unit, la durée d'une cible est duree_minutes × quantity. Une quantité de groupe (par exemple 30 chaises) est donc respectée. En mode fixed, la quantité ne multiplie pas le forfait. Le périmètre dynamique suit les équipements actifs du lot ; le périmètre manuel utilise la sélection explicitement enregistrée. Les tâches sans durée ont estimated_duration=0 et le statut technique needs_duration; elles ne sont pas proposées par DayPlanner comme tâches planifiées.

Les valeurs historiques ne sont pas réintroduites comme vérité : le catalogue reste idempotent et ne remplace jamais une personnalisation existante. Les propositions de durée du document de référence restent à valider métier avant d'être injectées en masse.

Espaces verts

Les zones disposent de quatre durées facultatives propres à la zone : tonte, bordures, haies et ramassage/évacuation. Elles sont éditables dans le formulaire normal d'une zone et ne créent aucune durée générique dans un lot. Le raccord automatique d'une règle de lot à ces quatre champs reste à faire dans une passe ultérieure après validation du vocabulaire des tâches espaces verts.

Entreprises et passages

Les champs existants company_id, contract_id, periodicite et jours_entre_interventions sont exposés dans la fiche de tâche, ainsi que le type d'exécutant. En revanche, le workflow complet de passage (rendez-vous, fenêtre, non-venue, date réelle, accompagnement et tableau Passages & contrôles) n'est pas encore implémenté dans cette passe. ContractVisit ne porte actuellement qu'une date obligatoire et ne peut pas représenter fidèlement les trois modes demandés sans migration métier dédiée.

Migration

h3c4d5e6f7a8_phase21b_preventive_scope.py ajoute sans perte :

les trois colonnes de qualification à lot_tasks ;
la table d'association lot_task_equipments ;
les quatre durées d'espaces verts à zones.

La migration est additive et possède un downgrade. Elle n'attribue aucun horaire, lot ou exécutant à alban.

Tests ajoutés

tests/unit/test_preventive_scope.py couvre le calcul par quantité, le forfait par cible et l'absence explicite de durée. La compilation Python et le chargement des modèles passent. La suite intégration locale est actuellement bloquée par l'erreur historique de teardown (equipment_lifecycle_events absente de la base de test), déjà présente avant cette passe.

État de validation

Cette passe est partiellement validée : la durée unitaire, le périmètre et les durées de zone ont une base persistante et une UI simple ; le workflow entreprise complet et le scénario intégral sans intervention technique restent à réaliser. Phase 2.2 non commencée.

3.4 KiB Raw Blame History Unescape Escape