sync: agent-ops from agentic-framework v1.1.174
This commit is contained in:
parent
1f8ac5117c
commit
c586935611
22 changed files with 850 additions and 269 deletions
|
|
@ -8,7 +8,7 @@
|
|||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, 또는 plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우에만 필요한 파일을 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우, 또는 plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다.
|
||||
- `agent-roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-ui/` 디렉터리가 있는 프로젝트에서도 `agent-ui/definition/archive/**`와 `agent-ui/archive/user-review/**`는 일반 작업에서 읽지 않는다. UI 과거 결정, 복원, 비교, 해결된 user review 확인이 필요한 경우에만 `agent-ops/rules/common/rules-agent-ui.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-spec/` 디렉터리가 있는 프로젝트에서 현재 구현 스펙 확인, 기존 기능 변경, 완료 검토, 구현 스펙 생성/갱신 요청은 세션 1회 `agent-ops/rules/common/rules-agent-spec.md`를 읽고, `agent-spec/index.md`와 매칭되는 spec 문서만 읽는다.
|
||||
|
|
@ -52,4 +52,4 @@
|
|||
|
||||
**테스트 실행/검증 작업이 포함된 경우, 작업 환경에 맞게 최초 1회 읽고 수행한다. 환경 미지정은 local로 본다.**
|
||||
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, 또는 plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우에만 필요한 파일을 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우, 또는 plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다.
|
||||
- `agent-roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-ui/` 디렉터리가 있는 프로젝트에서도 `agent-ui/definition/archive/**`와 `agent-ui/archive/user-review/**`는 일반 작업에서 읽지 않는다. UI 과거 결정, 복원, 비교, 해결된 user review 확인이 필요한 경우에만 `agent-ops/rules/common/rules-agent-ui.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-spec/` 디렉터리가 있는 프로젝트에서 현재 구현 스펙 확인, 기존 기능 변경, 완료 검토, 구현 스펙 생성/갱신 요청은 세션 1회 `agent-ops/rules/common/rules-agent-spec.md`를 읽고, `agent-spec/index.md`와 매칭되는 spec 문서만 읽는다.
|
||||
|
|
@ -52,4 +52,4 @@
|
|||
|
||||
**테스트 실행/검증 작업이 포함된 경우, 작업 환경에 맞게 최초 1회 읽고 수행한다. 환경 미지정은 local로 본다.**
|
||||
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, 또는 plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우에만 필요한 파일을 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우, 또는 plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다.
|
||||
- `agent-roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-ui/` 디렉터리가 있는 프로젝트에서도 `agent-ui/definition/archive/**`와 `agent-ui/archive/user-review/**`는 일반 작업에서 읽지 않는다. UI 과거 결정, 복원, 비교, 해결된 user review 확인이 필요한 경우에만 `agent-ops/rules/common/rules-agent-ui.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-spec/` 디렉터리가 있는 프로젝트에서 현재 구현 스펙 확인, 기존 기능 변경, 완료 검토, 구현 스펙 생성/갱신 요청은 세션 1회 `agent-ops/rules/common/rules-agent-spec.md`를 읽고, `agent-spec/index.md`와 매칭되는 spec 문서만 읽는다.
|
||||
|
|
@ -52,4 +52,4 @@
|
|||
|
||||
**테스트 실행/검증 작업이 포함된 경우, 작업 환경에 맞게 최초 1회 읽고 수행한다. 환경 미지정은 local로 본다.**
|
||||
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, 또는 plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우에만 필요한 파일을 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우, 또는 plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다.
|
||||
- `agent-roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-ui/` 디렉터리가 있는 프로젝트에서도 `agent-ui/definition/archive/**`와 `agent-ui/archive/user-review/**`는 일반 작업에서 읽지 않는다. UI 과거 결정, 복원, 비교, 해결된 user review 확인이 필요한 경우에만 `agent-ops/rules/common/rules-agent-ui.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-spec/` 디렉터리가 있는 프로젝트에서 현재 구현 스펙 확인, 기존 기능 변경, 완료 검토, 구현 스펙 생성/갱신 요청은 세션 1회 `agent-ops/rules/common/rules-agent-spec.md`를 읽고, `agent-spec/index.md`와 매칭되는 spec 문서만 읽는다.
|
||||
|
|
@ -52,4 +52,4 @@
|
|||
|
||||
**테스트 실행/검증 작업이 포함된 경우, 작업 환경에 맞게 최초 1회 읽고 수행한다. 환경 미지정은 local로 본다.**
|
||||
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, 또는 plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우에만 필요한 파일을 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우, 또는 plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다.
|
||||
- `agent-roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-ui/` 디렉터리가 있는 프로젝트에서도 `agent-ui/definition/archive/**`와 `agent-ui/archive/user-review/**`는 일반 작업에서 읽지 않는다. UI 과거 결정, 복원, 비교, 해결된 user review 확인이 필요한 경우에만 `agent-ops/rules/common/rules-agent-ui.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-spec/` 디렉터리가 있는 프로젝트에서 현재 구현 스펙 확인, 기존 기능 변경, 완료 검토, 구현 스펙 생성/갱신 요청은 세션 1회 `agent-ops/rules/common/rules-agent-spec.md`를 읽고, `agent-spec/index.md`와 매칭되는 spec 문서만 읽는다.
|
||||
|
|
@ -52,4 +52,4 @@
|
|||
|
||||
**테스트 실행/검증 작업이 포함된 경우, 작업 환경에 맞게 최초 1회 읽고 수행한다. 환경 미지정은 local로 본다.**
|
||||
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
1.1.170
|
||||
1.1.174
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, 또는 plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우에만 필요한 파일을 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다.
|
||||
- `agent-task/archive/**`는 일반 작업에서 읽지 않는다. 예외: 사용자가 과거 작업 확인, 복원, 비교, 특정 archive 경로 확인을 요청한 경우, active `PLAN-*.md` / `CODE_REVIEW-*.md` / `USER_REVIEW.md`가 특정 archive evidence 경로를 명시한 경우, plan/code-review 루프의 split subtask 선행 의존성 충족 여부를 확인하는 경우, 또는 plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다.
|
||||
- `agent-roadmap/` 디렉터리가 있는 프로젝트에서도 `agent-roadmap/archive/**`는 일반 작업에서 읽지 않는다. 로드맵 과거 완료 내용, 완료 근거, 복원, 비교가 필요한 경우에만 `agent-ops/rules/common/rules-roadmap.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-ui/` 디렉터리가 있는 프로젝트에서도 `agent-ui/definition/archive/**`와 `agent-ui/archive/user-review/**`는 일반 작업에서 읽지 않는다. UI 과거 결정, 복원, 비교, 해결된 user review 확인이 필요한 경우에만 `agent-ops/rules/common/rules-agent-ui.md`의 archive 접근 규칙을 따른다.
|
||||
- `agent-spec/` 디렉터리가 있는 프로젝트에서 현재 구현 스펙 확인, 기존 기능 변경, 완료 검토, 구현 스펙 생성/갱신 요청은 세션 1회 `agent-ops/rules/common/rules-agent-spec.md`를 읽고, `agent-spec/index.md`와 매칭되는 spec 문서만 읽는다.
|
||||
|
|
@ -52,4 +52,4 @@
|
|||
|
||||
**테스트 실행/검증 작업이 포함된 경우, 작업 환경에 맞게 최초 1회 읽고 수행한다. 환경 미지정은 local로 본다.**
|
||||
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
- local: `agent-test/local/rules.md` (없으면 `create-test`)
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
## 사용자 리뷰 요청
|
||||
|
||||
_기본값은 `없음`이다. 구현 중 새 결정이 필요해 보여도 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다. 이 섹션은 선택된 Milestone `구현 잠금 > 결정 필요` 항목이 실구현을 차단할 때만 채운다. 외부 환경/secret/서비스 준비, 검증 증거 공백, 반복 실패, 일반 범위 조정은 사용자 리뷰 요청이 아니며 `검증 결과`, `계획 대비 변경 사항`, 또는 code-review의 일반 follow-up plan으로 처리한다._
|
||||
|
||||
- 상태: 없음
|
||||
- 사유 유형: 없음
|
||||
- 연결 대상: 없음
|
||||
- 결정 필요: 없음
|
||||
- 차단 근거: 없음
|
||||
- 실행한 검증/명령: 없음
|
||||
- 자동 후속 불가 이유: 없음
|
||||
- 재개 조건: 없음
|
||||
|
|
@ -56,6 +56,7 @@ Task는 `- [ ] [item-id] 설명` 형식을 사용한다.
|
|||
item-id는 공백 없는 짧은 ASCII 영문/숫자 segment 1~4개로 작성하고 segment 구분자는 -_+= 만 사용한다.
|
||||
epic-id와 item-id는 해당 Milestone 안에서만 유일하면 되고, 다른 Milestone에서는 같은 id를 다시 사용할 수 있다.
|
||||
Task는 기능 또는 산출물 단위다. 검증이 필요한 기능만 같은 Task 안에 `검증: <명령/확인 방법/기대 결과>`를 덧붙인다.
|
||||
각 Epic에는 기능 Task를 최대 5개만 둔다. 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 Epic을 분리한다. 분리된 Epic이 독립 목표면 새 Milestone 후보로 둔다.
|
||||
Task 체크리스트는 Epic 바로 아래의 flat list로 유지하고, 구현 세부나 테스트만 따로 떼어낸 하위 체크박스는 만들지 않는다.
|
||||
별도 `완료 기준` 섹션은 만들지 않는다.
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: code-review
|
||||
description: Use for active task review requests such as 리뷰 진행해, 리뷰해줘, 코드 리뷰해줘, code review, CODE_REVIEW.md, USER_REVIEW.md resolution, implementation-time 사용자 리뷰 요청, or 리뷰 루프. Review the active PLAN/CODE_REVIEW pair, append PASS/WARN/FAIL, archive both active files, and create the required next state. PASS writes complete.log and moves the task to archive; WARN/FAIL must invoke the plan skill, which reruns finalize-task-routing before writing the next pair, unless the user-review gate requires USER_REVIEW.md.
|
||||
description: Use for active task review requests such as 리뷰 진행해, 리뷰해줘, 코드 리뷰해줘, code review, CODE_REVIEW.md, USER_REVIEW.md resolution, or 리뷰 루프. Review the active PLAN/CODE_REVIEW pair, append PASS/WARN/FAIL, archive both active files, and create the required next state. PASS writes complete.log and moves the task to archive; WARN/FAIL must invoke the plan skill, which reruns finalize-task-routing before writing the next pair, unless the review-agent-owned user-review gate requires USER_REVIEW.md.
|
||||
---
|
||||
|
||||
# Code Review
|
||||
|
|
@ -15,14 +15,14 @@ plan skill -> finalize-task-routing -> implementation -> code-review skill
|
|||
+----- WARN/FAIL: invoke plan skill with raw findings -+
|
||||
```
|
||||
|
||||
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 decision-stop path, and it is valid only for a selected Milestone `구현 잠금 > 결정 필요` item. 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`.
|
||||
Implementation agents never decide or request user review. They record implementation, verification, deviation, and blocker evidence in implementation-owned review fields. The official code-review agent alone evaluates the selected Milestone state and, when the review-agent-owned gate is justified, writes `USER_REVIEW.md` from `agent-ops/skills/common/code-review/templates/user-review-template.md`.
|
||||
|
||||
## Core Loop Rules
|
||||
|
||||
- Trigger: Korean or English active-task review requests, including `리뷰 진행해` and `리뷰해줘`, must use this skill when an active `CODE_REVIEW-*-G??.md` or `USER_REVIEW.md` exists under `agent-task/*/` or `agent-task/*/*/`, excluding `agent-task/archive/**`.
|
||||
- Finalize every selected active state: for `CODE_REVIEW-*-G??.md`, append one verdict, prepare the required next state, archive the active review and plan files, then materialize exactly one next state; for `USER_REVIEW.md` completion, update the stop state, write `complete.log`, and archive the task.
|
||||
- Next state: `PASS` writes `complete.log` and moves the task under `agent-task/archive/YYYY/MM/`; if the task group is `m-<milestone-slug>`, report completion metadata for the runtime event. `WARN` or `FAIL` normally invokes `agent-ops/skills/common/plan/SKILL.md`, which must run `finalize-task-routing` before writing the next active pair; if the user-review gate triggers, write `USER_REVIEW.md` instead. A completed `USER_REVIEW.md` uses the same terminal `complete.log` and archive path as `PASS`.
|
||||
- A filled implementation-owned `사용자 리뷰 요청` is a review input, not a next state by itself. The user-review gate triggers only when the request is tied to a concrete selected Milestone `구현 잠금 > 결정 필요` item. If it is vague, unsupported, repo-fixable, about external environment/secret/service setup, a generic scope conflict, loop exhaustion, or only missing evidence that a follow-up agent can produce by rerunning commands or collecting artifacts, invoke the plan skill for a normal WARN/FAIL follow-up instead.
|
||||
- The user-review gate is review-agent-owned and triggers only when current repository evidence proves that a concrete selected Milestone `구현 잠금 > 결정 필요` item blocks the next safe implementation step. Generic status fields or blocker text written by implementation are never a user-review request.
|
||||
- Do not replace `USER_REVIEW.md` with an inline user question. When the user-review gate triggers, write the file-based stop state and report its path.
|
||||
- Do not ask for confirmation before WARN/FAIL follow-up files. If the user-review gate triggers, write `USER_REVIEW.md`; otherwise invoke the plan skill with the current raw findings and let it write the smallest concrete follow-up after fresh routing.
|
||||
- Recovery: if a prior turn appended a verdict without archive or next-state files, do not append another verdict; resume Step 5 preparation/archive from that verdict. If exactly one member of the pair was archived after both archive destinations had been preflighted, verify the archived member and remaining source/destination, finish that archive, then use the post-archive recovery below. If both logs exist with a verdict but the required next state is absent, reconstruct it from those exact logs: PASS resumes `complete.log`; WARN/FAIL reruns the plan skill in `write` mode with raw archived findings and `isolated-reassessment`; a valid user-review gate rerenders `USER_REVIEW.md`. If a prior turn resolved `USER_REVIEW.md` without `complete.log`, resume at the matching finalization step.
|
||||
|
|
@ -33,8 +33,8 @@ Implementation may stop early by filling the active review stub's `사용자 리
|
|||
|
||||
- Compute `review-number` as `count(agent-task/{task_name}/code_review_*.log) + 1` before archiving the active review.
|
||||
- Repeated `WARN`/`FAIL`, loop exhaustion, missing verification evidence, and test environment blockers do not trigger `USER_REVIEW.md` by themselves. Invoke the plan skill for a narrower follow-up or report the non-roadmap blocker as verification evidence that remains unresolved.
|
||||
- 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.
|
||||
- If the filled request is about external environment/secret/service setup, unsupported device, generic scope conflict, agent execution limits, missing handoff evidence, incomplete verification records, or anything not tied to the Milestone lock, do not write `USER_REVIEW.md`; archive the review and invoke the plan skill for a normal WARN/FAIL follow-up when implementation can continue, or report the blocker without asking the user.
|
||||
- Resolve the selected Milestone from `Roadmap Targets` or another exact active Milestone path already fixed by the task. Read its current `구현 잠금 > 결정 필요` items and independently determine whether one exact unresolved decision blocks the next safe implementation step.
|
||||
- External environment/secret/service setup, unsupported device, generic scope conflict, agent execution limits, missing handoff evidence, incomplete verification records, arbitrary `상태` text, or anything not tied to that exact Milestone lock never triggers the gate. Archive the review and invoke the plan skill for a normal WARN/FAIL follow-up when implementation can continue, or report the non-user-review blocker.
|
||||
- `USER_REVIEW.md` is created from `agent-ops/skills/common/code-review/templates/user-review-template.md`, filled with the archived loop history, current archived plan/review paths, verdict, loop count, blocking evidence, connection target, and the exact Milestone decision item.
|
||||
|
||||
## User Review Resolution
|
||||
|
|
@ -44,7 +44,7 @@ When an active `USER_REVIEW.md` exists and the linked Milestone decision closes
|
|||
- Read `USER_REVIEW.md`, archived `plan_*.log`, and archived `code_review_*.log` in that task directory.
|
||||
- Verify the linked decision and any follow-up evidence are sufficient to close the task. If a new implementation plan is needed instead, do not close; route back to the plan skill, which archives `USER_REVIEW.md` to `user_review_N.log` before writing a new plan.
|
||||
- Update `USER_REVIEW.md` in place to show a resolved state, final verdict, loop history, fulfilled decision items, and the evidence that closed the stop state.
|
||||
- Write `complete.log` from `agent-ops/skills/common/code-review/templates/complete-log-template.md` before moving or archiving the task directory. Include both the original archived review verdict and the user-review resolution line in `루프 이력`.
|
||||
- Write `complete.log` from `agent-ops/skills/common/code-review/templates/complete-log-template.md` before moving or archiving the task artifacts. Include both the original archived review verdict and the user-review resolution line in `루프 이력`.
|
||||
- Then apply the same task-directory archive move and `m-<milestone-slug>` PASS completion metadata rules as a normal `PASS`.
|
||||
- Do not leave an active task directory that contains `USER_REVIEW.md` and `*.log` files but no `complete.log` after the linked Milestone decision resolves the task as complete/PASS.
|
||||
|
||||
|
|
@ -101,7 +101,6 @@ 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 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 | Ready for code-review skill |
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with appended verdict | Review finalization pending; do not append another verdict, resume Step 5 preparation/archive |
|
||||
| Exactly one active pair member + its newly archived counterpart | Partial archive after a preflighted finalization; verify both identities, finish the remaining archive, then resume post-archive recovery |
|
||||
|
|
@ -154,6 +153,13 @@ The diff is the starting point, not the boundary. Follow behavior and API connec
|
|||
|
||||
If the active plan or review file contains `Agent UI Completion`, also read `agent-ops/rules/common/rules-agent-ui.md` and the listed active agent-ui documents. Do not read `agent-ui/definition/archive/**` or `agent-ui/archive/user-review/**` unless the review explicitly cites those archive paths.
|
||||
|
||||
Review scope control:
|
||||
|
||||
- Use the plan's commands and checkpoints as the primary evidence. Add one focused, possibly table-driven reproducer only when needed to prove a suspected blocking defect; do not build speculative exhaustive probe matrices.
|
||||
- In a follow-up review, keep Required findings within the current plan, inherited Required findings, direct regressions from the fix, and concrete violations of the original SDD or contract acceptance criteria. Exclude unrelated pre-existing work from the verdict and Required/Suggested/Nit counts; mention it only in the final report as an out-of-scope task candidate.
|
||||
- Before adding a new Required that the current plan did not state, cite the exact original plan/SDD/contract criterion it violates or provide a concrete failing case. Do not require a preferred test shape when existing deterministic evidence proves the same behavior.
|
||||
- When one invariant fails in multiple already-observed variants, report that known set together instead of revealing one variant per follow-up.
|
||||
|
||||
## Step 3 - Pre-Review Checklist
|
||||
|
||||
Before writing the verdict:
|
||||
|
|
@ -163,10 +169,10 @@ Before writing the verdict:
|
|||
- 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.
|
||||
- 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.
|
||||
- Confirm the implementation marked the matching checklist items in the active review file, including the mandatory `CODE_REVIEW-*-G??.md` evidence item; repair clear artifact drift when evidence supports completion.
|
||||
- If the active plan or review file contains `Agent UI Completion`, verify the implementation-owned fields are filled before PASS: listed agent-ui docs exist, actual code evidence paths exist, requested status updates are explicit, and implementation verification evidence is present. Missing or untrusted evidence is a completeness or verification-trust issue.
|
||||
- Treat review artifact gaps as failures only when they prevent judging implementation correctness, tests, contracts, or verification trust.
|
||||
- Read 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. Reject the request unless it is tied to a selected Milestone `구현 잠금 > 결정 필요` item.
|
||||
- Treat every generic `상태` field and implementation blocker record as ordinary evidence, never as a request to stop for the user. Evaluate the user-review gate independently from the current selected Milestone only after a WARN/FAIL finding requires a next state.
|
||||
- Grep renamed/removed symbols for stale references.
|
||||
- Confirm every required test exists, name matches, and assertions are meaningful.
|
||||
- Cross-check claimed verification output in the active review file against actual code and project commands.
|
||||
|
|
@ -183,9 +189,10 @@ Required fields:
|
|||
- `종합 판정`: exactly `PASS`, `WARN`, or `FAIL`.
|
||||
- `차원별 평가`: Pass/Warn/Fail for correctness, completeness, test coverage, API contract, code quality, implementation deviation, verification trust. If SDD Evidence Map applies through `Roadmap Targets`, also include spec conformance.
|
||||
- `발견된 문제`: `없음`, or bullets using `Required`, `Suggested`, or `Nit` with `file:line` and a concrete fix.
|
||||
- `라우팅 신호`: calculate once and append `review_rework_count=<N>` and `evidence_integrity_failure=true|false`. Set rework count to archived same-task `WARN|FAIL` verdicts plus one only when the current verdict is non-PASS. Set integrity failure to true only when a claimed test, command, exit code, or production path is absent, unexecuted, or contradicted by fresh reviewer evidence.
|
||||
- `다음 단계`: keep only the matching PASS, WARN/FAIL follow-up, or USER_REVIEW line.
|
||||
|
||||
Do not 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.
|
||||
Do not check archive/next-state items in `코드리뷰 전용 체크리스트` during Step 4. Complete the applicable dedicated checklist items in the archived `code_review_*.log` during Step 7, after archive, next-state writes, and PASS task-artifact moves are done.
|
||||
|
||||
Severity semantics:
|
||||
|
||||
|
|
@ -216,13 +223,13 @@ Do not archive WARN/FAIL files until the next-state content is fully prepared in
|
|||
- If the gate triggers, render the complete `USER_REVIEW.md` body from `agent-ops/skills/common/code-review/templates/user-review-template.md` in memory.
|
||||
- Otherwise build the follow-up handoff described below and fully execute `agent-ops/skills/common/plan/SKILL.md` in `prepare-follow-up` mode.
|
||||
|
||||
Before preparing a follow-up, count the existing logs and parse each current active basename. Set `current_review_archive_number=count(code_review_*.log)` and `current_plan_archive_number=count(plan_*.log)`. Derive `current_review_archive_name` and `current_plan_archive_name` from the current active files' own lane/grade plus those numbers. These names describe the pair being closed, not the next route.
|
||||
Reuse the routing signals appended in Step 4; do not recount verdict history for routing. Separately count the existing logs once for archive identity: set `current_review_archive_number=count(code_review_*.log)` and `current_plan_archive_number=count(plan_*.log)`, then derive both archive names from the current active files' own lane/grade. These archive values describe the pair being closed, not the next route.
|
||||
|
||||
The follow-up handoff contains the selected `{task_name}`, current verdict, Required/Suggested/Nit findings, affected files, actual verification output, current ownership/dependency facts, roadmap carryover, `REVIEW_<PARENT_TAG>`, and those predicted current-pair archive names. Keep current active paths only as evidence pointers. Do not add the prior lane, grade, routing score, rationale, or a preferred next route to the neutral routing snapshot, and require plan to omit route-bearing basenames from the isolated routing input. The plan may use current archive names only after routing to render `Archive Evidence Snapshot`.
|
||||
The follow-up handoff contains the selected `{task_name}`, the current plan's requested outcome/acceptance/exclusions revalidated against current evidence, current verdict, Required/Suggested/Nit findings, affected files, actual verification output, current ownership/dependency facts, roadmap carryover, `review_rework_count`, `evidence_integrity_failure`, `REVIEW_<PARENT_TAG>`, and those predicted current-pair archive names. Keep current active paths only as evidence pointers. Do not add the prior lane, grade, routing score, rationale, or a preferred next route to the neutral routing snapshot, and require plan to omit route-bearing basenames from the isolated routing input. The plan may use current archive names only after routing to render `Archive Evidence Snapshot`.
|
||||
|
||||
- `prepare-follow-up` must return `status: routed`, the exact routed basenames, `prepared_plan`, `prepared_review`, `plan_number`, `current_plan_archive_name`, `current_plan_archive_number`, `current_review_archive_name`, `current_review_archive_number`, `plan_log_number`, `review_log_number`, and `gitignore_repair_needed`. It must have executed `finalize-task-routing` in `isolated-reassessment` mode.
|
||||
- Verify that the returned current archive names/numbers equal the values derived before preparation, and that `plan_log_number` / `review_log_number` are the post-archive counts embedded in the new review stub for its future archive.
|
||||
- If preparation returns `needs_evidence`, continue evidence collection and rerun it before archiving.
|
||||
- If preparation returns `needs_evidence`, collect all named new evidence and rerun after the input changes; never rerun with unchanged evidence. If the evidence cannot be obtained in the current scope, leave the verdict-appended pair in place and report the exact finalization blocker.
|
||||
- If preparation returns `blocked`, leave the verdict-appended active PLAN/CODE_REVIEW pair in place, do not check archive/next-state items, and report a resumable finalization blocker. A later code-review invocation resumes this step without appending another verdict.
|
||||
|
||||
After the required next state is prepared, archive is mandatory for `PASS`, `WARN`, and `FAIL`. Ensure `.gitignore` has the Agent-Ops managed gitignore block for task artifacts before writing `*.log` outputs. Prefer `source agent-ops/bin/ai-ignore.sh && agent_ops_ensure_gitignore_task_artifact_block .gitignore`; if the helper is unavailable, add or update a block containing `!agent-task/`, `!agent-task/**/`, `!agent-task/**/*.md`, `!agent-task/**/*.log`, and `agent-roadmap/current.md`. Apply the repair here when `prepare-follow-up` returned `gitignore_repair_needed: true`.
|
||||
|
|
@ -256,7 +263,7 @@ For `WARN` or `FAIL`, materialize the next state prepared in Step 5 immediately
|
|||
- If the user-review gate triggered, write the prepared body to `agent-task/{task_name}/USER_REVIEW.md`. It must use only `milestone-lock`, contain every archived loop entry plus the exact linked decision, and contain no placeholder. Do not write active PLAN/CODE_REVIEW files or `complete.log`.
|
||||
- Otherwise write `prepared_plan` and `prepared_review` byte-for-byte to their routed basenames. Do not rerun, adjust, compare, or upgrade their lane/G after archive.
|
||||
- Verify the written follow-up pair contains the predicted archived plan/review paths in identical `Archive Evidence Snapshot` sections and contains no unresolved token from the review-stub template inventory. Unrelated braces in commands or code are allowed.
|
||||
- A prior local failure never changes the prepared pair into an automatic cloud upgrade.
|
||||
- Do not adjust the prepared route after finalization. For a `local-fit` base, `review_rework_count >= 2` or `evidence_integrity_failure=true` must produce `recovery-boundary`; `capability-gap` and `grade-boundary` keep their own basis.
|
||||
|
||||
If the task group is `m-<milestone-slug>` and the user-review gate triggered, report that the milestone task is blocked on user review; do not emit PASS completion metadata and do not call `update-roadmap`.
|
||||
|
||||
|
|
@ -264,21 +271,21 @@ If the task group is `m-<milestone-slug>` and the user-review gate triggered, re
|
|||
|
||||
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/`.
|
||||
- If verdict is `PASS`, determine archive month from the current completion date as `YYYY/MM`, create the needed archive parent directories, then move the selected task artifacts from `agent-task/{task_name}/` to `agent-task/archive/YYYY/MM/{task_name}/`. For split work, move the selected subtask directory itself and preserve the task group path, e.g. `agent-task/refactoring/01_core/` moves to `agent-task/archive/YYYY/MM/refactoring/01_core/`.
|
||||
- Do not overwrite an existing archive directory. If `agent-task/archive/YYYY/MM/{task_name}/` already exists, append the next numeric suffix to the final path segment: single-plan `agent-task/archive/YYYY/MM/{task_group}_1/`, split-plan `agent-task/archive/YYYY/MM/{task_group}/{subtask_dir}_1/`, and so on.
|
||||
- After moving a split subtask, remove the active parent `agent-task/{task_group}/` only if it is empty. If sibling subtask directories or other files remain, leave the parent task group in place.
|
||||
- After moving a split subtask, remove the active parent `agent-task/{task_group}/` only when it is empty.
|
||||
- If verdict is `PASS` and `{task_group}` matches `m-<milestone-slug>`, do not resolve the roadmap target and do not call `update-roadmap`. Report completion event metadata after the task archive move: `origin-task=agent-task/{task_name}` from the original active task path, `task-group={task_group}`, `milestone-slug=<milestone-slug>`, final archive path, `complete.log` path, archived plan/review log paths, and `roadmap-completion=<Task ids from complete.log or none>`.
|
||||
- The runtime consumes that completion event, checks current state, and calls `update-roadmap` if needed. `update-roadmap` only checks Milestone Task ids when `complete.log` contains `Roadmap Completion`; if the section is absent, roadmap Task completion is a no-op even for `m-*` task groups.
|
||||
- If verdict is `PASS` and the archived review log contains `Agent UI Completion`, ensure the listed agent-ui status/evidence update and `validate-agent-ui` check are complete before writing or finalizing `complete.log`. Do not defer this to runtime or Milestone completion.
|
||||
- `WARN` and `FAIL` do not update the roadmap Milestone; the follow-up plan remains under the same `m-<milestone-slug>` task group when the original task was Milestone-linked.
|
||||
- `USER_REVIEW` does not update the roadmap Milestone and does not produce PASS completion metadata. Keep the active task directory in place with `USER_REVIEW.md` and archived plan/review logs until the linked Milestone lock decision is resolved.
|
||||
- If `USER_REVIEW.md` is later resolved as complete/PASS by linked Milestone decision and evidence, write `complete.log`, move the task directory to archive, and report `m-*` PASS completion metadata just like a normal `PASS`.
|
||||
- If `USER_REVIEW.md` is later resolved as complete/PASS by linked Milestone decision and evidence, write `complete.log`, move the task artifacts to archive, and report `m-*` PASS completion metadata just like a normal `PASS`.
|
||||
- For `PASS`, open the moved `agent-task/archive/YYYY/MM/{final_task_name}/{current_review_archive_name}`, where `{final_task_name}` is the archived task path, including `{task_group}/` for split work.
|
||||
- For user-review-resolved PASS, confirm the moved archive contains the resolved `USER_REVIEW.md`, `complete.log`, and the existing archived `plan_*.log` / `code_review_*.log`; do not recreate an active review file only to add a new checklist item.
|
||||
- For `WARN` or `FAIL`, open `agent-task/{task_name}/{current_review_archive_name}`.
|
||||
- Run `git check-ignore -q --` on the generated task artifacts (`plan_*.log`, `code_review_*.log`, `user_review_*.log` when present, `complete.log` when present, and active follow-up `.md` files). If any are ignored, apply the Agent-Ops managed gitignore block and re-check before reporting.
|
||||
- Check every applicable item in `코드리뷰 전용 체크리스트`; leave mutually exclusive verdict items unchecked.
|
||||
- If any applicable item cannot be checked, finish the missing archive, `complete.log`, task-directory move, mandatory plan-skill follow-up, or `USER_REVIEW.md` write first.
|
||||
- If any applicable item cannot be checked, finish the missing archive, `complete.log`, task-artifact move, mandatory plan-skill follow-up, or `USER_REVIEW.md` write first.
|
||||
- Do not recreate an active review file just to update this checklist; update the archived `code_review_*.log`.
|
||||
- Only report after the archived review log has the verdict, applicable checked review-only checklist, required next-state files, for `PASS` or user-review-resolved PASS the final task archive move, for `m-*` PASS tasks the completion event metadata, and for unresolved `USER_REVIEW` the filled `USER_REVIEW.md`.
|
||||
|
||||
|
|
@ -310,18 +317,17 @@ Report Required/Suggested counts, archive names, the final task archive path for
|
|||
- `{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.
|
||||
- No active `PLAN-*.md`, `CODE_REVIEW-*.md`, or `USER_REVIEW.md` remains after PASS or user-review-resolved PASS.
|
||||
- PASS or user-review-resolved PASS: `complete.log` written from `agent-ops/skills/common/code-review/templates/complete-log-template.md`, then task artifacts moved under `agent-task/archive/YYYY/MM/` with task-group path preserved for split work.
|
||||
- PASS milestone task group: `m-<milestone-slug>` completion event metadata was reported for runtime; roadmap was not modified by code-review.
|
||||
- PASS with `Roadmap Targets`: `complete.log` contains `Roadmap Completion` with Milestone path, Task ids, archived plan/review evidence, and verification evidence.
|
||||
- PASS without `Roadmap Targets`: `complete.log` omits `Roadmap Completion` and reported metadata says `roadmap-completion=none`.
|
||||
- PASS with `Agent UI Completion`: listed agent-ui docs were updated to `구현됨` with code evidence, `validate-agent-ui` passed, and `complete.log` contains `Agent UI Completion`.
|
||||
- PASS without `Agent UI Completion`: complete.log omits `Agent UI Completion`.
|
||||
- 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: the plan skill was invoked for the exact task path, completed `finalize-task-routing`, and created new active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` files matching the fresh routed output; no `complete.log`.
|
||||
- WARN/FAIL follow-up: the plan input omitted prior lane/G assessment, and the new active plan/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.
|
||||
- WARN/FAIL without user-review gate: the plan skill was invoked for the exact task path with verified `review_rework_count` and `evidence_integrity_failure`, completed `finalize-task-routing`, and created new active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` files matching the fresh routed output; no `complete.log`.
|
||||
- WARN/FAIL follow-up: the plan input omitted prior route fields, revalidated outcome/acceptance/exclusions from current evidence, used the completed in-memory PLAN as the packet, and copied identical `Archive Evidence Snapshot` sections into the new plan/review pair.
|
||||
- Follow-up plans and review stubs keep implementation agents limited to implementation/test/evidence and contain no implementation-owned user-review request section.
|
||||
- USER_REVIEW: `USER_REVIEW.md` exists from template, no active `PLAN-*.md` or `CODE_REVIEW-*.md` remains, and no `complete.log` was written.
|
||||
- Implementation-requested USER_REVIEW: archived review log preserves the filled `사용자 리뷰 요청` evidence and the generated `USER_REVIEW.md` records the exact linked Milestone decision needed.
|
||||
- Review-agent-owned USER_REVIEW: the generated `USER_REVIEW.md` records the exact active Milestone decision and repository evidence that made automatic continuation unsafe.
|
||||
- USER_REVIEW resolved as PASS: archived task contains both resolved `USER_REVIEW.md` and `complete.log`.
|
||||
- The applicable review-agent-only finalization checklist was completed before reporting.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: create-roadmap
|
||||
version: 1.19.0
|
||||
version: 1.19.2
|
||||
description: AI-first 개인/소규모 프로젝트의 전체 목표, Phase scaffold, Phase 하위 Milestone 문서, 전역 priority-queue.md 실행 순서 문서, 로컬 current.md 활성 Phase/Milestone 창, archive Phase scaffold를 처음 생성하고, agent-ui 코드 동기화 Milestone의 완료 리뷰 상태 반영 항목을 포함하는 공통 스킬
|
||||
---
|
||||
|
||||
|
|
@ -121,6 +121,8 @@ agent-roadmap/
|
|||
- 새 Milestone이 다른 프로젝트 Milestone 완료 전까지 잠겨야 하면 `구현 잠금`을 `잠금`으로 두고 프로젝트 상위 `.agent-roadmap-sync/locks.yaml`에 entry를 만든다. 의존 대상 확정과 entry 형식은 `update-roadmap`의 프로젝트 간 잠금 규칙을 따른다.
|
||||
- `기능`은 Epic heading과 Task 체크리스트로 작성한다.
|
||||
- Epic heading은 `### Epic: [epic-id] <이름>` 형식으로 작성한다.
|
||||
- 각 Epic에는 기능 Task를 최대 5개만 둔다. 5개를 초과하는 Task는 허용하지 않는다.
|
||||
- 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 기존 Epic을 둘 이상으로 분리한다. 분리 후에도 독립 목표가 남으면 새 Milestone 후보로 둔다.
|
||||
- Task는 `- [ ] [item-id] 설명` 형식으로 작성한다.
|
||||
- epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 해당 Milestone 안에서만 유일하면 된다.
|
||||
- 검증이 필요한 Task에만 같은 항목 안에 `검증: <명령/확인 방법/기대 결과>`를 붙인다. 검증이 필요 없는 기능에는 억지 검증을 붙이지 않는다.
|
||||
|
|
@ -156,6 +158,7 @@ agent-roadmap/
|
|||
- Phase는 큰 진화 단위로 나누고, 각 Phase에 목표와 상태를 둔다.
|
||||
- Milestone은 Phase 안에서 완료 판단이 가능한 단위로 나눈다.
|
||||
- Milestone 내부에서 여러 기능 묶음이 필요하면 Epic으로 선언하고, Epic 아래 flat Task 체크리스트를 둔다.
|
||||
- 각 Epic의 기능 Task 수는 최대 5개로 제한한다. 여섯 번째 Task가 필요하면 책임과 산출물 경계를 기준으로 Epic을 분리한다.
|
||||
|
||||
4. **파일 생성**
|
||||
- `ROADMAP.md`, `priority-queue.md`, 로컬 `current.md`, 각 Phase의 `PHASE.md`, 각 Milestone 문서를 템플릿 순서대로 생성한다.
|
||||
|
|
@ -179,6 +182,7 @@ agent-roadmap/
|
|||
- 생성한 로드맵 문서의 Markdown 링크 target에 템플릿 placeholder가 남지 않았는지 확인한다.
|
||||
- 로컬 `current.md` 활성 항목에 `agent-roadmap/archive/**` 경로가 없는지 확인한다.
|
||||
- Epic heading과 Task 체크리스트 id가 형식을 따르는지 확인한다.
|
||||
- 각 Epic의 기능 Task 수가 최대 5개인지 확인한다. 6개 이상이면 검증 실패로 보고하고 Epic 분리를 요구한다.
|
||||
- 상태 표기가 `[진행중]`처럼 공백 없는 표준값인지 확인한다.
|
||||
- `[스케치]` Milestone에 `승격 조건` 섹션이 있고 `구현 잠금`이 `잠금`인지 확인한다.
|
||||
- 각 Milestone의 `구현 잠금`에 `SDD: 필요|불필요`와 판정 사유가 있는지 확인한다.
|
||||
|
|
|
|||
|
|
@ -1,181 +1,149 @@
|
|||
---
|
||||
name: finalize-task-routing
|
||||
description: PLAN/CODE_REVIEW 작성 직전 현재 작업 증거만으로 cloud/local lane과 G01-G10 등급을 독립 평가하고 canonical 파일명을 확정한다. 최초 plan, review 실패 후 follow-up plan, 라우팅 재평가, lane/G 판단, routed filename 결정에 사용한다.
|
||||
description: PLAN/CODE_REVIEW 작성 직전 완성된 build packet을 한 번 평가해 local-first lane, G, canonical filename을 확정한다. 최초 plan과 WARN/FAIL follow-up에서 capability gap, indivisible context, 복합 loop-risk, review rework, evidence integrity에 따른 cloud 경계를 적용할 때 사용한다.
|
||||
---
|
||||
|
||||
# Finalize Task Routing
|
||||
|
||||
## 목적
|
||||
## 목표
|
||||
|
||||
계획 분석이 끝난 뒤 구현과 리뷰 target의 lane과 G 등급을 처음부터 평가하고 canonical 파일명을 반환한다.
|
||||
이 스킬은 라우팅 판단의 단일 원본이며 plan/review 내용을 작성하거나 task 파일을 직접 생성하지 않는다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- `plan`이 최초 PLAN/CODE_REVIEW pair를 쓰기 직전
|
||||
- `code-review`의 WARN/FAIL 후 `plan`이 follow-up PLAN/CODE_REVIEW pair를 다시 쓰기 직전
|
||||
- 기존 lane/G 판정이 검증 실패, 증거 충돌, 범위 변화, 소유권 변화로 무효화된 뒤 재평가할 때
|
||||
- 사용자가 현재 작업의 cloud/local, G 등급, canonical task 파일명만 요청할 때
|
||||
완성된 in-memory PLAN 하나를 한 번 평가해 build/review route를 확정한다. routing 전용 문서나 증거 탐색을 만들지 않는다. Build의 기본값은 local이며 아래 표의 cloud 조건에 일치할 때만 승격한다. 공식 review는 항상 cloud의 Codex `gpt-5.6-sol` xhigh다. 이 스킬은 task 파일을 수정하지 않는다.
|
||||
|
||||
## 입력
|
||||
|
||||
- `targets`: `build`, `review`, 또는 둘 다. `plan`은 항상 둘 다 전달한다 (필수)
|
||||
- `evaluation_mode`: 이전 라우팅이 없는 최초 평가는 `first-pass`, 무효화된 기존 라우팅이 있는 평가는 `isolated-reassessment` (필수)
|
||||
- `task_snapshot`: 사용자 요구, 현재 scope, 수정/영향 경로, 불변조건, 상태 전이, 검증 계획과 실제 증거 (필수)
|
||||
- `context_snapshot`: 함께 유지해야 하는 source/test/diff/log/contract 범위와 분할 가능성 (필수)
|
||||
- `ownership_snapshot`: 공유 상태, 병행 작업, sibling task, 외부 책임 경계 (필수)
|
||||
- `decision_snapshot`: 미해결 의미 판단, 사용자 권한이 필요한 결정, 외부 환경 의존성 (필수)
|
||||
- `invalidation_evidence`: 검증 실패, 실제 로그, review finding, 변경된 범위 등 현재 판정을 바꾸는 원시 증거 (선택)
|
||||
- `evaluation_mode`: `first-pass | isolated-reassessment`
|
||||
- `targets.build`: 구현 에이전트가 읽을 PLAN과 PLAN 작성에 이미 사용한 scope, source/test/contract, 불변조건, 검증 근거
|
||||
- `targets.review`: review scope, 영향 경로, 검증 계획과 근거
|
||||
- target별 closure와 근거: `scope_closed`, `context_closed`, `verification_closed`, `evidence_trusted`, `ownership_closed`, `decision_closed`
|
||||
- target별 G 점수: `scope_coupling`, `state_concurrency`, `blast_irreversibility`, `evidence_diagnosis`, `verification_complexity`
|
||||
- build 신호: `large_indivisible_context`, `matched_loop_risk_signatures`, `review_rework_count`, `evidence_integrity_failure`
|
||||
- closure가 false이고 cloud가 해소할 수 있을 때만 `capability_gap`: `observed`, `evidence`, `cloud_resolution`
|
||||
|
||||
이전 `lane`, `grade`, 점수, 라우팅 사유, routed filename은 입력에서 제외한다.
|
||||
이전 PLAN/CODE_REVIEW 문서의 코드 경로, 실제 로그, finding은 원본에서 재확인한 뒤 원시 증거로만 사용할 수 있다.
|
||||
이전 lane/G, 점수, route 사유, filename을 입력하지 않는다. `review_rework_count`와 `evidence_integrity_failure`만 route-free 운영 이력으로 전달한다.
|
||||
|
||||
## 먼저 확인할 것
|
||||
## 판정 순서
|
||||
|
||||
- [ ] `agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-route.sh`가 실행 가능한가
|
||||
- [ ] 호출자가 plan 분석, scope, split, 검증 계획을 모두 확정했는가
|
||||
- [ ] `targets`마다 필요한 구현 또는 리뷰 작업이 구분되어 있는가
|
||||
- [ ] 이전 lane/G와 그 평가 문구가 입력에서 격리되었는가
|
||||
- [ ] `isolated-reassessment`이면 이전 평가를 보지 않은 새 평가 context/sub-invocation에 중립 snapshot만 전달했는가
|
||||
- [ ] 주장이나 요약이 아니라 현재 파일, diff, 명령 출력, 확정된 제약을 우선 증거로 사용했는가
|
||||
아래 순서를 지키고 종료 조건을 만나면 즉시 멈춘다.
|
||||
|
||||
## 실행 절차
|
||||
### 1. Snapshot 고정
|
||||
|
||||
1. **평가 상태 초기화**
|
||||
- 호출할 때마다 각 target을 `unrouted`로 시작한다.
|
||||
- `isolated-reassessment`는 이전 평가가 없는 새 context/sub-invocation에서 실행하고, 현재 원시 증거로 재구성한 중립 snapshot만 노출한다.
|
||||
- 호출자가 격리 실행을 제공할 수 없으면 독립 재평가를 완료했다고 주장하지 말고 `status: blocked`, `blocked_reason: isolated-routing-unavailable`을 반환한다.
|
||||
- 이전 lane/G를 승계하거나 하한으로 사용하지 않는다.
|
||||
- 실패 횟수, Required 개수, 이전 G 등급만으로 cloud 또는 상위 G를 선택하지 않는다.
|
||||
- 실패는 자동 승격 조건이 아니라 현재 증거에 추가되는 판정 무효화 사건으로만 취급한다.
|
||||
- 새 결과가 확정되기 전에는 이전 평가와 비교하지 않는다. 필요하면 호출자가 routed 출력 이후에만 감사용 delta를 기록한다.
|
||||
PLAN body, split, verification, evidence, ownership, decision이 완성된 뒤 실행한다.
|
||||
|
||||
2. **폐쇄성 평가**
|
||||
- 각 target을 bounded local execution으로 완료·판정할 수 있는지를 기준으로 아래 값을 `true`, `false`, `unknown` 중 하나로 독립 판정하고 근거를 한 줄로 기록한다.
|
||||
- `scope_closed`: 정확성 조건과 영향 경로가 확정된 범위 안에서 설명되는가
|
||||
- `context_closed`: 중요한 증거를 생략하지 않고 필요한 컨텍스트를 함께 다룰 수 있는가
|
||||
- 계획 분석 결과, 해당 target을 수행하는 동안 긴 컨텍스트를 유지해야 한다고 판단되면 `context_closed=false`로 판정한다.
|
||||
- `verification_closed`: 결정적인 명령과 관찰로 성공 여부를 증명할 수 있는가
|
||||
- `evidence_trusted`: 검증이 의도한 실제 경로를 실행하며 출력이 재현 가능하고 현재 상태와 일치하는가
|
||||
- `ownership_closed`: 공유 상태, 병행 작업, 외부 소유권이 판단을 모호하게 만들지 않는가
|
||||
- `decision_closed`: 사용자 권한이나 미해결 외부 의미 결정 없이 작업을 완료할 수 있는가
|
||||
- 동시성, dirty worktree, 외부 명령, 많은 finding은 그 자체로 lane을 결정하지 않는다. 위 폐쇄성에 미치는 영향만 평가한다.
|
||||
- PLAN 자체를 build packet으로 사용한다. 별도 packet 요약을 만들지 않는다.
|
||||
- 이미 읽은 사실만 사용한다. routing 때문에 source/test/log를 다시 읽지 않는다.
|
||||
- split된 packet만 평가한다. parent/sibling의 파일·상태·risk를 합산하지 않는다.
|
||||
- `isolated-reassessment`에서는 이전 route 정보를 제거한다. 제거할 수 없으면 `blocked: isolated-routing-unavailable`로 종료한다.
|
||||
|
||||
3. **판정 가능성 확인**
|
||||
- 하나라도 `unknown`이면 `status: needs_evidence`와 필요한 증거를 반환한다. lane, grade, filename은 반환하지 않는다.
|
||||
- 하나 이상의 값이 `false`이고 cloud의 더 넓은 컨텍스트나 진단도 그 폐쇄 실패를 해소할 수 없으면 `status: blocked`, 폐쇄 실패별 `blocked_reason`, 해제 조건을 반환한다. 사용자 권한, secret, 접근 권한, 제품 결정은 대표적인 예일 뿐이며 이에 한정하지 않는다.
|
||||
- 호출자는 `needs_evidence`를 cloud로 해석하지 말고 증거를 보강한 뒤 이 스킬을 처음부터 다시 실행한다.
|
||||
### 2. Closure gate
|
||||
|
||||
4. **Lane 결정**
|
||||
- 모든 폐쇄성이 `true`인 target만 `local`로 정한다.
|
||||
- `unknown`이 없고 하나 이상의 폐쇄성이 `false`이며 cloud의 더 넓은 컨텍스트나 진단이 그 실패를 실제로 해소할 수 있을 때 `cloud`로 정한다.
|
||||
- `false`를 cloud가 해소할 수 있는지 근거를 기록한다. 해소 가능성을 설명할 수 없으면 추측으로 cloud를 선택하지 않고 Step 3의 `blocked`를 반환한다.
|
||||
- 실패 후에도 현재 폐쇄성이 모두 `true`이면 다시 `local`을 선택할 수 있다.
|
||||
- lane은 capability fit이며 작업량이나 모델 사용량 균형을 위한 값이 아니다.
|
||||
각 target의 closure를 독립적으로 판정한다.
|
||||
|
||||
5. **G 등급 재산정**
|
||||
- lane을 정한 뒤에만 각 target을 아래 다섯 차원에서 `0`, `1`, `2`로 처음부터 채점한다.
|
||||
- `scope_coupling`: `0` 단일 국소 변경 / `1` 여러 연결 지점 / `2` 다중 모듈·계약
|
||||
- `state_concurrency`: `0` 무상태 / `1` 상태 전이 / `2` 공유 상태·순서·동시성
|
||||
- `blast_irreversibility`: `0` 내부 가역 / `1` 다중 호출자·설정·지속 상태 / `2` 외부 계약·권한·비가역 영향
|
||||
- `evidence_diagnosis`: `0` 직접 증거 / `1` 복수 증거 조합 / `2` 충돌·불신 증거 진단
|
||||
- `verification_complexity`: `0` 단일 결정 명령 / `1` 복수 단계·통합 검증 / `2` 외부·상호작용·장시간 검증
|
||||
- grade는 `max(1, 다섯 점수의 합)`이며 유효 범위는 `G01`부터 `G10`이다.
|
||||
- 이전 grade, 실패 횟수, lane 변경은 점수에 더하지 않는다.
|
||||
- `scope_closed`: 정확성 조건과 영향 경로가 확정됨
|
||||
- `context_closed`: PLAN과 pointer가 구현에 필요한 사실을 제공함
|
||||
- `verification_closed`: 결정적 성공 판정 방법이 있음
|
||||
- `evidence_trusted`: 실제 경로를 실행하는 재현 가능한 근거가 있음
|
||||
- `ownership_closed`: 공유 상태와 외부 소유권이 명확함
|
||||
- `decision_closed`: 사용자·외부 의미 판단 없이 완료 가능함
|
||||
|
||||
6. **파일명 확정**
|
||||
- 각 target에 대해 다음 명령을 실행하고 stdout의 grade와 filename을 그대로 사용한다.
|
||||
첫 번째로 일치하는 규칙을 적용한다.
|
||||
|
||||
```bash
|
||||
agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-route.sh \
|
||||
<build|review> <local|cloud> \
|
||||
<scope_coupling> <state_concurrency> <blast_irreversibility> \
|
||||
<evidence_diagnosis> <verification_complexity>
|
||||
```
|
||||
| 조건 | 결과 |
|
||||
|------|------|
|
||||
| 어느 target이든 closure 하나라도 `unknown` | `needs_evidence`; 부족한 evidence를 구체적으로 기록하고 종료 |
|
||||
| 어느 target이든 closure 하나라도 `false`이고 구체적인 `cloud_resolution`이 없음 | `blocked`; 해제 조건을 기록하고 종료 |
|
||||
| build closure가 `false`이고 `observed`, `evidence`, `cloud_resolution`이 모두 있음 | build base basis를 `capability-gap`으로 설정 |
|
||||
| review closure만 `false`이고 cloud가 해소함 | review gap만 기록; build basis에는 영향 없음 |
|
||||
| build closure가 모두 `true` | G를 계산해 build base basis 결정 |
|
||||
|
||||
- 모델이 점수 합산, zero-padding, prefix 조합을 직접 계산하지 않는다.
|
||||
- 두 target은 같은 lane/G를 복사하지 말고 각자의 실행 범위로 독립 평가한다.
|
||||
- 모든 요청 target이 `routed`일 때만 filename을 반환한다.
|
||||
- 결과 확정 뒤 scope, 검증, 증거, 소유권, 결정 조건이 달라지면 결과를 무효화하고 Step 1부터 다시 실행한다.
|
||||
`needs_evidence`는 확인된 모든 missing evidence를 한 번에 나열한다. 입력이 달라진 뒤에만 재평가하고 같은 evidence로 반복하지 않는다.
|
||||
|
||||
## 실행 결과 검증
|
||||
### 3. G 계산
|
||||
|
||||
- [ ] 모든 요청 target에 여섯 폐쇄성 값과 현재 증거 근거가 있는가
|
||||
- [ ] 재평가가 `isolated-reassessment`로 실행되었고 새 결과 전까지 이전 평가가 노출·비교되지 않았는가
|
||||
- [ ] `unknown` 또는 `blocked` 상태에서 lane/G/filename을 만들지 않았는가
|
||||
- [ ] 이전 lane/G, 실패 횟수, finding 개수를 승계하거나 자동 승격 근거로 사용하지 않았는가
|
||||
- [ ] lane을 먼저 정하고 G 등급을 별도 차원 점수로 산정했는가
|
||||
- [ ] 각 target에 formatter script를 실행했고 grade와 filename을 stdout 그대로 사용했는가
|
||||
- [ ] build/review filename이 target별 formatter 결과와 정확히 일치하는가
|
||||
- 검증 실패 시: 결과를 `unrouted`로 폐기하고 누락된 현재 증거부터 보강한 뒤 전체 평가를 다시 수행한다.
|
||||
각 target의 다섯 값을 `0`~`2`로 채점하고 `grade=max(1, 합계)`로 계산한다.
|
||||
|
||||
## 출력 형식
|
||||
- `scope_coupling`: 국소 / 여러 연결 지점 / 다중 모듈·계약
|
||||
- `state_concurrency`: 무상태 / 상태 전이 / 공유 상태·순서·동시성
|
||||
- `blast_irreversibility`: 내부 가역 / 다중 호출자·지속 상태 / 외부 계약·비가역
|
||||
- `evidence_diagnosis`: 직접 증거 / 복수 증거 조합 / 충돌·불신 증거 진단
|
||||
- `verification_complexity`: 단일 명령 / 복수 단계·통합 / 외부·상호작용·장시간
|
||||
|
||||
```yaml
|
||||
status: routed | needs_evidence | blocked
|
||||
evaluation_mode: first-pass | isolated-reassessment
|
||||
targets:
|
||||
build:
|
||||
closures:
|
||||
scope_closed: true
|
||||
context_closed: true
|
||||
verification_closed: true
|
||||
evidence_trusted: true
|
||||
ownership_closed: true
|
||||
decision_closed: true
|
||||
closure_basis:
|
||||
scope_closed: "<current evidence>"
|
||||
context_closed: "<current evidence>"
|
||||
verification_closed: "<current evidence>"
|
||||
evidence_trusted: "<current evidence>"
|
||||
ownership_closed: "<current evidence>"
|
||||
decision_closed: "<current evidence>"
|
||||
lane: local
|
||||
grade_scores:
|
||||
scope_coupling: 1
|
||||
state_concurrency: 1
|
||||
blast_irreversibility: 1
|
||||
evidence_diagnosis: 0
|
||||
verification_complexity: 1
|
||||
grade: G04
|
||||
filename: PLAN-local-G04.md
|
||||
review:
|
||||
closures:
|
||||
scope_closed: true
|
||||
context_closed: false
|
||||
verification_closed: true
|
||||
evidence_trusted: false
|
||||
ownership_closed: true
|
||||
decision_closed: true
|
||||
closure_basis:
|
||||
scope_closed: "<current evidence>"
|
||||
context_closed: "<current evidence>"
|
||||
verification_closed: "<current evidence>"
|
||||
evidence_trusted: "<current evidence>"
|
||||
ownership_closed: "<current evidence>"
|
||||
decision_closed: "<current evidence>"
|
||||
lane: cloud
|
||||
grade_scores:
|
||||
scope_coupling: 1
|
||||
state_concurrency: 1
|
||||
blast_irreversibility: 1
|
||||
evidence_diagnosis: 2
|
||||
verification_complexity: 1
|
||||
grade: G06
|
||||
filename: CODE_REVIEW-cloud-G06.md
|
||||
missing_evidence: []
|
||||
blocked_reason: null
|
||||
capability gap이 없으면 G01~G08은 `local-fit`, G09~G10은 `grade-boundary`다.
|
||||
|
||||
### 4. Build 신호 계산
|
||||
|
||||
`large_indivisible_context=true`는 다음 세 조건을 모두 만족할 때만 사용한다.
|
||||
|
||||
1. 안전한 split을 끝냈다.
|
||||
2. 하나의 correctness/transaction 판단이 여러 독립 source of truth를 동시에 요구한다.
|
||||
3. 명시적 국소 규칙과 결정적 verification oracle로 축약할 수 없다.
|
||||
|
||||
파일이 많다는 이유만으로 true로 두지 않는다.
|
||||
|
||||
아래 signature를 이미 읽은 PLAN/source/test/contract에서 한 번만 확인한다. 양성 조건이 보인 이름만 기록하고, match하지 않은 signature의 부재를 증명하지 않는다. 필요한 범위가 불명확하면 risk를 `unknown`으로 만들지 말고 closure에서 처리한다.
|
||||
|
||||
- `temporal_state`: 상태 3개 이상과 partial/retry/cancel/recovery/stale/duplicate 경로
|
||||
- `concurrent_consistency`: actor 2개 이상과 atomic snapshot/lock order/exactly-once/race-free 제약
|
||||
- `boundary_contract`: component 3개 이상 또는 consumer 2개 이상과 validation/immutability/compatibility 제약
|
||||
- `structured_interpretation`: parser/lexer/protocol assembly/multi-source merge와 nesting/quoting/precedence/deduplication 위험
|
||||
- `variant_product`: 독립 variant 축 2개 이상과 조합 검증
|
||||
|
||||
중복 없는 이름 수를 `loop_risk_count=0..5`로 사용한다.
|
||||
|
||||
- `risk_boundary = large_indivisible_context || loop_risk_count >= 4`
|
||||
- `recovery_boundary = review_rework_count >= 2 || evidence_integrity_failure`
|
||||
|
||||
`review_rework_count`는 같은 task path의 archived `WARN|FAIL` 수에 현재 non-PASS verdict를 더한 값이다. 첫 non-PASS follow-up은 1, 두 번째는 2다.
|
||||
|
||||
### 5. Build route 확정
|
||||
|
||||
첫 번째로 일치하는 규칙을 적용한다.
|
||||
|
||||
| 조건 | `route_basis` | lane |
|
||||
|------|---------------|------|
|
||||
| base basis가 `capability-gap` | `capability-gap` | cloud |
|
||||
| base basis가 `grade-boundary` | `grade-boundary` | cloud |
|
||||
| base basis가 `local-fit`이고 `recovery_boundary` | `recovery-boundary` | cloud |
|
||||
| base basis가 `local-fit`이고 `risk_boundary` | `risk-boundary` | cloud |
|
||||
| 그 외 | `local-fit` | local |
|
||||
|
||||
risk/recovery는 local-fit build의 승격 조건이다. 이미 cloud인 capability/grade basis를 덮어쓰지 않는다. grade는 lane 변경과 무관하게 보존한다. review는 `official-review`, cloud, 실제 G를 사용한다.
|
||||
|
||||
### 6. Finalizer 실행
|
||||
|
||||
`status=routed`일 때만 아래 명령을 정확히 한 번 실행한다.
|
||||
|
||||
```bash
|
||||
agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-policy.sh pair \
|
||||
<build-base-basis> \
|
||||
<large-indivisible-context> <loop-risk-count> \
|
||||
<review-rework-count> <evidence-integrity-failure> \
|
||||
<build-scope> <build-state> <build-blast> <build-evidence> <build-verification> \
|
||||
official-review \
|
||||
<review-scope> <review-state> <review-blast> <review-evidence> <review-verification>
|
||||
```
|
||||
|
||||
`needs_evidence` 또는 `blocked`에서는 해당 target의 `lane`, `grade_scores`, `grade`, `filename`을 `null`로 둔다.
|
||||
finalizer 출력만 사용한다. lane, grade, boundary, filename을 수작업으로 만들지 않는다.
|
||||
|
||||
## 금지 사항
|
||||
## 출력 계약
|
||||
|
||||
- 이전 lane/G를 기본값, 최소값, 비교 기준으로 사용하지 않는다.
|
||||
- 기존 평가가 있는 재평가를 같은 평가 context에서 수행하지 않는다.
|
||||
- local 실패를 이유로 cloud로 자동 승격하지 않는다.
|
||||
- 높은 local G로 cloud에 필요한 컨텍스트나 판단을 보상하지 않는다.
|
||||
- 파일 수, 동시성, dirty 상태, Required 개수 같은 단일 휴리스틱으로 lane을 정하지 않는다.
|
||||
- grade나 filename을 formatter script 출력과 다르게 수작업으로 만들지 않는다.
|
||||
- `needs_evidence`를 `cloud`로 치환하거나 미완성 상태에서 routed filename을 만들지 않는다.
|
||||
- PLAN, CODE_REVIEW, archive, complete.log 파일을 직접 생성·수정·이동하지 않는다.
|
||||
항상 `status`, `evaluation_mode`, `missing_evidence`, `blocked_reason`을 반환한다. `status=routed`이면 다음 필드를 모두 반환한다.
|
||||
|
||||
- 공통: `finalizer=finalize-task-policy.sh`, `finalizer_mode=pair`
|
||||
- target별: `closures`, `closure_basis`, `capability_gap`, `grade_scores`, `route_basis`, `lane`, `grade`, `filename`
|
||||
- build 전용: `base_route_basis`, `large_indivisible_context`, `matched_loop_risk_signatures`, `loop_risk_count`, `review_rework_count`, `evidence_integrity_failure`, `risk_boundary_matched`, `recovery_boundary_matched`
|
||||
- review 전용: `route_basis=official-review`, `adapter=codex`, `model=gpt-5.6-sol`, `reasoning_effort=xhigh`
|
||||
|
||||
## 완료 확인
|
||||
|
||||
- 기존 PLAN 분석만 사용했고 routing-only 탐색을 하지 않았는가
|
||||
- split packet마다 독립 평가했는가
|
||||
- G01~G08 cloud route가 선택된 `route_basis` 하나와 일치하는 근거를 갖는가
|
||||
- G09~G10은 risk/recovery 신호가 있어도 `grade-boundary`를 유지하는가
|
||||
- finalizer 출력과 active filename이 일치하는가
|
||||
|
||||
## 금지
|
||||
|
||||
- unmatched signature의 부재를 찾기 위해 추가 탐색하지 않는다.
|
||||
- 이전 lane/G나 finding 개수를 승격 근거로 쓰지 않는다.
|
||||
- cloud가 해소할 수 없는 문제를 cloud route로 바꾸지 않는다.
|
||||
- PLAN, CODE_REVIEW, archive, complete.log를 직접 수정하지 않는다.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
interface:
|
||||
display_name: "Finalize Task Routing"
|
||||
short_description: "Finalize task lane, grade, and filenames"
|
||||
default_prompt: "Use $finalize-task-routing after task analysis to independently determine build/review lanes, grades, and canonical filenames."
|
||||
short_description: "Route plans once with explicit cloud boundaries"
|
||||
default_prompt: "Use $finalize-task-routing once on the completed plan to select local or cloud from explicit capability, grade, risk, and recovery boundaries."
|
||||
|
|
|
|||
168
agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-policy.sh
Executable file
168
agent-ops/skills/common/finalize-task-routing/scripts/finalize-task-policy.sh
Executable file
|
|
@ -0,0 +1,168 @@
|
|||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
usage() {
|
||||
printf '%s\n' \
|
||||
'usage:' \
|
||||
' finalize-task-policy.sh pair <build-base-basis> <large-indivisible-context> <loop-risk-count> <review-rework-count> <evidence-integrity-failure> <build-scope> <build-state> <build-blast> <build-evidence> <build-verification> official-review <review-scope> <review-state> <review-blast> <review-evidence> <review-verification>' \
|
||||
' build-base-basis: local-fit | capability-gap | grade-boundary' \
|
||||
' boolean fields: true | false; loop-risk-count: 0..5; review-rework-count: non-negative integer' >&2
|
||||
exit 2
|
||||
}
|
||||
|
||||
script_dir=$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" && pwd)
|
||||
formatter="$script_dir/finalize-task-route.sh"
|
||||
|
||||
field() {
|
||||
local output=$1
|
||||
local key=$2
|
||||
local value
|
||||
value=$(sed -n "s/^${key}=//p" <<<"$output")
|
||||
if [[ -z "$value" ]]; then
|
||||
printf 'missing formatter field: %s\n' "$key" >&2
|
||||
exit 3
|
||||
fi
|
||||
printf '%s\n' "$value"
|
||||
}
|
||||
|
||||
finalize_build() {
|
||||
local base_basis=$1
|
||||
shift
|
||||
local scores=("$@")
|
||||
local lane
|
||||
local route
|
||||
|
||||
case "$base_basis" in
|
||||
local-fit|capability-gap|grade-boundary)
|
||||
;;
|
||||
*)
|
||||
usage
|
||||
;;
|
||||
esac
|
||||
|
||||
BUILD_BASE_ROUTE_BASIS=$base_basis
|
||||
BUILD_RISK_BOUNDARY_MATCHED=false
|
||||
BUILD_RECOVERY_BOUNDARY_MATCHED=false
|
||||
if [[ "$BUILD_LARGE_INDIVISIBLE_CONTEXT" == true ||
|
||||
"$BUILD_LOOP_RISK_COUNT" -ge 4 ]]; then
|
||||
BUILD_RISK_BOUNDARY_MATCHED=true
|
||||
fi
|
||||
if [[ "$BUILD_EVIDENCE_INTEGRITY_FAILURE" == true ||
|
||||
"$BUILD_REVIEW_REWORK_COUNT" -ge 2 ]]; then
|
||||
BUILD_RECOVERY_BOUNDARY_MATCHED=true
|
||||
fi
|
||||
|
||||
if [[ "$base_basis" == capability-gap ]]; then
|
||||
BUILD_ROUTE_BASIS=capability-gap
|
||||
elif [[ "$base_basis" == local-fit &&
|
||||
"$BUILD_RECOVERY_BOUNDARY_MATCHED" == true ]]; then
|
||||
BUILD_ROUTE_BASIS=recovery-boundary
|
||||
elif [[ "$base_basis" == local-fit &&
|
||||
"$BUILD_RISK_BOUNDARY_MATCHED" == true ]]; then
|
||||
BUILD_ROUTE_BASIS=risk-boundary
|
||||
else
|
||||
BUILD_ROUTE_BASIS=$base_basis
|
||||
fi
|
||||
|
||||
if [[ "$BUILD_ROUTE_BASIS" == local-fit ]]; then
|
||||
lane=local
|
||||
else
|
||||
lane=cloud
|
||||
fi
|
||||
|
||||
route=$("$formatter" build "$lane" "${scores[@]}")
|
||||
BUILD_GRADE=$(field "$route" grade)
|
||||
if [[ "$base_basis" == local-fit &&
|
||||
( "$BUILD_GRADE" == G09 || "$BUILD_GRADE" == G10 ) ]]; then
|
||||
printf 'local-fit is valid only for G01-G08\n' >&2
|
||||
exit 2
|
||||
fi
|
||||
if [[ "$base_basis" == grade-boundary &&
|
||||
"$BUILD_GRADE" != G09 && "$BUILD_GRADE" != G10 ]]; then
|
||||
printf 'grade-boundary is valid only for G09-G10\n' >&2
|
||||
exit 2
|
||||
fi
|
||||
BUILD_LANE=$(field "$route" lane)
|
||||
BUILD_FILENAME=$(field "$route" filename)
|
||||
}
|
||||
|
||||
finalize_review() {
|
||||
local route_basis=$1
|
||||
shift
|
||||
local scores=("$@")
|
||||
local route
|
||||
|
||||
[[ "$route_basis" == official-review ]] || usage
|
||||
route=$("$formatter" review cloud "${scores[@]}")
|
||||
REVIEW_ROUTE_BASIS=$route_basis
|
||||
REVIEW_LANE=$(field "$route" lane)
|
||||
REVIEW_GRADE=$(field "$route" grade)
|
||||
REVIEW_FILENAME=$(field "$route" filename)
|
||||
REVIEW_ADAPTER=codex
|
||||
REVIEW_MODEL=gpt-5.6-sol
|
||||
REVIEW_REASONING_EFFORT=xhigh
|
||||
}
|
||||
|
||||
emit_build() {
|
||||
printf 'build_base_route_basis=%s\n' "$BUILD_BASE_ROUTE_BASIS"
|
||||
printf 'build_route_basis=%s\n' "$BUILD_ROUTE_BASIS"
|
||||
printf 'build_large_indivisible_context=%s\n' "$BUILD_LARGE_INDIVISIBLE_CONTEXT"
|
||||
printf 'build_loop_risk_count=%s\n' "$BUILD_LOOP_RISK_COUNT"
|
||||
printf 'build_risk_boundary_matched=%s\n' "$BUILD_RISK_BOUNDARY_MATCHED"
|
||||
printf 'build_review_rework_count=%s\n' "$BUILD_REVIEW_REWORK_COUNT"
|
||||
printf 'build_evidence_integrity_failure=%s\n' "$BUILD_EVIDENCE_INTEGRITY_FAILURE"
|
||||
printf 'build_recovery_boundary_matched=%s\n' "$BUILD_RECOVERY_BOUNDARY_MATCHED"
|
||||
printf 'build_lane=%s\n' "$BUILD_LANE"
|
||||
printf 'build_grade=%s\n' "$BUILD_GRADE"
|
||||
printf 'build_filename=%s\n' "$BUILD_FILENAME"
|
||||
}
|
||||
|
||||
emit_review() {
|
||||
printf 'review_route_basis=%s\n' "$REVIEW_ROUTE_BASIS"
|
||||
printf 'review_lane=%s\n' "$REVIEW_LANE"
|
||||
printf 'review_grade=%s\n' "$REVIEW_GRADE"
|
||||
printf 'review_filename=%s\n' "$REVIEW_FILENAME"
|
||||
printf 'review_adapter=%s\n' "$REVIEW_ADAPTER"
|
||||
printf 'review_model=%s\n' "$REVIEW_MODEL"
|
||||
printf 'review_reasoning_effort=%s\n' "$REVIEW_REASONING_EFFORT"
|
||||
}
|
||||
|
||||
mode=${1:-}
|
||||
[[ "$mode" == pair && $# -eq 17 ]] || usage
|
||||
|
||||
case "$3" in
|
||||
true|false)
|
||||
BUILD_LARGE_INDIVISIBLE_CONTEXT=$3
|
||||
;;
|
||||
*)
|
||||
usage
|
||||
;;
|
||||
esac
|
||||
|
||||
case "$4" in
|
||||
0|1|2|3|4|5)
|
||||
BUILD_LOOP_RISK_COUNT=$4
|
||||
;;
|
||||
*)
|
||||
usage
|
||||
;;
|
||||
esac
|
||||
[[ "$5" =~ ^[0-9]+$ ]] || usage
|
||||
BUILD_REVIEW_REWORK_COUNT=$5
|
||||
|
||||
case "$6" in
|
||||
true|false)
|
||||
BUILD_EVIDENCE_INTEGRITY_FAILURE=$6
|
||||
;;
|
||||
*)
|
||||
usage
|
||||
;;
|
||||
esac
|
||||
|
||||
finalize_build "$2" "${@:7:5}"
|
||||
finalize_review "${12}" "${@:13:5}"
|
||||
|
||||
printf 'finalizer=finalize-task-policy.sh\n'
|
||||
printf 'finalizer_mode=%s\n' "$mode"
|
||||
emit_build
|
||||
emit_review
|
||||
|
|
@ -13,8 +13,7 @@ fi
|
|||
|
||||
target=$1
|
||||
lane=$2
|
||||
shift 2
|
||||
scores=("$@")
|
||||
scores=("${@:3:5}")
|
||||
|
||||
case "$target" in
|
||||
build)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,364 @@
|
|||
#!/usr/bin/env python3
|
||||
from __future__ import annotations
|
||||
|
||||
import itertools
|
||||
import subprocess
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
SKILL_DIR = Path(__file__).resolve().parents[1]
|
||||
FORMATTER = SKILL_DIR / "scripts" / "finalize-task-route.sh"
|
||||
POLICY_FINALIZER = SKILL_DIR / "scripts" / "finalize-task-policy.sh"
|
||||
PLAN_SKILL = SKILL_DIR.parent / "plan" / "SKILL.md"
|
||||
COMMON_SKILLS_DIR = SKILL_DIR.parent
|
||||
COMMON_RULES_DIR = SKILL_DIR.parents[2] / "rules" / "common"
|
||||
|
||||
|
||||
GRADE_VECTORS = {
|
||||
1: (0, 0, 0, 0, 0),
|
||||
2: (2, 0, 0, 0, 0),
|
||||
3: (2, 1, 0, 0, 0),
|
||||
4: (2, 2, 0, 0, 0),
|
||||
5: (2, 2, 1, 0, 0),
|
||||
6: (2, 2, 2, 0, 0),
|
||||
7: (2, 2, 2, 1, 0),
|
||||
8: (2, 2, 2, 2, 0),
|
||||
9: (2, 2, 2, 2, 1),
|
||||
10: (2, 2, 2, 2, 2),
|
||||
}
|
||||
|
||||
|
||||
def run(
|
||||
script: Path, *args: object, check: bool = True
|
||||
) -> subprocess.CompletedProcess[str]:
|
||||
return subprocess.run(
|
||||
[str(script), *(str(arg) for arg in args)],
|
||||
check=check,
|
||||
capture_output=True,
|
||||
text=True,
|
||||
timeout=5,
|
||||
)
|
||||
|
||||
|
||||
def fields(stdout: str) -> dict[str, str]:
|
||||
return dict(line.split("=", 1) for line in stdout.splitlines())
|
||||
|
||||
|
||||
def expected_build_route(basis: str, grade: int) -> tuple[str, bool]:
|
||||
if basis == "local-fit":
|
||||
return "local", grade <= 8
|
||||
if basis == "capability-gap":
|
||||
return "cloud", True
|
||||
return "cloud", grade >= 9
|
||||
|
||||
|
||||
def pair_args(
|
||||
build_basis: str,
|
||||
build_grade: int,
|
||||
review_grade: int,
|
||||
large_context: str = "false",
|
||||
risk_count: int = 0,
|
||||
review_rework_count: int = 0,
|
||||
evidence_integrity: str = "false",
|
||||
review_basis: str = "official-review",
|
||||
) -> tuple[object, ...]:
|
||||
return (
|
||||
"pair",
|
||||
build_basis,
|
||||
large_context,
|
||||
risk_count,
|
||||
review_rework_count,
|
||||
evidence_integrity,
|
||||
*GRADE_VECTORS[build_grade],
|
||||
review_basis,
|
||||
*GRADE_VECTORS[review_grade],
|
||||
)
|
||||
|
||||
|
||||
class FinalizeTaskRoutingTests(unittest.TestCase):
|
||||
def assert_route(
|
||||
self,
|
||||
result: dict[str, str],
|
||||
target: str,
|
||||
basis: str,
|
||||
lane: str,
|
||||
grade: int,
|
||||
) -> None:
|
||||
prefix = "PLAN" if target == "build" else "CODE_REVIEW"
|
||||
self.assertEqual(result[f"{target}_route_basis"], basis)
|
||||
self.assertEqual(result[f"{target}_lane"], lane)
|
||||
self.assertEqual(result[f"{target}_grade"], f"G{grade:02d}")
|
||||
self.assertEqual(
|
||||
result[f"{target}_filename"], f"{prefix}-{lane}-G{grade:02d}.md"
|
||||
)
|
||||
|
||||
def test_common_workflows_do_not_depend_on_project_runtime(self) -> None:
|
||||
contract_roots = (
|
||||
COMMON_RULES_DIR / "rules-roadmap.md",
|
||||
COMMON_SKILLS_DIR / "create-roadmap",
|
||||
COMMON_SKILLS_DIR / "update-roadmap",
|
||||
COMMON_SKILLS_DIR / "sync-milestone-workstate",
|
||||
COMMON_SKILLS_DIR / "complete-milestone",
|
||||
COMMON_SKILLS_DIR / "plan",
|
||||
COMMON_SKILLS_DIR / "code-review",
|
||||
COMMON_SKILLS_DIR / "refine-local-plans",
|
||||
COMMON_SKILLS_DIR / "finalize-task-routing",
|
||||
)
|
||||
contract_files: list[Path] = []
|
||||
for root in contract_roots:
|
||||
candidates = (root,) if root.is_file() else root.rglob("*")
|
||||
contract_files.extend(
|
||||
path
|
||||
for path in candidates
|
||||
if path.is_file()
|
||||
and path.suffix in {".md", ".sh", ".yaml"}
|
||||
and "tests" not in path.parts
|
||||
)
|
||||
|
||||
forbidden = (
|
||||
"agent-ops/skills/project/",
|
||||
"orchestrate-agent-task-loop",
|
||||
"WORK_LOG.md",
|
||||
"work_log_",
|
||||
"dispatch.py",
|
||||
)
|
||||
for path in sorted(contract_files):
|
||||
text = path.read_text(encoding="utf-8")
|
||||
for needle in forbidden:
|
||||
with self.subTest(path=path, needle=needle):
|
||||
self.assertNotIn(needle, text)
|
||||
|
||||
def test_request_to_worker_contract_is_ordered_and_consistent(self) -> None:
|
||||
routing_skill = (SKILL_DIR / "SKILL.md").read_text(encoding="utf-8")
|
||||
plan_skill = PLAN_SKILL.read_text(encoding="utf-8")
|
||||
|
||||
self.assertIn("`matched_loop_risk_signatures`", routing_skill)
|
||||
self.assertIn("`temporal_state`", routing_skill)
|
||||
self.assertNotIn("`ordered_transitions`", routing_skill)
|
||||
self.assertIn("routing 때문에 source/test/log를 다시 읽지", routing_skill)
|
||||
self.assertIn("첫 번째로 일치하는 규칙", routing_skill)
|
||||
self.assertIn("이미 cloud인 capability/grade basis를 덮어쓰지 않는다", routing_skill)
|
||||
self.assertIn("review gap만 기록; build basis에는 영향 없음", routing_skill)
|
||||
|
||||
markers = (
|
||||
"**Assess split boundaries once**",
|
||||
"**Derive routing signals once**",
|
||||
"## Step 3 - Finalize Task Routing",
|
||||
)
|
||||
positions = [plan_skill.index(marker) for marker in markers]
|
||||
self.assertEqual(positions, sorted(positions))
|
||||
self.assertNotIn("**Extract the request contract**", plan_skill)
|
||||
self.assertNotIn("`요청 계약`", plan_skill)
|
||||
self.assertIn("reuse the values already validated and appended", plan_skill)
|
||||
policy_script = POLICY_FINALIZER.read_text(encoding="utf-8")
|
||||
self.assertNotIn("build_risk_triggered", policy_script)
|
||||
self.assertNotIn("boundary_triggered", policy_script)
|
||||
|
||||
def test_formatter_grade_and_filename_matrix(self) -> None:
|
||||
for target, lane, grade in itertools.product(
|
||||
("build", "review"), ("local", "cloud"), range(1, 11)
|
||||
):
|
||||
with self.subTest(target=target, lane=lane, grade=grade):
|
||||
result = fields(run(FORMATTER, target, lane, *GRADE_VECTORS[grade]).stdout)
|
||||
prefix = "PLAN" if target == "build" else "CODE_REVIEW"
|
||||
self.assertEqual(result["grade"], f"G{grade:02d}")
|
||||
self.assertEqual(
|
||||
result["filename"], f"{prefix}-{lane}-G{grade:02d}.md"
|
||||
)
|
||||
|
||||
def test_formatter_invalid_inputs_are_rejected(self) -> None:
|
||||
valid = list(GRADE_VECTORS[4])
|
||||
invalid_cases: list[tuple[object, ...]] = [
|
||||
("deploy", "local", *valid),
|
||||
("build", "hybrid", *valid),
|
||||
("build", "local", *valid[:-1]),
|
||||
("build", "local", *valid, 1),
|
||||
]
|
||||
for index in range(5):
|
||||
scores = valid.copy()
|
||||
scores[index] = 3
|
||||
invalid_cases.append(("build", "local", *scores))
|
||||
for args in invalid_cases:
|
||||
with self.subTest(args=args):
|
||||
self.assertEqual(run(FORMATTER, *args, check=False).returncode, 2)
|
||||
|
||||
def test_pair_policy_validates_each_build_basis_and_grade(self) -> None:
|
||||
for basis, grade in itertools.product(
|
||||
("local-fit", "capability-gap", "grade-boundary"), range(1, 11)
|
||||
):
|
||||
with self.subTest(basis=basis, grade=grade):
|
||||
completed = run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args(basis, grade, 1),
|
||||
check=False,
|
||||
)
|
||||
lane, valid = expected_build_route(basis, grade)
|
||||
if not valid:
|
||||
self.assertEqual(completed.returncode, 2)
|
||||
continue
|
||||
self.assertEqual(completed.returncode, 0, completed.stderr)
|
||||
result = fields(completed.stdout)
|
||||
self.assertEqual(result["finalizer_mode"], "pair")
|
||||
self.assert_route(result, "build", basis, lane, grade)
|
||||
|
||||
def test_official_review_keeps_grade_and_fixes_execution_target(self) -> None:
|
||||
for grade in range(1, 11):
|
||||
with self.subTest(grade=grade):
|
||||
result = fields(
|
||||
run(POLICY_FINALIZER, *pair_args("local-fit", 1, grade)).stdout
|
||||
)
|
||||
self.assert_route(
|
||||
result, "review", "official-review", "cloud", grade
|
||||
)
|
||||
self.assertEqual(result["review_adapter"], "codex")
|
||||
self.assertEqual(result["review_model"], "gpt-5.6-sol")
|
||||
self.assertEqual(result["review_reasoning_effort"], "xhigh")
|
||||
|
||||
def test_low_grade_cloud_requires_capability_gap_basis(self) -> None:
|
||||
rejected = run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args("grade-boundary", 4, 4),
|
||||
check=False,
|
||||
)
|
||||
self.assertEqual(rejected.returncode, 2)
|
||||
|
||||
accepted = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args("capability-gap", 4, 4),
|
||||
).stdout
|
||||
)
|
||||
self.assert_route(accepted, "build", "capability-gap", "cloud", 4)
|
||||
|
||||
def test_loop_risk_boundary_routes_four_or_more_signatures_to_cloud(self) -> None:
|
||||
for risk_count in range(6):
|
||||
with self.subTest(risk_count=risk_count):
|
||||
result = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args("local-fit", 7, 6, risk_count=risk_count),
|
||||
).stdout
|
||||
)
|
||||
self.assertEqual(result["build_loop_risk_count"], str(risk_count))
|
||||
expected_basis = "risk-boundary" if risk_count >= 4 else "local-fit"
|
||||
expected_lane = "cloud" if risk_count >= 4 else "local"
|
||||
self.assertEqual(result["build_base_route_basis"], "local-fit")
|
||||
self.assert_route(result, "build", expected_basis, expected_lane, 7)
|
||||
|
||||
def test_large_indivisible_context_routes_to_cloud(self) -> None:
|
||||
result = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args("local-fit", 4, 4, large_context="true"),
|
||||
).stdout
|
||||
)
|
||||
self.assertEqual(result["build_risk_boundary_matched"], "true")
|
||||
self.assert_route(result, "build", "risk-boundary", "cloud", 4)
|
||||
|
||||
def test_review_rework_and_evidence_integrity_route_to_cloud(self) -> None:
|
||||
one_rework = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args("local-fit", 4, 4, review_rework_count=1),
|
||||
).stdout
|
||||
)
|
||||
self.assert_route(one_rework, "build", "local-fit", "local", 4)
|
||||
|
||||
two_reworks = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args("local-fit", 4, 4, review_rework_count=2),
|
||||
).stdout
|
||||
)
|
||||
self.assert_route(
|
||||
two_reworks, "build", "recovery-boundary", "cloud", 4
|
||||
)
|
||||
|
||||
evidence_failure = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args("local-fit", 4, 4, evidence_integrity="true"),
|
||||
).stdout
|
||||
)
|
||||
self.assert_route(
|
||||
evidence_failure, "build", "recovery-boundary", "cloud", 4
|
||||
)
|
||||
|
||||
recovery_over_risk = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args(
|
||||
"local-fit",
|
||||
4,
|
||||
4,
|
||||
large_context="true",
|
||||
review_rework_count=2,
|
||||
),
|
||||
).stdout
|
||||
)
|
||||
self.assertEqual(recovery_over_risk["build_base_route_basis"], "local-fit")
|
||||
self.assert_route(
|
||||
recovery_over_risk, "build", "recovery-boundary", "cloud", 4
|
||||
)
|
||||
|
||||
def test_grade_boundary_is_not_relabelled_by_escalation_signals(self) -> None:
|
||||
result = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args(
|
||||
"grade-boundary",
|
||||
9,
|
||||
4,
|
||||
large_context="true",
|
||||
risk_count=5,
|
||||
review_rework_count=2,
|
||||
evidence_integrity="true",
|
||||
),
|
||||
).stdout
|
||||
)
|
||||
self.assertEqual(result["build_base_route_basis"], "grade-boundary")
|
||||
self.assertEqual(result["build_risk_boundary_matched"], "true")
|
||||
self.assertEqual(result["build_recovery_boundary_matched"], "true")
|
||||
self.assert_route(result, "build", "grade-boundary", "cloud", 9)
|
||||
|
||||
def test_capability_gap_has_precedence_over_other_cloud_triggers(self) -> None:
|
||||
result = fields(
|
||||
run(
|
||||
POLICY_FINALIZER,
|
||||
*pair_args(
|
||||
"capability-gap",
|
||||
4,
|
||||
4,
|
||||
large_context="true",
|
||||
risk_count=5,
|
||||
review_rework_count=2,
|
||||
evidence_integrity="true",
|
||||
),
|
||||
).stdout
|
||||
)
|
||||
self.assertEqual(result["build_base_route_basis"], "capability-gap")
|
||||
self.assert_route(result, "build", "capability-gap", "cloud", 4)
|
||||
|
||||
def test_policy_invalid_inputs_are_rejected(self) -> None:
|
||||
valid = GRADE_VECTORS[4]
|
||||
invalid_cases = (
|
||||
("pair", "local-fit", "unknown", 0, 0, "false", *valid, "official-review", *valid),
|
||||
("pair", "local-fit", "false", 6, 0, "false", *valid, "official-review", *valid),
|
||||
("pair", "local-fit", "false", 0, -1, "false", *valid, "official-review", *valid),
|
||||
("pair", "local-fit", "false", 0, 0, "unknown", *valid, "official-review", *valid),
|
||||
("pair", "local", "false", 0, 0, "false", *valid, "official-review", *valid),
|
||||
("pair", "local-fit", "false", 0, 0, "false", *valid, "cloud", *valid),
|
||||
("build", "local-fit", "false", 0, 0, "false", *valid),
|
||||
("pair", "local-fit", "false", 0, 0, "false", *valid, "official-review", *valid[:-1]),
|
||||
)
|
||||
for args in invalid_cases:
|
||||
with self.subTest(args=args):
|
||||
self.assertEqual(
|
||||
run(POLICY_FINALIZER, *args, check=False).returncode,
|
||||
2,
|
||||
)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
|
|
@ -11,14 +11,14 @@ Create the planning artifacts for the implementation loop:
|
|||
|
||||
```text
|
||||
plan skill -> analysis -> finalize-task-routing -> PLAN-{build_lane}-GNN.md + CODE_REVIEW-{review_lane}-GNN.md stub
|
||||
implementation -> code changes + filled CODE_REVIEW-{review_lane}-GNN.md, or blocked-state user-review request recorded in the review stub
|
||||
implementation -> code changes + filled implementation evidence in CODE_REVIEW-{review_lane}-GNN.md
|
||||
code-review skill -> verdict + archive, complete.log and task-directory archive move, USER_REVIEW.md, or mandatory plan-skill follow-up
|
||||
runtime -> for m-prefixed PASS completion events, state check and optional update-roadmap call
|
||||
```
|
||||
|
||||
`code-review` may stop the automatic loop with `USER_REVIEW.md` only when a selected Milestone `구현 잠금 > 결정 필요` item blocks implementation. Repeated non-PASS reviews, test environment blockers, external environment/secret/service setup, generic scope changes, and verification evidence gaps are not user-review reasons by themselves; they should become normal follow-up plans or unresolved verification evidence. Plan creation after `USER_REVIEW.md` requires the linked Milestone decision to be resolved. If the decision closes the task as complete/PASS, code-review resolves `USER_REVIEW.md`, writes `complete.log`, and archives the task instead of creating a new plan.
|
||||
|
||||
The plan file and review stub must be self-sufficient for implementation agents that do not read this skill. If implementation discovers a selected Milestone `구현 잠금 > 결정 필요` item that blocks safe progress, the implementing agent records a `사용자 리뷰 요청` in the active `CODE_REVIEW-*-G??.md`, leaves active files in place, and reports ready for review. This stop path is file-based only during implementation: the implementing agent must not interrupt the loop by asking the user directly, presenting choices in chat, or calling a user-input tool such as `request_user_input`. The code-review skill validates that request and writes `USER_REVIEW.md` when the stop is justified. Use `agent-ops/skills/common/_templates/implementation-user-review-request-section.md` as the shared section template.
|
||||
The plan file and review stub must be self-sufficient for implementation agents that do not read this skill. Implementing agents fill the active review's implementation evidence. They never decide whether user review is needed, write a user-review request, ask the user for a decision, create `USER_REVIEW.md`, or modify runtime-owned artifacts; those control-plane responsibilities belong to the official code-review skill and runtime.
|
||||
|
||||
## Workflow Contract
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ Task path terms:
|
|||
- `{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.
|
||||
- Split work stores active files under `agent-task/{task_group}/{subtask_dir}/`; the parent `agent-task/{task_group}/` contains no active plan/review files.
|
||||
|
||||
Filename rules:
|
||||
|
||||
|
|
@ -51,27 +51,25 @@ Filename rules:
|
|||
Role boundary rules:
|
||||
|
||||
- Implementing agents fill implementation-owned `CODE_REVIEW-*-G??.md` sections, keep active files in place, and report ready for review.
|
||||
- If implementation cannot continue because a selected Milestone `구현 잠금 > 결정 필요` item is unresolved, implementing agents fill the review stub's `사용자 리뷰 요청` section with the exact linked decision, evidence, commands/output, and resume condition, then stop with active files in place.
|
||||
- During implementation, do not ask the user directly, present multiple-choice prompts in chat, or call `request_user_input`/equivalent input tools. Milestone lock choices belong in the review stub's `사용자 리뷰 요청` section so code-review can validate and create `USER_REVIEW.md` only when justified.
|
||||
- If implementation cannot continue, implementing agents record the exact blocker, attempted commands/output, and resume condition only in `검증 결과` or `계획 대비 변경 사항`, then leave the active files in place for official review.
|
||||
- During implementation, do not ask the user directly, present choices, call user-input tools, or create control-plane stop files. The official reviewer owns all next-state classification.
|
||||
- Required UI evidence capture that needs a user-owned device, emulator, permission, secret, or interactive access unavailable to the agent is a verification blocker, not a user-review reason by itself. Record attempted commands and blocker evidence in `검증 결과` or `계획 대비 변경 사항` so code-review can write a normal follow-up or unresolved verification report.
|
||||
- Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, review-only checklist) is code-review-skill only.
|
||||
- Finalization (`코드리뷰 결과`, plan/review log rename, `complete.log`, task artifact archive moves, review-only checklist) is code-review-skill only.
|
||||
|
||||
Split decision policy:
|
||||
|
||||
- Default to multiple subtask directories under one task group. 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 subtask directories under one task group.
|
||||
- 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 the shared `{task_group}`, each sibling `{subtask_dir}`, and its dependency relationship.
|
||||
- Split only by behavior/contract boundaries whose children each have a stable intermediate contract and deterministic PASS verification.
|
||||
- Keep every production change with its required tests; use a test-only child only for additional integration evidence.
|
||||
- Keep one plan when the work is compact or split would sever one correctness/transaction invariant. Never split to lower lane, grade, context, or signature count.
|
||||
- If the existing analysis cannot prove that children independently PASS, keep the atomic work together and route it as one packet.
|
||||
- Record either each child's contract/dependency or the invariant that makes one plan indivisible.
|
||||
|
||||
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.
|
||||
- Split when mobile/UI verification can hang on emulator/device state, modal, permission dialog, animation, or external runner; isolate evidence recovery from feature implementation.
|
||||
- Separate foundation from rollout only when the foundation preserves compatibility and independently passes.
|
||||
- Split domains, verification profiles, or risk slices only when each independently passes.
|
||||
- Split work that can produce a useful earlier `complete.log` without invalid intermediate state.
|
||||
- Isolate mobile/UI/external verification that can block otherwise completed implementation.
|
||||
|
||||
Task directory naming rules:
|
||||
|
||||
|
|
@ -82,6 +80,8 @@ Task directory naming rules:
|
|||
- When split gates require decomposition, create one shared category folder and multiple subtask directories under it. Each subtask directory owns exactly one normal active plan file and one normal active review stub.
|
||||
- Multi-plan output is a set of independent `PLAN-{build_lane}-GNN.md` + `CODE_REVIEW-{review_lane}-GNN.md` pairs across `agent-task/{task_group}/{subtask_dir}/` folders, not multiple plan files inside one folder.
|
||||
- Multi-plan subtask directory names must start with a stable two-digit task index. The index must increase across sibling subtask directories for sorting, but it is not a serial execution dependency.
|
||||
- Assign new sibling indices in topological dependency order so every producer precedes its consumers. For ties, keep the planned sibling order; assign each task the lowest collision-free two-digit index greater than all of its predecessors.
|
||||
- Before writing the pairs, verify that the sibling dependency graph has no cycle and every predecessor index is lower than its consumer index. Skip an index only when it is not greater than an unchanged existing predecessor or is already occupied by an active/archived sibling.
|
||||
- Use `NN_{subtask_name}` for a task with no runtime dependencies, e.g. `01_core`, `04_docs`, `05_ui`.
|
||||
- Use `NN+PP[,QQ...]_{subtask_name}` for a task that depends on earlier task indices, e.g. `02+01_db`, `03+01,02_api`, `06+05_integration`.
|
||||
- Valid independent pattern: `^[0-9]{2}_[a-z0-9_]+$`.
|
||||
|
|
@ -98,17 +98,16 @@ Task directory naming rules:
|
|||
- Example: split a refactoring common core plus two app integrations under `agent-task/refactoring/` as `01_core`, `02+01_edge_integration`, `03+01_node_integration`. Both integrations depend only on `01_core` and may run in parallel after `01_core` has `complete.log`.
|
||||
- Example: split three sequential tasks under one task group as `01_schema`, `02+01_migration`, `03+02_api`.
|
||||
- Example: split independent docs/UI plus an integration under one task group as `01_core`, `02+01_db`, `03+02_api`, `04_docs`, `05_ui`, `06+05_integration`; `01_core`, `04_docs`, and `05_ui` can start together, and `06+05_integration` waits only for `05_ui`.
|
||||
- Preserve task group and subtask directory names verbatim; do not normalize, reinterpret, or choose execution order by agent judgment.
|
||||
- After a pair is written, preserve its task group and subtask directory name verbatim. Only an explicit `refine-local-plans` run may rename eligible unstarted local siblings by its dependency-order rules.
|
||||
|
||||
Final routing boundary:
|
||||
|
||||
- Do not estimate, inherit, or write lane/G while analyzing. Keep the task `unrouted` until all plan scope, split, verification, evidence, ownership, and decision facts are complete.
|
||||
- Execute `agent-ops/skills/common/finalize-task-routing/SKILL.md` for both `build` and `review` after analysis. Its routed outputs are the only source for active PLAN/CODE_REVIEW filenames.
|
||||
- Apply this boundary to first-pass plans, review WARN/FAIL follow-ups, USER_REVIEW replans, and each split subtask independently.
|
||||
- A previous loop's lane, grade, score, rationale, and filename are quarantined. Prior code paths, actual command output, and review findings may be carried only as revalidated raw evidence.
|
||||
- `needs_evidence` requires evidence collection and a fresh full routing run. `blocked` stops plan-file creation. Neither state may produce active routed filenames.
|
||||
- If plan facts change after routing, invalidate both target results and run final routing again before writing files.
|
||||
- Treat non-behavioral review artifact drift and obvious non-behavioral source nits as current-scope evidence; they do not bypass final routing.
|
||||
- Keep the task `unrouted` until split, PLAN body, verification, evidence, ownership, and decisions are complete.
|
||||
- Treat each final in-memory PLAN as its build packet. Derive `large_indivisible_context` and positive loop-risk signatures once from analysis already required to write that PLAN; do not create a separate packet summary or search for negative risk evidence.
|
||||
- Execute `finalize-task-routing` once for build/review and use only its lane/G/filenames. Apply it to first-pass, follow-up, USER_REVIEW replan, and each split subtask independently.
|
||||
- Quarantine previous lane/G/score/rationale. Carry only revalidated code, findings, command output, `review_rework_count`, and `evidence_integrity_failure`.
|
||||
- `needs_evidence` names genuinely missing closure evidence; `blocked` stops file creation. Changed plan facts invalidate the route.
|
||||
- Only `refine-local-plans` may retain an unstarted local pair's route while splitting it into strict-subset local children.
|
||||
|
||||
Directory states:
|
||||
|
||||
|
|
@ -116,7 +115,6 @@ Directory states:
|
|||
|-------|---------|
|
||||
| `PLAN-*-G??.md` only | Invalid; plan skill always writes both active files |
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` stub | Implementation is pending/in progress |
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with filled `사용자 리뷰 요청` | Implementation claims a selected Milestone lock decision blocker; ready for code-review to validate and create `USER_REVIEW.md` only if justified |
|
||||
| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md` without verdict | Ready for code-review skill |
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` with appended verdict | Review finalization is pending. Continue only when code-review invokes `prepare-follow-up`; `write` mode must not overwrite this state. |
|
||||
| `complete.log` + `*.log` files | Task complete (PASS or user-review-resolved PASS), before final task-directory archive move |
|
||||
|
|
@ -185,7 +183,7 @@ Before choosing plan files or task directory names, apply the split decision pol
|
|||
|
||||
## Step 2 - Analyze Before Writing
|
||||
|
||||
Complete all items below before creating active plan/review files. Work through them in order; do not proceed to the next step until every checkbox is done. The only allowed file edits before writing plan/review files are local `agent-roadmap/current.md` creation or `.gitignore` block repair needed for roadmap routing, plus `create-test` or `update-test` edits when the repository already uses agent-test for the relevant scope or the user explicitly asked to maintain test rules.
|
||||
Complete all items below before creating active plan/review files. Work through them in order; do not proceed to the next step until every checkbox is done. Keep the user request as the scope anchor and reconcile derived acceptance conditions before the split decision; do not create a separate routing summary. The only allowed file edits before writing plan/review files are local `agent-roadmap/current.md` creation or `.gitignore` block repair needed for roadmap routing, plus `create-test` or `update-test` edits when the repository already uses agent-test for the relevant scope or the user explicitly asked to maintain test rules.
|
||||
|
||||
- [ ] **Load test environment rules** — because implementation plans include verification, determine `test_env` before choosing verification commands. Use the user-specified environment when provided; otherwise use `local`. Agent-test is optional: some repositories or tasks intentionally do not have or use `agent-test/`. Check `agent-test/<test_env>/rules.md`; read it in full when present, even if it appears blank or skeleton. If it is absent, record that no agent-test rule was applied and choose fallback verification sources from repository manifests, scripts, workflows, domain rules, or direct read-only environment probes. Do not create agent-test files merely because a plan has verification. Invoke `create-test` only when the user asked for test-rule creation/maintenance, the current task is itself test-rule work, or the repository already uses agent-test for this scope and the missing/blank rule is a real maintenance gap. If creation is not appropriate or possible in the current task context, record the gap and fallback source; absence is not a user-review blocker by itself.
|
||||
- [ ] **Read all source files in full** — read every source file the change will touch, whole file. No partial reads.
|
||||
|
|
@ -193,24 +191,24 @@ Complete all items below before creating active plan/review files. Work through
|
|||
- [ ] **Preflight non-local test environments** — when any required verification leaves the current checkout, including remote runner, field/bootstrap, external provider, Docker/code-server, emulator/device, or shared long-running runtime, derive a read-only preflight before writing final verification commands. Use matched `agent-test` rules when they exist and apply; otherwise derive the preflight from repository manifests, scripts, workflows, domain rules, current task evidence, user-provided environment facts, and direct read-only probes. Record runner, repo root/workdir, branch/HEAD/dirty state, source sync status, binary/artifact paths, command help/version output needed by the verification, config path, runtime identity such as Edge id, ports/process state, external hosts, and OS/arch assumptions. If the preflight shows stale artifacts, dirty/divergent checkout, wrong identity, missing command, closed ports, host OS mismatch, or unsynced source, the plan must add an explicit setup/sync/rebuild step or report the blocker; do not write verification commands that silently assume profile or fallback values are already true.
|
||||
- [ ] **Read all test files in full** — read every test file that exercises the changed behavior, including files implied by matched agent-test profiles when any are used and by the repository test layout.
|
||||
- [ ] **Assess test coverage** — for each behavior change, explicitly record whether existing tests cover it.
|
||||
- [ ] **Assess split boundaries 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 subtask directories under one task group instead of one plan.
|
||||
- [ ] **Assess split boundaries once** — reconcile request acceptance with source/tests, then split only where every child has a stable contract and independent PASS verification. Otherwise keep the invariant together; do not gather extra evidence solely to lower routing risk.
|
||||
- [ ] **Capture recovery signals once** — first-pass uses `review_rework_count=0` and `evidence_integrity_failure=false`. In `prepare-follow-up`, reuse the values already validated and appended by code-review; do not recount verdict history. For another isolated replan, derive them once from the same-task state already loaded for planning, without a routing-only log pass.
|
||||
- [ ] **Resolve split predecessor completion** — if the selected or proposed subtask directory has `NN+PP[,QQ...]_...`, resolve each predecessor index under the same task group. Check only the active and archive candidate patterns defined in the task directory naming rules. Record found active/archive paths, missing predecessors, or ambiguous matches in `분석 결과 > 분할 판단` and, when order matters, `의존 관계 및 구현 순서`.
|
||||
- [ ] **Grep all symbol references** — for any renamed or removed symbol, find every call site and import chain.
|
||||
- [ ] **Check dependency manifests** — before adding any new package, verify its presence in go.mod / package manifest.
|
||||
- [ ] **Pre-check compile issues** — identify missing interface implementations, type mismatches, and broken imports.
|
||||
- [ ] **Verify verification commands** — confirm that the final verification commands actually run in this repository layout.
|
||||
- [ ] **Stabilize fragile verification** — for search or generated-output checks, choose deterministic commands up front, such as `rg --sort path`, and decide whether cached test output is acceptable or `-count=1` is required.
|
||||
- [ ] **Derive routing signals once** — treat each completed in-memory PLAN as the worker packet. From facts already collected, record `large_indivisible_context`, positive matched loop-risk names/count, and recovery signals. Do not reread files, prove unmatched signatures false, or aggregate parent/sibling risk for routing.
|
||||
|
||||
## Step 3 - Finalize Task Routing
|
||||
|
||||
This step is mandatory and must be the last semantic decision before routed filenames are fixed. Complete Step 2 and prepare the full plan structure in memory before starting it.
|
||||
|
||||
- [ ] **Build neutral input** — prepare current scope, affected paths, invariants, context size, split result, verification plan, actual evidence, ownership, unresolved decisions, and failure evidence for `build` and `review`. Exclude every previous lane, grade, routing score, rationale, filename, and archive basename that exposes them.
|
||||
- [ ] **Select evaluation mode** — use `first-pass` only when no prior routing exists. Review follow-ups, invalidated routes, and USER_REVIEW replans use `isolated-reassessment` and must pass the neutral input to a fresh evaluation context/sub-invocation that has not seen the previous assessment.
|
||||
- [ ] **Run the routing skill** — read and fully execute `agent-ops/skills/common/finalize-task-routing/SKILL.md` with both targets in the selected mode. Do not reproduce or replace its decision logic inside this skill. If isolated evaluation is unavailable, treat the routing result as `blocked`; do not silently evaluate in the current anchored context.
|
||||
- [ ] **Resolve non-final states** — for `needs_evidence`, collect the named evidence and rerun from `unrouted`; for `blocked`, stop without mutating task files and report the exact release condition. In `prepare-follow-up`, leave the verdict-appended active pair in place so code-review recovery can resume without losing the loop state.
|
||||
- [ ] **Accept only routed output** — require independent `build` and `review` closure records, lane, grade scores, GNN, and canonical filename.
|
||||
- [ ] **Freeze the result** — use those exact basenames in Steps 4-6. If any routing input changes before the files are written, discard both outputs and repeat this step from the beginning.
|
||||
- [ ] **Freeze routing input and mode** — use the completed in-memory PLAN and existing analysis facts. Include closure, grade, `large_indivisible_context`, positive risk names/count, and recovery signals; exclude previous route fields. Use `first-pass` with no prior route, otherwise `isolated-reassessment`. Remove prior route fields in memory; do not create a sub-agent, packet document, or routing-only evidence pass.
|
||||
- [ ] **Run routing once** — fully execute `agent-ops/skills/common/finalize-task-routing/SKILL.md` for build/review. Do not duplicate its decision rules in this skill.
|
||||
- [ ] **Stop or accept** — `needs_evidence` may rerun only after collecting all named new evidence; `blocked` stops without task-file mutation. Accept `routed` only when finalizer identity, closure, base/final basis, signals, grade, lane, and filenames satisfy the routing skill.
|
||||
- [ ] **Freeze routed names** — use the returned basenames unchanged in Steps 4-6. If an input fact changes before write, invalidate both routes and perform this step once again on the changed input.
|
||||
|
||||
## Step 4 - Archive Existing Active Files
|
||||
|
||||
|
|
@ -238,9 +236,8 @@ Header line must be exactly:
|
|||
Required sections:
|
||||
|
||||
- Title.
|
||||
- `이 파일을 읽는 구현 에이전트에게`: warn that filling implementation-owned `CODE_REVIEW-*-G??.md` sections is mandatory. Tell the implementer to run verification, fill actual notes/output, keep active files in place, and report ready for review; finalization is code-review-skill only. Also state that if implementation is blocked by a selected Milestone `구현 잠금 > 결정 필요` item, the implementer must fill the review stub's `사용자 리뷰 요청` section with exact linked evidence and stop for code-review; the implementer must not ask the user directly, present chat choices, call `request_user_input`, create `USER_REVIEW.md`, archive logs, or write `complete.log`. State that environment/secret/service blockers, generic scope changes, and evidence gaps a follow-up agent can close are not user-review requests by themselves.
|
||||
- `이 파일을 읽는 구현 에이전트에게`: warn that filling implementation-owned `CODE_REVIEW-*-G??.md` sections is mandatory. Tell the implementer to run verification, fill actual notes/output, keep active files in place, and report ready for review; finalization is code-review-skill only. If blocked, the implementer records only exact blocker evidence, attempted commands/output, and resume conditions in implementation-owned evidence fields. It must not ask the user, call user-input tools, create control-plane stop files, classify the next state, archive logs, or write `complete.log`.
|
||||
- `배경`: 2-4 sentences explaining why the work is needed.
|
||||
- `사용자 리뷰 요청 흐름`: state that only selected Milestone lock decisions are recorded in the active review stub's `사용자 리뷰 요청` section, copied from `agent-ops/skills/common/_templates/implementation-user-review-request-section.md`; direct user prompts during implementation are forbidden, and code-review owns validation plus the actual `USER_REVIEW.md` file write.
|
||||
- `Archive Evidence Snapshot`: include this section only when the plan resumes from `USER_REVIEW.md`, a prior archived review, or any archive evidence. Omit it for first-pass plans with no archive evidence. The section must contain only the archive facts needed to implement without rereading archive by default: prior task/archive paths, verdict, Required/Suggested/Nit summary, affected files, verification evidence, and any roadmap carryover. If exact prior context is still required, cite the specific archive file paths allowed to read; do not ask the implementer to search `agent-task/archive/**` broadly.
|
||||
- `Roadmap Targets`: include this section only when the plan is intended to complete one or more existing Milestone 기능 Task ids. Omit the section entirely for non-roadmap work or Milestone-adjacent work that should not check a Task on PASS. Format exactly:
|
||||
|
||||
|
|
@ -276,13 +273,13 @@ Required sections:
|
|||
- `테스트 환경 규칙`: state the chosen `test_env`, whether `agent-test/<test_env>/rules.md` was present/read/missing/intentionally unused, every matched profile path read when any, the concrete rules/commands applied, any structural blank/skeleton or missing rules, any `<확인 필요>` values, and any fallback verification source. If any required verification leaves the current checkout, include a `테스트 환경 프리플라이트` record with runner, repo root/workdir, branch/HEAD/dirty state, source sync status, binary/artifact paths, required command help/version output, config path, runtime identity such as Edge id, ports/process state, external hosts, OS/arch assumptions, and the exact setup/sync/rebuild step or blocker derived from mismatches. If agent-test is absent or unusable, explicitly say no agent-test rule was applied, what fallback is used, and whether test-rule maintenance is actually needed or not needed for this task.
|
||||
- `테스트 커버리지 공백`: list each behavior change and whether existing tests cover it; explicitly note gaps.
|
||||
- `심볼 참조`: list renamed/removed symbols and every call site found, or state "none" if no symbols were changed.
|
||||
- `분할 판단`: 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 the shared task group plus each sibling subtask directory and dependency relationship. For dependent subtask plans, include each predecessor index and whether it is satisfied by an active or archived `complete.log`, missing, or ambiguous.
|
||||
- `분할 판단`: for one plan, name the indivisible invariant or compact boundary; for split plans, list each child's stable contract, PASS evidence, and dependency. For dependent subtask plans, include each predecessor index and whether it is satisfied by an active or archived `complete.log`, missing, or ambiguous.
|
||||
- `범위 결정 근거`: state which files or areas were explicitly excluded from this change and why. This is the boundary justification — the implementing agent must not silently expand scope beyond what is recorded here.
|
||||
- `최종 라우팅`: record the `evaluation_mode` plus `build` and `review` closure results, grade scores, lane, GNN, and canonical filename returned by `finalize-task-routing`. Do not include or compare a previous loop's lane/G.
|
||||
- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per implementation/verification unit; if the roadmap feature Task has `검증:`, keep that verification in the same checklist item instead of making a separate completion-criteria item. Include one item for whole-plan intermediate/final verification only when it is not already covered by the feature items, 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.
|
||||
- `최종 라우팅`: record `evaluation_mode`, finalizer, both targets' closure/grade/route, `large_indivisible_context`, positive loop-risk names/count, recovery signals, capability-gap evidence, and canonical filenames. Do not include or compare a previous loop's lane/G.
|
||||
- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per implementation/verification unit; if the roadmap feature Task has `검증:`, keep that verification in the same checklist item instead of making a separate completion-criteria item. Include one item for whole-plan intermediate/final verification only when it is not already covered by the feature items. Make the last item exactly `- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다.` Copy this checklist into the review stub's `구현 체크리스트` section with the same item text and order.
|
||||
- One item per change: `### [TAG-1] Title`, `TAG-2`, etc.
|
||||
- `수정 파일 요약`: table mapping files to item ids.
|
||||
- `최종 검증`: runnable commands and expected outcome. Prefer commands from the matched agent-test env/profile rules. If agent-test is missing, blank, skeleton, or lacks a matching command, use repository manifests/workflows as fallback and record that fallback in `분석 결과 > 테스트 환경 규칙`. Commands must be exact and deterministic enough for the reviewer to rerun; use stable ordering for searches and state whether cached test output is acceptable. The final line of this section must read exactly — **"모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다."**
|
||||
- `최종 검증`: runnable commands and expected outcome. Prefer commands from the matched agent-test env/profile rules. If agent-test is missing, blank, skeleton, or lacks a matching command, use repository manifests/workflows as fallback and record that fallback in `분석 결과 > 테스트 환경 규칙`. Commands must be exact and deterministic enough for the reviewer to rerun; use stable ordering for searches and state whether cached test output is acceptable. End this section with **"모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다."**
|
||||
|
||||
Each plan item must include:
|
||||
|
||||
|
|
@ -337,7 +334,6 @@ Replace every occurrence of each token below:
|
|||
- Scalar tokens: `{date}`, `{task_group}`, `{task_name}`, `{plan_number}`, `{TAG}`, `{build_lane}`, `{build_grade}`, `{review_lane}`, `{review_grade}`, `{plan_log_number}`, `{review_log_number}`.
|
||||
- Plan-copy tokens: `{roadmap_targets_or_omit}`, `{archive_evidence_snapshot_or_omit}`, `{agent_ui_completion_or_omit}`, `{implementation_checklist}`, `{review_checkpoints}`.
|
||||
- Generated row/section tokens: `{implementation_completion_rows}` contains one row for every plan item, and `{verification_result_sections}` contains the fixed verification instructions plus every intermediate/final command from the plan.
|
||||
- `{implementation_user_review_request_section}` is replaced by the full contents of `agent-ops/skills/common/_templates/implementation-user-review-request-section.md`; do not prepend another `사용자 리뷰 요청` heading.
|
||||
|
||||
Use the routed build/review grades independently. Remove optional plan-copy content by replacing its token with an empty string, not by leaving template instructions.
|
||||
In `write` mode, write the rendered stub to the routed review basename. In `prepare-follow-up` mode, return it as `prepared_review` without writing.
|
||||
|
|
@ -358,6 +354,7 @@ Do not write or return a prepared pair when either routing target is not `routed
|
|||
- In `write` mode, `.gitignore` has the Agent-Ops managed block that unignores `agent-task/**/*.md` and `agent-task/**/*.log` and ignores local `agent-roadmap/current.md`. In `prepare-follow-up` mode, the block was only inspected and any needed repair was returned as `gitignore_repair_needed`.
|
||||
- Single-plan work stores active files directly under `agent-task/{task_group}/`.
|
||||
- Split work, if any, uses one shared `agent-task/{task_group}/` parent and one subtask directory per plan/review pair with names like `01_core`, `02+01_edge_integration`, `03+01_node_integration`; dependency details live in the subtask directory name as `NN+PP[,QQ...]_subtask_name`.
|
||||
- Split sibling indices follow topological dependency order: every predecessor is lower than its consumer, and every gap is explained by an unchanged existing predecessor or an occupied active/archive index.
|
||||
- Milestone-linked work uses `agent-task/m-<milestone-slug>/` as the task group; non-roadmap task groups do not start with `m-`.
|
||||
- Both first lines match `<!-- task={task_name} plan={plan_number} tag={TAG} -->`.
|
||||
- The review stub was rendered from `agent-ops/skills/common/plan/templates/review-stub-template.md` after routing and has no unresolved known template token.
|
||||
|
|
@ -371,11 +368,10 @@ Do not write or return a prepared pair when either routing target is not `routed
|
|||
- `분석 결과 > 테스트 환경 규칙` records the selected test env, env rules read/missing/structural-blank/intentionally-unused state, matched profiles read when any, and any fallback verification source.
|
||||
- Dependent split plans record predecessor completion using active sibling `complete.log` or matching archived `complete.log`; ambiguous archive matches are not guessed.
|
||||
- Every plan item has problem, solution, checklist, test decision, and intermediate verification.
|
||||
- The plan and review stub have matching `구현 체크리스트` item text/order, and the final checkbox is the mandatory `CODE_REVIEW-*-G??.md` completion item.
|
||||
- `finalize-task-routing` ran after all analysis for both `build` and `review` in the required evaluation mode; its output status is `routed`, and the active filenames plus `분석 결과 > 최종 라우팅` exactly match its two results.
|
||||
- The plan and review stub have matching `구현 체크리스트` item text/order; their final checkbox is the mandatory `CODE_REVIEW-*-G??.md` evidence item.
|
||||
- `finalize-task-routing` ran once after the PLAN body was complete, used no routing-only evidence pass, counted only positive packet-local risk, kept capability/grade basis from being relabeled by escalation signals, and produced matching filenames.
|
||||
- Review WARN/FAIL follow-ups entered through this plan skill and did not inherit or compare the archived lane/G.
|
||||
- The plan's implementer instructions and review stub both forbid direct user prompts during implementation and explain the implementation-time `사용자 리뷰 요청` stop path.
|
||||
- The review stub includes the `사용자 리뷰 요청` section from `agent-ops/skills/common/_templates/implementation-user-review-request-section.md`.
|
||||
- The plan's implementer instructions and review stub limit local implementation agents to implementation/test/evidence work and keep user-review classification plus control-plane stop files out of their input and ownership.
|
||||
- The review stub has a clearly marked `코드리뷰 전용 체크리스트` owned only by the review agent.
|
||||
- Routed review file completion table lists every plan item.
|
||||
- In `prepare-follow-up`, no repository file was mutated and the returned prepared basenames/bodies, `plan_number`, current archive names/numbers, post-archive log counts, and `gitignore_repair_needed` are complete; in `write`, prior active state was archived with its own parsed route and both new active files were written.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
interface:
|
||||
display_name: "Plan"
|
||||
short_description: "Write implementation plans"
|
||||
default_prompt: "Use $plan to analyze this repository change, run $finalize-task-routing as the final decision, and create the routed PLAN/CODE_REVIEW pair."
|
||||
default_prompt: "Use $plan to analyze this repository change, collect current routing evidence, run $finalize-task-routing with local-first capability-gap policy, and create the routed PLAN/CODE_REVIEW pair."
|
||||
|
|
|
|||
|
|
@ -6,8 +6,8 @@
|
|||
> 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 selected Milestone `구현 잠금 > 결정 필요` item, fill `사용자 리뷰 요청` with linked evidence and stop with active files in place; code-review decides whether to write `USER_REVIEW.md`. Environment/secret/service blockers, generic scope changes, repeated failures, and evidence gaps that a follow-up agent can close 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 only Milestone lock decisions in `사용자 리뷰 요청` and stop for code-review.
|
||||
> If implementation is blocked, record the exact blocker, attempted commands/output, and resume condition only in implementation-owned evidence fields.
|
||||
> Do not ask the user directly, present choices, call user-input tools, create control-plane stop files, or classify the next state.
|
||||
> Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, `코드리뷰 전용 체크리스트`) is review-agent-only, even after compaction/resume.
|
||||
> Follow the ownership table at the bottom of this file for which sections you own.
|
||||
|
||||
|
|
@ -26,9 +26,9 @@ task={task_name}, plan={plan_number}, tag={TAG}
|
|||
각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
|
||||
리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.
|
||||
|
||||
1. 판정을 append한다.
|
||||
1. 판정과 `review_rework_count` / `evidence_integrity_failure` 라우팅 신호를 append한다.
|
||||
2. `CODE_REVIEW-{review_lane}-{review_grade}.md` → `code_review_{review_lane}_{review_grade}_{review_log_number}.log`, `PLAN-{build_lane}-{build_grade}.md` → `plan_{build_lane}_{build_grade}_{plan_log_number}.log`로 아카이브한다.
|
||||
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 user-review gate를 확인한 뒤 plan skill을 실행해 fresh routing된 다음 active pair를 만들거나 `USER_REVIEW.md`를 작성한다. `USER_REVIEW.md`가 연결된 Milestone 결정으로 완료/PASS 해소되면 code-review가 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log` 작성 후 archive 이동한다.
|
||||
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동한다. WARN/FAIL이면 code-review skill이 요구하는 다음 filesystem state를 완전히 작성한다.
|
||||
4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
|
||||
5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
|
||||
|
||||
|
|
@ -51,7 +51,7 @@ task={task_name}, plan={plan_number}, tag={TAG}
|
|||
> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
|
||||
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.
|
||||
|
||||
- [ ] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
|
||||
- [ ] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정과 검증된 `review_rework_count`, `evidence_integrity_failure`를 append한다.
|
||||
- [ ] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
|
||||
- [ ] active `CODE_REVIEW-*-G??.md`를 `code_review_{review_lane}_{review_grade}_{review_log_number}.log`로 아카이브한다.
|
||||
- [ ] active `PLAN-*-G??.md`를 `plan_{build_lane}_{build_grade}_{plan_log_number}.log`로 아카이브한다.
|
||||
|
|
@ -60,9 +60,7 @@ task={task_name}, plan={plan_number}, tag={TAG}
|
|||
- [ ] 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가 트리거되지 않았으면 plan skill을 실행하고 `finalize-task-routing`의 fresh 결과와 일치하는 다음 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가 연결된 Milestone 결정으로 완료/PASS 해소되면 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log`를 작성한 뒤 task directory를 archive로 이동한다.
|
||||
- [ ] WARN/FAIL이면 code-review skill의 판정에 맞는 다음 filesystem state를 작성하고 `complete.log`를 작성하지 않는다.
|
||||
|
||||
## 계획 대비 변경 사항
|
||||
|
||||
|
|
@ -72,8 +70,6 @@ _구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께
|
|||
|
||||
_구현 에이전트가 주요 설계 결정 사항을 기록한다._
|
||||
|
||||
{implementation_user_review_request_section}
|
||||
|
||||
## 리뷰어를 위한 체크포인트
|
||||
|
||||
{review_checkpoints}
|
||||
|
|
@ -84,7 +80,7 @@ _구현 에이전트가 주요 설계 결정 사항을 기록한다._
|
|||
|
||||
---
|
||||
|
||||
> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
|
||||
> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section?**
|
||||
> If anything is blank, go back and fill it in before saving this file.
|
||||
> Leave review-agent-only sections unchanged.
|
||||
|
||||
|
|
@ -97,10 +93,9 @@ _구현 에이전트가 주요 설계 결정 사항을 기록한다._
|
|||
| Archive Evidence Snapshot | Fixed at stub creation from plan when present | Implementing agent uses it as default prior-loop context; read only the specific archive files cited there when more detail is required |
|
||||
| Agent UI Completion | Mixed | Present only for plan-required agent-ui code work; implementing agent fills actual evidence, review agent applies `구현됨` status/evidence update on PASS and copies the section into `complete.log` |
|
||||
| 구현 항목별 완료 여부 (item names) | Fixed at stub creation | Implementing agent checks `[ ]` → `[x]` only |
|
||||
| 구현 체크리스트 (item text/order) | Fixed at stub creation from plan | Implementing agent checks `[ ]` → `[x]` only; final checkbox is mandatory before saving |
|
||||
| 구현 체크리스트 (item text/order) | Fixed at stub creation from plan | Implementing agent checks `[ ]` → `[x]` only |
|
||||
| 코드리뷰 전용 체크리스트 | Review agent only | Implementing agent must not modify or check this section |
|
||||
| 계획 대비 변경 사항, 주요 설계 결정 | Implementing agent | Replace placeholder text with actual content |
|
||||
| 사용자 리뷰 요청 | Implementing agent | Keep `상태: 없음` unless a selected Milestone `구현 잠금 > 결정 필요` item blocks implementation; do not ask the user directly during implementation; environment/secret/service blockers, generic scope changes, and evidence gaps are not user-review requests |
|
||||
| 리뷰어를 위한 체크포인트 | Fixed at stub creation | Pre-filled from plan |
|
||||
| 검증 결과 (section headings + commands) | Fixed at stub creation | Implementing agent fills in command output only; command changes require a `계획 대비 변경 사항` entry |
|
||||
| 코드리뷰 결과 | Review agent appends | Not included in stub |
|
||||
|
|
|
|||
84
agent-ops/skills/common/refine-local-plans/SKILL.md
Normal file
84
agent-ops/skills/common/refine-local-plans/SKILL.md
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
---
|
||||
name: refine-local-plans
|
||||
description: 현재 plan들 세분화해, 현재 plan 세분화, 기존 plan 더 나눠, local plan 분리해 같은 요청에서 이미 생성된 미착수 PLAN-local-G??/CODE_REVIEW pair를 최대 3개의 작은 local sibling pair로 나누고 같은 task group의 미착수 index를 의존성 순서로 함께 정렬할 때 사용한다.
|
||||
---
|
||||
|
||||
# Refine Local Plans
|
||||
|
||||
## 목표
|
||||
|
||||
이미 생성된 미착수 local pair를 로컬 모델이 수행하기 쉬운 응집된 단위로 이번 실행에서 한 단계만 나눈다. Source/test를 다시 조사하거나 검증을 실행하지 않는다.
|
||||
|
||||
## 대상
|
||||
|
||||
- 사용자가 지정한 active task group, task path, 또는 `PLAN-local-G??.md`를 사용한다. 대상을 생략하면 미착수 local pair가 있는 task group이 정확히 하나일 때만 진행한다.
|
||||
- `PLAN-local-G??.md`와 matching `CODE_REVIEW-*-G??.md`가 모두 있고 verdict가 없어야 한다.
|
||||
- Review의 구현 완료표·구현 체크리스트가 모두 미체크이고, 구현 소유 기록과 검증 출력이 아직 채워지지 않은 pair만 미착수로 본다.
|
||||
- `complete.log` 또는 `USER_REVIEW.md`가 있거나 구현이 시작된 pair는 수정하지 않는다.
|
||||
- 대상 pair, 같은 task group의 미착수 active sibling pair, active directory basename과 archived sibling directory basename만 읽는다. Archive 내부 파일은 읽지 않는다. 새 구현 조사를 위해 source/test/roadmap/archive 본문을 읽지 않는다.
|
||||
|
||||
## 절차
|
||||
|
||||
1. **범위를 고정한다**
|
||||
- 기존 PLAN의 checklist, plan item, 수정 파일, 검증 명령을 원본 범위로 고정한다.
|
||||
- Plan에 없는 구현 범위나 검증을 추가하지 않는다.
|
||||
|
||||
2. **유지 또는 분리를 결정한다**
|
||||
- 서로 독립적으로 구현·검증 가능한 behavior slice가 정확히 2개 또는 3개일 때만 나눈다.
|
||||
- 각 child는 하나의 응집된 결과와 필요한 production 변경을 가진다.
|
||||
- Production 변경의 PASS에 필요한 기존 PLAN의 테스트는 같은 child에 둔다. 추가 통합/closure 검증만 별도 test child가 될 수 있다.
|
||||
- 경계가 불명확하거나 공유 write set·상태·순서 때문에 coordination이 커지면 원본을 유지한다.
|
||||
- 원본 유지로 결정하면 파일을 바꾸지 않고 결과만 보고한다.
|
||||
- 이번 실행에서 만든 child를 다시 분할하지 않는다.
|
||||
|
||||
3. **경로와 dependency를 정한다**
|
||||
- 이름은 `NN_{subtask_name}` 또는 `NN+PP[,QQ...]_{subtask_name}`만 사용하며 모든 predecessor는 `NN`보다 작아야 한다.
|
||||
- Target children과 같은 task group의 active sibling으로 DAG를 만든다. 시작·완료 sibling은 고정 anchor로 두고, 나머지는 producer가 consumer보다 먼저 오도록 topological sort한다.
|
||||
- 같은 단계에서는 기존 sibling의 index와 새 child의 원본 PLAN item 순서를 유지하고 basename으로 마지막 tie를 정한다.
|
||||
- 검사 시작 시 구현이 시작됐거나 `complete.log`, `USER_REVIEW.md`, 기존 `*.log`가 있는 sibling의 `NN`은 고정한다. Archived sibling의 `NN`도 예약된 번호로 취급한다.
|
||||
- 나머지 node에는 모든 predecessor보다 크면서 충돌하지 않는 가장 낮은 두 자리 index를 topological 순서대로 배정한다. 고정 predecessor 이하이거나 예약된 번호만 건너뛴다.
|
||||
- Reindex 후 각 basename의 predecessor를 새 index로 치환하고 오름차순으로 기록한다. 독립 node는 `NN_`, dependent node는 `NN+PP[,QQ...]_`를 사용한다.
|
||||
- 기존 dependent의 원래 predecessor를 실제 소비하는 child로 바꾼다. 전체 결과를 필요로 하면 마지막 closure child를 사용하고, 소비 child를 판단할 수 없으면 분리하지 않는다.
|
||||
- 고정 index 때문에 dependency 순서를 만들 수 없거나 cycle, `99` 초과, 시작된 sibling 이동이 필요하면 분리하지 않는다.
|
||||
- 예: 미착수 `01_core`, `03+01_api`, `04+01,03_integration`은 `01_core`, `02+01_api`, `03+01,02_integration`으로 정렬한다. 기존 `03`이 시작된 상태면 `03`은 이동하지 않는다.
|
||||
- Reindex되는 sibling은 directory basename과 PLAN/review 안의 기존 task path·index·dependency 참조를 새 값으로 바꾼다. 구현 scope, checklist, 검증, routing은 바꾸지 않는다.
|
||||
|
||||
4. **현재 PLAN/CODE_REVIEW 형식을 유지한다**
|
||||
- 각 child는 기존 PLAN을 복제한 뒤 자신의 scope만 남긴다. Header/task, title, background, `구현 체크리스트`, plan item, `수정 파일 요약`, `최종 검증`을 child 경계에 맞게 갱신한다. 기존 PLAN에 `분석 결과`가 있으면 읽은 파일·테스트 공백·심볼 참조·분할 판단·범위 결정 근거도 child 범위로 줄인다.
|
||||
- `Roadmap Targets`는 전체 결과를 닫는 closure child 하나에만 둔다. `Agent UI Completion`도 해당 구현과 PASS evidence를 소유하는 child 하나에만 둔다. 소유 child를 정할 수 없으면 분리하지 않는다.
|
||||
- 각 review는 기존 CODE_REVIEW를 복제한 뒤 header/task, 완료표, 구현 checklist, checkpoint, 검증 section을 matching PLAN과 맞춘다. 고정 안내와 review 전용 section의 문구는 유지하되 child task path와 future archive suffix 참조는 갱신한다.
|
||||
- PLAN과 review는 입력에 이미 있는 section 구조를 유지하며 없는 section을 새로 만들지 않는다. 첫 task header 외의 HTML metadata comment는 출력에서 제거한다.
|
||||
- PLAN과 review의 첫 줄은 동일한 `task`, `plan`, `tag`를 사용한다. Checklist 문구·순서와 검증 명령을 서로 일치시킨다.
|
||||
- 기존 build/review lane, G, canonical basename과 `최종 라우팅` 값을 child에 그대로 유지한다. Strict-subset local refinement에서는 `finalize-task-routing`을 다시 실행하지 않는다.
|
||||
|
||||
5. **최종 pair로 직접 교체한다**
|
||||
- 모든 child pair, sibling reindex, directory rename map을 먼저 메모리에서 완성하고 최종 경로·archive log 충돌을 확인한다.
|
||||
- 원본 active review와 PLAN을 각 파일 basename의 lane/G와 다음 monotonic suffix를 사용해 같은 task directory의 `code_review_*.log`, `plan_*.log`로 archive한다.
|
||||
- Reindex가 필요한 미착수 directory는 목적지가 비는 순서로 최종 basename으로 이동한다. 임시 directory나 별도 상태 파일이 필요한 충돌이면 분리하지 않는다.
|
||||
- Indexed target은 첫 child가 최종 basename으로 재사용한다. Task-group root의 single-plan target은 원본 log를 root에 남기고 모든 child directory를 새로 만든다.
|
||||
- 재사용 directory의 `plan` 번호와 future archive suffix는 원본 pair archive 후 log count를 사용한다. 새 child directory는 기존 log가 없으면 `0`을 사용한다.
|
||||
- Child PLAN/CODE_REVIEW를 최종 routed basename에 직접 쓴다. 임시 상태나 복구용 Markdown을 만들지 않는다.
|
||||
- 기존 파일이나 log를 덮어쓰지 않는다. 모든 최종 pair의 header, checklist, 검증 명령과 `predecessor NN < consumer NN`을 확인한다.
|
||||
|
||||
6. **Readiness를 보고한다**
|
||||
- 각 child directory의 encoded predecessor만 확인한다.
|
||||
- 모두 충족되면 `implementation-ready`, 하나라도 미충족이면 `dependency-waiting`으로 보고한다.
|
||||
- Worker, Review, 다음 sibling을 시작하지 않는다.
|
||||
|
||||
## 출력
|
||||
|
||||
```text
|
||||
Local plan refinement
|
||||
- targets: <원본 PLAN 경로>
|
||||
- decisions: <유지 | 원본 -> child 목록>
|
||||
- dependency updates: <변경 내용 또는 없음>
|
||||
- readiness: <pair path = implementation-ready | dependency-waiting>
|
||||
- document check: passed
|
||||
```
|
||||
|
||||
## 금지
|
||||
|
||||
- Source/test 재분석, compile, build, test, lint, formatter, smoke/E2E, live/remote 검증을 실행하지 않는다.
|
||||
- Package 설치, dependency 다운로드, cache warming을 하지 않는다.
|
||||
- Child 재귀 분리, cloud pair 분리, 다른 task group 또는 시작·완료 sibling 재인덱싱을 하지 않는다.
|
||||
- 별도 상태 파일, 임시 pair, repository 밖 복구 파일을 만들지 않는다.
|
||||
|
|
@ -37,6 +37,7 @@
|
|||
| roadmap dependency 확인, locks.yaml 판별, 외부 의존 잠금 확인, unlock-ready 판별, 잠금 해제 조건 충족 여부 확인, roadmap-dependency-checker.sh | `agent-ops/skills/common/check-roadmap-dependency/SKILL.md` |
|
||||
| 지금 작업이 뭐지?, 현재 작업 분석, 어디까지 했지?, 로드맵상 현 위치, 현재 마일스톤 위치, current 기준 breadcrumb | `agent-ops/skills/common/analyze-roadmap-position/SKILL.md` |
|
||||
| 계획 세워줘, 계획 작성해, 계획 만들어줘, 구현 계획, PLAN.md, plan, plan 작성해, plan 만들어줘 | `agent-ops/skills/common/plan/SKILL.md` |
|
||||
| 현재 plan들 세분화해, 현재 plan 세분화, 기존 plan 더 나눠, local plan 분리해 | `agent-ops/skills/common/refine-local-plans/SKILL.md` |
|
||||
| 최종 라우팅, task routing, cloud/local 재평가, lane/G 판단, G 등급 재평가, routed filename 결정 | `agent-ops/skills/common/finalize-task-routing/SKILL.md` |
|
||||
| 코드 리뷰해줘, 리뷰 진행해, 리뷰해줘, code review, CODE_REVIEW.md, 리뷰 루프 | `agent-ops/skills/common/code-review/SKILL.md` |
|
||||
| 커밋해줘, 푸시해줘, commit, push, 반영해줘 | `agent-ops/skills/common/commit-push/SKILL.md` |
|
||||
|
|
@ -46,6 +47,7 @@
|
|||
|
||||
라우팅 우선순위:
|
||||
|
||||
- PLAN/CODE_REVIEW 작성 또는 재작성이 요청 범위에 포함되면 `plan`을 선택한다. `plan`이 최종 단계에서 `finalize-task-routing`을 필수 호출한다.
|
||||
- 이미 생성된 미착수 local pair의 분할만 요청하면 `refine-local-plans`를 선택한다. 새 plan 작성이나 구현 범위 재분석이 포함되면 `plan`을 선택한다.
|
||||
- `refine-local-plans` 대상이 아닌 PLAN/CODE_REVIEW 작성 또는 재작성이 요청 범위에 포함되면 `plan`을 선택한다. `plan`이 최종 단계에서 `finalize-task-routing`을 필수 호출한다.
|
||||
- lane/G/canonical filename 판단만 요청되고 plan 문서 작성은 요청되지 않았을 때만 `finalize-task-routing`을 직접 선택한다.
|
||||
- 코드 리뷰 요청은 `code-review`를 선택한다. WARN/FAIL follow-up은 `code-review -> plan -> finalize-task-routing` 순서를 유지한다.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
name: update-roadmap
|
||||
version: 1.24.0
|
||||
version: 1.24.2
|
||||
description: 로드맵 업데이트, 로드맵에 추가, 마일스톤 추가/갱신, phase/페이즈 변경, 전역 Milestone 실행 순서 갱신 요청에 사용한다. Roadmap-priority-queue-Phase-Milestone scaffold에서 target 없는 신규 작업의 규모를 판정하고 기존 Phase/Milestone/Epic/Task를 검색해 upsert한 뒤, 없을 때만 새 항목을 만들고 priority-queue.md 순서 동기화, 로컬 current.md 동기화, runtime m-task 완료 이벤트 반영, 완료 후보 검토중 전환, agent-ui 코드 동기화 Milestone의 종료 검토 시 구현됨 상태 반영, 완료 근거 충족 archive 이동, workspace 외부 의존 잠금 양방향 동기화를 처리한다.
|
||||
---
|
||||
|
||||
|
|
@ -119,6 +119,9 @@ agent-roadmap/
|
|||
- `ROADMAP.md`의 Phase 흐름은 실행 순서가 아니라 도메인/책임 영역의 구조적 지도다. 상태 그룹은 완료, 검토중, 진행중, 계획, 스케치 순서를 기본으로 하되 실제 다음 작업 선택은 `priority-queue.md`를 우선한다.
|
||||
- `PHASE.md`의 Milestone 흐름은 해당 Phase 안의 상태 정리 흐름이다. Phase를 가로지르는 실행 순서로 해석하지 않는다.
|
||||
- Epic heading은 `### Epic: [epic-id] <이름>` 형식으로 작성한다.
|
||||
- 새 Epic과 기능 Task를 추가하거나 구조를 갱신하는 기존 Epic에는 기능 Task를 최대 5개만 둔다. 갱신 범위 밖 기존 Epic은 자동으로 재구성하지 않는다.
|
||||
- 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 기존 Epic을 둘 이상으로 분리한다. 분리 후에도 독립 목표가 남으면 새 Milestone 후보로 둔다.
|
||||
- 갱신 범위에 포함된 기존 Epic이 이미 6개 이상이면 같은 기준으로 분리한다. 이때 기존 item-id는 사용자가 명시하지 않는 한 바꾸지 않는다.
|
||||
- Task는 `- [ ] [item-id] 설명` 또는 `- [x] [item-id] 설명` 형식으로 작성한다.
|
||||
- epic-id와 item-id는 공백 없는 짧은 ASCII 토큰이며, 해당 Milestone 안에서만 유일하면 된다.
|
||||
- 사용자가 epic-id 또는 item-id를 언급하면 해당 항목을 우선 anchor로 삼고, 기존 id는 명시적 요청 없이 바꾸지 않는다.
|
||||
|
|
@ -258,6 +261,7 @@ agent-roadmap/
|
|||
- 요청이 방향성, 문제의식, 컨셉, 운영 원칙 수준이고 기능 Task나 실행 범위가 아직 부족하면 새 항목의 상태는 `[스케치]`로 둔다.
|
||||
- `[스케치]` Phase/Milestone을 만들 때는 `승격 조건`에 `[계획]`으로 전환하기 위해 필요한 정의, 결정, 경계, 후속 구현 Milestone 후보를 체크리스트로 남긴다.
|
||||
- 가장 작은 충분한 단위 원칙을 따른다. 애매하면 새 Phase나 새 Milestone으로 키우지 말고, 기존 Milestone의 Epic/Task에 넣을 수 있는지 먼저 확인한다.
|
||||
- 기존 Epic에 기능 Task가 5개 있으면 새 Task를 추가하지 않는다. 여섯 번째 Task는 capability, 산출물, 의존성, 검증 경계 중 하나로 분리한 새 Epic에 배치하고, 분리된 Epic이 독립 목표면 새 Milestone 후보로 재판정한다.
|
||||
- 위치 지정이 있으면 anchor의 레벨을 먼저 확인한다.
|
||||
- `<epic-id> 아래`는 해당 Epic 아래 Task로 넣는다.
|
||||
- `<item-id> 앞/뒤`는 같은 Epic 안의 형제 Task로 넣는다.
|
||||
|
|
@ -389,7 +393,9 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
|
|||
- 새 Milestone은 해당 Phase의 `milestones/` 아래에 만든다.
|
||||
- 새 `[스케치]` Milestone은 `승격 조건` 섹션을 포함하고 `구현 잠금`은 `잠금`으로 둔다.
|
||||
- 새 Epic은 `기능` 아래 `### Epic: [epic-id] <이름>`으로 만든다.
|
||||
- 새 Task는 관련 Epic 아래 `- [ ] [item-id] 설명`으로 만든다. 검증이 필요한 경우에만 같은 항목에 `검증: <명령/확인 방법/기대 결과>`를 붙인다.
|
||||
- 새 Task는 관련 Epic의 기능 Task가 5개 미만일 때만 `- [ ] [item-id] 설명`으로 만든다. 검증이 필요한 경우에만 같은 항목에 `검증: <명령/확인 방법/기대 결과>`를 붙인다.
|
||||
- 관련 Epic에 여섯 번째 Task가 필요하면 capability, 산출물, 의존성, 검증 경계 중 하나로 Epic을 분리한 뒤 새 Task를 배치한다. 분리된 Epic이 독립 목표면 새 Milestone 후보로 재판정한다.
|
||||
- 갱신 범위에 포함된 기존 Epic이 6개 이상이면 새 Task를 쓰기 전에 같은 기준으로 Epic을 분리한다. 기존 item-id는 사용자가 명시하지 않는 한 유지한다.
|
||||
- 새 항목은 레벨별 탐색에서 적절한 기존 후보가 없을 때만 만든다.
|
||||
- 완료 체크는 evidence가 있을 때만 `[x]`로 바꾼다.
|
||||
- 모든 기능 Task와 Task 안에 명시된 검증이 evidence와 함께 `[x]`이어도 `구현 잠금`이 `해제`가 아니거나 미완료 `결정 필요` 항목이 있으면 Milestone 상태를 `[검토중]`으로 바꾸지 않는다. `완료 리뷰` 또는 `작업 컨텍스트`에 잠금 차단 항목을 남긴다.
|
||||
|
|
@ -432,7 +438,7 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다
|
|||
- `agent-ui 상태 반영: 대기`가 아닌 Milestone 완료 리뷰에서 agent-ui 문서 status를 변경하지 않았는지 확인한다.
|
||||
- 각 Milestone의 `구현 잠금`에 SDD 필요 여부와 사유가 있는지 확인한다.
|
||||
- `SDD: 필요` Milestone은 SDD 문서 링크, SDD 파일 존재, 잠금 해제 조건, SDD 사용자 리뷰 상태가 일관되는지 확인한다. 사용자가 명시적으로 SDD 생성을 뒤로 미루지 않았는데 SDD 파일이 없으면 검증 실패로 본다.
|
||||
- Epic heading과 Task id 형식이 맞는지 확인한다.
|
||||
- Epic heading과 Task id 형식이 맞고, 새 Epic과 갱신 범위에 포함된 기존 Epic의 기능 Task 수가 최대 5개인지 확인한다. 6개 이상이면 검증 실패로 보고하고 Epic 분리를 요구한다.
|
||||
- 요청 규모가 판정되었고 결과 보고에 남았는지 확인한다.
|
||||
- 동일/유사 기존 항목을 검색했고 신규/업데이트 판정이 결과 보고에 남았는지 확인한다.
|
||||
- 자동 배치한 신규 작업이면 선택한 후보와 밀린 후보의 근거가 결과 보고에 포함되는지 확인한다.
|
||||
|
|
|
|||
Loading…
Reference in a new issue