iop/agent-ops/skills/common/code-review/SKILL.md

name	description
code-review	Use for active task review requests such as 리뷰 진행해, 리뷰해줘, 코드 리뷰해줘, code review, CODE_REVIEW.md, USER_REVIEW.md resolution, NEXT_STATE.md recovery, 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.

Code Review

Purpose

Review the implementation phase of the plan-code-review loop:

plan model -> implementation model -> review model
     ^                                      |
     +-- different plan model on WARN/FAIL -+

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. NEXT_STATE.md is a transient recovery record with kind: pair-finalization or kind: user-review-resolution. It must exist before destructive transition work and is removed as the final filesystem mutation only after the selected branch is fully verified.

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.
• 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.

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.

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.

• 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.
• 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.

• Read USER_REVIEW.md, archived plan_*.log, and archived code_review_*.log in that task directory.
• Verify that the linked decision is resolved. If it is unresolved, leave USER_REVIEW.md unchanged. If it requires implementation, record the resolution in that file and write NEXT_STATE.md with kind: user-review-resolution, target: plan, task, plan number, source path, expected user_review_N.log, archived plan/review evidence paths, and forbidden implementation/review model identities. Archive it using N=0 or max(existing numeric suffix) + 1, then dispatch a different plan model. Verify the pair, update the applicable archived checklist, prepare the report, and remove the pending file as the final filesystem mutation.
• If the resolved decision closes the task, first select and preflight the exact collision-safe task archive path. Write NEXT_STATE.md with kind: user-review-resolution, target: complete, task, plan, completion_timestamp, archive_month, task_archive_path, source path, and archived evidence. Then update USER_REVIEW.md in place with that timestamp, resolved state, final verdict, loop history, fulfilled decision items, and closing evidence. Reuse the timestamp and archive path in finalization.
• 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 루프 이력.
• 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.

Workflow Contract

Active work must live under an active task directory using routed filenames. This is the state protocol shared with the plan skill.

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 used only for split work and follows the indexed directory naming contract, such as 01_core or 02+01_db.
• {subtask_name} is the short snake_case name after the index or dependency prefix inside {subtask_dir}.
• {task_name} in headers and templates means the active task path relative to agent-task/: either {task_group} for a single-plan task or {task_group}/{subtask_dir} for a split subtask.
• A single-plan task stores active files directly under agent-task/{task_group}/.
• Split work stores active files under agent-task/{task_group}/{subtask_dir}/; the parent agent-task/{task_group}/ is only the grouping folder and must not contain active plan/review files.

Filename rules:

• Plan file: PLAN-{build_lane}-GNN.md
• Review file: CODE_REVIEW-{review_lane}-GNN.md
• {lane} is only local or cloud; never put model names in filenames.
• GNN is a two-digit capability grade from G01 to G10; runtime maps lane+grade to current models externally.
• This skill reads the active routed names but does not choose follow-up lane/G. Follow-up basenames come only from plan executing finalize-task-routing.

Multi-plan runtime contract:

• Multi-plan work is represented as multiple subtask directories under one shared {task_group}. Each subtask directory owns exactly one normal active plan file and one normal active review file.
• Multi-plan subtask directory names encode runtime scheduling metadata:
  • NN_{subtask_name} has no runtime dependencies.
  • NN+PP[,QQ...]_{subtask_name} depends on the listed earlier task indices.
• Subtask directory names are the runtime dependency source of truth. Preserve them verbatim; do not normalize, reinterpret, infer extra dependencies from numeric order, or choose execution order by agent judgment.
• If the user/runtime names a task group, task path, or subtask directory that identifies exactly one active review file, review that directory even when other active review files exist.

Milestone task group contract:

• agent-task/m-<milestone-slug>/ is reserved for Milestone-linked work created by the plan skill.
• Do not treat normal task groups that do not start with m- as runtime milestone completion targets.
• For a selected task path, parse only the first path segment as {task_group}. If it matches ^m-[a-z0-9][a-z0-9-]*$, strip m- to get <milestone-slug>.
• Do not modify agent-roadmap/** for milestone routing during code-review finalization. Read only the Milestone path from Roadmap Targets and its SDD path when needed to verify SDD Evidence Map.
• 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:

• 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, and stops.
• The review agent is responsible for ensuring that the follow-up pair exists, even though the different plan model authors it.

Directory states:

State	Meaning
PLAN-*-G??.md + unfilled CODE_REVIEW-*-G??.md stub/placeholders	implementation-ready 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	review-ready; the review model may consume it
PLAN-*-G??.md + CODE_REVIEW-*-G??.md with appended verdict	Transitional; do not append another verdict and immediately 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
NEXT_STATE.md	Review finalization is in progress; resume its recorded target and do not start implementation
complete.log + *.log files	Task complete (PASS or user-review-resolved PASS), before final task-directory archive move
USER_REVIEW.md + *.log files	Linked Milestone decision is required
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

The implementing agent never archives or deletes active files; archiving is this skill's responsibility.

Step 1 - Find Active Task

Find active review files with both globs, excluding agent-task/archive/**:

• agent-task/*/CODE_REVIEW-*-G??.md
• agent-task/*/*/CODE_REVIEW-*-G??.md

Also note active user-review stops, excluding agent-task/archive/**:

• agent-task/*/USER_REVIEW.md
• agent-task/*/*/USER_REVIEW.md

Also find NEXT_STATE.md with the same one-level and two-level task globs. A selected pending file takes precedence over other classification: validate its task/plan identity and resume its recorded target. If several exist and no task path was selected, list them without mutation.

Classify the combined set of active CODE_REVIEW-*-G??.md and USER_REVIEW.md paths. Apply the first matching row:

Result	Action
Exactly one active path and it is CODE_REVIEW-*-G??.md	Review that task; exactly one PLAN-*-G??.md is normally expected beside it. If the review already has a verdict and its exact plan counterpart was just archived, use partial-archive recovery instead of reporting a missing plan.
Exactly one active path and it is USER_REVIEW.md, with a linked Milestone completion/resolution decision	Perform User Review Resolution for that task.
One or more active paths and every active path is USER_REVIEW.md, with no completion/resolution decision	Report that the linked Milestone decision is required and list the paths.
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.

An unfilled review stub is not review-ready. Leave the pair unchanged and return it to the implementation stage; this precondition check occurs before review begins.

Finalization-recovery scan covers active task paths plus the narrow archive exceptions agent-task/archive/*/*/*/NEXT_STATE.md and agent-task/archive/*/*/*/*/NEXT_STATE.md:

• Find task directories with NEXT_STATE.md, a verdict-appended active review, a partially archived pair, complete.log not yet moved, or matching archived plan/review logs with no active pair, USER_REVIEW.md, or complete.log. Inside archive, inspect only the pending file and its named artifacts; after a task move, resolve those artifact basenames under its persisted task_archive_path.
• Match plan/review artifacts by their task and plan headers, not 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.
• Resume a verdict or partial archive at Step 5. Move a pending complete.log task. For archived WARN/FAIL without a next artifact, dispatch the different plan model. For archived PASS or a valid gate, finish the missing complete.log or USER_REVIEW.md. If legacy recovery lacks NEXT_STATE.md, reconstruct it from the exact headers, verdict, and archive paths before continuing.
• A newly created unfilled follow-up pair already satisfies the prior review's Plan output; do not review it until implementation makes it review-ready.

Step 2 - Load Context

Count agent-task/{task_name}/code_review_*.log in the selected active task directory:

• 0: first review. Read the active review file, active plan file, every planned source file, related tests, and files importing/imported by changed files up to 2 levels deep.
• >=1: follow-up review. Start with git diff, git diff --cached, and git log --oneline -5, then expand to related callers, implementers, tests, and any planned files missing from the diff.

The diff is the starting point, not the boundary. Follow behavior and API connections far enough to judge correctness.

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.

Step 3 - Pre-Review Checklist

Before writing the verdict:

• Compare actual source files against every planned checklist item.
• 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.
• 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.
• 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 identity matches in both files 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.
• 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.
• 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.
• For follow-up reviews, compare diff against the plan and scan for unplanned changes, debug prints, dead code, TODOs, formatting-only noise, and unrelated edits.

Step 4 - Append 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.

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.
• 다음 단계: keep only the matching PASS, WARN/FAIL follow-up, or USER_REVIEW line.

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-directory 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

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.
• 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.

Verdict consistency:

• PASS requires all dimensions to be Pass and no Required/Suggested issues. Nit-only findings may still PASS only when every dimension remains Pass.
• 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

• 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.
• Compute and preflight both destinations before the first rename. Partial-archive recovery must reuse those expected destinations, not recompute after one rename.
• For a new archive, require both destinations to be absent. For partial recovery, require the existing destination to match the pending identity and only the remaining destination to be absent.
• Before the first rename, write NEXT_STATE.md with no placeholders: kind: pair-finalization, task, plan, verdict, target (plan, user-review, or complete), active basenames, expected archive paths, and the implementation/review model identities forbidden for a follow-up Plan model. For target: complete, also select, preflight, and persist completion_timestamp, archive_month, and the exact collision-safe task_archive_path. Reuse an identical pending file during recovery; reject conflicting contents.
• Rename the review, then the plan. Verify no active pair remains.

Step 6 - Post-Review Actions

For PASS, write agent-task/{task_name}/complete.log using the timestamp persisted in NEXT_STATE.md. If a USER_REVIEW.md stop is resolved as complete/PASS, use its fixed resolution timestamp. Write 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.
• 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.
• After verifying complete.log, keep the matching NEXT_STATE.md until task movement and archived checklist finalization finish.

For WARN or FAIL after archive:

• If the user-review gate triggered, write and verify USER_REVIEW.md, then keep the matching NEXT_STATE.md through Step 7 finalization.
• Otherwise dispatch a different plan model with the archived plan/review paths and wait for its implementation-ready result. Require one new routed PLAN/CODE_REVIEW pair at the same task path, verify it, then keep the matching NEXT_STATE.md through Step 7 finalization. The review model must not write that pair or edit product source/tests.
• Stop before implementation.

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.

Step 7 - Complete Review-Only Checklist, Move PASS Task, And Report

After Step 6:

• If verdict is PASS, create the parent of the exact task archive path persisted in NEXT_STATE.md, preflight it again, then move the selected active task directory there. Recovery must reuse that path and timestamp rather than the current date or a newly calculated suffix.
• Select collision suffixes before writing NEXT_STATE.md: if the natural monthly destination exists, append the next numeric suffix to the final path segment. Never overwrite or recalculate the persisted destination during recovery.
• After moving a split subtask, remove the active parent agent-task/{task_group}/ only if it is empty. If sibling subtask directories or other files remain, leave the parent task group in place.
• If verdict is PASS and {task_group} matches m-<milestone-slug>, do not resolve the roadmap target and do not call update-roadmap. After the task archive move, prepare completion event metadata: 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.
• 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 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 generated logs and terminal files. If any are ignored, repair the Agent-Ops block and re-check.
• Check every applicable item in 코드리뷰 전용 체크리스트; leave mutually exclusive verdict items unchecked.
• If any applicable item cannot be checked, finish the missing archive, follow-up pair handoff, complete.log, task-directory move, or USER_REVIEW.md write first.
• Do not recreate an active review file just to update this checklist; update the archived code_review_*.log.
• Complete every applicable archived checklist item and prepare the branch report with its final paths and metadata.
• Remove NEXT_STATE.md from the active task or moved archive as the final filesystem mutation only after the selected artifact, archived checklist, and report data are verified.
• Report only after confirming that NEXT_STATE.md no longer exists.

Report exactly one output: follow-up plan pair, USER_REVIEW.md, or complete.log. Include the relevant paths.

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
Test coverage	Required tests present and meaningful
API contract	Call sites, compatibility, docs
Code quality	No debug prints, dead code, leftover TODOs
Plan deviation	Deviations justified, no unrelated risk
Verification trust	Reported output matches actual code

Quality Rules

• Lead with findings; use specific file:line.
• Provide a concrete fix for every Required issue.
• 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.

Final Checklist

• Exactly one next-state outcome was selected: a follow-up PLAN/CODE_REVIEW pair, USER_REVIEW.md, or complete.log.
• NEXT_STATE.md was written before archive mutation, retained through branch finalization, and removed as the final filesystem mutation before reporting.
• {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 written from agent-ops/skills/common/code-review/templates/complete-log-template.md, then task directory moved under agent-task/archive/YYYY/MM/ with task-group path preserved for split work.
• PASS milestone task group: m-<milestone-slug> completion event metadata is prepared 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 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.
• PASS split: empty active parent agent-task/{task_group}/ removed after the subtask move; non-empty parent left in place.
• WARN/FAIL without user-review gate: a different plan model wrote one follow-up pair, the reviewer did not plan or implement, and the implementation-ready report is prepared.
• 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.
• 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.
• 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 user_review_N.log, a different plan model wrote one follow-up pair, and the implementation-ready report is prepared.
• The applicable review-agent-only finalization checklist was completed before reporting.