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

agent-ops/.version

@@ -1 +1 @@
-1.1.18
+1.1.19

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

@@ -26,11 +26,26 @@ Filename rules:
 - `{lane}` is only `local` or `cloud`; never put model names in filenames.
 - `GNN` is a two-digit capability grade from `G01` to `G10`; the runtime maps lane+grade to current models externally.
 
+Split decision policy:
+
+- Default to multiple task directories. Before writing any plan, decide whether the work has smaller independently reviewable implementation units.
+- If there is any natural dependency boundary, ownership boundary, subsystem boundary, API-vs-call-site phase, test strategy split, or independently reviewable risk, write multiple task directories.
+- A single plan is an exception. Use one only when all of these are true: the work is one coherent implementation unit, it has one primary ownership boundary, it has no prerequisite subtask, splitting would create artificial coordination overhead, and the whole change remains easy to review at once.
+- When uncertain, split. Do not choose a single plan merely because it is shorter to write.
+- Record the split decision in the plan. For a single plan, explicitly state why each applicable split boundary does not require a separate task. For multi-plan output, list each sibling task directory and its dependency relationship.
+
+Split gates:
+
+- Split when the work combines shared API/foundation changes with broad call-site rollout. Put the API/foundation in an earlier task and the rollout in dependent task(s).
+- Split when the work touches multiple domains or ownership boundaries, unless the change is purely mechanical and trivially reviewable.
+- Split when different parts can be verified with different focused tests or have different risk profiles.
+- Split when a likely failure in one part would force rewriting unrelated parts of the plan.
+- Split when one part can produce a useful `complete.log` before another part starts.
+
 Task directory naming rules:
 
 - A single-plan task uses `agent-task/{task_name}/` with a short snake_case task name.
-- Prefer splitting before writing. A single-plan task is allowed only when the work is one coherent implementation unit with one primary ownership boundary, no prerequisite subtask, and a reviewable blast radius.
-- If the work can be decomposed by dependency, ownership boundary, subsystem, API-vs-call-site phase, test strategy, or independently reviewable risk, split it into multiple task directories. Each directory owns exactly one normal active plan file and one normal active review stub.
+- When split gates require decomposition, create 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 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`.
@@ -46,15 +61,6 @@ Task directory naming rules:
 - 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.
 
-Split-first gates:
-
-- Before choosing a single plan, explicitly ask: "Could this be split into smaller independently reviewable implementation units?" If yes, split.
-- Split when a plan would require both shared API/foundation changes and broad call-site rollout. Put the API/foundation in an earlier task and the rollout in dependent task(s).
-- Split when a plan touches multiple domains or ownership boundaries, unless the change is purely mechanical and trivially reviewable.
-- Split when different parts can be verified with different focused tests or different risk profiles.
-- Split when a likely failure in one part would force rewriting unrelated parts of the plan.
-- Single-plan bias is acceptable only for narrow fixes, one-file/small-file-cluster refactors, or tightly coupled changes where splitting would create artificial coordination overhead.
-
 Routing rules:
 
 - Build defaults to `local` when the plan is explicit, tests are runnable, and failure is review-detectable.
@@ -93,7 +99,7 @@ The routed plan file is the loop entry point. A missing active plan normally mea
 
 Use short snake_case task names, e.g. `api_refactor`.
 
-Before writing a single plan, record why the split-first gates did not require multiple task directories. When the work must be split into multiple plans, choose directory names using the task directory naming rules above. Do not put multiple active plan files in one task directory.
+Before choosing plan files or task directory names, apply the split decision policy above. When the policy allows a single plan, record the exception rationale. When the policy requires multiple plans, choose directory names using the task directory naming rules above. Do not put multiple active plan files in one task directory.
 
 ## Step 2 - Analyze Before Writing
 
@@ -102,7 +108,7 @@ Complete all items below before creating any files. Work through them in order;
 - [ ] **Read all source files in full** — read every source file the change will touch, whole file. No partial reads.
 - [ ] **Read all test files in full** — read every test file that exercises the changed behavior.
 - [ ] **Assess test coverage** — for each behavior change, explicitly record whether existing tests cover it.
-- [ ] **Assess split boundaries** — identify dependency boundaries, ownership boundaries, API-vs-call-site phases, and independently verifiable subwork. If any split-first gate applies, write multiple task directories instead of one plan.
+- [ ] **Assess split boundaries first** — identify dependency boundaries, ownership boundaries, API-vs-call-site phases, test strategy splits, risk profile splits, and independently verifiable subwork before selecting plan files. If any split gate applies or the decision is uncertain, write multiple task directories instead of one plan.
 - [ ] **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.
@@ -153,7 +159,7 @@ Required sections:
   - `읽은 파일`: list every source and test file read during analysis, with path.
   - `테스트 커버리지 공백`: 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.
-  - `분할 판단`: state whether the split-first gates were evaluated. For a single plan, explain why the work is still one coherent reviewable unit. For multi-plan output, list each sibling task directory and dependency relationship.
+  - `분할 판단`: state that the split decision policy was evaluated before choosing plan files. For a single plan, explain why each relevant split gate does not apply and why single-plan coordination is safer than splitting. For multi-plan output, list each sibling task directory and dependency relationship.
   - `범위 결정 근거`: 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.
   - `빌드 등급`: state the decided lane and GNN grade with a one-line rationale.
 - `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per plan item, one item for all intermediate/final verification, and make the final item exactly: `- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.` Copy this checklist into the review stub's `구현 체크리스트` section with the same item text and order.