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

agent-ops/.version

@@ -1 +1 @@
-1.1.171
+1.1.174

agent-ops/skills/common/_templates/implementation-user-review-request-section.md

@@ -1,12 +0,0 @@
-## 사용자 리뷰 요청
-
-_선택된 Milestone `구현 잠금 > 결정 필요`가 구현을 막을 때만 채운다. 이 섹션을 포함한 모든 구현 소유 섹션을 채운 뒤 `review-ready`를 보고하고 종료한다. code-review를 실행하거나 review model을 시작하지 않는다._
-
-- 상태: 없음
-- 사유 유형: 없음
-- 연결 대상: 없음
-- 결정 필요: 없음
-- 차단 근거: 없음
-- 실행한 검증/명령: 없음
-- 후속으로 해결할 수 없는 이유: 없음
-- 재개 조건: 없음

agent-ops/skills/common/_templates/roadmap-milestone-template.md

@@ -56,6 +56,7 @@ Task는 `- [ ] [item-id] 설명` 형식을 사용한다.
 item-id는 공백 없는 짧은 ASCII 영문/숫자 segment 1~4개로 작성하고 segment 구분자는 -_+= 만 사용한다.
 epic-id와 item-id는 해당 Milestone 안에서만 유일하면 되고, 다른 Milestone에서는 같은 id를 다시 사용할 수 있다.
 Task는 기능 또는 산출물 단위다. 검증이 필요한 기능만 같은 Task 안에 `검증: <명령/확인 방법/기대 결과>`를 덧붙인다.
+각 Epic에는 기능 Task를 최대 5개만 둔다. 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 Epic을 분리한다. 분리된 Epic이 독립 목표면 새 Milestone 후보로 둔다.
 Task 체크리스트는 Epic 바로 아래의 flat list로 유지하고, 구현 세부나 테스트만 따로 떼어낸 하위 체크박스는 만들지 않는다.
 별도 `완료 기준` 섹션은 만들지 않는다.
 -->

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, USER_REVIEW.md resolution, implementation-time 사용자 리뷰 요청, or 리뷰 루프. Review and archive one active pair, then leave exactly one next artifact: a follow-up PLAN/CODE_REVIEW pair, USER_REVIEW.md, or complete.log. Plan, implementation, and review use different models."
+description: Use for active task review requests such as 리뷰 진행해, 리뷰해줘, 코드 리뷰해줘, code review, CODE_REVIEW.md, USER_REVIEW.md resolution, 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 must invoke the plan skill, which reruns finalize-task-routing before writing the next pair, unless the review-agent-owned user-review gate requires USER_REVIEW.md.
 ---
 
 # Code Review
@@ -10,65 +10,41 @@ description: "Use for active task review requests such as 리뷰 진행해, 리
 Review the implementation phase of the plan-code-review loop:
 
 ```text
-plan model -> implementation model -> review model
-     ^                                      |
-     +-- different plan model on WARN/FAIL -+
+plan skill -> finalize-task-routing -> implementation -> code-review skill
+     ^                                                     |
+     +----- WARN/FAIL: invoke plan skill with raw findings -+
 ```
 
-Implementation may end its coding phase early by filling the active review stub's `사용자 리뷰 요청` section from `agent-ops/skills/common/_templates/implementation-user-review-request-section.md`. This path is valid only for a selected Milestone `구현 잠금 > 결정 필요` item. The implementation model must not ask the user directly, call a user-input tool, or execute code-review. It fills every implementation-owned section, reports `review-ready`, and stops for a later review model.
-
-The review agent must select exactly one next-state artifact before ending:
-
-- **Plan**: a different plan model writes one follow-up PLAN/CODE_REVIEW pair.
-- **User review**: the review agent writes `USER_REVIEW.md`.
-- **Complete**: the review agent writes `complete.log` and archives the task.
-
-Archived findings or `plan-ready` alone are not a valid review result.
-The three-output rule begins only after a `review-ready` pair or resolvable `USER_REVIEW.md` passes preflight. An unfilled stub remains in the implementation stage and is not a started review.
-Finalization recovery uses the durable artifact combination itself: verdict-appended active review, partial pair archive, `complete.log`, `USER_REVIEW.md`, resolved `user_review_*.log`, or archived WARN/FAIL logs. No model-written transient state file is part of the protocol.
-
-## Hard Actor Boundary
-
-- Plan, implementation, and review use different model identities; separate agents or reasoning settings on the same model do not satisfy this rule.
-- Runtime must preserve the exact selected task path and runtime-provided model identities through every handoff. A filled role identity is immutable for that pair; a retry uses the same model identity. Lane/G and agent names are not model identities.
-- Resolving `USER_REVIEW.md` continues the archived Review role and must use the same Review model identity recorded in that archived review. If that identity is unavailable, leave `USER_REVIEW.md` unchanged and stop.
-- The review model owns the verdict, archive, and USER_REVIEW/complete finalization. It must not edit product source/tests or author a follow-up plan.
-- On WARN/FAIL, dispatch a plan model different from both the implementation and review models. End only after the follow-up pair exists; do not implement it.
+Implementation agents never decide or request user review. They record implementation, verification, deviation, and blocker evidence in implementation-owned review fields. The official code-review agent alone evaluates the selected Milestone state and, when the review-agent-owned gate is justified, writes `USER_REVIEW.md` from `agent-ops/skills/common/code-review/templates/user-review-template.md`.
 
 ## Core Loop Rules
 
 - Trigger: Korean or English active-task review requests, including `리뷰 진행해` and `리뷰해줘`, must use this skill when an active `CODE_REVIEW-*-G??.md` or `USER_REVIEW.md` exists under `agent-task/*/` or `agent-task/*/*/`, excluding `agent-task/archive/**`.
-- Keep the selected `{task_name}` through review finalization.
-- `PASS`: archive the pair, write `complete.log`, and move the task to monthly archive.
-- `WARN`/`FAIL`: apply the user-review gate, then archive the pair. Write `USER_REVIEW.md` for a valid gate; otherwise dispatch a different plan model to write the follow-up pair.
-- A filled `사용자 리뷰 요청` is valid only for a selected Milestone lock decision. Otherwise record the blocker as a WARN/FAIL finding for the next plan model.
-- Do not replace `USER_REVIEW.md` with an inline user question. When the gate triggers, write the file-based stop state and include its path in the final report.
-- Every unresolved `Required` forces `FAIL`; every `Suggested` forces `WARN`. Both require a follow-up pair unless the user-review gate writes `USER_REVIEW.md`.
-- Recovery: finish missing review-owned finalization, then dispatch the different plan model when WARN/FAIL lacks a follow-up pair. Never plan or implement with the review model.
+- Finalize every selected active state: for `CODE_REVIEW-*-G??.md`, append one verdict, prepare the required next state, archive the active review and plan files, then materialize exactly one next state; for `USER_REVIEW.md` completion, update the stop state, write `complete.log`, and archive the task.
+- 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` normally invokes `agent-ops/skills/common/plan/SKILL.md`, which must run `finalize-task-routing` before writing the next active pair; if the user-review gate triggers, write `USER_REVIEW.md` instead. A completed `USER_REVIEW.md` uses the same terminal `complete.log` and archive path as `PASS`.
+- The user-review gate is review-agent-owned and triggers only when current repository evidence proves that a concrete selected Milestone `구현 잠금 > 결정 필요` item blocks the next safe implementation step. Generic status fields or blocker text written by implementation are never a user-review request.
+- Do not replace `USER_REVIEW.md` with an inline user question. When the user-review gate triggers, write the file-based stop state and report its path.
+- Do not ask for confirmation before WARN/FAIL follow-up files. If the user-review gate triggers, write `USER_REVIEW.md`; otherwise invoke the plan skill with the current raw findings and let it write the smallest concrete follow-up after fresh routing.
+- Recovery: if a prior turn appended a verdict without archive or next-state files, do not append another verdict; resume Step 5 preparation/archive from that verdict. If exactly one member of the pair was archived after both archive destinations had been preflighted, verify the archived member and remaining source/destination, finish that archive, then use the post-archive recovery below. If both logs exist with a verdict but the required next state is absent, reconstruct it from those exact logs: PASS resumes `complete.log`; WARN/FAIL reruns the plan skill in `write` mode with raw archived findings and `isolated-reassessment`; a valid user-review gate rerenders `USER_REVIEW.md`. If a prior turn resolved `USER_REVIEW.md` without `complete.log`, resume at the matching finalization step.
 
 ## User Review Gate
 
-`USER_REVIEW.md` is a loop stop state only for selected Milestone lock decisions. The default WARN/FAIL branch creates a follow-up pair through a different plan model. The gate requires positive evidence that the blocker is already represented as a concrete selected Milestone `구현 잠금 > 결정 필요` item.
+`USER_REVIEW.md` is a loop stop state only for selected Milestone lock decisions. Default to a normal WARN/FAIL follow-up; the gate requires positive evidence that the blocker is already represented, or must be represented, as a Milestone `구현 잠금 > 결정 필요` item.
 
-- Derive the pending review archive suffix as `0` when no `code_review_*.log` exists, otherwise `max(existing numeric suffix) + 1`; set `review-number` to that suffix plus one.
-- Repeated `WARN`/`FAIL`, missing verification evidence, and environment blockers do not trigger `USER_REVIEW.md`; record them as findings for the next plan model.
-- If the active review file has a filled `사용자 리뷰 요청` with `상태` other than `없음`, validate that `사유 유형` is `milestone-lock`, that `연결 대상` points to the selected Milestone, and that the requested decision matches a Milestone `구현 잠금 > 결정 필요` item.
-- A valid Milestone-lock request is `Required`/`FAIL` and writes `USER_REVIEW.md` instead of a follow-up pair.
-- If the request is not tied to the Milestone lock, do not write `USER_REVIEW.md`; record it as a WARN/FAIL finding.
+- Compute `review-number` as `count(agent-task/{task_name}/code_review_*.log) + 1` before archiving the active review.
+- Repeated `WARN`/`FAIL`, loop exhaustion, missing verification evidence, and test environment blockers do not trigger `USER_REVIEW.md` by themselves. Invoke the plan skill for a narrower follow-up or report the non-roadmap blocker as verification evidence that remains unresolved.
+- Resolve the selected Milestone from `Roadmap Targets` or another exact active Milestone path already fixed by the task. Read its current `구현 잠금 > 결정 필요` items and independently determine whether one exact unresolved decision blocks the next safe implementation step.
+- External environment/secret/service setup, unsupported device, generic scope conflict, agent execution limits, missing handoff evidence, incomplete verification records, arbitrary `상태` text, or anything not tied to that exact Milestone lock never triggers the gate. Archive the review and invoke the plan skill for a normal WARN/FAIL follow-up when implementation can continue, or report the non-user-review blocker.
 - `USER_REVIEW.md` is created from `agent-ops/skills/common/code-review/templates/user-review-template.md`, filled with the archived loop history, current archived plan/review paths, verdict, loop count, blocking evidence, connection target, and the exact Milestone decision item.
 
 ## User Review Resolution
 
-When an active `USER_REVIEW.md` exists, it remains terminal until the linked Milestone decision is resolved. After resolution, this skill either completes PASS finalization or dispatches a different plan model when more implementation is required.
+When an active `USER_REVIEW.md` exists and the linked Milestone decision closes the task as complete/PASS, finalization is still owned by this skill.
 
 - Read `USER_REVIEW.md`, archived `plan_*.log`, and archived `code_review_*.log` in that task directory.
-- Inspect `## 상태` before writing. `USER_REVIEW` means the linked decision still needs first-time resolution. `RESOLVED` means resolution was already durably recorded; never append another result or replace its timestamp.
-- When status is `USER_REVIEW`, verify the linked decision. If it remains unresolved, leave `USER_REVIEW.md` unchanged; otherwise record its resolution exactly once using the matching branch below.
-- If a first-time resolution requires implementation, replace the `## 상태` value with `RESOLVED` and append one `## 해소 결과` with the exact keys `결과: REPLAN`, `해소 일시`, `결정`, `Evidence`, `Archived plan`, `Archived review`, `Forbidden implementation model`, and `Forbidden review model`; then continue immediately with the `RESOLVED`/`REPLAN` branch below.
-- If active `USER_REVIEW.md` is already `RESOLVED`/`REPLAN`, validate that single result, archive the file unchanged as `user_review_N.log` using `N=0` or `max(existing numeric suffix) + 1`, then dispatch a different plan model with that log and its referenced archived pair. Verify the pair. The highest numeric-suffix matching `RESOLVED`/`REPLAN` log is durable `plan-ready` evidence and takes precedence over the original user-review gate during recovery.
-- If a first-time resolution closes the task, select one completion timestamp, replace the `## 상태` value with `RESOLVED`, and append one `## 해소 결과` with the exact keys `결과: COMPLETE`, `해소 일시`, `Final verdict`, `결정`, `Evidence`, `Archived plan`, and `Archived review`; then continue immediately with the `RESOLVED`/`COMPLETE` branch below.
-- If active `USER_REVIEW.md` is already `RESOLVED`/`COMPLETE`, validate that single result and reuse its `해소 일시` without changing the file. The final archive path is selected and persisted later in `complete.log`.
-- On that complete/PASS branch, write `complete.log` from `agent-ops/skills/common/code-review/templates/complete-log-template.md` before moving or archiving the task directory. Include both the original archived review verdict and the user-review resolution line in `루프 이력`.
+- Verify the linked decision and any follow-up evidence are sufficient to close the task. If a new implementation plan is needed instead, do not close; route back to the plan skill, which archives `USER_REVIEW.md` to `user_review_N.log` before writing a new plan.
+- Update `USER_REVIEW.md` in place to show a resolved state, final verdict, loop history, fulfilled decision items, and the evidence that closed the stop state.
+- Write `complete.log` from `agent-ops/skills/common/code-review/templates/complete-log-template.md` before moving or archiving the task artifacts. Include both the original archived review verdict and the user-review resolution line in `루프 이력`.
 - Then apply the same task-directory archive move and `m-<milestone-slug>` PASS completion metadata rules as a normal `PASS`.
 - Do not leave an active task directory that contains `USER_REVIEW.md` and `*.log` files but no `complete.log` after the linked Milestone decision resolves the task as complete/PASS.
 
@@ -112,28 +88,26 @@ Milestone task group contract:
 - 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.
 
-Follow-up handoff:
+Follow-up routing boundary:
 
-- Record concrete findings, affected paths, verification evidence, and release conditions in the archived review log.
-- The review model must not choose the next lane/G or write the follow-up pair.
-- Dispatch a different plan model with the exact archived log paths. That model performs isolated routing, writes the pair, reports `implementation-ready` or `dependency-waiting`, and stops.
-- The review agent is responsible for ensuring that the follow-up pair exists, even though the different plan model authors it.
+- This skill records current source, actual verification output, and findings, but it must not estimate or recommend the next lane/G.
+- On WARN/FAIL, invoke the plan skill in `prepare-follow-up` mode with the selected task path and raw current evidence before archiving the current pair.
+- Do not pass the archived lane, grade, routing score, rationale, or filename as plan-routing input. Archive paths remain evidence pointers, and actual logs/findings remain raw evidence.
+- The plan skill must complete its full analysis and mandatory `finalize-task-routing` step before it writes the next pair. Code-review must not create a routed follow-up pair directly.
+- Repair non-behavioral review artifact drift during review instead of failing solely for it when implementation correctness, tests, and contracts remain judgeable.
 
 Directory states:
 
 | State | Meaning |
 |-------|---------|
-| `PLAN-*-G??.md` + unfilled `CODE_REVIEW-*-G??.md` stub/placeholders | `implementation-ready`, `dependency-waiting`, or incomplete implementation; do not start review or append a verdict |
-| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with filled `사용자 리뷰 요청` | Implementation claims a selected Milestone lock decision blocker; review validates the request and writes `USER_REVIEW.md` only if justified |
-| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md` without verdict, dependencies satisfied | `review-ready`; the review model may consume it |
-| Active pair with encoded predecessors still unsatisfied | `dependency-waiting`; leave the pair unchanged and do not start review |
-| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with appended verdict | Transitional; do not append another verdict and immediately resume Step 5 preparation/archive |
+| `PLAN-*-G??.md` + unfilled `CODE_REVIEW-*-G??.md` stub/placeholders | Implementation is not judgeable; review should fail completeness if invoked |
+| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md` without verdict | Ready for code-review skill |
+| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with appended verdict | Review finalization pending; do not append another verdict, resume Step 5 preparation/archive |
 | Exactly one active pair member + its newly archived counterpart | Partial archive after a preflighted finalization; verify both identities, finish the remaining archive, then resume post-archive recovery |
-| `complete.log` + `*.log` files | Task complete (PASS or user-review-resolved PASS), with final archive/event metadata fixed before the final task-directory move |
-| `USER_REVIEW.md` + `*.log` files | Linked Milestone decision is required |
-| Highest numeric-suffix matching `user_review_*.log` has `## 상태` value `RESOLVED` and `해소 결과 > 결과` value `REPLAN`, with no active pair | Resolved user-review `plan-ready`; dispatch a different plan model using that log and its referenced archived pair |
+| `complete.log` + `*.log` files | Task complete (PASS or user-review-resolved PASS), before final task-directory archive move |
+| `USER_REVIEW.md` + `*.log` files | Automatic loop stopped; linked Milestone lock decision must be resolved before creating another plan |
 | `agent-task/archive/YYYY/MM/{task_name}/complete.log` + `*.log` files | Archived completed task path (PASS or user-review-resolved PASS); not active |
-| Only matching `plan_*.log` / `code_review_*.log` with WARN/FAIL | Internal `plan-ready`; dispatch a different plan model to create the follow-up pair |
+| Only `*.log` files (no `complete.log`) | If the newest review log has a verdict and its required next state is absent, post-archive finalization is pending; otherwise the task is terminated mid-loop or abandoned |
 
 The implementing agent never archives or deletes active files; archiving is this skill's responsibility.
 
@@ -159,25 +133,14 @@ Classify the combined set of active `CODE_REVIEW-*-G??.md` and `USER_REVIEW.md`
 | No active paths | Apply the finalization-recovery scan below; stop only when it finds no recoverable task. |
 | Multiple active paths | If the user/runtime named a task group, task path, or subtask directory that identifies exactly one active path, use that directory. Otherwise list paths and stop with an ambiguity report; do not choose by agent judgment and do not create a user-review request for routing ambiguity. |
 
-If a selected task directory contains both `USER_REVIEW.md` and an active `PLAN-*-G??.md` or `CODE_REVIEW-*-G??.md`, do not overwrite either state or ask the user to choose between files. Validate provenance: a valid unresolved `USER_REVIEW.md` remains the terminal state; otherwise resume the provable active-pair or finalization recovery path and preserve the inconsistent path as review evidence.
+If a selected task directory contains both `USER_REVIEW.md` and active `PLAN-*-G??.md` or `CODE_REVIEW-*-G??.md`, report an inconsistent loop state instead of overwriting either state.
 
-Before review begins, runtime re-evaluates every encoded predecessor for both filled and unfilled pairs. If one is unsatisfied, leave the pair unchanged, report `dependency-waiting`, and do not record a Review identity or append a verdict.
+Finalization-recovery scan, excluding `agent-task/archive/**`:
 
-An unfilled review stub with satisfied dependencies is not `review-ready`. Leave the pair unchanged and return it to the implementation stage.
-
-Finalization-recovery scans active task paths and uses only the artifact identities already present:
-
-- Find task directories with a verdict-appended active review, a partially archived pair, `complete.log` not yet moved, matching archived plan/review logs with no active pair, `USER_REVIEW.md`, or resolved `user_review_*.log`.
-- Match plan/review artifacts by their `task` and `plan` headers, and match a resolved user-review log by the archived plan/review paths recorded in its `해소 결과`; do not choose by modification time alone.
-- Recover the user/runtime-selected task path. Without one, recover only a single unambiguous candidate; list multiple candidates without mutating them.
-- Apply recovery precedence in this order: active `complete.log`; active `USER_REVIEW.md`; an already-created follow-up pair; highest numeric-suffix matching `RESOLVED`/`REPLAN` user-review log; verdict-appended or partially archived pair; archived pair alone.
-- Before returning an existing next artifact, verify its task/plan provenance and required fields.
-- An active `complete.log` owns its completion timestamp and exact final archive path. Validate those fields, then resume the final move.
-- An active `RESOLVED` `USER_REVIEW.md` resumes from its single `해소 결과`: archive an unchanged `REPLAN` result or continue `COMPLETE` using its fixed timestamp. Never resolve it again.
-- A highest numeric-suffix matching `RESOLVED`/`REPLAN` user-review log dispatches the different plan model with that log and its referenced archived pair; never recreate `USER_REVIEW.md` from the older gate.
-- Resume a verdict or partial archive at Step 5. For an archived WARN/FAIL pair without a next artifact, write `USER_REVIEW.md` when it proves a valid unresolved gate; otherwise dispatch the different plan model. For an archived PASS pair, finish the missing `complete.log`.
-- A newly created unfilled follow-up pair already satisfies the prior review's Plan output. Return the pair to implementation; do not review it until implementation makes it `review-ready`.
-- A PASS task move is the last review-owned filesystem mutation. After the move, the runtime may idempotently replay the completion event from the archived `complete.log` Finalization metadata; the review model does not reopen or mutate the moved task.
+- Candidate A has exactly one active plan, no active review/USER_REVIEW/complete.log, and a newest review log whose verdict belongs to that plan's current loop.
+- Candidate B has no active plan/review/USER_REVIEW/complete.log, and its newest plan/review logs form one loop whose review verdict requires a missing next state.
+- Accept only candidates whose exact source/archive identities and verdict can be proven from headers, log suffixes, and review contents. Do not treat a generic log-only abandoned directory as recoverable.
+- If the user/runtime names one candidate task path, resume it. Otherwise resume only when exactly one candidate exists; list multiple candidates as ambiguity. Use the Core Loop Rules recovery path and never append a second verdict.
 
 ## Step 2 - Load Context
 
@@ -190,22 +153,26 @@ The diff is the starting point, not the boundary. Follow behavior and API connec
 
 If the active plan or review file contains `Agent UI Completion`, also read `agent-ops/rules/common/rules-agent-ui.md` and the listed active agent-ui documents. Do not read `agent-ui/definition/archive/**` or `agent-ui/archive/user-review/**` unless the review explicitly cites those archive paths.
 
+Review scope control:
+
+- Use the plan's commands and checkpoints as the primary evidence. Add one focused, possibly table-driven reproducer only when needed to prove a suspected blocking defect; do not build speculative exhaustive probe matrices.
+- In a follow-up review, keep Required findings within the current plan, inherited Required findings, direct regressions from the fix, and concrete violations of the original SDD or contract acceptance criteria. Exclude unrelated pre-existing work from the verdict and Required/Suggested/Nit counts; mention it only in the final report as an out-of-scope task candidate.
+- Before adding a new Required that the current plan did not state, cite the exact original plan/SDD/contract criterion it violates or provide a concrete failing case. Do not require a preferred test shape when existing deterministic evidence proves the same behavior.
+- When one invariant fails in multiple already-observed variants, report that known set together instead of revealing one variant per follow-up.
+
 ## Step 3 - Pre-Review Checklist
 
 Before writing the verdict:
 
 - Compare actual source files against every planned checklist item.
-- For an indexed task directory, require its basename to match `NN_{subtask_name}` or `NN+PP[,QQ...]_{subtask_name}` and every encoded predecessor to be lower than `NN`. A malformed name is a Required orchestration finding and can never PASS.
-- For an indexed task directory with `+PP[,QQ...]`, require one unambiguous matching predecessor `complete.log` for every encoded index before review can PASS. Missing dependency evidence is a Required orchestration finding; the implementation worker never supplies or repairs it.
-- Compare the plan `구현 체크리스트` and review stub `구현 체크리스트`. Do not edit either checklist to repair drift; when correction is needed, record it as a WARN/FAIL finding.
+- Compare the plan `구현 체크리스트` and review stub `구현 체크리스트`; repair non-behavioral drift when implementation remains judgeable.
 - When the active artifacts have `Roadmap Targets`, check whether the referenced Milestone has `SDD: 필요`. When it does, read only that Milestone and its SDD, compare implementation evidence against the SDD Acceptance Scenarios/Evidence Map for the targeted task ids, and fail completeness or verification trust when evidence is insufficient. Do not require a separate SDD target section.
-- Record obvious non-behavioral source nits such as typos, stale comments, docs, or formatting. Do not edit source/test files during review; Nit-only findings may follow the PASS rule below.
+- Directly repair obvious non-behavioral source nits when safe: typos, stale comments, docs, or formatting only, with no behavior/test/API contract change.
 - If a checklist item contains integrated verification for a feature, treat that feature item as incomplete until both implementation evidence and the matching verification output are present. Do not accept a separate unchecked completion-criteria item as a substitute.
-- Confirm the implementation marked the matching checklist items in the active review file, including the final mandatory `CODE_REVIEW-*-G??.md` completion item. Do not mark or rewrite implementation-owned items on its behalf; classify missing or inconsistent entries by their effect on completeness and verification trust.
-- Verify that the PLAN `plan-model` metadata (or the legacy `역할 모델 > Plan` field) matches the review ledger and that the review stub records the Implementation identity. Require runtime to record the Review identity before verdict; filled identities are immutable. Reject review start unless all three are pairwise different, and do not infer identity from lane/G or agent name.
+- Confirm the implementation marked the matching checklist items in the active review file, including the mandatory `CODE_REVIEW-*-G??.md` evidence item; repair clear artifact drift when evidence supports completion.
 - If the active plan or review file contains `Agent UI Completion`, verify the implementation-owned fields are filled before PASS: listed agent-ui docs exist, actual code evidence paths exist, requested status updates are explicit, and implementation verification evidence is present. Missing or untrusted evidence is a completeness or verification-trust issue.
 - Treat review artifact gaps as failures only when they prevent judging implementation correctness, tests, contracts, or verification trust.
-- Read `사용자 리뷰 요청`. If filled, validate the exact linked Milestone decision and blocker evidence; reject non-lock requests.
+- Treat every generic `상태` field and implementation blocker record as ordinary evidence, never as a request to stop for the user. Evaluate the user-review gate independently from the current selected Milestone only after a WARN/FAIL finding requires a next state.
 - Grep renamed/removed symbols for stale references.
 - Confirm every required test exists, name matches, and assertions are meaningful.
 - Cross-check claimed verification output in the active review file against actual code and project commands.
@@ -215,30 +182,31 @@ Before writing the verdict:
 
 Append `코드리뷰 결과` to the active `CODE_REVIEW-*-G??.md`.
 
-Before appending `PASS`, if all other PASS conditions are met and the active review file contains `Agent UI Completion`, perform the review-pass status update first: update the listed agent-ui docs to `구현됨`, add actual code evidence, run `validate-agent-ui`, and mark the section's review-agent-owned finalization items. If this update or validation fails, do not append `PASS`; classify and record it as a normal WARN/FAIL finding.
+Before appending `PASS`, if all other PASS conditions are met and the active review file contains `Agent UI Completion`, perform the review-pass status update first: update the listed agent-ui docs to `구현됨`, add actual code evidence, run `validate-agent-ui`, and mark the section's review-agent-owned finalization items. If this update or validation fails, do not append `PASS`; classify the failure as `WARN` or `FAIL` and write the normal follow-up.
 
 Required fields:
 
 - `종합 판정`: exactly `PASS`, `WARN`, or `FAIL`.
 - `차원별 평가`: Pass/Warn/Fail for correctness, completeness, test coverage, API contract, code quality, implementation deviation, verification trust. If SDD Evidence Map applies through `Roadmap Targets`, also include spec conformance.
 - `발견된 문제`: `없음`, or bullets using `Required`, `Suggested`, or `Nit` with `file:line` and a concrete fix.
+- `라우팅 신호`: calculate once and append `review_rework_count=<N>` and `evidence_integrity_failure=true|false`. Set rework count to archived same-task `WARN|FAIL` verdicts plus one only when the current verdict is non-PASS. Set integrity failure to true only when a claimed test, command, exit code, or production path is absent, unexecuted, or contradicted by fresh reviewer evidence.
 - `다음 단계`: keep only the matching PASS, WARN/FAIL follow-up, or USER_REVIEW line.
 
-Do not perform archive or terminal-output mutations during Step 4. Step 5 onward owns finalization.
+Do not check archive/next-state items in `코드리뷰 전용 체크리스트` during Step 4. Complete the applicable dedicated checklist items in the archived `code_review_*.log` during Step 7, after archive, next-state writes, and PASS task-artifact moves are done.
 
 Severity semantics:
 
 | Verdict | Meaning | Follow-up plan |
 |---------|---------|----------------|
 | `PASS` | No Required/Suggested issues. Nit-only findings may still PASS. | No |
-| `WARN` | One or more Suggested issues, zero Required. | Follow-up pair via a different plan model; a valid gate is normally `FAIL` |
-| `FAIL` | One or more Required issues, including a valid Milestone-lock request. | Follow-up pair via a different plan model, except a valid `USER_REVIEW.md` gate |
+| `WARN` | One or more Suggested issues, zero Required. | Yes, unless the user-review gate triggers |
+| `FAIL` | One or more Required issues. | Yes, unless the user-review gate triggers |
 
 Issue severity:
 
-- `Required`: correctness, API contract, missing required test, missing integrated verification, plan-completeness issue, review artifact gaps that prevent judging implementation quality, or a valid selected Milestone-lock decision that blocks implementation.
+- `Required`: correctness, API contract, missing required test, missing integrated verification, plan-completeness issue, or review artifact gaps that prevent judging implementation quality.
 - `Suggested`: useful improvement that should enter the loop but does not block correctness.
-- `Nit`: tiny cleanup; record it without editing implementation-owned files or forcing WARN.
+- `Nit`: tiny cleanup; directly repair obvious non-behavioral cases when safe, otherwise record without forcing WARN.
 
 Verdict consistency:
 
@@ -246,67 +214,89 @@ Verdict consistency:
 - Any Fail dimension or any Required issue forces `FAIL`.
 - Any Warn dimension or any Suggested issue forces `WARN`, unless the only findings are explicitly Nit and every dimension remains Pass.
 
-## Step 5 - Archive Active Files
+## Step 5 - Prepare Next State And Archive Active Files
 
-- For a valid user-review gate, render `USER_REVIEW.md` in memory before renaming.
-- Ensure `.gitignore` exposes `agent-task/**/*.md` and `agent-task/**/*.log`.
-- Derive each archive suffix as `0` when no matching log exists, otherwise `max(existing numeric suffix) + 1`; combine it with that active file's own lane/grade.
-- For an uninterrupted archive, compute and preflight both destinations before the first rename and require both to be absent.
-- For partial recovery, identify the archived counterpart by matching `task` and `plan` headers. Treat its actual path as canonical, derive the missing member's destination from the remaining active member's own lane/grade and the current matching log suffixes, require that destination to be absent, and archive only the missing member. Do not invent or rename the existing counterpart.
-- The verdict, user-review gate, task/plan identity, and forbidden Plan identities remain readable from the active or archived review. Derive the post-archive branch from those artifacts after each rename; do not depend on an in-memory value surviving restart.
-- Rename the review, then the plan. Verify no active pair remains.
+Do not archive WARN/FAIL files until the next-state content is fully prepared in memory.
+
+- `PASS`: no routed follow-up preparation is required.
+- `WARN`/`FAIL`: apply the user-review gate before any rename.
+  - If the gate triggers, render the complete `USER_REVIEW.md` body from `agent-ops/skills/common/code-review/templates/user-review-template.md` in memory.
+  - Otherwise build the follow-up handoff described below and fully execute `agent-ops/skills/common/plan/SKILL.md` in `prepare-follow-up` mode.
+
+Reuse the routing signals appended in Step 4; do not recount verdict history for routing. Separately count the existing logs once for archive identity: set `current_review_archive_number=count(code_review_*.log)` and `current_plan_archive_number=count(plan_*.log)`, then derive both archive names from the current active files' own lane/grade. These archive values describe the pair being closed, not the next route.
+
+The follow-up handoff contains the selected `{task_name}`, the current plan's requested outcome/acceptance/exclusions revalidated against current evidence, current verdict, Required/Suggested/Nit findings, affected files, actual verification output, current ownership/dependency facts, roadmap carryover, `review_rework_count`, `evidence_integrity_failure`, `REVIEW_<PARENT_TAG>`, and those predicted current-pair archive names. Keep current active paths only as evidence pointers. Do not add the prior lane, grade, routing score, rationale, or a preferred next route to the neutral routing snapshot, and require plan to omit route-bearing basenames from the isolated routing input. The plan may use current archive names only after routing to render `Archive Evidence Snapshot`.
+
+- `prepare-follow-up` must return `status: routed`, the exact routed basenames, `prepared_plan`, `prepared_review`, `plan_number`, `current_plan_archive_name`, `current_plan_archive_number`, `current_review_archive_name`, `current_review_archive_number`, `plan_log_number`, `review_log_number`, and `gitignore_repair_needed`. It must have executed `finalize-task-routing` in `isolated-reassessment` mode.
+- Verify that the returned current archive names/numbers equal the values derived before preparation, and that `plan_log_number` / `review_log_number` are the post-archive counts embedded in the new review stub for its future archive.
+- If preparation returns `needs_evidence`, collect all named new evidence and rerun after the input changes; never rerun with unchanged evidence. If the evidence cannot be obtained in the current scope, leave the verdict-appended pair in place and report the exact finalization blocker.
+- If preparation returns `blocked`, leave the verdict-appended active PLAN/CODE_REVIEW pair in place, do not check archive/next-state items, and report a resumable finalization blocker. A later code-review invocation resumes this step without appending another verdict.
+
+After the required next state is prepared, archive is mandatory for `PASS`, `WARN`, and `FAIL`. Ensure `.gitignore` has the Agent-Ops managed gitignore block for task artifacts before writing `*.log` outputs. Prefer `source agent-ops/bin/ai-ignore.sh && agent_ops_ensure_gitignore_task_artifact_block .gitignore`; if the helper is unavailable, add or update a block containing `!agent-task/`, `!agent-task/**/`, `!agent-task/**/*.md`, `!agent-task/**/*.log`, and `agent-roadmap/current.md`. Apply the repair here when `prepare-follow-up` returned `gitignore_repair_needed: true`.
+
+Preflight both archive operations before either rename:
+
+1. Recount existing `code_review_*.log` as `current_review_archive_number`. Parse the active review's lane/grade from its own basename and derive `current_review_archive_name=code_review_{current_review_lane}_{current_review_grade}_{current_review_archive_number}.log`.
+2. Recount existing `plan_*.log` as `current_plan_archive_number`. Parse the active plan's lane/grade from its own basename and derive `current_plan_archive_name=plan_{current_build_lane}_{current_build_grade}_{current_plan_archive_number}.log`.
+3. Require both destinations not to exist. When the active stub contains concrete expected archive names, require them to match the derived names; legacy generic placeholders do not override the derived values.
+4. For WARN/FAIL, require exact matches with both prepared current archive names/numbers. If any check fails, do not rename either file.
+
+After both operations pass preflight, rename the active review and then the active plan to those exact names. If either current archive count or derived name changed after preparation, discard the prepared pair and rerun plan `prepare-follow-up` before renaming. After archiving, verify that the actual plan/review log counts equal the prepared `plan_log_number` and `review_log_number`; neither active `.md` file remains until Step 6 materializes the prepared next state.
 
 ## Step 6 - Post-Review Actions
 
-For `PASS`, after both pair logs exist, select one completion timestamp and collision-safe final task archive path, then write `agent-task/{task_name}/complete.log`. If a `USER_REVIEW.md` stop is resolved as complete/PASS, reuse its fixed resolution timestamp and select the collision-safe path when writing `complete.log`. Write and verify `complete.log` before moving that task. On recovery, an existing `complete.log` is canonical; do not select a new timestamp or path.
+For `PASS`, write `agent-task/{task_name}/complete.log` before reporting. If a `USER_REVIEW.md` stop is resolved as complete/PASS, write the same `complete.log` before archiving that task.
 
 Complete log template:
 
 - Template path: `agent-ops/skills/common/code-review/templates/complete-log-template.md`
 - Copy the template's section order and fill every placeholder from the archived plan/review logs and final verdict.
 - Do not leave placeholders in `complete.log`.
-- Fill the required `Finalization` section with the exact template keys: original `origin-task`, collision-safe `final-archive-path`, `task-group`, Milestone slug or `none`, final archived plan/review paths, and roadmap-completion Task ids or `none`. These fields are the runtime's idempotent completion-event input and the final-move recovery source.
 - If the task did not close through `USER_REVIEW.md`, remove the optional user-review row from the `루프 이력` table.
 - If the archived plan or review log contains `Roadmap Targets`, copy it into `complete.log` as `Roadmap Completion`. Include the Milestone path, completed Task ids, archived plan/review log paths, and verification evidence. If there is no `Roadmap Targets` section, remove the optional `Roadmap Completion` template section entirely and do not invent roadmap targets.
 - If the archived review log contains `Agent UI Completion`, copy the completed evidence into `complete.log`. If there is no `Agent UI Completion` section, remove the optional complete-log section entirely.
 - Use `없음` for empty `잔여 Nit` or `후속 작업`.
 - A PASS `complete.log` must not contain unresolved Required or Suggested issues. Nit-only leftovers may be recorded under `잔여 Nit`.
 
-For `WARN` or `FAIL` after archive:
+For `WARN` or `FAIL`, materialize the next state prepared in Step 5 immediately after archive:
 
-- If the user-review gate triggered, write and verify `USER_REVIEW.md`.
-- Otherwise dispatch a different plan model with the archived plan/review paths and wait for its readiness result. Require one new routed PLAN/CODE_REVIEW pair at the same task path and verify `implementation-ready` or `dependency-waiting`. The review model must not write that pair or edit product source/tests.
-- Stop before implementation.
+- If the user-review gate triggered, write the prepared body to `agent-task/{task_name}/USER_REVIEW.md`. It must use only `milestone-lock`, contain every archived loop entry plus the exact linked decision, and contain no placeholder. Do not write active PLAN/CODE_REVIEW files or `complete.log`.
+- Otherwise write `prepared_plan` and `prepared_review` byte-for-byte to their routed basenames. Do not rerun, adjust, compare, or upgrade their lane/G after archive.
+- Verify the written follow-up pair contains the predicted archived plan/review paths in identical `Archive Evidence Snapshot` sections and contains no unresolved token from the review-stub template inventory. Unrelated braces in commands or code are allowed.
+- Do not adjust the prepared route after finalization. For a `local-fit` base, `review_rework_count >= 2` or `evidence_integrity_failure=true` must produce `recovery-boundary`; `capability-gap` and `grade-boundary` keep their own basis.
 
-If the task group is `m-<milestone-slug>` and the user-review gate triggered, prepare a blocked-on-user-review report; do not emit PASS completion metadata and do not call `update-roadmap`.
+If the task group is `m-<milestone-slug>` and the user-review gate triggered, report that the milestone task is blocked on user review; do not emit PASS completion metadata and do not call `update-roadmap`.
 
-## Step 7 - Finalize, Move PASS Task, And Report
+## Step 7 - Complete Review-Only Checklist, Move PASS Task, And Report
 
 After Step 6:
 
-- For `PASS`, read the exact task archive path and completion-event fields back from `complete.log`; do not rely on in-memory copies.
-- Before a PASS move, run the ignore check and prepare the branch report from the same `complete.log` metadata. The move must be the only remaining review-owned filesystem mutation.
-- Create the parent of the exact task archive path and preflight the destination again. If it is newly occupied by non-matching evidence while the active task still exists, select the next collision-free suffix, replace every affected old final-archive prefix in `complete.log` including `Finalization` and `Roadmap Completion` evidence paths, re-read and revalidate the whole file, then preflight that new exact path.
-- Move the selected active task directory to that exact path as the final review-owned filesystem mutation. Do not open or update the moved review log, `complete.log`, or any other file after the move.
-- If verdict is `PASS` and `{task_group}` matches `m-<milestone-slug>`, do not resolve the roadmap target and do not call `update-roadmap`. Before the task archive move, verify the `complete.log` Finalization metadata contains `origin-task=agent-task/{task_name}`, `task-group={task_group}`, `milestone-slug=<milestone-slug>`, final archive path, archived plan/review log paths, and `roadmap-completion=<Task ids from complete.log or none>`.
+- 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 task artifacts from `agent-task/{task_name}/` to `agent-task/archive/YYYY/MM/{task_name}/`. For split work, move the selected subtask directory itself and 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 when it is empty.
+- 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, archived plan/review log paths, and `roadmap-completion=<Task ids from complete.log or none>`.
 - The runtime consumes that completion event, checks current state, and calls `update-roadmap` if needed. `update-roadmap` only checks Milestone Task ids when `complete.log` contains `Roadmap Completion`; if the section is absent, roadmap Task completion is a no-op even for `m-*` task groups.
 - If verdict is `PASS` and the archived review log contains `Agent UI Completion`, ensure the listed agent-ui status/evidence update and `validate-agent-ui` check are complete before writing or finalizing `complete.log`. Do not defer this to runtime or Milestone completion.
-- `WARN` and `FAIL` do not update the roadmap Milestone. The dispatched plan model keeps the same task path.
+- `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.
 - `USER_REVIEW` does not update the roadmap Milestone and does not produce PASS completion metadata. Keep the active task directory in place with `USER_REVIEW.md` and archived plan/review logs until the linked Milestone lock decision is resolved.
-- If `USER_REVIEW.md` is later resolved as complete/PASS by linked Milestone decision and evidence, write `complete.log`, move the task directory to archive, and report `m-*` PASS completion metadata just like a normal `PASS`.
-- For `WARN` or `FAIL`, run `git check-ignore -q --` on generated logs and terminal files after the follow-up pair or `USER_REVIEW.md` exists.
-- For `PASS`, perform the same ignore check before the final move. For user-review-resolved PASS, also verify the active task contains the resolved `USER_REVIEW.md`, `complete.log`, and existing archived pair before moving.
-- If any required artifact is missing, finish the archive, follow-up pair handoff, `complete.log`, final-path metadata, or `USER_REVIEW.md` write first.
-- Report only after the selected artifact and final paths are verified. A PASS report is read-only after the final move.
+- If `USER_REVIEW.md` is later resolved as complete/PASS by linked Milestone decision and evidence, write `complete.log`, move the task artifacts to archive, and report `m-*` PASS completion metadata just like a normal `PASS`.
+- For `PASS`, open the moved `agent-task/archive/YYYY/MM/{final_task_name}/{current_review_archive_name}`, where `{final_task_name}` is the archived task path, including `{task_group}/` for split work.
+- For user-review-resolved PASS, confirm the moved archive contains the resolved `USER_REVIEW.md`, `complete.log`, and the existing archived `plan_*.log` / `code_review_*.log`; do not recreate an active review file only to add a new checklist item.
+- For `WARN` or `FAIL`, open `agent-task/{task_name}/{current_review_archive_name}`.
+- Run `git check-ignore -q --` on the generated task artifacts (`plan_*.log`, `code_review_*.log`, `user_review_*.log` when present, `complete.log` when present, and active follow-up `.md` files). If any are ignored, apply the Agent-Ops managed gitignore block and re-check before reporting.
+- 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-artifact move, mandatory plan-skill follow-up, or `USER_REVIEW.md` 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, for `PASS` or user-review-resolved PASS the final task archive move, for `m-*` PASS tasks the completion event metadata, and for unresolved `USER_REVIEW` the filled `USER_REVIEW.md`.
 
-Report exactly one output: follow-up plan pair, `USER_REVIEW.md`, or `complete.log`. Include the relevant paths.
+Report Required/Suggested counts, archive names, the final task archive path for `PASS`, the new plan path for normal `WARN`/`FAIL`, the `USER_REVIEW.md` path for user review stops, and any `m-*` runtime completion event metadata.
 
 ## Review Dimensions
 
 | Dimension | Check |
 |-----------|-------|
 | Correctness | Logic, edge cases, concurrency, errors |
-| Completeness | Planned implementation/verification items are done; implementation-owned artifact drift is classified and routed without reviewer edits |
+| Completeness | Planned implementation/verification items are done; review artifact drift is repaired when judgeable |
 | Test coverage | Required tests present and meaningful |
 | API contract | Call sites, compatibility, docs |
 | Code quality | No debug prints, dead code, leftover TODOs |
@@ -320,24 +310,24 @@ Report exactly one output: follow-up plan pair, `USER_REVIEW.md`, or `complete.l
 - Name exact stale symbols or missing tests.
 - Do not write vague praise or style opinions without a rule.
 - Every dimension gets Pass/Warn/Fail.
-- For verification-trust findings, specify deterministic commands, for example `rg --sort path`, and forbid repo-local tool artifacts.
+- For follow-up plans about verification trust, specify deterministic commands, for example `rg --sort path`, and forbid repo-local tool artifacts.
 
 ## Final Checklist
 
-- Exactly one next-state outcome was selected: a follow-up PLAN/CODE_REVIEW pair, `USER_REVIEW.md`, or `complete.log`.
 - `{current_review_archive_name}` exists with the verdict appended and was derived from the archived active review's own route.
 - `{current_plan_archive_name}` exists and was derived from the archived active plan's own route.
 - `.gitignore` unignores `agent-task/**/*.md` and `agent-task/**/*.log` and ignores local `agent-roadmap/current.md`; generated task artifacts are not ignored by `git check-ignore`.
-- No active `.md` files remain after PASS or user-review-resolved PASS.
-- PASS or user-review-resolved PASS: `complete.log` contains the required Finalization metadata, then task directory moved under `agent-task/archive/YYYY/MM/` as the final filesystem mutation with task-group path preserved for split work.
-- PASS milestone task group: `m-<milestone-slug>` completion event metadata is prepared for runtime; roadmap was not modified by code-review.
+- No active `PLAN-*.md`, `CODE_REVIEW-*.md`, or `USER_REVIEW.md` remains after PASS or user-review-resolved PASS.
+- PASS or user-review-resolved PASS: `complete.log` written from `agent-ops/skills/common/code-review/templates/complete-log-template.md`, then task artifacts 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 with `Roadmap Targets`: `complete.log` contains `Roadmap Completion` with Milestone path, Task ids, archived plan/review evidence, and verification evidence.
-- PASS without `Roadmap Targets`: `complete.log` omits `Roadmap Completion` and prepared metadata says `roadmap-completion=none`.
+- PASS without `Roadmap Targets`: `complete.log` omits `Roadmap Completion` and reported metadata says `roadmap-completion=none`.
 - PASS with `Agent UI Completion`: listed agent-ui docs were updated to `구현됨` with code evidence, `validate-agent-ui` passed, and `complete.log` contains `Agent UI Completion`.
 - PASS without `Agent UI Completion`: complete.log omits `Agent UI Completion`.
-- WARN/FAIL without user-review gate: a different plan model wrote one follow-up pair, the reviewer did not plan or implement, and the pair has an `implementation-ready` or `dependency-waiting` result.
-- Follow-up review stubs include the `사용자 리뷰 요청` section from `agent-ops/skills/common/_templates/implementation-user-review-request-section.md` and forbid direct user prompts during implementation.
+- WARN/FAIL without user-review gate: the plan skill was invoked for the exact task path with verified `review_rework_count` and `evidence_integrity_failure`, completed `finalize-task-routing`, and created new active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` files matching the fresh routed output; no `complete.log`.
+- WARN/FAIL follow-up: the plan input omitted prior route fields, revalidated outcome/acceptance/exclusions from current evidence, used the completed in-memory PLAN as the packet, and copied identical `Archive Evidence Snapshot` sections into the new plan/review pair.
+- Follow-up plans and review stubs keep implementation agents limited to implementation/test/evidence and contain no implementation-owned user-review request section.
 - USER_REVIEW: `USER_REVIEW.md` exists from template, no active `PLAN-*.md` or `CODE_REVIEW-*.md` remains, and no `complete.log` was written.
-- Implementation-requested USER_REVIEW: archived review log preserves the filled `사용자 리뷰 요청` evidence and the generated `USER_REVIEW.md` records the exact linked Milestone decision needed.
+- Review-agent-owned USER_REVIEW: the generated `USER_REVIEW.md` records the exact active Milestone decision and repository evidence that made automatic continuation unsafe.
 - USER_REVIEW resolved as PASS: archived task contains both resolved `USER_REVIEW.md` and `complete.log`.
-- USER_REVIEW resolved to more implementation: `USER_REVIEW.md` was archived to a `RESOLVED`/`REPLAN` `user_review_N.log` that references its archived pair and forbidden identities, a different plan model wrote one follow-up pair from that evidence, and the pair has an `implementation-ready` or `dependency-waiting` result.
+- The applicable review-agent-only finalization checklist was completed before reporting.

agent-ops/skills/common/code-review/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Code Review"
-  short_description: "Review and leave the required next artifact"
-  default_prompt: "Use $code-review to leave exactly one result: a follow-up pair authored by a different Plan model, USER_REVIEW.md, or complete.log."
+  short_description: "Review and route task loops"
+  default_prompt: "Use $code-review to review or resolve the active task, archive it, and on WARN/FAIL invoke $plan so $finalize-task-routing creates the next routed pair."

agent-ops/skills/common/code-review/templates/complete-log-template.md

@@ -4,16 +4,6 @@
 
 {YYYY-MM-DD or ISO-8601}
 
-## Finalization
-
-- origin-task: `agent-task/{task_name}`
-- final-archive-path: `agent-task/archive/{YYYY}/{MM}/{final_task_name}`
-- task-group: `{task_group}`
-- milestone-slug: `{milestone-slug or none}`
-- archived-plan: `{final archived plan log path}`
-- archived-review: `{final archived review log path}`
-- roadmap-completion: `{Task ids or none}`
-
 ## 요약
 
 {one-line task summary, loop count, and final verdict; include user-review resolution if applicable}

agent-ops/skills/common/code-review/templates/user-review-template.md

@@ -46,7 +46,5 @@ USER_REVIEW
 
 ## 종료 규칙
 
-- 이 해소는 archived review에 기록된 같은 Review model identity의 재시도만 수행한다.
 - 연결 결정과 evidence가 이 stop state를 완료/PASS로 해소하면 `USER_REVIEW.md`를 해소 상태로 갱신하고, `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준 `complete.log`를 작성한 뒤 task directory를 archive로 이동한다.
-- 새 구현이 필요하면 `## 상태` 값을 `RESOLVED`로 바꾸고 단일 `## 해소 결과`에 `결과: REPLAN`, `해소 일시`, `결정`, `Evidence`, `Archived plan`, `Archived review`, `Forbidden implementation model`, `Forbidden review model`을 기록한 뒤 `user_review_N.log`로 아카이브한다. 이미 `RESOLVED`이면 결과나 timestamp를 다시 쓰지 않고 그대로 재개한다.
-- 완료/PASS 해소이면 `## 상태` 값을 `RESOLVED`로 바꾸고 단일 `## 해소 결과`에 `결과: COMPLETE`, `해소 일시`, `Final verdict`, `결정`, `Evidence`, `Archived plan`, `Archived review`를 기록한다. 이미 `RESOLVED`이면 기존 `해소 일시`를 재사용한다. 이 파일은 rename하지 않고 `complete.log`와 함께 최종 task archive에 보존한다.
+- 새 구현이 필요하면 `plan` 스킬이 `USER_REVIEW.md`를 `user_review_N.log`로 아카이브한 뒤 새 `PLAN-*-G??.md` / `CODE_REVIEW-*-G??.md`를 작성한다.

agent-ops/skills/common/create-roadmap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: create-roadmap
-version: 1.19.0
+version: 1.19.2
 description: AI-first 개인/소규모 프로젝트의 전체 목표, Phase scaffold, Phase 하위 Milestone 문서, 전역 priority-queue.md 실행 순서 문서, 로컬 current.md 활성 Phase/Milestone 창, archive Phase scaffold를 처음 생성하고, agent-ui 코드 동기화 Milestone의 완료 리뷰 상태 반영 항목을 포함하는 공통 스킬
 ---
 
@@ -121,6 +121,8 @@ agent-roadmap/
 - 새 Milestone이 다른 프로젝트 Milestone 완료 전까지 잠겨야 하면 `구현 잠금`을 `잠금`으로 두고 프로젝트 상위 `.agent-roadmap-sync/locks.yaml`에 entry를 만든다. 의존 대상 확정과 entry 형식은 `update-roadmap`의 프로젝트 간 잠금 규칙을 따른다.
 - `기능`은 Epic heading과 Task 체크리스트로 작성한다.
 - Epic heading은 `### Epic: [epic-id] <이름>` 형식으로 작성한다.
+- 각 Epic에는 기능 Task를 최대 5개만 둔다. 5개를 초과하는 Task는 허용하지 않는다.
+- 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 기존 Epic을 둘 이상으로 분리한다. 분리 후에도 독립 목표가 남으면 새 Milestone 후보로 둔다.
 - Task는 `- [ ] [item-id] 설명` 형식으로 작성한다.
 - epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 해당 Milestone 안에서만 유일하면 된다.
 - 검증이 필요한 Task에만 같은 항목 안에 `검증: <명령/확인 방법/기대 결과>`를 붙인다. 검증이 필요 없는 기능에는 억지 검증을 붙이지 않는다.
@@ -156,6 +158,7 @@ agent-roadmap/
    - Phase는 큰 진화 단위로 나누고, 각 Phase에 목표와 상태를 둔다.
    - Milestone은 Phase 안에서 완료 판단이 가능한 단위로 나눈다.
    - Milestone 내부에서 여러 기능 묶음이 필요하면 Epic으로 선언하고, Epic 아래 flat Task 체크리스트를 둔다.
+   - 각 Epic의 기능 Task 수는 최대 5개로 제한한다. 여섯 번째 Task가 필요하면 책임과 산출물 경계를 기준으로 Epic을 분리한다.
 
 4. **파일 생성**
    - `ROADMAP.md`, `priority-queue.md`, 로컬 `current.md`, 각 Phase의 `PHASE.md`, 각 Milestone 문서를 템플릿 순서대로 생성한다.
@@ -179,6 +182,7 @@ agent-roadmap/
    - 생성한 로드맵 문서의 Markdown 링크 target에 템플릿 placeholder가 남지 않았는지 확인한다.
    - 로컬 `current.md` 활성 항목에 `agent-roadmap/archive/**` 경로가 없는지 확인한다.
    - Epic heading과 Task 체크리스트 id가 형식을 따르는지 확인한다.
+   - 각 Epic의 기능 Task 수가 최대 5개인지 확인한다. 6개 이상이면 검증 실패로 보고하고 Epic 분리를 요구한다.
    - 상태 표기가 `[진행중]`처럼 공백 없는 표준값인지 확인한다.
    - `[스케치]` Milestone에 `승격 조건` 섹션이 있고 `구현 잠금`이 `잠금`인지 확인한다.
    - 각 Milestone의 `구현 잠금`에 `SDD: 필요|불필요`와 판정 사유가 있는지 확인한다.

agent-ops/skills/common/finalize-task-routing/SKILL.md

@@ -1,196 +1,149 @@
 ---
 name: finalize-task-routing
-description: PLAN/CODE_REVIEW 작성 직전 현재 작업 증거만으로 cloud/local lane과 G01-G10 등급을 독립 평가하고 canonical 파일명을 확정한다. 최초 plan, review 실패 후 follow-up plan, 라우팅 재평가, lane/G 판단, routed filename 결정에 사용한다.
+description: PLAN/CODE_REVIEW 작성 직전 완성된 build packet을 한 번 평가해 local-first lane, G, canonical filename을 확정한다. 최초 plan과 WARN/FAIL follow-up에서 capability gap, indivisible context, 복합 loop-risk, review rework, evidence integrity에 따른 cloud 경계를 적용할 때 사용한다.
 ---
 
 # Finalize Task Routing
 
-## 목적
+## 목표
 
-계획 분석이 끝난 뒤 구현과 리뷰 target의 lane과 G 등급을 처음부터 평가하고 canonical 파일명을 반환한다.
-이 스킬은 라우팅 판단의 단일 원본이며 plan/review 내용을 작성하거나 task 파일을 직접 생성하지 않는다.
-
-Lane/G는 capability 요구사항이다. Runtime은 plan, build, review를 서로 다른 모델 identity에 배정해야 하며, 같은 lane/G여도 같은 모델을 재사용하면 안 된다.
-
-## 언제 호출할지
-
-- `plan`이 최초 PLAN/CODE_REVIEW pair를 쓰기 직전
-- `code-review`의 WARN/FAIL 후 `plan`이 follow-up PLAN/CODE_REVIEW pair를 다시 쓰기 직전
-- 기존 lane/G 판정이 검증 실패, 증거 충돌, 범위 변화, 소유권 변화로 무효화된 뒤 재평가할 때
-- 사용자가 현재 작업의 cloud/local, G 등급, canonical task 파일명만 요청할 때
+완성된 in-memory PLAN 하나를 한 번 평가해 build/review route를 확정한다. routing 전용 문서나 증거 탐색을 만들지 않는다. Build의 기본값은 local이며 아래 표의 cloud 조건에 일치할 때만 승격한다. 공식 review는 항상 cloud의 Codex `gpt-5.6-sol` xhigh다. 이 스킬은 task 파일을 수정하지 않는다.
 
 ## 입력
 
-- `targets`: `build`, `review`, 또는 둘 다. `plan`은 항상 둘 다 전달한다 (필수)
-- `evaluation_mode`: 이전 라우팅이 없는 최초 평가는 `first-pass`, 무효화된 기존 라우팅의 lane/grade/score/rationale를 입력에서 격리하고 현재 미해결 작업을 처음부터 평가하는 모드는 `isolated-reassessment` (필수)
-- `task_snapshot`: 사용자 요구, 현재 scope, 수정/영향 경로, 불변조건, 상태 전이, 검증 계획, 이미 존재하는 증거 또는 `none` (필수)
-- `context_snapshot`: 함께 유지해야 하는 source/test/diff/log/contract 범위와 분할 가능성 (필수)
-- `ownership_snapshot`: 공유 상태, 병행 작업, sibling task, 외부 책임 경계 (필수)
-- `decision_snapshot`: 미해결 의미 판단, 사용자 권한이 필요한 결정, 외부 환경 의존성 (필수)
-- `invalidation_evidence`: 검증 실패, 실제 로그, review finding, 변경된 범위 등 현재 판정을 바꾸는 원시 증거 (선택)
+- `evaluation_mode`: `first-pass | isolated-reassessment`
+- `targets.build`: 구현 에이전트가 읽을 PLAN과 PLAN 작성에 이미 사용한 scope, source/test/contract, 불변조건, 검증 근거
+- `targets.review`: review scope, 영향 경로, 검증 계획과 근거
+- target별 closure와 근거: `scope_closed`, `context_closed`, `verification_closed`, `evidence_trusted`, `ownership_closed`, `decision_closed`
+- target별 G 점수: `scope_coupling`, `state_concurrency`, `blast_irreversibility`, `evidence_diagnosis`, `verification_complexity`
+- build 신호: `large_indivisible_context`, `matched_loop_risk_signatures`, `review_rework_count`, `evidence_integrity_failure`
+- closure가 false이고 cloud가 해소할 수 있을 때만 `capability_gap`: `observed`, `evidence`, `cloud_resolution`
 
-이전 `lane`, `grade`, 점수, 라우팅 사유, routed filename은 입력에서 제외한다.
-이전 PLAN/CODE_REVIEW 문서의 코드 경로, 기존 로그, finding은 경로와 revision 관련성을 정적으로 확인한 뒤 원시 증거로만 사용할 수 있다. 확인을 위해 검증 명령을 다시 실행하지 않는다.
+이전 lane/G, 점수, route 사유, filename을 입력하지 않는다. `review_rework_count`와 `evidence_integrity_failure`만 route-free 운영 이력으로 전달한다.
 
-## 먼저 확인할 것
+## 판정 순서
 
-- [ ] `agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-route.sh`가 실행 가능한가
-- [ ] 호출자가 plan 분석, scope, split, 검증 계획을 모두 확정했는가
-- [ ] `targets`마다 필요한 구현 또는 리뷰 작업이 구분되어 있는가
-- [ ] 이전 lane/G와 그 평가 문구가 입력에서 격리되었는가
-- [ ] `isolated-reassessment`이면 이전 lane/grade/score/rationale/preferred route를 제외한 중립 snapshot만 평가 입력으로 사용했는가
-- [ ] 현재 파일, diff, 확정된 제약, 이미 기록된 명령 출력을 우선 증거로 사용했는가
+아래 순서를 지키고 종료 조건을 만나면 즉시 멈춘다.
 
-## 검증 책임
+### 1. Snapshot 고정
 
-- Routing은 계획된 검증의 결정성과 관찰 가능성만 평가한다. 실행 전 출력 부재는 `unknown` 또는 `needs_evidence` 사유가 아니다.
-- Plan과 routing은 구현 검증을 실행하지 않는다. 이 스킬은 canonical filename 계산 script만 실행한다.
-- Build가 검증과 출력 기록을 맡고, review가 evidence를 확인하며 review scope에 필요한 명령을 재실행한다.
+PLAN body, split, verification, evidence, ownership, decision이 완성된 뒤 실행한다.
 
-## 실행 절차
+- PLAN 자체를 build packet으로 사용한다. 별도 packet 요약을 만들지 않는다.
+- 이미 읽은 사실만 사용한다. routing 때문에 source/test/log를 다시 읽지 않는다.
+- split된 packet만 평가한다. parent/sibling의 파일·상태·risk를 합산하지 않는다.
+- `isolated-reassessment`에서는 이전 route 정보를 제거한다. 제거할 수 없으면 `blocked: isolated-routing-unavailable`로 종료한다.
 
-1. **평가 상태 초기화**
-   - 호출할 때마다 각 target을 `unrouted`로 시작한다.
-   - `isolated-reassessment`는 이전 lane/grade/score/rationale/preferred route를 입력에서 제외하고, 현재 미해결 Required/Suggested, 영향 경로, 검증, 소유권, 결정 상태로 재구성한 중립 snapshot만 평가한다.
-   - `isolated-reassessment`는 plan 역할 안의 라우팅 재평가다. 별도 routing model은 필요 없으며 plan/build/review의 서로 다른 모델 조건은 그대로 유지한다.
-   - 이전 lane/G를 승계하거나 하한으로 사용하지 않는다.
-   - 실패 횟수, Required 개수, 이전 G 등급만으로 cloud 또는 상위 G를 선택하지 않는다.
-   - 실패는 자동 승격 조건이 아니라 현재 증거에 추가되는 판정 무효화 사건으로만 취급한다.
-   - 새 결과가 확정되기 전에는 이전 평가와 비교하지 않는다. 감사용 비교가 요청된 경우에만 호출자가 routed 출력 이후 delta를 기록한다.
+### 2. Closure gate
 
-2. **폐쇄성 평가**
-   - 각 target을 bounded local execution으로 완료·판정할 수 있는지를 기준으로 아래 값을 `true`, `false`, `unknown` 중 하나로 독립 판정하고 근거를 한 줄로 기록한다.
-     - `scope_closed`: 정확성 조건과 영향 경로가 확정된 범위 안에서 설명되는가
-     - `context_closed`: 중요한 증거를 생략하지 않고 필요한 컨텍스트를 함께 다룰 수 있는가
-       - 계획 분석 결과, 해당 target을 수행하는 동안 긴 컨텍스트를 유지해야 한다고 판단되면 `context_closed=false`로 판정한다.
-     - `verification_closed`: 계획된 명령과 관찰로 build/review가 성공 여부를 결정적으로 증명할 수 있는가
-     - `evidence_trusted`: 검증 경로와 evidence 출처가 구체적이고 재현 가능한가. 최초 plan에서는 실행 전 검증 설계의 신뢰성을 평가하며 PASS 출력은 요구하지 않는다.
-     - `ownership_closed`: 공유 상태, 병행 작업, 외부 소유권이 판단을 모호하게 만들지 않는가
-     - `decision_closed`: 사용자 권한이나 미해결 외부 의미 결정 없이 작업을 완료할 수 있는가
-       - active review follow-up에서는 유효한 Milestone-lock 결정만 `false`의 terminal gate가 될 수 있다. 환경, permission, secret, service, evidence 한계는 해결 완료 여부가 아니라 blocker 확인·해제 조건·재검증이 계획 가능한지를 평가한다.
-   - 동시성, dirty worktree, 외부 명령, 많은 finding은 그 자체로 lane을 결정하지 않는다. 위 폐쇄성에 미치는 영향만 평가한다.
+각 target의 closure를 독립적으로 판정한다.
 
-3. **판정 가능성 확인**
-   - 하나라도 `unknown`이면 `status: needs_evidence`와 필요한 정적 planning evidence를 반환한다. 실행 전 PASS 출력 부재는 `unknown` 사유가 아니다. lane, grade, filename은 반환하지 않는다.
-   - first-pass에서 하나 이상의 값이 `false`이고 cloud의 더 넓은 컨텍스트나 진단도 그 폐쇄 실패를 해소할 수 없으면 `status: blocked`, 폐쇄 실패별 `blocked_reason`, 해제 조건을 반환한다. 이 상태는 routed pair가 생성되기 전의 loop-entry 거절이며, active loop의 terminal state가 아니다.
-   - active code-review의 `isolated-reassessment`에서는 유효한 Milestone-lock 결정이 이미 code-review의 `USER_REVIEW.md` gate로 분기되어야 한다. 그 외 환경, permission, secret, service, ownership, verification 제한은 blocker 증거·결정적 해제 조건·재검증을 포함하는 follow-up으로 평가하고 `blocked`를 반환하지 않는다.
-   - 호출자는 `needs_evidence`를 cloud로 해석하지 말고 정적 planning evidence를 보강한 뒤 이 스킬을 처음부터 다시 실행한다. routing을 위해 구현 검증을 실행하지 않는다.
+- `scope_closed`: 정확성 조건과 영향 경로가 확정됨
+- `context_closed`: PLAN과 pointer가 구현에 필요한 사실을 제공함
+- `verification_closed`: 결정적 성공 판정 방법이 있음
+- `evidence_trusted`: 실제 경로를 실행하는 재현 가능한 근거가 있음
+- `ownership_closed`: 공유 상태와 외부 소유권이 명확함
+- `decision_closed`: 사용자·외부 의미 판단 없이 완료 가능함
 
-4. **Lane 결정**
-   - 모든 폐쇄성이 `true`인 target만 `local`로 정한다.
-   - `unknown`이 없고 하나 이상의 폐쇄성이 `false`이며 cloud의 더 넓은 컨텍스트나 진단이 그 실패를 실제로 해소할 수 있을 때 `cloud`로 정한다.
-   - `false`를 cloud가 해소할 수 있는지 근거를 기록한다. 해소 가능성을 설명할 수 없는 first-pass target만 Step 3의 `blocked`를 반환한다. Active code-review의 `isolated-reassessment`에서는 `blocked`를 반환하지 말고, 유효한 Milestone-lock 결정은 code-review의 `USER_REVIEW.md` gate로 돌려보내며 그 외 제한은 blocker 증거·결정적 해제 조건·재검증을 수행하는 bounded follow-up scope로 재구성한 뒤 폐쇄성을 다시 평가한다.
-   - 실패 후에도 현재 폐쇄성이 모두 `true`이면 다시 `local`을 선택할 수 있다.
-   - lane은 capability fit이며 작업량이나 모델 사용량 균형을 위한 값이 아니다.
+첫 번째로 일치하는 규칙을 적용한다.
 
-5. **G 등급 재산정**
-   - lane을 정한 뒤에만 각 target을 아래 다섯 차원에서 `0`, `1`, `2`로 처음부터 채점한다.
-     - `scope_coupling`: `0` 단일 국소 변경 / `1` 여러 연결 지점 / `2` 다중 모듈·계약
-     - `state_concurrency`: `0` 무상태 / `1` 상태 전이 / `2` 공유 상태·순서·동시성
-     - `blast_irreversibility`: `0` 내부 가역 / `1` 다중 호출자·설정·지속 상태 / `2` 외부 계약·권한·비가역 영향
-     - `evidence_diagnosis`: `0` 직접 증거 / `1` 복수 증거 조합 / `2` 충돌·불신 증거 진단
-     - `verification_complexity`: `0` 단일 결정 명령 / `1` 복수 단계·통합 검증 / `2` 외부·상호작용·장시간 검증
-   - grade는 `max(1, 다섯 점수의 합)`이며 유효 범위는 `G01`부터 `G10`이다.
-   - 이전 grade, 실패 횟수, lane 변경은 점수에 더하지 않는다.
+| 조건 | 결과 |
+|------|------|
+| 어느 target이든 closure 하나라도 `unknown` | `needs_evidence`; 부족한 evidence를 구체적으로 기록하고 종료 |
+| 어느 target이든 closure 하나라도 `false`이고 구체적인 `cloud_resolution`이 없음 | `blocked`; 해제 조건을 기록하고 종료 |
+| build closure가 `false`이고 `observed`, `evidence`, `cloud_resolution`이 모두 있음 | build base basis를 `capability-gap`으로 설정 |
+| review closure만 `false`이고 cloud가 해소함 | review gap만 기록; build basis에는 영향 없음 |
+| build closure가 모두 `true` | G를 계산해 build base basis 결정 |
 
-6. **파일명 확정**
-   - 각 target에 대해 다음 명령을 실행하고 stdout의 grade와 filename을 그대로 사용한다.
+`needs_evidence`는 확인된 모든 missing evidence를 한 번에 나열한다. 입력이 달라진 뒤에만 재평가하고 같은 evidence로 반복하지 않는다.
 
-     ```bash
-     agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-route.sh \
-       <build|review> <local|cloud> \
-       <scope_coupling> <state_concurrency> <blast_irreversibility> \
-       <evidence_diagnosis> <verification_complexity>
-     ```
+### 3. G 계산
 
-   - 모델이 점수 합산, zero-padding, prefix 조합을 직접 계산하지 않는다.
-   - 두 target은 같은 lane/G를 복사하지 말고 각자의 실행 범위로 독립 평가한다.
-   - 모든 요청 target이 `routed`일 때만 filename을 반환한다.
-   - 결과 확정 뒤 scope, 검증, 증거, 소유권, 결정 조건이 달라지면 결과를 무효화하고 Step 1부터 다시 실행한다.
+각 target의 다섯 값을 `0`~`2`로 채점하고 `grade=max(1, 합계)`로 계산한다.
 
-## 라우팅 결과 확인
+- `scope_coupling`: 국소 / 여러 연결 지점 / 다중 모듈·계약
+- `state_concurrency`: 무상태 / 상태 전이 / 공유 상태·순서·동시성
+- `blast_irreversibility`: 내부 가역 / 다중 호출자·지속 상태 / 외부 계약·비가역
+- `evidence_diagnosis`: 직접 증거 / 복수 증거 조합 / 충돌·불신 증거 진단
+- `verification_complexity`: 단일 명령 / 복수 단계·통합 / 외부·상호작용·장시간
 
-- [ ] 모든 요청 target에 여섯 폐쇄성 값과 현재 증거 근거가 있는가
-- [ ] 재평가가 `isolated-reassessment`로 실행되었고 새 결과를 확정하기 전에 이전 lane/grade/score/rationale를 입력·하한·비교 기준으로 사용하지 않았는가
-- [ ] `unknown` 또는 `blocked` 상태에서 lane/G/filename을 만들지 않았는가
-- [ ] 이전 lane/G, 실패 횟수, finding 개수를 승계하거나 자동 승격 근거로 사용하지 않았는가
-- [ ] lane을 먼저 정하고 G 등급을 별도 차원 점수로 산정했는가
-- [ ] 각 target에 formatter script를 실행했고 grade와 filename을 stdout 그대로 사용했는가
-- [ ] build/review filename이 target별 formatter 결과와 정확히 일치하는가
-- [ ] plan/build/review model identity 분리 조건을 runtime handoff에 남겼는가
-- 확인 실패 시 결과를 `unrouted`로 폐기하고 누락된 정적 planning evidence부터 보강한 뒤 전체 평가를 다시 수행한다.
+capability gap이 없으면 G01~G08은 `local-fit`, G09~G10은 `grade-boundary`다.
 
-## 출력 형식
+### 4. Build 신호 계산
 
-```yaml
-status: routed | needs_evidence | blocked
-evaluation_mode: first-pass | isolated-reassessment
-targets:
-  build:
-    closures:
-      scope_closed: true
-      context_closed: true
-      verification_closed: true
-      evidence_trusted: true
-      ownership_closed: true
-      decision_closed: true
-    closure_basis:
-      scope_closed: "<current evidence>"
-      context_closed: "<current evidence>"
-      verification_closed: "<current evidence>"
-      evidence_trusted: "<current evidence>"
-      ownership_closed: "<current evidence>"
-      decision_closed: "<current evidence>"
-    lane: local
-    grade_scores:
-      scope_coupling: 1
-      state_concurrency: 1
-      blast_irreversibility: 1
-      evidence_diagnosis: 0
-      verification_complexity: 1
-    grade: G04
-    filename: PLAN-local-G04.md
-  review:
-    closures:
-      scope_closed: true
-      context_closed: false
-      verification_closed: true
-      evidence_trusted: false
-      ownership_closed: true
-      decision_closed: true
-    closure_basis:
-      scope_closed: "<current evidence>"
-      context_closed: "<current evidence>"
-      verification_closed: "<current evidence>"
-      evidence_trusted: "<current evidence>"
-      ownership_closed: "<current evidence>"
-      decision_closed: "<current evidence>"
-    lane: cloud
-    grade_scores:
-      scope_coupling: 1
-      state_concurrency: 1
-      blast_irreversibility: 1
-      evidence_diagnosis: 2
-      verification_complexity: 1
-    grade: G06
-    filename: CODE_REVIEW-cloud-G06.md
-missing_evidence: []
-blocked_reason: null
+`large_indivisible_context=true`는 다음 세 조건을 모두 만족할 때만 사용한다.
+
+1. 안전한 split을 끝냈다.
+2. 하나의 correctness/transaction 판단이 여러 독립 source of truth를 동시에 요구한다.
+3. 명시적 국소 규칙과 결정적 verification oracle로 축약할 수 없다.
+
+파일이 많다는 이유만으로 true로 두지 않는다.
+
+아래 signature를 이미 읽은 PLAN/source/test/contract에서 한 번만 확인한다. 양성 조건이 보인 이름만 기록하고, match하지 않은 signature의 부재를 증명하지 않는다. 필요한 범위가 불명확하면 risk를 `unknown`으로 만들지 말고 closure에서 처리한다.
+
+- `temporal_state`: 상태 3개 이상과 partial/retry/cancel/recovery/stale/duplicate 경로
+- `concurrent_consistency`: actor 2개 이상과 atomic snapshot/lock order/exactly-once/race-free 제약
+- `boundary_contract`: component 3개 이상 또는 consumer 2개 이상과 validation/immutability/compatibility 제약
+- `structured_interpretation`: parser/lexer/protocol assembly/multi-source merge와 nesting/quoting/precedence/deduplication 위험
+- `variant_product`: 독립 variant 축 2개 이상과 조합 검증
+
+중복 없는 이름 수를 `loop_risk_count=0..5`로 사용한다.
+
+- `risk_boundary = large_indivisible_context || loop_risk_count >= 4`
+- `recovery_boundary = review_rework_count >= 2 || evidence_integrity_failure`
+
+`review_rework_count`는 같은 task path의 archived `WARN|FAIL` 수에 현재 non-PASS verdict를 더한 값이다. 첫 non-PASS follow-up은 1, 두 번째는 2다.
+
+### 5. Build route 확정
+
+첫 번째로 일치하는 규칙을 적용한다.
+
+| 조건 | `route_basis` | lane |
+|------|---------------|------|
+| base basis가 `capability-gap` | `capability-gap` | cloud |
+| base basis가 `grade-boundary` | `grade-boundary` | cloud |
+| base basis가 `local-fit`이고 `recovery_boundary` | `recovery-boundary` | cloud |
+| base basis가 `local-fit`이고 `risk_boundary` | `risk-boundary` | cloud |
+| 그 외 | `local-fit` | local |
+
+risk/recovery는 local-fit build의 승격 조건이다. 이미 cloud인 capability/grade basis를 덮어쓰지 않는다. grade는 lane 변경과 무관하게 보존한다. review는 `official-review`, cloud, 실제 G를 사용한다.
+
+### 6. Finalizer 실행
+
+`status=routed`일 때만 아래 명령을 정확히 한 번 실행한다.
+
+```bash
+agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-policy.sh pair \
+  <build-base-basis> \
+  <large-indivisible-context> <loop-risk-count> \
+  <review-rework-count> <evidence-integrity-failure> \
+  <build-scope> <build-state> <build-blast> <build-evidence> <build-verification> \
+  official-review \
+  <review-scope> <review-state> <review-blast> <review-evidence> <review-verification>
 ```
 
-`needs_evidence` 또는 `blocked`에서는 해당 target의 `lane`, `grade_scores`, `grade`, `filename`을 `null`로 둔다.
+finalizer 출력만 사용한다. lane, grade, boundary, filename을 수작업으로 만들지 않는다.
 
-## 금지 사항
+## 출력 계약
 
-- 이전 lane/G를 기본값, 최소값, 비교 기준으로 사용하지 않는다.
-- `isolated-reassessment`에 별도 routing model을 요구하거나, 이를 근거로 한 모델이 plan/build/review 중 둘 이상을 맡게 하지 않는다.
-- active review follow-up에서 `USER_REVIEW.md` gate가 아닌 blocker를 사용자 질문이나 `blocked` terminal로 바꾸지 않는다.
-- 기존 평가가 있다는 이유로 같은 호출에서 재평가하는 것을 금지하지 않는다. 다만 이전 lane/grade/score/rationale/preferred route를 재평가 입력이나 하한으로 사용하지 않는다.
-- local 실패를 이유로 cloud로 자동 승격하지 않는다.
-- 높은 local G로 cloud에 필요한 컨텍스트나 판단을 보상하지 않는다.
-- 파일 수, 동시성, dirty 상태, Required 개수 같은 단일 휴리스틱으로 lane을 정하지 않는다.
-- grade나 filename을 formatter script 출력과 다르게 수작업으로 만들지 않는다.
-- `needs_evidence`를 `cloud`로 치환하거나 미완성 상태에서 routed filename을 만들지 않는다.
-- 실행 전 PASS evidence를 요구하거나 routing 중 구현 검증 명령을 실행하지 않는다.
-- PLAN, CODE_REVIEW, archive, complete.log 파일을 직접 생성·수정·이동하지 않는다.
-- 이 routing 스킬은 다음 역할을 시작하지 않는다. 호출 runtime은 handoff 후 반드시 다른 model identity를 배정한다.
+항상 `status`, `evaluation_mode`, `missing_evidence`, `blocked_reason`을 반환한다. `status=routed`이면 다음 필드를 모두 반환한다.
+
+- 공통: `finalizer=finalize-task-policy.sh`, `finalizer_mode=pair`
+- target별: `closures`, `closure_basis`, `capability_gap`, `grade_scores`, `route_basis`, `lane`, `grade`, `filename`
+- build 전용: `base_route_basis`, `large_indivisible_context`, `matched_loop_risk_signatures`, `loop_risk_count`, `review_rework_count`, `evidence_integrity_failure`, `risk_boundary_matched`, `recovery_boundary_matched`
+- review 전용: `route_basis=official-review`, `adapter=codex`, `model=gpt-5.6-sol`, `reasoning_effort=xhigh`
+
+## 완료 확인
+
+- 기존 PLAN 분석만 사용했고 routing-only 탐색을 하지 않았는가
+- split packet마다 독립 평가했는가
+- G01~G08 cloud route가 선택된 `route_basis` 하나와 일치하는 근거를 갖는가
+- G09~G10은 risk/recovery 신호가 있어도 `grade-boundary`를 유지하는가
+- finalizer 출력과 active filename이 일치하는가
+
+## 금지
+
+- unmatched signature의 부재를 찾기 위해 추가 탐색하지 않는다.
+- 이전 lane/G나 finding 개수를 승격 근거로 쓰지 않는다.
+- cloud가 해소할 수 없는 문제를 cloud route로 바꾸지 않는다.
+- PLAN, CODE_REVIEW, archive, complete.log를 직접 수정하지 않는다.

agent-ops/skills/common/finalize-task-routing/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Finalize Task Routing"
-  short_description: "Finalize task lane, grade, and filenames"
-  default_prompt: "Use $finalize-task-routing to determine build/review capability routes while requiring distinct plan, build, and review model identities."
+  short_description: "Route plans once with explicit cloud boundaries"
+  default_prompt: "Use $finalize-task-routing once on the completed plan to select local or cloud from explicit capability, grade, risk, and recovery boundaries."

agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-policy.sh

@@ -0,0 +1,168 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+usage() {
+  printf '%s\n' \
+    'usage:' \
+    '  finalize-task-policy.sh pair <build-base-basis> <large-indivisible-context> <loop-risk-count> <review-rework-count> <evidence-integrity-failure> <build-scope> <build-state> <build-blast> <build-evidence> <build-verification> official-review <review-scope> <review-state> <review-blast> <review-evidence> <review-verification>' \
+    '  build-base-basis: local-fit | capability-gap | grade-boundary' \
+    '  boolean fields: true | false; loop-risk-count: 0..5; review-rework-count: non-negative integer' >&2
+  exit 2
+}
+
+script_dir=$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)
+formatter="$script_dir/finalize-task-route.sh"
+
+field() {
+  local output=$1
+  local key=$2
+  local value
+  value=$(sed -n "s/^${key}=//p" <<<"$output")
+  if [[ -z "$value" ]]; then
+    printf 'missing formatter field: %s\n' "$key" >&2
+    exit 3
+  fi
+  printf '%s\n' "$value"
+}
+
+finalize_build() {
+  local base_basis=$1
+  shift
+  local scores=("$@")
+  local lane
+  local route
+
+  case "$base_basis" in
+    local-fit|capability-gap|grade-boundary)
+      ;;
+    *)
+      usage
+      ;;
+  esac
+
+  BUILD_BASE_ROUTE_BASIS=$base_basis
+  BUILD_RISK_BOUNDARY_MATCHED=false
+  BUILD_RECOVERY_BOUNDARY_MATCHED=false
+  if [[ "$BUILD_LARGE_INDIVISIBLE_CONTEXT" == true ||
+        "$BUILD_LOOP_RISK_COUNT" -ge 4 ]]; then
+    BUILD_RISK_BOUNDARY_MATCHED=true
+  fi
+  if [[ "$BUILD_EVIDENCE_INTEGRITY_FAILURE" == true ||
+        "$BUILD_REVIEW_REWORK_COUNT" -ge 2 ]]; then
+    BUILD_RECOVERY_BOUNDARY_MATCHED=true
+  fi
+
+  if [[ "$base_basis" == capability-gap ]]; then
+    BUILD_ROUTE_BASIS=capability-gap
+  elif [[ "$base_basis" == local-fit &&
+          "$BUILD_RECOVERY_BOUNDARY_MATCHED" == true ]]; then
+    BUILD_ROUTE_BASIS=recovery-boundary
+  elif [[ "$base_basis" == local-fit &&
+          "$BUILD_RISK_BOUNDARY_MATCHED" == true ]]; then
+    BUILD_ROUTE_BASIS=risk-boundary
+  else
+    BUILD_ROUTE_BASIS=$base_basis
+  fi
+
+  if [[ "$BUILD_ROUTE_BASIS" == local-fit ]]; then
+    lane=local
+  else
+    lane=cloud
+  fi
+
+  route=$("$formatter" build "$lane" "${scores[@]}")
+  BUILD_GRADE=$(field "$route" grade)
+  if [[ "$base_basis" == local-fit &&
+        ( "$BUILD_GRADE" == G09 || "$BUILD_GRADE" == G10 ) ]]; then
+    printf 'local-fit is valid only for G01-G08\n' >&2
+    exit 2
+  fi
+  if [[ "$base_basis" == grade-boundary &&
+        "$BUILD_GRADE" != G09 && "$BUILD_GRADE" != G10 ]]; then
+    printf 'grade-boundary is valid only for G09-G10\n' >&2
+    exit 2
+  fi
+  BUILD_LANE=$(field "$route" lane)
+  BUILD_FILENAME=$(field "$route" filename)
+}
+
+finalize_review() {
+  local route_basis=$1
+  shift
+  local scores=("$@")
+  local route
+
+  [[ "$route_basis" == official-review ]] || usage
+  route=$("$formatter" review cloud "${scores[@]}")
+  REVIEW_ROUTE_BASIS=$route_basis
+  REVIEW_LANE=$(field "$route" lane)
+  REVIEW_GRADE=$(field "$route" grade)
+  REVIEW_FILENAME=$(field "$route" filename)
+  REVIEW_ADAPTER=codex
+  REVIEW_MODEL=gpt-5.6-sol
+  REVIEW_REASONING_EFFORT=xhigh
+}
+
+emit_build() {
+  printf 'build_base_route_basis=%s\n' "$BUILD_BASE_ROUTE_BASIS"
+  printf 'build_route_basis=%s\n' "$BUILD_ROUTE_BASIS"
+  printf 'build_large_indivisible_context=%s\n' "$BUILD_LARGE_INDIVISIBLE_CONTEXT"
+  printf 'build_loop_risk_count=%s\n' "$BUILD_LOOP_RISK_COUNT"
+  printf 'build_risk_boundary_matched=%s\n' "$BUILD_RISK_BOUNDARY_MATCHED"
+  printf 'build_review_rework_count=%s\n' "$BUILD_REVIEW_REWORK_COUNT"
+  printf 'build_evidence_integrity_failure=%s\n' "$BUILD_EVIDENCE_INTEGRITY_FAILURE"
+  printf 'build_recovery_boundary_matched=%s\n' "$BUILD_RECOVERY_BOUNDARY_MATCHED"
+  printf 'build_lane=%s\n' "$BUILD_LANE"
+  printf 'build_grade=%s\n' "$BUILD_GRADE"
+  printf 'build_filename=%s\n' "$BUILD_FILENAME"
+}
+
+emit_review() {
+  printf 'review_route_basis=%s\n' "$REVIEW_ROUTE_BASIS"
+  printf 'review_lane=%s\n' "$REVIEW_LANE"
+  printf 'review_grade=%s\n' "$REVIEW_GRADE"
+  printf 'review_filename=%s\n' "$REVIEW_FILENAME"
+  printf 'review_adapter=%s\n' "$REVIEW_ADAPTER"
+  printf 'review_model=%s\n' "$REVIEW_MODEL"
+  printf 'review_reasoning_effort=%s\n' "$REVIEW_REASONING_EFFORT"
+}
+
+mode=${1:-}
+[[ "$mode" == pair && $# -eq 17 ]] || usage
+
+case "$3" in
+  true|false)
+    BUILD_LARGE_INDIVISIBLE_CONTEXT=$3
+    ;;
+  *)
+    usage
+    ;;
+esac
+
+case "$4" in
+  0|1|2|3|4|5)
+    BUILD_LOOP_RISK_COUNT=$4
+    ;;
+  *)
+    usage
+    ;;
+esac
+[[ "$5" =~ ^[0-9]+$ ]] || usage
+BUILD_REVIEW_REWORK_COUNT=$5
+
+case "$6" in
+  true|false)
+    BUILD_EVIDENCE_INTEGRITY_FAILURE=$6
+    ;;
+  *)
+    usage
+    ;;
+esac
+
+finalize_build "$2" "${@:7:5}"
+finalize_review "${12}" "${@:13:5}"
+
+printf 'finalizer=finalize-task-policy.sh\n'
+printf 'finalizer_mode=%s\n' "$mode"
+emit_build
+emit_review

agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-route.sh

@@ -13,8 +13,7 @@ fi
 
 target=$1
 lane=$2
-shift 2
-scores=("$@")
+scores=("${@:3:5}")
 
 case "$target" in
   build)

agent-ops/skills/common/finalize-task-routing/tests/test_finalize_task_routing.py

@@ -0,0 +1,364 @@
+#!/usr/bin/env python3
+from __future__ import annotations
+
+import itertools
+import subprocess
+import unittest
+from pathlib import Path
+
+
+SKILL_DIR = Path(__file__).resolve().parents[1]
+FORMATTER = SKILL_DIR / "scripts" / "finalize-task-route.sh"
+POLICY_FINALIZER = SKILL_DIR / "scripts" / "finalize-task-policy.sh"
+PLAN_SKILL = SKILL_DIR.parent / "plan" / "SKILL.md"
+COMMON_SKILLS_DIR = SKILL_DIR.parent
+COMMON_RULES_DIR = SKILL_DIR.parents[2] / "rules" / "common"
+
+
+GRADE_VECTORS = {
+    1: (0, 0, 0, 0, 0),
+    2: (2, 0, 0, 0, 0),
+    3: (2, 1, 0, 0, 0),
+    4: (2, 2, 0, 0, 0),
+    5: (2, 2, 1, 0, 0),
+    6: (2, 2, 2, 0, 0),
+    7: (2, 2, 2, 1, 0),
+    8: (2, 2, 2, 2, 0),
+    9: (2, 2, 2, 2, 1),
+    10: (2, 2, 2, 2, 2),
+}
+
+
+def run(
+    script: Path, *args: object, check: bool = True
+) -> subprocess.CompletedProcess[str]:
+    return subprocess.run(
+        [str(script), *(str(arg) for arg in args)],
+        check=check,
+        capture_output=True,
+        text=True,
+        timeout=5,
+    )
+
+
+def fields(stdout: str) -> dict[str, str]:
+    return dict(line.split("=", 1) for line in stdout.splitlines())
+
+
+def expected_build_route(basis: str, grade: int) -> tuple[str, bool]:
+    if basis == "local-fit":
+        return "local", grade <= 8
+    if basis == "capability-gap":
+        return "cloud", True
+    return "cloud", grade >= 9
+
+
+def pair_args(
+    build_basis: str,
+    build_grade: int,
+    review_grade: int,
+    large_context: str = "false",
+    risk_count: int = 0,
+    review_rework_count: int = 0,
+    evidence_integrity: str = "false",
+    review_basis: str = "official-review",
+) -> tuple[object, ...]:
+    return (
+        "pair",
+        build_basis,
+        large_context,
+        risk_count,
+        review_rework_count,
+        evidence_integrity,
+        *GRADE_VECTORS[build_grade],
+        review_basis,
+        *GRADE_VECTORS[review_grade],
+    )
+
+
+class FinalizeTaskRoutingTests(unittest.TestCase):
+    def assert_route(
+        self,
+        result: dict[str, str],
+        target: str,
+        basis: str,
+        lane: str,
+        grade: int,
+    ) -> None:
+        prefix = "PLAN" if target == "build" else "CODE_REVIEW"
+        self.assertEqual(result[f"{target}_route_basis"], basis)
+        self.assertEqual(result[f"{target}_lane"], lane)
+        self.assertEqual(result[f"{target}_grade"], f"G{grade:02d}")
+        self.assertEqual(
+            result[f"{target}_filename"], f"{prefix}-{lane}-G{grade:02d}.md"
+        )
+
+    def test_common_workflows_do_not_depend_on_project_runtime(self) -> None:
+        contract_roots = (
+            COMMON_RULES_DIR / "rules-roadmap.md",
+            COMMON_SKILLS_DIR / "create-roadmap",
+            COMMON_SKILLS_DIR / "update-roadmap",
+            COMMON_SKILLS_DIR / "sync-milestone-workstate",
+            COMMON_SKILLS_DIR / "complete-milestone",
+            COMMON_SKILLS_DIR / "plan",
+            COMMON_SKILLS_DIR / "code-review",
+            COMMON_SKILLS_DIR / "refine-local-plans",
+            COMMON_SKILLS_DIR / "finalize-task-routing",
+        )
+        contract_files: list[Path] = []
+        for root in contract_roots:
+            candidates = (root,) if root.is_file() else root.rglob("*")
+            contract_files.extend(
+                path
+                for path in candidates
+                if path.is_file()
+                and path.suffix in {".md", ".sh", ".yaml"}
+                and "tests" not in path.parts
+            )
+
+        forbidden = (
+            "agent-ops/skills/project/",
+            "orchestrate-agent-task-loop",
+            "WORK_LOG.md",
+            "work_log_",
+            "dispatch.py",
+        )
+        for path in sorted(contract_files):
+            text = path.read_text(encoding="utf-8")
+            for needle in forbidden:
+                with self.subTest(path=path, needle=needle):
+                    self.assertNotIn(needle, text)
+
+    def test_request_to_worker_contract_is_ordered_and_consistent(self) -> None:
+        routing_skill = (SKILL_DIR / "SKILL.md").read_text(encoding="utf-8")
+        plan_skill = PLAN_SKILL.read_text(encoding="utf-8")
+
+        self.assertIn("`matched_loop_risk_signatures`", routing_skill)
+        self.assertIn("`temporal_state`", routing_skill)
+        self.assertNotIn("`ordered_transitions`", routing_skill)
+        self.assertIn("routing 때문에 source/test/log를 다시 읽지", routing_skill)
+        self.assertIn("첫 번째로 일치하는 규칙", routing_skill)
+        self.assertIn("이미 cloud인 capability/grade basis를 덮어쓰지 않는다", routing_skill)
+        self.assertIn("review gap만 기록; build basis에는 영향 없음", routing_skill)
+
+        markers = (
+            "**Assess split boundaries once**",
+            "**Derive routing signals once**",
+            "## Step 3 - Finalize Task Routing",
+        )
+        positions = [plan_skill.index(marker) for marker in markers]
+        self.assertEqual(positions, sorted(positions))
+        self.assertNotIn("**Extract the request contract**", plan_skill)
+        self.assertNotIn("`요청 계약`", plan_skill)
+        self.assertIn("reuse the values already validated and appended", plan_skill)
+        policy_script = POLICY_FINALIZER.read_text(encoding="utf-8")
+        self.assertNotIn("build_risk_triggered", policy_script)
+        self.assertNotIn("boundary_triggered", policy_script)
+
+    def test_formatter_grade_and_filename_matrix(self) -> None:
+        for target, lane, grade in itertools.product(
+            ("build", "review"), ("local", "cloud"), range(1, 11)
+        ):
+            with self.subTest(target=target, lane=lane, grade=grade):
+                result = fields(run(FORMATTER, target, lane, *GRADE_VECTORS[grade]).stdout)
+                prefix = "PLAN" if target == "build" else "CODE_REVIEW"
+                self.assertEqual(result["grade"], f"G{grade:02d}")
+                self.assertEqual(
+                    result["filename"], f"{prefix}-{lane}-G{grade:02d}.md"
+                )
+
+    def test_formatter_invalid_inputs_are_rejected(self) -> None:
+        valid = list(GRADE_VECTORS[4])
+        invalid_cases: list[tuple[object, ...]] = [
+            ("deploy", "local", *valid),
+            ("build", "hybrid", *valid),
+            ("build", "local", *valid[:-1]),
+            ("build", "local", *valid, 1),
+        ]
+        for index in range(5):
+            scores = valid.copy()
+            scores[index] = 3
+            invalid_cases.append(("build", "local", *scores))
+        for args in invalid_cases:
+            with self.subTest(args=args):
+                self.assertEqual(run(FORMATTER, *args, check=False).returncode, 2)
+
+    def test_pair_policy_validates_each_build_basis_and_grade(self) -> None:
+        for basis, grade in itertools.product(
+            ("local-fit", "capability-gap", "grade-boundary"), range(1, 11)
+        ):
+            with self.subTest(basis=basis, grade=grade):
+                completed = run(
+                    POLICY_FINALIZER,
+                    *pair_args(basis, grade, 1),
+                    check=False,
+                )
+                lane, valid = expected_build_route(basis, grade)
+                if not valid:
+                    self.assertEqual(completed.returncode, 2)
+                    continue
+                self.assertEqual(completed.returncode, 0, completed.stderr)
+                result = fields(completed.stdout)
+                self.assertEqual(result["finalizer_mode"], "pair")
+                self.assert_route(result, "build", basis, lane, grade)
+
+    def test_official_review_keeps_grade_and_fixes_execution_target(self) -> None:
+        for grade in range(1, 11):
+            with self.subTest(grade=grade):
+                result = fields(
+                    run(POLICY_FINALIZER, *pair_args("local-fit", 1, grade)).stdout
+                )
+                self.assert_route(
+                    result, "review", "official-review", "cloud", grade
+                )
+                self.assertEqual(result["review_adapter"], "codex")
+                self.assertEqual(result["review_model"], "gpt-5.6-sol")
+                self.assertEqual(result["review_reasoning_effort"], "xhigh")
+
+    def test_low_grade_cloud_requires_capability_gap_basis(self) -> None:
+        rejected = run(
+            POLICY_FINALIZER,
+            *pair_args("grade-boundary", 4, 4),
+            check=False,
+        )
+        self.assertEqual(rejected.returncode, 2)
+
+        accepted = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args("capability-gap", 4, 4),
+            ).stdout
+        )
+        self.assert_route(accepted, "build", "capability-gap", "cloud", 4)
+
+    def test_loop_risk_boundary_routes_four_or_more_signatures_to_cloud(self) -> None:
+        for risk_count in range(6):
+            with self.subTest(risk_count=risk_count):
+                result = fields(
+                    run(
+                        POLICY_FINALIZER,
+                        *pair_args("local-fit", 7, 6, risk_count=risk_count),
+                    ).stdout
+                )
+                self.assertEqual(result["build_loop_risk_count"], str(risk_count))
+                expected_basis = "risk-boundary" if risk_count >= 4 else "local-fit"
+                expected_lane = "cloud" if risk_count >= 4 else "local"
+                self.assertEqual(result["build_base_route_basis"], "local-fit")
+                self.assert_route(result, "build", expected_basis, expected_lane, 7)
+
+    def test_large_indivisible_context_routes_to_cloud(self) -> None:
+        result = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args("local-fit", 4, 4, large_context="true"),
+            ).stdout
+        )
+        self.assertEqual(result["build_risk_boundary_matched"], "true")
+        self.assert_route(result, "build", "risk-boundary", "cloud", 4)
+
+    def test_review_rework_and_evidence_integrity_route_to_cloud(self) -> None:
+        one_rework = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args("local-fit", 4, 4, review_rework_count=1),
+            ).stdout
+        )
+        self.assert_route(one_rework, "build", "local-fit", "local", 4)
+
+        two_reworks = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args("local-fit", 4, 4, review_rework_count=2),
+            ).stdout
+        )
+        self.assert_route(
+            two_reworks, "build", "recovery-boundary", "cloud", 4
+        )
+
+        evidence_failure = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args("local-fit", 4, 4, evidence_integrity="true"),
+            ).stdout
+        )
+        self.assert_route(
+            evidence_failure, "build", "recovery-boundary", "cloud", 4
+        )
+
+        recovery_over_risk = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args(
+                    "local-fit",
+                    4,
+                    4,
+                    large_context="true",
+                    review_rework_count=2,
+                ),
+            ).stdout
+        )
+        self.assertEqual(recovery_over_risk["build_base_route_basis"], "local-fit")
+        self.assert_route(
+            recovery_over_risk, "build", "recovery-boundary", "cloud", 4
+        )
+
+    def test_grade_boundary_is_not_relabelled_by_escalation_signals(self) -> None:
+        result = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args(
+                    "grade-boundary",
+                    9,
+                    4,
+                    large_context="true",
+                    risk_count=5,
+                    review_rework_count=2,
+                    evidence_integrity="true",
+                ),
+            ).stdout
+        )
+        self.assertEqual(result["build_base_route_basis"], "grade-boundary")
+        self.assertEqual(result["build_risk_boundary_matched"], "true")
+        self.assertEqual(result["build_recovery_boundary_matched"], "true")
+        self.assert_route(result, "build", "grade-boundary", "cloud", 9)
+
+    def test_capability_gap_has_precedence_over_other_cloud_triggers(self) -> None:
+        result = fields(
+            run(
+                POLICY_FINALIZER,
+                *pair_args(
+                    "capability-gap",
+                    4,
+                    4,
+                    large_context="true",
+                    risk_count=5,
+                    review_rework_count=2,
+                    evidence_integrity="true",
+                ),
+            ).stdout
+        )
+        self.assertEqual(result["build_base_route_basis"], "capability-gap")
+        self.assert_route(result, "build", "capability-gap", "cloud", 4)
+
+    def test_policy_invalid_inputs_are_rejected(self) -> None:
+        valid = GRADE_VECTORS[4]
+        invalid_cases = (
+            ("pair", "local-fit", "unknown", 0, 0, "false", *valid, "official-review", *valid),
+            ("pair", "local-fit", "false", 6, 0, "false", *valid, "official-review", *valid),
+            ("pair", "local-fit", "false", 0, -1, "false", *valid, "official-review", *valid),
+            ("pair", "local-fit", "false", 0, 0, "unknown", *valid, "official-review", *valid),
+            ("pair", "local", "false", 0, 0, "false", *valid, "official-review", *valid),
+            ("pair", "local-fit", "false", 0, 0, "false", *valid, "cloud", *valid),
+            ("build", "local-fit", "false", 0, 0, "false", *valid),
+            ("pair", "local-fit", "false", 0, 0, "false", *valid, "official-review", *valid[:-1]),
+        )
+        for args in invalid_cases:
+            with self.subTest(args=args):
+                self.assertEqual(
+                    run(POLICY_FINALIZER, *args, check=False).returncode,
+                    2,
+                )
+
+
+if __name__ == "__main__":
+    unittest.main()

agent-ops/skills/common/plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: plan
-description: "Analyze the repository and write routed PLAN/CODE_REVIEW pairs for initial work or archived WARN/FAIL findings. The plan model only plans, runtime gates dependencies, and a separate implementation model consumes only ready pairs. Plan, implementation, and review must use different model identities."
+description: Analyze the current repository and write a detailed PLAN-{build_lane}-GNN.md plus CODE_REVIEW-{review_lane}-GNN.md stub for implementation work. Use for every feature, refactor, bug fix, and code-review WARN/FAIL follow-up that enters the plan-code-review loop. Every initial or follow-up pair must run finalize-task-routing after analysis and before routed filenames are chosen. Milestone-linked work uses a reserved m-prefixed task group so runtime can route PASS completion events to update-roadmap.
 ---
 
 # Plan
@@ -10,41 +10,35 @@ description: "Analyze the repository and write routed PLAN/CODE_REVIEW pairs for
 Create the planning artifacts for the implementation loop:
 
 ```text
-plan model -> routed pair -> runtime dependency gate -> implementation model -> review-ready -> review model
-    ^                                                                                |
-    +-------------------------------- plan-ready -------------------------------------+
+plan skill -> analysis -> finalize-task-routing -> PLAN-{build_lane}-GNN.md + CODE_REVIEW-{review_lane}-GNN.md stub
+implementation -> code changes + filled implementation evidence in CODE_REVIEW-{review_lane}-GNN.md
+code-review skill -> verdict + archive, complete.log and task-directory archive move, USER_REVIEW.md, or mandatory plan-skill follow-up
+runtime -> for m-prefixed PASS completion events, state check and optional update-roadmap call
 ```
 
-After writing the pair, report `implementation-ready` only for a task whose encoded predecessors are satisfied; report `dependency-waiting` for an unsatisfied dependent task. Then stop.
+`code-review` may stop the automatic loop with `USER_REVIEW.md` only when a selected Milestone `구현 잠금 > 결정 필요` item blocks implementation. Repeated non-PASS reviews, test environment blockers, external environment/secret/service setup, generic scope changes, and verification evidence gaps are not user-review reasons by themselves; they should become normal follow-up plans or unresolved verification evidence. Plan creation after `USER_REVIEW.md` requires the linked Milestone decision to be resolved. If the decision closes the task as complete/PASS, code-review resolves `USER_REVIEW.md`, writes `complete.log`, and archives the task instead of creating a new plan.
 
-Role completion means leaving the routed PLAN/CODE_REVIEW pair and its readiness result; it does not include implementation or worker scheduling.
-
-`code-review` writes `USER_REVIEW.md` only when a selected Milestone `구현 잠금 > 결정 필요` item blocks implementation. Other blockers become `plan-ready` findings.
-
-Plan, implementation, and review use different model identities; separate agents using the same model do not satisfy this rule.
+The plan file and review stub must be self-sufficient for implementation agents that do not read this skill. Implementing agents fill the active review's implementation evidence. They never decide whether user review is needed, write a user-review request, ask the user for a decision, create `USER_REVIEW.md`, or modify runtime-owned artifacts; those control-plane responsibilities belong to the official code-review skill and runtime.
 
 ## Workflow Contract
 
 This skill intentionally uses routed active files under an active task directory as the state protocol. Do not change this directory or filename contract unless the paired code-review skill is updated together.
 
-Role boundary:
+Invocation modes:
 
-- The plan model may inspect source/tests but must not edit them or run implementation verification.
-- Write only PLAN/CODE_REVIEW files and required planning metadata.
-- Do not implement, review, invoke `code-review`, or start another agent.
-- Record the runtime-provided Plan model identity in both files. It is immutable for that pair; do not infer it from lane/G or agent name.
-- Runtime, not the implementation worker, resolves encoded predecessor `complete.log` evidence and starts only `implementation-ready` tasks. The worker never searches task archives, interprets dependency state, or schedules siblings.
+- `write` is the default for initial plans and explicit replans. After routing, this skill archives any prior active pair and writes the new pair.
+- `prepare-follow-up` is used only when code-review has appended WARN/FAIL but has not archived the active pair. This skill completes analysis, final routing, and exact PLAN/review-stub rendering in memory without mutating repository files. It returns `prepared_plan`, `prepared_review`, their routed basenames, the current pair's predicted archive names/numbers, and the post-archive log counts used by the new pair.
+- Both modes execute the same mandatory Step 3. `prepare-follow-up` is not a route-only shortcut.
 
 Task path terms:
 
 - `{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 an indexed executable sibling inside grouped work and follows the naming rules below, such as `01_core` or `02+01_db`.
+- `{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 one-off task or `{task_group}/{subtask_dir}` for a grouped task.
+- `{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.
 - A single-plan task stores active files directly under `agent-task/{task_group}/`.
-- Grouped work stores one active pair under each `agent-task/{task_group}/{subtask_dir}/`; the parent `agent-task/{task_group}/` must not contain active plan/review files.
-- Initial planning may create immediate sibling pairs. A `plan-ready` follow-up keeps the exact existing task path and writes one replacement pair.
+- Split work stores active files under `agent-task/{task_group}/{subtask_dir}/`; the parent `agent-task/{task_group}/` contains no active plan/review files.
 
 Filename rules:
 
@@ -54,30 +48,28 @@ Filename rules:
 - `GNN` is a two-digit capability grade from `G01` to `G10`; the runtime maps lane+grade to current models externally.
 - Lane, grade, and both canonical basenames come only from `agent-ops/skills/common/finalize-task-routing/SKILL.md`.
 
-Generated pair boundary:
+Role boundary rules:
 
-- Runtime records the Implementation identity and verifies every encoded predecessor before dispatch. An unsatisfied dependent pair remains `dependency-waiting`.
-- The implementation model receives only a ready pair, edits source/tests, fills implementation-owned review sections, then reports `review-ready` and stops. It does not inspect task/archive state.
-- The review model judges and archives the pair. On WARN/FAIL, orchestration dispatches a different plan model; no model performs another role itself.
+- Implementing agents fill implementation-owned `CODE_REVIEW-*-G??.md` sections, keep active files in place, and report ready for review.
+- If implementation cannot continue, implementing agents record the exact blocker, attempted commands/output, and resume condition only in `검증 결과` or `계획 대비 변경 사항`, then leave the active files in place for official review.
+- During implementation, do not ask the user directly, present choices, call user-input tools, or create control-plane stop files. The official reviewer owns all next-state classification.
+- Required UI evidence capture that needs a user-owned device, emulator, permission, secret, or interactive access unavailable to the agent is a verification blocker, not a user-review reason by itself. Record attempted commands and blocker evidence in `검증 결과` or `계획 대비 변경 사항` so code-review can write a normal follow-up or unresolved verification report.
+- Finalization (`코드리뷰 결과`, plan/review log rename, `complete.log`, task artifact archive moves, review-only checklist) is code-review-skill only.
 
-Planning-time verification boundary:
+Split decision policy:
 
-- This skill designs verification; build executes it and records actual output, and review validates the evidence and reruns commands required by its review scope.
-- During planning, use repository files, manifests, scripts, workflows, rules, and already-recorded evidence only. Do not refresh existing evidence.
-- Do not run compile, build, test, lint, source formatter, smoke/E2E, live/remote checks, package installation, dependency download, or cache warming while planning.
-- Missing implementation-time output is not a planning evidence gap. Record the command, expected result, assumptions, and responsible build/review stage instead.
+- Split only by behavior/contract boundaries whose children each have a stable intermediate contract and deterministic PASS verification.
+- Keep every production change with its required tests; use a test-only child only for additional integration evidence.
+- Keep one plan when the work is compact or split would sever one correctness/transaction invariant. Never split to lower lane, grade, context, or signature count.
+- If the existing analysis cannot prove that children independently PASS, keep the atomic work together and route it as one packet.
+- Record either each child's contract/dependency or the invariant that makes one plan indivisible.
 
-Shallow sibling extraction policy:
+Split gates:
 
-- Treat a Milestone Epic or other broad request as a selection boundary. Select exactly one next executable Milestone Task or non-roadmap candidate; do not batch every Task in the Epic.
-- Before loading implementation files in depth, use the selected Task, roadmap/SDD, repository structure, and targeted symbol/test inventory to make one shallow splitability check.
-- If the selected Task has at least two clearly separable implementation or verification chunks and keeping them together would make local context unnecessarily broad, materialize the minimum complete set of immediate sibling tasks. Otherwise keep one task.
-- Create one routed PLAN/CODE_REVIEW pair for every materialized sibling. Do not create empty directories, placeholder files, index-only reservations, decomposition caches, or manifests.
-- Split only one level. Do not recursively subdivide siblings or expand into other Milestone Tasks. Reuse the shallow inventory and load only each sibling's required source/test regions.
-- Account for the selected Task's required scope across the sibling set. Do not hide a known required chunk as deferred prose. Irreducible scope that has no coherent boundary remains one task and is handled by final cloud routing.
-- Declare each sibling's intended write set and shared mutable state. Siblings may run in parallel only when their write sets are disjoint and they have no state, ordering, or contract-handoff dependency; read-only overlap is allowed.
-- If write sets overlap or one sibling consumes another's state or contract, merge them or encode the producer as a `+` predecessor. Unknown overlap is not parallel-safe.
-- Record the full immediate sibling set and real dependencies in every sibling plan. Approximate but bounded fan-out is preferred over exhaustive decomposition.
+- Separate foundation from rollout only when the foundation preserves compatibility and independently passes.
+- Split domains, verification profiles, or risk slices only when each independently passes.
+- Split work that can produce a useful earlier `complete.log` without invalid intermediate state.
+- Isolate mobile/UI/external verification that can block otherwise completed implementation.
 
 Task directory naming rules:
 
@@ -85,71 +77,60 @@ Task directory naming rules:
 - 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-roadmap/phase/*/milestones/<milestone-slug>.md`; archive paths are not target candidates.
-- New Milestone/Epic task extraction creates either one indexed `{subtask_dir}` or the immediate sibling set selected by the shallow split.
-- Choose the next two-digit index after all active sibling indices and archived sibling directory basenames for the same task group. Read archive basenames only; do not read archived file contents. Allocate consecutive indices only to siblings that will receive routed pairs in this invocation.
-- Each indexed directory owns exactly one normal active plan file and one normal active review stub. The index increases for sorting but is not a serial execution dependency.
+- 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.
+- Assign new sibling indices in topological dependency order so every producer precedes its consumers. For ties, keep the planned sibling order; assign each task the lowest collision-free two-digit index greater than all of its predecessors.
+- Before writing the pairs, verify that the sibling dependency graph has no cycle and every predecessor index is lower than its consumer index. Skip an index only when it is not greater than an unchanged existing predecessor or is already occupied by an active/archived sibling.
 - Use `NN_{subtask_name}` for a task with no runtime dependencies, e.g. `01_core`, `04_docs`, `05_ui`.
 - Use `NN+PP[,QQ...]_{subtask_name}` for a task that depends on earlier task indices, e.g. `02+01_db`, `03+01,02_api`, `06+05_integration`.
 - Valid independent pattern: `^[0-9]{2}_[a-z0-9_]+$`.
 - Valid dependent pattern: `^[0-9]{2}\+[0-9]{2}(,[0-9]{2})*_[a-z0-9_]+$`.
-- `NN`, `PP`, and `QQ` are two-digit indices. Every predecessor index after `+` must be lower than `NN` and must refer to a sibling indexed task directory under the same `{task_group}`.
+- `NN`, `PP`, and `QQ` are two-digit indices. Every predecessor index after `+` must be lower than `NN` and must refer to a sibling multi-plan subtask directory under the same `{task_group}`.
 - The first `_` after the index or dependency list starts `{subtask_name}`. `{subtask_name}` stays short snake_case and may contain additional underscores.
-- Scheduling contract: a runtime that consumes task directories reads only `{subtask_dir}`; `_` means `depends_on=[]`, and `+` means `depends_on` is the comma-separated index list between `+` and the first `_`. Before worker dispatch, runtime requires one unambiguous matching predecessor `complete.log` for every encoded index. This skill records dependencies and readiness but does not start or schedule workers.
-- An independent `NN_...` name asserts that its write set and shared mutable state do not conflict with concurrently runnable siblings. Any write/state/ordering/contract conflict must appear as `NN+PP[,QQ...]_...` or be merged into one sibling.
+- Runtime scheduling reads only the `{subtask_dir}` name: `_` means `depends_on=[]`; `+` means `depends_on` is the comma-separated index list between `+` and the first `_`.
 - Subtask directory names are the source of truth for runtime dependencies. Do not hide extra dependencies only in the plan body, and do not create a bare `NN+{subtask_name}` without predecessor indices.
 - A predecessor index is satisfied by a `complete.log` for the matching predecessor subtask under the same `{task_group}`. Check active siblings first, then matching archived subtasks across all archive month folders. This is a narrow exception to the normal archive skip rule: read only candidate predecessor `complete.log` files needed to prove split dependency completion.
 - For predecessor index `PP`, the only valid active lookup candidates are `agent-task/{task_group}/PP_*/complete.log` and `agent-task/{task_group}/PP+*/complete.log`.
 - For predecessor index `PP`, the only valid archive lookup candidates are `agent-task/archive/*/*/{task_group}/PP_*/complete.log` and `agent-task/archive/*/*/{task_group}/PP+*/complete.log`.
 - Archive lookup matches the predecessor index at the start of the archived subtask directory name, such as `01_...` or `01+...`, under the same `{task_group}`. If multiple candidates match one predecessor index, do not choose by guess; record the ambiguity and require a concrete task path or runtime selection.
 - Do not treat an archived predecessor as the active task to edit. Archive lookup is only for dependency satisfaction before writing or implementing a dependent split plan.
-- `01_core`, `02+01_edge_integration`, and `03+01_node_integration` express two integrations that may run in parallel after `01_core` completes. A shallow split may create all three routed sibling pairs in one invocation.
-- Preserve task group and subtask directory names verbatim; do not normalize, reinterpret, or choose execution order by agent judgment.
+- Example: split a refactoring common core plus two app integrations under `agent-task/refactoring/` as `01_core`, `02+01_edge_integration`, `03+01_node_integration`. Both integrations depend only on `01_core` and may run in parallel after `01_core` has `complete.log`.
+- Example: split three sequential tasks under one task group as `01_schema`, `02+01_migration`, `03+02_api`.
+- Example: split independent docs/UI plus an integration under one task group as `01_core`, `02+01_db`, `03+02_api`, `04_docs`, `05_ui`, `06+05_integration`; `01_core`, `04_docs`, and `05_ui` can start together, and `06+05_integration` waits only for `05_ui`.
+- After a pair is written, preserve its task group and subtask directory name verbatim. Only an explicit `refine-local-plans` run may rename eligible unstarted local siblings by its dependency-order rules.
 
 Final routing boundary:
 
-- Do not estimate, inherit, or write lane/G while analyzing. Keep the task `unrouted` until plan scope, split, verification design, ownership, decision facts, and available existing evidence are complete.
-- Execute `agent-ops/skills/common/finalize-task-routing/SKILL.md` for both `build` and `review` after analysis. Its routed outputs are the only source for active PLAN/CODE_REVIEW filenames.
-- Apply this boundary independently to every first-pass sibling and to each review WARN/FAIL or USER_REVIEW replan.
-- A previous loop's lane, grade, score, rationale, and filename are quarantined. Prior code paths, recorded command output, and review findings may be carried as raw evidence after confirming their path and revision relevance without rerunning commands.
-- `needs_evidence` requires missing static planning facts and a fresh full routing run. It must not trigger implementation verification. A first-pass `blocked` may prevent loop entry; once a selected review loop is active, a valid Milestone-lock decision routes to `USER_REVIEW.md`, while every other limitation becomes a routed follow-up with its blocker evidence and deterministic release condition.
-- If plan facts change after routing, invalidate both target results and run final routing again before writing files.
-- Treat non-behavioral review artifact drift and obvious non-behavioral source nits as current-scope evidence; they do not bypass final routing.
+- Keep the task `unrouted` until split, PLAN body, verification, evidence, ownership, and decisions are complete.
+- Treat each final in-memory PLAN as its build packet. Derive `large_indivisible_context` and positive loop-risk signatures once from analysis already required to write that PLAN; do not create a separate packet summary or search for negative risk evidence.
+- Execute `finalize-task-routing` once for build/review and use only its lane/G/filenames. Apply it to first-pass, follow-up, USER_REVIEW replan, and each split subtask independently.
+- Quarantine previous lane/G/score/rationale. Carry only revalidated code, findings, command output, `review_rework_count`, and `evidence_integrity_failure`.
+- `needs_evidence` names genuinely missing closure evidence; `blocked` stops file creation. Changed plan facts invalidate the route.
+- Only `refine-local-plans` may retain an unstarted local pair's route while splitting it into strict-subset local children.
 
 Directory states:
 
 | State | Meaning |
 |-------|---------|
 | `PLAN-*-G??.md` only | Invalid; plan skill always writes both active files |
-| `STAGED_BATCH.md` | Multi-sibling write transaction; finish every listed sibling before reporting |
-| `STAGED_PLAN.md` only | Pair write interrupted; render the matching staged review from this fixed plan without rerouting |
-| `STAGED_PLAN.md` + `STAGED_CODE_REVIEW.md` | Pair is fully staged; verify and promote both without rerouting |
-| unstarted active pair + staged replacement | Explicit replan transaction; archive only the old pair, then promote the staged pair |
-| one old active member + its archived counterpart + staged replacement | Interrupted replan archive; finish the old archive, then promote the staged pair |
-| routed PLAN plus matching `STAGED_CODE_REVIEW.md` | Partial promotion; promote the staged review and do not rewrite the PLAN |
-| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` stub, dependencies satisfied | `implementation-ready`; a different implementation model consumes the pair |
-| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` stub, dependencies unsatisfied | `dependency-waiting`; runtime does not dispatch the implementation model |
-| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md`, dependencies satisfied | `review-ready`; a different review model consumes the pair |
-| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md`, dependencies unsatisfied | `dependency-waiting`; runtime does not dispatch the review model |
-| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with appended verdict | Review finalization pending; the plan model must not modify it |
-| `complete.log` + `*.log` files | Task complete (PASS or user-review-resolved PASS), with exact final archive/event metadata fixed before the final task-directory archive move |
-| `USER_REVIEW.md` + `*.log` files | Linked Milestone decision is required before planning |
-| Highest numeric-suffix matching `user_review_*.log` has `## 상태` value `RESOLVED` and `해소 결과 > 결과` value `REPLAN`, with no active pair | Resolved user-review `plan-ready`; create one follow-up pair from that log and its referenced archived pair |
+| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` stub | Implementation is pending/in progress |
+| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md` without verdict | Ready for code-review skill |
+| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with appended verdict | Review finalization is pending. Continue only when code-review invokes `prepare-follow-up`; `write` mode must not overwrite this state. |
+| `complete.log` + `*.log` files | Task complete (PASS or user-review-resolved PASS), before final task-directory archive move |
+| `USER_REVIEW.md` + `*.log` files | Automatic loop stopped; linked Milestone lock decision must be resolved before creating another plan |
 | `agent-task/archive/YYYY/MM/{task_name}/complete.log` + `*.log` files | Archived completed task path (PASS or user-review-resolved PASS); not active |
-| Matching archived plan/review logs with WARN/FAIL | `plan-ready`; create one follow-up pair from those exact logs |
+| Only `*.log` files (no `complete.log`) | Inspect the newest review log. A verdict with no required next state is post-archive finalization pending; otherwise the task is terminated mid-loop or abandoned. |
 
 ## Step 1 - Determine Task
 
-If the user names an exact existing task path for continuation or replan, use it. Do not treat a Milestone/Epic id or title as an exact task path.
-
-Any plan-creation request scoped to a Milestone, Epic, or other broad roadmap item enters new-task extraction mode unless it selects an existing indexed task. Select one Milestone Task inside the requested Epic before applying sibling extraction.
+If the user names the task explicitly, use that task group or task path.
 
 Otherwise, find active plan files with both globs, excluding `agent-task/archive/**`:
 
 - `agent-task/*/PLAN-*-G??.md`
 - `agent-task/*/*/PLAN-*-G??.md`
 
-Find `agent-task/*/STAGED_BATCH.md`, then `STAGED_PLAN.md` and `STAGED_CODE_REVIEW.md` with the task-depth globs before classifying active plans or selecting a new task. A staged state wins selection and resumes every listed sibling at Steps 5-6 with the recorded Plan model identity, without rerouting or a new task path. Do not apply active-pair stop rules until that transaction finishes.
-
 Also note active user-review stops, excluding `agent-task/archive/**`:
 
 - `agent-task/*/USER_REVIEW.md`
@@ -157,25 +138,17 @@ Also note active user-review stops, excluding `agent-task/archive/**`:
 
 | Result | Action |
 |--------|--------|
-| Exactly one | Select it, then apply the active-state guards below |
+| Exactly one | Continue that task |
 | None | Create a new task only for a feature/refactor/fix/follow-up that belongs in this workflow |
 | Multiple | If the user/runtime named a task group, task path, or subtask directory that identifies exactly one active plan, use it. Otherwise list paths and stop with an ambiguity report; do not choose by agent judgment and do not create a user-review request for routing ambiguity. |
 
-For an exact task path with no active pair, inspect durable evidence in this order:
+The routed plan file is the loop entry point. A missing active plan normally means only that no plan has been started for a new task; do not create task files for casual analysis, status, or review requests unless the user explicitly asks for a plan.
 
-1. If the highest numeric-suffix matching `user_review_*.log` has `## 상태` value `RESOLVED` and `해소 결과 > 결과` value `REPLAN`, require its referenced archived plan/review pair, treat all three files as `plan-ready` evidence, use the next monotonic plan number, and refuse the handoff if the current Plan model identity matches either forbidden identity recorded in the resolution log.
-2. Otherwise accept follow-up planning only when the highest numeric-suffix matching archived review log is WARN/FAIL, its plan log is identifiable, and the archived review does not contain a valid unresolved Milestone-lock user-review gate. Treat that pair as `plan-ready` evidence, use the next monotonic plan number, and refuse the handoff if the current Plan model identity matches the archived Implementation or Review identity.
-3. If the archived review contains a valid unresolved user-review gate and no matching resolved log exists, return the task to code-review recovery so it writes or restores `USER_REVIEW.md`; do not plan.
+If no active plan exists but one or more `USER_REVIEW.md` files exist, report that the linked Milestone decision is required and list the paths unless one path is explicitly selected for resolution or replanning. If a selected active task directory contains `USER_REVIEW.md`, read it before planning. Do not write a new follow-up plan unless the linked Milestone decision has been resolved or the new plan explicitly replans around that recorded decision. When planning resumes from `USER_REVIEW.md`, archive it to `user_review_N.log` in the same task directory before writing the new active plan/review pair, and record the resolved decision in the new plan `배경` or `분석 결과`.
 
-If `USER_REVIEW.md` exists, do not plan until a review model resolves and archives it.
+If a selected task directory contains both `USER_REVIEW.md` and active `PLAN-*-G??.md` or `CODE_REVIEW-*-G??.md`, report an inconsistent loop state and do not overwrite either state until a later explicit command selects either user-review resolution or the active plan/review path.
 
-If a selected task directory contains both `USER_REVIEW.md` and an active `PLAN-*-G??.md` or `CODE_REVIEW-*-G??.md`, do not overwrite either state or ask the user to choose between files. Treat a valid unresolved `USER_REVIEW.md` as the terminal state; otherwise return the exact paths and provenance to code-review finalization/recovery so it can continue from evidence rather than waiting for another instruction.
-
-If an active review already has a verdict, leave it unchanged and report that review finalization is required.
-
-Before reporting readiness for an indexed active pair, validate its basename against `NN_{subtask_name}` or `NN+PP[,QQ...]_{subtask_name}` and require every predecessor to be lower than `NN`. Return a malformed pair for Plan path migration; never dispatch it or report it as ready.
-
-If the selected active pair is an unfilled stub, resolve its encoded predecessor evidence. Report `implementation-ready` only when all predecessors are satisfied; otherwise report `dependency-waiting`. Replan it only when the user explicitly requests replan before implementation starts. If its implementation-owned sections are filled and it has no verdict, report `review-ready` and stop.
+If the selected review already has an appended verdict, accept it only in `prepare-follow-up` mode invoked by code-review. In every other mode, leave the pair unchanged and report that code-review finalization must resume.
 
 로드맵 확인:
 
@@ -199,51 +172,60 @@ If the selected active pair is an unfilled stub, resolve its encoded predecessor
 - 제품 선택, 우선순위 결정처럼 에이전트가 확정할 수 없는 항목은 구현 계획의 실행 checklist로 쓰지 않는다. 그런 항목이 남아 있으면 plan 생성을 멈추고 `구현 잠금 > 결정 필요`로 분리한다.
 - 기능 Task에 `검증:`이 있으면 구현 계획의 같은 plan item 안에 해당 검증을 포함한다. 검증이 명시되지 않은 기능 Task에는 억지 검증 항목을 만들지 말고, 필요한 일반 빌드/회귀 확인만 최종 검증에 둔다.
 - 선택한 활성 Milestone 범위에 속하는 구현 계획이면 `{task_group}`을 `m-<milestone-slug>`로 정한다. `<milestone-slug>`는 선택한 Milestone 경로의 파일명에서 `.md`를 제거한 값이다.
-- Milestone 또는 Epic 범위의 plan 생성은 먼저 Milestone Task 하나를 선택하고, 그 Task가 크면 immediate sibling pair들을 `agent-task/m-<milestone-slug>/<subtask_dir>/` 아래에 함께 만든다. Epic은 선택 범위일 뿐 완료 대상으로 쓰지 않는다.
-- Milestone 기능 Task 완료를 목표로 하는 계획이면 `Roadmap Targets` 섹션에 활성 Milestone 경로와 완료 대상 Task id를 고정한다. Sibling split에서는 모든 필수 sibling을 선행 조건으로 가진 closure sibling 하나에만 이 섹션을 둔다. 자연스러운 마지막 sibling이 없으면 작은 integration/verification closure sibling을 만든다. 이 섹션은 `complete.log`의 `Roadmap Completion` 근거로 복사되어 `update-roadmap`이 해당 Task만 체크하는 anchor가 된다. `{task_group}`이 해당 Milestone slug의 `m-<milestone-slug>`일 때만 쓴다.
-- Milestone 작업이 아니거나, Milestone 안의 조사/부분 구현처럼 이번 작업만으로 특정 기능 Task 완료를 주장할 수 없으면 `Roadmap Targets` 섹션을 쓰지 않는다. 해당 기능 Task의 남은 acceptance를 실제로 닫는 마지막 작업에만 넣는다. 섹션이 없으면 PASS 후에도 roadmap Task 체크를 하지 않는다.
+- 같은 Milestone에서 split work가 필요하면 기존 split 규칙 그대로 `agent-task/m-<milestone-slug>/<subtask_dir>/` 아래에 계획 파일을 만든다.
+- Milestone 기능 Task 완료를 목표로 하는 계획이면 `Roadmap Targets` 섹션에 활성 Milestone 경로와 완료 대상 Task id를 고정한다. 이 섹션은 `complete.log`의 `Roadmap Completion` 근거로 복사되어 `update-roadmap`이 해당 Task만 체크하는 anchor가 된다. 이 섹션은 `{task_group}`이 해당 Milestone slug의 `m-<milestone-slug>`일 때만 쓴다.
+- Milestone 작업이 아니거나, Milestone 안의 조사/하위 구현처럼 특정 기능 Task 완료를 주장하지 않는 계획이면 `Roadmap Targets` 섹션을 쓰지 않는다. 섹션이 없으면 PASS 후에도 roadmap Task 체크를 하지 않는다.
 - `agent-roadmap/` 디렉터리가 없으면 기존 task routing 규칙대로 진행한다.
 
 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 shallow sibling extraction policy once. Choose one task directory or a complete immediate sibling set. Do not put multiple active plan files in one task directory or mix indexed task directories with active plan/review files directly in the parent task group.
+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.
 
 ## Step 2 - Analyze Before Writing
 
-Complete these four items before creating active plan/review files. The only allowed pre-plan edits are local `agent-roadmap/current.md` creation or `.gitignore` repair needed for routing. Report test-rule gaps separately; do not create or update test rules while planning.
+Complete all items below before creating active plan/review files. Work through them in order; do not proceed to the next step until every checkbox is done. Keep the user request as the scope anchor and reconcile derived acceptance conditions before the split decision; do not create a separate routing summary. The only allowed file edits before writing plan/review files are local `agent-roadmap/current.md` creation or `.gitignore` block repair needed for roadmap routing, plus `create-test` or `update-test` edits when the repository already uses agent-test for the relevant scope or the user explicitly asked to maintain test rules.
 
-- [ ] **Fix scope and split once** — select one executable candidate from the request and required roadmap/SDD context. Keep it whole or freeze one immediate sibling set; do not recurse.
-- [ ] **Fix directories and dependencies** — allocate indices, encode real predecessors, and confirm concurrent siblings have disjoint writes and no shared state or ordering conflict. Resolve only the predecessor `complete.log` paths required by dependent siblings.
-- [ ] **Inspect the implementation surface** — read targeted source/test regions, affected contracts, renamed or removed symbol references, and relevant manifests. Identify obvious dependency, import, type, or implementation risks statically; do not load unrelated files or compile.
-- [ ] **Write the verification contract** — use the user-selected `test_env` or `local` by default. Read applicable rules/profiles or a static fallback, then record test additions or gaps, exact commands, workdir, expected results, cache policy when stale results could hide failure, and any non-local preflight assumptions. Do not execute commands, probe environments, or mutate test rules.
+- [ ] **Load test environment rules** — because implementation plans include verification, determine `test_env` before choosing verification commands. Use the user-specified environment when provided; otherwise use `local`. Agent-test is optional: some repositories or tasks intentionally do not have or use `agent-test/`. Check `agent-test/<test_env>/rules.md`; read it in full when present, even if it appears blank or skeleton. If it is absent, record that no agent-test rule was applied and choose fallback verification sources from repository manifests, scripts, workflows, domain rules, or direct read-only environment probes. Do not create agent-test files merely because a plan has verification. Invoke `create-test` only when the user asked for test-rule creation/maintenance, the current task is itself test-rule work, or the repository already uses agent-test for this scope and the missing/blank rule is a real maintenance gap. If creation is not appropriate or possible in the current task context, record the gap and fallback source; absence is not a user-review blocker by itself.
+- [ ] **Read all source files in full** — read every source file the change will touch, whole file. No partial reads.
+- [ ] **Resolve test profiles** — if env rules exist and contain `## 라우팅`, read every matching `agent-test/<test_env>/<test-profile>.md` in full. If agent-test is absent or intentionally unused for the task, skip profile resolution and record the fallback verification source. Use `create-test` for missing or structurally blank routes/profiles only when the repository already uses agent-test for this scope or the task is test-rule maintenance. Use `update-test` only when verified command or criteria facts are available or the user asked to maintain test rules. If a profile exists but leaves command/criteria values as `<확인 필요>`, record the incomplete values and choose fallback verification commands from repository manifests or workflows with lower confidence. Do not claim agent-test requires a command that is not written in the env rules or matched profiles.
+- [ ] **Preflight non-local test environments** — when any required verification leaves the current checkout, including remote runner, field/bootstrap, external provider, Docker/code-server, emulator/device, or shared long-running runtime, derive a read-only preflight before writing final verification commands. Use matched `agent-test` rules when they exist and apply; otherwise derive the preflight from repository manifests, scripts, workflows, domain rules, current task evidence, user-provided environment facts, and direct read-only probes. Record runner, repo root/workdir, branch/HEAD/dirty state, source sync status, binary/artifact paths, command help/version output needed by the verification, config path, runtime identity such as Edge id, ports/process state, external hosts, and OS/arch assumptions. If the preflight shows stale artifacts, dirty/divergent checkout, wrong identity, missing command, closed ports, host OS mismatch, or unsynced source, the plan must add an explicit setup/sync/rebuild step or report the blocker; do not write verification commands that silently assume profile or fallback values are already true.
+- [ ] **Read all test files in full** — read every test file that exercises the changed behavior, including files implied by matched agent-test profiles when any are used and by the repository test layout.
+- [ ] **Assess test coverage** — for each behavior change, explicitly record whether existing tests cover it.
+- [ ] **Assess split boundaries once** — reconcile request acceptance with source/tests, then split only where every child has a stable contract and independent PASS verification. Otherwise keep the invariant together; do not gather extra evidence solely to lower routing risk.
+- [ ] **Capture recovery signals once** — first-pass uses `review_rework_count=0` and `evidence_integrity_failure=false`. In `prepare-follow-up`, reuse the values already validated and appended by code-review; do not recount verdict history. For another isolated replan, derive them once from the same-task state already loaded for planning, without a routing-only log pass.
+- [ ] **Resolve split predecessor completion** — if the selected or proposed subtask directory has `NN+PP[,QQ...]_...`, resolve each predecessor index under the same task group. Check only the active and archive candidate patterns defined in the task directory naming rules. Record found active/archive paths, missing predecessors, or ambiguous matches in `분석 결과 > 분할 판단` and, when order matters, `의존 관계 및 구현 순서`.
+- [ ] **Grep all symbol references** — for any renamed or removed symbol, find every call site and import chain.
+- [ ] **Check dependency manifests** — before adding any new package, verify its presence in go.mod / package manifest.
+- [ ] **Pre-check compile issues** — identify missing interface implementations, type mismatches, and broken imports.
+- [ ] **Verify verification commands** — confirm that the final verification commands actually run in this repository layout.
+- [ ] **Stabilize fragile verification** — for search or generated-output checks, choose deterministic commands up front, such as `rg --sort path`, and decide whether cached test output is acceptable or `-count=1` is required.
+- [ ] **Derive routing signals once** — treat each completed in-memory PLAN as the worker packet. From facts already collected, record `large_indivisible_context`, positive matched loop-risk names/count, and recovery signals. Do not reread files, prove unmatched signatures false, or aggregate parent/sibling risk for routing.
 
 ## Step 3 - Finalize Task Routing
 
 This step is mandatory and must be the last semantic decision before routed filenames are fixed. Complete Step 2 and prepare the full plan structure in memory before starting it.
 
-- [ ] **Build neutral input** — for each sibling, prepare its scope, affected paths, invariants, context size, sibling-set position, verification plan, available existing evidence, ownership, unresolved decisions, and existing failure evidence for `build` and `review`. Exclude every previous lane, grade, routing score, rationale, filename, and archive basename that exposes them.
-- [ ] **Select evaluation mode** — use `first-pass` for new work and `isolated-reassessment` for `plan-ready` findings. Exclude the previous lane, grade, score, rationale, and preferred route.
-- [ ] **Run the routing skill** — read and fully execute `agent-ops/skills/common/finalize-task-routing/SKILL.md` with both targets independently for each sibling. Do not reproduce or replace its decision logic inside this skill. Do not return `blocked` merely because a separate evaluation context or explicit follow-up instruction is unavailable.
-- [ ] **Resolve non-final states** — for `needs_evidence`, collect only static planning facts and rerun. Never execute implementation verification.
-- [ ] **Accept only a fully routed set** — require independent `build` and `review` closure records, lane, grade scores, GNN, and canonical filename for every sibling. If any new sibling is not routed, write none of the new sibling batch.
-- [ ] **Freeze the result** — use each sibling's exact basenames in Steps 4-6. If any routing input or sibling boundary changes before files are written, discard the affected set and repeat this step.
+- [ ] **Freeze routing input and mode** — use the completed in-memory PLAN and existing analysis facts. Include closure, grade, `large_indivisible_context`, positive risk names/count, and recovery signals; exclude previous route fields. Use `first-pass` with no prior route, otherwise `isolated-reassessment`. Remove prior route fields in memory; do not create a sub-agent, packet document, or routing-only evidence pass.
+- [ ] **Run routing once** — fully execute `agent-ops/skills/common/finalize-task-routing/SKILL.md` for build/review. Do not duplicate its decision rules in this skill.
+- [ ] **Stop or accept** — `needs_evidence` may rerun only after collecting all named new evidence; `blocked` stops without task-file mutation. Accept `routed` only when finalizer identity, closure, base/final basis, signals, grade, lane, and filenames satisfy the routing skill.
+- [ ] **Freeze routed names** — use the returned basenames unchanged in Steps 4-6. If an input fact changes before write, invalidate both routes and perform this step once again on the changed input.
 
-## Step 4 - Prepare Task Files
+## Step 4 - Archive Existing Active Files
 
-Apply this step independently to every routed sibling directory. Do not archive or overwrite unrelated active siblings.
+In `write` mode, complete this step before writing new active files. In `prepare-follow-up` mode, calculate the same counts and archive names but do not modify any repository file; code-review owns the later archive.
 
-- Validate that the task directory contains at most one active routed pair, at most one staged pair, and at most one `USER_REVIEW.md`. Reject ambiguous, malformed, or identity-mismatched files.
-- For multi-sibling work, require at most one `STAGED_BATCH.md` in the task-group parent.
-- Ensure `.gitignore` exposes task Markdown and log files.
-- Do not archive review artifacts. A `plan-ready` pair is already archived by the review model.
-- For an explicit replan with an unstarted active pair, calculate its archive destinations but defer renames until the replacement pair is fully staged.
-- Use monotonic suffixes for the new pair's future archive names.
+- Validate that the task directory contains at most one active `PLAN-(local|cloud)-G(0[1-9]|10).md`, at most one active `CODE_REVIEW-(local|cloud)-G(0[1-9]|10).md`, and at most one `USER_REVIEW.md`. Reject ambiguous or malformed active names.
+- In `write` mode, ensure `.gitignore` has the Agent-Ops managed gitignore block before renaming any active file to `*.log` or creating local `agent-roadmap/current.md`. Prefer `source agent-ops/bin/ai-ignore.sh && agent_ops_ensure_gitignore_task_artifact_block .gitignore`; if the helper is unavailable, add or update a block containing `!agent-task/`, `!agent-task/**/`, `!agent-task/**/*.md`, `!agent-task/**/*.log`, and `agent-roadmap/current.md`. In `prepare-follow-up` mode, only inspect the block and return `gitignore_repair_needed: true|false`; code-review performs any repair after preparation.
+- Count existing `plan_*.log` as `current_plan_archive_number`. If an active plan exists, parse `current_build_lane` and `current_build_grade` from that active filename and set `current_plan_archive_name=plan_{current_build_lane}_{current_build_grade}_{current_plan_archive_number}.log`. Require that destination not to exist. In `write` mode rename that exact active file to the calculated name; in `prepare-follow-up` only return the name and number. Never use the newly routed build lane/grade to archive the old active plan.
+- Count existing `code_review_*.log` as `current_review_archive_number`. If an active review exists, parse `current_review_lane` and `current_review_grade` from that active filename and set `current_review_archive_name=code_review_{current_review_lane}_{current_review_grade}_{current_review_archive_number}.log`. Require that destination not to exist. In `write` mode rename that exact active file to the calculated name; in `prepare-follow-up` only return the name and number. Never use the newly routed review lane/grade to archive the old active review.
+- Count existing `user_review_*.log` as `current_user_review_archive_number`. If `USER_REVIEW.md` exists and the linked Milestone decision is resolved for replanning, set `current_user_review_archive_name=user_review_{current_user_review_archive_number}.log`; require that destination not to exist and rename it only in `write` mode.
+- Compute `post_archive_plan_log_count`, `post_archive_review_log_count`, and `post_archive_user_review_log_count` from the filesystem after actual archive in `write` mode, or from the predicted addition of each current active file in `prepare-follow-up` mode.
 
-Set each `next_log_suffix` to `0` when no matching log exists, otherwise `max(existing numeric suffix) + 1`. A normal new pair uses those suffixes. An explicit replacement archives the old pair at those suffixes and uses suffix plus one for the staged pair. Set `plan_number=plan_log_number`.
+Set `plan_number=post_archive_plan_log_count`. The new pair's future archive suffixes are `plan_log_number=post_archive_plan_log_count` and `review_log_number=post_archive_review_log_count`. These are intentionally different concepts from `current_plan_archive_number` and `current_review_archive_number`.
 
-## Step 5 - Render Plan File
+## Step 5 - Write Plan File
 
-Render each complete plan in memory. Do not write the routed PLAN basename yet.
+Render the complete plan in memory first. In `write` mode, write it to the routed plan basename. In `prepare-follow-up` mode, return the exact rendered body as `prepared_plan` and do not write it.
 
 Header line must be exactly:
 
@@ -251,23 +233,13 @@ Header line must be exactly:
 <!-- task={task_name} plan={plan_number} tag={TAG} -->
 ```
 
-Write the immutable Plan identity in a second metadata comment:
-
-```markdown
-<!-- plan-model={plan_model_identity} -->
-```
-
 Required sections:
 
 - Title.
-- `구현 에이전트 규칙`: keep this to four short bullets:
-  - runtime has already verified encoded predecessor dependencies before dispatch; do not search `agent-task/**` or `agent-task/archive/**`;
-  - change only the listed implementation files and follow the checklist/verification contract;
-  - fill only implementation-owned fields in the review stub;
-  - report `review-ready` and stop without reviewing, archiving, writing terminal files, or starting another agent.
-- `배경`: 1-3 sentences explaining why the work is needed.
-- `Archive Evidence Snapshot`: include this section only when the plan resumes from a resolved `user_review_*.log`, a prior archived review, or any archive evidence. Omit it for first-pass plans with no archive evidence. For resolved user review, include the resolution log path, decision, evidence, and its referenced archived pair. The section must otherwise contain only the archive facts needed to implement without rereading archive by default: prior task/archive paths, verdict, Required/Suggested/Nit summary, affected files, verification evidence, and any roadmap carryover. If exact prior context is still required, cite the specific archive file paths allowed to read; do not ask the implementer to search `agent-task/archive/**` broadly.
-- `Roadmap Targets`: include this section only when the plan is intended to complete one or more existing Milestone 기능 Task ids. In a sibling set, include it only in the closure sibling whose directory dependencies cover every required predecessor. Omit the section entirely for non-roadmap work or partial siblings that should not check a Task on PASS. Format exactly:
+- `이 파일을 읽는 구현 에이전트에게`: warn that filling implementation-owned `CODE_REVIEW-*-G??.md` sections is mandatory. Tell the implementer to run verification, fill actual notes/output, keep active files in place, and report ready for review; finalization is code-review-skill only. If blocked, the implementer records only exact blocker evidence, attempted commands/output, and resume conditions in implementation-owned evidence fields. It must not ask the user, call user-input tools, create control-plane stop files, classify the next state, archive logs, or write `complete.log`.
+- `배경`: 2-4 sentences explaining why the work is needed.
+- `Archive Evidence Snapshot`: include this section only when the plan resumes from `USER_REVIEW.md`, a prior archived review, or any archive evidence. Omit it for first-pass plans with no archive evidence. The section must contain only the archive facts needed to implement without rereading archive by default: prior task/archive paths, verdict, Required/Suggested/Nit summary, affected files, verification evidence, and any roadmap carryover. If exact prior context is still required, cite the specific archive file paths allowed to read; do not ask the implementer to search `agent-task/archive/**` broadly.
+- `Roadmap Targets`: include this section only when the plan is intended to complete one or more existing Milestone 기능 Task ids. Omit the section entirely for non-roadmap work or Milestone-adjacent work that should not check a Task on PASS. Format exactly:
 
 ```markdown
 ## Roadmap Targets
@@ -295,27 +267,31 @@ Required sections:
 - Status updates on PASS:
   - `agent-ui/definition/views/<view-id>/index.md`: `계획` -> `구현됨`
 ```
-- `구현 범위`: give the worker only execution-relevant facts:
-  - exact write set;
-  - required behavior, invariants, and public/inner contract constraints;
-  - only the source/spec/test-rule paths needed while implementing;
-  - tests to add or update;
-  - explicit exclusions.
-  Keep routing scores, lane rationale, full read inventories, split deliberation, and dependency-resolution history out of the generated plan. The routed filenames and task directory already preserve those decisions. For SDD work, include only the applicable SDD path, Acceptance Scenario ids, Milestone Task ids, and required evidence behavior.
-- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per implementation/verification unit; if the roadmap feature Task has `검증:`, keep that verification in the same checklist item. Make the final item exactly: `- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 채우고 review-ready를 보고한 뒤 현재 실행을 종료한다. code-review를 실행하거나 다음 에이전트를 시작하지 않는다.` Copy it into the review stub unchanged.
+- `분석 결과`: record the findings from Step 2 and the final routed output from Step 3. This section is the written output of the analysis — not a summary, but the actual findings that justify the plan's scope and decisions. Must include all of the following subsections:
+  - `읽은 파일`: list every source and test file read during analysis, with path. List agent-test rule/profile files only when they were actually present and read.
+  - `SDD 기준`: for `SDD: 필요` Milestones, list the SDD path, status, targeted Acceptance Scenario ids, their Milestone Task ids, and the Evidence Map rows that drive the plan. State explicitly how those rows shaped the implementation checklist and final verification. If the selected Milestone has `SDD: 불필요`, state the recorded reason. If the work is not Milestone-linked, state "not applicable".
+  - `테스트 환경 규칙`: state the chosen `test_env`, whether `agent-test/<test_env>/rules.md` was present/read/missing/intentionally unused, every matched profile path read when any, the concrete rules/commands applied, any structural blank/skeleton or missing rules, any `<확인 필요>` values, and any fallback verification source. If any required verification leaves the current checkout, include a `테스트 환경 프리플라이트` record with runner, repo root/workdir, branch/HEAD/dirty state, source sync status, binary/artifact paths, required command help/version output, config path, runtime identity such as Edge id, ports/process state, external hosts, OS/arch assumptions, and the exact setup/sync/rebuild step or blocker derived from mismatches. If agent-test is absent or unusable, explicitly say no agent-test rule was applied, what fallback is used, and whether test-rule maintenance is actually needed or not needed for this task.
+  - `테스트 커버리지 공백`: list each behavior change and whether existing tests cover it; explicitly note gaps.
+  - `심볼 참조`: list renamed/removed symbols and every call site found, or state "none" if no symbols were changed.
+  - `분할 판단`: for one plan, name the indivisible invariant or compact boundary; for split plans, list each child's stable contract, PASS evidence, and dependency. For dependent subtask plans, include each predecessor index and whether it is satisfied by an active or archived `complete.log`, missing, or ambiguous.
+  - `범위 결정 근거`: state which files or areas were explicitly excluded from this change and why. This is the boundary justification — the implementing agent must not silently expand scope beyond what is recorded here.
+  - `최종 라우팅`: record `evaluation_mode`, finalizer, both targets' closure/grade/route, `large_indivisible_context`, positive loop-risk names/count, recovery signals, capability-gap evidence, and canonical filenames. Do not include or compare a previous loop's lane/G.
+- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per implementation/verification unit; if the roadmap feature Task has `검증:`, keep that verification in the same checklist item instead of making a separate completion-criteria item. Include one item for whole-plan intermediate/final verification only when it is not already covered by the feature items. Make the last item exactly `- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다.` Copy this checklist into the review stub's `구현 체크리스트` section with the same item text and order.
 - One item per change: `### [TAG-1] Title`, `TAG-2`, etc.
 - `수정 파일 요약`: table mapping files to item ids.
-- `최종 검증`: runnable commands and expected outcome. Prefer commands from the matched agent-test env/profile rules. The final line must read exactly — **"검증 결과를 review stub에 기록하고 review-ready를 보고한 뒤 현재 실행을 종료한다. code-review를 실행하거나 다음 에이전트를 시작하지 않는다."**
+- `최종 검증`: runnable commands and expected outcome. Prefer commands from the matched agent-test env/profile rules. If agent-test is missing, blank, skeleton, or lacks a matching command, use repository manifests/workflows as fallback and record that fallback in `분석 결과 > 테스트 환경 규칙`. Commands must be exact and deterministic enough for the reviewer to rerun; use stable ordering for searches and state whether cached test output is acceptable. End this section with **"모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다."**
 
-Each plan item must include the applicable fields below:
+Each plan item must include:
 
 - `문제`: concrete problem with file:line references.
 - `해결 방법`: exact approach and before/after code block for non-trivial changes.
 - `수정 파일 및 체크리스트`: exhaustive file-level checklist.
 - `테스트 작성`: explicit write/skip decision. If writing tests, include path, test name, assertion goal, and fixtures. If skipping, justify.
-- `중간 검증` (optional): include it only when a later plan item depends on that result; otherwise rely on final verification.
+- `중간 검증`: runnable commands and expected result.
 
-Describe within-task implementation order only when one plan item depends on another. Do not copy sibling dependency status into the generated plan or instruct the implementation worker to inspect `complete.log`; `{subtask_dir}` and runtime remain the dependency source of truth.
+Include `의존 관계 및 구현 순서` only when order matters.
+
+For split multi-plan work, the `{subtask_dir}` directory name is the runtime source of truth. If a plan has a `NN+PP[,QQ...]_...` subtask directory name, `의존 관계 및 구현 순서` must echo the decoded predecessor subtask directories under the same task group that must produce `complete.log` before implementation starts, and it must not add dependencies that are absent from the directory name. If a predecessor already completed, cite the active or archived `complete.log` path that satisfies it.
 
 Quality rules:
 
@@ -339,8 +315,6 @@ Test policy:
 
 Verification fidelity rules:
 
-These are execution rules for build and review, not commands for the plan author to run.
-
 - Plan verification commands are a contract. The implementing agent must run them exactly as written.
 - If a command must be changed, the implementing agent must record the replacement command and reason in `계획 대비 변경 사항`, then paste the replacement command's actual stdout/stderr.
 - Before claiming a tool is unavailable, run and record `command -v <tool>` or the project-equivalent check.
@@ -354,28 +328,16 @@ These are execution rules for build and review, not commands for the plan author
 
 ## Step 6 - Write Review Stub
 
-Read `agent-ops/skills/common/plan/templates/review-stub-template.md` in full only after Step 3 returns `status: routed` for the complete new sibling set.
+Read `agent-ops/skills/common/plan/templates/review-stub-template.md` in full only after Step 3 returns `status: routed`.
 Replace every occurrence of each token below:
 
-- Scalar tokens: `{date}`, `{task_name}`, `{plan_number}`, `{TAG}`, `{plan_model_identity}`.
+- Scalar tokens: `{date}`, `{task_group}`, `{task_name}`, `{plan_number}`, `{TAG}`, `{build_lane}`, `{build_grade}`, `{review_lane}`, `{review_grade}`, `{plan_log_number}`, `{review_log_number}`.
 - Plan-copy tokens: `{roadmap_targets_or_omit}`, `{archive_evidence_snapshot_or_omit}`, `{agent_ui_completion_or_omit}`, `{implementation_checklist}`, `{review_checkpoints}`.
 - Generated row/section tokens: `{implementation_completion_rows}` contains one row for every plan item, and `{verification_result_sections}` contains the fixed verification instructions plus every intermediate/final command from the plan.
-- `{implementation_user_review_request_section}` is replaced by the full contents of `agent-ops/skills/common/_templates/implementation-user-review-request-section.md`; do not prepend another `사용자 리뷰 요청` heading.
-
-`{review_checkpoints}` contains only product behavior, scope, contract, and verification focuses useful while implementing. Do not include model identity, dependency/`complete.log`, archive, terminal-output, or finalization checks; the Review skill owns those controls.
 
 Use the routed build/review grades independently. Remove optional plan-copy content by replacing its token with an empty string, not by leaving template instructions.
-Do not write any pair when a sibling's routing target is not `routed`. After rendering, scan every stub for the exact template-token inventory above and reject the output if any known token remains; do not reject unrelated braces in copied commands or code.
-
-For a multi-sibling set, first write `STAGED_BATCH.md` with the task group, Plan identity, complete sibling paths, frozen scopes, routed basenames, and source-evidence fingerprints. Recovery must finish every listed pair without changing scope/routing; reject fingerprint drift. Remove the batch marker only after all listed pairs are verified.
-
-For each sibling, write the complete plan to `STAGED_PLAN.md`, then the complete stub to `STAGED_CODE_REVIEW.md`. An existing staged plan is immutable: use it as the render source, create only a missing staged review, and reject conflicts. Verify both headers, identities, routed basenames, and bodies before promotion.
-
-For an explicit replacement, preflight the old pair's calculated log destinations after both staged files exist, then rename the old review and old plan. On interruption, match the remaining old member, archived counterpart, and staged pair by task/plan headers; finish only the missing old archive and never overwrite a log.
-
-Preflight both routed destinations, then rename `STAGED_PLAN.md` to the routed PLAN basename and `STAGED_CODE_REVIEW.md` to the routed CODE_REVIEW basename. If only the PLAN was promoted, verify it against the staged identity and promote only the remaining review. Never reroute or create a second PLAN during staged recovery.
-
-After every pair is promoted, resolve only its encoded predecessor `complete.log` evidence and report the pair path with exactly one readiness value: `implementation-ready` or `dependency-waiting`. Do not start an implementation agent. Runtime re-evaluates a waiting task before later dispatch.
+In `write` mode, write the rendered stub to the routed review basename. In `prepare-follow-up` mode, return it as `prepared_review` without writing.
+Do not write or return a prepared pair when either routing target is not `routed`. After rendering, scan for the exact template-token inventory above and reject the output if any known token remains; do not reject unrelated braces in copied commands or code.
 
 ## Naming
 
@@ -388,13 +350,28 @@ After every pair is promoted, resolve only its encoded predecessor `complete.log
 
 ## Final Checklist
 
-- Every planned sibling has one fully routed PLAN/CODE_REVIEW output pair for the correct task path, with matching headers, checklist, conditional sections, and no template tokens.
-- No `STAGED_BATCH.md`, `STAGED_PLAN.md`, or `STAGED_CODE_REVIEW.md` remains after every routed pair is verified.
-- Directory names encode every real dependency; parallel siblings have no write, state, ordering, or contract conflict. Unsatisfied dependent siblings are reported as `dependency-waiting`, not dispatched.
-- `Roadmap Targets`, Agent UI, archive evidence, and user-review sections appear only when their stated conditions apply and match between PLAN and CODE_REVIEW; concise SDD targets remain in the PLAN implementation scope.
-- Verification records the selected environment, static sources, test decision, commands, and expected results without plan-time execution output. Intermediate verification appears only when it adds an early failure signal.
-- The plan model wrote the routed pair, reported `implementation-ready` or `dependency-waiting` from dependency evidence, and stopped without implementing, reviewing, or starting another agent.
-- An explicitly replaced unstarted pair was archived only after its replacement pair was fully staged, with distinct monotonic log suffixes.
-- Follow-up routing does not inherit prior lane/G, and implementation/user-review ownership remains unchanged.
-- Every generated review ledger states the three-model separation, and the PLAN worker rules state the one-role-per-invocation boundary.
-- The PLAN metadata comment and review ledger contain the same runtime-provided Plan model identity; Implementation and Review identities remain pending until runtime starts those roles.
+- In `write` mode, the routed `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` both exist under `agent-task/{task_name}/`. In `prepare-follow-up` mode, neither routed file was written; both exact bodies and basenames were returned while the verdict-appended current pair remained active.
+- In `write` mode, `.gitignore` has the Agent-Ops managed block that unignores `agent-task/**/*.md` and `agent-task/**/*.log` and ignores local `agent-roadmap/current.md`. In `prepare-follow-up` mode, the block was only inspected and any needed repair was returned as `gitignore_repair_needed`.
+- 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`.
+- Split sibling indices follow topological dependency order: every predecessor is lower than its consumer, and every gap is explained by an unchanged existing predecessor or an occupied active/archive index.
+- 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={plan_number} tag={TAG} -->`.
+- The review stub was rendered from `agent-ops/skills/common/plan/templates/review-stub-template.md` after routing and has no unresolved known template token.
+- In `write` mode, previous active files, if any, were archived with lane/grade parsed from their own basenames and the correct current archive suffixes. In `prepare-follow-up` mode, those archive names were only predicted.
+- In `write` mode when resuming from `USER_REVIEW.md`, it was archived to the calculated `current_user_review_archive_name` and the resolved linked Milestone decision was recorded in the new plan.
+- `Roadmap Targets` exists only when PASS should check explicit Milestone Task ids, the task group is `m-<milestone-slug>` for the listed Milestone path, and every listed Task id exists in the selected active Milestone.
+- If `Roadmap Targets` exists in the plan, the review stub contains the identical section. If it does not exist in the plan, the review stub omits it too.
+- If `Agent UI Completion` exists in the plan, the review stub contains the matching section with implementation-owned evidence fields. If it does not exist in the plan, the review stub omits it too.
+- If the selected Milestone has `SDD: 필요`, the plan's `분석 결과 > SDD 기준` proves that the implementation checklist and final verification were derived from the approved SDD Acceptance Scenarios and Evidence Map. Missing SDD mapping blocks plan creation.
+- If the plan is a follow-up or resumes from prior archive evidence, it has `Archive Evidence Snapshot` and the review stub contains the identical section.
+- `분석 결과 > 테스트 환경 규칙` records the selected test env, env rules read/missing/structural-blank/intentionally-unused state, matched profiles read when any, and any fallback verification source.
+- Dependent split plans record predecessor completion using active sibling `complete.log` or matching archived `complete.log`; ambiguous archive matches are not guessed.
+- Every plan item has problem, solution, checklist, test decision, and intermediate verification.
+- The plan and review stub have matching `구현 체크리스트` item text/order; their final checkbox is the mandatory `CODE_REVIEW-*-G??.md` evidence item.
+- `finalize-task-routing` ran once after the PLAN body was complete, used no routing-only evidence pass, counted only positive packet-local risk, kept capability/grade basis from being relabeled by escalation signals, and produced matching filenames.
+- Review WARN/FAIL follow-ups entered through this plan skill and did not inherit or compare the archived lane/G.
+- The plan's implementer instructions and review stub limit local implementation agents to implementation/test/evidence work and keep user-review classification plus control-plane stop files out of their input and ownership.
+- The review stub has a clearly marked `코드리뷰 전용 체크리스트` owned only by the review agent.
+- Routed review file completion table lists every plan item.
+- In `prepare-follow-up`, no repository file was mutated and the returned prepared basenames/bodies, `plan_number`, current archive names/numbers, post-archive log counts, and `gitignore_repair_needed` are complete; in `write`, prior active state was archived with its own parsed route and both new active files were written.

agent-ops/skills/common/plan/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Plan"
+  short_description: "Write implementation plans"
+  default_prompt: "Use $plan to analyze this repository change, collect current routing evidence, run $finalize-task-routing with local-first capability-gap policy, and create the routed PLAN/CODE_REVIEW pair."

agent-ops/skills/common/plan/templates/review-stub-template.md

@@ -2,28 +2,38 @@
 
 # Code Review Reference - {TAG}
 
-> **[IMPLEMENTATION WORKER]**
-> Complete the implementation checklist, fill the implementation evidence below, report `review-ready`, and stop.
-> Edit only completion checkboxes, `계획 대비 변경 사항`, `주요 설계 결정`, `사용자 리뷰 요청`, Agent UI implementation evidence when present, and command output blocks.
-> Do not edit role identities, review, archive, create terminal files, or start another agent. Runtime and the later Review model own those actions.
-> Do not ask the user directly. Use `사용자 리뷰 요청` only for a selected Milestone `구현 잠금 > 결정 필요`; record other blockers in the implementation evidence.
+> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
+> The task is NOT complete until every implementation-owned section below is filled in.
+> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
+> Fill implementation-owned sections, then stop with active files in place and report ready for review.
+> If implementation is blocked, record the exact blocker, attempted commands/output, and resume condition only in implementation-owned evidence fields.
+> Do not ask the user directly, present choices, call user-input tools, create control-plane stop files, or classify the next state.
+> Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, `코드리뷰 전용 체크리스트`) is review-agent-only, even after compaction/resume.
+> Follow the ownership table at the bottom of this file for which sections you own.
 
 ## 개요
 
 date={date}
 task={task_name}, plan={plan_number}, tag={TAG}
 
-## 역할 모델
-
-- Plan: `{plan_model_identity}`
-- Implementation: `pending`
-- Review: `pending`
-
-> Runtime-only ledger. Runtime requires three distinct model identities; the implementation worker does not edit it.
-
 {roadmap_targets_or_omit}
 {archive_evidence_snapshot_or_omit}
 
+## 이 파일을 읽는 리뷰 에이전트에게
+
+> **[REVIEW AGENT ONLY]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.
+
+각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
+리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.
+
+1. 판정과 `review_rework_count` / `evidence_integrity_failure` 라우팅 신호를 append한다.
+2. `CODE_REVIEW-{review_lane}-{review_grade}.md` → `code_review_{review_lane}_{review_grade}_{review_log_number}.log`, `PLAN-{build_lane}-{build_grade}.md` → `plan_{build_lane}_{build_grade}_{plan_log_number}.log`로 아카이브한다.
+3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 code-review skill이 요구하는 다음 filesystem state를 완전히 작성한다.
+4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
+5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
+
+---
+
 ## 구현 항목별 완료 여부
 
 | 항목 | 완료 여부 |
@@ -36,6 +46,22 @@ task={task_name}, plan={plan_number}, tag={TAG}
 
 {agent_ui_completion_or_omit}
 
+## 코드리뷰 전용 체크리스트
+
+> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
+> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.
+
+- [ ] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정과 검증된 `review_rework_count`, `evidence_integrity_failure`를 append한다.
+- [ ] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
+- [ ] active `CODE_REVIEW-*-G??.md`를 `code_review_{review_lane}_{review_grade}_{review_log_number}.log`로 아카이브한다.
+- [ ] active `PLAN-*-G??.md`를 `plan_{build_lane}_{build_grade}_{plan_log_number}.log`로 아카이브한다.
+- [ ] `.gitignore`의 Agent-Ops 관리 block이 `agent-task/**/*.md`와 `agent-task/**/*.log`를 unignore하고 `agent-roadmap/current.md`를 ignore하는지 확인한다.
+- [ ] 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이면 code-review skill의 판정에 맞는 다음 filesystem state를 작성하고 `complete.log`를 작성하지 않는다.
+
 ## 계획 대비 변경 사항
 
 _구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께 기록한다._
@@ -44,8 +70,6 @@ _구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께
 
 _구현 에이전트가 주요 설계 결정 사항을 기록한다._
 
-{implementation_user_review_request_section}
-
 ## 리뷰어를 위한 체크포인트
 
 {review_checkpoints}
@@ -56,4 +80,22 @@ _구현 에이전트가 주요 설계 결정 사항을 기록한다._
 
 ---
 
-> Before saving, fill every implementation-owned field and command output. Then report `review-ready` and stop.
+> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section?**
+> If anything is blank, go back and fill it in before saving this file.
+> Leave review-agent-only sections unchanged.
+
+## 섹션 소유권
+
+| Section | Owner | Note |
+|---------|-------|------|
+| Header comment, 개요, 리뷰 에이전트 지시 | Fixed at stub creation | Implementing agent must not modify or execute these (archive, complete.log, and task-directory archive move are review-agent only) |
+| Roadmap Targets | Fixed at stub creation from plan when present | Implementing agent must not modify; code-review copies it into `complete.log` as `Roadmap Completion` only on PASS |
+| Archive Evidence Snapshot | Fixed at stub creation from plan when present | Implementing agent uses it as default prior-loop context; read only the specific archive files cited there when more detail is required |
+| Agent UI Completion | Mixed | Present only for plan-required agent-ui code work; implementing agent fills actual evidence, review agent applies `구현됨` status/evidence update on PASS and copies the section into `complete.log` |
+| 구현 항목별 완료 여부 (item names) | Fixed at stub creation | Implementing agent checks `[ ]` → `[x]` only |
+| 구현 체크리스트 (item text/order) | Fixed at stub creation from plan | Implementing agent checks `[ ]` → `[x]` only |
+| 코드리뷰 전용 체크리스트 | Review agent only | Implementing agent must not modify or check this section |
+| 계획 대비 변경 사항, 주요 설계 결정 | Implementing agent | Replace placeholder text with actual content |
+| 리뷰어를 위한 체크포인트 | Fixed at stub creation | Pre-filled from plan |
+| 검증 결과 (section headings + commands) | Fixed at stub creation | Implementing agent fills in command output only; command changes require a `계획 대비 변경 사항` entry |
+| 코드리뷰 결과 | Review agent appends | Not included in stub |

agent-ops/skills/common/refine-local-plans/SKILL.md

@@ -1,63 +1,69 @@
 ---
 name: refine-local-plans
-description: 현재 plan들 세분화해, 현재 plan 세분화, 기존 plan 더 나눠, local plan 분리해 같은 요청에서 이미 생성된 미착수 local plan을 유지하거나 최대 3개의 local sibling plan으로 한 단계 분리할 때 사용한다. 현재 Worker용 PLAN/CODE_REVIEW 형식, 유효한 runtime dependency 이름, readiness를 함께 갱신한다.
+description: 현재 plan들 세분화해, 현재 plan 세분화, 기존 plan 더 나눠, local plan 분리해 같은 요청에서 이미 생성된 미착수 PLAN-local-G??/CODE_REVIEW pair를 최대 3개의 작은 local sibling pair로 나누고 같은 task group의 미착수 index를 의존성 순서로 함께 정렬할 때 사용한다.
 ---
 
-# refine-local-plans
+# Refine Local Plans
 
 ## 목표
 
-기존 미착수 local pair를 더 작은 실행 단위로 한 번만 나눈다. 문서와 runtime dependency를 갱신하되 구현 조사, 실행 검증, Worker/Review 시작은 하지 않는다.
+이미 생성된 미착수 local pair를 로컬 모델이 수행하기 쉬운 응집된 단위로 이번 실행에서 한 단계만 나눈다. Source/test를 다시 조사하거나 검증을 실행하지 않는다.
 
 ## 대상
 
-- 사용자가 지정한 `agent-task/{task_group}` 또는 `PLAN-local-G??.md`를 대상으로 삼는다.
-- 대상을 생략하면 미착수 local pair가 있는 active task group이 정확히 하나일 때만 사용한다. 여러 개면 후보만 보고한다.
-- 대상은 active PLAN/CODE_REVIEW pair가 있고 Implementation/Review identity와 구현 소유 필드가 아직 채워지지 않았으며 verdict가 없는 작업이다.
-- `complete.log` 또는 `USER_REVIEW.md`가 있는 작업과 이미 구현이 시작된 pair는 제외한다. 이전 loop의 `*.log`만 있다는 이유로 미착수 follow-up pair를 제외하지 않는다.
-- 대상 또는 dependency가 바뀌는 direct dependent가 이미 구현 중이면 분리하지 않는다.
-- 대상 pair와 실제 dependency가 바뀌는 미착수 sibling pair만 읽는다.
-- index 할당에는 같은 task group의 active directory name과 archived sibling directory basename만 사용한다. Readiness 판정에 필요한 direct predecessor `complete.log`만 active/archive에서 좁게 읽고 Worker 문서에는 그 경로나 상태를 쓰지 않는다.
-- Roadmap, source, test 또는 다른 `SKILL.md`를 추가로 읽거나 호출하지 않는다. PLAN만으로 독립 경계가 명확하지 않으면 유지한다.
+- 사용자가 지정한 active task group, task path, 또는 `PLAN-local-G??.md`를 사용한다. 대상을 생략하면 미착수 local pair가 있는 task group이 정확히 하나일 때만 진행한다.
+- `PLAN-local-G??.md`와 matching `CODE_REVIEW-*-G??.md`가 모두 있고 verdict가 없어야 한다.
+- Review의 구현 완료표·구현 체크리스트가 모두 미체크이고, 구현 소유 기록과 검증 출력이 아직 채워지지 않은 pair만 미착수로 본다.
+- `complete.log` 또는 `USER_REVIEW.md`가 있거나 구현이 시작된 pair는 수정하지 않는다.
+- 대상 pair, 같은 task group의 미착수 active sibling pair, active directory basename과 archived sibling directory basename만 읽는다. Archive 내부 파일은 읽지 않는다. 새 구현 조사를 위해 source/test/roadmap/archive 본문을 읽지 않는다.
 
 ## 절차
 
 1. **범위를 고정한다**
-   - 각 PLAN의 목적, write set, checklist, verification, encoded dependency만 정리한다.
-   - CODE_REVIEW는 미착수 여부, Plan identity, checklist, 명령만 확인한다.
-   - Active directory name으로 direct dependent를 찾고 실제 dependency가 바뀌는 미착수 pair만 대상에 추가한다.
+   - 기존 PLAN의 checklist, plan item, 수정 파일, 검증 명령을 원본 범위로 고정한다.
+   - Plan에 없는 구현 범위나 검증을 추가하지 않는다.
 
 2. **유지 또는 분리를 결정한다**
-   - 의미 있는 독립 경계가 두 개면 2개, 세 개면 최대 3개로 한 단계만 분리한다.
-   - 각 child는 단독 구현 가능한 결과와 겹치지 않는 write set을 가져야 한다. 공유 상태나 dependency가 더 복잡해지면 유지한다.
-   - 원본 checklist와 verification을 담당 child에 빠짐없이 배분하되 실행하지 않는다.
+   - 서로 독립적으로 구현·검증 가능한 behavior slice가 정확히 2개 또는 3개일 때만 나눈다.
+   - 각 child는 하나의 응집된 결과와 필요한 production 변경을 가진다.
+   - Production 변경의 PASS에 필요한 기존 PLAN의 테스트는 같은 child에 둔다. 추가 통합/closure 검증만 별도 test child가 될 수 있다.
+   - 경계가 불명확하거나 공유 write set·상태·순서 때문에 coordination이 커지면 원본을 유지한다.
+   - 원본 유지로 결정하면 파일을 바꾸지 않고 결과만 보고한다.
+   - 이번 실행에서 만든 child를 다시 분할하지 않는다.
 
-3. **경로와 dependency를 확정한다**
-   - 이름은 `NN_{subtask_name}` 또는 `NN+PP[,QQ...]_{subtask_name}`만 사용한다. 모든 predecessor는 `NN`보다 작고 같은 task group의 sibling이어야 한다.
-   - 첫 child는 가능한 경우 원본 index와 기존 predecessor를 유지한다. 추가 child는 active/archive basename에 없는 다음 index를 사용한다.
-   - 직렬 child에만 실제 predecessor를 comma-separated로 표시하고 병렬 child에는 dependency를 만들지 않는다.
-   - 기존 direct dependent가 새 child를 의존해야 하는데 predecessor index가 그 dependent의 index 이상이면, 해당 미착수 dependent를 다음 collision-free index로 옮긴다. `02+01+03`처럼 더 큰 index를 참조하는 이름은 만들지 않는다.
-   - 변경 대상 directory, PLAN header, review header와 `개요 > task`는 같은 최종 task path를 사용한다. Historical `*.log`의 header는 수정하지 않는다.
-   - 원본에 `Roadmap Targets`가 있으면 모든 필수 child를 거친 closure child 하나에만 둔다. 그런 closure를 만들 수 없으면 분리하지 않는다.
+3. **경로와 dependency를 정한다**
+   - 이름은 `NN_{subtask_name}` 또는 `NN+PP[,QQ...]_{subtask_name}`만 사용하며 모든 predecessor는 `NN`보다 작아야 한다.
+   - Target children과 같은 task group의 active sibling으로 DAG를 만든다. 시작·완료 sibling은 고정 anchor로 두고, 나머지는 producer가 consumer보다 먼저 오도록 topological sort한다.
+   - 같은 단계에서는 기존 sibling의 index와 새 child의 원본 PLAN item 순서를 유지하고 basename으로 마지막 tie를 정한다.
+   - 검사 시작 시 구현이 시작됐거나 `complete.log`, `USER_REVIEW.md`, 기존 `*.log`가 있는 sibling의 `NN`은 고정한다. Archived sibling의 `NN`도 예약된 번호로 취급한다.
+   - 나머지 node에는 모든 predecessor보다 크면서 충돌하지 않는 가장 낮은 두 자리 index를 topological 순서대로 배정한다. 고정 predecessor 이하이거나 예약된 번호만 건너뛴다.
+   - Reindex 후 각 basename의 predecessor를 새 index로 치환하고 오름차순으로 기록한다. 독립 node는 `NN_`, dependent node는 `NN+PP[,QQ...]_`를 사용한다.
+   - 기존 dependent의 원래 predecessor를 실제 소비하는 child로 바꾼다. 전체 결과를 필요로 하면 마지막 closure child를 사용하고, 소비 child를 판단할 수 없으면 분리하지 않는다.
+   - 고정 index 때문에 dependency 순서를 만들 수 없거나 cycle, `99` 초과, 시작된 sibling 이동이 필요하면 분리하지 않는다.
+   - 예: 미착수 `01_core`, `03+01_api`, `04+01,03_integration`은 `01_core`, `02+01_api`, `03+01,02_integration`으로 정렬한다. 기존 `03`이 시작된 상태면 `03`은 이동하지 않는다.
+   - Reindex되는 sibling은 directory basename과 PLAN/review 안의 기존 task path·index·dependency 참조를 새 값으로 바꾼다. 구현 scope, checklist, 검증, routing은 바꾸지 않는다.
 
-4. **현재 Worker 형식으로 pair를 만든다**
-   - Build/review lane과 G는 원본을 유지하고 재라우팅하지 않는다.
-   - 현재 runtime-provided Plan model identity를 PLAN metadata와 review ledger에 동일하게 기록한다. Implementation/Review는 `pending`으로 둔다.
-   - PLAN은 `구현 에이전트 규칙` 네 bullet, 짧은 `배경`, 실행에 필요한 `구현 범위`, checklist, 항목, 수정 파일, 검증만 둔다. 원본에 `Archive Evidence Snapshot`이 있으면 구현에 필요한 finding과 affected path만 담당 child에 보존한다.
-   - 분석 파일 목록, routing 점수, 분할 과정, dependency 상태/경로와 전체 archive history를 Worker PLAN에 쓰지 않는다.
-   - CODE_REVIEW는 `agent-ops/skills/common/plan/templates/review-stub-template.md`의 compact Worker 구조를 사용한다. Product behavior/scope/contract/verification checkpoint만 넣고 dependency, `complete.log`, archive, finalization, review 전용 checklist는 넣지 않는다.
-   - PLAN과 CODE_REVIEW의 checklist 문구·순서와 검증 명령을 정확히 맞춘다.
+4. **현재 PLAN/CODE_REVIEW 형식을 유지한다**
+   - 각 child는 기존 PLAN을 복제한 뒤 자신의 scope만 남긴다. Header/task, title, background, `구현 체크리스트`, plan item, `수정 파일 요약`, `최종 검증`을 child 경계에 맞게 갱신한다. 기존 PLAN에 `분석 결과`가 있으면 읽은 파일·테스트 공백·심볼 참조·분할 판단·범위 결정 근거도 child 범위로 줄인다.
+   - `Roadmap Targets`는 전체 결과를 닫는 closure child 하나에만 둔다. `Agent UI Completion`도 해당 구현과 PASS evidence를 소유하는 child 하나에만 둔다. 소유 child를 정할 수 없으면 분리하지 않는다.
+   - 각 review는 기존 CODE_REVIEW를 복제한 뒤 header/task, 완료표, 구현 checklist, checkpoint, 검증 section을 matching PLAN과 맞춘다. 고정 안내와 review 전용 section의 문구는 유지하되 child task path와 future archive suffix 참조는 갱신한다.
+   - PLAN과 review는 입력에 이미 있는 section 구조를 유지하며 없는 section을 새로 만들지 않는다. 첫 task header 외의 HTML metadata comment는 출력에서 제거한다.
+   - PLAN과 review의 첫 줄은 동일한 `task`, `plan`, `tag`를 사용한다. Checklist 문구·순서와 검증 명령을 서로 일치시킨다.
+   - 기존 build/review lane, G, canonical basename과 `최종 라우팅` 값을 child에 그대로 유지한다. Strict-subset local refinement에서는 `finalize-task-routing`을 다시 실행하지 않는다.
 
-5. **한 transaction으로 교체한다**
-   - 모든 최종 pair를 먼저 메모리에서 완성한다. Task-group parent에 `STAGED_BATCH.md`를 쓰고, 각 영향받는 directory에는 `STAGED_PLAN.md`와 `STAGED_CODE_REVIEW.md`를 모두 쓴 뒤 교체를 시작한다.
-   - Marker에는 task group, Plan identity, old-to-new directory mapping, 최종 pair basenames를 기록한다. 중단 시 이 mapping만 재개하고 scope/index를 다시 결정하지 않는다.
-   - 교체되는 미착수 active pair는 기존 lane/G와 monotonic suffix로 archive한 뒤 directory를 필요한 최종 이름으로 옮긴다. 교체 pair의 `plan_number`는 그 archive 다음 suffix를 사용하고, 새 child는 기존 log가 없으면 `0`을 사용한다. 기존 log를 덮어쓰거나 수정하지 않는다.
-   - 모든 staged pair의 header, identity, checklist, 명령을 검증한 뒤 최종 basename으로 promote한다. 모든 pair가 확인된 뒤에만 `STAGED_BATCH.md`를 제거한다.
+5. **최종 pair로 직접 교체한다**
+   - 모든 child pair, sibling reindex, directory rename map을 먼저 메모리에서 완성하고 최종 경로·archive log 충돌을 확인한다.
+   - 원본 active review와 PLAN을 각 파일 basename의 lane/G와 다음 monotonic suffix를 사용해 같은 task directory의 `code_review_*.log`, `plan_*.log`로 archive한다.
+   - Reindex가 필요한 미착수 directory는 목적지가 비는 순서로 최종 basename으로 이동한다. 임시 directory나 별도 상태 파일이 필요한 충돌이면 분리하지 않는다.
+   - Indexed target은 첫 child가 최종 basename으로 재사용한다. Task-group root의 single-plan target은 원본 log를 root에 남기고 모든 child directory를 새로 만든다.
+   - 재사용 directory의 `plan` 번호와 future archive suffix는 원본 pair archive 후 log count를 사용한다. 새 child directory는 기존 log가 없으면 `0`을 사용한다.
+   - Child PLAN/CODE_REVIEW를 최종 routed basename에 직접 쓴다. 임시 상태나 복구용 Markdown을 만들지 않는다.
+   - 기존 파일이나 log를 덮어쓰지 않는다. 모든 최종 pair의 header, checklist, 검증 명령과 `predecessor NN < consumer NN`을 확인한다.
 
 6. **Readiness를 보고한다**
-   - 각 최종 directory의 encoded predecessor만 확인한다.
-   - 모두 충족되면 `implementation-ready`, 하나라도 미충족이면 `dependency-waiting`을 보고한다.
-   - Worker 또는 Review를 시작하지 않는다.
+   - 각 child directory의 encoded predecessor만 확인한다.
+   - 모두 충족되면 `implementation-ready`, 하나라도 미충족이면 `dependency-waiting`으로 보고한다.
+   - Worker, Review, 다음 sibling을 시작하지 않는다.
 
 ## 출력
 
@@ -72,8 +78,7 @@ Local plan refinement
 
 ## 금지
 
-- Inventory/validator script, compile, build, test, lint, formatter, smoke/E2E, live/remote 검증을 실행하지 않는다.
-- Source/test 재분석, verification 실행, package 설치, dependency 다운로드, cache warming을 하지 않는다.
-- `plan` 또는 `finalize-task-routing`으로 child를 재라우팅하지 않는다.
-- 관련 없는 active sibling 재인덱싱, repository 밖 staging, 전체 task group 복원을 하지 않는다.
-- Plan 밖 구현 범위를 추가하거나 child를 재귀 분리하지 않는다.
+- Source/test 재분석, compile, build, test, lint, formatter, smoke/E2E, live/remote 검증을 실행하지 않는다.
+- Package 설치, dependency 다운로드, cache warming을 하지 않는다.
+- Child 재귀 분리, cloud pair 분리, 다른 task group 또는 시작·완료 sibling 재인덱싱을 하지 않는다.
+- 별도 상태 파일, 임시 pair, repository 밖 복구 파일을 만들지 않는다.

agent-ops/skills/common/router.md

@@ -8,7 +8,7 @@
 - "마일스톤 완료해도 될지 검토", "현 마일스톤 종료 검토", "현재 마일스톤 닫고 다음 마일스톤 지정"처럼 종료 판단, spec sync, roadmap archive, 다음 Milestone 지정을 함께 요구하는 요청은 `complete-milestone`으로 보낸다. 이 흐름 안에서 `update-spec`을 필수 gate로 수행한다.
 - 구현 계획 요청에서 선택 Milestone의 구현 잠금이 남아 있으면 `plan`은 구현 계획을 만들지 않고 잠금 차단을 보고한다.
 - SDD 생성/갱신/잠금 해제는 `roadmap-sdd` 또는 `update-roadmap` 요청으로 처리한다.
-- 런타임이 `origin-task`/`complete-log` 단건 완료 이벤트를 전달한 경우는 `update-roadmap`으로 처리한다. PASS task 이동 뒤에는 archived `complete.log`의 `Finalization` 메타데이터를 idempotent event source로 사용해 중단된 전달을 재생할 수 있다.
+- 런타임이 `origin-task`/`complete-log` 단건 완료 이벤트를 전달한 경우는 `update-roadmap`으로 처리한다.
 - active/archive `complete.log`, 관련 파일, git history를 종합해 Milestone 작업 상태를 복구하거나 확인하는 요청은 `sync-milestone-workstate`로 처리한다.
 
 | 요청 키워드 | SKILL.md |
@@ -36,8 +36,8 @@
 | 이 마일스톤은 X가 끝나야 가능해, A 전까지 B 잠가둬, 잠금 해제 조건은 X야, X 프로젝트 작업 뒤에 현재 마일스톤 진행, 의존성 설정해, 외부 의존 잠금 | `agent-ops/skills/common/update-roadmap/SKILL.md` |
 | roadmap dependency 확인, locks.yaml 판별, 외부 의존 잠금 확인, unlock-ready 판별, 잠금 해제 조건 충족 여부 확인, roadmap-dependency-checker.sh | `agent-ops/skills/common/check-roadmap-dependency/SKILL.md` |
 | 지금 작업이 뭐지?, 현재 작업 분석, 어디까지 했지?, 로드맵상 현 위치, 현재 마일스톤 위치, current 기준 breadcrumb | `agent-ops/skills/common/analyze-roadmap-position/SKILL.md` |
-| 현재 plan들 세분화해, 현재 plan 세분화, 기존 plan 더 나눠, local plan 분리해 | `agent-ops/skills/common/refine-local-plans/SKILL.md` |
 | 계획 세워줘, 계획 작성해, 계획 만들어줘, 구현 계획, PLAN.md, plan, plan 작성해, plan 만들어줘 | `agent-ops/skills/common/plan/SKILL.md` |
+| 현재 plan들 세분화해, 현재 plan 세분화, 기존 plan 더 나눠, local plan 분리해 | `agent-ops/skills/common/refine-local-plans/SKILL.md` |
 | 최종 라우팅, task routing, cloud/local 재평가, lane/G 판단, G 등급 재평가, routed filename 결정 | `agent-ops/skills/common/finalize-task-routing/SKILL.md` |
 | 코드 리뷰해줘, 리뷰 진행해, 리뷰해줘, code review, CODE_REVIEW.md, 리뷰 루프 | `agent-ops/skills/common/code-review/SKILL.md` |
 | 커밋해줘, 푸시해줘, commit, push, 반영해줘 | `agent-ops/skills/common/commit-push/SKILL.md` |
@@ -45,15 +45,9 @@
 | agent-ops pull해, agent-ops 가져와, agentic-framework에서 가져와, agent-ops 내려받아 | `agent-ops/skills/common/sync-pull/SKILL.md` |
 | 도메인 업데이트, domain rule 갱신, 도메인 검토, domain 스캔 | `agent-ops/skills/common/update-domain-rule/SKILL.md` |
 
-Plan/review 역할 경계:
+라우팅 우선순위:
 
-- 선택한 task group에 `STAGED_BATCH.md`, `STAGED_PLAN.md`, 또는 `STAGED_CODE_REVIEW.md`가 있으면 `plan` 복구를 먼저 수행하며, marker가 남아 있는 동안 implementation/review를 시작하지 않는다.
-- PLAN/CODE_REVIEW 작성 또는 재작성이 요청 범위에 포함되면 `plan`을 선택한다. `plan`이 최종 단계에서 `finalize-task-routing`을 필수 호출한다.
+- 이미 생성된 미착수 local pair의 분할만 요청하면 `refine-local-plans`를 선택한다. 새 plan 작성이나 구현 범위 재분석이 포함되면 `plan`을 선택한다.
+- `refine-local-plans` 대상이 아닌 PLAN/CODE_REVIEW 작성 또는 재작성이 요청 범위에 포함되면 `plan`을 선택한다. `plan`이 최종 단계에서 `finalize-task-routing`을 필수 호출한다.
 - lane/G/canonical filename 판단만 요청되고 plan 문서 작성은 요청되지 않았을 때만 `finalize-task-routing`을 직접 선택한다.
-- plan, implementation, review는 서로 다른 모델이 한 역할씩 수행한다. 현재/root 모델은 다음 역할을 다른 모델에 맡길 수 있지만 직접 그 역할을 수행하지 않는다.
-- Runtime은 선택 task path와 역할별 model identity를 pair/handoff에 기록한다. 다음 역할 시작 전에 identity 중복을 거부하고 encoded predecessor를 다시 확인한다. 구현 소유 리뷰 섹션이 모두 채워지고 dependency가 충족된 `review-ready` 상태에서만 Review 모델을 시작한다.
-- Indexed task의 basename은 `NN_{subtask_name}` 또는 `NN+PP[,QQ...]_{subtask_name}`이어야 하고 모든 predecessor는 `NN`보다 작아야 한다. Runtime은 malformed 이름을 implementation에 전달하지 않고 Plan 이관 대상으로 돌린다. 유효한 `_`/`+PP[,QQ...]` dependency는 runtime이 해석하며, 모든 predecessor의 matching `complete.log`가 확인된 pair만 implementation에 전달한다. Worker에게 archive 검색이나 dependency 판정을 맡기지 않는다.
-- Plan은 PLAN/CODE_REVIEW pair 작성과 `implementation-ready`/`dependency-waiting` 판정, implementation은 리뷰 문서 완성, review는 후속 plan pair·`USER_REVIEW.md`·`complete.log` 중 하나를 남긴 뒤 끝난다.
-- WARN/FAIL 리뷰는 다른 Plan 모델이 후속 pair를 작성한 뒤 끝나며, 같은 리뷰 흐름에서 구현하지 않는다.
-- Review finalization 복구는 verdict가 append된 active review, partial archive, `complete.log`, resolved `user_review_*.log`, archived WARN/FAIL pair 같은 실제 산출물 조합으로 판별한다. 별도 transient review state 파일을 만들지 않으며, PASS 이동은 self-contained `complete.log`를 쓴 뒤 review 모델의 마지막 filesystem mutation으로 수행한다.
-- 정상 역할 종료 상태에는 `STAGED_BATCH.md`, `STAGED_PLAN.md`, `STAGED_CODE_REVIEW.md`가 없다. `USER_REVIEW.md`는 결정 대기 terminal/evidence이며, 해소 후 replan이면 `user_review_N.log`, 완료면 task archive로 수렴한다.
+- 코드 리뷰 요청은 `code-review`를 선택한다. WARN/FAIL follow-up은 `code-review -> plan -> finalize-task-routing` 순서를 유지한다.

agent-ops/skills/common/update-roadmap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: update-roadmap
-version: 1.24.0
+version: 1.24.2
 description: 로드맵 업데이트, 로드맵에 추가, 마일스톤 추가/갱신, phase/페이즈 변경, 전역 Milestone 실행 순서 갱신 요청에 사용한다. Roadmap-priority-queue-Phase-Milestone scaffold에서 target 없는 신규 작업의 규모를 판정하고 기존 Phase/Milestone/Epic/Task를 검색해 upsert한 뒤, 없을 때만 새 항목을 만들고 priority-queue.md 순서 동기화, 로컬 current.md 동기화, runtime m-task 완료 이벤트 반영, 완료 후보 검토중 전환, agent-ui 코드 동기화 Milestone의 종료 검토 시 구현됨 상태 반영, 완료 근거 충족 archive 이동, workspace 외부 의존 잠금 양방향 동기화를 처리한다.
 ---
 
@@ -119,6 +119,9 @@ agent-roadmap/
 - `ROADMAP.md`의 Phase 흐름은 실행 순서가 아니라 도메인/책임 영역의 구조적 지도다. 상태 그룹은 완료, 검토중, 진행중, 계획, 스케치 순서를 기본으로 하되 실제 다음 작업 선택은 `priority-queue.md`를 우선한다.
 - `PHASE.md`의 Milestone 흐름은 해당 Phase 안의 상태 정리 흐름이다. Phase를 가로지르는 실행 순서로 해석하지 않는다.
 - Epic heading은 `### Epic: [epic-id] <이름>` 형식으로 작성한다.
+- 새 Epic과 기능 Task를 추가하거나 구조를 갱신하는 기존 Epic에는 기능 Task를 최대 5개만 둔다. 갱신 범위 밖 기존 Epic은 자동으로 재구성하지 않는다.
+- 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 기존 Epic을 둘 이상으로 분리한다. 분리 후에도 독립 목표가 남으면 새 Milestone 후보로 둔다.
+- 갱신 범위에 포함된 기존 Epic이 이미 6개 이상이면 같은 기준으로 분리한다. 이때 기존 item-id는 사용자가 명시하지 않는 한 바꾸지 않는다.
 - Task는 `- [ ] [item-id] 설명` 또는 `- [x] [item-id] 설명` 형식으로 작성한다.
 - epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 해당 Milestone 안에서만 유일하면 된다.
 - 사용자가 epic-id 또는 item-id를 언급하면 해당 항목을 우선 anchor로 삼고, 기존 id는 명시적 요청 없이 바꾸지 않는다.
@@ -258,6 +261,7 @@ agent-roadmap/
 - 요청이 방향성, 문제의식, 컨셉, 운영 원칙 수준이고 기능 Task나 실행 범위가 아직 부족하면 새 항목의 상태는 `[스케치]`로 둔다.
 - `[스케치]` Phase/Milestone을 만들 때는 `승격 조건`에 `[계획]`으로 전환하기 위해 필요한 정의, 결정, 경계, 후속 구현 Milestone 후보를 체크리스트로 남긴다.
 - 가장 작은 충분한 단위 원칙을 따른다. 애매하면 새 Phase나 새 Milestone으로 키우지 말고, 기존 Milestone의 Epic/Task에 넣을 수 있는지 먼저 확인한다.
+- 기존 Epic에 기능 Task가 5개 있으면 새 Task를 추가하지 않는다. 여섯 번째 Task는 capability, 산출물, 의존성, 검증 경계 중 하나로 분리한 새 Epic에 배치하고, 분리된 Epic이 독립 목표면 새 Milestone 후보로 재판정한다.
 - 위치 지정이 있으면 anchor의 레벨을 먼저 확인한다.
 - `<epic-id> 아래`는 해당 Epic 아래 Task로 넣는다.
 - `<item-id> 앞/뒤`는 같은 Epic 안의 형제 Task로 넣는다.
@@ -389,7 +393,9 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
    - 새 Milestone은 해당 Phase의 `milestones/` 아래에 만든다.
    - 새 `[스케치]` Milestone은 `승격 조건` 섹션을 포함하고 `구현 잠금`은 `잠금`으로 둔다.
    - 새 Epic은 `기능` 아래 `### Epic: [epic-id] <이름>`으로 만든다.
-   - 새 Task는 관련 Epic 아래 `- [ ] [item-id] 설명`으로 만든다. 검증이 필요한 경우에만 같은 항목에 `검증: <명령/확인 방법/기대 결과>`를 붙인다.
+   - 새 Task는 관련 Epic의 기능 Task가 5개 미만일 때만 `- [ ] [item-id] 설명`으로 만든다. 검증이 필요한 경우에만 같은 항목에 `검증: <명령/확인 방법/기대 결과>`를 붙인다.
+   - 관련 Epic에 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 Epic을 분리한 뒤 새 Task를 배치한다. 분리된 Epic이 독립 목표면 새 Milestone 후보로 재판정한다.
+   - 갱신 범위에 포함된 기존 Epic이 6개 이상이면 새 Task를 쓰기 전에 같은 기준으로 Epic을 분리한다. 기존 item-id는 사용자가 명시하지 않는 한 유지한다.
    - 새 항목은 레벨별 탐색에서 적절한 기존 후보가 없을 때만 만든다.
    - 완료 체크는 evidence가 있을 때만 `[x]`로 바꾼다.
    - 모든 기능 Task와 Task 안에 명시된 검증이 evidence와 함께 `[x]`이어도 `구현 잠금`이 `해제`가 아니거나 미완료 `결정 필요` 항목이 있으면 Milestone 상태를 `[검토중]`으로 바꾸지 않는다. `완료 리뷰` 또는 `작업 컨텍스트`에 잠금 차단 항목을 남긴다.
@@ -432,7 +438,7 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
    - `agent-ui 상태 반영: 대기`가 아닌 Milestone 완료 리뷰에서 agent-ui 문서 status를 변경하지 않았는지 확인한다.
    - 각 Milestone의 `구현 잠금`에 SDD 필요 여부와 사유가 있는지 확인한다.
    - `SDD: 필요` Milestone은 SDD 문서 링크, SDD 파일 존재, 잠금 해제 조건, SDD 사용자 리뷰 상태가 일관되는지 확인한다. 사용자가 명시적으로 SDD 생성을 뒤로 미루지 않았는데 SDD 파일이 없으면 검증 실패로 본다.
-   - Epic heading과 Task id 형식이 맞는지 확인한다.
+   - Epic heading과 Task id 형식이 맞고, 새 Epic과 갱신 범위에 포함된 기존 Epic의 기능 Task 수가 최대 5개인지 확인한다. 6개 이상이면 검증 실패로 보고하고 Epic 분리를 요구한다.
    - 요청 규모가 판정되었고 결과 보고에 남았는지 확인한다.
    - 동일/유사 기존 항목을 검색했고 신규/업데이트 판정이 결과 보고에 남았는지 확인한다.
    - 자동 배치한 신규 작업이면 선택한 후보와 밀린 후보의 근거가 결과 보고에 포함되는지 확인한다.