docs: Linux x86_64 est publie, la documentation le disait encore impossible
Les binaires x86_64 sont desormais attaches a la rc.4. Toute la
documentation affirmait « arm64 only — build from source on x86_64 »,
ce qui envoyait un utilisateur de PC compiler l'application pour rien.
Les guides donnent la substitution (`-x86_64` -> `-arm64`) plutot qu'une
seconde serie d'URLs : deux jeux de commandes a maintenir, c'est un jeu
qui finira perime. Ils commencent par `uname -m`, parce que le mauvais
fichier se telecharge parfaitement avant de refuser de demarrer — panne
d'autant plus deroutante que rien n'a echoue.
Le guide de construction gagne la raison du piege, qui n'etait ecrite
nulle part : electron-builder n'inscrit l'architecture dans le nom que
lorsqu'elle n'est pas x64, et la cible `linux` de package.json n'en
declare aucune, donc elle herite de la machine de build. C'est ainsi
qu'un Mac a produit des binaires arm64 dont le nom ne disait rien. D'ou
la consigne : lire l'en-tete ELF, jamais le nom du fichier.
Les tailles sont remesurees sur les six assets publies, avec l'ecart
x86_64 explique — `node-llama-cpp` embarque CUDA et Vulkan sur cette
architecture seulement. C'est un arbitrage, pas un defaut : ces
binaires servent a qui a une carte NVIDIA, et pesent pour les autres.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ababa2b
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>
d4c3937
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>
b579d06
docs(wiki): corriger la prémisse fausse de l'issue #29 (busy timeout)
Une contre-vérification adversariale des 40 issues filées par l'audit a
réfuté la prémisse centrale de l'issue #29 : better-sqlite3 applique par
défaut un timeout de 5000 ms à toute connexion (database.js :
`'timeout' in options ? options.timeout : 5000`) — le « 0 ms par défaut »
affirmé ne vaut que pour SQLite brut. L'issue a été retitrée et déclassée
sur GitHub ; les deux pages du wiki qui portaient cette affirmation sont
corrigées en conséquence :
- Obsidian Vault Guide : l'encadré « SQLITE_BUSY immédiat » devient un
risque résiduel étroit — seule une transaction d'écriture tenant le
verrou plus de 5 secondes (grosse réindexation par lot) peut encore
pousser un écrivain concurrent en SQLITE_BUSY ; la recommandation qui
survit est d'aligner les 3 écrivains sans WAL sur ObsidianVaultStore.
- Tropy Integration Guide : même correction sur l'encadré de concurrence
de l'auto-resync, et la note de conception sur la connexion non fermée
ne cite plus « l'absence de busy_timeout » comme facteur aggravant.
C'est le seul faux positif trouvé par la passe de re-vérification : les
39 autres issues de l'audit tiennent, et les 7 issues utilisateur
anciennes (#1, #2, #3, #9, #10, #11, #12) sont toutes confirmées contre
le code avec leur cause racine.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
b37c889
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).
112f19b
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.
f73f991
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.
670457f
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.
f17d740
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é).
db40768
docs(wiki): douzième passe — touches d'envoi du chat inversées, contradictions avec les issues #24 et #28, minTopicSize figé à 3
Aucun nouveau bug applicatif filé cette passe — uniquement des
corrections de documentation, mais deux d'entre elles sont des
contradictions directes avec des bugs déjà filés lors des passes
précédentes, qui avaient survécu parce que les pages n'avaient pas été
recroisées entre elles :
- Features.md : les réglages de compression de contexte et le ratio de
compression dans RAGExplanation étaient encore présentés comme
actifs, alors que la passe 11 a établi qu'ils sont totalement
jamais câblés (issue #28) — corrigé et lié.
- RC3 Release Notes : les réglages de livre (notes, numérotation,
bibliographie) étaient listés comme une fonctionnalité RC3 sans
réserve, alors que 1.15-Books-and-Chapters.md documente depuis la
passe 9 qu'aucun n'a d'interface (issue #24) — réserve ajoutée et
lien.
- RC2 Release Notes : deux affirmations sur obsidian-vectors.db
encore séparé de brain.db à l'époque de RC2 étaient fausses même
pour ce tag précis — vérifié via `git show v1.0.0-rc.2:...` que la
fusion datait de 5 jours avant le tag.
Corrections supplémentaires :
- Keyboard Shortcuts : les touches d'envoi/retour à la ligne du chat
RAG étaient inversées (Ctrl/Cmd+Entrée envoie, Entrée simple insère
un retour à la ligne — c'était documenté à l'envers) ; la touche
Échap pour annuler n'existe pas, seul un bouton l'annule.
- Guide des templates Word : mauvais pointeur de dépannage vers le
Journal Panel (qui est le journal d'usage IA, sans rapport avec les
logs d'export).
- Corpus Analysis Guide : nombre de topics par défaut réellement 10
(pas "Auto"), taille minimale de topic figée à 3 dans le code (pas
5, sans aucune interface pour la changer).
- Tropy Integration Guide : documentation du bouton de purge de la
base des sources primaires (tropy:purge), jusqu'ici non documenté
mais correctement scopé (contrairement au bug Obsidian/brain.db).
- Brainstorm Mode Guide : liste des préfixes de verbes de lecture
incomplète dans la nouvelle section bannière MCP.
- Build and Deployment Guide : npm test tourne en mode watch par
défaut, pas "une fois" ; storage des clés API.
- ClioDeck Installation : le lanceur .desktop généré ajoute
--no-sandbox à l'AppImage, absent du lancement direct.
Quatre passes de vérification exhaustive supplémentaires n'ont rien
trouvé de nouveau dans leurs clusters respectifs (LLM & analyse au-delà
du point ci-dessus, install & build au-delà des deux points ci-dessus).
406b72d
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.
900fb0d
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).
914ecf1
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.
0b7cc61
docs(wiki): neuvième passe — les réglages livre n'ont aucune UI, un bouton Test Connection qui n'existe pas pour Ollama
- Books-and-Chapters : les quatre réglages livre (style de notes,
numérotation, bibliographie, numérotation des chapitres) sont
présentés comme configurables alors qu'aucun n'a de chemin
d'interface — grep exhaustif : noteStyle n'apparaît que dans un
fichier de test, bookSettings. n'est lu nulle part côté renderer sauf
en lecture seule dans EditorPanel.tsx:169, ProjectPanel.tsx n'expose
que le sélecteur de type de projet. Seul un projet.json modifié à la
main permettrait de changer ces réglages — jamais mentionné comme
possible. Plus large et plus impactant que les précédentes lacunes
« capacité sans UI » vu le rôle central de la fonctionnalité livre.
Filé en issue #24.
- Guides Linux et macOS : « Click Test Connection to validate » dans la
configuration LLM/Ollama — ce bouton n'existe que pour Zotero
(ZoteroConfigSection.tsx). Le seul contrôle réel du panneau LLM est
le bouton de rafraîchissement des modèles (icône 🔄).
- Coût environnemental : preuve supplémentaire trouvée (recherche +
vérification directe d'une source citée) que la littérature publiée
sur le coût carbone de l'inférence LLM s'exprime généralement en
grammes voire en milligrammes, pas en kilogrammes — une requête
ChatGPT complète est couramment citée autour de 4 g CO2. Cela va à
l'encontre de l'indice directionnel précédent (qui supposait que les
chiffres à l'échelle du kg étaient probablement voulus). Aucune
source précise n'a pu être retrouvée pour le taux exact de cette
page dans un sens ou l'autre — l'encart reformulé pour présenter les
deux indices contradictoires honnêtement, sans trancher.
d33c4ae
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')).
b3ebb0f
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.
4112f6d
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.
bad44b8
docs(wiki): retirer une fonctionnalité de réindexation PDF fabriquée, préciser le filtre Tropy orphelin
- Features.md : « Re-indexation: Detect modified PDFs and propose
re-indexing » — recherche exhaustive (needsReindex/isModified/
hasChanged) dans tout le dépôt, aucun résultat. Aucune détection de
fichier PDF modifié sur disque n'existe ; OrphanPDFDetector.ts gère
les PDF orphelins, pas les PDF modifiés — fonctionnalité distincte.
Bullet retiré.
- Tropy guide : précision sur le filtre par collection — une action
setCollectionFilter existe bien côté store (primarySourcesStore.ts)
mais elle est orpheline, aucun composant PrimarySources/ ne l'appelle.
b3c66f5
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.
4560411
docs(wiki): propager l'avertissement export Word/livre à la page d'accueil
1.0-Getting-Started.md — la page d'entrée pour un nouvel utilisateur —
affirmait sans réserve « Word needs nothing extra » pour l'export d'un
livre, alors que trois pages sœurs portent déjà l'avertissement sur le
bug de l'issue #19 (export vide dans le cas courant bibliographie +
pandoc + pas de moteur de citation). C'est justement la page où un
nouvel utilisateur tomberait sur ce bug en premier, sans aucun signal.
7c02624
docs(wiki): trois petites imprécisions — clic sur segment, titre de segment, langues des system prompts
- Similarity Finder : le clic se fait sur une entrée du panneau de
résultats, pas dans le texte affiché de l'éditeur. Le titre de
segment vient de segment.title (sections seulement) ou des 60
premiers caractères — pas de repli par numéro comme décrit.
- Features.md : « system prompts personnalisables en français, anglais
et allemand » — getDefaultSystemPrompt n'accepte que 'fr' | 'en'
(SystemPrompts.ts:49). L'allemand est une langue d'interface, pas une
langue de system prompt — confusion entre les deux.
7626f5e
docs(wiki): l'export Word d'un livre est cassé dans le cas courant, pas juste "peu fiable"
En creusant pourquoi {content} ne recevait pas le manuscrit assemblé sur
la route pandoc (déjà noté), la trace complète du code a révélé un vrai
bug applicatif, pas seulement une nuance documentaire :
- WordExportModal.tsx:167 envoie un content vide pour un livre —
l'assemblage se fait censément côté main.
- word-export.ts:643-646 retourne immédiatement vers exportWithPandoc()
dès que bibliographie + pandoc + pas de moteur de citation (le cas le
plus courant pour un livre avec citations).
- assembleManuscript() n'a qu'UN SEUL point d'appel dans tout le fichier
(ligne 667), à l'intérieur du chemin natif — inatteignable depuis la
branche pandoc qui vient de renvoyer.
- exportWithPandoc() n'a aucune référence à manuscript/assembleManuscript
et écrit options.content (vide) tel quel dans le fichier d'entrée
pandoc (lignes 503-505). Pandoc réussit silencieusement sur un contenu
vide : le .docx produit a une page de titre et aucun texte de chapitre.
- pdf-export.ts fait ça correctement (assemblage inconditionnel avant
tout branchement bibliographie) — la route Word/pandoc est l'anomalie.
Signalé en issue #19 (bug applicatif réel, pas seulement un problème de
doc). Trois pages corrigées pour refléter la vraie gravité :
- 1.3-Guide-for-Using-Word-Templates.md : l'avertissement portait
uniquement sur {content} via un template ; élargi pour dire que
l'export sans template est tout autant affecté.
- 1.15-Books-and-Chapters.md : « Word produces one section per chapter »
était affirmé sans réserve — précisé que ça casse justement dans le
cas bibliographie + pandoc + pas de moteur de citation.
- 1.10-Export-Presentations.md : pointeur ajouté vers la mise en garde,
en précisant que le PDF n'est pas affecté.
Au passage, lien mort corrigé sur 1.4-Keyboard-Shortcuts.md : README.md
n'existe pas dans ce dépôt wiki.
b9688fa
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.
90c0ac0
docs(wiki): indice directionnel sur l'incohérence g/kg du coût environnemental
213d982
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).
6f042a0
docs(wiki): mettre à jour le renvoi vers Logging System — trois mécanismes, pas deux
4b38f09
docs(wiki): Features.md répétait deux fabrications déjà corrigées sur 1.9-Journal-and-History.md
« Context Recovery: Resume previous conversations » et « Timeline
View: Visualize activity over time » décrivaient une reprise de
conversation et une vue calendaire/heatmap — les deux confirmées
absentes du code lors de la correction de 1.9-Journal-and-History.md
(ChatHistoryView.tsx en lecture seule pure, SessionTimeline.tsx est
une simple liste verticale). La correction n'avait jamais été
propagée à cette page.
226f200
docs(wiki): filtrage par collection fabriqué, canal IPC et action d'annulation corrigés
- « Collection : Limiter à une collection Zotero » comme option de
configuration : grep sur les 5 composants Similarity du renderer,
zéro occurrence de "collection" — collectionFilter existe côté
backend (similarity-service.ts) mais n'est exposé nulle part dans
l'UI. Retiré de la Configuration et des Bonnes pratiques.
- Diagramme IPC : le canal réel est similarity:get-all-results, pas
similarity:get-results (similarity-handlers.ts:112). Un quatrième
canal réel, similarity:cancel (ligne 93), n'apparaissait dans aucune
version précédente du schéma alors qu'il existe une vraie méthode
cancelAnalysis() qui s'appuie dessus.
cb4cac4
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.
0a1920b
docs(wiki): num_ctx ne concerne que les embeddings, en-têtes MCP désynchronisés des onglets réels
- Brainstorm guide : « Adjust num_ctx in Settings → LLM » pour les
fenêtres de contexte de génération — le seul réglage num_ctx qui
existe (ollamaEmbeddingNumCtx, LLMConfigSection.tsx:358-362)
concerne les requêtes d'embedding Ollama, pas la génération. Aucun
contrôle de fenêtre de contexte pour la génération n'existe dans
l'UI aujourd'hui.
- MCP guide : les en-têtes de section (« Claude Code », « Generic
stdio client ») ne correspondaient plus aux libellés d'onglets
réels déjà corrigés ailleurs sur la même page (« Claude Code CLI »,
« Generic MCP (stdio) », common.json:1413,1415).
da1965c