Skill d'Investigation et de Planification d'Issue

Objectif

Investiguer une issue GitHub en détail et produire un plan d'implémentation structuré et actionnable. Le plan suit l'architecture en couches du projet (UI -> BLoC -> Repository -> Client) et inclut les fichiers à modifier, les étapes d'implémentation, la stratégie de test et l'évaluation des risques.

Flux de Travail

Phase 1 : Récupérer l'Issue

Récupérer le contexte complet de l'issue en utilisant la CLI gh et GraphQL.

# Obtenir les détails de l'issue
gh issue view <number> --json title,body,comments,labels,state,assignees

# Obtenir le type d'issue, la hiérarchie et les sous-issues
gh api graphql -f query='{ repository(owner: "divinevideo", name: "divine-mobile") {
  issue(number: <NUMBER>) {
    id
    title
    body
    issueType { id name }
    subIssues(first: 20) { nodes { number title state } }
    parentIssue { number title }
  }
} }'

Déterminer le type d'issue à partir de :

• Préfixe du titre : fix: = Bug, feat: = Feature, task: = Task
• Champ GraphQL issueType
• Labels (par exemple, bug label)

Extraire les informations clés :

• Bug : Étapes de reproduction, résultat réel vs attendu, environnement, preuves
• Feature : Exigences, critères d'acceptation, stories utilisateur
• Task : Description, périmètre, notes d'implémentation

Phase 2 : Explorer la Codebase

Rechercher dans la codebase pour comprendre le code pertinent. L'approche varie selon le type.

Pour les Bugs

1. Rechercher des mots-clés de la description du bug (messages d'erreur, noms d'écrans, noms de widgets) avec Grep
2. Identifier l'écran/page où le bug se manifeste en utilisant Glob sur lib/screens/ et lib/widgets/
3. Tracer le chemin du code à travers UI, BLoC, Repository jusqu'à Client
4. Vérifier les tests associés en utilisant Glob sur test/
5. Si lié à Nostr, utiliser mcp__nostr__read_kind ou mcp__nostr__read_nip pour le contexte du protocole

Pour les Features

1. Rechercher des features similaires existantes avec Grep et Glob
2. Identifier les couches architecturales nécessaires (nouveau BLoC ? Nouveau repository ? Nouveau package ?)
3. Vérifier si des modèles/repositories associés existent déjà dans mobile/packages/
4. Consulter le routeur (mobile/lib/router/) pour l'intégration de navigation
5. Si lié à Nostr, utiliser les outils mcp__nostr__* pour comprendre les NIPs et kinds d'événements pertinents

Pour les Tasks

1. Rechercher la zone de code spécifiée dans la task en utilisant Grep
2. Comprendre l'état actuel d'implémentation
3. Vérifier les tests existants qui devront être mis à jour
4. Identifier les fichiers associés qui pourraient être affectés

Phase 3 : Analyser

Pour les Bugs

• Identifier la cause racine en lisant les fichiers sources pertinents
• Déterminer quelle(s) couche(s) contient le bug (UI ? BLoC ? Repository ? Client ?)
• Évaluer le risque de régression (qu'est-ce d'autre pourrait casser ?)
• Vérifier si les tests existants auraient dû attraper cela

Pour les Features

• Déterminer quelles couches nécessitent du nouveau code vs des modifications
• Concevoir le flux de données : Client -> Repository -> BLoC -> UI
• Identifier les nouveaux modèles, événements, états nécessaires
• Considérer l'intégration avec les features existantes (routeur, thème, BLoCs existants)
• Évaluer si de nouveaux packages sont nécessaires dans mobile/packages/

Pour les Tasks

• Délimiter précisément la portée du changement
• Identifier tous les fichiers qui doivent être modifiés
• Déterminer si la task a des effets en cascade

Phase 4 : Planifier

Construire le plan d'implémentation en suivant l'architecture en couches du projet. Toujours ordonner les étapes d'implémentation de bas en haut :

1. Modifications de la couche données (packages Client dans mobile/packages/)
2. Modifications de la couche repository (packages Repository dans mobile/packages/)
3. Modifications de la logique métier (BLoCs dans mobile/lib/blocs/)
4. Modifications de la couche présentation (Screens/Widgets dans mobile/lib/screens/ ou mobile/lib/widgets/)
5. Modifications du routeur (si la navigation est affectée)
6. Plan de test (reflétant les couches d'implémentation)

Phase 5 : Sortie

Présenter le plan en utilisant le modèle de sortie ci-dessous.

Modèle de Sortie

## Plan : [Titre de l'Issue] (#[numéro])

**Type** : Bug | Feature | Task
**Issue** : [URL]
**Complexité** : Low | Medium | High

---

### Résumé de l'Issue
[Résumé en 1-2 phrases dans vos propres mots après investigation]

### [Bug Uniquement] Cause Racine
- **Couche** : [UI | BLoC | Repository | Client]
- **Fichier** : [chemin exact avec numéros de ligne]
- **Cause** : [explication claire de pourquoi cela se produit]
- **Preuves** : [snippet de code ou trace logique]

### [Feature Uniquement] Conception Architecturale
- **Nouveaux packages nécessaires** : [liste ou "Aucun"]
- **Couches affectées** : [lesquelles de UI, BLoC, Repository, Client]
- **Flux de données** : [description Client -> Repository -> BLoC -> UI]
- **Événements Nostr** : [kinds/NIPs pertinents si applicable]

### Fichiers Affectés

| Fichier | Action | Description |
|---------|--------|-------------|
| `path/to/file.dart` | Modify / Create / Delete | Quels changements |

### Étapes d'Implémentation

Étapes ordonnées de bas en haut (couche données d'abord, UI en dernier) :

1. **[Couche] : [Brève description]**
   - Fichier : `path/to/file.dart`
   - Changements : [changements spécifiques]
   - Pourquoi : [justification]

2. ...

### Stratégie de Test

| Couche | Fichier de Test | Quoi Tester |
|--------|-----------------|-------------|
| [Couche] | `test/path/to/test.dart` | [cas de test spécifiques] |

### Risques et Considérations
- [Risque 1 et atténuation]
- [Risque 2 et atténuation]

Référence des Outils

Directives de Complexité

Référence Architecturale

• Ordre des couches : UI -> BLoC -> Repository -> Client
• Ordre d'implémentation : De bas en haut (Client d'abord, UI en dernier)
• Packages : mobile/packages/
• BLoCs : mobile/lib/blocs/
• Écrans : mobile/lib/screens/
• Widgets : mobile/lib/widgets/
• Routeur : mobile/lib/router/
• Tests miroir : mobile/test/ reflète mobile/lib/
• Gestion d'état : BLoC pour les nouvelles features, Riverpod pour l'héritage
• Thème : Mode sombre uniquement, utiliser les constantes VineTheme
• IDs Nostr : Ne jamais tronquer, toujours un hex complet 64-caractères