Simpl-Resultat/STATE.md

STATE — Simpl'Résultat

Derniere MAJ : 2026-10-17 (#369 mergée et fermée — la Répartition réservée à l'édition Base, PR #452 en avance rapide par l'API, main a8c3fd6. En Gratuite, le bouton de la page Transactions porte un cadenas et ouvre l'écran de déverrouillage, jamais la fenêtre de répartition ; les répartitions existantes restent comptées. Suivis #451 et #454. audit.yml rouge depuis le 2026-10-17 (run 558) : trois avis sur zip 4.6.1, tiré pour Windows seulement par tauri-plugin-updater, à trancher avant le prochain tag. Aucune migration (v1→v17).)

Précédente MAJ : 2026-10-16 (#447 mergée et fermée — rustls 0.23.45 → 0.23.46, PR #448 en avance rapide par l'API, main 1763a9f. RUSTSEC-2026-0346 à -0349, non atteignables, rougissaient audit.yml depuis le 2026-10-15 ; vert de nouveau sur main (run 556). Pas de release corrective, le cycle réel de mise à jour est dû au prochain tag. Suivis #449 et agent-defenseurs#186. Aucune migration (v1→v17).)

Position actuelle

v0.9.1 shippée (2026-05-10). Milestones spec-refonte-rapports, spec-refonte-seed-categories-ipc, spec-price-fetching, overnight-2026-04-26-bilan et overnight-2026-04-27-prices complétées et fermées. Maximus-api 0.3.0 LIVE en prod (api.lacompagniemaximus.com) — pubkey Ed25519 alignée, smoke test Phase B (#161) validé. Backlog actif concentré sur spec-monetisation (7/12) : activation en ligne (#53), pipeline Stripe desktop (#50, #52) et maximus-api Stripe webhooks (#135, #136).

Audit critique de la page Bilan livré (docs/audit-bilan-2026-05.md, revue CPA + UX). Étape 0 — quick wins terminologie « catégorie »→« type », symbole optionnel, date de snapshot déplaçable — mergée (#201, issues #198/#199/#200 fermées). Chantier structurel = Étapes 1-2 de l'audit (séparation véhicule fiscal × classe d'actif via vehicle_type, puis détail par titre balance_securities+holdings+book_cost, bascule agrégé→détaillé, réouverture ADR 0012). Étape 1 livrée (sprint 2026-06-01 : PRs #206-#209 mergées, milestone overnight-2026-06-01-bilan-axe-vehicule fermée 4/4) — vehicle_type nullable = enveloppe fiscale portée par le compte, catégorie = pure classe d'actif (5 classes), migrations additives v12/v13 (v1-v11 intactes), renommage via custom_label (fix bug I), axe graphique classe/enveloppe + rendements repliables persistés ; ADR 0014 Accepted, ADR 0012 Rejected. CHANGELOG sous [Unreleased] (pas encore taggé). Étape 2 livrée (merge manuel 2026-06-09 : pile de 9 PRs stackées #219-#227 mergées bottom-up, milestone overnight-2026-06-05-bilan-detail-titres à 9/10, issues #210-#218 fermées) — détail par titre via balance_securities + balance_snapshot_holdings, balance_accounts.kind ('simple'|'detailed') + detailed_since, migrations additives v14/v15/v16 (v1-v13 intactes), conversion des comptes cotés existants en détaillés 1-position (v16), service securities transactionnel, reducer holdings + dispatch account.kind, UI multi-titres (SecurityPicker), assistant détailler-un-compte (date pivot), drill-down par titre + gain latent, tests intégration/régression ; ADR 0015 Accepted. #228 mergé (PR #229, fix-forward : garde d'abort v16 scopée aux comptes convertibles via JOIN balance_categories + c.asset_type IS NOT NULL dans les 3 copies — Migration v16 / V16_SQL / V16_CORRUPT — + test régression ; CI vert car #229 ciblait main) → milestone overnight-2026-06-05-bilan-detail-titres complète 10/10 et fermée. v0.10.0 shippée (2026-06-29 : Étapes 1+2 du bilan, migrations v12→v16) puis hotfix v0.10.1 (2026-06-30, PR #230, déployé) — corrige un « database is locked » introduit en 0.10.0 (apparaissait après l'abandon d'un snapshot en cours) : tout l'accès DB est désormais sérialisé via withTransaction dans db.ts (tauri-plugin-sql = pool sqlx multi-connexions sans primitive de transaction JS → BEGIN/COMMIT en db.execute séparés pouvaient strander une transaction d'écriture = verrou zombie), appliqué aux 5 sites transactionnels ; + console de log live-update + API logInfo/logWarn/logError. 20 tables / 24 index, 16 migrations (v1→v16).

Milestone deps-security-2026-07 livrée (2026-07-01, 4/4 fermée) — 4 vulns de dépendances Defenseur remédiées en 2 PRs (#239 react-router-dom 7.18.1 ; #240 vite 6.4.3 + vitest 4.1.9) ; npm audit 5→0 — le dernier @babel/core low remédié le 2026-07-04 (override scopé @vitejs/plugin-react→@babel/core@^7.29.7, issue #241 / PR #242 mergée). Ce « 0 » n'a pas tenu : des advisories publiées depuis l'ont ramené à 3 (#311, 2026-07-27, 2 acceptées sur react-router), puis à 8 ; 0 de nouveau au 2026-10-10 par le rafraîchissement du lock de #358 (mergé le 2026-10-12), qui ferme aussi #317. Nouveau milestone spec-ci-build-optimization (2/4) ouvert (baseline #231 : cause #2 = reserveCache timeout du runner ; #234 connectivité cache VPS, #232 split workflows).

v0.11.0 shippée (2026-07-05, tag v0.11.0 → CI release Windows/Linux + JSON updater) — milestone overnight-2026-07-05-bilan-rapports-ux complétée 5/5 et fermée via un run /autopilot (5 workers séquentiels, PRs #248-#252 toutes /pr-review APPROVE, puis merge local de la pile + réconciliation Forgejo). Contenu : rapport comparable réel-vs-réel hiérarchique avec sous-totaux (#247) ; netting des transferts ciblé (catégories type transfer → SUM signé ~0, autres types inchangés au byte) dans le compare (#243) ; landing Bilan en tuiles HubReportNavCard + guard empty-state découplé + gestion comptes accessible partout (#244) ; import CSV de titres dans un snapshot détaillé (front pur, autoDetectHoldingColumns, prix flexible) (#245) ; cible de migration catégories éditable sur chaque ligne + type-ahead CategoryCombobox feuilles-seulement (#246). Aucune migration DB (v1→v16 inchangées), 20 tables / 24 index, 16 migrations. Point de suivi non bloquant : nets de transfert signés traversent du code UI compare pensé pour des magnitudes positives (mord seulement les transferts déséquilibrés à une jambe).

v0.12.0 shippée (2026-07-05, tag v0.12.0 → CI release #311) — recadrage de #243 (montants de transfert inclus dans le comparable) par Max en « analyse de résultat » : deux rapports comparables refondus en états de résultat (income statement). Le compare réel-vs-réel (#253) et le tableau de tendance par catégorie (#256) affichent le revenu, un Résultat avant transferts (revenus − dépenses) et un Résultat net (après transferts), sections ordonnées revenu→dépense→transfert ; les rapports comparables ouvrent par défaut sur le mois complet précédent (#253). Modules purs extraits et testés (compareResults.ts, overTimeResults.ts) ; 2 blocages /pr-review corrigés (fuite du revenu dans les top-movers Cartes ; garde StrictMode sur le sync du mois de référence). Livré en 2 issues/PRs stackées #255→#257 (merge local + réconciliation Forgejo, branches supprimées), 701 vitest verts, aucune migration DB (v1→v16 inchangées), 20 tables / 24 index. Backlog ouvert au passage : #258 (db-locked proposeStarterAccounts) → fermé le 2026-07-07 (déjà corrigé v0.10.1, pas de nesting) ; #254 (collapse/expand) → livré le 2026-07-07 (PR #261) ; #259 (mapping manuel d'un compte standard sans similaire auto) et #260 (epic « rapports uniformes » — tous les rapports sur le modèle income-statement) ouverts.

v0.15.0 shippée (2026-09-12, tag v0.15.0 → CI release run 402, 7 artefacts + latest.json vérifiés) — première version où le gating par édition est actif : sans clé, Budget, Ajustements, rapports avancés, profils multiples, Bilan et mises à jour automatiques sont verrouillés (données intactes, ADR 0017). Les deux testeurs (Max, Michel) ont une clé Premium émise avant le tag. [Unreleased] vide. Aucune migration DB nouvelle (v1→v17). Étape 10 de /release consignée le 2026-09-13 : cycle réel v0.14.0 → v0.15.0 validé par les deux testeurs, trace rédigée pour le corps de la release Forgejo (invite polkit Linux non consignée, .rpm hors test → #320).

v0.16.0 shippée (2026-10-03, tag v0.16.0 → CI release run 451, 7 artefacts + latest.json vérifiés, registre de l'updater en 0.16.0) — première version vendable de bout en bout : « Obtenir Base » ouvre la page produit (#346), le client de licence parle /v1 et nomme chaque refus (#270), l'édition ne dépend que de la clé (#347), l'activation envoie un identifiant dérivé (#350), une clé révoquée retombe en Gratuite après un contrôle au démarrage (#365), et rustls 0.23.45 (#348). [Unreleased] vidé au tag. Aucune migration DB nouvelle (v1→v17). Sur la release publiée : #365 vérifiée et fermée le 2026-10-03, étape 10 de /release faite sous Linux le même jour (trace dans le corps de la release) ; étape 10 sous Windows faite par Michel (confirmée le 2026-10-10) ; #350 fermée et #346 vérifiée le 2026-10-04.

Onboarding phase 1 mergée sur main (2026-10-04, 667e058, publiée dans la v0.17.0) — milestone planned-2026-10-03-onboarding-phase1 fermée 7/7 (#351-#357, PRs #377-#383, produites par /autopilot le 2026-10-03 puis relues une à une par /pr-review) : états vides guidés (dashboard, Import, Transactions, Budget), liste de démarrage à 6 cases calculée depuis la base, bouton « Créer un dossier d'exemple », guide « Exporter un CSV depuis votre banque » (Desjardins, Tangerine, RBC, BNC, BMO). Aucune migration DB (v1→v17). Suivis : #384 (non bloquants) et #371 (BMO sur compte réel, saisie de Max).

Suites de licence mergées sur main (2026-10-05, 2cbc886, publiées dans la v0.17.0) — milestone planned-2026-10-03-suites-licence fermée 3/3 (#373, #370, #367 ; PRs #386 → #388, produites par /autopilot le 2026-10-04, relues par trois /pr-review APPROVE, suivis appliqués en tête de pile) : contrôle d'une clé révoquée dès sa saisie (au plus une fois par 24 h et par clé), « Retirer la clé » dans la carte Licence (place libérée d'abord sur une machine activée, contrôle quotidien arrêté), jeton d'une ancienne licence retiré sur un refus des cours ou à l'ouverture de la liste des machines. Aucune migration DB (v1→v17). Suivi : #389 (huit autres fichiers de tests au faux t brut).

v0.17.0 shippée (2026-10-05, tag v0.17.0 sur 07255e1 → CI release run 491 en 22 min, 7 artefacts + latest.json vérifiés par verify-release.sh, endpoint de l'updater en 0.17.0) — onboarding phase 1 et suites de licence. [Unreleased] vidé au tag. Aucune migration DB nouvelle (v1→v17). Étape 10 de /release non exigée (chaîne de mise à jour inchangée), raison écrite sur la release. Vérifications manuelles des suites de licence faites sur la release publiée (confirmées le 2026-10-10).

Parcours de démarrage guidé mergé sur main (2026-10-08, ee17f31, publié dans la v0.17.1) — milestone planned-2026-10-06-onboarding-parcours-guide fermée 6/6 (#396-#401, PRs #402 → #407, produites par /autopilot le 2026-10-08, relues par six /pr-review APPROVE, suivis appliqués en tête de pile) : bandeau « Démarrage n/N · Étape suivante » sur chaque page, cartes d'étape avec mise en évidence du contrôle sur Import, Transactions et Budget, état partagé par un fournisseur et canal d'événements de données (ADR 0022), règle D9 (un profil déjà actif trouve le parcours masqué). Aucune migration DB (v1→v17). Suivis : #408 (db.ts hors verrou pendant une transaction) et #409 (harnais de test).

v0.17.1 shippée (2026-10-08, tag v0.17.1 sur e4db715 → CI release run 508, 7 artefacts + latest.json vérifiés par verify-release.sh, endpoint de l'updater en 0.17.1) — parcours de démarrage guidé et #390 (étape 5 de la liste, rattrapage des migrations des profils secondaires, dossier des bases sous Linux). Numéro de correctif choisi par Max malgré les entrées Added. [Unreleased] vidé au tag. Aucune migration DB nouvelle (v1→v17). Étape 10 de /release non exigée (chaîne de mise à jour inchangée), raison écrite sur la release. Vérifications manuelles faites sur la release publiée (parcours guidé, #390), complétion confirmée le 2026-10-10.

Chaîne de release et dépendances mergée sur main (2026-10-12, 9e8c41b, pas encore publiée) — milestone planned-2026-10-10-release-deps fermée 4/4 (#376, #345, #320, #358, plus #317 ; PRs #414 → #417 produites par /autopilot le 2026-10-10 et relues par quatre /pr-review APPROVE, puis PR #418 de suivis des revues, relue à son tour) : Node 24 dans les trois workflows encore en Node 20 ; garde Verify windows-sys pinning dans check-rust (ADR 0023) ; latest.json avec une clé par paquet Linux (linux-x86_64-deb, linux-x86_64-rpm) et sans clé générique, contrôlé avant le DELETE du registre par scripts/check-latest-json.jq ; lock npm rafraîchi, npm audit à 0. Aucune migration DB (v1→v17). [Unreleased] porte un Corrigé (#320) et un Sécurité (#358). Suivi : #419 (point 1 avant le prochain tag).

#423 mergée sur main (2026-10-12, 8898213, pas encore publiée) — les champs « Catégorie parente » (formulaire de catégorie) et « Catégorie » (dialogue « Nouveau mot-clé ») utilisent CategoryCombobox : saisie qui filtre, ordre hiérarchique, noms du seed traduits. Liste des parents : racines et niveau 1, moins la catégorie éditée, profondeur réduite de la hauteur de son sous-arbre (pas de 4ᵉ niveau), parent courant toujours gardé ; seule garde aujourd'hui, updateCategory ne vérifie rien (#393). Le dialogue mot-clé prend la liste des Transactions (actives et saisissables, D2) et ne garde la catégorie pré-remplie que si elle en fait partie. [Unreleased] porte un Modifié. Suivi : #429. Aucune migration (v1→v17).

Fiabilité des tests et de db.ts mergée sur main (2026-10-13, c17bf5d, pas encore publiée) — milestone planned-2026-10-10-fiabilite-tests fermée 4/4 (#408, #409, #389, #395 ; PRs #433 → #436 produites par /autopilot le 2026-10-12, relues par quatre /pr-review APPROVE, cinq commits de suivi en tête de pile) : withTransaction remet au rappel son propre handle, révoqué à la fin, toute autre requête attend derrière le verrou ; changement de profil en une seule section exclusive avec numéro de génération ; alerte Journal après 15 s d'attente ; harnais src/test/hookHarness.ts et faux t marqué src/test/i18nMock.ts, gardé par src/__integration__/i18n-mock-guard.test.ts ; le Journal nomme la copie d'un rattrapage arrêté et ne contient plus de chemin, une seule copie gardée par profil, la page d'erreur du démarrage disparaît quand le profil s'ouvre après le délai ; badge « non garanti » traduit. [Unreleased] porte un Modifié et deux Corrigé de plus. Suivi : #437. Aucune migration (v1→v17).

Retours d'onboarding de la v0.17.1 mergés sur main (2026-10-15, 934bcbf, pas encore publiés) — milestone planned-2026-10-12-retours-onboarding-v0171 fermée 8/8 (#424, #422, #427, #426, #430, #431, #425, #432 ; PRs #438 → #445 produites par /autopilot le 2026-10-13, relues par huit /pr-review APPROVE sans bloquant) : grille Budget émise en profondeur et sous-totaux en bas rattachés à leur bloc (reorderRows, corrige aussi Budget vs réel et Comparables) ; encadré « Structure attendue » (un sous-dossier par compte), avertissement des CSV posés à la racine (scan_import_folder → ImportFolderScan), nom de source en lecture seule = sous-dossier ; cartes Transactions (« Ajouter comme mot-clé ») et Budget (feuilles, colonne Annuel) ; aide et guide périmés corrigés ; parcours à huit lignes avec deux étapes de visite (Catégories, Rapports) cochées par « J'ai compris » ou un clic sur Tendances, initialisées une fois par profil sans transaction (ADR 0022 amendé). [Unreleased] porte des Added, Changed et Fixed de plus. Suivi : #446. Aucune migration (v1→v17).

#447 mergée sur main (2026-10-16, 1763a9f, pas encore publiée) — rustls 0.23.45 → 0.23.46 (PR #448 : deux lignes de Cargo.lock, aucun bump compagnon, aucune arête windows-sys déplacée) corrige RUSTSEC-2026-0346 à -0349, publiées le 2026-10-14, qui rougissaient audit.yml depuis le 2026-10-15 sans que le lock ait bougé depuis la v0.17.1. Aucune des quatre n'est atteignable (rustls n'est atteint que par tauri-plugin-updater → reqwest 0.13), mais la règle 1 de .cargo/audit.toml demande de corriger plutôt que de supprimer ; audit.yml est de nouveau vert sur main (run 556). Pas de release corrective : le bump part avec le prochain tag, qui devra dérouler le cycle réel de mise à jour. [Unreleased] porte un second Sécurité. Suivis : #449 et agent-defenseurs#186. Aucune migration (v1→v17).

#369 mergée sur main (2026-10-17, a8c3fd6, pas encore publiée) — la Répartition (bouton de la page Transactions) est réservée à l'édition Base, comme l'écran de déverrouillage le promettait (upsell.features.adjustments) : en Gratuite, le bouton garde sa place, porte un cadenas et ouvre l'écran verrouillé dans une fenêtre (UpsellDialog) au lieu de la fenêtre de répartition, pour toute ligne ; tant que la licence n'est pas ready, bouton inactif, ni cadenas ni fenêtre ; les répartitions existantes restent comptées et gardent l'icône orange. Pièces : splitAccessFor (src/shared/splitGate.ts, open/locked/pending, plus strict que profileGate : allowed ne court-circuite pas ready) et la constante SPLIT_FEATURE, SplitButton, UpsellDialog, prop splitAccess obligatoire de TransactionTable, calculée par TransactionsPage depuis useEntitlement(SPLIT_FEATURE) ; ADR 0017 amendé, guide, docs intégrées FR/EN et architecture.md à jour, [Unreleased] porte un Modifié de plus. Suivis : #451 (fenêtre d'incitation de ProfileSwitcher sur UpsellDialog, Échap, focus) et #454 (reclasser une transaction répartie laisse sa ligne de compensation dans l'ancienne catégorie, irréparable en Gratuite depuis #369). Aucune migration (v1→v17).

Decisions recentes

• 2026-10-17 : #369 mergée — /fix-issue (plan check refusé une fois) → /pr-review APPROVE → deux commits de suivi en tête → merge ff par l'API (PR #452, main a8c3fd6) : la Répartition réservée à l'édition Base. L'écran de déverrouillage la rangeait déjà en Base (upsell.features.adjustments) alors que l'app la laissait ouverte en Gratuite ; désormais, en Gratuite, le bouton garde sa place, porte un cadenas et ouvre l'écran verrouillé (UpsellDialog) pour toute ligne, jamais la fenêtre de répartition ; bouton inactif tant que la licence n'est pas ready ; répartitions existantes comptées, icône orange gardée. splitAccessFor est plus strict que profileGate (allowed ne court-circuite pas ready) ; TransactionTable ne rend pas la fenêtre de répartition en locked mais la garde pendant un rafraîchissement de licence, et ne rend pas l'incitation en open. Refus du plan check (MAJOR) : le câblage de TransactionTable n'était pas testé, d'où TransactionTable.wiring.test.ts sur le harnais hookHarness de #409 ; second passage : pass. Preuves : 21 mutations de l'auteur, toutes rouges ; revue (commentaire 24129) avec 14 des 15 mutations du relecteur rouges, la survivante R14 (un clic verrouillé qui ouvrirait aussi la fenêtre de répartition) épinglée par d5d0e89 ; a8c3fd6 réunit la clé de la Répartition dans SPLIT_FEATURE ; ces deux commits en tête, non relus, sont nommés dans le commentaire 24148 ; tip en worktree npm ci propre (sonde rc=1, build, 2248 vitest sur 134 fichiers, contre 2222) ; CI 557 et 559 ; #369 fermée par le merge. Site : le tableau comparatif de la-compagnie-maximus#180 (PR #298 de ce dépôt-là), en production depuis le 2026-10-16, range déjà la Répartition en Base, en avance sur l'app, décalage accepté par Max ; commentaire 24164 posé le 2026-10-17 (mergé, publié avec la prochaine release, pas encore disponible). Suivis : #451 (incitation de ProfileSwitcher sur UpsellDialog, Échap, focus) et #454 (type:bug, compensation d'une transaction répartie laissée dans l'ancienne catégorie au reclassement, car updateTransactionCategory ne touche que le parent ; rare, mais irréparable en Gratuite depuis #369). Aucune migration (v1→v17). (ref #369, PR #452, #451, #454, la-compagnie-maximus#180)
• 2026-10-16 : #447 mergée — /fix-issue (plan check refusé une fois) → /pr-review APPROVE → merge ff par l'API (PR #448, main 1763a9f) : rustls 0.23.45 → 0.23.46, corrigeant RUSTSEC-2026-0346 à -0349. Publiés le 2026-10-14, les quatre avis rougissaient audit.yml (runs 553 et 555) sans que le lock ait bougé depuis la v0.17.1 ; repérés par la Phase 5.6 du /warmup le 2026-10-15, pas par le Défenseur, dont le check deps ne lance jamais cargo audit (décision de Max le 2026-10-15 : sous-check cargo-audit, agent-defenseurs#186). Aucun n'est atteignable (rustls atteint par tauri-plugin-updater → reqwest 0.13 seulement ; fournisseur ring sans groupe post-quantique, brotli non compilée, ni ECH ni ClientSessionStore maison), mais la règle 1 de .cargo/audit.toml dit corriger, pas supprimer. Diff : deux lignes de Cargo.lock, aucun bump compagnon, aucune arête windows-sys déplacée, une puce Sécurité par CHANGELOG. Refus du plan check (MAJOR) : « No behaviour change » avait déjà été recadré par 9abf474 au bump précédent, et la 0.23.46 apporte une dizaine d'autres corrections de la couche TLS (21 fichiers de src/ en amont), donc l'entrée restreint « aucun changement » au code de l'application ; second passage : pass. Preuves : cargo-audit 0.22.2 (binaire de la CI) rouge sur l'arbre intact (4 IDs) puis vert ; check-rust run 554 lu ligne à ligne (gardes 2/2 et 9/9, 267 tests, 0 vulnérabilité ; à froid, rustc 1.99.1 du 2026-10-13 ayant changé la clé du cache) ; revue (commentaire 23853) avec mutation inverse rouge sur les quatre IDs ; tip en worktree propre (npm ci, sonde rc=1, build, 2222 vitest, cargo test --locked à 267, gardes, audit exit 0) ; après le merge, audit.yml en workflow_dispatch sur main : run 556 vert (666 crates, 12 warnings autorisés, 0 vulnérabilité). PR en Refs #447 (critère post-merge), d'où une fermeture à la main (commentaire 23894). Pas de release corrective (décision de Max) : le bump part avec le prochain tag, cycle réel de mise à jour compris. Acquis : cargo-audit écrit « 1 vulnerability found! » mais « N vulnerabilities found! », chercher vulnerabilit(y|ies) found ou error: [0-9]+ vulnerabilit ; le journal de check-rust porte des codes ANSI (CARGO_TERM_COLOR=always) à retirer avant tout grep. Suivi #449 (--locked absent de check-rust.yml et de release.yml). Aucune migration (v1→v17). (ref #447, PR #448, #449, agent-defenseurs#186)
• 2026-10-15 : Milestone planned-2026-10-12-retours-onboarding-v0171 mergée — /autopilot (8 workers en série, 1 h 14, worker N+1 lancé pendant la CI du maillon N, CI lue à chaque maillon, runs 543-551) → huit /pr-review APPROVE en parallèle (aucun bloquant) → merge ff par l'API, chaque enfant reciblé sur main (main 934bcbf, 8 PRs merged). Tip éprouvé en worktree npm ci propre : sonde rc=1, build, 2222 vitest (2065 avant), 267 Rust. 31 décisions HIGH, 25 MEDIUM, 0 LOW ; mutations des workers et des relecteurs presque toutes rouges, les survivantes sans effet de comportement ou épinglées. Acquis : deux workers sur huit ont perdu leur implémentation non commitée au git checkout -- de la passe de mutations → consigne « commit avant la première mutation » ajoutée en cours de run, zéro incident ensuite ; les corps de PR des workers ne portent pas Resolves #N en clair (seulement les commits), sans effet sur un merge ff. Trou global relevé par deux revues : aucun test ne détecte une clé i18n présente dans une seule langue (#446). Aucune migration (v1→v17). (ref #424, #422, #427, #426, #430, #431, #425, #432, PRs #438-#445, #446)
• 2026-10-13 : Milestone planned-2026-10-10-fiabilite-tests mergée — /autopilot (4 workers en série, 1 h 25, CI lue à chaque maillon) → quatre /pr-review APPROVE en parallèle → suivis en tête de pile → merge ff par l'API, chaque enfant reciblé sur main (main c17bf5d, 4 PRs merged). Mesure du rattrapage : 306 ms en release pour 100 001 transactions (T490, NVMe), sous la règle des 3 s, donc STARTUP_TIMEOUT_MS reste à 10 000 (ADR 0021). Inventaire de #389 : 27 fichiers et non 24, trois mocks bruts venus de #423. Suivis appliqués en tête (74fae14, a1c31a1, ac3a981, 86eff9b, c17bf5d), non relus : close() d'un ancien proxy rejeté, échec de fermeture consigné sans bloquer le changement de profil, withoutFolders qui ne laisse plus passer un dossier contenant une espace, garde i18n plus stricte, badge traduit. Tip éprouvé en worktree npm ci propre : sonde rc=1, tsc, build, 2065 vitest, 262 Rust. ADR 0024 (serveur MCP, Proposed) rebasé sur le merge puis poussé (977ef3a). Acquis : l'orchestrateur a d'abord contredit à tort un constat juste du worker (badge best-effort codé en dur), sur un grep tronqué par head ; ne jamais conclure à l'absence depuis une sortie tronquée. Aucune migration (v1→v17). (ref #408, #409, #389, #395, PRs #433-#436, #437)
• 2026-10-12 : #423 mergée (PR #428, main 8898213) — menus déroulants de catégorie avec saisie dans le formulaire de catégorie et le dialogue mot-clé. Issue créée et analysée le jour même (/analyze : types Category vs CategoryTreeNode incompatibles → type structurel CategoryLike sur le combobox ; le formulaire ne connaissait pas l'id édité → prop editingId ; deux listes différentes → D2 de Max : liste des Transactions ; D1 : #423 porte l'exclusion UI, #393 garde la validation service). Plan check refusé une fois (la liste absolute était rognée par le scrollport du dialogue, réglé en sortant les champs du bloc défilant). Première revue REQUEST_CHANGES : la règle ne regardait que les enfants directs, une racine avec petits-enfants pouvait recevoir un parent (4ᵉ niveau) ; corrigé par la hauteur du sous-arbre, test rouge d'abord sur la sonde du relecteur. Seconde revue APPROVE, quatre suivis appliqués en tête (8898213, non relu : commentaires #393 corrigés, garde de cycle épinglée, espions sur buildParentOptions, garde redondante retirée). Preuves : 1963 vitest, 9 mutations rouges de l'auteur (une survivante remplacée : la règle « descendance » était impliquée par la règle de profondeur), CI 526-528, worktree npm ci propre. Acquis : /commits/<sha>/statuses renvoie l'historique (pending puis success), lire /commits/<sha>/status agrégé ; head_commit_id du merge exige le SHA complet (409 « head out of date » sur un SHA court). Aucune migration (v1→v17). (ref #423, PR #428, #429, #393)
• 2026-10-12 : Milestone planned-2026-10-10-release-deps mergée — /autopilot (4 PRs stackées en 1 h 50, CI lue dans les journaux à chaque maillon) → quatre /pr-review APPROVE → PR #418 de suivis en tête de pile → /pr-review APPROVE → merge ff par l'API, chaque enfant reciblé sur main (main 9e8c41b, 5 PRs merged).
  • Décision de Max : clé générique linux-x86_64 retirée de latest.json. Le worker de #320 puis la revue ont mesuré que ses seuls lecteurs (AppImage v0.4.3 à v0.4.5, binaire hors paquet) ne savaient pas installer le .deb qu'elle servait, et que les 64 tags qui embarquent l'updater (plugin 2.10.0) cherchent d'abord la clé de leur paquet : ces lecteurs reçoivent désormais TargetsNotFound, rien n'est installé.
  • Suivis des revues dans une 5ᵉ PR (#418) plutôt qu'en commits sur #417 : le retrait touche la garde d'avant le DELETE du registre, catégorie « garde de destruction » de /merge-stack, donc relue avant le merge, et les quatre têtes revues n'ont pas bougé. Le contrôle passe dans scripts/check-latest-json.jq, exercé à chaque PR par le test du script (11 → 28 tests, 10 mutations rouges, vert sous jq 1.6) ; /release rejoue le garde windows-sys juste après l'édition de Cargo.lock.
  • Constats : la prémisse « pas de Python dans le conteneur » de #345 était fausse (ADR 0023 corrigé) ; le déclencheur de la dérive windows-sys n'est pas « hyper et ce qu'il tire » (f4b09b0, #310) ; react-router 7.18.3 valide les navigations (150 contrôles sur les cibles de l'app, aucun échec) ; /actions/tasks ne liste un job qu'une fois pris par le runner, seuls les statuts de commit voient la file.
  • Restes : #419, dont le point 1 (sous jq 1.6, le filtre accepte un latest.json vide ou à deux documents, inatteignable aujourd'hui) à corriger avant le prochain tag ; vérifications de la prochaine release dans Blockers ; vérification de la navigation dans l'app lancée (Linux, Windows), confirmatoire.
  • Aucune migration DB (v1→v17). (ref #376, #345, #320, #358, #317, PRs #414-#418, #419, ADR 0023)
• 2026-10-08 : v0.17.1 taggée et publiée (e4db715, run 508 vert), sur demande de Max (« /deploy et nouveau release 17.1 »). Pré-vol du skill sur le tip 6de73b3 : build, 1904 vitest, cargo check sans avertissement, 255 Rust ; .claude/worktrees/ vide. Diff depuis v0.17.0 : Cargo.lock, release.yml et tauri.conf.json inchangés, seul ajout au manifeste Rust une dépendance de test (tauri avec la feature test, #390), rien sur le gating par édition : ni clés testeurs à émettre, ni cycle de mise à jour réel exigé (étape 10), la raison étant écrite dans le corps de la release. Numéro : [Unreleased] portait 6 entrées Added, et la convention (v0.16.0, v0.17.0) aurait donné une mineure ; question posée, Max a gardé 0.17.1. 5 manifestes, 2 changelogs et la ligne de CLAUDE.md, Cargo.lock édité à la main et accepté par cargo metadata --locked. Tag annoté poussé seul (jamais --tags). Run 508 ; verify-release.sh vert (7 artefacts, signatures et URL en 0.17.1) ; l'endpoint de tauri.conf.json (registre de paquets) sert la 0.17.1. Les vérifications manuelles (parcours guidé, post-merge de #390) passent après la publication, comme pour la v0.16.0. Aucune migration DB (v1→v17). (ref v0.17.1, #396-#401, #390)
• 2026-10-08 : Parcours de démarrage guidé livré de bout en bout — /autopilot (6 PRs stackées en 3 h, CI verte à chaque maillon) → six /pr-review APPROVE → sept commits en tête de pile → merge ff par l'API (main ee17f31).
  • Revues : aucun bloquant, un verdict indépendant par PR (commentaires 20659 à 20730) ; status:approved posé par les seuls relecteurs, les workers ayant laissé status:review (skill corrigé).
  • Décision de Max : voie A sur le critère de #398 « pas de « Fait. » pour un import qui n'ajoute rien ». Le relecteur a corrigé le rapport du run : les doublons seuls sont sans effet (leurs transactions sont venues avec un fichier completed) ; le vrai cas est l'import sans ligne valide (en-tête seul, format mal détecté), qui cochait l'étape 4 et faisait boucler /transactions et /import. L'étape compte désormais les imported_files en completed ayant au moins une transaction (EXISTS sur transactions.file_id, index idx_transactions_file), avec une entrée Corrigé : la v0.17.0 a déjà le défaut.
  • Autres suivis en tête : D9 lit son drapeau hors transaction, donc plus de BEGIN/COMMIT à chaque ouverture, pendant lesquels db.ts laisse tout passer hors verrou ; :focus-visible { outline: revert } sur le contrôle entouré (WCAG 2.4.7) ; carte Budget sans cible sur l'état vide ; épingles (séquence réelle du reducer, phrase selon le filtre, notification de restauration hors verrou, fuseau du test du mois) ; docs et liste QA à 44 cas.
  • Preuves : 16 mutations sur ces correctifs, toutes rouges, dont 4 survivantes des revues ; compteur rejoué avec sqlite3 sur le schéma consolidé ; tip en worktree npm ci propre (sonde rc=1, build, 1904 vitest) ; CI 507. Les commits ajoutés après la revue, non relus, sont nommés dans le commentaire 20835 de #407.
  • Merge : chaque enfant reciblé sur main puis mergé en ff épinglé, branches gardées jusqu'au dernier merge puis supprimées, donc 6 PRs merged. #384 : trois items cochés (réglés par la pile), #382 en partie.
  • Acquis : au /plan-run, confronter un critère à la définition du compteur hérité qu'il suppose (celui de l'étape 4 venait de la phase 1).
  • Aucune migration DB (v1→v17). (ref #396-#401, PRs #402-#407, #408, #409, #384)
• 2026-10-06 : #390 mergée (PR #394, main 5910387) — l'étape 5 de la liste de démarrage se coche, les profils secondaires rattrapent leurs migrations, et les bases sont cherchées dans le bon dossier sous Linux.
  • Constat : en testant l'onboarding de la v0.17.0, Max a vu que classer une transaction ne cochait pas l'étape 5.
  • Cause : depuis la v0.1.0, updateTransactionCategory lie un booléen JS. tauri-plugin-sql 2.3.2 le stocke en texte 'true', que le compteur = 1 ne trouve pas.
  • Deux défauts plus anciens, trouvés en corrigeant :
    • tauri-plugin-sql ne migre que simpl_resultat.db. Un profil secondaire gardait le schéma de sa création ; il existe sept états publiés depuis la v0.3.0.
    • Le plugin range les bases sous app_config_dir(). repair_migrations, delete_profile_db et compute_account_return cherchaient sous app_data_dir(), dossier différent sous Linux seulement. Supprimer un profil laissait sa base sur le disque, et les rendements du Bilan s'affichaient en tirets.
  • Décisions de Max : réparer les drapeaux à l'ouverture de chaque profil plutôt que par une v18 ; inclure le rattrapage dans #390 ; appliquer les suggestions rapides de la revue, puis merger.
  • Livré :
    • toSqlFlag, à l'écriture et à la restauration d'une sauvegarde ;
    • prepare_profile_db : plancher déduit du schéma, copie VACUUM INTO avant la première écriture, historique _sqlx_migrations au format sqlx, clés étrangères actives avec une seule reprise ciblée, réparation des drapeaux texte, échec ouvert ;
    • l'historique écrit dès la création d'un profil ;
    • profile_db_path : dossier app_config_dir() et nom de fichier validé ;
    • l'ADR 0021, et les amendements des ADR 0003 et 0005.
  • Preuves :
    • les sept états publiés sont rejoués en fixtures ;
    • 22 mutations de l'auteur, toutes rouges ;
    • le plan checker a refusé trois fois (dossier Linux, rejeu de v2, clés étrangères), puis Max a validé la suite ;
    • /pr-review APPROVE sur 71147c5 ;
    • les quatre suggestions rapides sont appliquées en tête (5910387, des tests seulement, non relu), les quatre autres sont reportées en #395 ;
    • tête éprouvée dans un worktree propre : sonde rc=1, 1520 vitest, 255 Rust, CI 495 et 496.
  • Suite : #390 reste ouverte en status:blocked jusqu'à la liste post-merge.
  • Aucune migration ajoutée (v1→v17). (ref #390, PR #394, #395, ADR 0021)
• 2026-10-05 : v0.17.0 taggée et publiée (07255e1, run 491 vert) ; #234 close ; textes de la-compagnie-maximus#184 postés. Pré-vol du skill sur le tip 8f964e0 : build, 1498 vitest, cargo check sans avertissement, 224 Rust ; .claude/worktrees/ vide. Avant le bump, diff vide depuis v0.16.0 sur Cargo.lock, Cargo.toml, release.yml, tauri.conf.json et package*.json, et aucune ligne du diff ne touche le gating par édition : ni clés testeurs à émettre, ni cycle de mise à jour réel exigé (étape 10), la raison étant écrite dans le corps de la release plutôt que tue. Version mineure (fonctionnalités ajoutées) : 5 manifestes, 2 changelogs et la ligne de CLAUDE.md, Cargo.lock édité à la main et accepté par cargo metadata --locked. Tag annoté confirmé par Max, poussé seul (jamais --tags). Run 491 en 22 min ; verify-release.sh vert (7 artefacts, signatures et URL en 0.17.0) ; l'endpoint de tauri.conf.json (registre de paquets) sert aussi la 0.17.0. Le même jour : #234 fermée sur sa quatrième preuve (actcache à 999 Mo, une seule entrée : celle, isolée, de la PR #375 a été évincée par le ménage par clé), avec la milestone spec-ci-build-optimization (4/4) ; la-compagnie-maximus#184 reçoit les deux textes des suites de licence (contrôle à la saisie, retrait de la clé), rattachés aux deux passages de son corps que la v0.17.0 rend faux. Aucune migration DB (v1→v17). (ref v0.17.0, #234, #373, #370, #367, la-compagnie-maximus#184)

Blockers actifs

• Aucun blocker externe dur. spec-monetisation fermée 12/12 (2026-07-08) — #50/#52/#53/#135/#136 livrées, ne sont plus des blockers.
• audit.yml rouge depuis le 2026-10-17 06:00 UTC, à trancher avant le prochain tag (run 558 sur 065f580, base d'avis passée de 1329 à 1334) : trois avis sur zip 4.6.1, à l'extraction d'une archive (liens symboliques, bits SUID/SGID), RUSTSEC-2026-0367 (élevée, 7.3), RUSTSEC-2026-0368 et RUSTSEC-2026-0369 (critique, 9.1). zip n'est compilé que pour Windows, tiré par tauri-plugin-updater 2.10.0 via sa feature par défaut zip (qui active aussi tar et flate2) ; il n'est corrigé qu'en zip >= 9.0.0, aucun 4.x corrigé, et tauri-plugin-updater 2.14.0 exige toujours zip ^4. L'extraction n'a lieu que sur un paquet zip dont la signature a été vérifiée (download vérifie avant install), et nos paquets Windows sont des .exe NSIS. Piste : déclarer l'updater sans ses features par défaut en gardant rustls-tls, ce qui retirerait zip (et tar, canari de la garde des suppressions de check-rust, à remplacer). Issue à ouvrir sur décision de Max. #447 reste fermée à bon droit : ses quatre identifiants n'apparaissent plus dans le run 558.
• Avant le prochain tag : #419, point 1. Sous jq 1.6, la version du conteneur de release, scripts/check-latest-json.jq accepte un latest.json vide ou à deux documents : c'est la garde du DELETE du registre. Inatteignable aujourd'hui (la génération échoue fermée avant « Publish »), mais à fermer avant de tagger.
• Vérifications dues à la prochaine release (après le tag, étape 9 de /release) :
  • Retours d'onboarding v0.17.1 (#438-#445), dans l'app : cas de la section « Retours de la v0.17.1 » de docs/qa-onboarding.html et parcours guidé à huit étapes, en particulier v0171-import-source-reopen, v0171-budget-card-leaves, l'encadré « Structure attendue » dans les deux thèmes et la première ouverture d'un profil qui avait fini le parcours (#446).
  • Répartition réservée à Base (#369), dans l'app : en Gratuite, cadenas sur le bouton Répartition de la page Transactions et écran de déverrouillage au clic, jamais la fenêtre de répartition, lignes déjà réparties toujours marquées de l'icône orange ; en Base, fenêtre de répartition comme avant. Puis dire sur la-compagnie-maximus#180 que le décalage avec le tableau comparatif déployé est résorbé.
  • release.yml sous Node 24 (#376) : node --version à v24.x dans le journal du run de release, et verify-release.sh vert. Le diff touchant release.yml, l'étape 10 de /release (cycle réel de mise à jour, docs/qa-update-cycle.md) s'applique aussi, selon la règle du skill. Le bump de rustls de #447 (dépendance de tauri-plugin-updater) la rend obligatoire lui aussi.
  • latest.json à trois clés (#320, clé générique linux-x86_64 retirée le 2026-10-11) : étape « Generate latest.json » du journal lue (un paquet retenu par type), verify-release.sh en VERDICT : OK sur linux-x86_64-deb, linux-x86_64-rpm et windows-x86_64 (extensions, file: des signatures). Cycle réel depuis une installation .rpm (§3 de docs/qa-update-cycle.md) dès qu'une machine Fedora ou openSUSE est disponible, sinon « non déroulé » avec la raison dans la trace de la release.
• Le paiement est live : « aucun tag avant le go-live » n'a plus de raison d'être, et la release desktop qu'attendait le go-live est publiée (v0.16.0, 2026-10-03). Bascule live le 2026-09-29 (Product et Price live à 19 $ CAD, webhook, variables Stripe de production, redeploy 3673d09 de maximus-api, URL cs_live_ vérifiée), puis achat réel de contrôle le 2026-09-30 : clé sur /merci et par courriel, activation dans l'app, remboursement complet et licence révoquée par charge.refunded. Volet serveur clos le 2026-10-03 (derniers commentaires relus le 2026-10-04) : maximus-api#62 fermée, tous critères cochés (maximus-api 0.4.2 en prod, secrets en runtime seul), avec la milestone spec-paiements de maximus-api (12/12) ; la-compagnie-maximus#150 (Link dans les textes légaux) livrée et fermée le 2026-10-01. Go-live clos : la-compagnie-maximus#141 fermée le 2026-10-10 sur décision de Max, l'updater vérifié (Free refuse et invite à acheter, Base accepte ; confirmé le même jour). Restent pour mémoire, sans issue : le Dashboard Stripe (logo, paramètres Checkout, reçus automatiques, alertes d'échec de webhook) et les relevés du commentaire de fermeture. la-compagnie-maximus#184 (politique de confidentialité : données d'activation, contrôle au démarrage) est en status:review ; sa PR reste en brouillon jusqu'au déploiement de maximus-api#85 (commentaire du 2026-10-03). Les deux textes des suites de licence (contrôle à la saisie, retrait de la clé) y sont postés depuis le 2026-10-05 (commentaire 19724). Vérifications manuelles sur la release publiée, toutes faites : #365 le 2026-10-03, #346 et #350 le 2026-10-04 (voir Décisions). L'étape 10 sous Windows est faite (Michel, confirmée le 2026-10-10).
• Backlog ouvert : vague planned-2026-09-24-paiements close 3/3 (milestone fermée le 2026-09-30) : #270 (PR #359) et #346 (PR #362) mergées le 2026-09-27, #347 (PR #364, ferme aussi #360) mergée le 2026-09-30 ; volet site clos (maximus/la-compagnie-maximus#153, redirection de /simpl-resultat en prod). #365 fermée le 2026-10-03 après sa vérification manuelle. Milestone planned-2026-10-03-suites-licence fermée 3/3 le 2026-10-05 (#373, #370, #367 mergées, voir Décisions ; suivi #389 en status:triage). Hors milestone : #369 (réserver le fractionnement de transactions à l'édition Base) fermée le 2026-10-17 (PR #452, voir Décisions) ; #372 (la liste complète des versions repousse le Journal en bas de Paramètres → Systèmes) reste en status:ready. #350 fermée le 2026-10-04 (étape 3 vérifiée en production, voir Décisions) ; #363 fermée le 2026-10-10 sur décision de Max (ses tests, absorbés par #347, sont livrés dans la v0.16.0) ; réglés côté serveur et site : maximus-api#63 (clés de 100 ans) et maximus-api#70 (réactivation d'une machine désactivée), fermées et contenues dans 3673d09, le commit déployé à la bascule du 2026-09-29, et la-compagnie-maximus#157, fermée, dont les CGV sont publiées en tronc commun plus annexe Simpl-Résultat (annexe relue en production le 2026-09-30, plus aucune durée de 10 ans) ; côté serveur, /v1/prices ne vérifie pas qu'une machine est encore active (une machine désactivée garde les cours jusqu'à l'expiration de son jeton), issue maximus-api à ouvrir ; suites de #350 ouvertes le 2026-10-01 : maximus-api#82 (status:triage : identifiants machine bruts déjà stockés, lignes désactivées comprises ; à rehacher avant l'expiration des premiers jetons bruts, sinon une réactivation crée une seconde ligne) et la-compagnie-maximus#184 (status:review, voir ci-dessus) ; go-live clos (la-compagnie-maximus#141 fermée le 2026-10-10, maximus-api#62 le 2026-10-03) ; spec-paiements fermée ici 5/5 ; onboarding phase 2 (parcours guidé) mergée : milestone planned-2026-10-06-onboarding-parcours-guide fermée 6/6 le 2026-10-08 (#396 à #401, ee17f31), suivis #408 et #409 (status:triage) ; onboarding phase 1 livrée : milestone planned-2026-10-03-onboarding-phase1 fermée 7/7 le 2026-10-04 (#351 à #357, mergées en avance rapide, 667e058) ; suivis ouverts : #384 (status:ready, suivis non bloquants des revues) et #371 (status:blocked, hors /autopilot : en-têtes CSV BMO à fournir par Max depuis un compte réel, un par type de compte, chèques/épargne et Mastercard, avec des valeurs fictives) ; analyse d'origine dans docs/analyse-onboarding-2026-09.md, plan détaillé dans les spec-*-onboarding-phase1.md locaux, ignorés par git ; #271 absorbé par #301, livré ; spec-ci-build-optimization fermée 4/4 le 2026-10-05 (#232 livrée le 2026-07-27 ; #234 close le 2026-10-05 avec ses quatre preuves : dispatch run 464, PR #386 run 480, run planifié 488, actcache à 999 Mo) ; #376 fermée le 2026-10-12 (Node 24, PR #414). Le suivi « glob src-tauri/** non prouvé » ouvert avec #232 est levé : la PR #344 est le cas test isolé attendu (Cargo.lock + 2 .md seulement) — check-rust a bien tourné, check-frontend a bien été sauté par sa denylist.
• Suivis des advisories : #312, #313 et #315 fermées le 2026-08-15 (PRs #321/#322 mergées). #314 fermée le 2026-08-15, prémisse infirmée — elle affirmait « zéro run schedule », or audit.yml tire tous les jours à 06:00 UTC (19 runs schedule verts du 07-28 au 08-15, sans trou) ; elle a été écrite le 07-27 vers 23:56Z, ~6 h avant le premier tir programmé possible, et décrivait donc une fenêtre trop courte, pas un scheduler en panne. Ces 19 runs confirment au passage que .cargo/audit.toml est bien lu en conteneur sur main — l'ADR 0018 ne l'avait vérifié que par un workflow_dispatch sur une branche. #343 fermée le 2026-09-04 (PR #344) — RUSTSEC-2026-0258 sur h2, la seule vulnérabilité qui rougissait l'audit depuis le 08-19 ; l'audit est de nouveau vert sur main, prouvé par workflow_dispatch (run 393) et non déduit du run de PR. #348 fermée le 2026-09-21 (PR #349) — RUSTSEC-2026-0285 sur rustls, seule vulnérabilité rougissant l'audit depuis le 09-15 (7 runs, 405→411) ; vert reprouvé par workflow_dispatch sur main (run 414 : 666 paquets, zéro vulnérabilité, 12 warnings autorisés). Deux advisories en cinq semaines sur le même chemin, celui de la mise à jour automatique. #447 fermée le 2026-10-16 (PR #448, run 556 vert), quatre avis rustls sur ce même chemin ; le Défenseur n'audite pas le Rust (agent-defenseurs#186), audit.yml reste le seul canal pour les avis RustSec. #317 fermée le 2026-10-12 par la PR #417 (#358). Reste #319 (déclencheur de retrait pour rsa, désormais seule entrée de .cargo/audit.toml — le garde-fou est passé à 2 vérifications). #345 fermée le 2026-10-12 (PR #415) : garde Verify windows-sys pinning dans check-rust.yml et ADR 0023, qui portent la mesure, le coût (3 contre 5 versions compilées pour Windows) et la condition de sortie. Côté npm, #358 fermée le 2026-10-12 (PR #417) : lock régénéré par npm@11.21.0 dans les bornes de package.json, npm audit 8 → 0 au 2026-10-10.
• #320 fermée le 2026-10-12 (PR #416, clé générique retirée par la PR #418) : une clé latest.json par paquet Linux, à vérifier au prochain tag (puce « Vérifications dues à la prochaine release ») ; le §3 de docs/qa-update-cycle.md est devenu la procédure de test rpm.
• Suivis ouverts du chantier import (milestone fermée) : le refus du format « montant absolu + indicateur D/C » ne scanne que amountCol ± 1, donc une colonne D/C placée ailleurs passe encore ; dérives de comptes préexistantes dans CLAUDE.md et docs/architecture.md (composants, pages, services, Version actuelle : 0.6.3 vs tag v0.14.0) mesurées et documentées en revue, non corrigées.
• Étape 10 de la release v0.15.0 consignée le 2026-09-13 — plus un blocker : cycle réel v0.14.0 → v0.15.0 validé par les deux testeurs ; trace rédigée pour le corps de la release (PATCH à appliquer par Max) ; invite d'authentification Linux non consignée ; #320 reste ouverte (.rpm). Deux restes : (1) le texte de la carte Compte Maximus (« Le compte est requis uniquement pour les fonctionnalités Premium », hérité de v0.7) contredit v0.15.0 où Premium vient de la clé, et a vraisemblablement conduit un testeur à se connecter pour rien (code de vérification Logto reçu par courriel) — reformulation livrée par #346 (PR #362), avec une réserve notée dans l'ADR 0017 (exacte tant que le chemin abonnement → Premium reste dormant) ; (2) le flux Logto exact (connexion par code, mot de passe oublié ou inscription) reste à lire dans le journal d'audit. Position produit : v0.17.1 (2026-10-08) ; [Unreleased] non vide (Added, Changed, Fixed, Security), en attente du prochain tag.