Workflow Diagnose
Diagnostica primero. Corrige después.
Leer Primero
Lee el contexto de mayor señal antes de modificar código:
.ai-workflow/GOAL.mdsi existe.ai-workflow/PLAN.mdsi existe.ai-workflow/ACCEPTANCE.mdsi existe.ai-workflow/IMPLEMENTATION_LOG.mdsi existeAGENTS.mdCONTEXT.mdsi existe- documentación relevante, ADRs y contratos de arquitectura
- la ruta de código con fallo concreto, pruebas, registros o evidencia de tiempo de ejecución
Comportamiento Central
- Construye un bucle de retroalimentación estable antes de proponer la corrección.
- Prefiere la evidencia sobre la suposición.
- Jerarquiza hipótesis en lugar de seguir la primera historia plausible.
- Mantén el diagnóstico separado de grandes refactorizaciones oportunistas.
- Cuando la causa raíz esté clara, pasa a la planificación o implementación con evidencia explícita.
Flujo de Trabajo
1. Definir el fallo
Escribe:
- qué está fallando
- comportamiento esperado
- comportamiento real
- si el fallo es determinista, inestable, dependiente de datos o dependiente del entorno
- la superficie más pequeña donde se pueda observar retroalimentación
2. Establecer un bucle de retroalimentación
Prefiere:
- una prueba automatizada que falla
- un comando reproducible
- un escenario local reducido
- un rastro de registro o métrica específico
Si aún no es posible un bucle estable, dilo explícitamente y registra la mejor evidencia proxy disponible.
3. Jerarquizar hipótesis
Enumera las causas más probables en orden.
Cada hipótesis debe conectar:
- síntoma
- capa o componente sospechoso
- qué evidencia la confirmaría o refutaría
4. Inspeccionar e instrumentar
Usa la instrumentación mínima necesaria para separar las hipótesis:
- registros específicos
- aserciones
- sondas temporales
- ajustes de prueba
- instantáneas de estado
No reescribas la arquitectura inmediatamente solo porque el código es feo.
5. Registrar el diagnóstico
Actualiza .ai-workflow/IMPLEMENTATION_LOG.md con una pasada de diagnóstico primero cuando estés en una tarea de flujo de trabajo activa. Incluye:
- bucle de retroalimentación
- hipótesis consideradas
- evidencia recopilada
- causas confirmadas o rechazadas
- próximo enfoque de corrección
Si no hay una tarea de .ai-workflow activa, proporciona el diagnóstico en la respuesta y recomienda crear o actualizar una antes de implementar.
6. Transferir limpiamente
Si se necesita una corrección:
- usa
workflow-plan-acceptancecuando la reparación requiera un plan de implementación definido - usa
workflow-implementcuando la tarea activa ya tenga un plan aprobado
Reglas específicas de backend
Si el código backend está involucrado, prueba las hipótesis contra los límites de la arquitectura:
- controlador
- aplicación/servicio
- orquestador/servicio de dominio
- repositorio
- persistencia
- adaptador/proveedor/fondo/streaming de infraestructura
Verifica explícitamente si el error realmente es causado por:
- responsabilidades mezcladas
- preocupaciones HTTP filtrándose en la lógica del servicio
- lógica de negocio en el repositorio
- confusión entre entidad/DTO/modelo de dominio
- manejo centralizado de excepciones o validación faltante
- dimensiones de trazabilidad o auditoría faltantes
Formato de respuesta final
Al final, responde en chino con exactamente estas secciones de nivel superior:
## 工作流结果
- 技能: `workflow-diagnose`
- 状态: `completed`
- 产物: `IMPLEMENTATION_LOG.md` 或诊断结论
## 诊断摘要
- 问题现象: ...
- 反馈回路: ...
- 主要假设: ...
- 已确认原因: ...
- 排除项: ...
## 下一步
- ...