131 lines
3.7 KiB
Markdown
131 lines
3.7 KiB
Markdown
# Loop Process
|
|
|
|
## 목적
|
|
이 문서는 `design_agent` 작업을 run 단위로 반복 실행하면서, 각 단계의 성공과 실패를 평가하고, 그 결과를 이슈와 다음 run으로 연결하는 운영 규칙을 정의한다.
|
|
|
|
## 기본 원칙
|
|
- 모든 작업은 `run-001`, `run-002`처럼 run 단위로 수행한다.
|
|
- 모든 run은 `01-input`부터 `06-validation`까지 같은 구조를 따른다.
|
|
- 각 단계는 단순 수행만이 아니라 `성공/실패 평가`를 포함해야 한다.
|
|
- 검증 결과는 끝이 아니라 다음 run의 입력이 된다.
|
|
|
|
## 표준 루프
|
|
1. 입력 준비
|
|
2. Step 1 입력 확인
|
|
3. Step 2 Kei 기준 해석
|
|
4. Step 3 콘텐츠 구조화
|
|
5. Step 4 실행 계획 수립
|
|
6. Step 5 실제 수행
|
|
7. Step 6 검증 및 기록
|
|
8. 이슈 업데이트
|
|
9. 다음 run 반영
|
|
|
|
## 단계별 평가 원칙
|
|
### Step 1 입력 확인
|
|
성공 기준:
|
|
- 입력 파일이 명확하다.
|
|
- 요청 목적과 작업 범위가 정리되었다.
|
|
- 주요 제약이 드러난다.
|
|
|
|
실패 기준:
|
|
- 입력 파일이 누락되었다.
|
|
- 요청 목적이 모호하다.
|
|
- 필수 제약이 기록되지 않았다.
|
|
|
|
실패 분류:
|
|
- Input
|
|
|
|
### Step 2 Kei 기준 해석
|
|
성공 기준:
|
|
- 핵심 목적이 한두 문장으로 정리되었다.
|
|
- 반드시 지켜야 할 의미가 기록되었다.
|
|
- 실패 패턴과 검증 기준이 드러난다.
|
|
|
|
실패 기준:
|
|
- 목적이 너무 넓거나 모호하다.
|
|
- 핵심과 보조 정보가 구분되지 않는다.
|
|
- 해석 결과가 다음 단계 입력으로 쓰기 어렵다.
|
|
|
|
실패 분류:
|
|
- Interpretation
|
|
|
|
### Step 3 콘텐츠 구조화
|
|
성공 기준:
|
|
- 중심 메시지와 보조 정보가 분리되었다.
|
|
- 섹션 구조와 우선순위가 드러난다.
|
|
- body/sidebar/footer 배치 가정이 있다.
|
|
|
|
실패 기준:
|
|
- 구조 없이 원문 나열 수준이다.
|
|
- 핵심 메시지가 묻힌다.
|
|
- 정보가 중복되거나 충돌한다.
|
|
|
|
실패 분류:
|
|
- Interpretation
|
|
- Planning
|
|
|
|
### Step 4 실행 계획 수립
|
|
성공 기준:
|
|
- Stage 목록이 명확하다.
|
|
- stage별 입력, 출력, 검증 기준이 있다.
|
|
- 재시도 기준과 fallback 경로가 정리되었다.
|
|
|
|
실패 기준:
|
|
- 세부 stage가 생략되었다.
|
|
- 검증 없는 생성 단계가 있다.
|
|
- Kei API 의존 여부가 불명확하다.
|
|
|
|
실패 분류:
|
|
- Planning
|
|
|
|
### Step 5 실제 수행
|
|
성공 기준:
|
|
- run 산출물이 실제로 생성되었다.
|
|
- 필요한 경우 기존 코드 자산이 사용되었다.
|
|
- 실패한 stage와 재시도 이력이 남는다.
|
|
|
|
실패 기준:
|
|
- 실행이 중간에 끊겼다.
|
|
- 산출물이 저장되지 않았다.
|
|
- 어떤 입력으로 어떤 코드를 돌렸는지 추적이 안 된다.
|
|
|
|
실패 분류:
|
|
- Generation
|
|
- Rendering
|
|
- Tooling
|
|
|
|
### Step 6 검증 및 기록
|
|
성공 기준:
|
|
- 목적 적합성, 내용 보존, 제약 준수, 렌더 상태가 평가되었다.
|
|
- 최종 판정(pass/revise/fail)이 명시되었다.
|
|
- 다음 액션과 되돌림 지점이 기록되었다.
|
|
|
|
실패 기준:
|
|
- 검증 결과가 모호하다.
|
|
- 실패 원인이 분류되지 않았다.
|
|
- 다음 run으로 이어질 개선 포인트가 없다.
|
|
|
|
실패 분류:
|
|
- Verification
|
|
- Quality
|
|
|
|
## 실패 원인 분류 체계
|
|
- Input
|
|
- Interpretation
|
|
- Planning
|
|
- Generation
|
|
- Verification
|
|
- Rendering
|
|
- Quality
|
|
- Tooling
|
|
|
|
## 이슈 운영 원칙
|
|
- 각 run은 최소 1개의 이슈 요약을 남긴다.
|
|
- 이슈에는 step별 결과 요약, 판정, 실패 원인, 다음 액션을 적는다.
|
|
- 자세한 산출물은 저장소 경로로 연결한다.
|
|
|
|
## 다음 run 연결 규칙
|
|
- 이전 run의 `06-validation` 결과를 다음 run의 참고 입력으로 둔다.
|
|
- 같은 실패가 반복되면 verifier 또는 stage 산출물 형식을 수정한다.
|
|
- 다음 run 시작 전에 이전 run의 `Next Action`을 반드시 읽는다.
|