You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
138 lines
5.2 KiB
Markdown
138 lines
5.2 KiB
Markdown
# Plan d'implementation des suggestions d'audit
|
|
|
|
Date: 2026-03-28
|
|
Base: audits multi-profils + clarifications produit validees le 2026-03-28.
|
|
|
|
## 1. Objectif
|
|
|
|
Implementer les recommandations de l'audit en priorisant:
|
|
1. la correction fonctionnelle (contrats/theme-scoping),
|
|
2. la fiabilite (scheduler + SSE + coverage CI deterministe),
|
|
3. la maintenabilite (simplification/refactoring progressif sans regression).
|
|
|
|
## 2. Contraintes de reference (deja decidees)
|
|
|
|
1. Creation de theme possible sans categories utilisateur.
|
|
2. Categories par defaut toujours presentes: `Divers`, `Sans date`.
|
|
3. `GET /themes/{id}/schedule` retourne `200` avec `null` si absent.
|
|
4. Valeurs par defaut theme: `max_items_per_category=4`, `summary_length=3`.
|
|
5. Sources et "preferred" strictement scopes par theme.
|
|
6. Import/export sources toujours lies au theme selectionne.
|
|
7. Mode d'extraction "LLM vs HTML" deprecie (HTML uniquement).
|
|
8. Couverture deterministe CI obligatoire avant release pour flows critiques.
|
|
|
|
## 3. Sequencement recommande
|
|
|
|
## Phase 0 - Stabilisation des contrats (3-5 jours)
|
|
|
|
### Backend
|
|
1. Rendre `theme_id` obligatoire pour create/bulk/import-csv/export-csv/preferred.
|
|
2. Scoper `PUT /sources/preferred` par `theme_id`.
|
|
3. Verifier ownership `theme_id` sur tous les writes sources.
|
|
4. Aligner defaults backend sur `4/3`.
|
|
5. Aligner validation theme create/update sur les regles finales.
|
|
|
|
### Frontend
|
|
1. Adapter clients API (`sources.ts`, `themes.ts`, `schedules.ts`) aux nouveaux contrats.
|
|
2. Garantir l'envoi systematique du `theme_id` dans tous les flux sources.
|
|
3. Aligner creation de theme (draft sans categories utilisateur).
|
|
4. Gerer explicitement `schedule: null`.
|
|
|
|
### QA
|
|
1. Ajouter tests d'integration contrat API (theme + sources + schedule).
|
|
2. Ajouter tests d'isolation multi-theme (import/export/preferred).
|
|
|
|
### Definition of Done
|
|
1. Contrats API aligns avec docs.
|
|
2. Tests integration P0 verts en CI.
|
|
3. Aucun flux UI principal casse.
|
|
|
|
## Phase 1 - Fiabilite runtime + gates CI (4-6 jours)
|
|
|
|
### Backend
|
|
1. Ajouter timeout explicite sur execution scheduler (parite avec generation manuelle).
|
|
2. Brancher cleanup periodique `job_store.cleanup_expired()` au runtime.
|
|
3. Renforcer erreurs non silencieuses (`.ok()` critiques -> logs/warn explicites).
|
|
|
|
### QA
|
|
1. Tests d'integration deterministes scheduler:
|
|
- due selection, anti-double-run, conflit job actif, succes/echec email.
|
|
2. Tests d'integration deterministes SSE:
|
|
- sequence `progress -> complete/error`, ownership, resilience.
|
|
3. Rendre ces suites bloquantes dans CI.
|
|
|
|
### Definition of Done
|
|
1. Scheduler/SSE couverts par tests deterministes.
|
|
2. Gate CI "release" bloque si ces suites echouent.
|
|
|
|
## Phase 2 - Coherence produit et hygiene code (4-6 jours)
|
|
|
|
### Frontend
|
|
1. Corriger enums/filters `ArticleHistory` pour coller au contrat backend.
|
|
2. Supprimer hardcoded strings (i18n centralise).
|
|
3. Appliquer regle stricte `Button` (remplacer les `<button>` bruts).
|
|
4. Eliminer fetch directs dans pages au profit du client API.
|
|
|
|
### Backend
|
|
1. Supprimer toute trace fonctionnelle du mode extraction LLM deprecie.
|
|
2. Verification complete des defaults/documentation runtime.
|
|
|
|
### QA
|
|
1. Tests unitaires/frontend sur i18n + rendering + article-history filters.
|
|
2. Tests integration pour cas no-date -> `Sans date`.
|
|
|
|
### Definition of Done
|
|
1. Plus de drift visible entre spec/doc/code pour ces zones.
|
|
2. Lint/tests frontend/backend verts.
|
|
|
|
## Phase 3 - Simplification structurelle (1-2 sprints)
|
|
|
|
### Backend
|
|
1. Decomposer `services/synthesis.rs` par phases:
|
|
- `init`, `phase1`, `phase2`, `finalize`, `trace`.
|
|
2. Extraire structures de contexte pour limiter l'etat mutable partage.
|
|
3. Ajouter tests de caracterisation avant et apres refactor.
|
|
|
|
### Frontend
|
|
1. Decomposer `ThemeManager`, `Settings`, `Admin/Providers`.
|
|
2. Introduire hooks/metiers (`useThemeEditor`, `useGenerationProgress`, etc.).
|
|
3. Nettoyer anti-patterns reactivite (side effects en render).
|
|
|
|
### Definition of Done
|
|
1. Complexite par fichier/fonction reduite de facon mesurable.
|
|
2. Aucun changement comportemental non voulu (tests non-regression verts).
|
|
|
|
## Phase 4 - Durcissement final (3-5 jours)
|
|
|
|
1. Optimiser points chauds (N+1 `article_history`, insertions bulk).
|
|
2. Completer observabilite (logs structurés, erreurs pipeline visibles).
|
|
3. Mettre a jour templates PR/checklists anti-drift docs/spec/code.
|
|
4. Synchroniser `qa_guidelines` avec inventaire reel genere en CI.
|
|
|
|
## 4. Plan QA global (obligatoire)
|
|
|
|
1. Gate CI minimal:
|
|
- backend unit
|
|
- backend integration (incluant scheduler + SSE + source-scoping)
|
|
- frontend typecheck
|
|
- frontend unit tests
|
|
2. E2E live provider reste non-bloquant (supplementaire).
|
|
3. Aucun merge sur branches release si gate deterministe rouge.
|
|
|
|
## 5. Risques et mitigation
|
|
|
|
1. Risque: regression sur flux theme/sources.
|
|
- Mitigation: tests d'integration multi-theme en premier.
|
|
2. Risque: refactor structurel trop tot.
|
|
- Mitigation: refactor uniquement apres Phases 0-2 stabilisees.
|
|
3. Risque: fausse confiance via tests live externes.
|
|
- Mitigation: CI bloquee sur suites deterministes internes.
|
|
|
|
## 6. Ordre d'execution concret (suggestion)
|
|
|
|
1. Sprint A: Phase 0 complete.
|
|
2. Sprint B: Phase 1 complete.
|
|
3. Sprint C: Phase 2 complete.
|
|
4. Sprint D-E: Phase 3.
|
|
5. Sprint F: Phase 4 + cloture.
|