Skip to main content
Cette page couvre les crates de crates/ qui gèrent les données, les fichiers, l’export PDF, les prompts du LLM, les notifications et quelques services système. L’organisation générale est décrite dans Architecture. Dans le workspace Cargo, chaque crate est déclarée sous un alias syntheo-* (par exemple syntheo-db-app pour crates/db-app). Les dépendances internes listées ci-dessous utilisent ces alias.

​
Vue d’ensemble

​
Base de données

La base app.db est le cœur des données. Les crates se répartissent en couches : db-core ouvre la connexion, db-migrate applique le schéma fourni par db-app, et db-change, db-execute et db-reactive servent l’interface via le plugin db (voir Plugins Tauri).

​
db-core

  • Chemin : crates/db-core
  • Rôle : ouvre un pool SQLite et y attache un ChangeNotifier.
  • API : Db (open, connect_memory, connect_local_read_write, connect_local_read_only, pool, change_notifier), DbOpenOptions, DbStorage, ManagedDb.
  • Dépendances internes : syntheo-db-change.
  • À noter : la CLI ouvre la base avec connect_local_read_only (apps/cli/src/db.rs), ce qui garantit la lecture seule décrite dans CLI pour agents.
  • Pages de doc concernées : Données et confidentialité, CLI pour agents.

​
db-app

  • Chemin : crates/db-app, migrations SQL dans crates/db-app/migrations.
  • Rôle : définit le schéma applicatif (schema(), APP_MIGRATION_STEPS, prepare_schema) et regroupe les opérations SQL partagées par l’application, la CLI et les plugins.
  • Dépendances internes : syntheo-db-core, syntheo-db-migrate.
Les modules de crates/db-app/src et les pages qu’ils alimentent :
Ne décrivez pas le comportement du produit à partir du schéma SQL brut. Partez des opérations et de l’interface qui les utilisent.

​
db-migrate

  • Chemin : crates/db-migrate
  • Rôle : applique une liste ordonnée de MigrationStep (migrate, migrate_with_progress), avec la portée Plain ou CloudsyncAlter.
  • Dépendances internes : syntheo-db-core.
  • Pages de doc concernées : aucune.

​
db-change, db-execute, db-reactive

  • db-change (crates/db-change) : ChangeNotifier, TableChange et TableChangeKind signalent les tables modifiées. Aucune dépendance interne.
  • db-execute (crates/db-execute) : DbExecutor exécute une requête, une requête « proxy » ou une transaction décrite en JSON (TransactionStatement). Dépend de syntheo-db-core.
  • db-reactive (crates/db-reactive) : LiveQueryRuntime extrait les tables lues par une requête (extract_dependencies, via EXPLAIN) et la rejoue quand l’une d’elles change. Le plugin db l’expose par les commandes subscribe et unsubscribe. Dépend de syntheo-db-core, syntheo-db-change, syntheo-db-execute, syntheo-db-migrate.
  • Pages de doc concernées : aucune.

​
Fichiers et stockage

​
storage

  • Chemin : crates/storage
  • Rôle : calcule l’emplacement des données et écrit les fichiers sans suivre les liens symboliques.
  • API :
    • global::compute_default_base : dossier de base. Le build stable utilise le dossier syntheo ; les autres identités (debug, configuration dev) utilisent leur identifiant de bundle.
    • vault : settings.json, clé vault_path, consolidate_custom_vault.
    • safe_path : join_under_base, resolve_under_base, open_no_follow, write_no_follow, copy_no_follow.
    • session_tree : parcours de l’arborescence des sessions (walk_session_tree, find_session_dir).
    • fs : atomic_write, copy_dir_recursive.
    • windows_auth : fichier auth.dpapi chiffré avec DPAPI, actif sous Windows uniquement.
    • StorageRuntime : trait qui fournit les bases globale et de coffre.
  • Dépendances internes : syntheo-brand.
  • Pages de doc concernées : Données et confidentialité, Désinstaller.

​
fs-sync-core

  • Chemin : crates/fs-sync-core
  • Rôle : gère les dossiers de sessions sur disque pour le plugin fs-sync : liste, création, renommage et déplacement de dossiers, lecture du contenu d’une session, pièces jointes, fichiers audio (audio : import dans une session, métadonnées, crêtes, détection de parole, suppression des orphelins expirés).
  • API : FsSyncCore (list_folders, move_session, create_folder), modules scan, session_content, folder, audio, path.
  • Dépendances internes : syntheo-storage, syntheo-fs-format, syntheo-frontmatter, syntheo-tiptap, syntheo-audio-utils, syntheo-vad ; syntheo-data en dev-dependency.
  • Pages de doc concernées : Notes, Importer des enregistrements, Réunions.

​
fs-format, frontmatter, tiptap

  • fs-format (crates/fs-format) : types sérialisables du fichier de transcription (TranscriptJson, TranscriptWithData, TranscriptWord, TranscriptSpeakerHint). Aucune dépendance interne.
  • frontmatter (crates/frontmatter) : Document analyse et sérialise un Markdown avec en-tête. Aucune dépendance interne.
  • tiptap (crates/tiptap) : tiptap_json_to_md, md_to_tiptap_json, tiptap_json_to_mdast, mdast_to_markdown, validate_tiptap_json, module merge. Aucune dépendance interne. crates/agent-access l’utilise pour convertir le corps des notes en Markdown dans les sorties de la CLI et du serveur MCP.
  • Pages de doc concernées : tiptap alimente CLI pour agents, Serveur MCP et Référence de la CLI ; fs-format et frontmatter : aucune.

​
Export

​
export-core

  • Chemin : crates/export-core
  • Rôle : produit le PDF d’une réunion avec Typst (typst, typst-pdf, polices de typst-assets).
  • API : export_pdf(path, input), render_pdf(input), types ExportInput, ExportMetadata, Transcript, TranscriptItem, ExportLabels (libellés des sections dans la langue de l’interface).
  • Dépendances internes : aucune.
  • À noter : seul le PDF passe par cette crate. Les autres formats d’export de l’application (TXT, Markdown, Org) et l’export Markdown ou JSON de la CLI n’en dépendent pas.
  • Pages de doc concernées : Notes (section « Exporter une réunion »).

​
Prompts et comptes rendus

​
template-app

  • Chemin : crates/template-app, gabarits dans crates/template-app/assets/*.md.jinja.
  • Rôle : rend les prompts envoyés au LLM. Les gabarits sont compilés avec Askama.
  • API : render(Template), enum Template (EnhanceSystem, EnhanceUser, TitleSystem, TitleUser, ChatSystem, ContextBlock, ToolSearchSessions, TranscriptPatchSystem, TranscriptPatchUser, ActivityCaptureSystem, DailySummarySystem, EventContactSystem…), EditableTemplate (EnhanceFormat, EnhanceUser, TitleUser) et template_source.
  • Dépendances internes : syntheo-askama-utils.
  • À noter : le plugin template expose render et get_template_source. L’interface lit la source de enhanceFormat dans le formulaire du modèle « Automatique » (apps/desktop/src/templates/auto-form.tsx).
  • Pages de doc concernées : Personnaliser les comptes rendus, Notes, Chat, Langues.

​
askama-utils

  • Chemin : crates/askama-utils
  • Rôle : filtres partagés par les gabarits (current_date, language, language_name, is_english, is_korean) et extraction des variables utilisées (extract, TemplateUsage).
  • Dépendances internes : aucune.
  • Pages de doc concernées : Langues.

​
summary

  • Chemin : crates/summary
  • Rôle : calcule la longueur cible du compte rendu selon la taille de la transcription et le nombre de sections du modèle, puis met en forme le texte généré (titre en première ligne, ligne de tags).
  • API : summary_length_policy, summary_length_policy_for_texts, prepare_generated_summary, compose_generated_summary, extract_tag_names. Le plugin template les expose comme commandes.
  • Dépendances internes : aucune.
  • Pages de doc concernées : Personnaliser les comptes rendus, Notes.

​
template-app-legacy

  • Chemin : crates/template-app-legacy
  • Rôle : ancien moteur MiniJinja hérité d’Anarlog, avec ses gabarits (enhance, title, chat, auto_generate_tags, postprocess_transcript, highlight).
  • Usage : le plugin template initialise son environnement au démarrage et s’en sert pour la commande render_custom, qu’aucun code de apps/desktop/src n’appelle hors tests.
  • Dépendances internes : aucune.
  • Pages de doc concernées : aucune.

​
Automatisation locale

​
hooks

  • Chemin : crates/hooks
  • Rôle : exécute les commandes shell configurées pour un événement et renvoie leur résultat.
  • API : HooksConfig, HookDefinition, HookEvent (beforeListeningStarted, afterListeningStopped), run_hooks_for_event, HookResult.
  • Usage : le plugin hooks lit la configuration sous la clé hooks des paramètres et l’interface déclenche les événements depuis apps/desktop/src/store/zustand/listener/general-live.ts.
  • Dépendances internes : aucune.
  • Pages de doc concernées : aucune. Cette fonction n’est pas documentée côté utilisateur ; elle est distincte des webhooks.

​
Notifications

crates/notification est la façade appelée par le plugin notification. Elle déduplique les notifications par clé, conserve leur contexte et délègue l’affichage au backend de la plateforme, activé par la feature legacy (active par défaut et demandée par le plugin).

​
Plateforme et identité

  • Pages de doc concernées : voir la colonne Remarques ; aucune pour host, user-error, shortcut-macos, overlay-kit et bundle.

​
Intégrations d’agents de code

crates/claude, crates/codex et crates/opencode pilotent les CLI Claude Code, Codex et OpenCode : options, flux d’événements, sessions ou threads, vérification d’installation (health_check_with_options) et lecture ou écriture de leur configuration. codex et opencode exposent aussi des liens profonds (new_thread_deeplink, open_project_deeplink).
  • Dépendances internes : syntheo-cli-process pour les trois.
  • Usage : seule crates/agent-core les utilise, pour installer un hook de notification dans la configuration de chaque agent (commande char … notify, héritée d’Anarlog). plugins/agent expose health_check, install_cli et uninstall_cli, mais aucun code de apps/desktop/src n’importe @syntheo/plugin-agent.
  • Pages de doc concernées : aucune. L’installation des compétences décrite dans Compétences ne passe pas par ces crates.

​
Outillage et données de test

  • data (crates/data) : échantillons audio WAV (anglais et coréen) inclus à la compilation. Dépendance normale de crates/audio-mock, dev-dependency de audio-actual, audio-utils, fs-sync-core, owhisper-client, resampler et vad. Pages de doc concernées : aucune.
  • xtask (crates/xtask) : cargo xtask prepare-binaries compile syntheo-cli en release pour la cible courante (TAURI_ENV_TARGET_TRIPLE ou triple de l’hôte) et copie le binaire dans apps/desktop/src-tauri/resources/cli/syntheo-cli-{triple}. Alias défini dans .cargo/config.toml. Pages de doc concernées : aucune directement ; le binaire préparé est celui qu’embarque l’application (voir Installation).