160 lines
17 KiB
Markdown
160 lines
17 KiB
Markdown
# Assistant V2.1 ObsiGate — Phase 5 : L'extension (packs de domaines et évaluation continue)
|
||
|
||
| Champ | Valeur |
|
||
|---|---|
|
||
| Phase | **5 sur 5** — optionnelle et étalée : le cœur (phases 0–4) est complet sans elle |
|
||
| Document parent | `ASSISTANT-V2.1.md` — en particulier §13.4 (packs de domaines), §16 (évaluation & observabilité), §20 (risque « périmètre qui grandit sans fin ») |
|
||
| Version | 1.0 — 9 octobre 2026 |
|
||
| Auteur | Spark, pour Bruno |
|
||
| Statut | Cadre prêt ; chaque chantier s'active séparément, à la demande de Bruno |
|
||
| Tranches | **#210** (packs de domaines, chantiers A–G), **#212** (évaluation & observabilité — volet continu, chantier H) |
|
||
| Effort estimé | 3–5 jours **par chantier de pack**, étalés ; chantier H : 2–3 jours puis continu |
|
||
| Prérequis | Phases 0–4 terminées pour les chantiers qui consomment connecteurs, personnes et automatisations ; les chantiers A et F sont possibles dès la phase 2 |
|
||
| Dépendances | #210 ← #208 (+ phase 3 pour B, C partiellement, E ; + phase 4 pour C et les relances) ; #212 ← amorce de la phase 0, puis toutes les phases |
|
||
| Débloque | Rien : c'est la phase d'extension. Chaque chantier terminé enrichit l'assistant sans rien débloquer d'obligatoire |
|
||
|
||
> **Résultat visible à la fin de chaque chantier.** Un domaine de vie de plus est couvert de bout en bout par l'assistant — pas par un nouveau moteur, mais par l'assemblage curé de ce qui existe : des **recettes** (automatisations et plans), des **procédures** (la façon de Bruno de faire les choses, en mémoire), des **skills** et ses **golden tasks** propres. Un pack ne s'active qu'à la demande, se désactive sans laisser de trace dans le quotidien, et prouve son utilité par ses scénarios avant d'être livré. Le chantier H (#212) court en parallèle de toute la phase : le corpus de golden tasks grandit, les métriques du centre de contrôle deviennent des revues périodiques, et le routage de modèles s'affine sur données réelles.
|
||
|
||
---
|
||
|
||
## Table des matières
|
||
|
||
1. [Objectif et principe directeur](#1-objectif-et-principe-directeur)
|
||
2. [Ce qu'est un pack — anatomie et gouvernance](#2-ce-quest-un-pack--anatomie-et-gouvernance)
|
||
3. [État d'entrée](#3-état-dentrée)
|
||
4. [Chantiers de packs — #210](#4-chantiers-de-packs--210)
|
||
5. [Chantier H — Évaluation & observabilité continues — #212](#5-chantier-h--évaluation--observabilité-continues--212)
|
||
6. [Critères d'acceptation de la phase](#6-critères-dacceptation-de-la-phase)
|
||
7. [Risques spécifiques et vigilance](#7-risques-spécifiques-et-vigilance)
|
||
8. [Ordre d'exécution suggéré](#8-ordre-dexécution-suggéré)
|
||
9. [Définition de « terminé »](#9-définition-de--terminé-)
|
||
|
||
---
|
||
|
||
## 1. Objectif et principe directeur
|
||
|
||
Le principe : **« maximum de tâches » s'atteint par assemblage, pas par accumulation de moteurs.** Le cœur des phases 0–4 (mémoire, tâches, plan, exécution fiable, connecteurs, automatisations, personnes) est générique à dessein ; la valeur d'un domaine — voyages, argent, apprentissage — tient à ses recettes, ses procédures et ses critères de qualité, pas à du code nouveau. La phase 5 est donc organisée en **chantiers indépendants et optionnels**, sur le modèle de la phase d'extension des documents Agents & Skills : aucun chantier n'est un prérequis d'un autre (hors dépendances notées), chacun a ses critères de sortie, et la phase n'a pas de « fin » obligée.
|
||
|
||
Deux garde-fous contre la dispersion (risque nommé au parent §20) :
|
||
|
||
- **Un pack = un chantier, un chantier = une livraison.** Pas de pack « à moitié activé » : recettes, procédures, skills et golden tasks arrivent ensemble, ou le chantier n'est pas terminé.
|
||
- **La désactivation est un non-événement.** Retirer un pack retire ses recettes actives et ses skills des menus ; les notes, tâches et faits créés restent (ce sont des données de Bruno, pas du pack).
|
||
|
||
## 2. Ce qu'est un pack — anatomie et gouvernance
|
||
|
||
| Composant | Forme | Exemple |
|
||
|---|---|---|
|
||
| Recettes | Automatisations et plans pré-remplis (phase 2), activables une à une | « Veille de prix hebdomadaire » |
|
||
| Procédures | Faits `kind='procedure'` livrés avec le pack, **modifiables** (mémoire phase 0) | « Un dossier de voyage contient : itinéraire, documents, contacts, budget » |
|
||
| Skills | Skills `/` existants ou nouveaux, dans le format actuel (`data/skills.json` et skills intégrés) | `/voyage-prep` |
|
||
| Modèles de notes | Notes modèles dans le vault (listes, checklists, tableaux) | Checklist d'entretien maison par saison |
|
||
| Golden tasks | Scénarios du domaine, ajoutés au corpus (chantier H) | 2–4 par pack, bloquants pour la livraison du chantier |
|
||
| Réglages | Niveau d'autonomie par défaut proposé (jamais imposé), budgets propres éventuels | Pack Voyages : niveau 1 par défaut (lecture) |
|
||
|
||
Gouvernance : un registre simple des packs (installé/activé/désactivé) dans les Configurations, section Assistant ; l'activation affiche **tout** ce que le pack ajoutera (recettes avec leurs déclencheurs, procédures avec leur texte, skills) avant confirmation — même exigence de transparence que pour une automatisation importée (parent §15.1). Aucun pack ne peut élever un niveau d'autonomie ni créer une délégation : il *propose*, les mécanismes des phases 0–1 disposent.
|
||
|
||
## 3. État d'entrée
|
||
|
||
Tout ce que les phases 0–4 ont livré, et en particulier : le catalogue d'outils existants bien plus riche que le seul périmètre assistant (documents docx/xlsx/csv/pdf et outils tableurs complets — lecture, recherche, analyse de plages, édition — décrits dans les guides `ASSISTANT_IA_FORGE` et `RECHERCHE_PDF_EXCALIDRAW`), les skills d'apprentissage déjà intégrés (`/quiz`, `/reading-note`, `/qa-generator`…), la recherche et le Deep Research, `fetch_url`/`crawl_site`, les connecteurs Gitea/GitHub migrés au cadre (phase 3), les automatisations et le bus (phase 2), les personnes et engagements (phase 4). Plusieurs chantiers ci-dessous ne demandent **aucun nouvel outil** — c'est un critère de conception, pas un hasard.
|
||
|
||
## 4. Chantiers de packs — #210
|
||
|
||
*Convention : chaque chantier est décrit par son contenu (recettes/procédures/skills), ses dépendances propres, 1 exemple de golden task et ses critères de sortie spécifiques. L'effort type est de 3–5 jours, presque entièrement en contenu et en tests, pas en moteur.*
|
||
|
||
### Chantier A — Connaissance & veilles avancées
|
||
|
||
Contenu : recettes de veille multi-sources (page web + recherche périodique sur un sujet → note de diff dans le vault, insight seulement si changement matériel) ; synthèse de dossier à la demande (« tout ce que j'ai sur X, et ce qui a changé depuis <date> ») en skill assemblant recherche vault, Notion synchronisée (phase 3) et mémoire ; revue de lecture hebdomadaire depuis l'inbox (items `url` non triés > 7 j proposés en lot : lire/résumer/archiver).
|
||
Dépendances : phases 0–2 (3 pour la source Notion).
|
||
Golden task (exemple) : une page fixture modifiée entre deux veilles produit exactement une note de diff citant l'ancien et le nouveau contenu ; inchangée, elle ne produit rien.
|
||
Sortie : les trois recettes fonctionnent sur fixtures ; aucun nouvel outil créé.
|
||
|
||
### Chantier B — Documents & données du quotidien
|
||
|
||
Contenu : procédures et recettes sur les outils **existants** (documents et tableurs) : classeur de budget personnel (modèle xlsx + recette mensuelle « importer un relevé csv déposé dans le vault → catégoriser selon la procédure de Bruno → mettre à jour le classeur → rapport d'écarts en note ») ; génération de documents récurrents (attestations, courriers types) depuis des modèles de notes et des faits mémoire ; extraction de tableaux de PDF du vault vers des notes.
|
||
Dépendances : phases 0–2 ; relevés = fichiers déposés par Bruno (aucune connexion bancaire, voir chantier D).
|
||
Golden task : un relevé fixture de 30 lignes est catégorisé selon la procédure, avec les lignes ambiguës en carte — jamais devinées.
|
||
Sortie : le rapport mensuel complet est produisible par une recette dry-runée puis activée.
|
||
|
||
### Chantier C — Maison & administration personnelle
|
||
|
||
Contenu : modèle d'entretien récurrent (tâches RRULE par équipement, notes d'interventions liées) ; démarches suivies (renouvellements, garanties, assurances) comme engagements envers soi avec échéances et documents rassemblés ; listes vivantes (courses, cadeaux — alimentées par l'inbox et les personnes de la phase 4 : anniversaires → propositions) ; rappels saisonniers en recettes.
|
||
Dépendances : phases 1, 2, 4 (anniversaires et cadeaux) ; phase 3 optionnelle (échéances lues dans les courriels candidats).
|
||
Golden task : la garantie d'un équipement arrivant à échéance dans 30 j produit une tâche datée avec le document lié, sans notification directe (revue).
|
||
Sortie : le dossier « Maison » du vault de test est entièrement tenu par les recettes du pack pendant un mois simulé.
|
||
|
||
### Chantier D — Argent en lecture seule
|
||
|
||
Contenu : **strictement** la lecture et l'analyse de données que Bruno dépose (relevés csv/xlsx, exports) : catégorisation (procédure du chantier B réutilisée), budgets par enveloppe en notes, alertes d'échéances de factures détectées dans les notes et les courriels candidats, synthèse mensuelle. Aucun accès bancaire direct, aucun paiement, aucune initiation de virement — ces exclusions sont **structurelles** (aucun outil du pack n'a de capability d'écriture externe) et rappelées dans la fiche du pack.
|
||
Dépendances : chantier B ; phase 3 pour les candidats courriels.
|
||
Golden task : une facture fixture échue non payée (selon les notes) apparaît en revue avec sa source ; une facture payée n'y apparaît pas.
|
||
Sortie : la synthèse mensuelle d'un mois fixture est exacte au centime sur les lignes non ambiguës, et les ambiguës sont listées à part.
|
||
|
||
### Chantier E — Voyages
|
||
|
||
Contenu : procédure « dossier de voyage » (itinéraire, documents, contacts sur place, budget, contraintes) ; recettes : préparation (checklist générée depuis la procédure et les dates, documents rassemblés depuis le vault et Drive), rappels décalés par fuseau (le moteur RRULE/heure murale des phases 1–2, appliqué au fuseau de destination pour les rappels « sur place »), briefing de départ (agenda, documents, engagements en suspens pendant l'absence), retour (dépenses déposées → chantier D, photos/notes → dossier).
|
||
Dépendances : phases 1–4 (agenda réel et Drive en phase 3 fortement recommandés).
|
||
Golden task : un voyage fixture sur 2 fuseaux produit des rappels aux heures murales correctes dans chaque fuseau, affichés avec leur heure d'origine (règle de la phase 3 §7.2).
|
||
Sortie : le dossier complet d'un voyage de test est produit par les recettes, sans intervention de code.
|
||
|
||
### Chantier F — Apprentissage
|
||
|
||
Contenu : assemblage des skills **existants** (`/quiz`, `/reading-note`, `/qa-generator`, `/summary-progressive`) avec les habitudes (phase 2) et la mémoire : parcours de lecture d'un dossier (ordre proposé, fiches générées dans le vault, quiz espacés en tâches récurrentes liées à l'objectif), revue d'apprentissage mensuelle (ce qui est su, mesuré par les quiz, pas déclaré).
|
||
Dépendances : phases 0–2 seulement — chantier livrable tôt.
|
||
Golden task : un chapitre fixture produit des fiches et un quiz ; les réponses du quiz mettent à jour le suivi sans toucher aux notes sources.
|
||
Sortie : un parcours complet sur un dossier de test, de la première fiche à la revue mensuelle.
|
||
|
||
### Chantier G — Synchronisation de tâches externe (option conditionnelle)
|
||
|
||
Contenu : **seulement si** Bruno tranche la décision ouverte n° 4 du parent en faveur d'un gestionnaire externe (Todoist ou équivalent) : connecteur du cadre (phase 3) en synchronisation bidirectionnelle avec le vault **source de vérité** (règles du parent §11.5 : tâches synchronisées marquées `source='connector'` + id externe ; conflit = modification la plus récente gagne, journalisée et visible) ; la vue Aujourd'hui et le plan continuent de lire l'index local.
|
||
Dépendances : phases 1, 3 ; décision de Bruno.
|
||
Golden task : la même tâche modifiée des deux côtés pendant une coupure se résout selon la règle, avec le conflit visible dans le journal — jamais de perte silencieuse.
|
||
Sortie : une semaine d'usage simulé sans divergence d'index ; la désactivation du connecteur laisse le vault complet et autonome.
|
||
|
||
## 5. Chantier H — Évaluation & observabilité continues — #212
|
||
|
||
Ce chantier n'est pas un pack : c'est le volet continu de #212, amorcé en phase 0 (harnais + G3/G6/G7) et enrichi par chaque phase (G1/G2/G4/G5/G8 en phase 2, G9–G11 en phase 3, G12–G14 en phase 4, puis les golden tasks des packs).
|
||
|
||
**P5-H1 — Corpus vivant.** Le corpus `tests/golden/` devient une suite de référence versionnée : tout scénario qui a un jour révélé un défaut réel y entre comme test de non-régression (règle : un bug d'assistant corrigé sans golden task ajouté n'est pas « terminé »). Revue du corpus à chaque livraison de chantier : scénarios obsolètes retirés explicitement, jamais en silence.
|
||
|
||
**P5-H2 — Métriques en revues.** Les compteurs du centre de contrôle (parent §16.2 : plans tenus, runs par statut, validations de faits, acceptation des détecteurs, coût par type de run, temps de décision quotidien, interruptions vs budget) sont assemblés en **revue mensuelle automatique** (note dans `99_Assistant/Revues/`) relue avec Bruno : c'est là que se décident les ajustements de seuils, de budgets et de niveaux d'autonomie — sur données, pas sur impressions.
|
||
|
||
**P5-H3 — Routage de modèles affiné.** La table de routage par type de job (parent §16.3) est ajustée depuis les métriques : un job dont le taux de rejet/correction dépasse un seuil passe au modèle supérieur (proposition en revue mensuelle, jamais de changement silencieux de coût) ; un job à très haut volume et haute acceptation peut descendre au modèle inférieur, golden tasks du job vertes à l'appui.
|
||
|
||
**P5-H4 — Échantillon réel en lecture seule.** Avant chaque livraison de chantier, l'échantillon de scénarios sûrs (lecture seule) tourne contre l'instance réelle de Bruno ; les écarts avec la CI (données réelles vs fixtures) sont consignés dans la fiche du chantier. Aucune écriture réelle n'est jamais produite par ce mécanisme.
|
||
|
||
Critères de sortie (le chantier est « en régime » quand) : la revue mensuelle est produite et a été relue au moins deux fois ; le corpus compte les scénarios de toutes les phases livrées ; au moins un ajustement (seuil, budget ou routage) a été décidé sur la base d'une revue.
|
||
|
||
## 6. Critères d'acceptation de la phase
|
||
|
||
La phase 5 n'a pas de critère global — chaque chantier a les siens. Critères transverses, vérifiés à chaque livraison de chantier :
|
||
|
||
1. Le chantier n'a créé **aucun nouveau moteur** ; tout outil nouveau éventuel est justifié dans la fiche du chantier (par défaut : zéro).
|
||
2. Ses golden tasks sont vertes et entrées au corpus (chantier H).
|
||
3. Son activation a été précédée de l'affichage complet de ce qu'il ajoute ; sa désactivation ne supprime aucune donnée de Bruno.
|
||
4. Sa fiche `docs/features/` et son guide sont livrés (DoD commune).
|
||
|
||
## 7. Risques spécifiques et vigilance
|
||
|
||
| Risque | Vigilance |
|
||
|---|---|
|
||
| La phase devient un fourre-tout qui ne finit jamais | C'est assumé : la phase est **optionnelle et étalée** ; le produit est complet sans elle. Le risque serait l'inverse — bloquer le cœur pour un pack |
|
||
| Des packs médiocres érodent la confiance dans le cœur | La barre de livraison d'un chantier est celle des phases précédentes (golden tasks, DoD) ; un pack qui ne la passe pas ne s'active pas |
|
||
| Le chantier D (argent) glisse vers du conseil financier | Périmètre lecture/analyse uniquement ; les synthèses citent les données déposées et n'émettent ni recommandation d'achat/vente ni jugement de solvabilité — écrit dans la procédure du pack et dans sa fiche |
|
||
| La revue mensuelle (#212) devient un rituel ignoré | Elle est courte par construction (une page, chiffres et écarts seulement) et lue dans la revue de semaine existante, pas dans un nouveau rendez-vous |
|
||
|
||
## 8. Ordre d'exécution suggéré
|
||
|
||
Aucun ordre imposé. Suggestion fondée sur les dépendances et le rapport valeur/effort :
|
||
|
||
```
|
||
Dès la phase 2 : F (apprentissage — aucun connecteur requis)
|
||
Après la phase 3 : A (veilles) → B (documents & données) → D (argent, après B)
|
||
Après la phase 4 : C (maison & admin) → E (voyages)
|
||
Si décision prise : G (sync tâches externe)
|
||
En continu, dès la phase 0 : H (#212) — ses livrables propres sont en §5
|
||
```
|
||
|
||
## 9. Définition de « terminé »
|
||
|
||
Par chantier : DoD du document de phase 0 §12 + critères transverses du §6 ci-dessus. La phase 5 elle-même n'est jamais « terminée » par construction : elle se clos quand Bruno décide qu'aucun chantier restant ne vaut son effort — ce qui est un succès du découpage, pas un échec du plan.
|