maximus/Simpl-Resultat
1
0
Fork 0
Code Issues 5 Pull requests Projects Releases 29 Packages Wiki Activity Actions
Simpl-Resultat/CLAUDE.md
le king fu 263ebe1495
All checks were successful
PR Check — Frontend / frontend (pull_request) Successful in 1m43s
Details
PR Check — Rust / rust (pull_request) Successful in 8m55s
Details
ci: split check.yml, drop dead caches, prebuild cargo-audit (#232) 
The rust job cost 21m44s on every PR while only ~1 PR in 40 touches
src-tauri/, and the runner has capacity 1 — the frontend job queues behind
it, so every PR paid ~24.5 min of feedback.

Measured on run 326 (2026-07-21), 12m15s of that was pure waste:
- 6m54s tarring target/ and the cargo registry for saves that time out
  against the runner's unreachable cache server (#234). The restore times
  out into a miss too, so nothing was ever cached at either end.
- 4m41s recompiling cargo-audit from source on every run.
- ~40s on the two doomed restores.

Split check.yml into check-rust.yml (paths: src-tauri/**) and
check-frontend.yml (paths-ignore denylist), drop every actions/cache step
until #234 is fixed, and install cargo-audit as a prebuilt binary via
taiki-e/install-action. The audit step keeps continue-on-error — advisories
are informational and can land on unrelated crates — but loses the `|| true`
that also hid tooling failures; the install step is blocking.

The frontend filter is a denylist on purpose: that job costs ~2.5 min, so
running it needlessly is cheap while silently not running it is not. The
expensive job keeps a strict allowlist.

Neither workflow filters on `branches:` anymore. `branches: [main]` never
matched a PR stacked on another feature branch, which is what /autopilot
produces: PRs #305-#308 of the feature-gating milestone ran no CI at all.

Adds audit.yml for daily RustSec coverage, since check-rust.yml now only
runs on Rust PRs. It skips the Rust toolchain entirely — cargo-audit only
reads Cargo.lock — so it costs ~1-2 min rather than the ~22 a scheduled
check-rust would burn daily on a capacity-1 runner.

The GitHub mirror is left untouched (#233: it receives no PRs).

Expected: Rust PR ~9-10 min, frontend-only PR ~2.5 min instead of ~24.5.

Resolves #232
2026-07-24 20:26:35 -04:00

9.9 KiB
Raw Blame History

CLAUDE.md — Simpl'Résultat

@STATE.md

Contexte du projet

Simpl'Résultat est une application de bureau desktop privacy-first pour la gestion des finances personnelles. Elle traite localement les fichiers CSV bancaires sans aucune dépendance cloud. Projet solo entrepreneurial, en développement par Max.

Stack technique : Tauri v2 + React 19 + TypeScript + Tailwind CSS v4 Backend : Rust (commandes Tauri) Stockage : SQLite local (tauri-plugin-sql) Langues supportées : Français (FR) et Anglais (EN) Plateformes : Windows, Linux Version actuelle : 0.6.3 Licence : GPL-3.0-only

Principes fondamentaux

Privacy-first — NON NÉGOCIABLE

  • Zéro donnée envoyée vers un serveur tiers
  • Tout le traitement CSV et toutes les données financières restent en local
  • Aucune télémétrie, aucun analytics cloud

Précision financière

  • Toujours valider les montants selon les règles de parsing configurables (gestion des virgules/points, espaces, symboles monétaires)
  • Gérer l'encodage des fichiers CSV (UTF-8, Windows-1252, ISO-8859-15)

Internationalisation (i18n)

  • Toute chaîne affichée à l'utilisateur doit passer par le système i18n (i18next + react-i18next)
  • Jamais de texte en dur dans les composants React
  • Fichiers de traduction : src/i18n/locales/fr.json et src/i18n/locales/en.json

Architecture & structure du code

src/
├── components/          # 53 composants React organisés par domaine
│   ├── adjustments/     # Ajustements
│   ├── budget/          # Budget
│   ├── categories/      # Catégories hiérarchiques
│   ├── dashboard/       # Tableau de bord
│   ├── import/          # Wizard d'import (13 composants)
│   ├── layout/          # AppShell, Sidebar
│   ├── profile/         # Profils (PIN, formulaire, switcher)
│   ├── reports/         # Graphiques et rapports
│   ├── settings/        # Paramètres
│   ├── shared/          # Composants réutilisables
│   └── transactions/    # Transactions
├── contexts/            # ProfileContext (état global profil)
├── hooks/               # 13 hooks custom (useReducer)
├── pages/               # 11 pages
├── services/            # 14 services métier
├── shared/              # Types et constantes partagés
├── utils/               # Utilitaires (parsing, CSV, charts)
├── i18n/                # Config i18next + locales FR/EN
├── App.tsx              # Router principal (react-router-dom)
└── main.tsx             # Point d'entrée

src-tauri/
├── src/
│   ├── commands/        # 3 modules, 17 commandes Tauri
│   │   ├── fs_commands.rs           # Système de fichiers (6 commandes)
│   │   ├── export_import_commands.rs # Export/import chiffré (5 commandes)
│   │   └── profile_commands.rs      # Gestion des profils (6 commandes)
│   ├── database/        # Schémas SQL et migrations
│   │   ├── schema.sql               # Schéma initial (v1)
│   │   ├── seed_categories.sql      # Seed catégories (v2)
│   │   └── consolidated_schema.sql  # Schéma complet (nouveaux profils)
│   ├── lib.rs           # Point d'entrée, 7 migrations inline, plugins
│   └── main.rs
└── Cargo.toml

Règles d'architecture :

  • La logique métier va dans services/, jamais directement dans les composants
  • L'état de chaque domaine est géré par un hook useReducer dédié dans hooks/
  • Les composants React sont responsables de l'affichage uniquement
  • Toute opération sur les fichiers système passe par les commandes Tauri (Rust)
  • Les requêtes SQL passent par les services TypeScript via tauri-plugin-sql

Fonctionnalités principales

  • Import CSV : wizard multi-étapes, détection auto de l'encodage/délimiteur, templates de config, déduplication par fichier
  • Catégorisation : automatique (mots-clés avec priorité) et manuelle, drag-and-drop pour réorganiser
  • Transactions : filtrage, tri, split sur plusieurs catégories, notes
  • Budget : grille 12 mois, templates réutilisables, budget vs réel
  • Rapports : tendances mensuelles, répartition par catégorie, évolution dans le temps, graphiques interactifs (SVG patterns, menu contextuel)
  • Multi-profils : bases de données séparées, protection par PIN (Argon2), switching rapide
  • Export/Import : JSON/CSV avec chiffrement AES-256-GCM optionnel (format SREF)
  • Mises à jour : auto-updater intégré (tauri-plugin-updater)
  • Changelog bilingue : page /changelog avec historique complet, notes de version dynamiques FR/EN depuis CHANGELOG.md / CHANGELOG.fr.md (bundlés dans public/)

Conventions de code

React / TypeScript

  • Un composant = un fichier .tsx, nommé en PascalCase
  • Hooks custom dans hooks/, services dans services/
  • État local via useReducer dans les hooks de domaine

Rust / Tauri

  • Toutes les commandes Tauri retournent Result<T, String> pour la gestion d'erreurs
  • Documenter chaque commande avec un commentaire sur son rôle

Général

  • Commits en anglais, commentaires de code en anglais
  • Messages d'interface en français ET anglais (via i18n)
  • Tester les cas limites de parsing CSV (montants négatifs, cellules vides, formats inattendus)

Base de données

  • 20 tables SQLite, 24 index (voir docs/architecture.md pour le détail). Le module Bilan en représente 7 tables (balance_categories, balance_accounts, balance_snapshots, balance_snapshot_lines, balance_account_transfers, puis balance_securities + balance_snapshot_holdings ajoutées en Étape 2 — détail par titre) et 9 index
  • 16 migrations inline dans lib.rs (v1→v16, via tauri_plugin_sql::Migration). Étape 2 (détail par titre) : v14 (balance_securities + balance_snapshot_holdings + 2 index), v15 (balance_accounts.kind + detailed_since + backfill), v16 (conversion des comptes cotés existants en détaillés 1-position). Voir ADR 0015
  • Schéma consolidé (consolidated_schema.sql) pour l'initialisation des nouveaux profils
  • Les migrations appliquées sont protégées par checksum — ne jamais modifier une migration existante, toujours en créer une nouvelle

Documentation technique

La documentation technique est centralisée dans docs/ :

  • docs/architecture.md — Architecture technique complète (stack, BDD, services, hooks, commandes Tauri, routing, i18n, CI/CD)
  • docs/adr/ — Architecture Decision Records (décisions techniques structurantes)
  • docs/guide-utilisateur.md — Guide utilisateur
  • docs/archive/ — Anciennes spécifications archivées

Règle : quand un changement touche l'architecture, mettre à jour la documentation :

  • Nouveau service, hook, commande Tauri, page/route, ou table SQL → mettre à jour docs/architecture.md
  • Décision technique structurante (choix de librairie, pattern architectural, changement de stratégie) → créer un nouvel ADR dans docs/adr/
  • Changement affectant l'utilisation de l'app → mettre à jour docs/guide-utilisateur.md et les traductions i18n correspondantes (src/i18n/locales/fr.json, src/i18n/locales/en.json, clés sous docs.*)

Règle CHANGELOG : tout changement affectant le comportement utilisateur → ajouter une entrée sous ## [Unreleased] dans les deux fichiers :

  • CHANGELOG.md (anglais) — source principale
  • CHANGELOG.fr.md (français) — traduction
  • Catégories : Added/Ajouté, Changed/Modifié, Fixed/Corrigé, Removed/Supprimé
  • Format Keep a Changelog. Le contenu est extrait automatiquement par le CI pour les release notes et affiché dans l'app selon la langue de l'utilisateur.
  • The public/ copies are synced automatically: Vite copies them on dev/build start via syncChangelogs() in vite.config.ts. No manual sync needed.

Points d'attention RS&DE / CRIC

Pour maintenir l'éligibilité aux crédits d'impôt R&D (RS&DE fédéral + CRIC Québec) :

  • Documenter les incertitudes technologiques rencontrées pendant le développement
  • Noter les expérimentations et les approches alternatives testées
  • Garder un journal des avancées techniques (dans /docs/rnd-journal/)
  • Les algorithmes de catégorisation automatique et le parsing multi-format sont des activités R&D éligibles

CI/CD

Workflows Forgejo Actions dans .forgejo/workflows/. Le runner est à capacité 1 — les jobs se suivent, ils ne tournent pas en parallèle.

  • check-rust.yml — déclenché sur les PR touchant src-tauri/**. Lance cargo check, cargo test et un cargo audit informatif. Doit être vert avant tout merge.
  • check-frontend.yml — déclenché sur les PR, sauf si tous les fichiers modifiés sont du Rust, de la doc ou du markdown. Lance npm run build (tsc + vite) et npm test (vitest). Doit être vert avant tout merge.
  • audit.yml — audit RustSec quotidien (06:00 UTC) + workflow_dispatch, pour couvrir les avis de sécurité entre deux PR Rust. Échec bloquant.
  • release.yml — déclenché par les tags v*. Build Windows (NSIS .exe) + Linux (.deb, .rpm), signe les binaires et publie le JSON d'updater pour les mises à jour automatiques.

Aucun workflow check-* ne filtre sur branches: : une PR stackée sur une autre branche de feature déclenche donc bien la CI. Le cache Actions est retiré partout tant que #234 (connectivité du serveur de cache) n'est pas réglé — restore et save échouent tous les deux. Le miroir .github/workflows/ est dormant (aucune PR côté GitHub).

Ressources clés