docs(agent-ops): 마일스톤과 설정 UI 기준을 갱신한다

This commit is contained in:
toki 2026-08-03 07:50:57 +09:00
parent eba60a3db7
commit 8d442212ec
14 changed files with 274 additions and 39 deletions

View file

@ -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 선행 의존성 충족 여부를 확인하는 경우, plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive 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를 충돌 없이 할당하는 경우, `sync-milestone-workstate`가 활성 대상 Milestone의 동일 `m-<milestone-slug>` task group evidence를 집계하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인과 Milestone workstate 동기화는 같은 task group의 후보 `complete.log`와 직접 연결된 plan/review log만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive log를 탐색하지 않는다.
- `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 문서만 읽는다.
@ -34,7 +34,7 @@
**아래 경우에 부합되는지 반드시 끝까지 정독해서 읽고, 부합할 경우 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다.** 자동으로 수행하지 않는다. **절대 스킵하지 말고 정독해야한다**
- agent-ops 초기화
- domain rule 생성
- skill 생성
- skill 생성/갱신
- agent-ui 생성/갱신/검증/코드 동기화, UI 스캐폴드, 화면 정의서, view/component/frame/wireframe 정의, agent-ui USER_REVIEW
- 테스트 룰 작성/생성/수정, 도메인별/검증 시나리오별 테스트 문서, create-test/update-test
- 계약 생성/업데이트, agent-contract 생성/갱신, inner/outer 계약 문서 작성/정리, 계약 포인터 관리
@ -44,6 +44,7 @@
- 로드맵/마일스톤 생성·갱신
- SDD 작성/갱신, SDD 필요 여부, SDD gate 확인, SDD 사용자 리뷰, SDD 잠금 해제
- 로드맵 현지점 / 현재 작업 지점 확인
- 현재 또는 지정 마일스톤 시작 전 정합성 체크 / 전체 프로젝트 작업현황과 마일스톤 정합성 확인 / plan 전 마일스톤 리프레시
- 마일스톤 완료 검토 / 종료 검토 / 현재 마일스톤 닫기 / 다음 마일스톤 지정
- 계획 작성 / plan 생성
- 코드 리뷰 / review 진행

View file

@ -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 선행 의존성 충족 여부를 확인하는 경우, plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인은 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive 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를 충돌 없이 할당하는 경우, `sync-milestone-workstate`가 활성 대상 Milestone의 동일 `m-<milestone-slug>` task group evidence를 집계하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인과 Milestone workstate 동기화는 같은 task group의 후보 `complete.log`와 직접 연결된 plan/review log만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive log를 탐색하지 않는다.
- `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 문서만 읽는다.
@ -34,7 +34,7 @@
**아래 경우에 부합되는지 반드시 끝까지 정독해서 읽고, 부합할 경우 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다.** 자동으로 수행하지 않는다. **절대 스킵하지 말고 정독해야한다**
- agent-ops 초기화
- domain rule 생성
- skill 생성
- skill 생성/갱신
- agent-ui 생성/갱신/검증/코드 동기화, UI 스캐폴드, 화면 정의서, view/component/frame/wireframe 정의, agent-ui USER_REVIEW
- 테스트 룰 작성/생성/수정, 도메인별/검증 시나리오별 테스트 문서, create-test/update-test
- 계약 생성/업데이트, agent-contract 생성/갱신, inner/outer 계약 문서 작성/정리, 계약 포인터 관리
@ -44,6 +44,7 @@
- 로드맵/마일스톤 생성·갱신
- SDD 작성/갱신, SDD 필요 여부, SDD gate 확인, SDD 사용자 리뷰, SDD 잠금 해제
- 로드맵 현지점 / 현재 작업 지점 확인
- 현재 또는 지정 마일스톤 시작 전 정합성 체크 / 전체 프로젝트 작업현황과 마일스톤 정합성 확인 / plan 전 마일스톤 리프레시
- 마일스톤 완료 검토 / 종료 검토 / 현재 마일스톤 닫기 / 다음 마일스톤 지정
- 계획 작성 / plan 생성
- 코드 리뷰 / review 진행

View file

@ -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 선행 의존성 충족 여부를 확인하는 경우, plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive 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를 충돌 없이 할당하는 경우, `sync-milestone-workstate`가 활성 대상 Milestone의 동일 `m-<milestone-slug>` task group evidence를 집계하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인과 Milestone workstate 동기화는 같은 task group의 후보 `complete.log`와 직접 연결된 plan/review log만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive log를 탐색하지 않는다.
- `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 문서만 읽는다.
@ -34,7 +34,7 @@
**아래 경우에 부합되는지 반드시 끝까지 정독해서 읽고, 부합할 경우 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다.** 자동으로 수행하지 않는다. **절대 스킵하지 말고 정독해야한다**
- agent-ops 초기화
- domain rule 생성
- skill 생성
- skill 생성/갱신
- agent-ui 생성/갱신/검증/코드 동기화, UI 스캐폴드, 화면 정의서, view/component/frame/wireframe 정의, agent-ui USER_REVIEW
- 테스트 룰 작성/생성/수정, 도메인별/검증 시나리오별 테스트 문서, create-test/update-test
- 계약 생성/업데이트, agent-contract 생성/갱신, inner/outer 계약 문서 작성/정리, 계약 포인터 관리
@ -44,6 +44,7 @@
- 로드맵/마일스톤 생성·갱신
- SDD 작성/갱신, SDD 필요 여부, SDD gate 확인, SDD 사용자 리뷰, SDD 잠금 해제
- 로드맵 현지점 / 현재 작업 지점 확인
- 현재 또는 지정 마일스톤 시작 전 정합성 체크 / 전체 프로젝트 작업현황과 마일스톤 정합성 확인 / plan 전 마일스톤 리프레시
- 마일스톤 완료 검토 / 종료 검토 / 현재 마일스톤 닫기 / 다음 마일스톤 지정
- 계획 작성 / plan 생성
- 코드 리뷰 / review 진행

View file

@ -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 선행 의존성 충족 여부를 확인하는 경우, plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive 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를 충돌 없이 할당하는 경우, `sync-milestone-workstate`가 활성 대상 Milestone의 동일 `m-<milestone-slug>` task group evidence를 집계하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인과 Milestone workstate 동기화는 같은 task group의 후보 `complete.log`와 직접 연결된 plan/review log만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive log를 탐색하지 않는다.
- `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 문서만 읽는다.
@ -34,7 +34,7 @@
**아래 경우에 부합되는지 반드시 끝까지 정독해서 읽고, 부합할 경우 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다.** 자동으로 수행하지 않는다. **절대 스킵하지 말고 정독해야한다**
- agent-ops 초기화
- domain rule 생성
- skill 생성
- skill 생성/갱신
- agent-ui 생성/갱신/검증/코드 동기화, UI 스캐폴드, 화면 정의서, view/component/frame/wireframe 정의, agent-ui USER_REVIEW
- 테스트 룰 작성/생성/수정, 도메인별/검증 시나리오별 테스트 문서, create-test/update-test
- 계약 생성/업데이트, agent-contract 생성/갱신, inner/outer 계약 문서 작성/정리, 계약 포인터 관리
@ -44,6 +44,7 @@
- 로드맵/마일스톤 생성·갱신
- SDD 작성/갱신, SDD 필요 여부, SDD gate 확인, SDD 사용자 리뷰, SDD 잠금 해제
- 로드맵 현지점 / 현재 작업 지점 확인
- 현재 또는 지정 마일스톤 시작 전 정합성 체크 / 전체 프로젝트 작업현황과 마일스톤 정합성 확인 / plan 전 마일스톤 리프레시
- 마일스톤 완료 검토 / 종료 검토 / 현재 마일스톤 닫기 / 다음 마일스톤 지정
- 계획 작성 / plan 생성
- 코드 리뷰 / review 진행

View file

@ -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 선행 의존성 충족 여부를 확인하는 경우, plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive 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를 충돌 없이 할당하는 경우, `sync-milestone-workstate`가 활성 대상 Milestone의 동일 `m-<milestone-slug>` task group evidence를 집계하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인과 Milestone workstate 동기화는 같은 task group의 후보 `complete.log`와 직접 연결된 plan/review log만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive log를 탐색하지 않는다.
- `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 문서만 읽는다.
@ -34,7 +34,7 @@
**아래 경우에 부합되는지 반드시 끝까지 정독해서 읽고, 부합할 경우 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다.** 자동으로 수행하지 않는다. **절대 스킵하지 말고 정독해야한다**
- agent-ops 초기화
- domain rule 생성
- skill 생성
- skill 생성/갱신
- agent-ui 생성/갱신/검증/코드 동기화, UI 스캐폴드, 화면 정의서, view/component/frame/wireframe 정의, agent-ui USER_REVIEW
- 테스트 룰 작성/생성/수정, 도메인별/검증 시나리오별 테스트 문서, create-test/update-test
- 계약 생성/업데이트, agent-contract 생성/갱신, inner/outer 계약 문서 작성/정리, 계약 포인터 관리
@ -44,6 +44,7 @@
- 로드맵/마일스톤 생성·갱신
- SDD 작성/갱신, SDD 필요 여부, SDD gate 확인, SDD 사용자 리뷰, SDD 잠금 해제
- 로드맵 현지점 / 현재 작업 지점 확인
- 현재 또는 지정 마일스톤 시작 전 정합성 체크 / 전체 프로젝트 작업현황과 마일스톤 정합성 확인 / plan 전 마일스톤 리프레시
- 마일스톤 완료 검토 / 종료 검토 / 현재 마일스톤 닫기 / 다음 마일스톤 지정
- 계획 작성 / plan 생성
- 코드 리뷰 / review 진행

View file

@ -166,6 +166,14 @@
- 다른 Milestone에서는 같은 id를 다시 사용할 수 있다. 여러 Milestone 후보에서 같은 id가 발견되면 Milestone 이름이나 문서 경로로 대상을 확정한다.
- 사용자가 epic-id 또는 item-id를 언급하면 해당 Milestone의 Epic/Task 항목을 우선 anchor로 삼고, 기존 id는 명시적 요청 없이 바꾸지 않는다.
## Milestone 시작 전 정합성
- 사용자가 현재 또는 지정 Milestone의 시작, 정합성 체크, Plan 전 리프레시를 요청하면 `sync-milestone-workstate mode=consistency-check`로 Plan 전에 read-only preflight를 수행한다.
- preflight는 전체 활성 Phase/Milestone, `current.md`, `priority-queue.md`, workspace lock과 active agent-task를 얕게 확인하고 대상 Milestone의 목표·범위·기능·SDD·spec·contract를 현재 코드·config·proto·테스트와 깊게 대조한다. unrelated archive와 전체 코드를 무차별 탐색하지 않는다.
- 아직 구현되지 않은 미래 capability는 정상 planned delta다. 현재 owner/API/wire/config/공통 기반과 충돌하거나 이미 대체·구현된 경우만 drift로 판정한다.
- 결과는 `ready`, `refresh-required`, `blocked` 중 하나다. `refresh-required`이면 미반영 완료 Task에 대한 `sync-milestone-workstate mode=sync`와 필요한 `update-roadmap`/`roadmap-sdd`/`update-spec`/`update-contract` 갱신 후 `consistency-check`를 다시 실행하고, `blocked`이면 차단을 해소하기 전 Plan을 만들지 않는다.
- `consistency-check`는 어떤 파일도 수정하지 않는다. 완료 evidence 반영 후보만 보는 `check-only`와 의미를 합치지 않는다.
## Milestone 기반 agent-task
- `plan` 스킬이 활성 Milestone 범위의 구현 계획을 만들면 task group은 `agent-task/m-<milestone-slug>/` 형식을 사용한다.

View file

@ -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 선행 의존성 충족 여부를 확인하는 경우, plan 스킬이 같은 task group의 새 index를 충돌 없이 할당하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인 같은 task group의 후보 `complete.log`만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive 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를 충돌 없이 할당하는 경우, `sync-milestone-workstate`가 활성 대상 Milestone의 동일 `m-<milestone-slug>` task group evidence를 집계하는 경우, 또는 `sync-agent-ui mode=reconcile-completion`에 exact `completion-log` 경로가 전달된 경우에만 필요한 범위를 좁게 읽는다. split 의존성 확인과 Milestone workstate 동기화는 같은 task group의 후보 `complete.log`와 직접 연결된 plan/review log만 읽을 수 있다. index 할당은 같은 task group의 archived sibling directory basename만 열람하고 내부 파일은 읽지 않는다. UI 완료 정합화는 전달된 exact `complete.log` 한 건만 읽고 sibling archive log를 탐색하지 않는다.
- `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 문서만 읽는다.
@ -34,7 +34,7 @@
**아래 경우에 부합되는지 반드시 끝까지 정독해서 읽고, 부합할 경우 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다.** 자동으로 수행하지 않는다. **절대 스킵하지 말고 정독해야한다**
- agent-ops 초기화
- domain rule 생성
- skill 생성
- skill 생성/갱신
- agent-ui 생성/갱신/검증/코드 동기화, UI 스캐폴드, 화면 정의서, view/component/frame/wireframe 정의, agent-ui USER_REVIEW
- 테스트 룰 작성/생성/수정, 도메인별/검증 시나리오별 테스트 문서, create-test/update-test
- 계약 생성/업데이트, agent-contract 생성/갱신, inner/outer 계약 문서 작성/정리, 계약 포인터 관리
@ -44,6 +44,7 @@
- 로드맵/마일스톤 생성·갱신
- SDD 작성/갱신, SDD 필요 여부, SDD gate 확인, SDD 사용자 리뷰, SDD 잠금 해제
- 로드맵 현지점 / 현재 작업 지점 확인
- 현재 또는 지정 마일스톤 시작 전 정합성 체크 / 전체 프로젝트 작업현황과 마일스톤 정합성 확인 / plan 전 마일스톤 리프레시
- 마일스톤 완료 검토 / 종료 검토 / 현재 마일스톤 닫기 / 다음 마일스톤 지정
- 계획 작성 / plan 생성
- 코드 리뷰 / review 진행

View file

@ -100,6 +100,8 @@
## 스킬 라우팅
- 설정 UI 노출 정책 기록, `설정 UI에서 빼`, `설정 화면에서 숨겨`, `설정 제외로 기록해`, `설정 노출 정책에 추가해`: `agent-ops/skills/common/update-agent-ui/SKILL.md``view-id=settings`, `mode=definition`, `status=계획`, `post-validate=true`, `post-sync=false`로 사용해 `agent-ui/definition/views/settings/index.md`의 설정 노출 정책을 설정 경로 기준으로 upsert한다.
- `설정으로 빼`는 현재 문맥이 UI 노출 제외이고 대상 설정이 식별될 때만 위 라우팅을 사용한다. config 추출·스키마 삭제와 구분되지 않으면 자동 기록하지 않고 확인 대상으로 남긴다.
- UI 없는 사용자 CRUD, OpenAI-compatible 사용자/principal 추가·조회·수정·비활성화·삭제, principal token 운영 CRUD: `agent-ops/skills/project/iop-user-crud-ops/SKILL.md`
- Confluence 문서 작성, 컨플 문서 생성·갱신·검토, Lab2 문서 작성, lgucorp 위키 업데이트: `agent-ops/skills/project/lgucorp-confluence-docs/SKILL.md`
- OpenAI-compatible 사용자 token 발급·추가, dev-corp 사용자 추가와 token 발급, principal_ref token 등록, principal alias 매핑, raw IOP token 1회 전달: `agent-ops/skills/project/openai-usage-token-issue/SKILL.md`

View file

@ -12,6 +12,8 @@
- SDD 생성/갱신/잠금 해제는 `roadmap-sdd` 또는 `update-roadmap` 요청으로 처리한다.
- 런타임이 새 형식의 `origin-task`/`complete-log` 완료 이벤트를 전달하고 첫 줄에 `milestone-task`가 있으면 `sync-milestone-workstate`로 처리해 같은 Milestone task group의 evidence를 집계한다. first-line metadata가 없고 legacy `Roadmap Completion`만 있는 과거 단건 이벤트는 `update-roadmap` 호환 흐름으로 처리할 수 있다.
- active/archive `complete.log`, 관련 파일, git history를 종합해 Milestone 작업 상태를 복구하거나 확인하는 요청은 `sync-milestone-workstate`로 처리한다.
- 현재 또는 지정 Milestone의 시작 전 정합성 체크, 전체 프로젝트 작업현황과 Milestone의 현재 코드·spec·contract drift 확인, Plan 전 리프레시 필요성 판정은 `sync-milestone-workstate mode=consistency-check`로 처리한다. 이 모드는 read-only이며 기존 완료 evidence용 `check-only`와 구분한다.
- "정합성 체크해", "확인해"는 `consistency-check` 보고에서 멈춘다. "정합성 맞춰줘", "리프레시해", "검사하고 반영해"는 `consistency-check` 결과를 먼저 만든 뒤 미반영 완료 Task는 `sync-milestone-workstate mode=sync`, Milestone/queue/lock은 `update-roadmap`, SDD는 `roadmap-sdd`, living spec은 `update-spec`, contract는 `update-contract`로 넘긴다. 갱신 뒤 `consistency-check`를 다시 실행해 `ready`를 확인한 경우에만 연결된 `plan` 요청을 계속한다.
- plan 요청에 사용할 테스트 환경 규칙이 있으면 `update-test mode=resolve-context`로 read-only `Verification Context`를 만든 뒤 `plan`에 전달한다. 규칙이 없거나 매칭되지 않으면 파일을 생성하지 않고 plan의 repository-native fallback을 사용한다.
- `sync-agent-ui``plan-required`로 라우팅한 작업은 plan pair 생성 뒤 `sync-agent-ui mode=prepare-code-work`로 task/UI 매핑을 기록한다. 일반 code-review PASS와 exact `complete.log` 생성 뒤에는 원래 `task-path``completion-log``sync-agent-ui mode=reconcile-completion`에 전달해 해당 매핑만 정합화한다.
- pending UI task가 WARN/FAIL follow-up plan으로 교체되면 새 pair 생성 뒤 `prepare-code-work`를 다시 실행한다. 매핑 범위가 실제로 달라진 경우에만 검증 후 state helper의 `--replace`를 사용한다.
@ -37,6 +39,7 @@
| README 작성해줘, README 만들어줘, 프로젝트 설명 문서 만들어줘 | `agent-ops/skills/common/create-readme/SKILL.md` |
| 핸즈오프 남겨, handoff 작성, 인수인계 작성, 다른 세션에서 이어가게 정리, 작업을 이어받도록 기록 | `agent-ops/skills/common/create-handoff/SKILL.md` |
| 로드맵 만들어줘, roadmap 생성, 마일스톤 설계, goal/phase 구조 잡아줘 | `agent-ops/skills/common/create-roadmap/SKILL.md` |
| 현재 마일스톤 정합성 체크해, 특정 마일스톤 정합성 체크해, 마일스톤 시작 전 정합성 확인, plan 전 마일스톤 리프레시, 전체 프로젝트 작업현황과 마일스톤 정합성 확인 | `agent-ops/skills/common/sync-milestone-workstate/SKILL.md` |
| 현 마일스톤과 작업현황 동기화, 현재 마일스톤 작업현황 동기화, 마일스톤 작업현황 동기화, 마일스톤 완료내역 동기화, agent-task 완료를 마일스톤에 반영, complete.log 후보 스캔, milestone-task id별 evidence 집계, 누락된 Roadmap Completion 복구, 파일/git 기준 작업 상태 확인, 작은 작업 완료 반영, 마일스톤 체크박스 재동기화, 로드맵 작업 완료 상태 동기화 | `agent-ops/skills/common/sync-milestone-workstate/SKILL.md` |
| 마일스톤 완료해도 될지 검토해봐, 현 마일스톤 종료 검토, 현재 마일스톤 닫고 다음 마일스톤 지정, 마일스톤 종료해, 마일스톤 완료 검토, 종료 검토 | `agent-ops/skills/common/complete-milestone/SKILL.md` |
| 로드맵 업데이트, roadmap 갱신, 로드맵에 추가, 로드맵 작업 추가, 로드맵 기능 추가, 로드맵 Epic 추가, 로드맵 에픽 추가, 로드맵 Task 추가, 로드맵 태스크 추가, 로드맵 테스크 추가, 로드맵 TODO 추가, 마일스톤에 추가, 마일스톤 추가, 마일스톤 갱신, 마일스톤 아카이브, phase 추가, phase 변경, 페이즈 추가, 페이즈 변경, 현재 마일스톤 변경, 로드맵 한국어 전환, 로드맵 번역 | `agent-ops/skills/common/update-roadmap/SKILL.md` |

View file

@ -1,13 +1,18 @@
---
name: sync-milestone-workstate
description: 현 마일스톤과 작업현황 동기화, 현재 마일스톤 작업현황 동기화, 마일스톤 완료내역 동기화, agent-task 완료를 마일스톤에 반영, complete.log의 milestone-task id별 증거 집계, active/archive 완료 로그 스캔, legacy Roadmap Completion 복구, 파일/git 기준 작업 상태 확인, 마일스톤 체크박스 재동기화 요청에서 Milestone Task와 상태를 실제 evidence에 맞추는 절차
description: 현재 또는 지정 Milestone을 시작하기 전 전체 활성 workstate와 대상의 코드·SDD·spec·contract 정합성을 검사해 Plan 준비 상태를 판정하거나, 진행·종료 시 complete.log·파일·git evidence를 Task별로 집계해 상태를 동기화하는 절차. "현재 마일스톤 정합성 체크해", "특정 마일스톤 정합성 체크해", Plan 전 리프레시, 완료내역 반영, 체크박스 재동기화 요청에서 사용한다.
---
# sync-milestone-workstate
## 목적
현재 또는 지정 Milestone의 기능 Task 상태를 실제 작업 evidence와 동기화한다. 새 작업을 배치하거나 구현 계획을 수정하지 않는다.
현재 또는 지정 Milestone의 시작 전 정합성과 진행·종료 workstate를 실제 repository evidence에 맞춘다.
- 시작 전 `consistency-check`는 프로젝트 전체 활성 작업현황을 얕게 확인하고 대상 Milestone의 목표·범위·기능·SDD·spec·contract 가정을 현재 코드와 깊게 대조해 Plan 준비 상태를 판정한다.
- 진행·종료의 `check-only``sync`는 같은 Milestone task group의 완료 evidence를 현재 기능 Task 계약에 집계한다.
`consistency-check``check-only`는 read-only다. 이 스킬은 새 작업을 배치하거나 구현 계획을 만들지 않는다. 시작 전 발견한 미반영 완료는 같은 스킬의 `sync`로 검증·반영하고, 문서 drift는 `update-roadmap`, `roadmap-sdd`, `update-spec`, `update-contract` 책임으로 넘긴다.
새 계약의 `complete.log` 첫 줄 `milestone-task=<id>[,<id>...]`는 해당 완료 작업의 evidence가 어느 Milestone Task에 기여하는지 나타내는 인덱스다. 이 값만으로 Task 완료를 선언하지 않는다. 같은 Milestone task group의 모든 완료 로그를 id별로 모은 뒤 현재 Task 설명, Task 안의 `검증:`, 관련 파일/git evidence, 필요한 SDD Acceptance Scenario와 Evidence Map을 함께 평가해 계약 전체가 충족된 Task만 `[x]`로 바꾼다.
@ -15,6 +20,8 @@ description: 현 마일스톤과 작업현황 동기화, 현재 마일스톤 작
## 언제 호출할지
- 사용자가 "현재 마일스톤 정합성 체크해", "<이름> 마일스톤 정합성 체크해"처럼 현재 또는 지정 Milestone을 시작하기 전 실제 프로젝트 상태와 대조해 달라고 요청할 때
- 사용자가 마일스톤 시작, Plan 전 마일스톤 리프레시, 전체 프로젝트 작업현황과 대상 Milestone 정합성 확인을 요청할 때
- 사용자가 현 마일스톤과 작업현황 동기화, 마일스톤 완료내역 반영, 체크박스 재동기화를 요청할 때
- code-review가 `m-*` PASS completion event와 `complete-log`를 전달했을 때
- `complete.log``milestone-task` id별 evidence를 모아 현재 Task 계약을 평가해야 할 때
@ -24,8 +31,65 @@ description: 현 마일스톤과 작업현황 동기화, 현재 마일스톤 작
## 입력
- `target-milestone`: 활성 Milestone 이름, slug, 또는 경로. 없으면 `agent-roadmap/current.md`의 단일 활성 Milestone을 사용한다. (선택)
- `complete-log`: 방금 완료된 exact `complete.log` 경로. 이 파일을 우선 검증하되 같은 Milestone task group의 다른 완료 로그도 집계한다. (선택)
- `mode`: `sync` 또는 `check-only`. 기본값은 `sync`다. `check-only`에서는 어떤 파일도 수정하지 않는다. (선택)
- `complete-log`: 방금 완료된 exact `complete.log` 경로. `sync` 또는 `check-only`에서 이 파일을 우선 검증하되 같은 Milestone task group의 다른 완료 로그도 집계한다. (선택)
- `mode`: `consistency-check`, `sync`, `check-only` 중 하나다. 기본값은 `sync`다. `consistency-check``check-only`에서는 어떤 파일도 수정하지 않는다. (선택)
## 모드 경계
| mode | lifecycle | 책임 | 쓰기 |
|------|-----------|------|------|
| `consistency-check` | 시작 전 | 전역 활성 workstate를 얕게 확인하고 대상 Milestone과 현재 repository의 semantic drift 및 Plan 준비 상태를 판정 | 금지 |
| `check-only` | 진행·종료 | 완료 evidence를 Task별로 집계하고 반영 후보만 판정 | 금지 |
| `sync` | 진행·종료 | 검증된 완료 evidence를 Task 체크와 허용된 Milestone/Phase/current 상태에 반영 | 허용 |
`check-only`는 완료 evidence dry-run이고 `consistency-check`는 시작 전 semantic drift 감사다. 두 모드를 같은 의미로 사용하지 않는다.
## consistency-check 실행 절차
1. **대상 Milestone 확정**
- `target-milestone`이 있으면 활성 `agent-roadmap/phase/*/milestones/*.md`에서 정확히 하나를 찾는다.
- 없으면 `agent-roadmap/current.md`의 단일 활성 Milestone을 사용한다.
- 대상이 없거나 둘 이상이거나 archive 경로이면 어떤 파일도 수정하지 않고 `blocked`로 보고한다.
2. **프로젝트 활성 workstate snapshot 구성**
- `agent-roadmap/current.md``priority-queue.md`는 존재할 때만 읽고, 없으면 만들지 않은 채 각각 `local current 없음`, `전역 실행 순서 없음`으로 기록한다. 명시 target이 있으면 current 부재만으로 차단하지 않고, queue 부재·파싱 오류는 `refresh-required`로 판정한다.
- `ROADMAP.md`의 Phase 흐름, 모든 active Phase `PHASE.md`의 Milestone 흐름, active Milestone 문서의 H1·상태·구현 잠금 상태와 `.agent-roadmap-sync/locks.yaml` 존재 시 관련 lock을 얕게 읽는다.
- 각 prefix의 active lane head, 대상의 선행 차단과 실제 진행 중인 참조 대상에 대한 동시 차단, Milestone/Phase/current 라벨 불일치와 구현 잠금 상태를 확인한다. prefix 그룹 순서와 일반적인 관련성은 의존성으로 만들지 않는다.
- `current.md`는 활성 후보 창이지 실제 진행 상태가 아니다. 실제 진행 중 여부는 사용자 명시와 active task evidence로 구분한다.
- `agent-task/`의 active task group 이름과 PLAN/CODE_REVIEW/USER_REVIEW 존재 상태를 얕게 확인한다. unrelated task 본문을 전부 읽지 않는다.
- `git status --short`로 checkout의 활성 변경을 확인하되 사용자 변경을 수정하거나 완료 evidence로 간주하지 않는다.
3. **대상 Milestone 계약 읽기**
- `목표`, `상태`, `구현 잠금`, `범위`, `기능`, `범위 제외`, `작업 컨텍스트`와 관련 Phase/queue 설명을 읽는다.
- `SDD: 필요`이면 SDD의 현재 책임 경계, Acceptance Scenario, Evidence Map과 같은 디렉터리의 `USER_REVIEW.md` 존재 여부를 확인한다.
- 대상 task group이 이미 있으면 이 스킬의 완료 로그 수집·Task별 evidence 집계 기준을 재사용해 구현됐지만 Milestone에 반영되지 않은 capability가 있는지 확인한다. 다른 slug의 archive는 읽지 않는다.
4. **현재 repository 기준선 확인**
- 프로젝트와 대상 경로의 domain rule을 먼저 읽는다.
- `agent-spec/`이 있으면 `rules-agent-spec.md`, `agent-spec/index.md`, 매칭되는 현재 spec만 읽는다.
- API, wire, config, schema 또는 컴포넌트 간 계약이 관련되며 `agent-contract/index.md`가 있으면 index와 매칭되는 active contract만 읽는다.
- Milestone `작업 컨텍스트`의 관련 경로에서 `rg --files`, symbol 검색, 현재 코드·config·proto·테스트를 확인한다. 필요할 때만 관련 경로의 `git log`, `git show`, `git diff`를 사용한다.
- 전체 repository를 무차별 감사하지 않고 전역 workstate는 얕게, 대상 Milestone과 직접 의존 기반만 깊게 확인한다.
5. **semantic drift 분류**
- `already-implemented`: 현재 capability가 구현됐지만 Task/evidence에 반영되지 않았다.
- `stale-assumption`: Milestone 또는 SDD가 현재 존재하지 않는 owner, 경로, 상태 전이, API/wire/config 구조를 전제한다.
- `dependency-drift`: 선행 기반이나 공통 coordinator가 변경돼 계획한 구현·검증·retry/identity 경계를 다시 써야 한다.
- `scope-drift`: 현재 기능 Task가 중복·누락됐거나 현재 책임 경계와 충돌한다.
- `queue-lock-drift`: 실제 의존·배타적 변경 책임과 priority queue blocker 또는 workspace lock이 충돌한다. 경로 중복이나 일반적인 관련성만으로 동시 차단을 만들지 않는다.
- `evidence-gap`: 구현 가능성 판단에 필요한 spec, contract, test 또는 provenance가 부족하다.
- 아직 구현되지 않은 미래 capability 자체는 정상 planned delta다. 현재 구조와 충돌하거나 이미 대체된 경우에만 drift로 분류한다.
6. **Plan 준비 상태 판정**
- `ready`: 대상이 `[계획]` 또는 `[진행중]`, 구현 잠금과 SDD gate가 해제되고 blocker가 없으며 Plan 입력을 바꿀 semantic drift가 없다.
- `refresh-required`: 대상 identity는 유효하지만 Milestone/SDD/spec/contract/queue를 현재 기준으로 갱신해야 Plan 범위를 확정할 수 있다.
- `blocked`: 대상이 모호하거나 `[스케치]`·`[보류]`, 해당 prefix의 active lane head가 아니거나 구현 잠금·사용자 결정·SDD review·선행/동시/외부 의존이 남아 Plan을 시작할 수 없다.
7. **read-only 보고와 후속 라우팅**
- 어떤 파일도 수정하지 않고 아래 `consistency-check 판정 보고 형식`으로 결과를 남긴다.
- 사용자가 "체크해", "확인해"만 요청했으면 보고 후 멈춘다.
- 사용자가 "정합성 맞춰줘", "리프레시해", "검사하고 반영해"까지 요청했으면 caller/router가 보고 evidence를 유지한다. `already-implemented` Task는 같은 스킬의 `mode=sync`, Milestone/queue/lock은 `update-roadmap`, SDD는 `roadmap-sdd`, living spec은 `update-spec`, contract는 `update-contract`로 넘긴다.
- 후속 갱신 뒤 `consistency-check`를 다시 실행한다. `ready`가 확인되고 별도 Plan 요청 또는 연결된 사용자 요청이 있을 때만 `plan`으로 진행한다.
## first-line metadata 계약
@ -42,7 +106,7 @@ description: 현 마일스톤과 작업현황 동기화, 현재 마일스톤 작
- PLAN, CODE_REVIEW, `complete.log`는 같은 generation header를 보존한다.
- metadata는 evidence routing 범위다. PASS 또는 id 존재만으로 `[x]` 처리하지 않는다.
## 실행 절차
## sync/check-only 실행 절차
1. **대상 Milestone 확정**
- `target-milestone`이 있으면 활성 `agent-roadmap/phase/*/milestones/*.md`에서 정확히 하나를 찾는다.
@ -116,6 +180,35 @@ description: 현 마일스톤과 작업현황 동기화, 현재 마일스톤 작
## 판정 보고 형식
### consistency-check 판정 보고 형식
```markdown
## 마일스톤 시작 정합성 체크
- 대상 Milestone: [<milestone-name>](agent-roadmap/phase/<phase-slug>/milestones/<milestone-slug>.md)
- 모드: consistency-check
- Plan 준비 상태: <ready | refresh-required | blocked>
## 프로젝트 작업현황
- current/Phase/Milestone 상태: <정합 | 불일치 요약>
- queue/lock: <실행 가능 | 차단 요약 | 정리 필요>
- active agent-task: <관련 상태 요약 또는 없음>
- checkout 변경: <관련 변경 요약 또는 없음>
- 깊게 확인한 범위: <문서·코드·config·proto·테스트 링크 또는 없음>
## Drift 판정
- <already-implemented | stale-assumption | dependency-drift | scope-drift | queue-lock-drift | evidence-gap>: <evidence와 영향 또는 없음>
## 후속 라우팅
- 필요한 갱신: <쉼표로 구분한 sync-milestone-workstate mode=sync | update-roadmap | roadmap-sdd | update-spec | update-contract 목록 또는 없음>
- Plan 진행 조건: <충족 | 필요한 선행 조치>
```
### sync/check-only 판정 보고 형식
```markdown
## 동기화 완료
@ -143,6 +236,10 @@ description: 현 마일스톤과 작업현황 동기화, 현재 마일스톤 작
## 금지 사항
- `consistency-check`에서 파일을 수정하거나 Task 체크박스·Milestone 상태·queue·lock을 변경하지 않는다.
- 정상 planned delta를 현재 미구현이라는 이유만으로 drift 또는 차단으로 판정하지 않는다.
- 전역 workstate 확인을 이유로 unrelated 코드, unrelated active task 본문 또는 다른 Milestone의 archive를 무차별 탐색하지 않는다.
- `refresh-required` 또는 `blocked` 상태에서 Plan을 만들거나 구현을 시작하지 않는다.
- `milestone-task` id 존재, plan PASS, 로그 개수만으로 Task를 `[x]` 처리하지 않는다.
- plan 하나와 Task 하나를 1:1로 가정하거나, 같은 id의 여러 로그 중 하나만 임의 선택하지 않는다.
- 새 canonical 로그에 `Roadmap Completion` 작성을 요구하지 않는다.

View file

@ -7,7 +7,7 @@
## 목표
Node가 자신이 실행하는 normalized run과 provider raw tunnel의 provider-originated 진행 신호를 request 단위로 관측하고, 기본 5분 동안 의미 있는 진행이 없으면 request stall로 확정한다.
Node가 자신이 실행하는 normalized run과 provider raw tunnel의 provider-originated 진행 신호를 request 단위로 관측하고, 더 이른 request hard deadline이나 transport loss가 없는 상태에서 기본 5분 동안 의미 있는 진행이 없으면 request stall로 확정한다.
Node는 원 요청의 liveness와 provider 전체 health를 분리해 직접 점검하고 stalled attempt를 취소·fence하며, Edge의 ingress recovery owner는 전달받은 typed 결과와 response commit 상태를 기준으로 안전한 요청만 기존 공통 budget 안에서 bounded 재실행한다.
## 상태
@ -49,15 +49,15 @@ Node는 원 요청의 liveness와 provider 전체 health를 분리해 직접 점
Node가 provider 실행에 가장 가까운 위치에서 진행 증거와 무응답 시간을 판정하고 health probe 결과를 별도 축으로 분류하는 capability를 묶는다.
- [ ] [activity-contract] normalized `RuntimeEvent`와 raw `ProviderTunnelFrame`의 provider-originated activity를 하나의 진행 계약으로 정규화하고 provider-level `response_stall_timeout_ms`의 기본 5분 no-progress clock을 적용한다. 더 이른 request hard deadline은 기존 failure로 유지하며 구현과 함께 Agent Runtime·Edge Config/Refresh 계약을 갱신한다. 검증: config default/override/negative validation과 fake clock 기반 run/tunnel 테스트에서 text·reasoning·response start/body/usage가 clock을 갱신하고 Node/Edge heartbeat, socket/process 생존, 빈 frame은 갱신하지 않으며 hard deadline을 stall로 재분류하지 않는다.
- [ ] [activity-contract] normalized `RuntimeEvent`와 raw `ProviderTunnelFrame`의 provider-originated activity를 하나의 진행 계약으로 정규화하고 provider-level `response_stall_timeout_ms`의 기본 5분 no-progress clock을 적용한다. 더 이른 request hard deadline과 transport disconnect는 각각 기존 failure로 유지하며 구현과 함께 Provider Execution Runtime·Edge Config/Refresh 계약을 갱신한다. 검증: config default/override/negative validation과 fake clock 기반 run/tunnel 테스트에서 text·reasoning·response start/body/usage가 clock을 갱신하고 terminal은 clock을 종료하며, Node/Edge heartbeat, socket/process 생존, 빈 frame은 갱신하지 않고 hard deadline이나 `heartbeat_timeout`을 stall로 재분류하지 않는다.
- [ ] [stall-watchdog] no-progress threshold에 도달한 attempt를 단 한 번 `response_stalled`로 전환하고 cancel·exactly-once terminal·late-event fencing을 Node pipeline에서 수행한다. `attempt_fence=confirmed`는 old attempt의 Node emission authority와 로컬 transport/execution ownership이 닫혔음을 뜻하고, `unconfirmed`이면 자동 재실행을 금지한다. 검증: threshold 경계, timer/event/cancel race, close success/failure와 terminal 이후 late delta/frame에서 terminal과 fence 결과가 정확히 한 번 확정된다.
- [ ] [health-classification] stalled request와 독립된 bounded target-aware provider probe를 실행해 `available`, `unavailable`, `unknown`을 각각 request-stalled/provider-unhealthy/health-unknown으로 분류한다. Node는 adapter/target과 connection-scoped monotonic observation sequence를 내고, Edge는 수신 connection generation 및 immutable dispatch의 provider identity와 일치하는 fresh evidence만 runtime health overlay에 적용한다. 검증: probe 성공·target 없음·network error·unsupported prober·stale connection/sequence·identity mismatch·unhealthy 후 recovery fixture가 원 요청의 내부 추론 상태를 추정하지 않고 기대 분류와 복구 전이를 낸다.
- [ ] [health-classification] stalled request와 독립된 bounded target-aware provider probe를 실행해 `available`, `unavailable`, `unknown`을 각각 request-stalled/provider-unhealthy/health-unknown으로 분류한다. Node는 adapter/target과 connection-scoped monotonic observation sequence를 내고, Edge는 수신 connection generation 및 immutable dispatch의 provider identity와 일치하는 fresh evidence만 runtime health overlay에 적용한다. 검증: probe 성공·target 없음·network error·unsupported prober·provider identity 없음·stale connection/sequence·identity mismatch·unhealthy 후 recovery fixture가 원 요청의 내부 추론 상태를 추정하지 않고 기대 분류와 fail-closed 복구 전이를 낸다.
### Epic: [recovery-handoff] Edge 복구 Handoff와 Attempt Fencing
Node가 확정한 stall evidence를 Edge가 안전한 재실행 또는 terminal 결과로 수렴시키는 capability를 묶는다.
- [ ] [failure-handoff] normalized run과 raw tunnel이 같은 stable `response_stalled` failure code, provider health 분류, idle duration, attempt identity, fence 결과와 observation sequence를 전달하고 구현과 함께 Agent Runtime·Edge-Node Runtime Wire 계약을 갱신한다. `Failure.retryable`은 confirmed local fence에 대한 capability hint일 뿐 재실행 승인이 아니며, Node terminal에는 Node가 알 수 없는 `recovery_eligible`을 싣지 않는다. Edge는 immutable dispatch binding을 검증하고 old attempt lease를 정확히 한 번 정리한다. 검증: Edge-Node wire round-trip과 normalized/tunnel lifecycle 테스트에서 secret/raw output 없이 동일 분류가 보존되고 provider identity mismatch가 health projection을 바꾸지 않는다.
- [ ] [failure-handoff] normalized run과 raw tunnel이 같은 stable `response_stalled` failure code, provider health 분류, idle duration, attempt identity, fence 결과와 observation sequence를 전달하고 구현과 함께 Provider Execution Runtime·Edge-Node Runtime Wire 계약을 갱신한다. `Failure.retryable`은 confirmed local fence에 대한 capability hint일 뿐 재실행 승인이 아니며, Node terminal에는 Node가 알 수 없는 `recovery_eligible`을 싣지 않는다. Edge는 immutable dispatch binding을 검증하고 old attempt lease를 정확히 한 번 정리한다. 검증: Edge-Node wire round-trip과 normalized/tunnel lifecycle 테스트에서 secret/raw output 없이 동일 분류가 보존되고 provider identity mismatch가 health projection을 바꾸지 않는다.
- [ ] [bounded-retry] OpenAI-compatible host가 typed stall을 기존 StreamGate recovery intent/cause로 변환하고, `transport_uncommitted`, caller cancel, tool/비가역 side effect, confirmed attempt fence와 공유 request-level recovery budget을 함께 평가해 새 run/attempt identity로 재실행한다. stalled provider는 해당 recovery cycle에서 우선 제외하고, 대체 후보가 없으며 probe가 `available`일 때만 같은 provider 후보를 허용한다. 별도 liveness retry counter를 만들지 않고 recovery owner가 없는 surface, post-commit, unconfirmed fence와 budget 소진은 terminal로 끝낸다. 검증: healthy request stall, unhealthy provider failover, unknown probe, same-provider-only, no-recovery-owner, post-commit, unconfirmed fence와 shared-budget exhaustion fixture에서 중복 dispatch/terminal이 없다.
### Epic: [liveness-operations] Liveness 운영 증거
@ -88,12 +88,16 @@ request stall과 provider health를 운영자가 서로 다른 원인 축으로
## 작업 컨텍스트
- 관련 경로: `apps/node/internal/node`, `packages/go/agentruntime`, `packages/go/config`, `apps/edge/internal/service`, `apps/edge/internal/openai`, `packages/go/streamgate`, `proto/iop/runtime.proto`
- 관련 경로: `apps/node/internal/node`, `packages/go/execution`, `packages/go/config`, `apps/edge/internal/service`, `apps/edge/internal/openai`, `packages/go/streamgate`, `proto/iop/runtime.proto`
- 관련 계약: [Provider Execution Runtime 계약](../../../../agent-contract/inner/execution-runtime.md), [Edge-Node Runtime Wire 계약](../../../../agent-contract/inner/edge-node-runtime-wire.md), [Edge Config/Refresh 계약](../../../../agent-contract/inner/edge-config-runtime-refresh.md)
- 현재 구현 기준: [Edge-Node Provider Execution 구현 스펙](../../../../agent-spec/runtime/edge-node-execution.md), [Stream Evidence Gate 구현 스펙](../../../../agent-spec/runtime/stream-evidence-gate.md), [Provider Pool Config/Refresh 구현 스펙](../../../../agent-spec/runtime/provider-pool-config-refresh.md)
- 표준선(선택): liveness timer, local attempt fence와 probe orchestration은 Node가 소유한다. 공통 runtime은 provider-neutral activity/failure/probe 계약만 제공한다. Edge service는 provider lease·admission·routing을 소유하고 ingress별 recovery host가 response commit·replay eligibility를 소유하며 Control Plane과 agent는 실행 감시자가 아니다.
- 표준선(선택): reasoning 여부는 provider가 `reasoning_delta` 또는 동등한 명시 progress를 낸 경우에만 관측 가능하다. socket/process/heartbeat가 살아 있다는 사실이나 독립 health probe 성공을 원 요청의 추론 진행 증거로 사용하지 않는다.
- 표준선(선택): 현재 Edge/Node transport의 30초 heartbeat interval과 45초 response wait는 connection-generation liveness다. 먼저 발생한 `heartbeat_timeout`/disconnect는 connection generation과 provider lease를 fence하지만 raw tunnel subscriber를 즉시 terminal로 닫는 신호는 아니므로, ingress의 기존 wait timeout/cancel과 혼동하거나 5분 request stall로 재분류하지 않는다.
- 표준선(선택): 현재 기본 hard timeout은 OpenAI/A2A/Console surface `120s`, service fallback `30s`로 기본 stall timeout `300s`보다 짧다. 이 경로에서는 hard timeout이 먼저 끝나는 것이 정상이며, stall 분류는 effective request timeout이 300초보다 길거나 provider override가 그보다 짧은 요청에서만 활성화된다.
- 표준선(선택): timeout 진입은 monotonic하다. threshold 뒤 도착한 old attempt event는 새 progress로 되살리지 않고 attempt generation으로 drop한다.
- 표준선(선택): OpenAI-compatible 자동 재실행은 [OpenAI-compatible 출력 검증 필터](../../knowledge-tool-optimization-extension/milestones/openai-compatible-output-validation-filters.md)가 채택하는 StreamGate commit boundary와 request-local recovery coordinator를 재사용하고 공통 fault budget을 소비한다. 이 Milestone은 별도 기본 재시도 횟수를 추가하지 않는다.
- 큐 배치: 사용자 지정 순서가 없어 전역 실행 순서 끝에 추가한다.
- 선행 작업: 없음
- 구현 계획 분할 기준: Node observer/watchdog/probe와 execution/wire 변경을 한 slice로, Edge health overlay와 ingress recovery host 결합을 다른 slice로 나눈다. 후자는 plan 생성 시 관련 Milestone인 [IOP 실행 프리셋과 Hot Path](../../knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md)의 최신 OpenAI/StreamGate 변경을 다시 확인한다.
- 실행 순서: [전역 마일스톤 실행 순서](../../../priority-queue.md)의 `observe-01`을 따른다.
- 후속 작업: [요청 실행 로그와 Usage Ledger 기반](request-execution-log-usage-ledger-foundation.md), [Provider 부하 메트릭과 Live Queue Dashboard](provider-load-metrics-queue-dashboard.md)
- 확인 필요: 없음

View file

@ -29,14 +29,15 @@
| 영역 | 기준 | 메모 |
|------|------|------|
| Roadmap | [Milestone 문서](../../../phase/operational-observability-provider-management/milestones/node-provider-execution-liveness-recovery.md) | 목표, 기능 Task와 완료 범위 |
| Code | `apps/node/internal/node/run_handler.go`, `runtime_sink.go`, `tunnel_handler.go` | per-run/tunnel observer, cancel과 terminal fencing owner |
| Code | `packages/go/agentruntime/types.go`, `failure.go` | provider-neutral activity, `ProviderProber`와 typed failure 계약 |
| Code | `apps/edge/internal/service` | immutable dispatch-provider binding, provider lease·admission·routing owner |
| Code | `apps/node/internal/node/run_handler.go`, `run_manager.go`, `runtime_sink.go`, `tunnel_handler.go` | per-run/tunnel observer, cancel과 terminal fencing owner |
| Code | `packages/go/execution/types.go`, `failure.go`, `emitter.go` | provider-neutral activity, `ProviderProber`, typed failure와 terminal 계약 |
| Code | `apps/edge/internal/service/provider_tunnel.go`, `model_queue_release.go`, `run_cancel.go` | immutable dispatch-provider binding, provider lease·admission·routing, disconnect settlement과 cancel transport owner |
| Code | `packages/go/streamgate`, `apps/edge/internal/openai` | OpenAI response commit, request-local recovery budget, attempt abort/rebuild/dispatch owner |
| Config | `packages/go/config`, `configs/edge.yaml` | provider-first liveness timeout과 Node payload source of truth |
| Contract | [Agent Runtime 계약](../../../../agent-contract/inner/agent-runtime.md) | provider run/event/probe/failure 의미 |
| Contract | [Provider Execution Runtime 계약](../../../../agent-contract/inner/execution-runtime.md) | provider run/event/probe/failure 의미 |
| Contract | [Edge-Node Runtime Wire 계약](../../../../agent-contract/inner/edge-node-runtime-wire.md) | normalized run/tunnel terminal과 cancel ordering |
| Contract | [Edge Config/Refresh 계약](../../../../agent-contract/inner/edge-config-runtime-refresh.md) | provider liveness 설정과 generation isolation |
| Spec | [Edge-Node Provider Execution](../../../../agent-spec/runtime/edge-node-execution.md), [Stream Evidence Gate](../../../../agent-spec/runtime/stream-evidence-gate.md), [Provider Pool Config/Refresh](../../../../agent-spec/runtime/provider-pool-config-refresh.md) | 현재 구현된 transport heartbeat, commit/recovery와 provider config 기준 |
| User Decision | 2026-07-29 사용자 대화 | Node 관측 pipeline이 감시를 소유하고, 5분 이상 응답이 없으면 health 분류 후 안전한 요청을 재실행한다. |
## State Machine
@ -45,6 +46,8 @@
|------|-----------|-----------|------|
| request/observing | Node가 run/tunnel attempt를 실행하고 start clock을 시작함 | request/observing / request/stall-detected / request/terminal | provider-originated activity, monotonic clock, terminal |
| request/observing | non-empty text/reasoning/response-start/body/usage 또는 명시 provider progress가 도착함 | request/observing | Node liveness observer가 last-progress를 갱신 |
| request/observing | current connection이 먼저 `heartbeat_timeout` 또는 disconnect로 종료됨 | request/transport-lost | connection-generation과 provider lease를 fence하고 request stall metadata를 만들지 않음 |
| request/transport-lost | ingress의 기존 wait timeout, caller cancel 또는 transport close가 확정됨 | request/terminal | raw tunnel subscriber가 disconnect만으로 즉시 닫히지 않는 현재 경로에서도 기존 ingress terminal owner가 exactly once로 수렴 |
| request/stall-detected | last-progress 이후 configured threshold가 지나고 terminal이 없음 | request/fencing + provider/probing | Node watchdog이 stall을 단 한 번 확정하고 cancel/close와 bounded probe를 시작 |
| request/fencing | Node가 old attempt의 emission authority를 철회하고 local transport/execution ownership을 닫음 | request/stalled (`attempt_fence=confirmed`) | late event를 drop할 수 있는 local generation fence |
| request/fencing | bounded cancel/close가 실패하거나 완료 여부를 확정할 수 없음 | request/terminal (`attempt_fence=unconfirmed`) | 중복 output/dispatch 위험 때문에 자동 재실행 금지 |
@ -55,16 +58,17 @@
| request/stalled | ingress recovery owner가 uncommitted·uncanceled·side-effect-safe·budget-available로 판정함 | request/redispatched | host-owned commit boundary와 recovery coordinator |
| request/redispatched | recovery owner가 새 run/attempt identity를 발급함 | request/observing | 새 Node execution generation |
| request/stalled | recovery owner 없음, post-commit, cancel, side effect, budget 소진 또는 provider 후보 없음 | request/terminal | typed `response_stalled` terminal |
| request/terminal | complete/error/cancelled 또는 liveness terminal이 exactly once 확정됨 | 없음 | terminal emitter와 old generation fence |
| request/terminal | complete/error/cancelled, ingress transport terminal 또는 liveness terminal이 exactly once 확정됨 | 없음 | terminal emitter/ingress terminal owner와 old generation fence |
## Interface Contract
- 계약 원문: [Agent Runtime 계약](../../../../agent-contract/inner/agent-runtime.md), [Edge-Node Runtime Wire 계약](../../../../agent-contract/inner/edge-node-runtime-wire.md), [Edge Config/Refresh 계약](../../../../agent-contract/inner/edge-config-runtime-refresh.md)
- 계약 원문: [Provider Execution Runtime 계약](../../../../agent-contract/inner/execution-runtime.md), [Edge-Node Runtime Wire 계약](../../../../agent-contract/inner/edge-node-runtime-wire.md), [Edge Config/Refresh 계약](../../../../agent-contract/inner/edge-config-runtime-refresh.md)
- 입력:
- `nodes[].providers[].response_stall_timeout_ms`: 생략/`0`이면 `300000`, 양수이면 provider별 override, 음수이면 config 오류다. provider-first config가 Node adapter/runtime observation config로 전달되며 provider config가 없는 legacy adapter route도 기본 `300000`을 사용한다. 변경은 다른 provider-first execution field와 같이 `restart_required`로 분류한다.
- timeout precedence: request hard deadline이 no-progress threshold보다 먼저 끝나면 기존 deadline failure를 유지한다. `response_stall_timeout_ms`는 queue timeout, request 전체 timeout과 CLI profile의 `response_idle_timeout_ms` completion heuristic을 대체하지 않는다.
- normalized activity: non-empty `delta`, `reasoning_delta`, 명시 provider progress와 terminal event. `start`는 clock 시작점이지 반복 progress heartbeat가 아니다.
- tunnel activity: provider response start/header, non-empty body, usage와 terminal frame. 빈 frame, Node/Edge heartbeat, socket/process 생존은 progress가 아니다.
- timeout precedence: request hard deadline이나 current connection의 `heartbeat_timeout`/disconnect가 no-progress threshold보다 먼저 끝나면 각각 기존 deadline/transport 경계를 유지한다. 현재 Edge/Node의 30초 heartbeat interval과 45초 response wait는 connection-generation liveness이며 `response_stall_timeout_ms`는 queue timeout, request 전체 timeout, transport liveness와 CLI profile의 `response_idle_timeout_ms` completion heuristic을 대체하지 않는다.
- current timeout baseline: 현재 OpenAI/A2A/Console 기본 hard timeout은 `120s`, service fallback은 `30s`다. 기본 `response_stall_timeout_ms=300000`은 이 기본 경로에서 hard timeout보다 먼저 발동하지 않으며, effective request timeout이 300초보다 길거나 provider override가 더 짧을 때만 stall 판정이 도달 가능하다. 이 관계를 자동으로 timeout 값 변경이나 config 오류로 재해석하지 않는다.
- normalized activity: non-empty `delta`, `reasoning_delta`와 명시 provider progress. `start`는 clock 시작점이고 complete/error/cancelled terminal은 observer를 종료하지만 last-progress를 갱신하지 않는다.
- tunnel activity: provider response start/header, non-empty body와 usage. END/ERROR terminal은 observer를 종료하지만 last-progress를 갱신하지 않으며 빈 frame, Node/Edge heartbeat, socket/process 생존은 progress가 아니다.
- provider probe: stalled attempt의 adapter/target에 대한 bounded `ProviderProber` 결과. probe는 원 request와 별도 context에서 실행한다.
- recovery eligibility: ingress recovery owner가 소유한 response commit, caller cancel, shared request-level fault budget, tool/비가역 side effect, provider-pool candidate와 request idempotency 상태. Node는 이 값을 계산하지 않는다.
- 출력:
@ -72,8 +76,8 @@
- wire terminal: normalized run은 exactly-once `RunEvent{type=error}`, tunnel은 exactly-once `ProviderTunnelFrame{kind=ERROR}`로 수렴한다.
- safe Node metadata: `failure_code=response_stalled`, `provider_health=available|unavailable|unknown`, `idle_duration_ms`, `run_id`, `attempt_id`, `attempt_fence=confirmed|unconfirmed`, adapter/target identity와 `health_observation_seq`; raw provider body, reasoning, prompt, credential과 Edge-owned `recovery_eligible`은 넣지 않는다.
- provider identity: Node의 `health_observation_seq`는 connection 안에서만 단조 증가한다. Edge는 wire에 내부 generation을 노출하지 않고 evidence를 수신한 registry connection generation에 묶은 뒤, immutable `RunDispatch``(node_id, provider_id, adapter, target)`과 대조한다. stale connection/sequence 또는 identity mismatch evidence는 health projection에 적용하지 않는다.
- provider projection: config health는 immutable config snapshot으로 유지하고 runtime health overlay를 `(node_id, connection_generation, provider_id)`에 별도 관리한다. `unavailable` probe만 bound provider candidate를 runtime unhealthy로 낮추고, 이후 bounded status probe가 낸 current connection의 같은 provider/adapter/target `available` evidence와 더 큰 observation sequence가 있어야 다시 활성화한다. request-stalled/available과 health-unknown은 provider 전체 장애로 승격하지 않는다.
- recovery: OpenAI-compatible host는 typed stall을 기존 StreamGate recovery cause/intent로 변환하고 `transport_uncommitted`에서만 기존 request-local coordinator의 공유 fault budget을 소비해 새 `run_id`와 attempt identity를 발급한다. 별도 liveness retry counter는 없다. recovery owner가 없는 surface는 typed terminal로 끝난다.
- provider projection: config health는 immutable config snapshot으로 유지하고 runtime health overlay를 `(node_id, connection_generation, provider_id)`에 별도 관리한다. `unavailable` probe만 bound provider candidate를 runtime unhealthy로 낮추고, 이후 bounded status probe가 낸 current connection의 같은 provider/adapter/target `available` evidence와 더 큰 observation sequence가 있어야 다시 활성화한다. immutable dispatch에 stable `provider_id`가 없거나 adapter/target identity가 맞지 않으면 request terminal evidence만 보존하고 health overlay는 갱신하지 않는다. request-stalled/available과 health-unknown은 provider 전체 장애로 승격하지 않는다.
- recovery: OpenAI-compatible host는 typed stall을 기존 StreamGate recovery cause/intent로 변환하고 `transport_uncommitted`에서만 기존 request-local coordinator의 공유 fault budget을 소비해 새 `run_id`와 attempt identity를 발급한다. 별도 liveness retry counter는 없다. recovery owner가 없는 surface는 typed terminal로 끝난다. 현재 `AttemptController.AbortAttempt`의 cancel 전송 성공만으로 Node local fence를 추정하지 않고, Node terminal의 `attempt_fence=confirmed`와 request-local transport close를 모두 만족해야 다음 dispatch를 허용한다.
- 금지:
- Node/Edge heartbeat, TCP 연결, process 생존이나 독립 probe 성공을 원 request의 추론 진행 증거로 사용하지 않는다.
- 현재 CLI persistent `idle-timeout` complete를 liveness failure로 재해석하거나 새 watchdog을 provider별 구현에 복제하지 않는다.
@ -85,9 +89,9 @@
| ID | Milestone Task | Given | When | Then |
|----|----------------|-------|------|------|
| S01 | `activity-contract` | normalized run과 raw tunnel이 provider default/override 설정으로 실행 중임 | provider text/reasoning/response-start/body, Node heartbeat와 더 이른 hard deadline이 각각 발생함 | provider-originated activity만 last-progress를 갱신하고 기본 5분/positive override가 적용되며 heartbeat/process/socket은 무시되고 hard deadline은 stall로 재분류되지 않는다. |
| S01 | `activity-contract` | normalized run과 raw tunnel이 provider default/override 설정으로 실행 중이고 일부 request hard timeout은 stall timeout보다 짧음 | provider text/reasoning/response-start/body, terminal, Node heartbeat, 더 이른 hard deadline과 transport disconnect가 각각 발생함 | provider-originated activity만 last-progress를 갱신하고 terminal은 observer를 종료하며, 짧은 hard timeout과 `heartbeat_timeout`은 stall로 재분류되지 않고 기존 terminal/transport 경계로 수렴한다. |
| S02 | `stall-watchdog` | terminal 없이 configured threshold 동안 provider progress가 없음 | watchdog, 늦은 provider event와 cancel/close success 또는 failure가 경쟁함 | stall/terminal과 local attempt fence가 한 번만 확정되고 confirmed일 때 old event가 drop되며 unconfirmed일 때 자동 재실행이 금지된다. |
| S03 | `health-classification` | request stall이 확정됨 | target probe가 available/unavailable/unsupported 또는 timeout을 반환하고 stale connection/sequence, identity mismatch 및 fresh recovery evidence가 도착함 | request health와 provider health가 분리되고 current connection의 bound identity와 더 큰 observation sequence만 unhealthy를 회복하며 probe 성공을 원 request progress로 기록하지 않는다. |
| S03 | `health-classification` | request stall이 확정됨 | target probe가 available/unavailable/unsupported 또는 timeout을 반환하고 stable provider identity 없음, stale connection/sequence, identity mismatch 및 fresh recovery evidence가 도착함 | request health와 provider health가 분리되고 stable provider identity가 있는 current connection의 bound evidence와 더 큰 observation sequence만 unhealthy를 회복하며 probe 성공을 원 request progress로 기록하지 않는다. |
| S04 | `failure-handoff` | normalized run과 tunnel이 각각 stall됨 | Node가 typed terminal을 Edge로 전달함 | 두 path가 같은 failure/health/fence 의미를 보존하고 Node metadata에 recovery eligibility가 없으며 identity mismatch는 health를 바꾸지 않고 old attempt lease가 정확히 한 번 정리된다. |
| S05 | `bounded-retry` | OpenAI 미커밋 request, post-commit request, unconfirmed fence와 recovery owner가 없는 request가 각각 stall됨 | ingress host가 recovery를 평가함 | confirmed·미커밋·side-effect-safe request만 StreamGate 공유 fault budget 안에서 새 run identity로 재실행되고 나머지는 terminal로 끝난다. |
| S06 | `ops-evidence` | provider-available request stall, provider-unhealthy, stale health evidence와 후속 recovery가 발생함 | Node/Edge metric·log와 provider snapshot을 조회함 | request liveness, fence/probe와 Edge commit/recovery 결정이 분리되고 stale evidence가 거부되며 high-cardinality/raw content가 노출되지 않는다. |
@ -96,9 +100,9 @@
| Scenario | Required Evidence | `agent-task` 연결 | 완료 Evidence 기대 |
|----------|-------------------|------------------|---------------------------|
| S01 | config validation과 fake clock 기반 normalized/tunnel activity/deadline table test | `agent-task/m-node-provider-execution-liveness-recovery/...` | `activity-contract` Task id, default/override/negative, activity reset와 deadline precedence assertion |
| S01 | config validation과 fake clock 기반 normalized/tunnel activity/deadline/transport table test | `agent-task/m-node-provider-execution-liveness-recovery/...` | `activity-contract` Task id, default/override/negative, terminal stop, activity reset, shorter hard timeout과 transport precedence assertion |
| S02 | threshold·timer/event·cancel/close race와 exactly-once terminal/fence test | `agent-task/m-node-provider-execution-liveness-recovery/...` | `stall-watchdog` Task id, confirmed/unconfirmed fixture와 late-event fence assertion |
| S03 | available/unavailable/unsupported/timeout, stale connection/sequence, identity mismatch와 fresh recovery prober fixture | `agent-task/m-node-provider-execution-liveness-recovery/...` | `health-classification` Task id, request/provider 분리, binding validation과 fresh observation recovery assertion |
| S03 | available/unavailable/unsupported/timeout, provider identity 없음, stale connection/sequence, identity mismatch와 fresh recovery prober fixture | `agent-task/m-node-provider-execution-liveness-recovery/...` | `health-classification` Task id, request/provider 분리, fail-closed binding validation과 fresh observation recovery assertion |
| S04 | RunEvent/ProviderTunnelFrame wire round-trip와 queue lifecycle test | `agent-task/m-node-provider-execution-liveness-recovery/...` | `failure-handoff` Task id, stable code/fence metadata, no recovery eligibility와 release-once assertion |
| S05 | StreamGate commit-boundary/shared-budget, provider-pool failover와 no-owner terminal test | `agent-task/m-node-provider-execution-liveness-recovery/...` | `bounded-retry` Task id, recovery-owner gating, new run identity와 bounded dispatch count assertion |
| S06 | Node/Edge metric label guard, structured log capture와 provider snapshot overlay recovery test | `agent-task/m-node-provider-execution-liveness-recovery/...` | `ops-evidence` Task id, liveness/fence/health/commit/recovery 축과 raw-free evidence |
@ -113,6 +117,7 @@
- [x] Evidence Map이 code-review/complete.log에서 검증 가능하다.
- [x] agent-contract를 쓰는 경우 SDD에 계약 원문을 복제하지 않았다.
- [x] 사용자 리뷰가 필요한 항목은 `USER_REVIEW.md`에만 남겼다.
- [x] 2026-08-03 현재 `packages/go/execution`, Edge-Node 30초/45초 transport heartbeat, 30초/120초 hard timeout, provider tunnel disconnect lifecycle과 StreamGate abort/recovery seam을 다시 확인했다.
## 사용자 리뷰 이력
@ -122,4 +127,6 @@
- 표준선: Node는 execution-local liveness, local attempt fence와 probe evidence를 소유한다. Edge service는 provider lease·candidate eligibility를, ingress recovery host는 response commit·bounded retry를 소유한다. Control Plane은 projection을 소비할 수 있지만 canonical 실행 상태나 watchdog을 소유하지 않는다.
- 재사용 기준: OpenAI-compatible 경로는 [OpenAI-compatible 출력 검증 필터 SDD](../../knowledge-tool-optimization-extension/openai-compatible-output-validation-filters/SDD.md)의 StreamGate commit/recovery 경계를 사용한다. liveness failure는 Node 관측 결과를 소비하는 recovery cause/intent이며 별도 output content filter나 retry coordinator가 아니다.
- 현재 구현 차이: `response_stalled` failure/wire metadata, provider runtime health overlay와 `response_stall_timeout_ms`는 아직 구현되지 않았다. raw tunnel subscriber도 Node disconnect만으로 즉시 닫히지 않고 ingress wait timeout/cancel에 의존한다. 기존 `ProviderProber`, terminal emitter, provider tunnel release-once와 StreamGate recovery coordinator를 확장하며 구현 완료로 간주하지 않는다.
- 계획 분할 기준: Node observer/watchdog/probe와 execution/wire 변경을 한 slice로, Edge health overlay와 ingress recovery host 결합을 다른 slice로 계획한다. 후자는 plan 생성 시 [IOP 실행 프리셋과 Hot Path](../../knowledge-tool-optimization-extension/iop-hot-path-one-shot-execution/SDD.md)의 최신 OpenAI/StreamGate 변경을 다시 확인한다.
- 후속 SDD: [요청 실행 로그와 Usage Ledger 기반 SDD](../request-execution-log-usage-ledger-foundation/SDD.md)

View file

@ -6,6 +6,7 @@ views:
- nodes
- runtime
- execution-logs
- settings
---
# View Definitions
@ -19,6 +20,7 @@ views:
| `nodes` | 구현됨 | `apps/client/lib/widgets/nodes_panel.dart`, `apps/client/lib/widgets/nodes_panel_sections.dart` | 선택 Edge의 Node inventory, adapter config, provider catalog를 보여준다. |
| `runtime` | 구현됨 | `apps/client/lib/widgets/runtime_panel.dart`, `apps/client/lib/widgets/runtime_panel_sections.dart` | Edge health, Node status, provider command와 operation history를 다룬다. |
| `execution-logs` | 구현됨 | `apps/client/lib/widgets/execution_logs_panel.dart` | 선택 Edge의 lifecycle event와 execution log timeline을 보여준다. |
| `settings` | 계획 | 사용자 결정 | 향후 설정 UI 설계에 사용할 설정별 노출, 편집, 마스킹, 제외 정책을 관리한다. |
## Navigation
@ -27,6 +29,7 @@ views:
- `overview` -> `runtime`: 좌측 rail의 Runtime 버튼을 선택한다.
- `overview` -> `execution-logs`: 좌측 rail의 Execution & Logs 버튼을 선택한다.
- `edges`, `nodes`, `runtime`, `execution-logs` -> any listed view: 좌측 rail section 선택으로 전환한다.
- `settings`: 계획 상태이며 navigation과 화면 배치는 아직 확정하지 않는다.
## Common States

View file

@ -0,0 +1,105 @@
---
ui_doc_type: view
view_id: settings
status: 계획
frame: null
source_evidence:
- type: user
path: null
notes: User requested one canonical registry for settings that should be hidden, excluded, masked, read-only, or removed before future UI design.
regions:
- settings.configuration-exposure-policy
---
# Settings
View ID: `settings`
Frame:
- 없음
Status: `계획`
## Source Evidence
| Type | Path | Notes |
|------|------|-------|
| user | 없음 | 향후 UI 설계에서 참조할 설정 노출·제외 결정을 한 곳에 모으도록 요청했다. |
## Purpose
향후 설정 UI 설계에 앞서 설정별 노출, 편집, 마스킹, 제외 결정을 한 곳에서 관리한다.
실제 config schema를 복제하지 않고 설정 경로와 근거 계약을 참조하며, UI 정책과 런타임 설정 제거를 구분한다.
## Primary Users
- IOP operator
- 설정 UI를 설계하거나 구현하는 engineer와 agent
## Primary Tasks
- 설정별 UI 노출 및 편집 가능 여부 확인
- 비노출, 마스킹, 읽기 전용, 스키마 제거 후보 결정 기록
- 향후 view와 component 설계 시 설정 정책 참조
## Information Priority
1. 설정 경로와 UI 처리 결정
2. 결정 사유와 대체 표현 또는 설정
3. 적용 화면, 계약 근거, 결정 상태
## Regions
| Region ID | Purpose | Component | Priority | Notes |
|-----------|---------|-----------|----------|-------|
| `settings.configuration-exposure-policy` | 설정별 UI 노출·제외 정책 관리 | 없음 | high | 실제 화면 배치와 component는 향후 UI 설계에서 확정한다. |
## Configuration Exposure Policy
### UI 처리 값
- `편집 가능`: UI에서 값을 조회하고 변경할 수 있다.
- `읽기 전용`: UI에서 값을 표시하지만 변경할 수 없다.
- `마스킹`: secret 원문을 노출하지 않고 존재 여부나 축약값만 표시한다.
- `UI 비노출`: 설정은 유지하지만 UI에서 표시하거나 변경하지 않는다.
- `스키마 제거 후보`: UI 결정만으로 제거하지 않고 matching config contract와 구현 변경이 별도로 필요하다.
### 설정 정책 목록
`설정 경로`를 고유 키로 사용한다. 같은 설정은 새 행을 만들지 않고 기존 행을 갱신한다.
| 설정 경로 | 소유 범위 | UI 처리 | 사유 | 대체 표현/설정 | 적용 화면 | 근거 | 결정 상태 |
|-----------|-----------|---------|------|----------------|-----------|------|-----------|
### 기록 규칙
- secret, token, credential 원문은 기록하지 않는다.
- `UI 비노출`을 config schema 제거로 해석하지 않는다.
- `스키마 제거 후보`는 matching `agent-contract`와 구현이 갱신되기 전까지 실제 제거로 표시하지 않는다.
- 실제 config key, type, default는 이 문서에 복제하지 않고 matching contract 경로를 `근거`에 기록한다.
- 사용자 결정이 명확하면 `결정 상태``확정`으로 기록한다.
- 설정 경로, 처리 의미, 소유 범위가 불명확하면 추정으로 행을 추가하지 않고 `Open Questions` 또는 `agent-ui/USER_REVIEW.md`로 분리한다.
- 이 문서 기록만으로 UI 코드 동기화를 시작하지 않는다.
## Actions
| Action ID | Trigger | Result | Guard |
|-----------|---------|--------|-------|
| 없음 | 없음 | 구체적인 UI action은 향후 화면 설계에서 확정한다. | 없음 |
## States
- loading: 향후 UI 설계에서 확정한다.
- empty: 등록된 설정 정책이 없음을 표시하는 방향으로 설계한다.
- error: 향후 UI 설계에서 확정한다.
- permission-denied: 설정 조회·변경 권한 모델과 함께 확정한다.
## Open Questions
- navigation과 화면 배치
- 설정 그룹과 반복 component 구조
- 설정 조회·변경 권한 모델
## Decision History
- 2026-08-03: 설정 UI 노출·제외 결정을 누적하는 중앙 정책 문서를 계획 상태로 만들고, 문서 기록만으로 코드 동기화를 시작하지 않도록 정했다.