docs(wiki): dix-septième passe — les deux journaux peuvent être attribués au mauvais projet après un changement Un nouveau bug applicatif réel trouvé et filé cette passe, dans la même famille que les issues #33/#34/#35/#38/#39 (relire un état de singleton en direct après un await asynchrone) : - issue #40 : les deux journaux (journal de recherche brain.db, journal d'usage IA journal.db) peuvent recevoir un événement attribué au mauvais projet après un changement — HistoryService.init() implique une vraie fenêtre d'I/O asynchrone, et chaque site d'écriture relit le gestionnaire courant plutôt que de garder une référence figée. Contrairement au cas de l'indexation PDF (#38), cela ne plante pas : l'écriture réussit toujours, juste dans le mauvais journal. Trois vérifications ciblées sont revenues négatives (comportement déjà sûr, pas un bug) : le cache de undo/historique d'état de l'éditeur est entièrement vidé à chaque changement de projet (commentaire du code nommant explicitement ce risque de collision) ; les caches d'embeddings de requête et de chunk sont des fonctions pures texte→vecteur sans donnée spécifique au projet, donc sans risque de fuite ; la synchronisation Tropy reçoit son vectorStore en paramètre explicite capturé une fois, contrairement à Zotero. Autres corrections : - Features.md : quatre lacunes de complétude comblées — quatre bugs déjà filés (#19, #17/minTopicSize, #37, #38) n'étaient pas encore répercutés dans les puces correspondantes de la page. - RC3 Release Notes : #37 et #38 ajoutés à la liste des bugs trouvés depuis la sortie, en réappliquant le même critère de sévérité que la passe précédente. - Logging System : cinquième passe consécutive trouvant encore une petite incohérence interne (la section Environment Detection et l'exemple Checking Filter Status ne portaient pas la réserve « uniquement dans le process principal » déjà présente ailleurs sur la page). - Tropy Integration Guide : précision sur une connexion vectorStore non fermée à chaque changement de projet dans TropyService.init() — pas un nouveau bug en soi, déjà substantiellement couvert par les issues #29 et #34 existantes. - Archive Connectors Guide : confirmation que la clé API Europeana est globale à l'application, jamais scopée par projet — aucun risque de fuite inter-projets à ce niveau. Cluster install & build : troisième passe consécutive entièrement propre, convergence confirmée (matrice OS/architecture et intégrité des liens vers les 39 issues re-vérifiées, tout tient).

inactinique committed Jul 24, 2026

docs(wiki): seizième passe — changer de projet peut perdre des frappes non sauvegardées ou faire planter l'indexation PDF en cours Poursuite de la chasse « que se passe-t-il si on change de projet pendant une opération en cours », déjà fructueuse en passe 15 (issues #33/#34/#35). Trois nouveaux bugs applicatifs réels trouvés et filés cette passe, chacun dans un mécanisme différent qui n'avait pas encore été soumis à cet angle : - issue #37 (le plus impactant pour l'utilisateur) : changer de projet ClioDeck avec des modifications non sauvegardées dans l'éditeur les perd silencieusement, sans aucun avertissement. Le garde-fou qui protège déjà la bascule de chapitre (loadFile() vérifie isDirty et sauvegarde avant de continuer) n'a pas d'équivalent au niveau du changement de projet (loadProject() n'a aucune vérification de ce type). C'est exactement la même classe de bug déjà corrigée une fois à l'échelon du chapitre, réintroduite un niveau au-dessus. - issue #38 : l'indexation d'un PDF peut planter si l'on change de projet pendant qu'elle tourne encore — pdf-service.ts ferme inconditionnellement le vectorStore de l'ancien projet dès le début de init(), sans vérifier qu'une indexation est encore en cours. Pas de corruption inter-projets ici (le PdfIndexer garde sa bonne référence), mais l'écriture finale échoue contre une base fermée — d'autant plus atteignable que l'extraction PDF isolée (documentée en passe 14) peut prendre jusqu'à 120 secondes. - issue #39 : l'entrée de journal d'audit d'un appel d'outil MCP peut être attribuée au mauvais projet après un changement — même famille et même sévérité que l'issue #35, aucun résultat d'outil n'est affecté, seule la traçabilité de l'audit peut se tromper de projet. Confirmé aussi qu'exactement le même défaut existe une seconde fois dans le gestionnaire zotero:apply-updates — couvert par l'issue #33 existante plutôt que filé séparément, le correctif étant identique. Autres corrections : - RC3 Release Notes : nouvelle sous-section listant les bugs significatifs découverts depuis la sortie (#27, #30, #32, #33), confirmés présents dès le tag v1.0.0-rc.3 lui-même. - Logging System : incohérence interne trouvée sur une relecture complète de bout en bout — le schéma d'architecture étiquetait encore console-filter.ts « (live) » sans conditions, alors que le texte détaillé explique depuis plusieurs passes que le filtre renderer n'est en réalité jamais actif. - Features.md : le filtrage par tags multiples est en réalité en OR (n'importe quel tag sélectionné), pas en AND comme un utilisateur pourrait raisonnablement s'y attendre, et il n'existe aucun bouton pour changer de mode — précision ajoutée. Audit d'intégrité, à l'échelle du wiki entier : les 39 issues filées à ce jour ont été vérifiées une à une (numéro, état, titre) contre GitHub depuis chaque page qui les cite — aucune référence périmée, fermée ou renumérotée trouvée. Cluster install & build entièrement propre cette passe (aucune correction), converge après plusieurs passes consécutives sans trouvaille nouvelle.

inactinique committed Jul 24, 2026

docs(wiki): quatorzième passe — brain.db sans busy_timeout, course export/renumérotation, affirmation de confidentialité incomplète Deux nouveaux bugs applicatifs réels trouvés et filés cette passe : - issue #29 : aucune des quatre classes qui écrivent dans le brain.db partagé (VectorStore, PrimarySourcesVectorStore, HistoryManager, ObsidianVaultStore) ne définit de busy_timeout — seul le module Obsidian active le mode WAL. Le journal.db séparé a déjà ce correctif exact (WAL + busy_timeout=3000, avec un commentaire explicite sur l'écriture concurrente) mais il n'a jamais été appliqué au fichier partagé, qui a pourtant plus d'écrivains concurrents. Documenté dans les guides Obsidian et Tropy. - issue #30 : la renumérotation des notes à l'échelle du livre écrit chapitre par chapitre sur le disque sans verrou — un export déclenché pendant la boucle peut assembler un manuscrit à moitié renuméroté, silencieusement. Le rollback en cas d'échec protège contre les échecs internes de l'opération, pas contre une lecture concurrente par l'export. Documenté dans Books-and-Chapters. Autres corrections : - Build and Deployment Guide : l'affirmation de confidentialité « aucune donnée envoyée sauf Zotero » se contredisait avec la phrase juste au-dessus mentionnant les fournisseurs cloud — réécrite pour lister les trois catégories réelles de sortie de données optionnelle (Zotero, fournisseur LLM cloud, connecteurs d'archives). - Technical Architecture : traçage complet d'un scénario de bout en bout (PDF de 200 pages → indexation → récupération Brainstorm) a révélé un mécanisme jamais documenté en 13 passes — l'extraction PDF tourne dans un processus enfant Node système isolé (contournement d'un crash pdfjs-dist), avec un timeout de 120s, une file d'attente séquentielle globale (un PDF à la fois, jamais en parallèle), et une exigence de binaire Node système séparé d'Electron. Documentation aussi d'un second filet de sécurité (EMBED_CHAR_CAP=6000 caractères dans PdfIndexer.ts, indépendant de la troncature côté Ollama). - Features.md : la bascule automatique Ollama→embarqué est en réalité asymétrique entre génération (toujours) et embeddings (seulement si les dimensions correspondent) — précision ajoutée, déjà documentée ailleurs mais pas ici. - Logging System : la table « comportement par défaut » laissait penser à un mécanisme unique de filtrage alors que celui du renderer n'est jamais réellement actif (aucun `process` global) — précision ajoutée après trois passes de corrections successives sur cette même page qui n'avaient jamais été reconciliées entre elles. Meta & notes de version : une seule correction mineure de cohérence interne sur Logging System, rien d'autre trouvé sur les notes de version elles-mêmes malgré la recherche de contradictions avec les pages actuelles.

inactinique committed Jul 24, 2026

docs(wiki): onzième passe — Unlink Obsidian écrase brain.db, compression de contexte jamais câblée Deux bugs applicatifs sérieux trouvés et filés cette passe, en changeant de méthode sur le cluster brainstorm/intégrations (deux passes propres consécutives, donc recherche de contradictions inter-pages et de collisions sur des ressources partagées plutôt que répéter les mêmes vérifications) : - issue #27 : le bouton « Unlink » d'un carnet Obsidian supprime le fichier .cliodeck/brain.db tout entier via fs.unlink, pas seulement l'index du carnet — obsidianStorePath() pointe vers le même fichier partagé que les vecteurs PDF, l'index Tropy et le journal de recherche depuis la consolidation. Documenté dans 1.14-Obsidian-Vault-Guide.md. - issue #28 : le système de compression de contexte RAG (ContextCompressor.ts) n'est appelé nulle part dans le vrai chemin de requête — retrieval-service.ts ne renseigne jamais le champ `compression` que chat-engine.ts vérifie en aval. Tout contexte récupéré part vers le LLM sans compression, quelle que soit sa taille. Documenté dans 2.-Technical-Architecture.md (section renommée « declared but dead »). Autres corrections : - Brainstorm Mode Guide + MCP Integration Guide : une vraie UI de bascule par outil existe désormais (bannière MCP, classification lecture/écriture avec opt-in explicite pour les outils d'écriture) — la note « UI minimale » était périmée, remplacée par une section complète. - Keyboard Shortcuts : nuances plateforme sur F11 (plein écran) et F12 (DevTools) sur macOS, même classe de lacune que Cmd+W (passe 10). - Logging System : dernière formulation trop large sur les DevTools et les variables d'environnement corrigée (seul CLIODESK_DEBUG/DEBUG ouvre les DevTools, pas CLIODESK_LOG_LEVEL ; les logs renderer révélés n'existent de toute façon plus dans le bundle de production). - RC2 Release Notes : le « problème connu » sur l'étape export des recipes était factuellement faux (document_id était déjà honoré à ce tag) — remplacé par la vraie limitation de l'époque (projectType 'article' figé), corrigée avant RC3. - Features.md : tableau de bord statistiques a 5 onglets, pas 4 (onglet Tags manquant). - Installation Linux : bibliothèques système manquantes dans le résumé (libsecret-1, libgbm) alors que présentes dans la commande d'installation réelle. - Build and Deployment Guide : build:all ne construit que pour la plateforme hôte, pas toutes les plateformes ; stockage des clés API documenté avec son repli en clair non signalé ailleurs quand le chiffrement OS n'est pas disponible.

inactinique committed Jul 24, 2026

docs(wiki): dixième passe — Cmd+W non lié sur macOS, filtre console inerte en renderer, chunking mal attribué - Keyboard Shortcuts : Cmd+W n'est pas réellement lié sur macOS (le sous-menu Window n'inclut le rôle 'close' que sur Windows/Linux) — corrigé et lié à l'issue #26 nouvellement créée. - Build and Deployment Guide + Logging System : CLIODESK_DEBUG et CLIODESK_LOG_LEVEL ne peuvent avoir d'effet observable que dans le process principal — la fenêtre renderer est créée avec contextIsolation/sandbox (sans condition dev/prod), donc son `typeof process` est toujours undefined et les branches basées sur ces variables d'environnement ne peuvent jamais s'exécuter côté renderer, indépendamment de esbuild qui supprime déjà les appels console.* en production. - Technical Architecture : le chunking "emergency" par découpage de phrases était attribué à Ollama, mais appartient en réalité au provider LLM embarqué (EmbeddedLLMClient.ts, seuil de 2000 caractères) — Ollama gère les dépassements par troncature côté serveur (`truncate: true`), l'inverse de ce qui était décrit. - Installation Linux : alignée sur macOS pour la note sur le venv Python (pas de création automatique, étape manuelle). - FEATURE_SIMILARITY_FINDER : contrôle manquant dans la liste ("Type de source" / sourceType) — les 6 contrôles réels sont maintenant tous listés. Deux nouveaux bugs applicatifs réels trouvés et filés : issue #25 (liens du menu Aide pointant vers le dépôt archivé inactinique/cliodeck au lieu de cliodeck/cliodeck-app) et issue #26 (Cmd+W non lié sur macOS, ci-dessus). Quatre clusters entièrement propres cette passe (aucune correction) : brainstorm & intégrations (deuxième passe consécutive sans trouvaille), meta & notes de version, feature pages & home (hors le contrôle manquant), LLM & analyse (hors l'attribution du chunking).

inactinique committed Jul 24, 2026

docs(wiki): septième passe — le service Python calcule zéro embedding, un vrai trou de composition sur le logging, une correction de ma propre passe 6 Technical Architecture (sept trouvailles sur sept passes maintenant) : - Section Topic Modeling entièrement fausse sur l'architecture. Le service Python ne calcule aucun embedding — son propre docstring dit « Reçoit des embeddings pré-calculés depuis Electron/Ollama », son schéma de requête exige embeddings en champ obligatoire. Aucun appel SentenceTransformer nulle part dans main.py (sentence-transformers n'est qu'une dépendance transitive de BERTopic). Forme de réponse réelle aussi corrigée : {topics, topic_assignments, outliers, statistics}, pas {topics, topic_info, probabilities}. - Tableau Memory Footprint : une ligne « Ollama (nomic) » présentée comme le seul cas, incohérente avec le reste de la page déjà recadrée sur le registre multi-provider. Logging System : trou de composition réel entre les deux mécanismes. isProd (logger.ts:28) est une constante Vite figée à la compilation, pas une vérification runtime — et vite.config.mts:79 marque console.log/info/debug "pure" pour esbuild, qui les retire purement et simplement du bundle de production. Aucune variable d'environnement ne peut donc jamais faire réapparaître logger.debug()/log()/info() dans un build packagé — seuls les appels console.* bruts répondent aux variables d'environnement documentées. Un développeur suivant les conseils de cette même page pour déboguer un build packagé via logger.debug() obtenait un silence total sans explication. Zotero guide : ma propre correction de la passe 6 affirmait qu'aucun chemin de code ne construit la forme bibliographySource type: 'zotero' — faux. ZoteroImport.tsx:226 l'écrit après chaque synchronisation réussie, avec un champ filePath que ma version corrigée avait aussi omis. Précisé aussi que type ne sert qu'à documenter : à la lecture, 'file' et 'zotero' sont traités identiquement, seul filePath compte.

inactinique committed Jul 24, 2026

docs(wiki): un troisième logger existe — celui réellement utilisé par le renderer Quatre passes avaient déclaré cette page propre en vérifiant que @shared/logger.ts se comporte bien comme décrit — vrai en isolation, mais personne n'avait vérifié qui l'importe réellement. Résultat : zéro fichier en dehors de logger.ts lui-même (grep sur tout src/ et backend/). 100% des imports réels de logger côté renderer résolvent vers un troisième fichier jamais documenté : src/renderer/src/utils/logger.ts — API différente (log/info/debug variadiques + canaux typés ipc/store/component/error), mécanisme de suppression différent (strip par le bundler esbuild, pas les variables d'environnement). Toute la section « Centralized Logger (for Developers) » documentait donc du code mort. Remplacée par la vraie API. Le filtre console global (console-filter.ts) reste correctement décrit — c'est un mécanisme séparé et bien réel, importé par main.tsx et main/index.ts. Arbre d'architecture et vue d'ensemble mis à jour pour refléter les trois mécanismes réels (filtre console, logger renderer, logger main process) plutôt que les deux précédemment documentés.

inactinique committed Jul 24, 2026

docs(wiki): documenter le second logger, silencieux jusqu'ici La page ne couvrait que src/shared/logger.ts (renderer). Un second logger, distinct, tourne dans tout le processus principal (src/main/utils/logger.ts) — IPC, services — avec une API et un format différents, absent de la page. Écart de comportement réel signalé, pas seulement documentaire : CLIODESK_LOG_LEVEL n'agit que sur le logger du renderer. Le logger du process principal fixe son niveau à 'info' en dur ; sa méthode setLevel() n'est appelée nulle part dans le dépôt. Positionner cette variable d'environnement ne change donc rien aux logs debug émis par les handlers IPC.

inactinique committed Jul 23, 2026

first commit after move from inactinique

inactinique committed Feb 9, 2026