워크플로우 진단은(는) 무엇을 하나요?
진단 먼저. 수정은 그 다음.
먼저 읽어야 할 것
코드를 변경하기 전에 가장 중요한 컨텍스트를 먼저 읽으세요:
.ai-workflow/GOAL.md(있는 경우).ai-workflow/PLAN.md(있는 경우).ai-workflow/ACCEPTANCE.md(있는 경우).ai-workflow/IMPLEMENTATION_LOG.md(있는 경우)AGENTS.mdCONTEXT.md(있는 경우)- 관련 문서, ADR, 아키텍처 계약
- 구체적인 실패 코드 경로, 테스트, 로그 또는 런타임 증거
핵심 동작
- 수정을 제안하기 전에 안정적인 피드백 루프를 구축하세요.
- 추측보다 증거를 우선시하세요.
- 첫 번째 그럴듯한 이야기를 따르지 말고 가설에 순위를 매기세요.
- 진단을 대규모 기회주의적 리팩터링과 분리하세요.
- 근본 원인이 명확해지면 명시적인 증거와 함께 계획 또는 구현 단계로 전환하세요.
워크플로우
1. 실패 정의
다음을 기록하세요:
- 무엇이 실패하고 있는가
- 예상 동작
- 실제 동작
- 실패가 결정적인지, 불안정한지, 데이터에 의존적인지, 환경에 의존적인지
- 피드백을 관찰할 수 있는 가장 작은 표면
2. 피드백 루프 구축
다음을 선호하세요:
- 실패하는 자동화된 테스트
- 재현 가능한 명령
- 좁은 로컬 시나리오
- 대상화된 로그 또는 메트릭 추적
아직 안정적인 루프가 불가능하다면, 그 사실을 명시적으로 말하고 사용 가능한 최고의 프록시 증거를 기록하세요.
3. 가설 순위 매기기
가장 가능성이 높은 원인을 순서대로 나열하세요.
각 가설은 다음을 연결해야 합니다:
- 증상
- 의심되는 계층 또는 구성 요소
- 이를 확인하거나 반증할 증거
4. 검사 및 계측
가설을 분리하는 데 필요한 최소한의 계측을 사용하세요:
- 대상화된 로그
- 어설션
- 임시 프로브
- 테스트 조정
- 상태 스냅샷
코드가 보기 흉하다고 해서 아키텍처를 즉시 재작성하지 마세요.
5. 진단 기록
활성 워크플로우 작업 중일 때는 .ai-workflow/IMPLEMENTATION_LOG.md를 진단 우선 접근 방식으로 업데이트하세요. 다음을 포함하세요:
- 피드백 루프
- 고려된 가설
- 수집된 증거
- 확인되거나 기각된 원인
- 다음 수정 초점
활성 .ai-workflow 작업이 없으면, 응답에 진단을 제공하고 구현 전에 새 작업을 생성하거나 새로 고칠 것을 권장하세요.
6. 깔끔하게 전환
수정이 필요한 경우:
- 수리가 범위가 지정된 구현 계획이 필요하면
workflow-plan-acceptance를 사용하세요. - 활성 작업에 이미 승인된 계획이 있으면
workflow-implement를 사용하세요.
백엔드별 규칙
백엔드 코드가 관련된 경우, 아키텍처 경계를 따라 가설을 테스트하세요:
- 컨트롤러
- 애플리케이션/서비스
- 오케스트레이터/도메인 서비스
- 리포지토리
- 지속성
- 인프라 어댑터/프로바이더/백그라운드/스트리밍
버그가 실제로 다음에 의해 발생했는지 명시적으로 확인하세요:
- 책임 혼재
- 서비스 로직으로 누출되는 HTTP 관심사
- 리포지토리 소유 비즈니스 로직
- 엔티티/DTO/도메인 모델 혼동
- 중앙 집중식 예외 또는 검증 처리 누락
- 추적성 또는 감사 차원 누락
최종 응답 형식
마지막에는 다음 최상위 섹션과 함께 중국어로 응답하세요:
## 工作流结果
- 技能: `workflow-diagnose`
- 状态: `completed`
- 产物: `IMPLEMENTATION_LOG.md` 或诊断结论
## 诊断摘要
- 问题现象: ...
- 反馈回路: ...
- 主要假设: ...
- 已确认原因: ...
- 排除项: ...
## 下一步
- ...