ObsiGate/docs/ISSUES_TODOLIST.md

> **IMPORTANT — Lire d'abord**
> Ce document utilise un **format tabulaire simple et rigoureux** conçu pour être
> maintenu à la fois par un humain (éditeur texte) et par un agent IA. Les règles
> exactes sont définies dans la section **« Comment fonctionne ce document »**.

# 🐛 ObsiGate — Suivi des Bugs / TODO de Correction

> **Rôle du document** : registre unique et vivant des bugs découverts et des corrections
> à apporter au projet **ObsiGate** (application Web + desktop Tauri).
> C'est l'**outil de communication commun** entre l'utilisateur humain et l'IA
> qui effectue les corrections dans le code.

- **Projet** : ObsiGate — Porte d'entrée web pour vaults Obsidian
- **Stack** : Python 3.11+ (backend FastAPI) · JavaScript/Vanilla (frontend) · Tauri/Rust (desktop)
- **Dernière mise à jour** : *(à tenir à jour à chaque modification)*

---

## ⚙️ Comment fonctionne ce document (À LIRE ABSOLUMENT)

Ce document est un **contrat de travail partagé**. Suivez les règles ci-dessous pour
qu'un humain OU un agent IA puisse le lire, le modifier et l'exploiter sans ambiguïté.

### 1. Une table = un état (workflow par rangée)

Chaque bug/TODO est une **rangée** dans la section [📋 Registre des bugs / TODOs](#-registre-des-bugs--todos).
Une rangée ne change **jamais de table** au fil de sa vie ; c'est la **colonne « Statut »**
qui encode son avancement :

| Statut (colonne) | Signification | Qui peut le poser |
|---|---|---|
| `🔴 ouvert` | Bug confirmé / tâche à faire, en attente de traitement | Utilisateur **ou** IA |
| `🟠 en cours` | Un agent IA a **commencé** à corriger | IA uniquement |
| `🟢 corrigé` | La correction est écrite **et** vérifiée (tests OK) | IA uniquement |
| `✅ vérifié` | L'utilisateur (ou les tests) a **validé** le correctif | Utilisateur uniquement |
| `⚪ abandonné` | Décision de ne pas corriger (documentée dans notes) | Utilisateur ou IA |

### 2. Cycle de vie d'un bug (workflow)

```mermaid
flowchart LR
    A[🔴 ouvert<br/>Découverte d'un bug] --> B[🟠 en cours<br/>IA travaille dessus]
    B --> C[🟢 corrigé<br/>Correctif écrit + tests OK]
    C --> D[✅ vérifié<br/>Re-validation par l'utilisateur]
    C --> E[⚪ abandonné<br/>Refus / hors périmètre]
    D --> F[✅ Fermé : lignée conservée en historique]
```

1. **Un bug est signalé** → posé en `🔴 ouvert` par l'utilisateur **ou** l'IA (à l'issue d'une
   investigation ou d'une session de test).
2. **L'IA prend en charge** → passe le statut en `🟠 en cours` **avant** de commencer à coder,
   et crée une entrée dans [🛠️ Journal des interventions AI](#-journal-des-interventions-ai).
3. **La correction est terminée** → l'IA exécute les tests pertinents, passe le statut en
   `🟢 corrigé` et remplit la colonne « Correctif / Commit ».
4. **Validation finale** → c'est l'utilisateur qui passe en `✅ vérifié` une fois le correctif
   contrôlé. Les rangées `✅ vérifié` sont **déplacées dans l'historique** périodiquement.
5. **Abandon** → justifié obligatoirement dans la colonne « Notes / Scope ».

> ⚠️ **Ne JAMAIS supprimer** une rangée terminée : déplacez-la dans la section
> [📜 Historique des bugs résolus](#-historique-des-bugs-résolus) à la place.

### 3. Ordre de lecture pour un agent IA

Avant de corriger quoi que ce soit, un agent IA doit :

1. **Lire ce fichier en entier** (en particulier ce guide et le registre).
2. **Identifier** les rangées de statut `🔴 ouvert` avec un **scope `IA`** et une
   **priorité** élevée qui lui sont attribuées (colonne « Assigné »).
3. **Poser le statut `🟠 en cours`** sur la rangée choisie **avant** toute modification de code.
4. Corriger en respectant la [checklist de vérification](#-checklist-de-traitement-dun-bug-rappel-pour-toute-ia)
   et les [conventions du projet](CONTRIBUTING.md).
5. Revenir mettre le statut à `🟢 corrigé`, documenter le correctif, et **journaliser** son passage.
6. Ne pas marquer `✅ vérifié` lui-même (c'est un droit utilisateur, sauf mention contraire explicite).

### 4. Identifiants uniques (ID)

- Chaque bug porte un **ID stable** `BUG-###` ou `TODO-###` (voir le format dans le registre).
- L'ID **ne change jamais**, même après résolution. Il permet de retrouver le bug dans
  l'historique et dans le journal d'interventions.
- Le format du numéro est `###` = 3 chiffres incrémental (001, 002, 003…).
- Si vous (IA) créez un nouveau bug, **reprenez le plus grand numéro existant + 1** dans le
  registre, quel que soit l'ordre des lignes.

### 5. Comment mettre à jour ce document (bonnes pratiques)

- **Formatage** : garder les colonnes alignées par des espaces pour la lisibilité brute.
  Une rangée = une seule ligne de tableau Markdown.
- **Copier-coller** : pour ajouter un bug, dupliquez une ligne existante puis modifiez les champs.
- **Ne pas casser** : conservez le séparateur d'en-tête `|---|---|…|` et les **champs fixes**
  (#, Titre, Statut, Priorité, Scope, Assigné, Zone, Cmd de repro, Correctif/Commit, Notes).
- **Frontière des rôles** : un agent IA ne doit **jamais** se passer à lui-même une rangée en
  `✅ vérifié` ; il s'arrête à `🟢 corrigé` (sauf si l'utilisateur l'y autorise explicitement).

---

## 📋 Registre des bugs / TODOs

> **Légende colonnes :**
> - **Statut** : `🔴 ouvert` | `🟠 en cours` | `🟢 corrigé` | `✅ vérifié` | `⚪ abandonné`
> - **Priorité** : `P0` (critique/bloquant) · `P1` (élevée) · `P2` (normale) · `P3` (basse/cosmétique)
> - **Scope** : `📱 frontend` · `⚙️ backend` · `🔌 api` · `🧩 tests` · `🖥️ desktop` · `📦 build` · `📄 docs` · `🤖 ia` · `❓ inconnu` (À affiner par l'IA)
> - **Assigné** : `IA` (à traiter par un agent) · `USER` (à traiter par l'utilisateur) · `—` (non attribué)
> - **Zone** : chemin/nom de fichier concerné (ex. `frontend/app.js`, `backend/search.py`)
> - **Cmd de repro** : commande ou scénario permettant de reproduire / vérifier (vide si N/C)

### Bugs ouverts (à traiter)

| # | Titre | Statut | Priorité | Scope | Assigné | Zone (fichier) | Cmd de repro | Correctif / Commit | Notes |
|---|---|---|---|---|---|---|---|---|---|
| *BUG-001* | L'ouverture des fichier PDF ne fonctionne pas et donne l'erreur Internal Server Error | 🔴 ouvert | P1 | fichier PDF | IA |  | 
https://og.dracodev.net/api/file/Recettes/pdf/stream?path=98_Boite_Outils%2F98.2_Attachments%2FBi%C3%A8re%20blonde%20envoy%C3%A9%20par%20Desja.pdf| — | l'erreur se retrouve dans la section network de la console web et dans l'interface web lors du chargement d'un pdf |
| *BUG-002* | l'ouverture d'un fichier .excalidraw ne fonctionne pas et affiche toujours Loading *Excalidraw…* | 🔴 ouvert | P1 | fichier .excalidaw  | IA | |  | — | test d'accès réaliser via cloudflare et réseau local démontre que ce problème est au 2 endroits |
|  | | | | | | | | | |

### TODOs techniques (améliorations / nouvelles tâches)

| # | Titre | Statut | Priorité | Scope | Assigné | Zone (fichier) | Cmd de repro | Correctif / Commit | Notes |
|---|---|---|---|---|---|---|---|---|---|
| *(exemple)* TODO-002 | Rendre l'index inversé incrémental (40k+ fichiers) | 🔴 ouvert | P1 | ⚙️ backend | IA | `backend/indexer.py`, `backend/search.py` | Recherche sur très gros vault | — | Exemple à remplacer. Cf. plan.md |
| *(À remplir)* | | | | | | | | | |

---

## 🛠️ Journal des interventions AI

> Chaque passage d'un agent IA qui modifie du code ou l'état du registre est journalisé.
> **Règle** : l'IA ajoute **une ligne** à la fin de ce tableau à chaque session de correction.
> Colonnes : `Date` (YYYY-MM-DD) · `ID(s) traité(s)` · `Action` · `Fichiers modifiés` · `Résumé` · `Statut après`.

| Date | ID(s) traité(s) | Action | Fichiers modifiés | Résumé | Statut après |
|---|---|---|---|---|---|
| *(exemple)* 2026-06-15 | BUG-001 | Correction | `frontend/app.js` | Réécriture de `renderFile()` pour préserver le DOM dashboard | 🟢 corrigé (en attente vérif) |

---

## 📜 Historique des bugs résolus

> Les rangées `✅ vérifié` (ou `⚪ abandonné`) sont déplacées ici régulièrement pour garder
> le **registre actuel** court et lisible. Conservez l'ID d'origine pour la traçabilité.

| # | Titre | Date résolution | Résolu par | Correctif / Commit | Notes |
|---|---|---|---|---|---|
| *(aucun pour l'instant)* | | | | | |

---

## 🧪 Procédure de vérification d'une correction (pour l'IA)

Quand une correction est écrite, l'agent IA doit **avant** de passer en `🟢 corrigé` :

1. **Exécuter les tests** du projet :
   - Backend : `python -m pytest tests/ -v` (ou `pytest`)
   - S'il existe des tests ciblés sur la zone modifiée, les lancer en priorité.
2. **Vérifier le lancement** du module concerné (import sans erreur, endpoint répond).
3. **Relire sa propre diff** pour éviter les régressions.
4. Mettre la colonne « Correctif / Commit » à jour **puis** le statut en `🟢 corrigé`.
5. Si un test échoue ou que la correction est incomplète, **rester en `🟠 en cours`** et le noter.

---

## ✔️ Checklist de traitement d'un bug (rappel pour toute IA)

- [ ] Bug identifié avec un **ID** et repris dans le [registre](#-registre-des-bugs--todos)
- [ ] Statut posé en `🟠 en cours` avant de coder
- [ ] Correction conforme aux [conventions du projet](CONTRIBUTING.md)
- [ ] Tests exécutés et **vert** (colonne « Correctif / Commit » renseignée)
- [ ] Journal des interventions AI mis à jour
- [ ] Statut passé en `🟢 corrigé` (pas `✅ vérifié` sauf autorisation)
- [ ] (Après validation utilisateur) rangée déplacée dans l'historique

---

## 📚 Liens utiles

- **Guide de contribution** : [CONTRIBUTING.md](CONTRIBUTING.md) (conventions de code)
- **Structure du projet** : [README.fr.md](../README.fr.md)
- **Tests** : répertoire `tests/` — voir CONTRIBUTING
- **Analyse/décisions complémentaires** : [IMPLEMENTATION_PLAN.md](IMPLEMENTATION_PLAN.md), [ROADMAP.md](ROADMAP.md)