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): 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): lier les quatre bugs applicatifs trouvés en passe 8 à leurs issues GitHub Ces quatre lacunes avaient été corrigées dans le wiki mais jamais signalées comme bugs réels de l'application — corrigé : - issue #20 : la resynchronisation Zotero efface silencieusement la collection associée - issue #21 : le filtrage par collection existe côté backend (Similarity Finder et Tropy) mais n'a aucune UI - issue #22 : les nœuds auteur du graphe de connaissances sont entièrement implémentés mais désactivés en dur - issue #23 : la relance manuelle d'OCR par source existe dans le store Tropy mais n'est déclenchable depuis aucun composant Au passage, la description de la « transcription manuelle » a été précisée : ce n'est pas une saisie au clavier, mais une relance OCR par source (performOCR → updateTranscription(..., 'manual')).

inactinique committed Jul 24, 2026

docs(wiki): huitième passe — une resynchronisation Zotero qui efface silencieusement la collection, une transcription manuelle fabriquée, une nuance sur l'issue #19 - Zotero guide : setBibliographySource écrase l'objet entier au lieu de fusionner, et le sélecteur de collection repart à vide (useState('')) à chaque réouverture du dialogue de sync. Resynchroniser sans re-choisir la collection écrase silencieusement zoteroCollection avec undefined — l'association précédente est perdue sans avertissement. Documenté. - Tropy guide : « Manuel : Transcription saisie dans ClioDeck » comme quatrième source de transcription — fabriqué. updateTranscription(..., source: 'manual') existe côté backend mais n'a aucun point d'appel dans tout le renderer ; seul l'import de fichier PAGE/ALTO fonctionne réellement. - Word Templates : nuance ajoutée à l'avertissement de l'issue #19 — sur le mécanisme 2 (docx natif), un échec de fusion de template produit paradoxalement un document PLUS complet qu'une fusion réussie, puisque le document natif est toujours construit à partir du manuscrit correctement assemblé, alors qu'une fusion réussie aurait rempli {content} avec la valeur non assemblée.

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): forme JSON Zotero fabriquée, filtre par collection Tropy inexistant - Zotero guide : l'exemple bibliographySource pour Zotero inventait userId, lastSync et collectionKey. Le vrai type (project-manager.ts:51-55) n'a que type et zoteroCollection. Précisé aussi qu'aucun chemin de code actuel ne construit cette forme type: 'zotero' — le flux de sync réel produit toujours un .bib (type: 'file'). - Tropy guide : « Filtrage par collection... via les paramètres RAG » n'existe nulle part — vérifié RAGConfigSection.tsx et tous les composants PrimarySources/, le nom de collection n'est qu'affiché (carte, statistiques), jamais utilisable comme filtre. Même défaut que le filtre par collection déjà retiré de FEATURE_SIMILARITY_FINDER.md.

inactinique committed Jul 24, 2026

docs(wiki): citations de ligne obsolètes retirées, seuil de caractères et dépannage corrigés - Zotero guide : deux citations de ligne précises (LLMConfigSection.tsx :140-170, RAGConfigSection.tsx:140-172) avaient dérivé et pointaient vers un tout autre champ (Mistral, curseur topK) que celui décrit. Remplacées par des renvois au fichier/section, sans numéro de ligne fragile qui redérivera au prochain refactor. - Tropy guide : seuil de transcription minimal annoncé à 100 caractères, réel est 50 (TropySync.ts:384,449, vérifié aux deux points d'application : acceptation OCR et éligibilité de source). Dépannage « Performances lentes » ne blâmait qu'Ollama non démarré — les embeddings passent par le provider configuré, pas spécifiquement Ollama.

inactinique committed Jul 24, 2026

docs(wiki): documenter le mode local Zotero, jamais mentionné Toute la page ne documentait que le mode API (User ID + clé API). Un second mode existe pourtant, réglable via le même sélecteur dans les paramètres Zotero : « Local database (reads zotero.sqlite) » (ZoteroConfigSection.tsx, config.mode: 'api' | 'local') — entièrement hors ligne, sans clé API, en pointant directement vers le dossier de données Zotero (~/Zotero). zotero-service.ts confirme que les deux modes sont interchangeables derrière la même interface (IZoteroDataSource) : tout le reste du guide (import, sync, PDF) s'applique aux deux de la même façon. Section ajoutée après la configuration API, et note dans les prérequis pour ne pas laisser croire que la clé API est obligatoire.

inactinique committed Jul 23, 2026

docs(wiki): fix last stale vectors.db reference in Zotero guide

inactinique committed Jul 23, 2026

docs(wiki): sortir le guide Zotero du vocabulaire bêta Seule page du lot d'intégrations encore en langage bêta (« Added in BETA 2 », changelog se terminant en janvier 2024) sans aucun bandeau RC — donnait l'impression de dater d'avant toute la lignée RC. Les mécanismes eux-mêmes restent exacts, vérifiés contre zotero-service.ts, ZoteroConfigSection.tsx et BibliographyPanel.tsx. Bandeau de version ajouté, changelog bêta remplacé par un résumé et un renvoi vers les notes de version RC2/RC3, cohérent avec le traitement des autres guides d'intégration.

inactinique committed Jul 23, 2026

docs: seconde passe du wiki — vérifications, traductions, parcours débutant La relecture adverse a rattrapé, entre autres, une erreur introduite par la première passe : le guide des LLM embarqués affirmait désormais que ClioDeck pouvait produire ses embeddings sans Ollama, au motif que le catalogue propose un modèle embarqué et que le réglage existe. En traçant l'appel jusqu'au registre de providers, il n'y a aucune branche embarquée : le réglage ne change rien. La page dit maintenant la vérité, écart entre catalogue et câblage compris. Autres rattrapages : - vingt liens vers l'ancien dépôt inactinique/cliodeck, dans sept pages dont les deux guides d'installation ; - la page journal décrivait .cliodeck/history.db et un dossier conversations/, vestiges d'avant la fusion : tout vit dans brain.db ; - six pages en français dans un wiki anglophone, et non deux comme la première passe l'avait cru — les deux nommées sont traduites, quatre restent ; - quatre imprécisions dans les pages créées à la première passe (plan derrière un dépliant, libellés réels des boutons, troncature de la recherche, message d'un fichier manquant). Créé : 1.0-Getting-Started, qui comblait le trou entre « installer » et « écrire » — rien n'expliquait comment créer un projet ni ce que le choix du type implique. Les cinq pages laissées sous bandeau à la première passe ont été reprises ligne à ligne : une était fausse, quatre exactes. Plus aucun bandeau. 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