--- tags: note, silverbullet, grist, organisation, pkm, v2 type: "note" nature: info # Options : portrait, lieu, info, concept, script, process, tuto, none ressource: false univers: PERSO projects: - "[[02_DOMAINES/PERSO-PKM]]" date: "[[01_JOURNAL/2026/2026-10-21]]" priority: 10 --- # Organisation du PKM SilverBullet / Grist (v2) Agent correspondant en cours de construction : [[00_INBOX/Pro/AGENT_Pkm-Manager-2]] ## 0. Principes Le système repose sur trois composants complémentaires : * **SilverBullet (SB)** : saisie rapide, rédaction et capitalisation (Markdown). * **Grist** : pilotage quotidien, suivi des actions et des décisions (données atomiques). * **OpenCode (agent `pkm-manager2`)** : pont entre les deux via MCP. Il structure, extrait et synchronise pour que l'utilisateur se concentre sur la saisie et l'action. Règles fondamentales : 1. **Une seule source de vérité par type d'information.** * Le *texte* (notes, comptes rendus, documentation) vit dans SB. * L'*état* (tâches, statuts, décisions, projets) vit dans Grist. * Une note SB n'est **jamais mise à jour après synchronisation** : c'est un historique figé. Seul Grist porte l'état des tâches. 2. **Zéro friction à la saisie.** Une quick-note n'exige aucune métadonnée. L'IA complète. 3. **L'IA propose, l'humain valide** pour tout ce qui structure le système (nouveau projet, fusion, suppression). 4. **Commencer petit.** La V1 tient en 3 tables. Le reste vient si le besoin se confirme à l'usage. ## 1. Ce qui vit dans SilverBullet ### Documents sources (entrée du workflow) Quick-notes, brouillons, notes de réunion. Ils suivent ce trajet : 1. Prise de notes à la volée (sans métadonnée obligatoire). 2. Lancement de l'agent sur la note. 3. L'agent restructure la note en synthèse : contexte/constat, informations importantes, décisions, actions. 4. L'agent propose les écritures dans Grist, les applique après validation, puis marque la note comme synchronisée. ### Documentation stabilisée Fiches de synthèse, guides, procédures. Elles résultent d'une capitalisation, rédigée directement ou produite avec l'IA. Elles ne passent pas par le workflow de synchronisation. ### Frontmatter Tout est optionnel à la création : ```yaml --- domaine: Pro # Perso | Asso | Pro (optionnel) projet: PRO-REFONTE # Code_Court du projet (optionnel) type: reunion # quick-note | reunion | brouillon (optionnel) --- ``` Après synchronisation, l'agent ajoute : ```yaml grist_sync: date: 2026-10-21 taches: [T-0123, T-0124] logs: [L-0456] ``` La présence de `grist_sync` signifie « note déjà traitée ». L'agent ne la retraite pas sans demande explicite. ## 2. Ce qui vit dans Grist ### 2.1 V1 : trois tables #### `Projets` Cadre structuré regroupant tâches et logs. Les « issues » (sujets ou problèmes à traiter) sont des sous-projets via le champ `Parent`. | Champ | Type | Remarque | |---|---|---| | `ID` | Auto | ex. PROJ-042 | | `Code_Court` | Texte unique | ex. `PRO-REFONTE`, clé de référence pour l'IA et SB | | `Nom_Projet` | Texte | | | `Domaine` | Choix | Perso, Asso, Pro | | `Axe` | Choix | Selon le domaine | | `Statut` | Choix | Actif, En attente, Archivé | | `Parent` | Référence `Projets` | Pour les issues | Un projet spécial **`INBOX`** (par domaine ou global) reçoit tout ce que l'IA ne sait pas rattacher. #### `Taches` | Champ | Type | Remarque | |---|---|---| | `ID` | Auto | ex. T-0123 | | `Titre` | Texte | Commence par un verbe | | `Projet` | Référence `Projets` | Vide = « À trier » | | `Nature` | Choix | À FAIRE, À LIRE, À SUIVRE | | `Statut` | Choix | À valider, À faire, En cours, En attente, Terminé, Annulé, Doublon | | `Horizon` | Choix | Aujourd'hui, Cette semaine, Plus tard | | `Echeance` | Date | Optionnelle (date dure uniquement) | | `Prochaine_revue` | Date | Obligatoire si `Nature = À SUIVRE` | | `Date_Terminee` | Date | Renseignée à la clôture | | `Origine` | Choix | IA, Manuel | | `Source_Ref` | Texte | Chemin de la note SB | | `Source_Id` | Texte | Identifiant d'extrait, ex. `Reunions/2026-10-21 CoPil#a2` | Notes de conception : * `Horizon` remplace la priorité Haute/Moyenne/Basse, qui finit toujours en « Haute ». C'est un arbitrage de temps, donc plus actionnable. * `Statut = À valider` : tâche proposée par l'IA, pas encore acceptée. Elle n'apparaît pas dans « Aujourd'hui ». * `Source_Id` rend la synchronisation idempotente (voir §4). #### `Logs` Informations ponctuelles qualifiées (pas de compte rendu long) : 5 à 10 lignes maximum. | Champ | Type | Remarque | |---|---|---| | `ID` | Auto | ex. L-0456 | | `Date` | Date | Date de l'information (à qualifier : création, décision, constat…) | | `Type` | Choix | Décision, Constat, Information, Point d'avancement, Réunion | | `Contenu` | Texte | 5 à 10 lignes | | `Projet` | Référence `Projets` | | | `Origine` | Choix | IA, Manuel | | `Source_Ref` | Texte | Chemin de la note SB | | `Source_Id` | Texte | Identifiant d'extrait | Le type `Réunion` permet de tracer une réunion sans table dédiée : le log renvoie vers la note SB complète. ### 2.2 Plus tard (si le besoin se confirme) * **`Evenements`** : uniquement si Grist doit porter de la planification (date, heures, lieu). Le calendrier existant reste prioritaire pour l'agenda. * **`References`** : pont vers les documents SB stables (titre, projet, mots-clés, type, chemin). À alimenter automatiquement par l'agent, sinon elle ne sera jamais tenue à jour. SB dispose déjà de sa propre recherche. ## 3. Consultation dans Grist ### Page 1 : « Aujourd'hui » (point d'entrée quotidien) Transversale, tous domaines confondus. * Tâches `Horizon = Aujourd'hui`, `Statut` ∈ {À faire, En cours}. * Tâches `Echeance` ≤ aujourd'hui + 3 jours. * Tâches `À SUIVRE` dont `Prochaine_revue` ≤ aujourd'hui. * Tâches `Horizon = Cette semaine` en seconde zone. ### Page 2 : « À trier » * Tâches sans projet ou rattachées à `INBOX`. * Tâches `Statut = À valider` (propositions de l'IA). * Logs sans projet. ### Page 3 : « Projets » * Sélecteur : `Domaine` et `Statut = Actif`. * Gauche : liste des projets filtrés. * Droite (liée à la sélection) : onglet Tâches ouvertes, onglet Logs/Décisions. ### Revue hebdomadaire (15 minutes) 1. Vider « À trier ». 2. Parcourir les projets actifs : y a-t-il une prochaine action ? 3. Revoir les tâches `En attente` et les `À SUIVRE`. 4. Repositionner les `Horizon` pour la semaine suivante. 5. Archiver les projets terminés. ## 4. Workflow OpenCode (`pkm-manager2`) ### Schéma global ``` SILVERBULLET OPENCODE GRIST Saisie en vrac ──────► 1. Lit la note + frontmatter (quick-note, réunion) 2. Identifie le projet 3. Extrait tâches / logs 4. Dédoublonne (2 niveaux) ◄──── Requêtes ciblées 5. Présente un diff │ validation ▼ Frontmatter grist_sync ◄── 6. Écrit dans Grist ───────► Taches / Logs ``` ### Étapes 1. **Lecture** : contenu et frontmatter de la note. Si `grist_sync` existe, s'arrêter et le signaler. 2. **Projet** : utiliser `projet` du frontmatter. Sinon, proposer un projet à partir des `Code_Court` actifs. En cas de doute, `INBOX`. Ne jamais créer de projet sans validation. 3. **Extraction en mémoire** : actions (→ `Taches`), décisions et faits marquants (→ `Logs`), nature réunion (→ log de type `Réunion`). 4. **Dédoublonnage à deux niveaux** : * *Déterministe* : `Source_Id` déjà présent dans Grist ? Alors l'extrait est déjà traité. * *Sémantique* : requête ciblée limitée au projet, colonnes utiles seulement, tâches ouvertes **et** tâches terminées depuis moins de 30 jours : ```sql SELECT id, Titre, Statut FROM Taches WHERE Projet = AND (Statut NOT IN ('Terminé','Annulé','Doublon') OR Date_Terminee >= date('now','-30 day')) ``` L'IA compare l'extrait uniquement à ce sous-ensemble. Elle ne lit jamais tout Grist. 5. **Diff de validation** : présenter à l'utilisateur ce qui sera créé, ignoré (doublon) ou rapproché. Rien n'est écrit avant accord. 6. **Écriture** : créer les lignes avec `Origine = IA`, `Statut = À valider` (ou `À faire` si l'utilisateur le demande), `Source_Ref`, `Source_Id`. 7. **Marquage** : ajouter `grist_sync` au frontmatter de la note, avec les identifiants créés. Pas de bloc de texte injecté dans le corps de la note. ### Modes d'utilisation de l'agent * `traiter ` : workflow complet ci-dessus. * `inbox` : traite les notes non synchronisées d'un dossier, une par une. * `revue` : prépare la revue hebdomadaire (tâches périmées, `À SUIVRE` à revoir, projets sans action). ## 5. Règles de gouvernance * Pas de suppression par l'IA : elle marque `Doublon` ou `Annulé`. * Pas de modification des tâches créées manuellement (`Origine = Manuel`) sans accord, sauf pour signaler un doublon. * Une tâche = une action concrète démarrant par un verbe. * Une information ne se saisit qu'une fois : texte long dans SB, donnée atomique dans Grist.