80 lines
3.4 KiB
Markdown
80 lines
3.4 KiB
Markdown
# 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.
|