3.9 KiB
02 — Piloter la prévention des pertes depuis les règles
GitLab: #71
What to build: L’utilisateur crée une règle d’optimisation de prévention des pertes, l’enregistre, la déplace parmi ses préférences et constate son effet sur les congés placés et les soldes restants. La désactiver retire réellement sa priorité automatique.
Blocked by: 01 — Unifier l’évaluation et la comparaison des objectifs.
Status: ready-for-agent
Première tranche fonctionnelle du modèle commun de l’ADR 0008. Continuer la branche d’intégration du ticket 01 ; l’ajout des six préréglages aux données existantes et la mise en service sont traités au ticket 06. Les scénarios de cette tranche soumettent explicitement leurs règles.
- Proposer la famille Optimisation dans la liste existante et permettre de créer, nommer, éditer, activer, désactiver, supprimer et réordonner une règle utilisant la somme des soldes à risque non placés. Seul le mode préférence est disponible pour cette famille.
- L’édition, les résumés et les commandes utilisent le contrat du ticket 01, sont traduits et accessibles au clavier. La configuration complète est sauvegardée localement et restaurée, avec son identité, ses paramètres, son activation et sa position.
- Le calcul résout les obligations conjointement puis utilise l’ordre des préférences actives pour arbitrer les placements. Placer la prévention des pertes sous une préférence personnelle peut laisser davantage de congés à risque inutilisés ; la remonter restaure sa priorité.
- Remplacer l’exécution implicite de la prévention des pertes par l’exécution de sa configuration explicite. Mettre en place le parcours ordonné partagé des règles ; aucun objectif n’est ajouté implicitement à une requête pour compenser une règle absente ou une configuration non prise en charge.
- Une règle désactivée donne le même plan que son absence, à autres entrées identiques. Une requête sans règle active n’ajoute aucun congé, même avec des soldes à risque, et conserve les jours déclarés. Les départages par expiration et dates ne déclenchent aucun placement.
- Les quantités, disponibilités, expirations, jours éligibles et jours déclarés restent des contraintes de validité. Une configuration active incompatible ou mal formée produit une erreur d’entrée rattachable à la règle, sans devenir un conflit d’obligations ni réactiver un défaut.
- Les chemins direct et worker conservent tous les paramètres de la règle dans l’instantané du calcul. L’explication, la trace et les analyses contrefactuelles suivent le même ordre actif ; une modification ultérieure dans l’éditeur ne change pas le résultat soumis.
- Adapter les consommateurs concernés, notamment ceux qui supposent qu’une règle comporte toujours un nombre de jours à poser. L’estimation de durée reste finie et les règles existantes Si… alors… et Période restent utilisables.
- Les tests de comportement couvrent création et rechargement, déplacement au clavier, priorité inversée contre une préférence personnelle, désactivation équivalente à suppression, absence de règles, entrée invalide et passage par le worker. S’appuyer sur les suites existantes de gestion des règles, de planification et d’instantané immuable.
- Les fonctionnalités communes de cette tranche sont réutilisables par les familles des tickets 03 à 05. Ne pas conserver une exécution historique parallèle comme solution transitoire ; la série est livrée après sa validation commune.
Vérification de bout en bout : Avec un solde à risque et une préférence personnelle concurrente, déplacer la prévention des pertes, recalculer et comparer les placements et soldes ; désactiver ensuite toutes les règles et vérifier l’absence de nouveaux congés.