--- title: "Réorganisation PKM SilverBullet — Plan" tags: [plan, pkm, silverbullet, migration] type: plan projects: - "[[02_PROJETS/MIGRATION-PKM-2026]]" status: draft date: "2026-10-11" --- # Réorganisation PKM SilverBullet (shizendo) — Plan d'action > Document de planification. À valider avant toute migration. > Structure cible + frontmatter final + ordre de migration. > Exécution détaillée étape par étape : voir `80_CONFIG/PLAN_PKM_Execution.md`. > Version du 11/10/2026 --- ## 1. Objectif & principes - Passer d'une organisation **par dossier de domaine** (`02_DOMAINS/PRO|PERSO|AMM`) à une organisation **à plat**, où le domaine est porté par l'attribut `area` du frontmatter. - Les requêtes deviennent indépendantes des chemins : - Avant : `p.name.startsWith("02_DOMAINS/PERSO/PROJETS/")` - Après : `p.area == 'perso' and p.type == 'project'` - Frontmatter **significatif mais léger** : uniquement des attributs utiles aux requêtes. - **`priority` est un attribut réservé de SilverBullet** (sert au tri des pages) → **le conserver tel quel** ; pour la priorité métier, utiliser `urgence`. - **Documentation projet** : gérée par `type: note` + `nature: documentation` + `projects`, pas par une arborescence `PROJET-A/Documentation/`. - **Tâches simplifiées** : `* [ ]` / `* [x]` + tags d'état (`#URGENT`, `#waiting`…), au lieu des états `[STATE]` multiples. --- ## 2. Structure cible (arborescence plate) ``` ├── 00_INBOX/ ├── 01_JOURNAL/ │ ├── 2025/ │ ├── 2026/ │ ├── Meetings/ ← ex. 02_DOMAINS/PRO/EVENTS (comptes-rendus) │ └── Weeks/ ← ex. 01_JOURNAL/Weekly ├── 02_PROJETS/ ← ex. 02_DOMAINS/*/PROJETS (projets à plat) ├── 03_NOTES/ ← ex. 02_DOMAINS/*/NOTES + BOOKS + RESSOURCES/LIEUX + docs projets │ └── LIEUX/ ← ex. 03_RESSOURCES/LIEUX ├── 04_CODES/ ← ex. 02_DOMAINS/*/CODES ├── 05_CONTACTS/ ← ex. 02_DOMAINS/*/CONTACTS ├── 80_CONFIG/ ├── 90_ARCHIVES/ │ ├── index.md ← fusion Home + Index + Dashboard (dashboard général) ├── TDB_PRO.md ← tableau de bord domaine Pro ├── TDB_PERSO.md ← tableau de bord domaine Perso └── TDB_AMM.md ← tableau de bord domaine AMM ``` **Notes de structure :** - **Pas d'emojis dans les noms de fichiers** (robustesse liens/scripts/sync). Les emojis vivent dans les **alias d'affichage** et les titres H1. - `01_JOURNAL` garde l'année en sous-dossier (`2026/`), plus `Meetings/` et `Weeks/`. - `02_PROJETS` : **projets à plat** (décidé) — chaque page projet directement dans `02_PROJETS/`, la documentation étant rattachée par `nature: documentation` + `projects` (pas de sous-dossier). - `03_NOTES` : accueille NOTES (tous domaines), BOOKS (PERSO), `LIEUX/` (ex. RESSOURCES) et la **documentation des projets** (`nature: documentation`). - `04_CODES` : regroupe PRO/PERSO/AMM CODES. - `05_CONTACTS` : regroupe PRO/PERSO/AMM CONTACTS. - `00_INBOX`, `80_CONFIG`, `90_ARCHIVES` : inchangés. --- ## 3. Frontmatter final ### Projet (`type: project`) ```yaml --- type: project tags: projet univers: PRO axe: "PILOTAGE" # Libre, enrichi avec le temps ; listes différentes pro/perso status: active # Options : active, in-progress, closed, draft urgence: "normale" # Options : haute, normale, basse title: "" aliases: [""] start: "[[01_JOURNAL/${os.date('%Y')}/${os.date('%Y-%m-%d')}]]" end: "" review: "" --- ``` > **Changements vs proposition initiale :** suppression de `date` ; `start` auto-initialisé (lien journal), `end`/`review` **vides** (pas la date de création). `priority` (réservé SilverBullet) est **conservé**. ### Note (`type: note`) ```yaml --- type: "note" tags: note nature: info # Options : portrait, lieu, info, concept, script, process, tuto, book, documentation, none ressource: false # Options : true, false — marque une note comme ressource (ex. documentation de projet) univers: PRO axe: none status: active # Options : active, in-progress, closed, draft projects: - "[[PROJET]]" # liste → multi-projets date: "[[01_JOURNAL/${os.date('%Y')}/${os.date('%Y-%m-%d')}]]" --- ``` > `nature: book` ajouté pour l'accueil des BOOKS (ex. PERSO) dans `03_NOTES`. > `nature: documentation` ajouté pour la documentation de projet (voir §3bis). ### Tableau de bord (`type: tdb`) ```yaml --- type: tdb univers: PRO status: active date: "[[01_JOURNAL/${os.date('%Y')}/${os.date('%Y-%m-%d')}]]" --- ``` > Homogénéité : `area` (pas `domain`) pour rester cohérent avec les autres types. ### En-tête des fichiers TDB (menu de navigation) ``` [[index|🏠 Index]] | [[TDB_PRO|💼 Pro]] | [[TDB_PERSO|🌱 Perso]] | [[TDB_AMM|🥋 AMM]] ``` > Syntaxe corrigée : **nom de page sans extension, sans slash initial** (convention SilverBullet `[[page|alias]]`), cohérente avec les liens existants (`[[02_DOMAINS/PRO/PROJETS/NEWSLETTER]]`). --- ## 3bis. Documentation de projet **Principe :** une note de documentation est une note classique (`type: note`) avec `nature: documentation`, rattachée à un ou plusieurs projets via l'attribut `projects` (liste). Aucune arborescence spécifique : tout vit dans `03_NOTES/`. ```yaml --- type: "note" tags: note nature: documentation # marque la note comme documentation ressource: true # la documentation est une ressource du projet univers: PRO status: active projects: - "[[COTEC-DGE-2026-02]]" date: "[[01_JOURNAL/${os.date('%Y')}/${os.date('%Y-%m-%d')}]]" --- ``` **Affichage dans la page Projet** — requête à insérer dans la page du projet (remplace une arborescence `PROJET-A/Documentation/`) : ``` {query[[ from p = index.tag "page" where p.type == "note" and p.nature == "documentation" and table.includes(p.projects, "[[" .. _CTX.currentPage.name .. "]]") order by p.lastModified desc select { DOCUMENTATION = "[[" .. p.ref .. "]]", MODIFIED = p.lastModified } ]]} ``` **Alternatives retenues dans le plan :** - **Option A — nouveau type :** `type: documentation` (au lieu de `type: note` + `nature`). Requête `p.type == 'documentation'`. Plus explicite mais ajoute un type distinct. - **Option B — nature (recommandée) :** `type: note` + `nature: documentation`, comme ci-dessus. Reste dans le système `nature` existant, une seule famille de notes, requêtes homogènes. - Le marquage `ressource: true` permet en complément de la distinguer dans les listes de ressources. **Décision :** **Option B** retenue (2026-10-11) — `type: note` + `nature: documentation`. --- ## 4. Gestion des événements (par semaine) - **Saisie** : les `#event` avec `[date: YYYY-MM-DD]` et `[hour: HHhMM/...]` restent dans la **page hebdo** (`01_JOURNAL/Weeks/YYYY-WNN`). - **Vision transversale** : requête dynamique dans la page hebdo listant les événements de la semaine (pattern existant du skill `week-to-days`). - **Requêtes dans les pages journalières** : affichage des événements du jour via `t.date == _CTX.currentPage.date` (les attributs `[date:]`/`[hour:]` **doivent être conservés**). - **Comptes-rendus de réunion** : déplacés dans `01_JOURNAL/Meetings/` (ex. `20261008_15h30_NOM-PROJET_Sujet`), suffixe `_Synthese` conservé. --- ## 5. Gestion des tâches (par jour) — format simplifié **Saisie** : directement dans la **page du jour** (`01_JOURNAL/YYYY/YYYY-MM-DD`). ### Nouveau format : `* [ ]` / `* [x]` + tags | Avant | Après | |---|---| | `* [TODO] [[PROJET]] - Tâche [date: ...] #URGENT` | `* [ ] [[PROJET]] - Tâche [date: ...] #URGENT` | | `* [DONE] [[PROJET]] - Tâche` | `* [x] [[PROJET]] - Tâche` | | `* [WAITING] [[PROJET]] - Tâche` | `* [ ] [[PROJET]] - Tâche #waiting` | | `* [PLANNED] [[PROJET]] - Tâche` | `* [ ] [[PROJET]] - Tâche #planned` | | `* [REVIEW] [[PROJET]] - Tâche` | `* [ ] [[PROJET]] - Tâche #review` | | `* [DUPLICATE] / [MISSING] / [ABORTED]` | `[x] #duplicate` / `#missing` / `#aborted` (ou suppression) | **Règles :** - **`[x]` = fait** (`done: true`), **`[ ]` = à faire** — format natif SilverBullet (`index.tasks()`), `.done` fonctionne tel quel. - **Conserver `[date:]` et `[hour:]`** : ils alimentent le journal et `week-to-days`. - Les **états deviennent des tags** : `#URGENT` (déjà en place), `#waiting`, `#planned`, `#review`… - Les requêtes existantes **continuent de fonctionner** : `index.tasks('URGENT')`, `not i.done`, `table.includes(i.tags, 'next')`, `index.tasks('event')`. ### Page hebdo - La requête de tâches **n'est pas obligatoire** ; privilégier les **liens vers les projets importants de la semaine** (déjà en place via « Priorités de la semaine »). --- ## 6. Ordre de migration > Outil clé : **`rename_note` du MCP silverbullet-ai** → renomme un fichier **et met à jour automatiquement tous les backlinks** de l'espace. À privilégier pour chaque déplacement (un déplacement = un renommage du chemin complet). ### Phase 0 — Décisions préalables ✅ (tranchées le 2026-10-11) - [x] Projets : **à plat** — chaque page projet est directement rattachée au dossier `02_PROJETS`. - [x] `axe` : valeur par défaut **`none`** ; la liste des valeurs sera complétée au fur et à mesure et documentée. - [x] Page d'accueil : nouveau nom **`index.md`**. - [x] Documentation projet : **Option B** (`type: note` + `nature: documentation`). - [x] Réorganisation : **manuelle au départ**, puis application sur les points les plus problématiques. - [x] Compléments d'exécution (2026-10-11) : `area: WORK` → `pro` ; BOOKS → `type: note` + `nature: book` ; tâches `ABORTED/DUPLICATE/MISSING` → `[x]` + tag ; `AI Chat` supprimé conservé ; doublon webp orphelin supprimé + lien corrigé. ### Phase 1 — Pages racine & hubs - [ ] Créer `index.md` : fusionner le contenu de `Home.md` + `Index.md` + `Dashboard.md` (requêtes TODO/projets/quick notes). Archiver les 3 anciennes. - [ ] Créer `TDB_PRO.md`, `TDB_PERSO.md`, `TDB_AMM.md` avec le menu de navigation et les requêtes par `area`. - [ ] Créer les dossiers cibles vides (`02_PROJETS`, `03_NOTES`, `04_CODES`, `05_CONTACTS`, `01_JOURNAL/Meetings`, `01_JOURNAL/Weeks`). ### Phase 2 — Journal - [ ] Renommer `01_JOURNAL/Weekly` → `01_JOURNAL/Weeks` (via `rename_note` sur chaque page `YYYY-WNN`). - [ ] Déplacer les comptes-rendus `02_DOMAINS/PRO/EVENTS/YYYY/*` → `01_JOURNAL/Meetings/`. - [ ] **Convertir les tâches** dans les pages du jour et les pages hebdo : `[STATE]` → `[ ]`/`[x]` + tags (voir §5). ### Phase 3 — Domaine PRO - [ ] `02_DOMAINS/PRO/PROJETS/*` → `02_PROJETS/` (renommage chemin complet, backlinks auto). - [ ] `02_DOMAINS/PRO/NOTES/*` → `03_NOTES/`. - [ ] `02_DOMAINS/PRO/CONTACTS/*` → `05_CONTACTS/`. - [ ] `02_DOMAINS/PRO/CODES` → `04_CODES/`. - [ ] Mettre à jour le frontmatter de chaque page déplacée (ajout `area`, `urgence`, `axe`, `nature` si pertinent ; `priority` conservé). - [ ] Marquer la documentation existante : `nature: documentation` (+ `ressource: true`) et `projects` renseignés. - [ ] Ajouter la requête « Documentation » dans les pages projets concernées (voir §3bis). ### Phase 4 — Domaine PERSO - [ ] `02_DOMAINS/PERSO/PROJETS/*` → `02_PROJETS/`. - [ ] `02_DOMAINS/PERSO/NOTES/*` → `03_NOTES/`. - [ ] `02_DOMAINS/PERSO/BOOKS/*` → `03_NOTES/` avec `nature: book`. - [ ] `02_DOMAINS/PERSO/CONTACTS/*` → `05_CONTACTS/`. - [ ] `02_DOMAINS/PERSO/CODES/*` → `04_CODES/`. - [ ] Frontmatter à jour (idem Phase 3) + documentation marquée. ### Phase 5 — Domaine AMM - [ ] Idem : PROJETS → `02_PROJETS/`, NOTES → `03_NOTES/`, CODES → `04_CODES/`. ### Phase 6 — Ressources & migration transverse - [ ] `03_RESSOURCES/LIEUX/*` → `03_NOTES/LIEUX/` (note + images webp associées). - [ ] Renommer `03_RESSOURCES` si vidé. - [ ] **Conversion globale des tâches** restantes (`[TODO]`, `[DONE]`, `[WAITING]`…) dans toutes les pages : recherche + remplacement (voir §5). ### Phase 7 — Requêtes, templates & skills - [ ] Mettre à jour les requêtes par chemin → requêtes par `area` dans `index.md`, TDB, pages projets (`TaskManager`), `Todo.md`. - [ ] Mettre à jour les templates : `80_CONFIG/Slash/day-template`, template hebdo, template projet, template note. - [ ] **Template projet** : ajouter la section « Documentation » (requête §3bis). - [ ] **Mettre à jour les skills côté SilverBullet** (`80_CONFIG/IA_SKILLS/`), puis resync OpenCode : - `Synthese-Reunion` : chemin `02_DOMAINS/PRO/EVENTS/...` → `01_JOURNAL/Meetings/...` **et** format des actions `* [STATUS]` → `* [ ]` (suffixe `_Synthese` conservé). - `Week-To-Days` : `01_JOURNAL/Weekly/` → `01_JOURNAL/Weeks/` **et** gestion des tâches `[STATE]` → `[ ]`/`[x]`. - `Silverbullet-Conventions` : documenter la nouvelle arborescence + frontmatter + format tâches + type documentation. - `Silverbullet-Api` : vérifier si des chemins sont référencés. ### Phase 8 — Archivage & vérification - [ ] Déplacer les anciens dossiers vides / résiduels vers `90_ARCHIVES` (ou suppression après validation). - [ ] Vérification : plus aucun lien `[[02_DOMAINS/...]]` cassé (recherche), requêtes OK, backlinks mis à jour. - [ ] Vérifier qu'aucune tâche `[STATE]` (ancien format) ne subsiste (recherche `[TODO]`, `[DONE]`, `[WAITING]`, `[PLANNED]`, `[REVIEW]`, `[DUPLICATE]`, `[MISSING]`, `[ABORTED]`). --- ## 7. Outils MCP SilverBullet mobilisés | Outil | Usage | |---|---| | `rename_note` | Déplacement + mise à jour automatique des backlinks (outil principal) | | `create_note` | Création `index`, TDB, dossiers/pages cibles | | `update_note` / `search_replace` | Mise à jour contenu (requêtes, menus, conversion tâches) | | `update_frontmatter` | Ajustement frontmatter des pages déplacées (`nature`, `projects`, `area`…) | | `read_note` / `list_pages` / `eval_lua` | Vérification avant/après | --- ## 8. Points ouverts (à trancher avant migration) 1. Rythme : par domaine (recommandé) vs tout d'un coup. 2. Destinataire des anciennes pages racine (`Home`, `Dashboard`) : fusion + archive. 3. Sort des tâches `DUPLICATE`/`MISSING`/`ABORTED` : suppression ou `[x]` + tag. 4. Valeurs initiales de `axe` (pro : Pilotage, Animation, Communication… ; perso : Maison, Voiture, Animaux…) — à documenter au fil de l'eau. --- ## 9. Risques & mitigations | Risque | Mitigation | |---|---| | Liens cassés `[[02_DOMAINS/...]]` | `rename_note` met à jour les backlinks ; vérifier ensuite par recherche | | Requêtes existantes par chemin | Migration des requêtes en Phase 7, en parallèle des déplacements | | Skills obsolètes (chemins + format tâches) | Mise à jour SilverBullet + resync OpenCode (Phase 7) | | `priority` (réservé SilverBullet) | **Conservé** (tri des pages) ; priorité métier portée par `urgence` | | Tâches `[STATE]` résiduelles | Conversion globale en Phase 6 + vérification finale Phase 8 | | Volume (≈486 fichiers) | Migration par domaine, phases courtes, vérifications à chaque phase |