sync: from iop v1.1.16

agent-ops/.version

@@ -1 +1 @@
-1.1.15
+1.1.16

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

@@ -1,6 +1,6 @@
 ---
 name: code-review
-description: Review completed implementation work in the current repository. Reads PLAN-{build_lane}-GNN.md and CODE_REVIEW-{review_lane}-GNN.md from the active task, reviews the actual changed source files, appends a verdict to the review file, then archives both files as .log. On PASS, writes complete.log summarising the full loop history and moves the completed task under agent-task/archive/YYYY/MM/. If Required or Suggested issues are found (FAIL or WARN), writes new routed plan/review files so the loop continues immediately. Nit-only findings may still PASS.
+description: Use for active task review requests such as 리뷰 진행해, 리뷰해줘, 코드 리뷰해줘, code review, CODE_REVIEW.md, or 리뷰 루프. Review the active PLAN/CODE_REVIEW pair, append PASS/WARN/FAIL, archive both active files, and create the required next state: PASS writes complete.log and moves the task to archive; WARN/FAIL immediately writes follow-up PLAN/CODE_REVIEW files. Never stop after verdict append.
 ---
 
 # Code Review
@@ -15,6 +15,14 @@ plan skill -> implementation -> code-review skill
      +----- issues found: new routed plan/review files
 ```
 
+## Core Loop Rules
+
+- Trigger: Korean or English active-task review requests, including `리뷰 진행해` and `리뷰해줘`, must use this skill when `agent-task/*/CODE_REVIEW-*-G??.md` exists.
+- Finalize every selected active review: append one verdict, archive the active review and plan files, then create exactly one next state before reporting.
+- Next state: `PASS` writes `complete.log` and moves the task under `agent-task/archive/YYYY/MM/`; `WARN` or `FAIL` writes the next active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md`.
+- Do not ask for confirmation before WARN/FAIL follow-up files. If details are uncertain, write the smallest concrete follow-up plan with file references and verification commands.
+- Recovery: if a prior turn appended a verdict without archive or next-state files, resume at Step 5 and finish finalization first.
+
 ## Workflow Contract
 
 Active work must live under `agent-task/{task_name}/` using routed filenames. This is the state protocol shared with the plan skill.
@@ -29,7 +37,10 @@ Filename rules:
 Multi-plan runtime contract:
 
 - Multi-plan work is represented as multiple task directories. Each directory owns exactly one normal active plan file and one normal active review file.
-- Directory names may encode runtime scheduling metadata. Preserve them verbatim; do not normalize, reinterpret, or choose execution order by agent judgment.
+- Multi-plan task directory names encode runtime scheduling metadata:
+  - `NN_{task_name}` has no runtime dependencies.
+  - `NN+PP[,QQ...]_{task_name}` depends on the listed earlier task indices.
+- 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 directory, review that directory even when other active review files exist.
 
 Review routing rules:
@@ -51,17 +62,6 @@ Directory states:
 
 The implementing agent never archives or deletes active files; archiving is this skill's responsibility.
 
-Finalization invariant:
-
-- Every review attempt that selects an active review file must end by archiving the active `CODE_REVIEW-*-G??.md` and `PLAN-*-G??.md` files.
-- A review is not complete when the verdict is appended. It is complete only after the required archive files and next-state files exist.
-- After archiving, exactly one next state is allowed:
-  - `PASS`: write `complete.log`, move `agent-task/{task_name}/` to `agent-task/archive/YYYY/MM/{task_name}/`, then complete the review-only checklist in the final archive path.
-  - `WARN` or `FAIL`: write the next active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md`; do not write `complete.log`.
-- Never stop after appending a verdict. Do not report to the user until archive, required next-state file writes, review-only checklist updates, and PASS task-directory archive moves are complete.
-- If the review result feels ambiguous, choose `WARN` or `FAIL` according to the severity rules, archive the current files, and write the next plan/review pair. Ambiguity is not a reason to leave active files unarchived.
-- If you notice that you already reported after only appending `PASS`, `WARN`, or `FAIL`, resume immediately: archive the active files, write `complete.log` or the follow-up plan/review pair, update the archived review checklist, then correct the user-facing report.
-
 ## Step 1 - Find Active Task
 
 Glob `agent-task/*/CODE_REVIEW-*-G??.md`:
@@ -148,16 +148,11 @@ Complete log template:
 - 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 Step 7, report:
-
-- Verdict.
-- Archive filenames.
-- Final task archive path under `agent-task/archive/YYYY/MM/`.
-
 For `WARN` or `FAIL`, 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>`.
+- Base the follow-up scope directly on the archived review findings. Keep it narrow and actionable.
 - Choose lane/grade again; preserve the prior route only when it was adequate, otherwise raise `GNN` and/or move `local -> cloud`.
 - Before choosing the follow-up route, apply this escalation gate:
   - If the archived plan was `local-*` and the verdict is `FAIL` for correctness, completeness, test coverage, or verification trust, move the follow-up build lane to `cloud` unless the issue is trivially deterministic and review-detectable without live environment behavior.
@@ -191,16 +186,12 @@ task={task_name}, plan={N}, tag={TAG}
 ## 이 파일을 읽는 리뷰 에이전트에게
 
 각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
-Review 완료 후 반드시 아래 순서로 아카이브하세요.
+리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.
 
-1. `CODE_REVIEW-{review_lane}-GNN.md` → `code_review_{review_lane}_GNN_N.log` (N = 기존 code_review_*.log 수)
-2. `PLAN-{build_lane}-GNN.md` → `plan_{build_lane}_GNN_M.log` (M = 기존 plan_*.log 수)
-3. PASS인 경우 `complete.log` 작성 후 `agent-task/archive/YYYY/MM/{task_name}/`로 task 디렉터리 이동. WARN/FAIL인 경우 새 routed plan + review 스텁 작성.
-
-판정 append만으로 review를 끝내면 안 됩니다. `PASS`, `WARN`, `FAIL` 모두 active plan/review 파일을 `.log`로 전환한 뒤 다음 상태 파일까지 만든 후에만 보고하세요.
-어떤 판정에서도 아카이브를 건너뛰지 마세요. PASS/WARN/FAIL 모두 `코드리뷰 결과` append 후 active plan/review 파일을 먼저 아카이브하고, 그 다음 `complete.log` 또는 다음 plan/review 파일을 작성해야 합니다.
-PASS에서는 `agent-ops/skills/common/code-review/templates/complete-log-template.md`의 섹션 순서와 필수 항목을 기준으로 `complete.log`를 작성하세요. 작성 후 현재 날짜의 `YYYY/MM` 기준으로 task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고, 최종 archive 경로의 `code_review_*.log`에서 `코드리뷰 전용 체크리스트`를 갱신한 다음 보고하세요.
-WARN/FAIL에서는 다음 상태 파일 작성 후 현재 task 경로의 archived `code_review_*.log`에서 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 체크한 다음 보고하세요.
+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` 작성 후 task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 다음 active plan/review 파일을 즉시 작성한다.
+4. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
 
 ---
 

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

@@ -1,4 +1,4 @@
 interface:
   display_name: "Code Review"
-  short_description: "Review task implementation"
-  default_prompt: "Use $code-review to review the active repository task and archive or continue the loop."
+  short_description: "Review and continue task loops"
+  default_prompt: "Use $code-review to review the active repository task, archive active files, and create complete.log or follow-up plan/review files."

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

@@ -31,14 +31,19 @@ Task directory naming rules:
 - A single-plan task uses `agent-task/{task_name}/` with a short snake_case task name.
 - If one plan is not enough, split the work into multiple task directories. Each 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 multiple folders, not multiple plan files inside one folder.
-- Multi-plan task directory names must start with the current task's execution-order index: `01_{task_name}`, `02_{task_name}`, `03_{task_name}`, and so on. The leading number is always the current task index and must increase across sibling task directories.
-- Use `_` after the index for a task that can start independently at that point: `01_{task_name}`, `03_{task_name}`.
-- Use `+` instead of `_` after the index for a task that depends on an earlier task: `02+{task_name}`. Do not put predecessor numbers in the directory name.
-- Record the exact predecessor task directory or directories in the plan's `의존 관계 및 구현 순서` section.
-- Example: split a common core plus two app integrations as `01_core`, `02+edge_integration`, `03+node_integration`. In both `02+...` and `03+...`, write that they depend on `agent-task/01_core`. The `+` marker does not mean `03+...` depends on `02+...`; if `03+...` also depends on `02+...`, say so explicitly in `의존 관계 및 구현 순서`.
-- Example: split three sequential tasks as `01_schema`, `02+migration`, `03+api`. In `02+migration`, list `agent-task/01_schema` as predecessor. In `03+api`, list `agent-task/02+migration` as predecessor.
-- Directory names are runtime scheduling metadata. Preserve them verbatim; do not normalize, reinterpret, or choose execution order by agent judgment.
-- Every split plan must include `의존 관계 및 구현 순서` and list predecessor task directories that must reach `complete.log` before implementation begins.
+- Multi-plan task directory names must start with a stable two-digit task index. The index must increase across sibling task directories for sorting, but it is not a serial execution dependency.
+- Use `NN_{task_name}` for a task with no runtime dependencies, e.g. `01_core`, `04_docs`, `05_ui`.
+- Use `NN+PP[,QQ...]_{task_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 multi-plan task directory.
+- The first `_` after the index or dependency list starts `{task_name}`. `{task_name}` stays short snake_case and may contain additional underscores.
+- Runtime scheduling reads only the directory name: `_` means `depends_on=[]`; `+` means `depends_on` is the comma-separated index list between `+` and the first `_`.
+- 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+{task_name}` without predecessor indices.
+- Example: split a common core plus two app integrations 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 as `01_schema`, `02+01_migration`, `03+02_api`.
+- Example: split independent docs/UI plus an integration 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`.
+- Preserve task directory names verbatim; do not normalize, reinterpret, or choose execution order by agent judgment.
 
 Routing rules:
 
@@ -154,7 +159,7 @@ Each plan item must include:
 
 Include `의존 관계 및 구현 순서` only when order matters.
 
-For split multi-plan work, `의존 관계 및 구현 순서` is mandatory in every generated plan. If a plan has a `NN+...` directory name, state which predecessor task directory or directories must produce `complete.log` before implementation starts.
+For split multi-plan work, the directory name is the runtime source of truth. If a plan has a `NN+PP[,QQ...]_...` directory name, `의존 관계 및 구현 순서` must echo the decoded predecessor task directories that must produce `complete.log` before implementation starts, and it must not add dependencies that are absent from the directory name.
 
 Quality rules:
 
@@ -210,16 +215,12 @@ task={task_name}, plan={N}, tag={TAG}
 ## 이 파일을 읽는 리뷰 에이전트에게
 
 각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
-review 완료 후 반드시 아래 순서로 아카이브하세요.
+리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.
 
-1. `CODE_REVIEW-{review_lane}-GNN.md` → `code_review_{review_lane}_GNN_N.log` (N = 기존 code_review_*.log 수)
-2. `PLAN-{build_lane}-GNN.md` → `plan_{build_lane}_GNN_M.log` (M = 기존 plan_*.log 수)
-3. PASS인 경우 `complete.log` 작성 후 `agent-task/archive/YYYY/MM/{task_name}/`로 task 디렉터리 이동. WARN/FAIL인 경우 새 routed plan + review 스텁 작성.
-
-판정 append만으로 review를 끝내면 안 됩니다. `PASS`, `WARN`, `FAIL` 모두 active plan/review 파일을 `.log`로 전환한 뒤 다음 상태 파일까지 만든 후에만 보고하세요.
-어떤 판정에서도 아카이브를 건너뛰지 마세요. PASS/WARN/FAIL 모두 `코드리뷰 결과` append 후 active plan/review 파일을 먼저 아카이브하고, 그 다음 `complete.log` 또는 다음 plan/review 파일을 작성해야 합니다.
-PASS에서는 `agent-ops/skills/common/code-review/templates/complete-log-template.md`의 섹션 순서와 필수 항목을 기준으로 `complete.log`를 작성하세요. 작성 후 현재 날짜의 `YYYY/MM` 기준으로 task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고, 최종 archive 경로의 `code_review_*.log`에서 `코드리뷰 전용 체크리스트`를 갱신한 다음 보고하세요.
-WARN/FAIL에서는 다음 상태 파일 작성 후 현재 task 경로의 archived `code_review_*.log`에서 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 체크한 다음 보고하세요.
+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` 작성 후 task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 다음 active plan/review 파일을 즉시 작성한다.
+4. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
 
 ---
 
@@ -312,7 +313,7 @@ Sections and their ownership:
 ## Final Checklist
 
 - `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` both exist under `agent-task/{task_name}/`.
-- Split work, if any, uses one task directory per plan/review pair with names like `01_core`, `02+edge_integration`, `03+node_integration`; predecessor details live in `의존 관계 및 구현 순서`, not in the directory name.
+- Split work, if any, uses one task directory per plan/review pair with names like `01_core`, `02+01_edge_integration`, `03+01_node_integration`; dependency details live in the directory name as `NN+PP[,QQ...]_task_name`.
 - Both first lines match `<!-- task={task_name} plan={N} tag={TAG} -->`.
 - Previous active files, if any, were archived with correct numeric suffixes.
 - Every plan item has problem, solution, checklist, test decision, and intermediate verification.

agent-ops/skills/common/router.md

@@ -6,7 +6,7 @@
 | domain rule 만들어줘, rules.md 생성, 새 도메인 규칙 | `agent-ops/skills/common/create-domain-rule/SKILL.md` |
 | skill 만들어줘, SKILL.md 생성, 새 스킬 추가 | `agent-ops/skills/common/create-skill/SKILL.md` |
 | 계획 세워줘, 구현 계획, PLAN.md, plan | `agent-ops/skills/common/plan/SKILL.md` |
-| 코드 리뷰해줘, code review, CODE_REVIEW.md, 리뷰 루프 | `agent-ops/skills/common/code-review/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` |
 | agent-ops 싱크해, agent-ops 동기화해, agentic-framework에 올려줘, agent-ops를 [프로젝트]로 싱크해 | `agent-ops/skills/common/sync-push/SKILL.md` |
 | agent-ops pull해, agent-ops 가져와, agentic-framework에서 가져와, agent-ops 내려받아 | `agent-ops/skills/common/sync-pull/SKILL.md` |