docs(wiki): commandes d'installation reparees — les noms d'assets ont change en rc.4 Les guides donnaient des commandes `wget` avec les URL de rc.3. Bumper le seul numero de version ne suffisait pas : les fichiers publies portent desormais un prefixe de plateforme (`Linux.AppImage.-.`, `Mac.Silicon.-.`), si bien qu'une URL construite a l'ancienne rend un 404. C'est exactement ce sur quoi un nouvel utilisateur bute, et rien dans la page ne le lui dirait. Les trois URL de telechargement du wiki sont verifiees : elles repondent en 200. Un commentaire dans chaque bloc explique le prefixe, pour que la prochaine mise a jour ne refasse pas l'erreur. Tailles d'installeurs mesurees sur les fichiers reellement publies, plutot que reconduites : 262 Mo (AppImage), 158 Mo (deb), 263 et 268 Mo (DMG Silicon et Intel). En-tetes `**Version**` des neuf pages concernees passes en 1.0.0-rc.4. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

inactinique committed Jul 26, 2026

docs(wiki): RC4 — notes de version, et 23 defauts documentes qui n'existent plus Le wiki citait 23 issues comme ouvertes. Toutes sont fermees : chaque « voir issue #N » decrivait donc un defaut corrige, et le wiki decrivait une application qui n'existe plus. Nouvelles notes de version (3.4), sur le modele des RC3 : orientees utilisateur, ordonnees par ce qu'on perdait ou voyait de faux plutot que par famille technique. La section 1 s'ouvre sur les deux defauts qui retiraient du texte d'un livre exporte, parce que c'est ce qu'un auteur doit lire en premier. Dix-huit pages corrigees. Le plus souvent, un long paragraphe decrivant un bug verifie dans le code est remplace par sa resolution — d'ou un diff qui retire plus de lignes qu'il n'en ajoute. Les affirmations les plus trompeuses etaient : - les reglages d'ouvrage « n'ont aucune UI » (ils en ont une depuis la RC4) - l'export Word d'un livre cite « sort vide » (corrige) - le corpus manuscrit sans interface (elle existe) - le compresseur de contexte « jamais appele » (cable, et ses trois distorsions corrigees) - `embeddingProvider` sans controle (section Embeddings) - le filtre par collection absent, le bouton OCR manuel injoignable, le toggle des noeuds auteurs desactive en dur Home annonce la RC4 ; Features passe en 1.0.0-rc.4 et gagne deux sections — corpus manuscrit et accessibilite — qui n'avaient nulle part ou vivre. Les limitations connues des notes RC4 sont argumentees, pas subies : pdfjs-dist renvoie a #77, et le mode de detection seule de l'inspecteur explique pourquoi une source primaire contenant des imperatifs ne doit pas etre tronquee. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

inactinique committed Jul 26, 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): quinzième passe — course Zotero inter-projets, watcher Tropy orphelin, BibTeX perd les entrées sans auteur Six nouveaux bugs applicatifs réels trouvés et filés cette passe, la plupart via un angle « que se passe-t-il si on change de projet pendant une opération en cours » appliqué systématiquement à chaque intégration : - issue #33 (le plus sérieux) : une synchronisation Zotero relit le vectorStore du projet ACTUELLEMENT ouvert après son await réseau, pas celui qui a démarré la synchronisation — changer de projet pendant une synchronisation en cours écrit les collections du projet A dans le projet B. Corruption de données inter-projets réelle, pas juste une fuite ou un glitch d'affichage. - issue #34 : TropyService.init() remplace this.watcher sans jamais appeler .unwatch() sur l'ancien (contrairement au registre LLM juste à côté, qui a son disposePreviousRegistry() explicite) — un watcher orphelin peut déclencher une resynchronisation du mauvais projet. - issue #35 : le canal de progression d'indexation Obsidian (fusion:vault:progress) ne porte aucun identifiant de projet — affichage seulement, aucune corruption de données puisque l'écriture elle-même reste bien scopée. - issue #31 : l'événement d'expiration d'une proposition IA lors d'un changement de chapitre est journalisé sous le chemin du chapitre qu'on vient de rejoindre, pas celui qu'on quitte — la destruction de la vue CodeMirror se produit après que le store ait déjà basculé son filePath. - issue #32 : l'import BibTeX rejette silencieusement toute entrée sans champ author (pas de repli sur editor), perdant les volumes collectifs et travaux anonymes courants en bibliographie historique — seul un console.warn, aucun signal côté interface. - issue #36 : npm run lint échoue immédiatement, aucune configuration ESLint n'existe dans le dépôt (déjà su et documenté dans le commentaire du workflow CI, mais jamais remonté dans le wiki ni retiré du script). Autre trouvaille notable (pass fusionné après un traçage de bout en bout du pipeline Tropy) : l'ordre de priorité des transcriptions était mal documenté depuis le début (notes Tropy > transcription externe type Transkribus > OCR — pas « notes > OCR > manuel » comme l'affirmait une version antérieure), et le chunking des sources primaires est en réalité figé en taille fixe (DocumentChunker), jamais le chunker adaptatif utilisé par les PDF — corrigé sur Technical Architecture. Cluster meta & notes de version entièrement converti en lecture vide cette passe : Ethics.md a enfin eu sa première lecture véritablement approfondie (aucune affirmation factuelle vérifiable trouvée, page confirmée inerte plutôt que simplement non examinée) et un nouvel échantillon de notes de version RC2/RC3 vérifié contre les tags git réels a tenu sans exception.

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): treizième passe — embeddingProvider toujours sans UI (contradiction avec #18), variable d'environnement Wayland inexistante Aucun nouveau bug applicatif filé — uniquement des corrections de documentation, dont deux contradictions inter-pages qui avaient survécu 12 passes précédentes : - Technical Architecture : affirmait que embeddingProvider est sélectionnable depuis Settings → LLM au même titre que generationProvider — faux, aucune UI n'existe pour ce réglage (contredit directement l'issue #18 et le propre texte du guide LLM embarqué). Corrigé, et documentation du garde-fou réel découvert au passage : le repli automatique Ollama→embarqué pour les embeddings ne s'active que si les deux modèles partagent la même dimension de vecteur, sinon échec volontaire plutôt que corruption silencieuse de la recherche par similarité. - Export Presentations : les réglages de style de notes/bibliographie du livre étaient présentés sans réserve alors qu'ils sont entièrement figés (issue #24, documentée ailleurs mais pas liée ici) — lien ajouté. Autres corrections : - Installation Linux : `ELECTRON_NO_SANDBOX` n'est pas une variable d'environnement Electron réelle — le vrai nom est `ELECTRON_DISABLE_SANDBOX` ; commande de suppression de ~/.local/share/cliodeck retirée (l'app n'y écrit jamais, chemin Electron par défaut confirmé). - MCP Integration Guide : la nouvelle bannière de retry MCP a été qualifiée à tort de « silencieuse » — la transition par l'état `degraded` est en fait visible en temps réel dans l'UI (même code couleur que `failed`) ; seule la tentative elle-même est automatique, pas son affichage. - Zotero Integration Guide : documentation d'un comportement réel non documenté jusqu'ici — le mode local copie zotero.sqlite (+ le WAL) dans un fichier temporaire en lecture seule, donc sûr même avec Zotero ouvert en parallèle. Deux clusters entièrement propres cette passe (aucune correction) : meta & notes de version (méthode de vérification contre les tags git appliquée à un nouvel échantillon, tout confirmé), feature pages & home (balayage complet contre les issues #16-#28, rien trouvé).

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): neuvième passe (suite) — Technical Architecture : regex roman périmée, RAGExplanation incomplet - Le regex "roman numeral header" montré pour AdaptiveChunker.ts était périmé : le vrai code (ligne 159) exige un titre capitalisé de 2 à 50 caractères sans point final, comme le pattern `numbered` voisin — pas un simple "I. n'importe quoi". - L'extrait de formatContextAsSystemPrompt() passait sous silence 2 des 4 règles réelles (TITRE comme réponse valide pour les questions d'identification, formulation explicite contre les phrases toutes faites en cas d'absence) sans le signaler — ajout d'un commentaire indiquant l'abréviation. - L'interface RAGExplanation montrée omettait deux champs racine réels de backend/types/chat-source.ts (`llm` et `timing`) — ajoutés. Brainstorm & intégrations (MCP, Zotero, Tropy, Obsidian, connecteurs d'archives) : sixième relecture consécutive sans aucune correction nécessaire, tout vérifié à nouveau contre le code actuel.

inactinique committed Jul 24, 2026

docs(wiki): huitième trouvaille sur huit passes — le system prompt réel n'a rien à voir avec celui affiché, et contredisait une autre page du wiki - Step 1 PDF Extraction : le champ réel est text, pas content (PDFExtractor.ts:174-176, confirmé par tous les usages en aval qui lisent page.text). - Step 5 Context Building : entièrement fabriqué. Le vrai formatContextAsSystemPrompt (fusion-chat-service.ts:799) produit des blocs numérotés TITRE/AUTEUR/EXTRAIT en français avec une règle explicite forçant le modèle à ne répondre qu'à partir de ces champs — pas le Markdown "# Context (sources)" inventé. Cette page contredisait carrément le guide Brainstorm (déjà vérifié exact sur ce même format) sur ce qu'est réellement le system prompt envoyé au modèle. Step 6 corrigé en cohérence : il n'existe aucun template de prompt anglais séparé, le message system EST le bloc TITRE/AUTEUR/ EXTRAIT de l'étape 5.

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): quatre erreurs de plus sur l'architecture technique — sixième passe, sixième trouvaille sur cette page - Arbre « Key Architecture Files » : listait encore PDFIndexer.ts avec le commentaire "PDF extraction + indexing", contredisant la section Step 1 déjà corrigée sur la même page qui dit que l'extraction vit dans PDFExtractor.ts. PDFExtractor.ts ajouté à l'arbre. - Step 3 Embedding Generation : montrait l'ancien point d'entrée /api/embeddings (un seul prompt), que le vrai code évite explicitement — le commentaire d'ollama.ts dit noir sur blanc que cet ancien point d'entrée ignore truncate et plante (500), exactement le bug d'indexation PDF que le point d'entrée moderne /api/embed (entrées par lot, truncate: true) corrige. - Index 3 BM25 : montrait un index inversé fait main (invertedIndex[token] = ...) — le vrai code délègue entièrement à TfIdf de la bibliothèque natural, aucune structure de ce genre n'existe dans BM25Index.ts. - Section CPU Optimizations : deux méthodes inventées (ollama.batchEmbed(), hnswStore.rebuild()) qui n'existent nulle part — précisé qu'il s'agit de pseudocode illustratif, avec la vraie méthode de remplacement où elle existe (generateEmbeddings sur le provider actif).

inactinique committed Jul 24, 2026

docs(wiki): section Adaptive Chunking jamais confrontée au code en détail — trois erreurs - Regex de détection de structure trop permissives par rapport au vrai code. Le pattern "numbered" exige un point final et un titre en majuscule de 2-50 caractères (AdaptiveChunker.ts:149), pas la version laxiste affichée. Le pattern "uppercase" exige 6-51 caractères plus un filtrage sur une liste de titres connus (ligne 168), pas un simple {3,}. - Interface DocumentChunk : un champ embedding?: number[] inventé — les embeddings vivent dans la ligne de la base ou le vector store, jamais sur cet objet en mémoire (backend/types/pdf-document.ts:57-66). Les vrais champs startPosition/endPosition manquaient. - Schéma SQLite : la table s'appelle pdf_chunks, pas chunks (VectorStore.ts:104-113) ; colonnes metadata et created_at inventées, absentes du vrai schéma ; start_position/end_position manquantes ; noms d'index réels (idx_chunks_document_id, idx_chunks_page_number) différents de ceux affichés.

inactinique committed Jul 24, 2026

docs(wiki): deux citations de fichier fausses et un extrait BibTeX qui sous-estime largement le vrai code - Extraction PDF : le code cité (getDocument/getTextContent/getMetadata) ne vit pas dans PDFIndexer.ts (646 lignes, zéro occurrence de ces appels) mais dans PDFExtractor.ts — PDFIndexer.ts n'est qu'un orchestrateur qui délègue. - Zotero : les appels fetch() et les en-têtes cités (Zotero-API-Key, api.zotero.org) ne sont pas dans zotero-service.ts (zéro fetch()) mais dans backend/integrations/zotero/ZoteroAPI.ts, jamais cité par la page. - BibTeX : le code montré était une fonction de 20 lignes à base d'une seule regex. Le vrai parseur (BibTeXParser.ts) est une classe de 484 lignes ; aucune fonction parseBibTeX n'existe nulle part dans le dépôt.

inactinique committed Jul 23, 2026

docs(wiki): cinq erreurs supplémentaires dans l'architecture technique, un footer figé en bêta Cette page continue de produire des erreurs à chaque passe — cinq de plus trouvées et corrigées ici : - Graph Expansion : décrite comme une fonctionnalité active (recherche de voisins dans le graphe, expansion par similarité cosinus). Vérifié qu'useGraphContext/graphSimilarityThreshold/additionalGraphDocs n'ont aucun consommateur dans retrieval-service.ts ni backend/core/rag/ — le réglage existe dans les types et l'UI, mais ne fait rien. Documenté comme un manque connu, pas un comportement réel. - Context Compression : les seuils sont en caractères, pas en tokens (le commentaire du code le dit explicitement) ; les paliers étaient faux — la vraie logique a un premier niveau « pas de compression » (≤10 000 caractères) que la page ne mentionnait pas du tout, avant Level 1 (15-25k), Level 2 (25-35k), Level 3 (>35k) — avec une zone morte entre 10k et 15k où rien ne se passe. - RAG Explanation : l'interface était entièrement inventée (forme plate à 7 champs). La vraie interface (chat-source.ts) est imbriquée — search/compression/graph — et ne partage aucun nom de champ avec la version précédente de la page. - Configuration de chunking : un champ maxTokens fabriqué apparaissait à deux endroits de la page ; DocumentChunker.ts n'a que maxChunkSize/overlapSize/minChunkSize, aucune limite de tokens dans ce type. - En-tête et pied de page « RAG Configuration Defaults » / Version/Status figés sur 1.0.0-beta.2, jamais mis à jour malgré trois passes de corrections sur cette même page. Les valeurs elles-mêmes restaient exactes — seul l'habillage était périmé.

inactinique committed Jul 23, 2026

docs(wiki): deuxième passe — corriger une erreur dans ma propre réécriture, et un vrai manque d'UI **Erreur dans ma propre correction précédente** : - Guide des LLM embarqués : j'avais écrit que embeddingProvider se règle « dans Paramètres → LLM » au même titre que generationProvider. Faux — vérifié frais : grep sur tout src/renderer/ pour "embeddingProvider" ne retourne aucun fichier ; RAGSettingsPanel.tsx n'écrit jamais que generationProvider ; EmbeddedLLMSection.tsx ne contient aucune occurrence du mot "embedding". Le moteur sait faire des embeddings embarqués, mais rien dans l'interface ne permet de les sélectionner ou de télécharger le modèle — seule l'édition manuelle du fichier de configuration le permet aujourd'hui. Corrigé à quatre endroits de la page, et signalé comme un vrai manque produit en issue #18 (https://github.com/cliodeck/cliodeck-app/issues/18), pas seulement un défaut de documentation. **Erreur dans ma réécriture du guide Word Templates** : le découpage en trois routes d'export était faux. Vérifié frais dans word-export.ts — mergeWithTemplate() (fusion par {placeholders}) ne dépend que de templatePath, pas du tout de useEnginePipeline. Il n'y a que deux mécanismes réels : pandoc+reference-doc (styles, uniquement si bibliographie + pandoc + moteur de citation non demandé), et native+docxtemplater (placeholders, dans tous les autres cas — y compris bibliographie + moteur de citation demandé, que ma première version traitait à tort comme une troisième route « à base de styles »). **Erreurs ratées par la première passe** : - Corpus Analysis Guide : langue par défaut du topic modeling annoncée « Français », en réalité « multilingual » (main.py:54-56, useCorpusData.ts:145). - Journal and History : une « icône History dans le panneau de chat » fabriquée — AssistantChat.tsx n'a aucune référence à l'historique ; le vrai composant de navigation (ChatHistoryView.tsx) ne vit que dans le panneau Journal. Reformulé pour dire que c'est la même donnée, pas une fonctionnalité séparée. - Technical Architecture : la section Primary Sources (Tropy) décrivait encore un vector store autonome (sources.db/sources.hnsw) alors que PrimarySourcesVectorStore utilise le brain.db partagé depuis la fusion — contradiction interne avec la section Key Architecture Files déjà corrigée sur cette même page. L'étape « Dense Search » appelait encore ollamaClient.generateEmbedding(), contredisant l'étape Embedding Generation juste au-dessus, déjà corrigée elle aussi. - Obsidian Vault Guide : « alongside the other workspace databases (vectors.db, primary-sources.db) » — ces deux noms sont pré-fusion, le vrai voisin est brain.db.

inactinique committed Jul 23, 2026

docs(wiki): purger l'architecture technique des classes qui n'existent plus L'arbre « Key Architecture Files » listait backend/core/llm/OllamaClient.ts et src/main/services/chat-service.ts — les deux ont disparu du dépôt, remplacés par le registre de providers typé et fusion-chat-service.ts/chat-engine.ts. L'arbre omettait entièrement des pans entiers de l'architecture actuelle : le registre de providers, retrieval-service.ts, la pile manuscrit (4e corpus RAG), mcp-clients-service.ts, usage-journal-service.ts, l'éditeur CM6 (src/editor/), les recipes, et l'architecture livre/chapitres. La section LLM embarqué inventait une classe « LLMProviderManager » — recherchée dans tout le dépôt, aucune occurrence. Elle répétait aussi l'erreur de 1.7 (« pas d'embeddings, nécessite Ollama ») déjà signalée. Remplacée par un renvoi vers 1.7 comme source canonique, pour éviter qu'un même fait périme à deux endroits séparément comme c'est arrivé ici. Autres foyers de la même erreur trouvés en balayant tout le fichier et corrigés : le flux de données Tropy (« OllamaClient génère les embeddings »), l'étape de génération LLM (appel direct à Ollama en dur), l'étape de génération d'embeddings (fichier cité inexistant), le tableau Key Technologies et le résumé Overview (tous ne mentionnaient qu'Ollama). Gain vérifié en passant : la fusion RRF omettait le boost de correspondance exacte (EXACT_MATCH_BOOST dans HybridSearch.ts) — sans lui, un score RRF en tête de liste (~0.016) ne peut jamais dépasser un voisin sémantique fort (0.45–0.55) ; ajouté.

inactinique committed Jul 23, 2026

docs: wiki à jour pour la 1.0.0-rc.3 Les 33 pages ont été confrontées au code, pas réécrites de mémoire. Créées : « Writing a Book — Chapters Guide » (la nouveauté majeure de cette version : manifeste, navigateur, plan, recherche d'ouvrage, renumérotation, réglages, exports), « The Editor » (CodeMirror 6 en rendu live, notes et citations pandoc, fidélité octet pour octet, propositions adjudicables) et les notes de version RC3. Corrigées, entre autres : - Features et Technical Architecture annonçaient encore l'éditeur Milkdown, retiré depuis ; - trois raccourcis documentés n'existent pas (Ctrl+Shift+S, Ctrl+Shift+L, Alt+4) et Ctrl+J n'était pas documenté — vérifié dans menu.ts ; - « Export Presentations » ne parlait pas des présentations malgré son titre : ni reveal.js, ni modes en ligne/hors ligne/PDF, ni Beamer ; - Electron 28 dans deux pages, alors que le projet est en 40.9.2 ; - le journal d'usage IA distingue désormais ses deux couches et enregistre les adjudications de propositions. Cinq pages anciennes (Tropy, LLM embarqués, analyse de corpus, similarité, stratégie d'embeddings) portent un bandeau signalant qu'elles n'ont pas été revérifiées ligne à ligne : elles ne contiennent rien de manifestement faux, mais leur horodatage est ancien. Aucune page supprimée. Le wiki ne contient aucune capture d'écran : rien à refaire de ce côté. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

inactinique committed Jul 20, 2026

first commit after move from inactinique

inactinique committed Feb 9, 2026