toki/appsok
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
appsok/agent-ops/skills/common/code-review/SKILL.md

45 KiB
Raw Blame History

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 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 writes follow-up PLAN/CODE_REVIEW files unless the user-review gate requires USER_REVIEW.md; user review resolution that closes the task writes complete.log before archive. Never stop after verdict append or user-review closure without writing the required next-state artifact.

Code Review

Purpose

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

plan skill -> implementation -> code-review skill
     ^                              |
     +----- issues found: new routed plan/review files

Implementation may stop early by filling the active review stub's 사용자 리뷰 요청 section from agent-ops/skills/common/_templates/implementation-user-review-request-section.md. This is the only implementation-time user-decision path: implementation must not ask the user directly, present choices in chat, or call a user-input tool such as request_user_input. Code-review validates that request and, when 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/**.
  • Finalize every selected active state: for CODE_REVIEW-*-G??.md, append one verdict, archive the active review and plan files, then create exactly one next state; for USER_REVIEW.md completion, update the stop state, write complete.log, and archive the task. Do not report before finalization is complete.
  • 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 writes the next active PLAN-{build_lane}-GNN.md and CODE_REVIEW-{review_lane}-GNN.md; 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.
  • A filled implementation-owned 사용자 리뷰 요청 is a review input, not a next state by itself. If it is a genuine user-only decision, user-owned external environment prerequisite, or scope conflict, the user-review gate triggers and this skill writes USER_REVIEW.md; if it is vague, unsupported, repo-fixable, or only missing evidence that a follow-up agent can produce by rerunning commands or collecting artifacts, write a normal WARN/FAIL follow-up plan instead.
  • 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, if details are uncertain, write the smallest concrete follow-up plan with file references and verification commands.
  • Recovery: if a prior turn appended a verdict without archive or next-state files, or resolved USER_REVIEW.md without complete.log, resume at the matching finalization step and finish the missing artifacts first.

User Review Gate

USER_REVIEW.md is a loop stop state for loop-limit exhaustion or user-owned blockers. Default to a normal WARN/FAIL follow-up; the gate requires positive evidence that another implementation/review agent cannot resolve the blocker without user action.

  • Compute review-number as count(agent-task/{task_name}/code_review_*.log) + 1 before archiving the active review.
  • If review-number >= 5 and the verdict is WARN or FAIL, stop the automatic loop and write USER_REVIEW.md.
  • If review-number == 1, the verdict is FAIL, and the blocking issue is a test environment problem that requires user action rather than repo-owned setup or evidence a follow-up agent can produce by rerunning commands or collecting artifacts, stop the automatic loop and write USER_REVIEW.md.
  • If the active review file has a filled 사용자 리뷰 요청 with 상태 other than 없음, and the blocker is a user-only decision, user-owned external environment prerequisite, or scope conflict that the repository and a capable next agent cannot safely resolve by code changes or verification reruns, stop the automatic loop and write USER_REVIEW.md.
  • If the active review file records a decision the implementer would otherwise ask as chat choices, treat it as an implementation-blocked user-review candidate when it has the required evidence and resume condition; do not ask that choice inline during review.
  • Treat a first-review failure as a test environment problem only with evidence from an attempted command: missing SDK/tool/runtime, unavailable external service, absent secret/credential, unsupported OS/device/interactive environment, or another prerequisite outside the repository. Record the exact command and stdout/stderr. Before claiming a tool is missing, require command -v <tool> or the project-equivalent check. Missing or non-verbatim verification evidence is a verification-trust failure, not a test environment problem.
  • Treat an implementation-owned 사용자 리뷰 요청 as valid only with specific decision questions, evidence, attempted commands/output or a reason commands could not run, and clear resume conditions. The not-run reason must identify user-owned action or an external prerequisite; agent execution limits, missing handoff evidence, or incomplete verification records become normal WARN/FAIL follow-up plans when a capable follow-up lane can produce the evidence.
  • Do not classify repo-owned setup bugs or verification evidence gaps as environment problems. If a manifest, bootstrap script, test fixture, documented project entrypoint, or follow-up agent can provide the dependency or evidence, write a normal follow-up plan instead.
  • 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, and user decision options.

User Review Resolution

When an active USER_REVIEW.md exists and the user 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.
  • Verify the user 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 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 user has completed and approved the task.

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.

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 read or modify agent-roadmap/** for milestone routing during code-review finalization.
  • Do not call update-roadmap from this skill. The runtime consumes the PASS completion event, checks current state, resolves the active Milestone, and calls update-roadmap if needed.
  • For m-<milestone-slug> PASS tasks, report the original active task path, final archive path, complete log path, task group, and milestone slug so the runtime has deterministic event inputs.

Review routing rules:

  • Route reviews so a normal mixed backlog can use both lanes substantially. This is not a per-review quota; neither local nor cloud is the default catch-all.
  • local: first-pass and review-detectable work, including multi-file or API/call-site reviews when scope and required context are bounded and verification can be rerun or reasoned about locally.
  • local-G01 through local-G10 and cloud-G01 through cloud-G10 are valid. Do not treat high grade alone as an implicit cloud route; context volume is separate lane evidence.
  • Repair non-behavioral review artifact drift during review instead of failing solely for it when implementation correctness, tests, and contracts remain judgeable.
  • cloud: reviews requiring stronger-than-local judgment, larger-than-local context, or evidence recovery: weak verification that review cannot compensate for, security/auth, storage/migration, concurrency, protocol/schema, broad cross-domain behavior with hard-to-review failure modes, repeated non-trivial Required issues, or untrusted verification evidence.
  • cloud-G07 or higher is mandatory only when terminal-agent or external interactive behavior is central and cannot be made deterministic for local review, or when the review requires more source/test/diff/log context than local can hold without omitting material evidence: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, terminal benchmark-style tasks, real bin/smoke/integration failures after unit tests passed, TUI/PTY/browser/screen repaint/cursor stream behavior, rerun-mismatched verification trust failures, or very large cross-module/cross-domain changes that cannot be safely split for review.

Directory states:

State Meaning
PLAN-*-G??.md + unfilled CODE_REVIEW-*-G??.md stub/placeholders Implementation is not judgeable; review should fail completeness if invoked
PLAN-*-G??.md + CODE_REVIEW-*-G??.md with filled 사용자 리뷰 요청 Implementation claims a user-only blocker; review validates the request and writes USER_REVIEW.md only if justified
PLAN-*-G??.md + filled CODE_REVIEW-*-G??.md Ready for code-review skill
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; user decision is required 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 *.log files (no complete.log) Task terminated mid-loop or abandoned

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

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 expected beside it.
Exactly one active path and it is USER_REVIEW.md, with a user-supplied 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 user decision is required and list the paths.
No active paths Stop and report that no active review exists.
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 ask which task to review or resolve; do not choose by agent judgment.

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.

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.

Step 3 - Pre-Review Checklist

Before writing the verdict:

  • Compare actual source files against every planned checklist item.
  • Compare the plan 구현 체크리스트 and review stub 구현 체크리스트; repair non-behavioral drift when implementation remains judgeable.
  • If the plan or review stub has Spec Targets, read the referenced SDD and compare implementation evidence against the listed Acceptance Scenario ids and Evidence Map.
  • 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; repair clear artifact drift when evidence supports completion.
  • Treat review artifact gaps as failures only when they prevent judging implementation correctness, tests, contracts, or verification trust.
  • Read the 사용자 리뷰 요청 section. If 상태 is not 없음, validate the exact decision needed, blocker evidence, command output or not-run reason, why automatic follow-up cannot resolve it, and resume condition before deciding whether the user-review gate triggers.
  • 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.

Required fields:

  • 종합 판정: exactly PASS, WARN, or FAIL.
  • 차원별 평가: Pass/Warn/Fail for correctness, completeness, test coverage, API contract, code quality, plan deviation, verification trust. If Spec Targets exists, 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. 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, 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; directly repair obvious non-behavioral cases when safe, otherwise record without 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

Archive is mandatory for PASS, WARN, and FAIL. Before the archive order, 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.

Archive order is fixed:

  1. Count existing code_review_*.log as N; rename CODE_REVIEW-{review_lane}-GNN.md to code_review_{review_lane}_GNN_N.log.
  2. Count existing plan_*.log as M; rename PLAN-{build_lane}-GNN.md to plan_{build_lane}_GNN_M.log.

After archiving, neither active .md file remains unless Step 6 writes a follow-up plan/review or USER_REVIEW.md.

Step 6 - Post-Review Actions

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.
  • 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 plan or review log contains Spec Targets, copy it into complete.log as Spec Completion. Include the SDD path, completed Acceptance Scenario ids, archived plan/review log paths, and verification evidence. If there is no Spec Targets section, remove the optional Spec Completion template 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, apply the user-review gate before writing follow-up files.

If the user-review gate triggers:

  • Write agent-task/{task_name}/USER_REVIEW.md from agent-ops/skills/common/code-review/templates/user-review-template.md.
  • Fill every placeholder. Use loop-limit, environment-blocked, or implementation-blocked as the reason type.
  • Include all available archived loop history in chronological order, the current archived plan/review log paths, the final verdict, review number, issue summary, blocking evidence, and the exact user decision needed.
  • Do not write a new active PLAN-{build_lane}-GNN.md or CODE_REVIEW-{review_lane}-GNN.md.
  • Do not write complete.log.
  • If the task group is m-<milestone-slug>, report that the milestone task is blocked on user review; do not emit PASS completion metadata and do not call update-roadmap.

If the user-review gate does not trigger, write new routed plan/review files using the plan skill format:

  • New plan number is the count of plan_*.log after archive.
  • Header tag is REVIEW_<PARENT_TAG>.
  • If the selected task group is m-<milestone-slug>, write the follow-up plan/review under the same m-<milestone-slug> task group.
  • Base the follow-up scope directly on the archived review findings. Keep it narrow and actionable.
  • Choose lane/grade again; preserve the prior route when it was adequate. Raise local-GNN for explicit, deterministic, review-detectable follow-ups, but move local -> cloud when the failure exposes reasoning, risk, evidence, or context-volume gaps that local review should not own.
  • If the finding is only missing or untrusted verification evidence that an appropriate follow-up lane can produce by rerunning commands or collecting artifacts, do not write USER_REVIEW.md solely for that reason. Write a follow-up plan that reruns the exact commands in an appropriate lane and records actual stdout/stderr.
  • If follow-up verification involves mobile/UI hangs, timeouts, or no progress for 2 minutes, stop blind retries; require focused rerun output plus screenshot/window/UI-tree evidence path, or the exact reason capture is impossible.
  • Write an Archive Evidence Snapshot section in every WARN/FAIL follow-up plan. Copy enough prior-loop evidence from the archived plan/review logs for the next implementer to act without rereading archive by default: current archived plan/review log paths, verdict, Required/Suggested/Nit summary, affected files, verification evidence, and any roadmap/spec carryover. If exact prior context is still required, cite the specific archive file paths allowed to read; do not instruct the implementer to search agent-task/archive/** broadly.
  • Copy the follow-up plan's Archive Evidence Snapshot section exactly into the follow-up review stub.
  • Before choosing the follow-up route, apply this escalation gate:
    • If the archived plan was local-* and the verdict is FAIL for correctness, completeness, test coverage, or verification trust, keep the follow-up on local with a higher grade when the issue is explicit, deterministic, and review-detectable; move to cloud only when the failure shows local capability or evidence trust is likely insufficient.
    • If the follow-up work is terminal-agent work that cannot be reduced to deterministic commands and evidence, use cloud-G07 or higher.
    • If unit tests passed but a real bin/smoke/integration command failed and local follow-up cannot isolate the failure with deterministic evidence, use cloud-G07 or higher.
    • If the task depends on interactive TUI/PTY/browser/external CLI behavior, screen repaint/cursor stream parsing, or live command-palette state that cannot be captured deterministically, use cloud-G07 or higher.
    • If the follow-up requires more source/test/diff/log context than local can hold without dropping material evidence, or the failure spans broad cross-module/cross-domain context that cannot be safely split, use cloud-G07 or higher.
    • If verification evidence is missing, reconstructed, stale, untrusted, or mismatched on rerun, use a local follow-up only when exact commands and actual stdout/stderr capture are enough; use cloud-G07 or higher when evidence trust recovery needs stronger diagnosis.
  • FAIL: one plan item per Required issue.
  • WARN: one grouped plan item for Suggested issues, plus related Nit issues if useful.
  • Each plan item needs problem, solution with before/after when non-trivial, checklist, test decision, intermediate verification.
  • The follow-up plan and review stub must contain matching 구현 체크리스트 item text/order, including the final mandatory CODE_REVIEW-*-G??.md completion item.
  • The follow-up plan's implementer instructions and review stub must forbid direct user prompts and include the implementation-time 사용자 리뷰 요청 stop path so the next implementer can act without reading the plan skill.
  • Copy agent-ops/skills/common/_templates/implementation-user-review-request-section.md into the follow-up review stub's 사용자 리뷰 요청 section.
  • If the archived plan had Roadmap Targets and the follow-up still works toward the same Milestone Task completion, copy that section into the follow-up plan and review stub. If the follow-up intentionally no longer claims roadmap Task completion, omit the section and explain why in the follow-up plan 범위 결정 근거.
  • If the archived plan had Spec Targets and the follow-up still works toward the same SDD Acceptance Scenario completion, copy that section into the follow-up plan and review stub. If the follow-up no longer claims scenario completion, omit it and explain why in 범위 결정 근거.

Routed review stub template (fill {…} placeholders; everything else is fixed and must not be changed by the implementing agent):

<!-- task={task_name} plan={N} tag={TAG} -->

# Code Review Reference - {TAG}

> **[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 by a user-only decision, user-owned external environment prerequisite, or scope conflict, fill `사용자 리뷰 요청` with evidence and stop with active files in place; code-review decides whether to write `USER_REVIEW.md`. Evidence gaps that a follow-up agent can close by rerunning commands or collecting artifacts are normal follow-up issues, not user-review blockers by themselves.
> Do not ask the user directly, present choices in chat, or call `request_user_input` during implementation; record the needed decision in `사용자 리뷰 요청` and stop for code-review.
> 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={YYYY-MM-DD}
task={task_name}, plan={N}, tag={TAG}

{copy the follow-up plan's Roadmap Targets section exactly if present; omit this block if the follow-up plan has no Roadmap Targets}
{copy the follow-up plan's Spec Targets section exactly if present; omit this block if the follow-up plan has no Spec Targets}
{copy the follow-up plan's Archive Evidence Snapshot section exactly if present; omit this block if the follow-up plan has no Archive Evidence Snapshot}

## 이 파일을 읽는 리뷰 에이전트에게

> **[REVIEW AGENT ONLY]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.

각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.

1. 판정을 append한다.
2. `CODE_REVIEW-{review_lane}-GNN.md` → `code_review_{review_lane}_GNN_N.log`, `PLAN-{build_lane}-GNN.md` → `plan_{build_lane}_GNN_M.log`로 아카이브한다.
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 user-review gate를 확인한 뒤 다음 active plan/review 파일 또는 `USER_REVIEW.md`를 작성한다. `USER_REVIEW.md`가 사용자 결정으로 완료/PASS 해소되면 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log` 작성 후 archive 이동한다.
4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.

---

## 구현 항목별 완료 여부

| 항목 | 완료 여부 |
|------|---------|
| [{TAG}-1] {item description} | [ ] |
| [{TAG}-2] {item description} | [ ] |

## 구현 체크리스트

{copy the follow-up plan's 구현 체크리스트 items exactly, preserving order and checkbox text}

## 코드리뷰 전용 체크리스트

> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.

- [ ] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
- [ ] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
- [ ] active `CODE_REVIEW-*-G??.md`를 `code_review_{review_lane}_GNN_N.log`로 아카이브한다.
- [ ] active `PLAN-*-G??.md`를 `plan_{build_lane}_GNN_M.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이고 user-review gate가 트리거되지 않았으면 다음 active `PLAN-{build_lane}-GNN.md`와 `CODE_REVIEW-{review_lane}-GNN.md`를 작성하고 `complete.log`를 작성하지 않는다.
- [ ] USER_REVIEW이면 `agent-ops/skills/common/code-review/templates/user-review-template.md` 기준으로 `USER_REVIEW.md`를 작성하고 active `PLAN-*.md`, `CODE_REVIEW-*.md`, `complete.log`를 남기지 않는다.
- [ ] USER_REVIEW가 사용자 결정으로 완료/PASS 해소되면 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log`를 작성한 뒤 task directory를 archive로 이동한다.

## 계획 대비 변경 사항

_구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께 기록한다._

## 주요 설계 결정

_구현 에이전트가 주요 설계 결정 사항을 기록한다._

## 사용자 리뷰 요청

_기본값은 `없음`이다. 구현 중 사용자 결정, 사용자 소유 외부 환경/secret/서비스 준비, 또는 계획 범위 변경 없이는 안전하게 진행할 수 없으면 아래 항목을 실제 내용으로 교체하고, 구현을 중단한 뒤 active 파일을 그대로 둔 채 리뷰를 요청한다. 구현 에이전트는 사용자에게 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다. 후속 에이전트가 명령 재실행이나 산출물 수집으로 해소할 수 있는 검증 증거 공백만으로는 사용자 리뷰 요청을 작성하지 않는다._

- 상태: 없음
- 사유 유형: 없음
- 결정 필요: 없음
- 차단 근거: 없음
- 실행한 검증/명령: 없음
- 자동 후속 불가 이유: 없음
- 재개 조건: 없음

## 리뷰어를 위한 체크포인트

{pre-filled from plan — one bullet per review focus area}

## 검증 결과

_구현 에이전트가 각 중간 검증 및 최종 검증 명령 실행 후 출력을 여기에 붙여 넣는다._

필수 규칙:
- 검증 명령은 고정된 계약이다. 임의로 대체하지 않는다.
- 대체가 필요하면 `계획 대비 변경 사항`에 이유와 대체 명령을 기록한다.
- `검증 결과`에는 실제 stdout/stderr를 붙여 넣는다.
- 사용자 리뷰 요청으로 명령을 끝까지 실행하지 못했다면 `사용자 리뷰 요청`에 실행한 명령, 실제 출력, 미실행 명령의 사유를 기록한다.
- mobile/UI hang, timeout, 또는 2분 무진행은 blind retry를 중단하고 focused rerun 명령과 screenshot/window/UI-tree evidence path를 남기며, 불가능하면 정확한 사유를 남긴다.

### {TAG}-1 중간 검증

$ {verification command from plan} (output)


### 최종 검증

$ {final verification command from plan} (output)


---

> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
> If anything is blank, go back and fill it in before saving this file.
> Leave review-agent-only sections unchanged.

Sections and their ownership:

섹션 소유자 설명
헤더 주석, 개요(date/task/plan/tag), 리뷰 에이전트 지시 스텁 생성 시 고정 구현 에이전트가 수정하거나 실행하지 않음
Roadmap Targets follow-up plan에서 복사해 스텁 생성 시 고정 구현 에이전트가 수정하지 않음; PASS 시 code-review가 complete.log의 Roadmap Completion으로 복사
Spec Targets follow-up plan에서 복사해 스텁 생성 시 고정 구현 에이전트가 수정하지 않음; PASS 시 code-review가 complete.log의 Spec Completion으로 복사
Archive Evidence Snapshot follow-up plan에서 복사해 스텁 생성 시 고정 구현 에이전트의 기본 이전 루프 컨텍스트; 추가 확인이 필요할 때 여기에 명시된 archive 파일만 좁게 읽음
구현 항목별 완료 여부 (항목명) 스텁 생성 시 고정 [ ] → [x] 체크만 구현 에이전트가 수행
구현 체크리스트 (항목 텍스트/순서) follow-up plan에서 복사해 스텁 생성 시 고정 구현 에이전트가 [ ] → [x] 체크만 수행; 마지막 체크박스는 저장 전 필수
코드리뷰 전용 체크리스트 Review agent only Implementing agent must not modify or check this section
계획 대비 변경 사항, 주요 설계 결정 구현 에이전트가 채움 placeholder 텍스트를 실제 내용으로 교체
사용자 리뷰 요청 구현 에이전트가 채움 진행에 사용자 입력이 필요하지 않으면 상태: 없음 유지; 구현 중 직접 질문은 금지; 필요하면 결정 항목, 근거, 명령 출력, 자동 후속 불가 이유, 재개 조건을 기록
리뷰어를 위한 체크포인트 스텁 생성 시 고정 계획에서 추출한 리뷰 포인트
검증 결과 (섹션 제목 + 명령) 스텁 생성 시 고정 실행 출력만 구현 에이전트가 채움; 명령 변경은 계획 대비 변경 사항에 기록
코드리뷰 결과 리뷰 에이전트가 append 스텁에 포함하지 않음

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

After Step 6:

  • If verdict is PASS, determine archive month from the current completion date as YYYY/MM, create the needed archive parent directories, then move the selected active task directory agent-task/{task_name}/ to agent-task/archive/YYYY/MM/{task_name}/. For split work, the selected active task directory is the subtask directory, and the archive must preserve the task group path, e.g. agent-task/refactoring/01_core/ moves to agent-task/archive/YYYY/MM/refactoring/01_core/.
  • Do not overwrite an existing archive directory. If agent-task/archive/YYYY/MM/{task_name}/ already exists, append the next numeric suffix to the final path segment: single-plan agent-task/archive/YYYY/MM/{task_group}_1/, split-plan agent-task/archive/YYYY/MM/{task_group}/{subtask_dir}_1/, and so on.
  • After moving a split subtask, remove the active parent agent-task/{task_group}/ only if it is empty. If sibling subtask directories or other files remain, leave the parent task group in place.
  • If verdict is PASS and {task_group} matches m-<milestone-slug>, do not resolve the roadmap target and do not call update-roadmap. Report completion event metadata after the task archive move: origin-task=agent-task/{task_name} from the original active task path, task-group={task_group}, milestone-slug=<milestone-slug>, final archive path, complete.log path, 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.
  • 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 user decides how to resume, replan, defer, or abandon the task.
  • If USER_REVIEW.md is later resolved as complete/PASS by user 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}/code_review_{review_lane}_GNN_N.log, 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}/code_review_{review_lane}_GNN_N.log.
  • 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-directory move, follow-up plan/review write, 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 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; 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
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 follow-up plans about verification trust, specify deterministic commands, for example rg --sort path, and forbid repo-local tool artifacts.

Final Checklist

  • code_review_{review_lane}_GNN_N.log exists with verdict appended.
  • plan_{build_lane}_GNN_M.log exists.
  • .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 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 with Spec Targets: complete.log contains Spec Completion with SDD path, Acceptance Scenario ids, archived plan/review evidence, and verification evidence.
  • PASS without Roadmap Targets: complete.log omits Roadmap Completion and reported metadata says roadmap-completion=none.
  • 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: new active PLAN-{build_lane}-GNN.md and CODE_REVIEW-{review_lane}-GNN.md created with matching headers and matching 구현 체크리스트; no complete.log.
  • WARN/FAIL follow-up: new active plan and review stub contain identical Archive Evidence Snapshot sections with prior archived plan/review log paths, verdict, issue summary, affected files, verification evidence, and specific archive paths allowed for narrow reread when needed.
  • 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 user decision needed.
  • USER_REVIEW resolved as PASS: archived task contains both resolved USER_REVIEW.md and complete.log.
  • The applicable review-agent-only finalization checklist was completed before reporting.