workflow-diagnose

Workflow Diagnose

Diagnostiquer d'abord. Corriger ensuite.

Lire en premier

Lire le contexte le plus pertinent avant de modifier du code :

• .ai-workflow/GOAL.md s'il existe
• .ai-workflow/PLAN.md s'il existe
• .ai-workflow/ACCEPTANCE.md s'il existe
• .ai-workflow/IMPLEMENTATION_LOG.md s'il existe
• AGENTS.md
• CONTEXT.md s'il existe
• les documents, ADR et contrats d'architecture pertinents
• le chemin d'échec concret, les tests, les logs ou les preuves d'exécution

Comportement de base

1. Construire une boucle de rétroaction stable avant de proposer une correction.
2. Privilégier les preuves plutôt que les suppositions.
3. Classer les hypothèses au lieu de suivre la première explication plausible.
4. Garder le diagnostic séparé des grandes refontes opportunistes.
5. Lorsque la cause racine est claire, passer à la planification ou à l'implémentation avec des preuves explicites.

Workflow

1. Définir l'échec

Écrire :

• ce qui échoue
• le comportement attendu
• le comportement réel
• si l'échec est déterministe, instable, dépendant des données ou de l'environnement
• la plus petite surface où la rétroaction peut être observée

2. Établir une boucle de rétroaction

Privilégier :

• un test automatisé qui échoue
• une commande reproductible
• un scénario local restreint
• une trace de log ou de métrique ciblée

Si aucune boucle stable n'est encore possible, le dire explicitement et enregistrer la meilleure preuve indirecte disponible.

3. Classer les hypothèses

Lister les causes les plus probables dans l'ordre.

Chaque hypothèse doit relier :

• le symptôme
• la couche ou le composant suspecté
• les preuves qui la confirmeraient ou l'infirmeraient

4. Inspecter et instrumenter

Utiliser l'instrumentation minimale nécessaire pour séparer les hypothèses :

• logs ciblés
• assertions
• sondes temporaires
• ajustements de test
• instantanés d'état

Ne pas réécrire immédiatement l'architecture juste parce que le code est laid.

5. Enregistrer le diagnostic

Mettre à jour .ai-workflow/IMPLEMENTATION_LOG.md avec une passe de diagnostic d'abord lorsque vous êtes dans une tâche de workflow active. Inclure :

• la boucle de rétroaction
• les hypothèses considérées
• les preuves rassemblées
• les causes confirmées ou rejetées
• le prochain axe de correction

S'il n'y a pas de tâche .ai-workflow active, fournir le diagnostic dans la réponse et recommander de créer ou d'actualiser une tâche avant l'implémentation.

6. Passer proprement la main

Si une correction est nécessaire :

• utiliser workflow-plan-acceptance lorsque la réparation nécessite un plan d'implémentation cadré
• utiliser workflow-implement lorsque la tâche active possède déjà un plan approuvé

Règles spécifiques au backend

Si du code backend est impliqué, tester les hypothèses par rapport aux limites architecturales :

• contrôleur
• application/service
• orchestrateur/domaine/service
• dépôt
• persistance
• adaptateur d'infrastructure/fournisseur/fond/streaming

Vérifier explicitement si le bogue est en réalité causé par :

• un mélange de responsabilités
• des préoccupations HTTP qui fuient dans la logique métier
• une logique métier détenue par le dépôt
• une confusion entre entité/DTO/modèle de domaine
• une gestion manquante de la centralisation des exceptions ou de la validation
• des dimensions de traçabilité ou d'audit manquantes

Format de réponse final

À la fin, répondre en chinois avec exactement ces sections de premier niveau :

## 工作流结果
- 技能: `workflow-diagnose`
- 状态: `completed`
- 产物: `IMPLEMENTATION_LOG.md` 或诊断结论

## 诊断摘要
- 问题现象: ...
- 反馈回路: ...
- 主要假设: ...
- 已确认原因: ...
- 排除项: ...

## 下一步
- ...