Update README for stage-based retry workflow

README.md

@@ -5,7 +5,7 @@
 핵심 목표는 다음과 같다.
 - 누구라도 같은 저장소 구조와 위키 기준만으로 `mdx -> 슬라이드` 변환을 수행할 수 있어야 한다.
 - 실행 과정은 `위키 -> 이슈 -> docs/run-xxx -> 결과물` 순서로 추적 가능해야 한다.
-- 결과는 한 번 만들고 끝나는 것이 아니라, `검증 -> revise -> 재실행` 루프로 개선 가능해야 한다.
+- 결과는 한 번 만들고 끝나는 것이 아니라, `검증 -> revise -> rollback -> 재실행` 루프로 개선 가능해야 한다.
 - Codex와 Gitea를 함께 사용해 작업 기준, 실행 기록, 산출물, 검증 결과를 모두 남긴다.
 
 ## 저장소 역할
@@ -15,17 +15,21 @@
 1. 입력과 산출물 저장소
 - `mdx` 원문 입력
 - 중간 구조화 결과
+- stage snapshot
 - 최종 HTML 결과물
 - 검증 기록
 
 2. 실행 운영 저장소
 - Step 1 ~ Step 6 이슈 정의
-- 자동 실행 루프 스크립트
+- stage 기반 실행 스크립트
+- 자동 루프 스크립트
 - Gitea 이슈 코멘트 자동 등록 스크립트
 
 3. 반복 개선 저장소
 - 실패 분류
 - 수정 액션
+- `retry-plan.json`
+- rollback 이력
 - 다음 반복에 반영할 개선 방향
 
 4. 협업 저장소
@@ -36,7 +40,7 @@
 ## 전체 구조
 
 - `docs/`
-  - run별 입력, 중간 산출물, 최종 결과물, 검증 결과
+  - run별 입력, 중간 산출물, stage snapshot, 최종 결과물, 검증 결과
 - `scripts/`
   - 실제 실행, 자동 루프, Gitea 이슈 코멘트 등록 스크립트
 - `issues/`
@@ -83,12 +87,13 @@
 - 원본 입력 `mdx`
 - 중간 해석 파일
 - 계획 파일
+- stage context snapshot
 - 생성 HTML
 - measurement 결과
 - validation 결과
 - 이슈 코멘트 원문
 
-즉, `docs/run-xxx`는 `실제로 무엇이 만들어졌는가`를 저장한다.
+즉, `docs/run-xxx`는 `실제로 무엇이 만들어졌는가`와 `어느 stage에서 무엇이 바뀌었는가`를 저장한다.
 
 ## 실행 대상 입력
 
@@ -109,8 +114,8 @@
 2. Step 이슈를 읽는다.
 3. `docs/run-xxx/01-input`의 원본 `mdx`를 입력으로 사용한다.
 4. Step 1 ~ Step 4 결과를 기준으로 실행 준비를 마친다.
-5. `scripts/run_from_artifacts.py`로 실제 후반부 실행을 수행한다.
-6. `scripts/auto_loop_runner.py`로 검증, 자동 보정, 반복 실행을 수행한다.
+5. `scripts/run_from_artifacts.py`로 실제 stage 실행을 수행한다.
+6. `scripts/auto_loop_runner.py`로 검증, retry-plan 생성, rollback, 반복 실행을 수행한다.
 7. 결과를 `docs/run-xxx/05-execution`, `06-validation`에 저장한다.
 8. Step 5, Step 6 결과를 Gitea 이슈 코멘트로 남긴다.
 
@@ -138,12 +143,35 @@
 
 ### Step 5. 실제 수행
 - 실제 HTML 생성과 렌더링, 측정을 수행한다.
-- 결과는 `05-execution/`에 남긴다.
+- stage snapshot과 산출물은 `05-execution/`에 남긴다.
 
 ### Step 6. 검증 및 기록
 - 핵심 메시지 가시성, 비교 정보, 이미지 참조, overflow 여부를 검증한다.
+- 실패 시 retry-plan과 rollback 기준을 만든다.
 - 결과는 `06-validation/`에 남긴다.
 
+## stage snapshot
+
+`run_from_artifacts.py`는 실행 중간 상태를 stage별로 저장한다.
+
+예시:
+- `stage_0_context.json`
+- `stage_1a_context.json`
+- `stage_1b_context.json`
+- `stage_1_5a_context.json`
+- `stage_1_7_context.json`
+- `stage_1_5b_context.json`
+- `stage_2_context.json`
+- `stage_2_verification.json`
+- `stage_3_context.json`
+- `stage_4_context.json`
+- `final_context.json`
+
+이 구조가 중요한 이유:
+- 최종 `final.html`만 보고 수정하지 않는다.
+- 실패가 나면 어느 stage로 돌아가야 하는지 추적할 수 있다.
+- 무한 루프에 가까운 반복 개선의 근거가 된다.
+
 ## 자동 루프
 
 이 저장소의 핵심은 한 번 생성하고 끝나는 것이 아니라, 실패 시 자동으로 보정하고 다시 실행하는 루프다.
@@ -153,15 +181,35 @@
 
 이 스크립트가 하는 일:
 - `run_from_artifacts.py` 실행
-- 결과 HTML 및 measurement 로드
+- 결과 HTML, measurement, stage snapshot 로드
 - strict 검증 수행
-- 실패 시 자동 보정 시도
-- 필요하면 더 짧고 강한 컴팩트 레이아웃으로 재구성
+- 실패 시 `retry-plan.json` 생성
+- 실패 분류에 따라 rollback stage 결정
+- `stage-1b-refined-concepts.json` 보정 및 이력 백업 생성
+- 다시 실행 후 재검증
 - validation 결과 기록
 - Step 5 / Step 6 코멘트 파일 작성
 - Gitea 이슈 코멘트 자동 등록
 
-즉, 이 스크립트는 `실행 -> 검증 -> revise -> 자동 보정 -> 재검증`의 핵심 루프를 담당한다.
+즉, 이 스크립트는 `실행 -> 검증 -> retry-plan -> rollback -> 재실행 -> 재검증`의 핵심 루프를 담당한다.
+
+## retry-plan과 rollback
+
+검증 실패 시 `04-plan/retry-plan.json`이 생성된다.
+
+이 파일에는 다음이 들어간다.
+- 실패 분류
+- rollback stage
+- 실패 이유
+- 어떤 topic 또는 budget을 어떻게 보정할지에 대한 mutation 목록
+
+또한 `04-plan/history/` 아래에 stage 입력의 이전 버전이 백업된다.
+
+예시:
+- `stage-1b-refined-concepts.iteration-1.json`
+- `stage-1b-refined-concepts.iteration-2.json`
+
+즉, 루프는 단순히 마지막 HTML을 덮어쓰는 것이 아니라, stage 입력을 보정하고 다시 생성하는 구조다.
 
 ## strict 검증 기준
 
@@ -175,21 +223,25 @@
 - 핵심 메시지 가시 텍스트 존재
 - 이미지/도해 참조 문구 존재
 - 비교 핵심 4축(범위, 프로세스, 성과품, 확장성) 존재
+- 관계도 블록 존재
 
-즉, `측정 통과 + 가시 정보 보존`이 둘 다 만족되어야 한다.
+즉, `측정 통과 + 가시 정보 보존 + 슬라이드 구조 유지`가 모두 만족되어야 한다.
 
 ## 주요 스크립트
 
 ### `scripts/run_from_artifacts.py`
 역할:
-- Step 4에서 만들어진 입력 산출물을 사용해 실제 후반부 생성 실행
-- `generated_html.json`, `final.html`, `measurement.json`, `context.json` 저장
+- Step 4에서 만들어진 입력 산출물을 사용해 실제 stage 실행 수행
+- stage snapshot 저장
+- `generated_html.json`, `final.html`, `measurement.json`, `context.json`, `final_context.json` 저장
+- `retry-plan.json`이 있으면 `stage_2`에서 재생성 전략 적용
 
 ### `scripts/auto_loop_runner.py`
 역할:
 - 실행 결과를 다시 읽음
 - strict 검증 수행
-- 필요 시 자동 보정
+- 실패 시 retry-plan 생성
+- rollback 기준에 따라 stage 입력 보정
 - validation 기록 저장
 - Step 5 / Step 6 코멘트 자동 생성
 - Gitea 이슈 코멘트 자동 등록
@@ -239,7 +291,7 @@ $env:GITEA_TOKEN="발급받은_개인_액세스_토큰"
 3. 필요한 Step 1 ~ Step 4 산출물을 채운다.
 4. 위키의 `Prompt`를 기준으로 실행한다.
 5. `scripts/auto_loop_runner.py`를 실행한다.
-6. 결과를 확인한다.
+6. 결과와 retry-plan, history를 확인한다.
 
 ## 사람이 실제로 하는 최소 판단
 
@@ -247,6 +299,7 @@ $env:GITEA_TOKEN="발급받은_개인_액세스_토큰"
 - 최종 `final.html`이 실제 사용 목적에 맞는가
 - 너무 과하게 압축되지는 않았는가
 - 표현 톤이나 정보 강조가 의도와 맞는가
+- stage rollback 방향이 설득력 있는가
 
 즉, 시스템의 `pass`는 운영 기준 합격이고, 최종 실사용 품질은 사람 검토로 한 번 더 확인하면 가장 좋다.
 
@@ -257,6 +310,8 @@ $env:GITEA_TOKEN="발급받은_개인_액세스_토큰"
 - 생성 HTML JSON: `docs/run-001/05-execution/generated_html.json`
 - 측정 결과: `docs/run-001/05-execution/measurement.json`
 - 검증 결과: `docs/run-001/06-validation/validation-result.md`
+- 재시도 계획: `docs/run-001/04-plan/retry-plan.json`
+- 재시도 이력: `docs/run-001/04-plan/history/`
 
 ## 현재 상태
 
@@ -266,9 +321,9 @@ $env:GITEA_TOKEN="발급받은_개인_액세스_토큰"
 - `mdx` 입력을 저장소 안에 둔다.
 - Codex가 위키와 이슈를 읽는다.
 - 단계별 실행을 수행한다.
-- 산출물을 저장한다.
+- stage snapshot을 저장한다.
 - strict 검증을 수행한다.
-- 실패 시 자동 보정 후 재실행한다.
+- 실패 시 retry-plan과 rollback으로 재실행한다.
 - Gitea 이슈 코멘트로 결과를 남긴다.
 
 ## 한 줄 요약