Lot 1 bis — Écran « Activités » et synchronisation par module
02/10/2026. Séquence L1-5 du plan d’alignement, d’après la note d’amendement (AM-04, AM-05, P2). Écart ouvert : EC-111.
- Un écran, deux vues (
/activites, menu Administration, visible de tous en lecture) :- Mes activités : les activités de la filière proposées à l’organisation, avec leur état, leurs sous-activités, les sites où l’activité est déclarée à part, et les fonctions qu’elles ouvrent. Qui détient
modules.managepeut activer ou désactiver (motif obligatoire, cascade annoncée avant confirmation). Les refus viennent de l’API (garde-fous, dépendances), l’écran n’ajoute aucune règle. - Vue d’ensemble : parcours conceptuel de la filière, de la parcelle au conteneur. Une colonne par activité de premier niveau, ses sous-activités (pastilles obligatoire, critique, sous-traitable, à valider), les fonctions et écrans qu’elle ouvre. Pointillé : l’élément existe dans la filière mais n’est pas activé chez l’organisation.
- Mes activités : les activités de la filière proposées à l’organisation, avec leur état, leurs sous-activités, les sites où l’activité est déclarée à part, et les fonctions qu’elles ouvrent. Qui détient
- P2 respecté : plus aucun mot « pack » à l’écran (« Filière figée », « Filière d’origine »), et « module » ne s’affiche pas ; on parle d’activités et de fonctions.
- Symbole + libellé pour chaque état (● ○ ◐), jamais de couleur seule, pas de vert.
- Synchronisation filtrée par module : un compartiment
module_membres_foncierne descend producteurs, parcelles, zones, versions de polygone et soldes de capacité que pour les agents affectés quand le module est actif. Module désactivé : le compartiment se vide.
Fichiers : apps/backoffice/src/pages/Activites.tsx (page), activites-vue.ts (mise en forme pure : hiérarchie de l’arbre, descendants pour la cascade, activités proposées, fonctions d’une activité, écrans d’un module d’après les manifestes). Client : listerActivites, changerEtatActivite, lireArbreActivites, initialiserArbreActivites, changerEtatNoeud, listerModules, changerEtatModule. Routes d’API : celles de L0-2 et L1-4, sans nouvelle route (contrat 1.16.0).
Menu : l’entrée grisée « Packs filières » devient « Activités ». /activites est déclaré dans les écrans du noyau (manifestes.ts).
Synchronisation
Section intitulée « Synchronisation »Migration db/migrations/20261004100000_lot1bis_perimetre_module.sql.
| Objet | Rôle |
|---|---|
app.perimetre_module_agent |
Une ligne par agent affecté (affectation en cours), par groupement et par module actif. Donnée dérivée, publiée, lisible par PowerSync |
app.recalculer_perimetre_module(org) |
Recalcule une organisation sans toucher aux lignes inchangées (pas de bruit de synchronisation) ; définisseur, borné à l’organisation |
| déclencheurs | Après un changement d’affectation ou d’activation de module |
Pourquoi une table : une règle de synchronisation ne sait ni joindre, ni appeler app.module_actif, ni lire une vue.
Règles : infra/powersync/sync-config.yaml, compartiment module_membres_foncier (paramètre : app.perimetre_module_agent). Le périmètre de l’agent garde le groupement et les statuts de conformité. Collecte et SCI n’ont pas de table descendue : aucun compartiment n’est créé pour eux.
Voir Lot 1 — synchronisation. Remesuré en L1-5 avec le nouveau compartiment : 4,56 Mo pour le plus gros groupement et 11,38 Mo dans le pire cas (budget 20 Mo tenu ; la répartition en compartiments ne change pas le volume, une organisation sans le module descend moins).
apps/backoffice:activites-vue.test.ts(6),navigation.test.ts(entrée Activités).db/tests/l1bis-5.sql: périmètre par module (activation, nouvelle affectation, affectation terminée, désactivation, isolation).infra/powersync/regles.test.mjs: structure du nouveau compartiment, module désactivé, module absent.