sync: agent-ops from agentic-framework v1.1.51

2026-05-25 12:38:35 +09:00 · 2026-05-25 12:38:35 +09:00 · 300b58b6d8
commit 300b58b6d8
parent e9a9d3148a
19 changed files with 247 additions and 45 deletions
--- a/.clinerules
+++ b/.clinerules
@ -7,6 +7,7 @@
 - 불확실하면 단정하지 말고 후보를 제시한다.
 - `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
 - `agent-ops/roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-ops/roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
+- agent-ops 구조, 규칙, 스킬, 로드맵, 런타임 책임 경계를 설계하거나 수정할 때만 `agent-ops/rules/common/philosophy.md`를 읽는다.

 **세션 최초 1회 아래 파일을 순서대로 반드시 읽는다.** 파일이나 디렉터리가 없는 항목은 건너뛴다. 그외에 스킵은 금지한다.

--- a/.cursorrules
+++ b/.cursorrules
@ -7,6 +7,7 @@
 - 불확실하면 단정하지 말고 후보를 제시한다.
 - `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
 - `agent-ops/roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-ops/roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
+- agent-ops 구조, 규칙, 스킬, 로드맵, 런타임 책임 경계를 설계하거나 수정할 때만 `agent-ops/rules/common/philosophy.md`를 읽는다.

 **세션 최초 1회 아래 파일을 순서대로 반드시 읽는다.** 파일이나 디렉터리가 없는 항목은 건너뛴다. 그외에 스킵은 금지한다.

--- a/AGENTS.md
+++ b/AGENTS.md
@ -7,6 +7,7 @@
 - 불확실하면 단정하지 말고 후보를 제시한다.
 - `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
 - `agent-ops/roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-ops/roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
+- agent-ops 구조, 규칙, 스킬, 로드맵, 런타임 책임 경계를 설계하거나 수정할 때만 `agent-ops/rules/common/philosophy.md`를 읽는다.

 **세션 최초 1회 아래 파일을 순서대로 반드시 읽는다.** 파일이나 디렉터리가 없는 항목은 건너뛴다. 그외에 스킵은 금지한다.

--- a/CLAUDE.md
+++ b/CLAUDE.md
@ -7,6 +7,7 @@
 - 불확실하면 단정하지 말고 후보를 제시한다.
 - `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
 - `agent-ops/roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-ops/roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
+- agent-ops 구조, 규칙, 스킬, 로드맵, 런타임 책임 경계를 설계하거나 수정할 때만 `agent-ops/rules/common/philosophy.md`를 읽는다.

 **세션 최초 1회 아래 파일을 순서대로 반드시 읽는다.** 파일이나 디렉터리가 없는 항목은 건너뛴다. 그외에 스킵은 금지한다.

--- a/GEMINI.md
+++ b/GEMINI.md
@ -7,6 +7,7 @@
 - 불확실하면 단정하지 말고 후보를 제시한다.
 - `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
 - `agent-ops/roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-ops/roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
+- agent-ops 구조, 규칙, 스킬, 로드맵, 런타임 책임 경계를 설계하거나 수정할 때만 `agent-ops/rules/common/philosophy.md`를 읽는다.

 **세션 최초 1회 아래 파일을 순서대로 반드시 읽는다.** 파일이나 디렉터리가 없는 항목은 건너뛴다. 그외에 스킵은 금지한다.

--- a/agent-ops/.version
+++ b/agent-ops/.version
@ -1 +1 @@
-1.1.50
+1.1.51
--- a/agent-ops/rules/common/philosophy.md
+++ b/agent-ops/rules/common/philosophy.md
@ -0,0 +1,82 @@
+# Agent-Ops 철학
+
+이 문서는 agent-ops 구조, 규칙, 스킬, 로드맵, 런타임 책임 경계를 설계하거나 고칠 때만 읽어.
+일반 구현 작업에서는 읽지 마.
+
+## 핵심
+
+- agent-ops는 AI agent가 작업하기 위한 규칙이자 가이드다.
+- 사람 문서처럼 장황하게 설명하지 말고, agent가 바로 실행할 수 있게 써.
+- 필요한 컨텍스트만 읽게 만들어. 모든 문서를 항상 읽게 만들지 마.
+- 애매한 형식을 만들지 마. 경로, 상태, id, 입력, 출력은 판별 가능해야 한다.
+- 문서는 짧고 단단해야 한다. 길어서 이해되는 문서보다 짧아서 헷갈리지 않는 문서가 낫다.
+
+## 문서 작성
+
+- 규칙과 스킬은 핵심만 써.
+- 같은 말을 여러 문서에 반복하지 마. 한 곳에 두고 링크해.
+- 설명보다 조건, 입력, 행동, 금지 사항을 우선해.
+- "적절히", "필요하면", "가능하면" 같은 말은 판별 기준이 없으면 쓰지 마.
+- 예외가 있으면 예외 조건을 같이 써.
+- 긴 배경 설명은 README나 별도 참조 문서로 보내고, 실행 문서에는 실행 규칙만 남겨.
+- 반말이어도 된다. 명확한 명령형이 더 좋다.
+
+## 라우팅
+
+- 라우팅은 얕아야 한다.
+- 1홉은 진입 파일에서 공통/프로젝트 규칙을 읽는 단계다.
+- 2홉은 규칙에서 domain rule, roadmap rule, router를 따라가는 단계다.
+- 3홉은 router에서 SKILL.md를 읽는 단계다.
+- 4홉은 skill이 템플릿이나 참조 문서를 추가로 읽는 단계다.
+- 4홉 이상이 필요하면 구조가 과하게 쪼개졌는지 먼저 의심해. 필요하면 앞 문서에 바로 가는 링크를 추가해.
+- 깊은 링크 체인을 만들지 말고, 필요한 문서가 무엇인지 앞 문서에서 바로 보이게 해.
+- 일반 작업마다 router, 모든 skill, 전체 roadmap, archive를 읽게 만들지 마.
+
+## LLM과 런타임
+
+- LLM은 의미 판단, 범위 판단, 요약, 설계 선택을 맡는다.
+- 런타임은 파일명, 폴더명, 상태값, exit code처럼 결정적으로 판별 가능한 일을 맡는다.
+- LLM 없이 처리할 수 있는 구간은 파일 규약으로 빼.
+- 런타임 신호는 문서 본문보다 경로와 이름에 둬.
+- 런타임 신호를 만들 때는 agent가 본문을 읽지 않아도 판별 가능해야 한다.
+- `m-<milestone-slug>` 같은 prefix는 런타임 판별을 위한 신호다.
+- code-review는 PASS 산출물을 만들고 완료 이벤트 메타데이터를 남긴다.
+- roadmap 반영 여부와 호출 타이밍은 런타임이 완료 이벤트를 보고 판단한다.
+
+## 로드맵
+
+- roadmap은 장기 기억이고, agent-task는 실행 상태다.
+- current는 현재 작업 하나가 아니라 활성 Phase/Milestone 후보 창이다.
+- Phase와 Milestone은 큰 방향과 완료 기준을 담는다.
+- 구현 계획은 agent-task의 PLAN/CODE_REVIEW 루프에 둔다.
+- 완료 후보는 바로 archive하지 말고 `[검토중]`으로 둔다.
+- archive는 일반 작업에서 읽지 않는다. 과거 근거가 필요할 때만 링크를 따라 읽는다.
+
+## 스킬
+
+- skill은 절차 문서다.
+- skill 하나에 책임 하나만 둬.
+- skill이 다른 skill을 자동으로 깊게 호출하는 구조를 만들지 마.
+- skill 본문은 실행에 필요한 규칙만 둬.
+- 템플릿은 출력 형식이 흔들릴 때만 둬.
+- 스킬 업데이트 시 router, rules, template, 출력 형식이 같은 계약을 말하는지 같이 확인해.
+
+## 좋은 구조
+
+- 진입 파일은 최소 규칙만 둔다.
+- common rules는 공통 시작점만 둔다.
+- project rules는 프로젝트 특화 판단만 둔다.
+- domain rules는 특정 코드 영역 규칙만 둔다.
+- skills는 반복 작업 절차만 둔다.
+- roadmap은 장기 목표와 완료 기준만 둔다.
+- agent-task는 실행 중인 작업 상태와 완료 산출물만 둔다.
+
+## 경고 신호
+
+- 같은 내용을 세 군데 이상 설명하고 있다.
+- 어떤 문서를 읽어야 할지 문서 안에서 다시 찾아야 한다.
+- 상태값이 사람은 이해하지만 런타임은 판별하기 어렵다.
+- skill이 너무 많은 예외를 품고 있다.
+- README가 내부 규칙 문서처럼 길어지고 있다.
+- archive를 일반 작업 컨텍스트로 끌어오고 있다.
+- LLM이 파일명만 봐도 될 일을 본문까지 읽어 판단하고 있다.
--- a/agent-ops/rules/common/rules-roadmap.md
+++ b/agent-ops/rules/common/rules-roadmap.md
@ -7,6 +7,7 @@
 - 최상위 로드맵은 `agent-ops/roadmap/ROADMAP.md`다.
 - 활성 Phase는 `agent-ops/roadmap/phase/<phase-slug>/PHASE.md`에 둔다.
 - 활성 Milestone은 해당 Phase 아래 `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md`에 둔다.
+- `<phase-slug>`와 `<milestone-slug>`는 소문자 영문, 숫자, 하이픈만 사용한다.
 - 완료된 Phase는 scaffold 그대로 `agent-ops/roadmap/archive/phase/<phase-slug>/PHASE.md`로 이동하고, 하위 Milestone도 `archive/phase/<phase-slug>/milestones/` 아래에 둔다.
 - 진행중 Phase 안에서 완료된 Milestone은 활성 `PHASE.md`에 짧은 archive 링크를 남기고, 상세 문서는 `agent-ops/roadmap/archive/phase/<phase-slug>/milestones/`로 이동한다.
 - archive `PHASE.md`는 Phase 자체가 완료/폐기될 때만 만들며, 진행중 Phase의 완료 Milestone만 archive된 경우 archive Phase 디렉터리에 `milestones/`만 있을 수 있다.
@ -25,6 +26,7 @@
 - `current.md`는 현재 작업 위치가 아니라 활성 Phase와 활성 Milestone 후보 목록이다.
 - 활성 Phase는 `agent-ops/roadmap/phase/**/PHASE.md`만 대상으로 한다.
 - 활성 Milestone은 `agent-ops/roadmap/phase/**/milestones/*.md`만 대상으로 한다.
+- `current.md`에는 `[완료]` 또는 `[폐기]` Phase/Milestone을 남기지 않는다. 완료 후보는 승인 전까지 `[검토중]`으로 둔다.
 - "로드맵에 추가", "마일스톤에 추가"처럼 target 없는 신규 작업 추가 요청은 `update-roadmap` 스킬로 처리하고, Phase/Milestone/Epic/Task 배치를 자동 판단한다.
 - target 없는 신규 추가 요청은 먼저 요청 규모를 `phase`, `milestone`, `epic`, `task`, `subtask`, `context` 중 가장 작은 충분한 단위로 판정한다.
 - target 없는 신규 추가 요청은 활성 창만으로 결정하지 말고 필요한 경우 `ROADMAP.md`의 Phase 흐름과 관련 Phase/Milestone 문서를 비교한다.
@ -38,9 +40,13 @@

 ## 상태 표기

- Phase와 Milestone 상태 표기는 `[계획]`, `[진행중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다.
+- Phase와 Milestone 상태 표기는 `[계획]`, `[진행중]`, `[검토중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다.
 - 갱신 범위에 포함된 기존 진행 상태 표기는 `[진행중]`으로 정리한다.
- `ROADMAP.md`의 Phase 흐름과 `PHASE.md`의 Milestone 흐름은 완료, 진행중, 계획 순서를 기본으로 하며 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
+- `[검토중]`은 모든 필수 작업과 완료 기준이 충족된 것으로 보이나, 사용자의 최종 완료 확인과 archive 승인이 아직 남은 완료 후보 상태다.
+- `[검토중]` 항목은 활성 경로에 남기고 `current.md`의 활성 후보로 유지할 수 있다.
+- 검토 결과 보완이 필요하면 별도 reopen 상태를 만들지 않고 `[진행중]`으로 되돌린 뒤 `완료 리뷰` 또는 `작업 컨텍스트`에 보완 방향을 남긴다.
+- 검토 결과 보류 또는 폐기 결정이 나면 `[보류]` 또는 `[폐기]`로 전환한다.
+- `ROADMAP.md`의 Phase 흐름과 `PHASE.md`의 Milestone 흐름은 완료, 검토중, 진행중, 계획 순서를 기본으로 하며 아래로 갈수록 미래 작업에 가까워지게 정렬한다.

 ## 구현 잠금

@ -62,6 +68,27 @@
 - 다른 Milestone에서는 같은 id를 다시 사용할 수 있다. 여러 Milestone 후보에서 같은 id가 발견되면 Milestone 이름이나 문서 경로로 대상을 확정한다.
 - 사용자가 epic-id 또는 item-id를 언급하면 해당 Milestone의 Epic/Task 항목을 우선 anchor로 삼고, 기존 id는 명시적 요청 없이 바꾸지 않는다.

+## Milestone 기반 agent-task
+
+- `plan` 스킬이 활성 Milestone 범위의 구현 계획을 만들면 task group은 `agent-task/m-<milestone-slug>/` 형식을 사용한다.
+- `<milestone-slug>`는 활성 Milestone 파일명에서 `.md`를 제거한 값이며, Phase slug, Epic id, Task id, 별도 task slug를 task group에 넣지 않는다.
+- split 작업은 기존 규칙 그대로 `agent-task/m-<milestone-slug>/<subtask_dir>/` 아래에 둔다.
+- `m-<milestone-slug>`는 Milestone 기반 작업 전용 예약 prefix이며, 일반 작업 task group은 `m-`으로 시작하지 않는다.
+- 런타임은 파일 내부가 아니라 task group 이름만으로 Milestone 기반 작업 여부를 판별한다.
+- `code-review`에서 `m-<milestone-slug>` 작업이 PASS되면 roadmap을 직접 수정하거나 `update-roadmap`을 직접 호출하지 않는다.
+- 런타임은 PASS 완료 이벤트의 task group에서 `m-<milestone-slug>`를 판별하고, 상태 체크 후 `update-roadmap` 흐름으로 Milestone 업데이트를 호출한다.
+- 런타임 완료 이벤트가 최종 archive 경로만 갖고 있으면 `agent-task/archive/YYYY/MM/m-<milestone-slug>/...`를 `agent-task/m-<milestone-slug>/...` 형태의 `origin-task`로 정규화해 전달한다.
+- 런타임 호출에서 매칭되는 활성 Milestone이 없거나 둘 이상이면 추정하지 말고 수동 target 선택이 필요하다고 보고한다.
+- `WARN` 또는 `FAIL`은 Milestone 완료 업데이트를 하지 않고 같은 `m-<milestone-slug>` task group에서 follow-up plan/review를 이어간다.
+
+## 완료 리뷰
+
+- Task 완료나 Milestone 갱신 시 필수 Epic/Task와 완료 기준이 모두 evidence와 함께 `[x]`가 되었는지 확인한다.
+- 모두 충족된 것으로 보이면 Milestone을 `[완료]`로 바로 바꾸거나 archive로 이동하지 말고 `[검토중]`으로 바꾼다.
+- `[검토중]`으로 바꿀 때는 Milestone 문서에 `완료 리뷰` 섹션을 만들거나 갱신하고, 완료 근거 1~3줄과 사용자에게 필요한 최종 확인 항목을 남긴다.
+- 사용자가 완료를 승인한 뒤에만 `[완료]`로 전환하고 archive 이동을 수행한다.
+- Phase도 모든 하위 Milestone이 `[완료]` 또는 `[폐기]`로 정리되어 Phase 완료 후보가 되면 `[검토중]`으로 두고 사용자 최종 확인을 받은 뒤 `[완료]` 또는 `[폐기]`로 전환한다.
+
 ## 작업 지점 분석

 - 현재 작업 지점이나 남은 작업 분석 요청은 `analyze-roadmap-position` 스킬로 처리한다.
@ -72,6 +99,7 @@
 ## 아카이브

 - 완료 또는 폐기되어 현재 작업 후보에서 제외할 Phase/Milestone은 `update-roadmap` 스킬로 아카이빙한다.
+- `[검토중]` Phase/Milestone은 archive 대상이 아니며, 사용자 승인 전까지 활성 경로에 남긴다.
 - Phase 아카이브 대상은 `agent-ops/roadmap/archive/phase/<phase-slug>/PHASE.md`와 같은 scaffold로 이동한다.
 - Milestone 아카이브 대상은 `agent-ops/roadmap/archive/phase/<phase-slug>/milestones/<milestone-slug>.md`로 이동한다.
 - 아카이빙할 때는 활성 `ROADMAP.md` 또는 활성 `PHASE.md`에 archive 문서 링크와 짧은 요약만 남긴다.
--- a/agent-ops/rules/common/rules.md
+++ b/agent-ops/rules/common/rules.md
@ -7,6 +7,7 @@
 - 불확실하면 단정하지 말고 후보를 제시한다.
 - `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
 - `agent-ops/roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-ops/roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
+- agent-ops 구조, 규칙, 스킬, 로드맵, 런타임 책임 경계를 설계하거나 수정할 때만 `agent-ops/rules/common/philosophy.md`를 읽는다.

 **세션 최초 1회 아래 파일을 순서대로 반드시 읽는다.** 파일이나 디렉터리가 없는 항목은 건너뛴다. 그외에 스킵은 금지한다.

--- a/agent-ops/skills/common/_templates/roadmap-current-template.md
+++ b/agent-ops/skills/common/_templates/roadmap-current-template.md
@ -2,12 +2,12 @@

 ## 활성 Phase

- [<계획 | 진행중 | 완료 | 보류 | 폐기>] <phase-name>
+- [<계획 | 진행중 | 검토중 | 보류>] <phase-name>
  - 경로: `agent-ops/roadmap/phase/<phase-slug>/PHASE.md`

 ## 활성 Milestone

- [<계획 | 진행중 | 완료 | 보류 | 폐기>] <milestone-name>
+- [<계획 | 진행중 | 검토중 | 보류>] <milestone-name>
  - Phase: `agent-ops/roadmap/phase/<phase-slug>/PHASE.md`
  - 경로: `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md`

@ -17,6 +17,8 @@
 - 활성 Phase는 `agent-ops/roadmap/phase/<phase-slug>/PHASE.md`를 가리킨다.
 - 활성 Milestone은 `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md`를 가리킨다.
 - 활성 항목은 아카이브 경로를 포함하지 않는다.
+- `[검토중]` 항목은 사용자 완료 확인 전까지 활성 항목으로 남길 수 있다.
+- `[완료]` 또는 `[폐기]` 항목은 archive 링크를 남긴 뒤 활성 항목에서 제거한다.
 - 요청 내용, 현재 브랜치, 변경 파일, 관련 코드 경로를 보고 가장 관련 있는 Phase와 Milestone을 선택하고 같은 세션에서 1회 읽는다.
 - 활성 Phase 또는 Milestone 둘 이상에 걸치면 필요한 문서를 모두 읽고 작업 범위를 좁힌다.
 - 활성 범위 밖의 작업이면 `agent-ops/roadmap/ROADMAP.md`의 Phase 흐름을 확인하고 사용자에게 진행 또는 전환 여부를 확인한다.
--- a/agent-ops/skills/common/_templates/roadmap-milestone-template.md
+++ b/agent-ops/skills/common/_templates/roadmap-milestone-template.md
@ -11,7 +11,7 @@

 ## 상태

-[<계획 | 진행중 | 완료 | 보류 | 폐기>]
+[<계획 | 진행중 | 검토중 | 완료 | 보류 | 폐기>]

 ## 구현 잠금

@ -43,6 +43,16 @@ epic-id와 item-id는 해당 Milestone 안에서만 유일하면 되고, 다른

 - [ ] <완료 여부를 확인할 수 있는 기준>

+## 완료 리뷰
+
+- 상태: <없음 | 요청됨 | 승인됨 | 보완 필요 | 보류 | 폐기>
+- 요청일: <YYYY-MM-DD | 없음>
+- 완료 근거: <모든 필수 Task와 완료 기준 충족 여부를 1~3줄로 요약>
+- 리뷰 필요:
+  - [ ] 사용자가 완료 결과를 확인했다
+  - [ ] archive 이동을 승인했다
+- 리뷰 코멘트: <없음 | 보완/보류/폐기 방향성>
+
 ## 범위 제외

 - <이 Milestone에서 의도적으로 하지 않는 일>
--- a/agent-ops/skills/common/_templates/roadmap-phase-template.md
+++ b/agent-ops/skills/common/_templates/roadmap-phase-template.md
@ -2,7 +2,7 @@

 ## 상태

-[<계획 | 진행중 | 완료 | 보류 | 폐기>]
+[<계획 | 진행중 | 검토중 | 완료 | 보류 | 폐기>]

 ## 목표

@ -10,10 +10,10 @@

 ## Milestone 흐름

-완료된 Milestone은 archive 경로를 가리키고, 진행중 또는 계획 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
-완료, 진행중, 계획 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
+완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
+완료, 검토중, 진행중, 계획 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.

- [<계획 | 진행중 | 완료 | 보류 | 폐기>] <Milestone 이름>
+- [<계획 | 진행중 | 검토중 | 완료 | 보류 | 폐기>] <Milestone 이름>
  - 경로: `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md` 또는 `agent-ops/roadmap/archive/phase/<phase-slug>/milestones/<milestone-slug>.md`
  - 요약: <목표 또는 결과 1문장>

--- a/agent-ops/skills/common/_templates/roadmap-position-report-template.md
+++ b/agent-ops/skills/common/_templates/roadmap-position-report-template.md
@ -7,6 +7,7 @@
 - 우선순위 추천: <단일 후보 | 1순위: phase/milestone; 2순위: phase/milestone; 추천 근거>
 - 신뢰도: <높음 | 중간 | 낮음>
 - 구현 잠금: <해제 | 잠금 | 정보 없음>
+- 완료 리뷰: <없음 | 요청됨 | 보완 필요 | 승인됨 | 보류 | 폐기 | 정보 없음>
 - 결정 필요: <없음 | 현재 요청에 직접 영향을 주는 사용자 결정 항목 요약>
 - 한 줄 결론: <현재 작업 지점과 가장 중요한 다음 판단을 1문장으로 요약>

--- a/agent-ops/skills/common/_templates/roadmap-template.md
+++ b/agent-ops/skills/common/_templates/roadmap-template.md
@ -8,9 +8,9 @@

 위에서 아래로 진행된 순서와 예정 흐름을 나타낸다.
 완료된 Phase도 로드맵에서 제거하지 않고, archive의 Phase 문서로 연결한다.
-진행중 Phase는 계획 Phase보다 위에 두어, 아래로 갈수록 미래 계획에 가까워지게 정렬한다.
+검토중 또는 진행중 Phase는 계획 Phase보다 위에 두어, 아래로 갈수록 미래 계획에 가까워지게 정렬한다.

- [<계획 | 진행중 | 완료 | 보류 | 폐기>] <Phase 이름>
+- [<계획 | 진행중 | 검토중 | 완료 | 보류 | 폐기>] <Phase 이름>
  - 경로: `agent-ops/roadmap/phase/<phase-slug>/PHASE.md` 또는 `agent-ops/roadmap/archive/phase/<phase-slug>/PHASE.md`
  - 요약: <이 Phase의 목표와 역할 1문장>

@ -27,6 +27,7 @@
 - 활성 Phase 또는 Milestone 밖의 작업이면 이 문서의 Phase 흐름을 확인하고 사용자에게 진행 또는 전환 여부를 확인한다.
 - 이 문서는 로드맵 생성/갱신, Phase 전환, Phase 추가/수정, 전체 구조 변경 요청이 있을 때만 읽는다.
 - 상세 작업과 완료 기준은 각 Milestone 문서의 `필수 기능`, `완료 기준`으로 관리한다.
+- 모든 필수 작업과 완료 기준이 충족된 Milestone은 먼저 `[검토중]`으로 두고, 사용자 완료 확인과 archive 승인을 받은 뒤 `[완료]`로 전환한다.
 - 완료된 Phase는 `agent-ops/roadmap/archive/phase/<phase-slug>/PHASE.md`로 이동하고, 하위 Milestone도 같은 archive Phase scaffold 아래에 둔다.
 - 진행중 Phase 안에서 완료된 Milestone은 활성 Phase 문서에 짧은 링크를 남기고, 상세 문서는 `agent-ops/roadmap/archive/phase/<phase-slug>/milestones/`로 이동한다.
 - archive `PHASE.md`는 Phase 자체가 완료 또는 폐기될 때만 만들며, 진행중 Phase의 완료 Milestone만 archive된 경우 archive Phase 디렉터리에 `milestones/`만 있을 수 있다.
--- a/agent-ops/skills/common/analyze-roadmap-position/SKILL.md
+++ b/agent-ops/skills/common/analyze-roadmap-position/SKILL.md
@ -1,6 +1,6 @@
 ---
 name: analyze-roadmap-position
-version: 1.8.0
+version: 1.9.0
 description: "지금 작업이 뭐지?, 현재 작업 분석, 남은 작업 확인 요청에 대해 로드맵이 있으면 활성 Phase/Milestone과 코드 상태를 함께 읽고, 로드맵이 없으면 git/active task 기준으로 현재 작업 지점과 남은 일을 추정하는 읽기 전용 스킬"
 ---

@ -41,7 +41,7 @@ Milestone의 `필수 기능`에 Epic/Task id가 있으면 남은 작업과 판
   - `agent-ops/roadmap/current.md`를 읽고 활성 Phase, 활성 Milestone 후보와 선택 규칙을 파악한다.
   - `current.md`의 후보가 `agent-ops/roadmap/archive/**`를 가리키면 해당 문서는 읽지 말고 로드맵 갱신 필요 항목으로 기록한다.
   - 관련 활성 Phase 문서를 읽고 Phase 목표, Milestone 흐름, Phase 경계를 확인한다.
-   - 관련 활성 Milestone 문서를 읽고 목표, 범위, 필수 기능, 완료 기준, 범위 제외, 구현 잠금을 확인한다.
+   - 관련 활성 Milestone 문서를 읽고 목표, 범위, 필수 기능, 완료 기준, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다.
   - 목록이 많으면 사용자 요청이나 변경 파일과 관련 높은 Phase/Milestone부터 읽는다.
   - `current.md` 형식이 맞지 않으면 `ROADMAP.md`를 자동으로 읽지 말고 로드맵 컨텍스트 불확실성을 보고한다.

@ -56,11 +56,11 @@ Milestone의 `필수 기능`에 Epic/Task id가 있으면 남은 작업과 판
   - 활성 Milestone의 목표, 범위, 완료 기준, 범위 제외 항목과 변경 파일/요청 내용을 비교한다.
   - Milestone의 `필수 기능`에서 관련 Epic/Task id가 있으면 판단 근거와 남은 작업에 함께 기록한다.
   - 여러 Milestone 후보에서 같은 epic-id 또는 item-id가 보이면 id만으로 위치를 확정하지 말고 Milestone 이름과 문서 링크를 함께 제시한다.
-   - 활성 Milestone의 `구현 잠금` 섹션, 상태, `결정 필요` 항목을 함께 확인한다.
+   - 활성 Milestone의 `구현 잠금` 섹션, 상태, `완료 리뷰` 섹션, `결정 필요` 항목을 함께 확인한다.
   - 하나의 Milestone에 명확히 속하면 단일 후보로 보고한다.
   - 둘 이상의 Phase 또는 Milestone에 걸치면 복수 후보로 보고하고, 어떤 파일이나 기능이 어느 후보에 닿는지 나눈다.
   - 복수 후보일 때는 후보 우선순위를 추천한다. 요청 문장/변경 파일 직접성, 현재 diff 근거, Milestone 상태, 구현 잠금, 선후 의존성, Phase/Milestone 흐름상 위치를 함께 본다.
-   - 관련성이 비슷하면 `[진행중]` 후보를 `[계획]` 후보보다 우선하고, 같은 상태라면 현재 변경 파일을 더 많이 설명하는 후보를 우선한다.
+   - 관련성이 비슷하면 `[검토중]` 후보는 리뷰/승인 요청에서 우선하고, 구현 작업 요청에서는 `[진행중]` 후보를 `[계획]` 후보보다 우선한다. 같은 상태라면 현재 변경 파일을 더 많이 설명하는 후보를 우선한다.
   - 사용자가 특정 Phase, Milestone, epic-id, item-id, 파일 경로를 명시했으면 그 후보를 우선하되, 범위 제외나 잠금 결정 필요가 있으면 우선순위 근거에 같이 적는다.
   - 로드맵이 있고 활성 Phase/Milestone 밖으로 보이면 `ROADMAP.md`의 Phase 흐름을 확인하고 전환 또는 신규 Phase/Milestone 필요성을 제안한다.

@ -87,6 +87,7 @@ Milestone의 `필수 기능`에 Epic/Task id가 있으면 남은 작업과 판
 - [ ] 로드맵이 있는 프로젝트에서 `current.md`만 근거로 현재 위치를 단정하지 않았는가
 - [ ] 로드맵이 있는 프로젝트에서 활성 Phase 문서의 목표와 Phase 경계를 확인했는가
 - [ ] 로드맵이 있는 프로젝트에서 활성 Milestone 문서의 목표와 범위 제외 항목을 확인했는가
+- [ ] 로드맵이 있는 프로젝트에서 활성 Milestone 문서의 `완료 리뷰` 섹션과 `[검토중]` 상태 여부를 확인했는가
 - [ ] `agent-ops/roadmap/archive/**` 문서를 명시 요청 없이 읽지 않았는가
 - [ ] 로드맵이 있는 프로젝트에서 활성 Milestone 문서의 `구현 잠금` 섹션 존재 여부, 상태, `결정 필요` 항목을 확인했는가
 - [ ] 로드맵이 있는 프로젝트에서 추정 Phase/Milestone마다 문서 링크를 출력했는가
@ -111,5 +112,5 @@ Milestone의 `필수 기능`에 Epic/Task id가 있으면 남은 작업과 판
 - 로드맵이 없는 프로젝트에서 로드맵 파일을 만들거나 읽는 것을 현재 작업 분석의 선행 조건으로 삼지 않는다.
 - 사용자가 명시하지 않은 상태에서 `ROADMAP.md`, `current.md`, Phase, Milestone 문서를 수정하지 않는다.
 - 사용자가 명시하지 않은 상태에서 `agent-ops/roadmap/archive/**`를 읽지 않는다.
- evidence 없이 Phase, Milestone, Epic, Task를 완료 처리하지 않는다.
+- evidence 없이 Phase, Milestone, Epic, Task를 `[완료]` 또는 `[검토중]`으로 처리하지 않는다.
 - 활성 Phase/Milestone 밖 작업을 임의로 새 항목으로 추가하지 않는다.
--- a/agent-ops/skills/common/code-review/SKILL.md
+++ b/agent-ops/skills/common/code-review/SKILL.md
@ -1,6 +1,6 @@
 ---
 name: code-review
-description: Use for active task review requests such as 리뷰 진행해, 리뷰해줘, 코드 리뷰해줘, code review, CODE_REVIEW.md, or 리뷰 루프. Review the active PLAN/CODE_REVIEW pair, append PASS/WARN/FAIL, archive both active files, and create the required next state: PASS writes complete.log and moves the task to archive; WARN/FAIL immediately writes follow-up PLAN/CODE_REVIEW files. Never stop after verdict append.
+description: Use for active task review requests such as 리뷰 진행해, 리뷰해줘, 코드 리뷰해줘, code review, CODE_REVIEW.md, or 리뷰 루프. Review the active PLAN/CODE_REVIEW pair, append PASS/WARN/FAIL, archive both active files, and create the required next state: PASS writes complete.log, moves the task to archive, and reports m-prefixed completion metadata for runtime; WARN/FAIL immediately writes follow-up PLAN/CODE_REVIEW files. Never stop after verdict append.
 ---

 # Code Review
@ -19,7 +19,7 @@ plan skill -> implementation -> code-review skill

 - Trigger: Korean or English active-task review requests, including `리뷰 진행해` and `리뷰해줘`, must use this skill when an active `CODE_REVIEW-*-G??.md` exists under `agent-task/*/` or `agent-task/*/*/`, excluding `agent-task/archive/**`.
 - Finalize every selected active review: append one verdict, archive the active review and plan files, then create exactly one next state before reporting.
- Next state: `PASS` writes `complete.log` and moves the task under `agent-task/archive/YYYY/MM/`; `WARN` or `FAIL` writes the next active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md`.
+- Next state: `PASS` writes `complete.log` and moves the task under `agent-task/archive/YYYY/MM/`; if the task group is `m-<milestone-slug>`, report completion metadata for the runtime event; `WARN` or `FAIL` writes the next active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md`.
 - Do not ask for confirmation before WARN/FAIL follow-up files. If details are uncertain, write the smallest concrete follow-up plan with file references and verification commands.
 - Recovery: if a prior turn appended a verdict without archive or next-state files, resume at Step 5 and finish finalization first.

@ -29,7 +29,8 @@ Active work must live under an active task directory using routed filenames. Thi

 Task path terms:

- `{task_group}` is the top-level work category under `agent-task/`, using a short snake_case name such as `refactoring`.
+- `{task_group}` is the top-level work category under `agent-task/`. Normal task groups use a short snake_case name such as `refactoring`.
+- Milestone-linked work uses the reserved task group form `m-<milestone-slug>`, where `<milestone-slug>` is the active Milestone filename without `.md`.
 - `{subtask_dir}` is used only for split work and follows the indexed directory naming contract, such as `01_core` or `02+01_db`.
 - `{subtask_name}` is the short snake_case name after the index or dependency prefix inside `{subtask_dir}`.
 - `{task_name}` in headers and templates means the active task path relative to `agent-task/`: either `{task_group}` for a single-plan task or `{task_group}/{subtask_dir}` for a split subtask.
@ -52,6 +53,15 @@ Multi-plan runtime contract:
 - Subtask directory names are the runtime dependency source of truth. Preserve them verbatim; do not normalize, reinterpret, infer extra dependencies from numeric order, or choose execution order by agent judgment.
 - If the user/runtime names a task group, task path, or subtask directory that identifies exactly one active review file, review that directory even when other active review files exist.

+Milestone task group contract:
+
+- `agent-task/m-<milestone-slug>/` is reserved for Milestone-linked work created by the plan skill.
+- Do not treat normal task groups that do not start with `m-` as runtime milestone completion targets.
+- For a selected task path, parse only the first path segment as `{task_group}`. If it matches `^m-[a-z0-9][a-z0-9-]*$`, strip `m-` to get `<milestone-slug>`.
+- Do not read or modify `agent-ops/roadmap/**` for milestone routing during code-review finalization.
+- Do not call `update-roadmap` from this skill. The runtime consumes the PASS completion event, checks current state, resolves the active Milestone, and calls `update-roadmap` if needed.
+- For `m-<milestone-slug>` PASS tasks, report the original active task path, final archive path, complete log path, task group, and milestone slug so the runtime has deterministic event inputs.
+
 Review routing rules:

 - `local`: narrow, low-risk, or first-pass review where tests and scope are clear.
@ -164,6 +174,7 @@ For `WARN` or `FAIL`, write new routed plan/review files using the plan skill fo

 - New plan number is the count of `plan_*.log` after archive.
 - Header tag is `REVIEW_<PARENT_TAG>`.
+- If the selected task group is `m-<milestone-slug>`, write the follow-up plan/review under the same `m-<milestone-slug>` task group.
 - Base the follow-up scope directly on the archived review findings. Keep it narrow and actionable.
 - Choose lane/grade again; preserve the prior route only when it was adequate, otherwise raise `GNN` and/or move `local -> cloud`.
 - Before choosing the follow-up route, apply this escalation gate:
@ -206,7 +217,8 @@ task={task_name}, plan={N}, tag={TAG}
 1. 판정을 append한다.
 2. `CODE_REVIEW-{review_lane}-GNN.md` → `code_review_{review_lane}_GNN_N.log`, `PLAN-{build_lane}-GNN.md` → `plan_{build_lane}_GNN_M.log`로 아카이브한다.
 3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 다음 active plan/review 파일을 즉시 작성한다.
-4. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
+4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
+5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.

 ---

@ -232,6 +244,7 @@ task={task_name}, plan={N}, tag={TAG}
 - [ ] active `PLAN-*-G??.md`를 `plan_{build_lane}_GNN_M.log`로 아카이브한다.
 - [ ] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
 - [ ] PASS이면 active task 디렉터리 `agent-task/{task_name}/`를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
+- [ ] PASS이고 task group이 `m-<milestone-slug>`이면 런타임이 읽을 완료 이벤트 메타데이터를 보고하고, roadmap 수정이나 `update-roadmap` 직접 호출을 하지 않는다.
 - [ ] PASS split 작업이면 이동 후 빈 active parent `agent-task/{task_group}/`를 제거하거나, 남은 sibling/file이 있어 유지했다고 확인한다.
 - [ ] WARN/FAIL이면 다음 active `PLAN-{build_lane}-GNN.md`와 `CODE_REVIEW-{review_lane}-GNN.md`를 작성하고 `complete.log`를 작성하지 않는다.

@ -295,14 +308,17 @@ After Step 6:
 - If verdict is `PASS`, determine archive month from the current completion date as `YYYY/MM`, create the needed archive parent directories, then move the selected active task directory `agent-task/{task_name}/` to `agent-task/archive/YYYY/MM/{task_name}/`. For split work, the selected active task directory is the subtask directory, and the archive must preserve the task group path, e.g. `agent-task/refactoring/01_core/` moves to `agent-task/archive/YYYY/MM/refactoring/01_core/`.
 - Do not overwrite an existing archive directory. If `agent-task/archive/YYYY/MM/{task_name}/` already exists, append the next numeric suffix to the final path segment: single-plan `agent-task/archive/YYYY/MM/{task_group}_1/`, split-plan `agent-task/archive/YYYY/MM/{task_group}/{subtask_dir}_1/`, and so on.
 - After moving a split subtask, remove the active parent `agent-task/{task_group}/` only if it is empty. If sibling subtask directories or other files remain, leave the parent task group in place.
+- If verdict is `PASS` and `{task_group}` matches `m-<milestone-slug>`, do not resolve the roadmap target and do not call `update-roadmap`. Report completion event metadata after the task archive move: `origin-task=agent-task/{task_name}` from the original active task path, `task-group={task_group}`, `milestone-slug=<milestone-slug>`, final archive path, `complete.log` path, and archived plan/review log paths.
+- The runtime consumes that completion event, checks current state, resolves `agent-ops/roadmap/phase/*/milestones/<milestone-slug>.md`, and calls `update-roadmap` if needed.
+- `WARN` and `FAIL` do not update the roadmap Milestone; the follow-up plan remains under the same `m-<milestone-slug>` task group when the original task was Milestone-linked.
 - For `PASS`, open the moved `agent-task/archive/YYYY/MM/{final_task_name}/code_review_{review_lane}_GNN_N.log`, where `{final_task_name}` is the archived task path, including `{task_group}/` for split work.
 - For `WARN` or `FAIL`, open `agent-task/{task_name}/code_review_{review_lane}_GNN_N.log`.
 - Check every applicable item in `코드리뷰 전용 체크리스트`; leave mutually exclusive verdict items unchecked.
 - If any applicable item cannot be checked, finish the missing archive, `complete.log`, task-directory move, or follow-up plan/review write first.
 - Do not recreate an active review file just to update this checklist; update the archived `code_review_*.log`.
- Only report after the archived review log has the verdict, applicable checked review-only checklist, required next-state files, and for `PASS` the final task archive move.
+- Only report after the archived review log has the verdict, applicable checked review-only checklist, required next-state files, for `PASS` the final task archive move, and for `m-*` PASS tasks the completion event metadata.

-Report Required/Suggested counts, archive names, and the final task archive path for `PASS` or new plan path for `WARN`/`FAIL`.
+Report Required/Suggested counts, archive names, the final task archive path for `PASS` or new plan path for `WARN`/`FAIL`, and any `m-*` runtime completion event metadata.

 ## Review Dimensions

@ -331,6 +347,7 @@ Report Required/Suggested counts, archive names, and the final task archive path
 - `plan_{build_lane}_GNN_M.log` exists.
 - No active `.md` files remain after PASS.
 - PASS: `complete.log` written from `agent-ops/skills/common/code-review/templates/complete-log-template.md`, then task directory moved under `agent-task/archive/YYYY/MM/` with task-group path preserved for split work.
+- PASS milestone task group: `m-<milestone-slug>` completion event metadata was reported for runtime; roadmap was not modified by code-review.
 - PASS split: empty active parent `agent-task/{task_group}/` removed after the subtask move; non-empty parent left in place.
 - WARN/FAIL: new active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` created with matching headers and matching `구현 체크리스트`; no `complete.log`.
 - The applicable review-agent-only finalization checklist was completed before reporting.
--- a/agent-ops/skills/common/create-roadmap/SKILL.md
+++ b/agent-ops/skills/common/create-roadmap/SKILL.md
@ -1,6 +1,6 @@
 ---
 name: create-roadmap
-version: 1.11.0
+version: 1.12.0
 description: AI-first 개인/소규모 프로젝트의 전체 목표, Phase scaffold, Phase 하위 Milestone 문서, current.md 활성 Phase/Milestone 창, archive Phase scaffold를 처음 생성하는 공통 스킬
 ---

@ -68,16 +68,17 @@ agent-ops/
 ## 작성 규칙

 - 기본 작성 언어는 한국어다.
- 상태 표기는 `[계획]`, `[진행중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다.
+- 상태 표기는 `[계획]`, `[진행중]`, `[검토중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다.
 - Phase와 Milestone 이름, 파일명에는 `1`, `2`, `M01`, `P1` 같은 순번을 붙이지 않는다.
 - 진행 순서는 `ROADMAP.md`와 각 `PHASE.md`의 위에서 아래 순서로 표현한다.
 - Phase 파일명은 `agent-ops/roadmap/phase/<phase-slug>/PHASE.md`로 만든다.
 - Milestone 파일명은 `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md`로 만든다.
+- `<phase-slug>`와 `<milestone-slug>`는 소문자 영문, 숫자, 하이픈만 사용하고, 공백/언더스코어/순번 prefix를 넣지 않는다.
 - 중간에 Phase나 Milestone을 끼워 넣을 수 있도록 기존 항목의 이름과 파일명을 불필요하게 바꾸지 않는다.

 ## Milestone 작성 규칙

- Milestone 표준 섹션은 `위치`, `목표`, `상태`, `구현 잠금`, `범위`, `필수 기능`, `완료 기준`, `범위 제외`, `작업 컨텍스트`다.
+- Milestone 표준 섹션은 `위치`, `목표`, `상태`, `구현 잠금`, `범위`, `필수 기능`, `완료 기준`, `완료 리뷰`, `범위 제외`, `작업 컨텍스트`다.
 - 새 Milestone은 사용자만 결정할 수 있는 제품 방향, 범위, 우선순위, 책임 경계가 남아 있으면 `구현 잠금`을 `잠금`으로 둔다.
 - Milestone 전체에서 사용자만 결정할 항목이 더 이상 없고 에이전트가 표준선에 따라 실행하면 되는 상태라면 `해제`로 둔다.
 - `구현 잠금`에는 상태와 `결정 필요` 체크리스트만 적는다. 결정할 항목이 없으면 `결정 필요: 없음`으로 적는다.
@ -86,6 +87,7 @@ agent-ops/
 - Task는 `- [ ] [item-id] 설명` 형식으로 작성한다.
 - epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 해당 Milestone 안에서만 유일하면 된다.
 - `완료 기준`은 검증 가능한 조건의 체크리스트로 작성한다.
+- `완료 리뷰`는 새 Milestone에서는 `상태: 없음`, `요청일: 없음`으로 두고, 모든 필수 Task와 완료 기준이 충족된 뒤 사용자 최종 확인을 요청할 때 갱신한다.
 - `범위`, `범위 제외`, `작업 컨텍스트`는 설명 목록으로 작성하고, 실행해야 할 작업을 이 섹션에 숨기지 않는다.

 ## 먼저 확인할 것
@ -117,7 +119,7 @@ agent-ops/
 4. **파일 생성**
   - `ROADMAP.md`, `current.md`, 각 Phase의 `PHASE.md`, 각 Milestone 문서를 템플릿 순서대로 생성한다.
   - 활성 Phase와 활성 Milestone은 `current.md`에 모두 기록한다.
-   - `ROADMAP.md`의 Phase 흐름에는 완료/진행중/계획 Phase 모두를 위에서 아래 순서로 두고, 계획 Phase는 진행중 Phase보다 아래에 둔다.
+   - `ROADMAP.md`의 Phase 흐름에는 완료/검토중/진행중/계획 Phase 모두를 위에서 아래 순서로 두고, 계획 Phase는 진행중 Phase보다 아래에 둔다.
   - 완료된 Phase가 초기 구조에 포함되어야 하는 경우 `archive/phase/<phase-slug>/PHASE.md`로 만들고 `ROADMAP.md`에서 archive 경로를 가리킨다.
   - 완료된 Milestone이 진행중 Phase에 포함되어야 하는 경우 `archive/phase/<phase-slug>/milestones/<milestone-slug>.md`로 만들고 해당 활성 `PHASE.md`에서 archive 경로를 가리킨다.
   - archive `PHASE.md`는 Phase 자체가 완료/폐기된 경우에만 만든다. 진행중 Phase의 완료 Milestone만 archive된 경우 archive Phase 디렉터리에 `milestones/`만 둘 수 있다.
@ -127,6 +129,7 @@ agent-ops/
   - `current.md` 활성 항목에 `agent-ops/roadmap/archive/**` 경로가 없는지 확인한다.
   - Epic heading과 Task 체크리스트 id가 형식을 따르는지 확인한다.
   - 상태 표기가 `[진행중]`처럼 공백 없는 표준값인지 확인한다.
+   - Milestone 문서에 `완료 리뷰` 섹션이 있는지 확인한다.

 ## 출력 형식

--- a/agent-ops/skills/common/plan/SKILL.md
+++ b/agent-ops/skills/common/plan/SKILL.md
@ -1,6 +1,6 @@
 ---
 name: plan
-description: Analyze the current repository and write a detailed PLAN-{build_lane}-GNN.md for implementation work. Also writes the CODE_REVIEW-{review_lane}-GNN.md stub that the implementing agent will fill in after coding. Use for any feature, refactor, bug fix, or follow-up fix that should enter the plan-code-review loop. A separate implementing agent, or the same agent in an implementation pass, reads the plan file and does the coding. The code-review skill archives both files after review and moves PASS tasks under agent-task/archive/YYYY/MM/.
+description: Analyze the current repository and write a detailed PLAN-{build_lane}-GNN.md for implementation work. Also writes the CODE_REVIEW-{review_lane}-GNN.md stub that the implementing agent will fill in after coding. Use for any feature, refactor, bug fix, or follow-up fix that should enter the plan-code-review loop. Milestone-linked work uses a reserved m-prefixed task group so runtime can route PASS completion events to update-roadmap. A separate implementing agent, or the same agent in an implementation pass, reads the plan file and does the coding.
 ---

 # Plan
@ -13,6 +13,7 @@ Create the planning artifacts for the implementation loop:
 plan skill -> PLAN-{build_lane}-GNN.md + CODE_REVIEW-{review_lane}-GNN.md stub
 implementation -> code changes + filled CODE_REVIEW-{review_lane}-GNN.md
 code-review skill -> verdict + archive, complete.log, and PASS task-directory archive move or new follow-up plan/review files
+runtime -> for m-prefixed PASS completion events, state check and optional update-roadmap call
 ```

 ## Workflow Contract
@ -21,7 +22,8 @@ This skill intentionally uses routed active files under an active task directory

 Task path terms:

- `{task_group}` is the top-level work category under `agent-task/`, using a short snake_case name such as `refactoring`.
+- `{task_group}` is the top-level work category under `agent-task/`. Normal task groups use a short snake_case name such as `refactoring`.
+- Milestone-linked work uses the reserved task group form `m-<milestone-slug>`, where `<milestone-slug>` is the active Milestone filename without `.md`.
 - `{subtask_dir}` is used only for split work and follows the existing indexed directory naming rules below, such as `01_core` or `02+01_db`.
 - `{subtask_name}` is the short snake_case name after the index or dependency prefix inside `{subtask_dir}`.
 - `{task_name}` in headers and templates means the active task path relative to `agent-task/`: either `{task_group}` for a single-plan task or `{task_group}/{subtask_dir}` for a split subtask.
@ -58,7 +60,10 @@ Split gates:

 Task directory naming rules:

- A single-plan task uses `agent-task/{task_group}/` with a short snake_case category name, e.g. `agent-task/refactoring/`.
+- A normal single-plan task uses `agent-task/{task_group}/` with a short snake_case category name, e.g. `agent-task/refactoring/`.
+- If the plan is based on a selected active Milestone, use `agent-task/m-<milestone-slug>/` as the task group. Do not include the Phase slug, Epic id, Task id, or a separate task slug in the task group.
+- `m-<milestone-slug>` is a reserved top-level task group namespace for Milestone-linked work. Non-roadmap tasks must not use `m-`.
+- Runtime completion-event routing for `m-*` reads only the top-level `{task_group}` name. It resolves `<milestone-slug>` by matching exactly one active file at `agent-ops/roadmap/phase/*/milestones/<milestone-slug>.md`; archive paths are not target candidates.
 - When split gates require decomposition, create one shared category folder and multiple subtask directories under it. Each subtask directory owns exactly one normal active plan file and one normal active review stub.
 - Multi-plan output is a set of independent `PLAN-{build_lane}-GNN.md` + `CODE_REVIEW-{review_lane}-GNN.md` pairs across `agent-task/{task_group}/{subtask_dir}/` folders, not multiple plan files inside one folder.
 - Multi-plan subtask directory names must start with a stable two-digit task index. The index must increase across sibling subtask directories for sorting, but it is not a serial execution dependency.
@ -119,14 +124,16 @@ The routed plan file is the loop entry point. A missing active plan normally mea
 - `agent-ops/roadmap/current.md`가 있으면 구현 계획 파일을 만들기 전에 읽고, 사용자 요청, 브랜치, 변경 경로를 기준으로 관련 Phase와 Milestone을 선택한다.
 - `current.md`가 `agent-ops/roadmap/archive/**`를 가리키면 해당 문서는 읽지 말고 활성 Phase/Milestone이 아니라고 보고한다.
 - 선택한 Phase를 한 번 읽어 Phase 목표, Milestone 흐름, Phase 경계를 확인한다.
- 선택한 Milestone을 한 번 읽어 목표, 범위, 필수 기능, 완료 기준, 범위 제외, 구현 잠금을 확인한다. `구현 잠금` 섹션이 없거나 상태가 `잠금`이면 현재 요청에 직접 영향을 주는 `결정 필요` 항목만 확인하고, 그 결정 없이는 `PLAN-*-G??.md`, `CODE_REVIEW-*-G??.md`, file/API/package 수준 구현 단계를 확정하지 않는다.
+- 선택한 Milestone을 한 번 읽어 목표, 범위, 필수 기능, 완료 기준, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다. `구현 잠금` 섹션이 없거나 상태가 `잠금`이면 현재 요청에 직접 영향을 주는 `결정 필요` 항목만 확인하고, 그 결정 없이는 `PLAN-*-G??.md`, `CODE_REVIEW-*-G??.md`, file/API/package 수준 구현 단계를 확정하지 않는다.
 - Phase 또는 Milestone 후보가 여럿이면 요청 문장, 변경 경로 직접성, Milestone 상태, 구현 잠금, 선후 의존성, Phase/Milestone 흐름상 위치를 기준으로 1순위와 2순위를 추천하고 필요한 후보 문서만 읽어 범위를 좁힌다.
 - 로드맵 current가 있고 활성 Phase/Milestone 밖 작업이면 `ROADMAP.md`의 Phase 흐름을 확인하고 전환, 신규 Phase/Milestone, 또는 기존 활성 범위 내 배치 필요성을 보고한다.
 - 현재 요청과 직접 관련 없는 미정 항목은 잠금 상태로 남겨도 되며, 기존 구조, 도메인 rule, 플랫폼 관례로 정할 수 있는 세부는 표준선/가정으로 계획에 기록하고 진행할 수 있다.
 - 사용자가 선택한 Milestone의 작업, 구현, 계획 작성을 명시했고 현재 계획에 필요한 결정이 모두 정해져 있다면 계획 작성을 이어간다. Milestone 전체에서 사용자만 결정할 항목이 더 이상 없을 때만 roadmap update 흐름으로 `구현 잠금` 상태를 `해제`로 갱신한다. 현재 요청에 직접 걸리는 결정이 필요하면 그 항목만 체크리스트로 남기고 사용자에게 확인한다.
+- 선택한 활성 Milestone 범위에 속하는 구현 계획이면 `{task_group}`을 `m-<milestone-slug>`로 정한다. `<milestone-slug>`는 선택한 Milestone 경로의 파일명에서 `.md`를 제거한 값이다.
+- 같은 Milestone에서 split work가 필요하면 기존 split 규칙 그대로 `agent-task/m-<milestone-slug>/<subtask_dir>/` 아래에 계획 파일을 만든다.
 - roadmap/current 파일이 없으면 기존 task routing 규칙대로 진행한다.

-Use short snake_case task group names, e.g. `api_refactor`.
+Use short snake_case task group names for non-roadmap work, e.g. `api_refactor`.

 Before choosing plan files or task directory names, apply the split decision policy above. When the policy allows a single plan, write active files directly under `agent-task/{task_group}/` and record the exception rationale. When the policy requires multiple plans, choose one shared `{task_group}` and `{subtask_dir}` names using the task directory naming rules above. Do not put multiple active plan files in one active task directory, and do not mix split subtask directories with active plan/review files directly in the parent task group.

@ -270,7 +277,8 @@ task={task_name}, plan={N}, tag={TAG}
 1. 판정을 append한다.
 2. `CODE_REVIEW-{review_lane}-GNN.md` → `code_review_{review_lane}_GNN_N.log`, `PLAN-{build_lane}-GNN.md` → `plan_{build_lane}_GNN_M.log`로 아카이브한다.
 3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 다음 active plan/review 파일을 즉시 작성한다.
-4. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
+4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
+5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.

 ---

@ -296,6 +304,7 @@ task={task_name}, plan={N}, tag={TAG}
 - [ ] active `PLAN-*-G??.md`를 `plan_{build_lane}_GNN_M.log`로 아카이브한다.
 - [ ] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
 - [ ] PASS이면 active task 디렉터리 `agent-task/{task_name}/`를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
+- [ ] PASS이고 task group이 `m-<milestone-slug>`이면 런타임이 읽을 완료 이벤트 메타데이터를 보고하고, roadmap 수정이나 `update-roadmap` 직접 호출을 하지 않는다.
 - [ ] PASS split 작업이면 이동 후 빈 active parent `agent-task/{task_group}/`를 제거하거나, 남은 sibling/file이 있어 유지했다고 확인한다.
 - [ ] WARN/FAIL이면 다음 active `PLAN-{build_lane}-GNN.md`와 `CODE_REVIEW-{review_lane}-GNN.md`를 작성하고 `complete.log`를 작성하지 않는다.

@ -366,6 +375,7 @@ Sections and their ownership:
 - `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` both exist under the active task directory `agent-task/{task_name}/`.
 - Single-plan work stores active files directly under `agent-task/{task_group}/`.
 - Split work, if any, uses one shared `agent-task/{task_group}/` parent and one subtask directory per plan/review pair with names like `01_core`, `02+01_edge_integration`, `03+01_node_integration`; dependency details live in the subtask directory name as `NN+PP[,QQ...]_subtask_name`.
+- Milestone-linked work uses `agent-task/m-<milestone-slug>/` as the task group; non-roadmap task groups do not start with `m-`.
 - Both first lines match `<!-- task={task_name} plan={N} tag={TAG} -->`.
 - Previous active files, if any, were archived with correct numeric suffixes.
 - Every plan item has problem, solution, checklist, test decision, and intermediate verification.
--- a/agent-ops/skills/common/update-roadmap/SKILL.md
+++ b/agent-ops/skills/common/update-roadmap/SKILL.md
@ -1,7 +1,7 @@
 ---
 name: update-roadmap
-version: 1.16.0
-description: 로드맵 업데이트, 로드맵에 추가, 마일스톤 추가/갱신, phase/페이즈 변경 요청에 사용한다. Roadmap-Phase-Milestone scaffold에서 target 없는 신규 작업의 규모를 판정하고 기존 Phase/Milestone/Epic/Task를 검색해 upsert한 뒤, 없을 때만 새 항목을 만들고 current.md 동기화와 archive 이동을 처리한다.
+version: 1.17.0
+description: 로드맵 업데이트, 로드맵에 추가, 마일스톤 추가/갱신, phase/페이즈 변경 요청에 사용한다. Roadmap-Phase-Milestone scaffold에서 target 없는 신규 작업의 규모를 판정하고 기존 Phase/Milestone/Epic/Task를 검색해 upsert한 뒤, 없을 때만 새 항목을 만들고 current.md 동기화, runtime m-task 완료 이벤트 반영, 완료 후보 검토중 전환, 승인된 archive 이동을 처리한다.
 ---

 # 로드맵 업데이트
@ -23,6 +23,7 @@ Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `필수
 - Milestone 완료, 보류, 폐기, 신규 추가가 필요할 때
 - Phase 완료, 보류, 폐기, 신규 추가가 필요할 때
 - 완료 또는 폐기된 Phase/Milestone을 archive로 이동해야 할 때
+- 런타임이 `m-<milestone-slug>` task group의 PASS 완료 이벤트를 Milestone에 반영해야 할 때
 - 특정 기능이나 작업을 새 Milestone, 기존 Milestone의 Epic, 기존 Epic의 Task 중 적절한 위치에 추가해야 할 때
 - 활성 Phase/Milestone 창에 포함할 목록이 달라졌을 때
 - 기존 로드맵을 `phase/<phase-slug>/PHASE.md` scaffold로 마이그레이션하거나 표준화해야 할 때
@ -40,6 +41,9 @@ Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `필수
 - `lock-state`: Milestone 구현 잠금 상태. `잠금` / `해제` 중 하나 (선택)
 - `decision-needed`: `구현 잠금`에 남길 사용자만 결정할 수 있는 질문 목록 (선택)
 - `evidence`: 완료 판단에 사용할 파일, PR, 테스트, 커밋, 사용자 설명 (선택)
+- `review-state`: 완료 리뷰 상태. `요청됨` / `승인됨` / `보완 필요` / `보류` / `폐기` 중 하나 (선택)
+- `review-comment`: 완료 리뷰에 남길 사용자 확인, 보완, 보류, 폐기 방향성 (선택)
+- `origin-task`: 런타임 완료 이벤트가 전달한 `agent-task/m-<milestone-slug>` 또는 `agent-task/m-<milestone-slug>/<subtask_dir>` 형식의 원래 active task 경로. 이벤트가 최종 archive 경로만 갖고 있으면 런타임이 이 형식으로 정규화해 전달한다 (선택)
 - `archive-date`: Phase/Milestone 아카이브 날짜. 없으면 현재 날짜를 사용한다 (선택)

 ## 표준 구조
@ -67,14 +71,19 @@ agent-ops/roadmap/
 - 완료된 Phase는 `archive/phase/<phase-slug>/PHASE.md`로 이동하고, 하위 Milestone도 같은 archive Phase scaffold 아래에 둔다.
 - 진행중 Phase 안에서 완료된 Milestone은 `archive/phase/<phase-slug>/milestones/<milestone-slug>.md`로 이동하고, 활성 `PHASE.md`에는 짧은 archive 링크를 남긴다.
 - archive `PHASE.md`는 Phase 자체가 완료/폐기될 때만 만든다. 진행중 Phase의 완료 Milestone만 archive된 경우에는 archive Phase 디렉터리에 `milestones/`만 있을 수 있다.
+- `<phase-slug>`와 `<milestone-slug>`는 소문자 영문, 숫자, 하이픈만 사용한다.
 - `current.md`는 활성 Phase와 활성 Milestone을 모두 가리킨다.
 - `current.md`에는 archive 경로를 넣지 않는다.
+- `current.md`에는 `[완료]` 또는 `[폐기]` Phase/Milestone을 남기지 않는다. 완료 후보는 사용자 승인 전까지 `[검토중]`으로 둔다.

 ## 상태와 id

- 상태 표기는 `[계획]`, `[진행중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다.
+- 상태 표기는 `[계획]`, `[진행중]`, `[검토중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다.
 - 기존 비표준 상태 표기는 갱신 범위에 포함될 때 표준 상태 표기로 정리한다.
- `ROADMAP.md`의 Phase 흐름과 `PHASE.md`의 Milestone 흐름은 완료, 진행중, 계획 순서를 기본으로 하며 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
+- `[검토중]`은 모든 필수 작업과 완료 기준이 충족된 것으로 보이나, 사용자 최종 확인과 archive 승인이 남은 완료 후보 상태다.
+- 검토 결과 보완이 필요하면 별도 reopen 상태를 만들지 않고 `[진행중]`으로 되돌린 뒤 `완료 리뷰` 또는 `작업 컨텍스트`에 보완 방향을 남긴다.
+- 검토 결과 보류 또는 폐기 결정이 나면 `[보류]` 또는 `[폐기]`로 전환한다.
+- `ROADMAP.md`의 Phase 흐름과 `PHASE.md`의 Milestone 흐름은 완료, 검토중, 진행중, 계획 순서를 기본으로 하며 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
 - Epic heading은 `### Epic: [epic-id] <이름>` 형식으로 작성한다.
 - Task는 `- [ ] [item-id] 설명` 또는 `- [x] [item-id] 설명` 형식으로 작성한다.
 - epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 해당 Milestone 안에서만 유일하면 된다.
@ -103,6 +112,25 @@ agent-ops/roadmap/
 - Milestone 전체에서 사용자만 결정할 항목이 더 이상 없고 에이전트가 표준선에 따라 실행하면 되는 상태라면 `해제`로 둔다.
 - 잠금 상태 변경은 Milestone 완료 판정이 아니므로 `필수 기능`과 `완료 기준`을 자동 완료 처리하지 않는다.

+## 완료 리뷰와 검토중 상태
+
+- Task 완료 또는 Milestone 갱신 후 필수 Epic/Task와 `완료 기준`이 모두 evidence와 함께 `[x]`인지 확인한다.
+- 모두 충족된 것으로 보이면 Milestone을 `[완료]`로 바로 바꾸거나 archive로 이동하지 말고 `[검토중]`으로 바꾼다.
+- `[검토중]`으로 바꿀 때는 Milestone 문서의 `완료 리뷰` 섹션을 만들거나 갱신한다.
+- `완료 리뷰`에는 `상태: 요청됨`, `요청일`, 완료 근거 1~3줄, 사용자 최종 확인 항목, 리뷰 코멘트를 남긴다.
+- 사용자가 승인하면 `완료 리뷰`를 `상태: 승인됨`으로 바꾸고 Milestone 상태를 `[완료]`로 전환한 뒤 archive 모드를 수행한다.
+- 사용자가 보완을 요구하면 `완료 리뷰`를 `상태: 보완 필요`로 바꾸고 Milestone 상태를 `[진행중]`으로 되돌린다. 이때 보완 방향을 `완료 리뷰` 또는 `작업 컨텍스트`에 남기며 별도 reopen 상태는 만들지 않는다.
+- 사용자가 보류 또는 폐기를 지시하면 `완료 리뷰`와 Milestone 상태를 각각 `보류`/`[보류]`, `폐기`/`[폐기]`로 맞춘다. `[폐기]`는 archive 대상이 될 수 있다.
+- Phase는 하위 Milestone이 모두 `[완료]` 또는 `[폐기]`로 정리되고 Phase 목표도 충족된 것으로 보일 때 `[검토중]`으로 두고, 사용자 승인 후 `[완료]` 또는 `[폐기]`로 archive한다.
+
+## Milestone task group 연동
+
+- 런타임 완료 이벤트의 `origin-task`에서 `agent-task/` 다음 첫 path segment가 `m-<milestone-slug>`이면 Milestone 기반 plan/review 완료에서 온 요청으로 본다. `origin-task`는 archive 이동 전 active task 경로 또는 런타임이 그 형태로 정규화한 경로를 사용한다.
+- `<milestone-slug>`는 활성 `agent-ops/roadmap/phase/*/milestones/<milestone-slug>.md`에서 정확히 하나만 찾아야 한다. archive Milestone은 target 후보가 아니다.
+- target이 없거나 둘 이상이면 Milestone 내용을 추정해 수정하지 말고 target 불명확으로 보고한다.
+- target이 확정되면 PASS evidence, `complete.log`, final archive path, archived plan/review log 경로, code-review 결과 요약을 근거로 해당 Milestone의 Epic/Task와 완료 기준을 갱신한다. target routing 자체는 완료 이벤트의 `m-<milestone-slug>` task group으로만 결정한다.
+- 갱신 후 필수 Epic/Task와 완료 기준이 모두 충족되면 `[검토중]` 전환과 `완료 리뷰` 요청 규칙을 적용한다.
+
 ## 삽입 단위 정책

 | 삽입 단위 | 사용 기준 |
@ -121,10 +149,10 @@ agent-ops/roadmap/
 - `<item-id> 앞/뒤`는 같은 Epic 안의 형제 Task로 넣는다.
 - `<item-id> 아래`는 해당 Task의 하위 작업으로 넣는다.
 - `<phase-name> 안`은 새 Milestone 또는 기존 Milestone/Epic/Task 중 작업 성격에 맞는 단위로 배치한다.
- 위치 지정이 없으면 `auto`로 본다. `current.md`의 활성 창만으로 결정하지 않고, 필요한 경우 `ROADMAP.md`의 Phase 흐름까지 확인해 완료/진행중/계획 Phase를 비교한다.
+- 위치 지정이 없으면 `auto`로 본다. `current.md`의 활성 창만으로 결정하지 않고, 필요한 경우 `ROADMAP.md`의 Phase 흐름까지 확인해 완료/검토중/진행중/계획 Phase를 비교한다.
 - target 없는 신규 추가 요청은 요청 문장, 관련 파일/도메인 힌트, Phase 목표, Milestone 목표, 기존 Epic/Task, 선후 의존성, 상태, 활성 창을 비교해 가장 자연스러운 위치를 자동 판단한다.
 - 자동 배치 후보가 여러 개이면 1순위와 2순위 후보를 비교하고, 선택한 Phase/Milestone/Epic/Task와 밀린 후보의 이유를 짧게 남긴다.
- 관련성이 비슷하면 `[진행중]` Milestone을 `[계획]` Milestone보다 우선하되, 요청 내용이 계획 Phase/Milestone 목표에 더 직접 연결되면 계획 항목에 배치할 수 있다.
+- 관련성이 비슷하면 `[진행중]` Milestone을 `[계획]` Milestone보다 우선하되, `[검토중]` Milestone은 리뷰 보완 요청이 아닌 신규 작업의 기본 배치 대상으로 삼지 않는다.
 - 자동 배치한 경우 결과 보고에 선택한 삽입 단위, 위치, 판단 근거, 비교한 후보를 짧게 남긴다.
 - 사용자 지정 위치가 Phase 목표, Milestone 범위 제외, 선후 의존성과 충돌하면 수정 전에 사용자에게 확인한다.

@ -163,7 +191,8 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다

 ### Milestone archive

- 대상 Milestone이 `[완료]` 또는 `[폐기]`인지, 또는 그렇게 바꿀 근거가 있는지 확인한다.
+- 대상 Milestone이 `[완료]` 또는 `[폐기]`인지 확인한다.
+- `[검토중]` Milestone은 archive하지 않는다. 사용자 완료 승인 또는 폐기 지시가 있으면 먼저 `[완료]` 또는 `[폐기]`로 바꾼 뒤 archive한다.
 - 대상 파일을 `agent-ops/roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md`에서 `agent-ops/roadmap/archive/phase/<phase-slug>/milestones/<milestone-slug>.md`로 이동한다.
 - 활성 `PHASE.md`의 Milestone 흐름에는 `[완료]` 또는 `[폐기]` 항목을 남기고, 경로는 archive 경로로 바꾼다.
 - `current.md`의 활성 Milestone에서는 제거한다.
@ -172,7 +201,8 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다

 ### Phase archive

- Phase 전체가 `[완료]` 또는 `[폐기]`인지, 또는 그렇게 바꿀 근거가 있는지 확인한다.
+- Phase 전체가 `[완료]` 또는 `[폐기]`인지 확인한다.
+- `[검토중]` Phase는 archive하지 않는다. 사용자 완료 승인 또는 폐기 지시가 있으면 먼저 `[완료]` 또는 `[폐기]`로 바꾼 뒤 archive한다.
 - `agent-ops/roadmap/phase/<phase-slug>/PHASE.md`를 `agent-ops/roadmap/archive/phase/<phase-slug>/PHASE.md`로 이동한다.
 - 해당 Phase의 하위 Milestone도 `archive/phase/<phase-slug>/milestones/` 아래로 이동한다.
 - `ROADMAP.md`의 Phase 흐름에는 해당 Phase 항목을 남기고, 상태와 경로를 archive `PHASE.md`로 바꾼다.
@ -183,8 +213,9 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다

 1. **갱신 범위 결정**
   - 요청에서 mode, 대상 Phase/Milestone, placement, placement-unit을 추론한다.
+   - 런타임 완료 이벤트의 `origin-task` task group이 `m-<milestone-slug>`이면 `target-milestone`을 활성 Milestone 경로 매칭으로 확정한다.
   - 구조 전환, 템플릿 보정, current 동기화는 `sync`로 본다.
-   - 완료/폐기 이동은 `archive`로 본다.
+   - 사용자 승인 이후의 완료/폐기 이동은 `archive`로 본다.
   - 새 기능 배치, Epic/Task 추가는 `milestone` 또는 `phase`로 본다.
   - "로드맵에 추가"처럼 target이 없는 신규 작업 요청은 `placement=auto`, `placement-unit=auto`, `new-feature=<요청 내용>`으로 본다.

@ -197,7 +228,7 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
   - `current.md`의 활성 Phase와 활성 Milestone 후보를 확인한다.
   - target이 명시된 경우 대상 Phase의 `PHASE.md`를 읽고 Milestone 흐름과 Phase 경계를 확인한다.
   - target이 없거나 활성 창 밖 배치 가능성이 있으면 `ROADMAP.md`의 Phase 흐름을 확인하고, 관련성이 높은 Phase 문서를 읽는다.
-   - 대상 또는 후보 Milestone 문서의 목표, 범위, 필수 기능, 완료 기준, 범위 제외, 구현 잠금을 확인한다.
+   - 대상 또는 후보 Milestone 문서의 목표, 범위, 필수 기능, 완료 기준, 완료 리뷰, 범위 제외, 구현 잠금을 확인한다.
   - Phase -> Milestone -> Epic -> Task 순서로 내려가며 같은 레벨의 동일/유사 후보를 먼저 찾는다.
   - `current.md`에 archive 경로가 있으면 읽지 말고 제거 대상으로 기록한다.
   - 필요한 경우에만 `ROADMAP.md`를 읽어 전체 Phase 흐름을 확인한다.
@ -206,20 +237,26 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
   - `ROADMAP.md`는 전체 목표, Phase 흐름, 로딩 정책이 바뀔 때만 수정한다.
   - `current.md`는 활성 Phase/Milestone 창이 바뀔 때 수정한다.
   - `PHASE.md`는 Phase 목표, 상태, Milestone 흐름, Phase 경계가 바뀔 때 수정한다.
-   - Milestone 문서는 목표, 상태, 구현 잠금, 범위, Epic/Task, 완료 기준, 범위 제외, 작업 컨텍스트가 바뀔 때 수정한다.
+   - Milestone 문서는 목표, 상태, 구현 잠금, 범위, Epic/Task, 완료 기준, 완료 리뷰, 범위 제외, 작업 컨텍스트가 바뀔 때 수정한다.
   - 동일/유사 후보가 있으면 기존 항목을 업데이트하고 중복 항목을 만들지 않는다.
   - 새 Milestone은 해당 Phase의 `milestones/` 아래에 만든다.
   - 새 Epic은 `필수 기능` 아래 `### Epic: [epic-id] <이름>`으로 만든다.
   - 새 Task는 관련 Epic 아래 `- [ ] [item-id] 설명`으로 만든다.
   - 새 항목은 레벨별 탐색에서 적절한 기존 후보가 없을 때만 만든다.
   - 완료 체크는 evidence가 있을 때만 `[x]`로 바꾼다.
+   - 필수 Epic/Task와 완료 기준이 모두 evidence와 함께 `[x]`이면 Milestone 상태를 `[검토중]`으로 바꾸고 `완료 리뷰`에 리뷰 요청과 근거를 남긴다.
+   - `[검토중]` 전환만으로 archive 이동, `current.md` 제거, archive 링크 변경을 수행하지 않는다.
+   - 사용자 승인 근거가 있으면 `[검토중]`을 `[완료]`로 전환하고 archive 모드를 수행할 수 있다.

 5. **검증**
   - `current.md`의 활성 Phase/Milestone 경로가 실제 파일을 가리키는지 확인한다.
   - `current.md`의 활성 항목이 archive 경로를 가리키지 않는지 확인한다.
+   - `current.md`의 활성 항목이 `[완료]` 또는 `[폐기]` 상태로 남아 있지 않은지 확인한다.
   - `ROADMAP.md`의 Phase 경로가 실제 `PHASE.md` 파일을 가리키는지 확인한다.
   - 각 `PHASE.md`의 Milestone 경로가 실제 파일을 가리키는지 확인한다.
   - 상태 표기가 표준값인지 확인한다.
+   - `[검토중]` Milestone이 archive 경로로 이동되지 않았는지 확인한다.
+   - 필수 Epic/Task와 완료 기준이 모두 `[x]`인 Milestone에는 `완료 리뷰` 섹션과 사용자 리뷰 요청이 있는지 확인한다.
   - Epic heading과 Task id 형식이 맞는지 확인한다.
   - 요청 규모가 판정되었고 결과 보고에 남았는지 확인한다.
   - 동일/유사 기존 항목을 검색했고 신규/업데이트 판정이 결과 보고에 남았는지 확인한다.
@ -235,6 +272,8 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
   - 신규 작업의 삽입 단위와 배치 위치
   - 자동 배치한 경우 비교한 후보와 선택 근거
   - current.md 활성 창 변경 사항
+   - 완료 리뷰 상태와 사용자 확인 필요 항목
+   - 런타임 완료 이벤트의 `origin-task`가 `m-<milestone-slug>`이면 원래 active task 경로와 매칭된 target Milestone 또는 target 불명확 사유
   - archive 모드이면 이동 경로와 남긴 링크
   - 확인 필요로 남긴 항목

@ -263,6 +302,8 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
 - 배치 후보: <자동 배치 시 1순위/2순위 후보와 선택/제외 근거 | 해당 없음>
 - 템플릿 보정: <ROADMAP | current.md | PHASE | Milestone | 이미 일치 | 변경 없음>
 - 구현 잠금: <잠금 유지 | 잠금 추가 | 해제 | 변경 없음>; 결정 필요: <없음 | 항목 요약>
+- 완료 리뷰: <변경 없음 | 요청됨 | 승인됨 | 보완 필요 | 보류 | 폐기>
+- runtime m-task 라우팅: <해당 없음 | origin-task -> target Milestone | target 불명확>
 - 활성 항목: <변경 없음 | Phase/Milestone 추가/제거 요약>
 - 아카이브: <변경 없음 | 이동 경로와 남긴 링크>
 - 상태: <변경 없음 | 이전 -> 이후>
@ -276,7 +317,7 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
 ## 금지 사항

 - 로드맵 파일이 없는데 새 구조를 임의로 만들지 않는다. 이 경우 `create-roadmap`을 사용한다.
- evidence 없이 Phase, Milestone, Epic, Task를 완료 처리하지 않는다.
+- evidence 없이 Phase, Milestone, Epic, Task를 `[완료]` 또는 `[검토중]`으로 처리하지 않는다.
 - 전체 `ROADMAP.md`를 모든 작업의 필수 로딩 파일로 만들지 않는다.
 - `ROADMAP.md`에 Milestone 상세 작업 체크리스트를 남기지 않는다.
 - `current.md`에 개인별 현재 작업 위치나 완료 상태를 남기지 않는다.
 @ -1 +1 @@
 .1.50
 .1.51