diff --git a/agent-ops/rules/common/rules-roadmap.md b/agent-ops/rules/common/rules-roadmap.md index 54704a72..d4ec7cda 100644 --- a/agent-ops/rules/common/rules-roadmap.md +++ b/agent-ops/rules/common/rules-roadmap.md @@ -52,9 +52,16 @@ ## Phase와 Milestone 선택 - `current.md`는 현재 작업 위치가 아니라 활성 Phase와 활성 Milestone 후보 목록이다. -- `priority-queue.md`는 현재 작업 위치가 아니라 Phase를 가로지르는 실행 순서 문서다. 위에 있는 항목을 먼저 검토한다. -- `priority-queue.md`는 순서 전용 문서이며, Milestone 제목 링크와 식별용 한 줄 설명만 둔다. 상태, 목표, 범위, 잠금, 기능, 완료 근거, 의존성은 Milestone 문서를 원본으로 삼는다. -- `priority-queue.md`의 순서는 사용자가 순서 조정을 요청한 경우에만 바꾼다. 단, archive/폐기 제거, 경로 변경, split/merge, 실행 의미 변경, 깨진 링크 복구는 예외다. +- `priority-queue.md`는 현재 작업 위치가 아니라 Phase를 가로지르는 실행 lane과 차단 예외를 한눈에 보는 문서다. +- 각 실행 후보는 `[[-] ]()` 형식의 제목 링크와 1~2문장 설명을 가진다. 실행 태그는 소문자 영문으로 시작하는 ASCII prefix, 하이픈, 두 자리 숫자로 작성한다. 예: `[route-01]`. +- 같은 prefix 항목은 하나의 `### ` 그룹에 모으고 `NN` 오름차순으로 둔다. 같은 prefix에서는 더 작은 활성 `NN`이 정상 선행 순서이며, 별도 차단 줄로 반복하지 않는다. +- 서로 다른 prefix는 기본적으로 병렬 실행할 수 있다. 예외만 설명 바로 아래의 exact label `선행 차단:` 또는 `동시 차단:`과 backtick 실행 태그 목록으로 기록한다. +- `선행 차단`은 다른 prefix의 특정 Milestone 완료 전 시작할 수 없을 때만 쓴다. `동시 차단`은 두 작업을 동시에 실행할 수 없을 때 낮은 우선순위 쪽 한 곳에만 쓴다. 일반적인 관련성이나 권장 순서는 차단으로 만들지 않는다. +- 실행 태그와 차단 줄은 `priority-queue.md`가 유일한 실행 순서 원본이다. Milestone 파일 경로/slug는 안정적인 identity이며, 실행 태그를 바꿔도 파일명을 바꾸지 않는다. +- 실행 태그를 재배치하면 같은 변경에서 queue 제목, Milestone H1, 활성 `PHASE.md`와 로컬 `current.md`의 표시 제목, queue 안의 차단 참조를 함께 갱신한다. archive 문서는 재표기하지 않는다. +- runtime은 `## 실행 순서` 아래의 `### ` 그룹, numbered item의 첫 실행 태그와 링크 target, exact blocker label만 파싱한다. 설명 본문은 표시용이며 scheduling 판단에 사용하지 않는다. 중복 태그, prefix heading 불일치, malformed blocker, 존재하지 않는 active tag 참조는 fail-closed 검증 오류다. +- 실행 가능한 후보는 각 prefix에서 가장 작은 활성 `NN` 항목 중 `선행 차단`이 없는 항목이다. `동시 차단`은 참조 대상이 실제 진행 중일 때만 막는다. 여러 prefix 후보가 동시에 열리면 그룹의 문서상 위아래 순서는 기본 선택용 tie-breaker일 뿐 선행 의존성이 아니다. +- `priority-queue.md`의 실행 태그, 그룹 순서, 차단 예외는 사용자가 순서 조정을 요청한 경우에만 바꾼다. 단, archive/폐기 제거, 경로 변경, split/merge, 실행 의미 변경, 깨진 링크·태그·차단 참조 복구는 예외다. - `priority-queue.md` 링크가 깨졌으면 추측하지 말고 활성 Milestone 문서를 기준으로 큐를 재정렬하거나 재생성한다. - `current.md`는 공유 진행 상태가 아니며, 공유해야 할 상태는 `ROADMAP.md`, `PHASE.md`, Milestone 문서, `.agent-roadmap-sync/locks.yaml`에 남긴다. - 활성 Phase는 `agent-roadmap/phase/**/PHASE.md`만 대상으로 한다. @@ -200,6 +207,6 @@ - Milestone 아카이브 전에는 이동 전 활성 경로 identity로 `.agent-roadmap-sync/locks.yaml`을 확인한다. 해당 identity가 `rely-on.target`이면 `[완료]` 상태에서 `enable`로 동기화하고, 해당 identity가 `locked`이면 의존 조건 충족 여부를 보고하며, 어느 쪽에도 없으면 `관련 lock 없음`으로 보고한다. - `구현 잠금`이 남아 있는 Milestone은 `[완료]` 전환이나 완료 archive 대상으로 삼지 않는다. 명시적인 폐기 근거가 있는 `[폐기]` archive는 허용한다. - 아카이빙할 때는 활성 `ROADMAP.md` 또는 활성 `PHASE.md`에 archive 문서 링크와 짧은 요약만 남긴다. -- 아카이빙할 때 `priority-queue.md`가 있으면 이동 전 활성 Milestone 경로 항목을 제거한다. archive 경로로 바꿔 남기지 않는다. +- 아카이빙할 때 `priority-queue.md`가 있으면 이동 전 활성 Milestone 경로 항목을 제거하고, 해당 실행 태그를 가리키는 충족된 `선행 차단` 참조도 제거한다. archive 경로로 바꿔 남기지 않는다. - 아카이브된 Phase/Milestone은 로컬 `current.md`에 남기지 않고, 일반 Phase/Milestone 선택이나 위치 분석의 후보로 삼지 않는다. - 아카이브 문서는 과거 기록 스냅샷으로 보고, 최신 템플릿이나 스킬 규약에 맞춰 재포맷하지 않는다. diff --git a/agent-ops/skills/common/_templates/roadmap-current-template.md b/agent-ops/skills/common/_templates/roadmap-current-template.md index 4ec36eae..adca2388 100644 --- a/agent-ops/skills/common/_templates/roadmap-current-template.md +++ b/agent-ops/skills/common/_templates/roadmap-current-template.md @@ -12,9 +12,9 @@ ## 활성 Milestone -- [<스케치 | 계획 | 진행중 | 검토중 | 보류>] +- [<스케치 | 계획 | 진행중 | 검토중 | 보류>] [-] - Phase: [PHASE.md](phase//PHASE.md) - - 경로: [](phase//milestones/.md) + - 경로: [[-] ](phase//milestones/.md) ## 선택 규칙 diff --git a/agent-ops/skills/common/_templates/roadmap-milestone-template.md b/agent-ops/skills/common/_templates/roadmap-milestone-template.md index 5db5b316..f70ebf64 100644 --- a/agent-ops/skills/common/_templates/roadmap-milestone-template.md +++ b/agent-ops/skills/common/_templates/roadmap-milestone-template.md @@ -1,4 +1,4 @@ -# Milestone: +# Milestone: [-] ## 위치 @@ -87,6 +87,6 @@ Task 체크리스트는 Epic 바로 아래의 flat list로 유지하고, 구현 - 관련 경로: `` - 표준선(선택): <기존 구조, 도메인 rule, 플랫폼 관례, 업계 표준으로 진행할 기본 기준> -- 선행 작업: <없음 또는 파일 위치 기준 Markdown 링크(예: [Milestone 이름](../other-milestone.md))/태스크 이름> -- 후속 작업: <없음 또는 파일 위치 기준 Markdown 링크(예: [Milestone 이름](../next-milestone.md))/태스크 이름> +- 실행 순서와 차단 관계: [전역 마일스톤 실행 순서](../../../priority-queue.md) +- 관련 Milestone(선택): <없음 또는 파일 위치 기준 Markdown 링크(예: [Milestone 이름](../other-milestone.md))> - 확인 필요: <없음 | `구현 잠금 > 결정 필요` 또는 [USER_REVIEW.md](../../../sdd///USER_REVIEW.md)로 분리할 항목> diff --git a/agent-ops/skills/common/_templates/roadmap-phase-template.md b/agent-ops/skills/common/_templates/roadmap-phase-template.md index 349fc3d2..9faf33c8 100644 --- a/agent-ops/skills/common/_templates/roadmap-phase-template.md +++ b/agent-ops/skills/common/_templates/roadmap-phase-template.md @@ -16,8 +16,8 @@ Milestone은 완료, 검토중, 진행중, 계획, 스케치 또는 보류 상 Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실행 순서](../../priority-queue.md)를 우선한다. 스케치 Milestone은 아직 구현 가능한 계획이 아니므로 계획 Milestone보다 아래에 둔다. -- [<스케치 | 계획 | 진행중 | 검토중 | 완료 | 보류 | 폐기>] - - 경로: [](milestones/.md) 또는 [archive ](../../archive/phase//milestones/.md) +- [<스케치 | 계획 | 진행중 | 검토중 | 완료 | 보류 | 폐기>] [-] + - 경로: [[-] ](milestones/.md) 또는 [archive ](../../archive/phase//milestones/.md) - 요약: <목표 또는 결과 1문장> ## Phase 경계 diff --git a/agent-ops/skills/common/_templates/roadmap-position-report-template.md b/agent-ops/skills/common/_templates/roadmap-position-report-template.md index 62d0be0c..22f27fb6 100644 --- a/agent-ops/skills/common/_templates/roadmap-position-report-template.md +++ b/agent-ops/skills/common/_templates/roadmap-position-report-template.md @@ -27,8 +27,10 @@ ## 전역 마일스톤 실행 순서 -- {없음 | [MILESTONE_TITLE](agent-roadmap/phase//milestones/.md): 식별용 한 줄 설명} -- {[MILESTONE_TITLE](agent-roadmap/phase//milestones/.md): 식별용 한 줄 설명 | 큐 정리 필요: 사유} +### {prefix} + +- {없음 | [[prefix-NN] MILESTONE_TITLE](agent-roadmap/phase//milestones/.md): 설명 1~2문장} + - {lane head | 선행 차단: [tag] | 동시 차단: [tag] | 큐 정리 필요: 사유} ## 전체 Phase 흐름 diff --git a/agent-ops/skills/common/_templates/roadmap-priority-queue-template.md b/agent-ops/skills/common/_templates/roadmap-priority-queue-template.md index 9dbaf8e2..c8ca7f40 100644 --- a/agent-ops/skills/common/_templates/roadmap-priority-queue-template.md +++ b/agent-ops/skills/common/_templates/roadmap-priority-queue-template.md @@ -1,17 +1,28 @@ # 전역 마일스톤 실행 순서 -이 문서는 Phase를 가로지르는 Milestone 실행 순서만 기록한다. 위에 있는 항목을 먼저 검토한다. +이 문서는 Phase를 가로지르는 Milestone 실행 lane과 차단 예외를 기록한다. 같은 prefix는 순차 실행하고, 다른 prefix는 차단 표기가 없으면 병렬 실행할 수 있다. ## 실행 순서 diff --git a/agent-ops/skills/common/_templates/roadmap-template.md b/agent-ops/skills/common/_templates/roadmap-template.md index 247ad642..a22bfa4a 100644 --- a/agent-ops/skills/common/_templates/roadmap-template.md +++ b/agent-ops/skills/common/_templates/roadmap-template.md @@ -4,11 +4,12 @@ - 전역 Milestone 실행 순서는 [전역 마일스톤 실행 순서](priority-queue.md)를 먼저 확인한다. - Phase는 도메인/책임 영역이며 순차 실행 게이트가 아니다. -- Phase 흐름과 상태는 로드맵 구조를 설명하고, 실제 다음 작업 선택은 `priority-queue.md`의 위아래 순서를 우선한다. +- Phase 흐름과 상태는 로드맵 구조를 설명하고, 실제 다음 작업 선택은 `priority-queue.md`의 prefix별 index와 차단 표기를 따른다. - `priority-queue.md`는 순서 전용 문서이며, 상태, 목표, 범위, 잠금, 기능, 완료 근거는 각 Milestone 문서를 원본으로 삼는다. -- `priority-queue.md` 항목은 Milestone 제목 링크와 식별용 한 줄 설명만 둔다. +- `priority-queue.md` 항목은 `[prefix-NN]`을 포함한 Milestone 제목 링크, 1~2문장 설명, 필요한 `선행 차단`/`동시 차단` 예외만 둔다. - `priority-queue.md`는 로드맵 생성 시 함께 만들며, 실행 후보가 없을 때도 문서와 `실행 순서` 섹션은 유지한다. -- `priority-queue.md`는 사용자가 순서 조정을 요청한 경우, Milestone archive 시 완료 항목 제거가 필요한 경우, 큐에 있는 Milestone이 폐기, 경로 변경, split/merge, 또는 실행 의미가 바뀔 정도로 수정된 경우에만 재정렬한다. +- 같은 prefix의 작은 index는 큰 index보다 먼저 실행하고, 다른 prefix는 차단 표기가 없으면 병렬 실행할 수 있다. 여러 열린 prefix 중 문서상 위쪽 그룹은 기본 선택 tie-breaker다. +- `priority-queue.md`는 사용자가 순서 조정을 요청한 경우, Milestone archive 시 완료 항목과 충족된 차단 참조 제거가 필요한 경우, 큐에 있는 Milestone이 폐기, 경로 변경, split/merge, 또는 실행 의미가 바뀔 정도로 수정된 경우에만 재정렬한다. - `priority-queue.md`의 링크가 깨졌으면 활성 Milestone 문서를 기준으로 큐를 재정렬하거나 재생성한다. ## 전체 목표 diff --git a/agent-ops/skills/common/analyze-roadmap-position/SKILL.md b/agent-ops/skills/common/analyze-roadmap-position/SKILL.md index 9debffd9..6e504efb 100644 --- a/agent-ops/skills/common/analyze-roadmap-position/SKILL.md +++ b/agent-ops/skills/common/analyze-roadmap-position/SKILL.md @@ -1,7 +1,8 @@ --- name: analyze-roadmap-position -version: 1.13.0 -description: "여러 레포를 전환할 때 코드/git 분석 없이 priority-queue 실행 순서와 ROADMAP > Phase > Milestone > current 현지점을 링크 달린 흐름 목록으로 빠르게 보여주는 읽기 전용 스킬" +metadata: + version: "1.14.0" +description: "여러 레포를 전환할 때 코드/git 분석 없이 priority-queue 실행 순서와 ROADMAP → Phase → Milestone → current 현지점을 링크 달린 흐름 목록으로 빠르게 보여주는 읽기 전용 스킬" --- # 로드맵 현지점 @@ -10,7 +11,7 @@ description: "여러 레포를 전환할 때 코드/git 분석 없이 priority-q 여러 레포를 병렬 운용하다가 돌아왔을 때, 현재 작업이 전체 로드맵의 어느 Phase와 Milestone에 있는지 빠르게 보여준다. 기본 출력은 전역 Milestone 실행 순서, `로드맵 > Phase > Milestone` breadcrumb, 전체 Phase 흐름, 현재 Phase의 Milestone 흐름이다. -Phase 흐름은 실행 순서가 아니라 도메인/책임 영역의 구조적 지도이며, 다음 작업 후보는 `priority-queue.md` 순서를 우선한다. +Phase 흐름은 실행 순서가 아니라 도메인/책임 영역의 구조적 지도이며, 다음 작업 후보는 `priority-queue.md`의 prefix별 index와 차단 예외를 우선한다. 코드 진행도 감사, git diff 분석, 테스트 근거 확인, 남은 작업 정밀 판정은 기본 책임이 아니다. ## 언제 호출할지 @@ -39,8 +40,9 @@ Phase 흐름은 실행 순서가 아니라 도메인/책임 영역의 구조적 2. `agent-ops/skills/common/_templates/roadmap-position-report-template.md`를 읽는다. 3. 로컬 `agent-roadmap/current.md`를 확인한다. - 없으면 로컬 current 없음으로 보고하고, `priority-queue.md`가 있으면 전역 실행 순서와 `ROADMAP.md`의 `Phase 흐름`을 보여준다. -4. `agent-roadmap/priority-queue.md`가 있으면 `실행 순서` 항목을 읽어 전역 Milestone 실행 순서 목록을 만든다. - - 각 항목은 순번, Milestone 제목 링크, 식별용 한 줄 설명만 남긴다. +4. `agent-roadmap/priority-queue.md`가 있으면 `실행 순서` 항목을 읽어 prefix별 Milestone 실행 lane 목록을 만든다. + - 각 항목은 `[prefix-NN]`, Milestone 제목 링크, 1~2문장 설명, `선행 차단`과 `동시 차단`을 그대로 남긴다. + - 같은 prefix의 작은 active index를 lane head로 표시하고, 다른 prefix의 head는 차단이 없으면 병렬 가능 후보로 표시한다. - 상태, 잠금, 목표, 기능 Task는 각 Milestone 문서 원본을 읽기 전에는 추정하지 않는다. - archive 링크가 있거나 링크가 깨진 것으로 보이면 `큐 정리 필요`로 표시하고 archive 문서는 읽지 않는다. - 파일이 없으면 `전역 실행 순서: 없음`으로 출력한다. @@ -100,7 +102,7 @@ Phase 흐름은 실행 순서가 아니라 도메인/책임 영역의 구조적 - 현재 후보의 역할 태그는 `선행 스케치`, `다음 구현 계획`, `검토 후보`, `보류 후보`처럼 짧게 쓰되 SDD 상태를 역할 태그에 넣지 않는다. - 현재 후보에 `SDD 문서` 링크/경로가 있으면 Milestone 아래에 SDD 링크를 배치한다. `USER_REVIEW.md`가 있으면 그 링크도 SDD 아래에 배치한다. - 문서 포인터는 항상 `[표시 제목](상대경로)` Markdown 링크로 출력한다. 파일이 없어도 raw path만 쓰지 말고 `SDD_LINK (파일 없음)`처럼 링크와 상태를 함께 쓴다. -- `전역 마일스톤 실행 순서`에는 `priority-queue.md`의 항목 순서를 그대로 출력한다. Milestone 상태나 잠금은 각 Milestone 문서를 읽지 않았다면 출력하지 않는다. +- `전역 마일스톤 실행 순서`에는 `priority-queue.md`의 prefix 그룹, index, 설명, blocker를 그대로 출력한다. Milestone 상태나 구현 잠금은 각 Milestone 문서를 읽지 않았다면 출력하지 않는다. - 로드맵이 없는 프로젝트에서는 로드맵 없음으로 짧게 보고하고 템플릿을 억지로 채우지 않는다. - 로컬 `current.md`가 없으면 `local current: 없음`으로 출력하고, `[current.md](agent-roadmap/current.md)` 링크를 만들지 않는다. diff --git a/agent-ops/skills/common/complete-milestone/SKILL.md b/agent-ops/skills/common/complete-milestone/SKILL.md index cb0cc44e..07dd53bf 100644 --- a/agent-ops/skills/common/complete-milestone/SKILL.md +++ b/agent-ops/skills/common/complete-milestone/SKILL.md @@ -80,7 +80,7 @@ description: "마일스톤 완료해도 될지 검토, 현 마일스톤 종료 7. **다음 Milestone 지정** - `next-milestone`이 있으면 활성 Milestone에서 정확히 하나인지 확인하고 `current.md`에 반영한다. - - 없고 `priority-queue.md`가 있으면 큐의 위에서 아래 순서 중 완료/archive 대상이 아니고 `[폐기]`가 아닌 첫 활성 Milestone을 다음 후보로 찾는다. + - 없고 `priority-queue.md`가 있으면 각 prefix의 가장 작은 active index 중 `선행 차단`이 없고, 현재 진행 중인 `동시 차단` target이 없는 lane head를 다음 후보로 찾는다. 여러 후보가 열리면 방금 완료한 prefix의 다음 항목을 우선하고, 없으면 queue group 순서를 tie-breaker로 쓴다. - `priority-queue.md`가 없으면 같은 Phase의 Milestone 흐름에서 완료/폐기/archive가 아닌 다음 후보를 찾는다. - 후보가 없거나 둘 이상이면 자동 지정하지 않고 후보와 이유를 보고한다. - 다음 후보가 `[스케치]`이면 구현 대상이 아니라 구체화 대상임을 보고한다. @@ -98,7 +98,7 @@ description: "마일스톤 완료해도 될지 검토, 현 마일스톤 종료 - [ ] `agent-spec/`가 있으면 `update-spec` 결과를 확인하고 완료 진행 가능 상태가 `Spec updated` 또는 `Spec update not needed`인지 판단했는가 - [ ] `Spec blocked` 또는 `create-spec needed` 상태에서 Milestone 완료/archive를 하지 않았는가 - [ ] `update-roadmap` 완료/archive 규칙과 workspace lock 규칙을 따랐는가 -- [ ] `priority-queue.md`가 있으면 완료/archive된 Milestone이 제거되었고 다음 후보 판단에 큐 순서가 반영되었는가 +- [ ] `priority-queue.md`가 있으면 완료/archive된 Milestone과 충족된 blocker 참조가 제거되었고 다음 후보 판단에 prefix index와 차단 예외가 반영되었는가 - [ ] 완료 Milestone이 `current.md`에 남아 있지 않은가 - [ ] 다음 Milestone 지정이 모호하면 자동 선택하지 않았는가 - [ ] `git diff --check`를 실행했는가 diff --git a/agent-ops/skills/common/create-roadmap/SKILL.md b/agent-ops/skills/common/create-roadmap/SKILL.md index 621da02d..695145a4 100644 --- a/agent-ops/skills/common/create-roadmap/SKILL.md +++ b/agent-ops/skills/common/create-roadmap/SKILL.md @@ -9,7 +9,7 @@ description: AI-first 개인/소규모 프로젝트의 전체 목표, Phase scaf `agent-roadmap/` 하위에 `Roadmap -> priority-queue -> Phase -> Milestone` 기반 한국어 로드맵 구조를 처음 생성한다. 전체 로드맵은 전체 방향과 Phase index만 담당하고, 일반 작업에서는 브랜치별 로컬 `current.md`의 활성 Phase/Milestone 링크와 관련 문서만 읽도록 만든다. -`priority-queue.md`는 Phase를 가로지르는 실행 순서만 담당한다. +`priority-queue.md`는 Phase를 가로지르는 prefix별 실행 순서와 막히는 지점의 차단 예외만 담당한다. Milestone은 구현 계획이 아니라 방향성, 범위, 위험, 확인 필요 사항을 기록하는 협업 문서다. Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `기능` 안에서 관리한다. 별도 `완료 기준` 섹션은 만들지 않고, 검증이 필요한 기능에만 같은 Task 안의 `검증:` 문구로 통합한다. @@ -59,7 +59,7 @@ agent-roadmap/ | 파일 | 역할 | |------|------| | `agent-roadmap/ROADMAP.md` | 전체 목표와 Phase 흐름만 담는 최상위 지도. 로드맵 생성/갱신/Phase 전환 때만 읽는다 | -| `agent-roadmap/priority-queue.md` | Phase를 가로지르는 Milestone 실행 순서만 담는 순서 전용 문서 | +| `agent-roadmap/priority-queue.md` | Phase를 가로지르는 prefix별 Milestone 순서, 설명, 차단 예외를 담는 실행 순서 문서 | | `agent-roadmap/current.md` | 활성 Phase와 활성 Milestone 후보, 선택 규칙을 담는 브랜치별 로컬 포인터 | | `agent-roadmap/phase//PHASE.md` | Phase 목표, 상태, Milestone 흐름, Phase 경계를 담는 문서 | | `agent-roadmap/phase//milestones/.md` | 일반 작업 시 읽는 Milestone 단위 목표, 스케치 승격 조건, 구현 잠금, 범위, 기능 Epic/Task 체크리스트, 범위 제외 항목 | @@ -78,7 +78,7 @@ agent-roadmap/ - SDD 본문은 `agent-ops/skills/common/_templates/roadmap-sdd-template.md` 형식을 따른다. - SDD 사용자 리뷰는 `agent-ops/skills/common/_templates/roadmap-sdd-user-review-template.md` 형식을 따른다. - `ROADMAP.md`에는 Milestone 상세 체크리스트를 넣지 않는다. -- `priority-queue.md`는 순서 전용 문서이며, Milestone 제목 링크와 식별용 한 줄 설명만 둔다. +- `priority-queue.md`는 `[prefix-NN]` 제목 링크, 1~2문장 설명, 필요한 `선행 차단`/`동시 차단`만 둔다. - `current.md`는 git 추적 대상이 아니며, 예시 파일을 `agent-roadmap/`에 따로 만들지 않는다. - `current.md`는 활성 Phase/Milestone 후보만 담고, 개인별 현재 작업 위치나 완료 상태를 적지 않는다. - archive 경로는 `current.md`의 활성 항목에 넣지 않는다. @@ -89,15 +89,17 @@ agent-roadmap/ - 상태 표기는 `[스케치]`, `[계획]`, `[진행중]`, `[검토중]`, `[완료]`, `[보류]`, `[폐기]` 중 하나만 사용한다. - `[스케치]`는 방향성, 문제의식, 후보 범위, 미정 질문을 기록하는 컨셉 상태다. 구현 가능한 계획이 아니므로 구현 계획 생성 대상이 아니다. - `[계획]`은 목표, 범위, 기능 Task, 구현 잠금, 결정 필요 항목이 문서화되어 잠금 해제 후 구현 계획을 만들 수 있는 상태다. -- Phase와 Milestone 이름, 파일명에는 `1`, `2`, `M01`, `P1` 같은 순번을 붙이지 않는다. +- Phase 이름과 파일명, Milestone 파일명에는 `1`, `2`, `M01`, `P1` 같은 순번을 붙이지 않는다. Milestone 표시 제목에는 실행 태그 `[prefix-NN]`을 반드시 붙인다. - Phase 흐름은 실행 순서가 아니라 도메인/책임 영역의 구조적 지도다. -- Phase를 가로지르는 실제 실행 순서는 `priority-queue.md`의 위에서 아래 순서로 표현한다. -- `priority-queue.md`에는 상태, 목표, 범위, 잠금, 기능, 완료 근거, 의존성 필드를 복제하지 않는다. +- Phase를 가로지르는 실제 실행 순서는 `priority-queue.md`의 prefix 그룹과 두 자리 index로 표현한다. 같은 prefix는 작은 index부터 순차 실행하고, 다른 prefix는 차단 표기가 없으면 병렬 실행할 수 있다. +- `priority-queue.md`에는 상태, 목표, 범위, 잠금, 기능, 완료 근거를 복제하지 않는다. 설명은 생략하지 않고, 일반 순서로 표현할 수 없는 차단 예외만 exact blocker label로 둔다. - 실행 후보가 없더라도 `priority-queue.md` 파일과 `실행 순서` 섹션은 생성한다. - Phase 파일명은 `agent-roadmap/phase//PHASE.md`로 만든다. - Milestone 파일명은 `agent-roadmap/phase//milestones/.md`로 만든다. - ``와 ``는 소문자 영문, 숫자, 하이픈만 사용하고, 공백/언더스코어/순번 prefix를 넣지 않는다. - 중간에 Phase나 Milestone을 끼워 넣을 수 있도록 기존 항목의 이름과 파일명을 불필요하게 바꾸지 않는다. +- 실행 태그는 `^[a-z][a-z0-9-]*-[0-9]{2}$` 형태로 만들고 프로젝트 안에서 유일하게 유지한다. 같은 작업 lane은 같은 prefix로 묶고, 관련성만 있고 순차 관계가 없으면 다른 prefix를 사용한다. +- 실행 태그 재배치가 필요하면 파일명은 유지하고 Milestone H1, `PHASE.md`, 로컬 `current.md`, `priority-queue.md`와 queue blocker 참조만 함께 바꾼다. - 로드맵 문서 안에서 다른 로드맵 문서, SDD, `USER_REVIEW.md`, archive 문서를 가리킬 때는 raw path만 쓰지 말고 `[표시 제목](상대경로)` Markdown 링크로 쓴다. - 문서 안의 링크 target은 링크를 작성하는 Markdown 파일 위치 기준 상대경로로 쓴다. 예: `ROADMAP.md`와 `current.md`에서는 `[PHASE.md](phase//PHASE.md)`, Phase 문서에서는 `[Milestone](milestones/.md)`, Milestone 문서에서는 `[ROADMAP.md](../../../ROADMAP.md)`와 `[PHASE.md](../PHASE.md)`를 쓴다. - `경로:`, `Phase:`, `Milestone:`, `SDD 문서:` 같은 필드명을 유지해야 해도 값은 `경로: [PHASE.md](phase//PHASE.md)`처럼 링크로 작성한다. @@ -107,6 +109,7 @@ agent-roadmap/ ## Milestone 작성 규칙 - Milestone 기본 섹션은 `위치`, `목표`, `상태`, `구현 잠금`, `범위`, `기능`, `완료 리뷰`, `범위 제외`, `작업 컨텍스트`다. +- Milestone H1은 `# Milestone: [prefix-NN] ` 형식으로 작성한다. scheduling 관계는 `priority-queue.md`를 원본으로 두고 Milestone `작업 컨텍스트`에는 queue 링크만 둔다. - `승격 조건`은 `[스케치]` Milestone에서 필수다. `[계획]` 이상 상태에서는 섹션을 생략하거나 `- 없음`으로 둘 수 있다. - `[스케치]` Milestone은 `승격 조건`을 체크리스트로 작성하고, `[계획]`으로 전환하기 위해 필요한 정의, 결정, 경계, 후속 구현 Milestone 후보를 적는다. - 새 Milestone은 에이전트가 확정할 수 없는 제품 방향, 범위, 우선순위, 책임 경계가 남아 있으면 `구현 잠금`을 `잠금`으로 둔다. @@ -159,7 +162,7 @@ agent-roadmap/ 4. **파일 생성** - `ROADMAP.md`, `priority-queue.md`, 로컬 `current.md`, 각 Phase의 `PHASE.md`, 각 Milestone 문서를 템플릿 순서대로 생성한다. - `ROADMAP.md` 최상단에는 `priority-queue.md`를 먼저 확인하도록 `고정 실행 순서` 섹션을 둔다. - - `priority-queue.md`에는 Phase를 가로지르는 실행 후보 Milestone을 위에서 아래 순서로 둔다. 후보가 없으면 `실행 순서` 섹션만 비워 둔다. + - `priority-queue.md`에는 실행 후보를 prefix별 `### ` 그룹으로 묶고 index 오름차순으로 둔다. 각 항목의 설명 1~2문장을 유지하고, 다른 prefix의 필수 선행은 `선행 차단`, 실제 동시 충돌은 낮은 우선순위 쪽 `동시 차단`으로만 둔다. 후보가 없으면 `실행 순서` 섹션만 비워 둔다. - 활성 Phase와 활성 Milestone은 `current.md`에 모두 기록한다. - `.gitignore`의 Agent-Ops 관리 block에 `agent-roadmap/current.md`가 있는지 확인하고 없으면 추가한다. - `ROADMAP.md`의 Phase 흐름에는 완료/검토중/진행중/계획/스케치 Phase 모두를 상태 그룹별로 정리한다. 이 순서는 실행 우선순위가 아니며, 실제 다음 작업 선택은 `priority-queue.md`를 따른다. @@ -173,7 +176,7 @@ agent-roadmap/ 5. **검증** - 생성한 링크가 실제 파일을 가리키는지 확인한다. - `priority-queue.md`가 존재하고 `실행 순서` 섹션이 있는지 확인한다. - - `priority-queue.md`의 모든 링크가 활성 Milestone 파일을 가리키는지 확인한다. 실행 후보가 없어서 빈 큐이면 정상으로 보고하되, 활성 실행 후보가 있는데 비어 있으면 큐 동기화 필요로 본다. + - `priority-queue.md`의 모든 링크가 활성 Milestone 파일을 가리키고, 실행 태그가 유일하며, group prefix와 tag prefix가 일치하고, 같은 prefix index가 오름차순인지 확인한다. blocker는 다른 active tag만 참조하고 같은 prefix 정상 순서를 중복하지 않아야 한다. 실행 후보가 없어서 빈 큐이면 정상으로 보고하되, 활성 실행 후보가 있는데 비어 있으면 큐 동기화 필요로 본다. - 생성한 로드맵 문서의 문서/산출물 포인터가 raw path만 남지 않고 Markdown 링크로 작성되었는지 확인한다. - 생성한 로드맵 문서의 Markdown 링크 target에 템플릿 placeholder가 남지 않았는지 확인한다. - 로컬 `current.md` 활성 항목에 `agent-roadmap/archive/**` 경로가 없는지 확인한다. @@ -221,11 +224,11 @@ agent-roadmap/ - 기존 `agent-roadmap/` 파일을 덮어쓰지 않는다. - 일반 작업마다 전체 `ROADMAP.md`를 읽도록 규칙을 만들지 않는다. -- `priority-queue.md`를 두 번째 로드맵처럼 사용하지 않는다. 상태, 목표, 범위, 잠금, 기능, 완료 근거를 복제하지 않는다. +- `priority-queue.md`를 두 번째 로드맵처럼 사용하지 않는다. 상태, 목표, 범위, 잠금, 기능, 완료 근거를 복제하지 않되, 항목 설명과 최소 차단 예외는 생략하지 않는다. - `priority-queue.md`에 archive Milestone 링크를 넣지 않는다. - 로컬 `current.md`에 `agent-roadmap/archive/**` 경로를 넣지 않는다. - `agent-roadmap/current.md`를 git 추적 대상으로 만들지 않는다. -- Phase와 Milestone 이름 또는 파일명에 순번을 강제하지 않는다. +- Phase 이름/파일명이나 Milestone 파일명에 순번을 강제하지 않는다. Milestone 표시 제목의 `[prefix-NN]` 실행 태그는 예외다. - `ROADMAP.md`에 Milestone 상세 작업 체크리스트를 넣지 않는다. - Epic과 Task를 별도 파일로 분리하지 않는다. - Milestone 문서에서 `구현 잠금` 섹션을 생략하지 않는다. diff --git a/agent-ops/skills/common/plan/SKILL.md b/agent-ops/skills/common/plan/SKILL.md index 59b1ac14..66626d1f 100644 --- a/agent-ops/skills/common/plan/SKILL.md +++ b/agent-ops/skills/common/plan/SKILL.md @@ -157,9 +157,11 @@ If the selected review already has an appended verdict, accept it only in `prepa 로드맵 확인: - `agent-roadmap/current.md`는 브랜치별 로컬 포인터다. 있으면 구현 계획 파일을 만들기 전에 읽고, 사용자 요청, 브랜치, 변경 경로를 기준으로 관련 Phase와 Milestone을 선택한다. -- `agent-roadmap/priority-queue.md`가 있으면 명시 target이 없는 구현 계획에서 Phase를 가로지르는 후보 순서를 확인하기 위해 읽는다. 큐 순서는 우선순위 참고이며, 상태/잠금/기능 원본은 각 Milestone 문서다. -- 사용자가 target Milestone을 명시하지 않았고 요청이 "다음 작업" 또는 일반 구현 계획이면 `priority-queue.md`의 위에서 아래 순서 중 요청과 맞고 활성 경로에 존재하는 첫 Milestone을 우선 후보로 둔다. -- `priority-queue.md` 링크가 깨졌으면 Milestone을 추측해 계획하지 말고 `update-roadmap`으로 큐 재정렬/재생성이 필요하다고 보고한다. +- `agent-roadmap/priority-queue.md`가 있으면 명시 target이 없는 구현 계획에서 prefix별 후보와 차단 예외를 확인하기 위해 읽는다. 상태/잠금/기능 원본은 각 Milestone 문서다. +- 각 prefix에서 가장 작은 active index 하나만 lane head 후보로 둔다. `선행 차단`이 남은 후보는 제외하고, `동시 차단` target이 현재 실행 중이면 제외한다. 다른 prefix의 열린 head들은 병렬 후보이며 문서상 위쪽 group은 target 없는 "다음 작업"의 tie-breaker로만 쓴다. +- 사용자가 Milestone을 명시해도 같은 prefix의 더 작은 active index, `선행 차단`, 현재 진행 중인 `동시 차단` target이 있으면 plan을 만들지 않고 실행 순서 차단을 보고한다. +- queue의 설명은 후보 이해에 유지하되 scheduling 판단에는 tag, link target, exact `선행 차단`/`동시 차단` label만 사용한다. +- `priority-queue.md` 링크, 실행 태그, group-prefix, blocker 참조가 깨졌으면 Milestone을 추측해 계획하지 말고 `update-roadmap`으로 큐 정리가 필요하다고 보고한다. - `agent-roadmap/`이 있는데 `current.md`가 없으면 `agent-ops/skills/common/_templates/roadmap-current-template.md` 형식으로 로컬 파일을 만들거나, `ROADMAP.md`의 Phase 흐름과 관련 `PHASE.md`에서 후보를 고른 뒤 로컬 current를 채운다. current 없음만으로 일반 task routing으로 빠지지 않는다. - `current.md`가 `agent-roadmap/archive/**`를 가리키면 해당 문서는 읽지 말고 활성 Phase/Milestone이 아니라고 보고한다. - 선택한 Phase를 한 번 읽어 Phase 목표, Milestone 흐름, Phase 경계를 확인한다. diff --git a/agent-ops/skills/common/update-roadmap/SKILL.md b/agent-ops/skills/common/update-roadmap/SKILL.md index 56f39325..5147b221 100644 --- a/agent-ops/skills/common/update-roadmap/SKILL.md +++ b/agent-ops/skills/common/update-roadmap/SKILL.md @@ -11,7 +11,7 @@ description: 로드맵 업데이트, 로드맵에 추가, 마일스톤 추가· 표준 구조는 `ROADMAP.md -> priority-queue.md -> phase//PHASE.md -> phase//milestones/.md`다. archive도 같은 Phase scaffold를 유지하며 `archive/phase//...` 아래에 둔다. 로드맵 전체를 매 작업마다 읽지 않도록 유지하면서, 브랜치별 로컬 `current.md`의 활성 Phase와 활성 Milestone 창이 실제 작업 후보 목록으로 동작하게 한다. -`priority-queue.md`는 Phase를 가로지르는 실행 순서만 담당하며, Milestone 상세 정보는 복제하지 않는다. +`priority-queue.md`는 Phase를 가로지르는 prefix별 실행 순서, 설명, 최소 차단 예외만 담당하며 Milestone 상세 정보는 복제하지 않는다. Milestone은 구현 계획이 아니라 방향성, 범위, 위험, 확인 필요 사항을 기록하는 협업 문서로 유지한다. Epic과 Task는 별도 파일로 분리하지 않고 Milestone 문서의 `기능` 안에서 관리한다. 별도 `완료 기준` 섹션은 만들지 않고, 검증이 필요한 기능에만 같은 Task 안의 `검증:` 문구로 통합한다. @@ -86,7 +86,7 @@ agent-roadmap/ ``` - `ROADMAP.md`는 전체 목표와 Phase 흐름, `priority-queue.md` 고정 라우팅만 담는다. -- `priority-queue.md`는 Phase를 가로지르는 Milestone 실행 순서만 담는다. 항목은 Milestone 제목 링크와 식별용 한 줄 설명만 둔다. +- `priority-queue.md`는 Phase를 가로지르는 prefix별 Milestone 실행 순서와 차단 예외를 담는다. 항목은 `[prefix-NN]` 제목 링크, 1~2문장 설명, 필요한 exact blocker label만 둔다. - `PHASE.md`는 해당 Phase의 목표, 상태, Milestone 흐름, Phase 경계를 담는다. - Milestone 문서는 해당 Phase 하위 `milestones/`에 둔다. - 완료된 Phase는 `archive/phase//PHASE.md`로 이동하고, 하위 Milestone도 같은 archive Phase scaffold 아래에 둔다. @@ -100,7 +100,16 @@ agent-roadmap/ - `current.md`는 git 추적 대상이 아니며, 공유 진행 상태는 `ROADMAP.md`, `PHASE.md`, Milestone 문서, `.agent-roadmap-sync/locks.yaml`에 기록한다. - `current.md`에는 archive 경로를 넣지 않는다. - `current.md`에는 `[완료]` 또는 `[폐기]` Phase/Milestone을 남기지 않는다. 완료 후보는 완료 근거와 archive 전환이 정리될 때까지 `[검토중]`으로 둔다. -- `priority-queue.md`에는 archive 경로를 넣지 않는다. 완료 Milestone은 archive 시 제거하고, 폐기 Milestone은 큐에서 제거한다. +- `priority-queue.md`에는 archive 경로를 넣지 않는다. 완료 Milestone은 archive 시 항목과 충족된 `선행 차단` 참조를 제거하고, 폐기 Milestone은 큐에서 제거한다. + +## 실행 태그와 차단 예외 + +- 실행 태그는 `[prefix-NN]` 형식이며 내부 값은 `^[a-z][a-z0-9-]*-[0-9]{2}$`를 따른다. 같은 prefix는 동일 작업 lane, `NN`은 그 lane 안의 선후 순서다. +- 같은 prefix의 항목은 `### ` 그룹에 모아 index 오름차순으로 둔다. 더 작은 active index가 기본 선행이므로 blocker로 중복하지 않는다. +- 다른 prefix는 기본 병렬이다. 반드시 다른 lane 완료를 기다리는 지점만 exact label `선행 차단:`과 backtick tag 목록으로, 실제 동시 실행 충돌만 낮은 우선순위 항목의 exact label `동시 차단:`과 backtick tag 목록으로 둔다. +- blocker target은 같은 queue의 active tag여야 한다. 프로젝트 간 잠금은 queue tag로 대체하지 않고 `.agent-roadmap-sync/locks.yaml`을 사용한다. +- 실행 태그는 scheduling label이고 Milestone link target/slug는 identity다. 재index해도 파일명을 바꾸지 않으며, H1, 활성 Phase/current 표시, queue 제목과 blocker 참조만 원자적으로 갱신한다. +- Milestone 본문의 선행/후속 설명은 scheduling source가 아니다. 갱신 범위에서는 `작업 컨텍스트`에 `priority-queue.md` 링크와 관련 Milestone 설명만 남긴다. ## 상태와 id @@ -304,7 +313,7 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다 - 대상 파일을 `agent-roadmap/phase//milestones/.md`에서 `agent-roadmap/archive/phase//milestones/.md`로 이동한다. - 활성 SDD 디렉터리 `agent-roadmap/sdd///`가 있으면 `agent-roadmap/archive/sdd///`로 이동한다. `USER_REVIEW.md`가 남아 있으면 archive하지 말고 해결 필요로 보고한다. - 활성 `PHASE.md`의 Milestone 흐름에는 `[완료]` 또는 `[폐기]` 항목을 남기고, 경로는 archive 경로로 바꾼다. -- `priority-queue.md`가 있으면 대상 Milestone의 활성 경로 항목을 제거한다. archive 경로로 바꿔 남기지 않는다. +- `priority-queue.md`가 있으면 대상 Milestone의 활성 경로 항목과 해당 실행 태그를 가리키는 충족된 `선행 차단` 참조를 제거한다. `동시 차단` 참조는 target이 더는 active하지 않으므로 함께 제거한다. archive 경로로 바꿔 남기지 않는다. - 로컬 `current.md`의 활성 Milestone에서는 제거한다. - `ROADMAP.md`는 Phase 상태나 경로가 바뀌지 않으면 수정하지 않는다. - 이동한 archive 문서는 스냅샷으로 보존하고 최신 템플릿에 맞춰 재포맷하지 않는다. @@ -363,8 +372,9 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다 5. **변경 내용 작성** - `ROADMAP.md`는 전체 목표, Phase 흐름, 로딩 정책이 바뀔 때만 수정한다. - `priority-queue.md`가 없고 로드맵 구조를 표준화하거나 생성/동기화하는 요청이면 `roadmap-priority-queue-template.md` 형식으로 만든다. - - `priority-queue.md`는 사용자 순서 조정 요청, archive/폐기 제거, 경로 변경, split/merge, 실행 의미 변경, 깨진 링크 복구 때만 수정한다. - - `priority-queue.md`를 수정할 때는 Milestone 제목 링크와 식별용 한 줄 설명만 남기고, 상태, 목표, 범위, 잠금, 기능, 완료 근거, 의존성 필드를 복제하지 않는다. + - `priority-queue.md`는 사용자 순서 조정 요청, archive/폐기 제거, 경로 변경, split/merge, 실행 의미 변경, 깨진 링크·태그·차단 참조 복구 때만 수정한다. + - `priority-queue.md`를 수정할 때는 prefix 그룹, `[prefix-NN]` Milestone 제목 링크, 1~2문장 설명, 필요한 blocker 줄을 유지하고 상태, 목표, 범위, 잠금, 기능, 완료 근거는 복제하지 않는다. + - 새 Milestone은 관련 lane이 있으면 같은 prefix의 적절한 index를 할당하고, 순차 관계가 없으면 새 prefix를 만든다. 중간 삽입으로 재index가 필요하면 경로는 유지하고 모든 표시 제목과 queue blocker 참조를 같은 변경에서 갱신한다. - 로컬 `current.md`는 활성 Phase/Milestone 창이 바뀔 때 수정한다. - `.gitignore`의 Agent-Ops 관리 block에 `agent-roadmap/current.md`가 있는지 확인하고 없으면 추가한다. - `PHASE.md`는 Phase 목표, 상태, Milestone 흐름, Phase 경계가 바뀔 때 수정한다. @@ -403,6 +413,9 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다 - 로컬 `current.md`의 활성 항목이 `[완료]` 또는 `[폐기]` 상태로 남아 있지 않은지 확인한다. - `agent-roadmap/current.md`가 git 추적 대상으로 남아 있지 않은지 확인한다. - `agent-roadmap/priority-queue.md`가 있으면 `실행 순서` 섹션이 있고 모든 링크가 실제 활성 Milestone 파일을 가리키는지 확인한다. + - queue 실행 태그가 유일하고 두 자리 index 형식이며 group prefix와 일치하는지, 같은 prefix가 오름차순인지, 각 항목에 1~2문장 설명이 있는지 확인한다. + - `선행 차단`/`동시 차단` 외 blocker label이 없는지, 모든 target이 active tag로 해석되는지, 같은 prefix 기본 순서를 `선행 차단`으로 중복하지 않았는지 확인한다. + - queue tag가 Milestone H1, 활성 `PHASE.md`, 로컬 `current.md`의 표시 제목과 일치하는지 확인한다. tag 불일치는 파일 slug로 추정 보정하지 않고 검증 실패로 보고한다. - `priority-queue.md`에 archive 경로, `[완료]` archive 대상, `[폐기]` Milestone 항목이 남아 있지 않은지 확인한다. - `priority-queue.md`가 비어 있는데 활성 실행 후보가 있으면 큐 동기화 필요로 보고한다. 실행 후보가 없으면 빈 큐를 허용한다. - `ROADMAP.md`의 Phase 경로가 실제 `PHASE.md` 파일을 가리키는지 확인한다. @@ -486,16 +499,16 @@ target 없는 신규 추가 요청은 append가 아니라 upsert로 처리한다 - evidence 없이 Phase, Milestone, Epic, Task를 `[완료]` 또는 `[검토중]`으로 처리하지 않는다. - 전체 `ROADMAP.md`를 모든 작업의 필수 로딩 파일로 만들지 않는다. - `ROADMAP.md`에 Milestone 상세 작업 체크리스트를 남기지 않는다. -- `priority-queue.md`에 상태, 목표, 범위, 잠금, 기능, 완료 근거, 의존성 필드를 복제하지 않는다. +- `priority-queue.md`에 상태, 목표, 범위, 잠금, 기능, 완료 근거를 복제하지 않는다. 1~2문장 설명과 최소 blocker 예외는 삭제하지 않는다. - `priority-queue.md`에 archive 경로를 남기지 않는다. -- 사용자 순서 조정 요청 없이 `priority-queue.md`의 순서를 에이전트 판단만으로 바꾸지 않는다. 단, archive/폐기 제거, 경로 변경, split/merge, 실행 의미 변경, 깨진 링크 복구는 예외다. +- 사용자 순서 조정 요청 없이 `priority-queue.md`의 그룹/index/차단 관계를 에이전트 판단만으로 바꾸지 않는다. 단, archive/폐기 제거, 경로 변경, split/merge, 실행 의미 변경, 깨진 링크·태그·차단 참조 복구는 예외다. - 로컬 `current.md`에 개인별 현재 작업 위치나 완료 상태를 남기지 않는다. - 로컬 `current.md`에 `agent-roadmap/archive/**` 경로를 남기지 않는다. - `agent-roadmap/current.md`를 git 추적 대상으로 만들지 않는다. - archive 문서를 명시 요청 없이 읽거나 최신 템플릿으로 재포맷하지 않는다. - 완료된 Phase/Milestone 기록을 삭제하지 않는다. - Epic과 Task를 별도 파일로 분리하지 않는다. -- Phase와 Milestone 이름 또는 파일명에 순번을 강제하지 않는다. +- Phase 이름/파일명이나 Milestone 파일명에 순번을 강제하지 않는다. Milestone 표시 제목의 `[prefix-NN]` 실행 태그는 예외다. - 에이전트가 확정할 수 없는 결정 항목이 남아 있는데 Milestone의 `구현 잠금`을 `해제`로 바꾸지 않는다. - `구현 잠금`이 남아 있는 Milestone을 `[검토중]`, `[완료]`, 또는 완료 archive 대상으로 전환하지 않는다. 명시적인 폐기 근거가 있는 `[폐기]` archive는 허용한다. - 사용자가 지정한 Phase/Milestone/Epic/Task anchor를 무시하지 않는다. diff --git a/agent-roadmap/ROADMAP.md b/agent-roadmap/ROADMAP.md index f135db4d..04d983e0 100644 --- a/agent-roadmap/ROADMAP.md +++ b/agent-roadmap/ROADMAP.md @@ -4,39 +4,40 @@ - 전역 Milestone 실행 순서는 [전역 마일스톤 실행 순서](priority-queue.md)를 먼저 확인한다. - Phase는 도메인/책임 영역이며 순차 실행 게이트가 아니다. -- Phase 흐름과 상태는 로드맵 구조를 설명하고, 실제 다음 작업 선택은 `priority-queue.md`의 위아래 순서를 우선한다. +- Phase 흐름과 상태는 로드맵 구조를 설명하고, 실제 다음 작업 선택은 `priority-queue.md`의 prefix별 index와 차단 표기를 따른다. - `priority-queue.md`는 순서 전용 문서이며, 상태, 목표, 범위, 잠금, 기능, 완료 근거는 각 Milestone 문서를 원본으로 삼는다. -- `priority-queue.md` 항목은 Milestone 제목 링크와 식별용 한 줄 설명만 둔다. +- `priority-queue.md` 항목은 `[prefix-NN]` Milestone 제목 링크, 1~2문장 설명, 필요한 `선행 차단`/`동시 차단` 예외만 둔다. - `priority-queue.md`는 로드맵 생성 시 함께 만들며, 실행 후보가 없을 때도 문서와 `실행 순서` 섹션은 유지한다. -- 새 실행 후보 Milestone은 생성과 같은 갱신에서 사용자 지정 위치, `작업 컨텍스트 > 큐 배치`의 명시 anchor, 큐 끝 순서로 `priority-queue.md`에 삽입한다. 일반 `선행 작업`과 `후속 작업`은 큐 위치로 해석하지 않는다. +- 새 실행 후보 Milestone은 생성과 같은 갱신에서 같은 작업 lane의 prefix와 index를 배정한다. 같은 prefix의 작은 index는 정상 선행이고, 다른 prefix는 차단 표기가 없으면 병렬 실행할 수 있다. - `[보류]`, `[완료]`, `[폐기]` Milestone은 큐에서 제거하고, `[보류]` Milestone을 실행 후보 상태로 재활성화하면 같은 삽입 규칙을 적용한다. -- 신규 삽입과 연속 순번 재계산은 기존 항목 재정렬로 보지 않는다. 기존 항목끼리의 상대 순서는 사용자가 순서 조정을 요청한 경우, Milestone archive 시 완료 항목 제거가 필요한 경우, 큐에 있는 Milestone이 폐기, 경로 변경, split/merge, 또는 실행 의미가 바뀔 정도로 수정된 경우에만 바꾼다. +- 신규 삽입과 prefix 안의 index 재계산은 기존 파일 경로 변경이 아니다. 실행 태그를 바꾸면 Milestone H1, Phase/current 표시, queue 제목과 blocker 참조만 함께 바꾸며, 파일명은 유지한다. - `priority-queue.md`의 링크가 깨졌으면 활성 Milestone 문서를 기준으로 큐를 재정렬하거나 재생성한다. ## 전체 목표 -IOP(Inference Operations Platform)는 Control Plane - Edge - Node 계층 구조를 기반으로 모델 서빙과 CLI Agent/Automation 실행을 함께 운영하는 실행 오케스트레이션 플랫폼을 만든다. -내부 실행 모델은 `adapter + target`을 기준으로 하며, Edge가 로컬 실행 그룹의 상태와 라우팅을 소유하고 Control Plane은 Edge를 통해 시스템을 관찰하고 제어한다. +IOP(Inference Operations Platform)는 Control Plane - Edge - IOP Node 계층 구조를 기반으로 모델·provider·device의 서빙과 운영을 담당하는 추론 운영 플랫폼을 만든다. +내부 실행 모델은 `adapter + target`을 기준으로 하며, Edge가 로컬 provider 실행 그룹의 상태와 라우팅을 소유하고 Control Plane은 Edge를 통해 IOP 시스템을 관찰하고 제어한다. -IOP는 NomadCode에 종속된 Agent Shell이 아니라, NomadCode와 외부 agent, 운영 CLI, client, 자동화 도구가 함께 소비할 수 있는 범용 추론/자동화 운영 엔진이다. -로드맵 전반에서 OpenAI-compatible API와 Anthropic-compatible Messages API는 외부 클라이언트의 모델 기반 호출 표면으로, A2A API는 외부 agent의 agent-to-agent 작업 위임 표면으로, IOP native protocol은 운영 제어, logical session, background run, command, lifecycle event, remote terminal session 같은 IOP 고유 기능의 기준으로 둔다. +IOP는 특정 agent 제품에 종속된 Shell이 아니라, 외부 agent·client·자동화 도구가 추론 API를 통해 소비할 수 있는 범용 추론 운영 엔진이다. 장기 작업 루프, workspace·terminal orchestration, 스케줄링과 durable review 상태는 IOP의 요청 실행 경계에 포함하지 않는다. +로드맵 전반에서 OpenAI-compatible API와 Anthropic-compatible Messages API는 외부 클라이언트의 모델 기반 호출 표면으로, IOP native protocol은 provider 실행·취소·상태·usage와 provider/device/model lifecycle 같은 IOP 고유 운영 기능의 기준으로 둔다. OpenAI-compatible API는 현재 chat completions baseline을 넘어 Responses API 호환 표면까지 지원해야 한다. Anthropic-compatible Messages API는 Edge가 직접 제공해 Claude Code를 포함한 client가 별도 agent-client gateway 없이 IOP를 호출하게 하며, Chat-only upstream은 IOP의 protocol bridge로 연결한다. -IOP의 외부 실행 호출 계약은 OpenAI-compatible API 방식을 기본 표면으로 채택하고, IOP 고유의 workspace, session, agent, approval, artifact, notification 의미는 별도 `iop` wrapper field가 아니라 `metadata` 또는 IOP native endpoint의 명시 필드로 전달한다. +IOP의 외부 추론 호출 계약은 OpenAI-compatible API 방식을 기본 표면으로 채택하고, model/provider route, 요청 상관관계, usage, 취소·상태처럼 IOP가 소유하는 의미만 제한된 `metadata` 또는 IOP native endpoint의 명시 필드로 전달한다. IOP native protocol은 proto-socket을 기본으로 하며, HTTP는 OpenAI-compatible/A2A/health/bootstrap처럼 필요한 경계에서만 사용한다. -A2A는 표면으로 유지하되, NomadCode가 A2A를 도입하는 시점은 현재 확정하지 않는다. -현재 제1 active delivery는 NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 OpenAI-compatible Responses 요청의 `metadata.workspace`, task/source metadata, 내부 workspace-bound agent 실행 경로를 먼저 안정화하는 것이다. +A2A는 provider-backed 요청을 수용하는 호환 표면으로 유지하며, workflow 의미를 도입하지 않는다. +현재 제1 active delivery는 완료된 `iop-agent` 자산을 Chronos 수용 bundle로 전달한 뒤 IOP의 workspace agent·CLI agent session·terminal 및 Chronos 연결 surface를 제거하고, IOP Node에는 추론 provider 운영에 필요한 경계만 남기는 것이다. 이 분리 작업의 진행 내용은 별도 작업 checkout의 활성 Milestone을 원본으로 동기화한다. +IOP 내부 라우팅 축은 Hot Path에서 request-local 실행 형태와 Edge 라우팅 판단의 기준선을 세운 뒤 단계 호출·검증 최적화, cloud-first 하이브리드 라우팅, routing evidence 기반 local model 전환으로 확장한다. -모델 선택, 로컬/클라우드 라우팅, 모델별 profile, token/속도/품질 최적화, 모델 호출 로그와 품질 평가는 IOP 책임으로 둔다. Control Plane은 principal과 IOP token, 사용자별 provider credential slot의 원장을 소유하고 Edge는 principal별 route와 제한된 credential lease를 실행에 사용한다. +모델 선택, 요청 난이도에 따른 request-local 실행 형태, 로컬/클라우드 라우팅, 모델별 profile, token/속도/품질 최적화, 모델 호출 로그와 품질 평가는 IOP 책임으로 둔다. Edge가 model advisory와 deterministic hard gate를 결합해 최종 route를 확정하고 Node는 확정된 adapter/target stage를 실행한다. Control Plane은 principal과 IOP token, 사용자별 provider credential slot의 원장을 소유하고 Edge는 principal별 route와 제한된 credential lease를 실행에 사용한다. 또한 원격지와 로컬의 Ollama, vLLM, SGLang, Lemonade 같은 추론 엔진은 단순 endpoint가 아니라 provider/device/model 조합으로 관리하고, provider별 lifecycle capability, device 상태, 모델 qualification, 테스트 결과 리포트를 운영 데이터로 축적하는 방향을 목표로 한다. -특히 로컬 모델을 우선 활용하되, cloud fallback과 품질 평가를 결합해 엔터프라이즈 모델 서비스에 가까운 운영 품질을 목표로 한다. +초기 하이브리드 라우팅은 cloud frontier model을 semantic judge/teacher로 활용해 route evidence를 축적하고, 충분한 품질·규모 gate를 통과하면 RAG 기반 local routing model을 운영 기본으로 점진 전환하되 cloud fallback과 품질 평가를 유지한다. RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback은 기본 모델 서빙과 부하 라우팅이 가능해진 뒤 확장한다. ## MVP 경계 -1차 MVP는 다중 Node/디바이스의 model group queue와 추가 provider 검증, provider 요청 사용량·실행 로그와 운영 관측, 사용자/토큰/credential 추적, provider catalog와 로컬 디바이스 상태 관찰, 단계 호출과 runtime schema 검증의 최소 실행 모드를 기준으로 둔다. standalone workflow 알림과 desktop delivery 이력은 Chronos Roadmap이 소유한다. +1차 MVP는 다중 IOP Node/디바이스의 model group queue와 추가 provider 검증, provider 요청 사용량·실행 로그와 운영 관측, 사용자/토큰/credential 추적, provider catalog와 로컬 디바이스 상태 관찰, request-local 단계 호출과 runtime schema 검증의 최소 실행 모드를 기준으로 둔다. standalone workflow, agent automation, terminal과 desktop delivery는 IOP 제품 범위 밖의 별도 제품 축으로 둔다. provider/device/model별 qualification report와 모델 lifecycle 관리는 provider serving 경로와 capacity/concurrency 기준선이 잡힌 뒤 `운영 관측과 Provider 관리` Phase의 후반부에서 깊게 구체화한다. -`(2차)`로 분류한 누적 요청 컨텍스트 최적화, 장기 기억/RAG update loop, advisor와 Context Hook, 특정 Node CLI agent의 원격 터널링, oto 기반 자동화 scheduler/CI-CD, cross-Edge/cloud fallback 고도화는 MVP 이후 스케치로 잠근다. +`(2차)`로 분류한 누적 요청 컨텍스트 최적화, 장기 기억/RAG update loop, advisor와 Context Hook, cross-Edge/cloud fallback 고도화는 IOP MVP 이후 스케치로 잠근다. 특정 Node CLI agent, 원격 터널링과 oto 기반 scheduler/CI-CD는 IOP 후속 후보에서 제외한다. 새로 추가되는 MVP/2차 Milestone은 모두 사용자 검토 전까지 `구현 잠금: 잠금` 상태를 유지하고, 구현 계획이나 세부 API 확정은 별도 구체화 요청에서 다룬다. ## Phase 흐름 @@ -44,7 +45,7 @@ provider/device/model별 qualification report와 모델 lifecycle 관리는 prov Phase는 실행 순서가 아니라 도메인/책임 영역의 구조적 지도다. 완료된 Phase도 로드맵에서 제거하지 않고, archive의 Phase 문서로 연결한다. 상태 그룹은 완료, 검토중, 진행중, 계획, 스케치 순서로 정리해 각 도메인 축의 성숙도와 정리 상태를 읽기 쉽게 한다. -실제 다음 작업 선택은 [전역 마일스톤 실행 순서](priority-queue.md)의 위아래 순서를 우선한다. +실제 다음 작업 선택은 [전역 마일스톤 실행 순서](priority-queue.md)의 prefix별 index와 차단 표기를 따른다. - [완료] Edge-Node 실행 기반 - 경로: [PHASE.md](archive/phase/edge-node-execution-foundation/PHASE.md) @@ -64,7 +65,7 @@ Phase는 실행 순서가 아니라 도메인/책임 영역의 구조적 지도 - [완료] 라우팅 정책과 모델 오케스트레이션 - 경로: [PHASE.md](archive/phase/routing-policy-model-orchestration/PHASE.md) - - 요약: OpenAI-compatible raw tunnel, provider 연동, mixed provider dispatch와 provider capability 기반 passthrough 계약을 완료했다. 최초 요청 workflow 라우팅과 누적 요청 컨텍스트 최적화는 각각 Automation Runtime과 지식·도구 최적화로 분리했다. + - 요약: OpenAI-compatible raw tunnel, provider 연동, mixed provider dispatch와 provider capability 기반 passthrough 계약을 완료했다. 과도하게 결합됐던 과거 Hybrid Routing 스케치는 폐기했지만, IOP Edge의 요청 난이도·실행 형태·local/cloud 판정 책임은 `지식과 도구 최적화 확장` Phase에서 현재 경계에 맞게 복원한다. - [진행중] 운영 관측과 Provider 관리 - 경로: [PHASE.md](phase/operational-observability-provider-management/PHASE.md) @@ -76,11 +77,11 @@ Phase는 실행 순서가 아니라 도메인/책임 영역의 구조적 지도 - [진행중] Automation Runtime과 Bridge 확장 - 경로: [PHASE.md](phase/automation-runtime-bridge/PHASE.md) - - 요약: 완료된 `iop-agent`의 Chronos-owned 자산 선별 이전, IOP standalone surface 제거와 잔류 Node/provider 회귀를 IOP의 최우선 선행 Milestone으로 수행한다. 이 완료 evidence가 Chronos Roadmap의 외부 잠금을 해제한 뒤에만 scoped workflow, local control, managed bridge와 client 제품 작업을 Chronos에서 시작하며, IOP에는 finite provider 실행과 repository-local managed integration 경계만 남긴다. + - 요약: 완료된 `iop-agent`의 source·contract·test·config·state·build·document 자산을 repository-neutral Chronos acceptance bundle로 전부 전달하고 IOP의 관련 surface와 의존성을 제거하는 작업을 최우선 선행 Milestone으로 수행한다. 이 완료 evidence가 Chronos Roadmap의 외부 잠금을 해제한 뒤에만 실제 repository import와 Chronos Server/Node의 작업 루프·agent·terminal 제어를 시작하며, IOP Node에는 추론 provider 운영 경계만 남기고 Chronos 연결점을 두지 않는다. - [계획] 지식과 도구 최적화 확장 - 경로: [PHASE.md](phase/knowledge-tool-optimization-extension/PHASE.md) - - 요약: 단계 호출, tool/schema 강제, 검증/retry/fallback의 MVP 실행 모드와 Gemini 3.6 Flash·RTX 5090 `ornith-fast`를 조합하는 독립 IOP Hot Path를 스케치하고, caller-neutral 누적 요청 컨텍스트 최적화, RAG 장기 기억, Advisor와 Context Hook은 서로 책임이 다른 2차 기능으로 분리한다. + - 요약: Hot Path에서 model advisory·Edge arbiter·고정 실행 profile의 기본을 구축하고, request-local analysis/generation/verification과 cloud-first 하이브리드 라우팅으로 일반화한다. 운영 evidence가 충분해지면 routing 전용 RAG local model로 점진 전환하며, repository 장기 기억 RAG와 Advisor/Context Hook은 별도 책임으로 유지한다. - [스케치] Personal Edge 패키징과 배포 프로파일 - 경로: [PHASE.md](phase/personal-edge-packaging-deployment/PHASE.md) diff --git a/agent-roadmap/phase/automation-runtime-bridge/milestones/oto-automation-scheduler-second-wave.md b/agent-roadmap/archive/phase/automation-runtime-bridge/milestones/oto-automation-scheduler-second-wave.md similarity index 100% rename from agent-roadmap/phase/automation-runtime-bridge/milestones/oto-automation-scheduler-second-wave.md rename to agent-roadmap/archive/phase/automation-runtime-bridge/milestones/oto-automation-scheduler-second-wave.md diff --git a/agent-roadmap/phase/automation-runtime-bridge/milestones/pi-cli-provider-integration.md b/agent-roadmap/archive/phase/automation-runtime-bridge/milestones/pi-cli-provider-integration.md similarity index 100% rename from agent-roadmap/phase/automation-runtime-bridge/milestones/pi-cli-provider-integration.md rename to agent-roadmap/archive/phase/automation-runtime-bridge/milestones/pi-cli-provider-integration.md diff --git a/agent-roadmap/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md b/agent-roadmap/archive/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md similarity index 100% rename from agent-roadmap/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md rename to agent-roadmap/archive/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md diff --git a/agent-roadmap/phase/automation-runtime-bridge/PHASE.md b/agent-roadmap/phase/automation-runtime-bridge/PHASE.md index 8ddf0bb4..5a57273b 100644 --- a/agent-roadmap/phase/automation-runtime-bridge/PHASE.md +++ b/agent-roadmap/phase/automation-runtime-bridge/PHASE.md @@ -6,16 +6,16 @@ ## 목표 -Runtime과 Automation 실행 흐름을 공통화하고, agent 설치형 대상과 비설치형 대상의 제어 경로를 분리해 확장한다. -CLI 실행, specialized agent 등록, bootstrap/enrollment, OpenAI-compatible workspace agent 실행 계약을 서로 충돌하지 않는 운영 경로로 정리했다. -NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 하는 Responses 기반 workspace agent 실행 계약과 정적 lane/G 결과를 시간대·quota·실행 상태와 결합하는 Agent Task 동적 실행 Target Selector를 완료했다. 완료된 `iop-agent`는 현재 IOP가 소유하는 선별 이전 source이며, [IOP Agent Runtime의 Chronos 선별 이전과 IOP 의존성 제거](milestones/iop-agent-chronos-extraction-decoupling.md)가 필요한 자산 전달, IOP standalone 제거와 잔류 provider 회귀를 먼저 닫는다. 이 Milestone 완료 전에는 Chronos Roadmap을 시작하지 않으며, 이후 scoped workflow, task-file grade routing policy, Provider 알림, 원격 workspace와 Flutter·Unity 제품 작업은 Chronos가 소유한다. -원격 터미널/CLI 터널링과 oto scheduler/CI-CD 자동화는 2차 스케치로 잠그고, 현재 활성 구현 범위로 끌어오지 않는다. +과거 IOP 안에서 공통화한 CLI Agent/Automation 자산을 독립 Chronos 플랫폼으로 이전하고, IOP를 추론 provider 운영 책임으로 되돌린다. +완료된 CLI 실행, workspace agent, Agent Task selector와 standalone `iop-agent`는 이전 기준선일 뿐 IOP의 장기 제품 경계가 아니다. +[IOP Agent Runtime의 Chronos 전체 이전과 IOP 의존성 제거](milestones/iop-agent-chronos-extraction-decoupling.md)가 모든 관련 자산을 repository-neutral Chronos acceptance bundle로 전달하고 IOP의 agent·workspace·terminal·host/client lifecycle surface와 Chronos 연결점을 제거한다. 이 Milestone 완료 전에는 Chronos Roadmap을 시작하지 않으며, 이후 실제 repository import, 최종 layout 결정, 외부 접근 가능한 Chronos Server, 독립 Chronos Node, 작업 루프·agent·terminal·원격 호스트 제어는 Chronos가 소유한다. +IOP Control Plane·Edge·IOP Node에는 model/provider/device 서빙에 필요한 route·실행·취소·상태·usage·lifecycle만 남긴다. Chronos는 필요할 때 IOP의 외부 추론 API를 일반 client로 소비하며 IOP Node에 연결하거나 제어하지 않는다. ## Milestone 흐름 -완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다. +완료되었거나 `[폐기]` 상태인 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다. 이 흐름은 해당 Phase 안의 상태 정리이며, Phase를 가로지르는 실행 순서는 아니다. -Milestone은 완료, 검토중, 진행중, 계획, 스케치 또는 보류 상태 그룹으로 정리한다. +Milestone은 완료, 폐기, 검토중, 진행중, 계획, 스케치 또는 보류 상태 그룹으로 정리한다. Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실행 순서](../../priority-queue.md)를 우선한다. - [완료] CLI Automation Runtime 안정화 @@ -90,38 +90,37 @@ Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실 - 경로: [agent-task-runtime-target-selector](../../archive/phase/automation-runtime-bridge/milestones/agent-task-runtime-target-selector.md) - 요약: 정적 lane/G 결과를 시간대, quota와 이전 실행 상태에 결합해 작업 단위로 고정되는 `adapter + target` 선택과 failover·selfcheck·task-local blocker·독립 작업 drain 정책을 구현했다. 중복된 최종 audit pair는 임시 Python 구현 폐기 예정에 따른 사용자 결정으로 미실행 종료했다. -- [계획] Pi CLI Provider Integration - - 경로: [pi-cli-provider-integration](milestones/pi-cli-provider-integration.md) - - 요약: Node CLI adapter의 실행 profile 후보에 Pi를 추가하고, Pi JSON stream 출력 파서, config 예시, OpenAI-compatible route smoke를 통해 `adapter=cli,target=pi`를 안정적으로 사용할 수 있게 한다. +- [폐기] Pi CLI Provider Integration + - 경로: [pi-cli-provider-integration](../../archive/phase/automation-runtime-bridge/milestones/pi-cli-provider-integration.md) + - 요약: workspace와 tools를 가진 Pi CLI agent 실행은 IOP 추론 provider 책임이 아니므로 IOP 계획을 폐기하고 Chronos Server/Node의 agent 실행 후보로 넘긴다. - [완료] IOP Agent CLI Runtime - 경로: [iop-agent-cli-runtime](../../archive/phase/automation-runtime-bridge/milestones/iop-agent-cli-runtime.md) - 요약: Python 감시·dispatcher와 Node CLI runtime 동등성을 공통 Go CLI Provider·AgentTaskManager 및 개인 장비당 단일 `iop-agent` binary로 이전하고, 다중 project 관측·수동 시작/자동 재개·client subprocess 소유 경계를 완료했다. -- [스케치] IOP Agent Runtime의 Chronos 선별 이전과 IOP 의존성 제거 - - 경로: [IOP Agent Runtime의 Chronos 선별 이전과 IOP 의존성 제거](milestones/iop-agent-chronos-extraction-decoupling.md) - - 요약: 완료된 `iop-agent`에서 Chronos-owned source와 fixture만 전달하고 IOP standalone surface를 제거한 뒤 잔류 Node/provider 회귀와 downstream 잠금 해제 evidence를 남긴다. +- [진행중] IOP Agent Runtime의 Chronos 전체 이전과 IOP 의존성 제거 + - 경로: [IOP Agent Runtime의 Chronos 전체 이전과 IOP 의존성 제거](milestones/iop-agent-chronos-extraction-decoupling.md) + - 요약: 완료된 `iop-agent`의 모든 관련 자산과 저장 상태를 repository-neutral Chronos acceptance bundle로 전달하고 IOP의 agent·terminal·workspace·Chronos 연결 surface를 제거한 뒤, 추론 provider 운영 경계만 남은 IOP Node 회귀와 downstream 잠금 해제 evidence를 남긴다. -- [스케치] oto 자동화 스케줄러와 CI-CD 연동 (2차) - - 경로: [oto-automation-scheduler-second-wave](milestones/oto-automation-scheduler-second-wave.md) - - 요약: oto를 이용한 자동화, scheduler, CI-CD 연동은 MVP 이후 2차 후보로 스케치한다. +- [폐기] oto 자동화 스케줄러와 CI-CD 연동 (2차) + - 경로: [oto-automation-scheduler-second-wave](../../archive/phase/automation-runtime-bridge/milestones/oto-automation-scheduler-second-wave.md) + - 요약: loop engineering, scheduler와 CI-CD workflow는 IOP가 아니라 Chronos Server 책임이므로 IOP 후보를 폐기한다. -- [보류] 원격 터미널/CLI 터널링 POC (2차) - - 경로: [remote-terminal-bridge-poc](milestones/remote-terminal-bridge-poc.md) - - 요약: Agent를 설치하기 어려운 host/device 또는 특정 Node의 CLI agent를 Socket 경유로 다른 원격지에 연결하는 터널링 POC는 MVP 이후 2차로 보류한다. +- [폐기] 원격 터미널/CLI 터널링 POC (2차) + - 경로: [remote-terminal-bridge-poc](../../archive/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md) + - 요약: terminal/PTY와 원격 호스트 제어는 독립 Chronos Node가 소유하므로 Edge-IOP Node 브리지 방식의 IOP POC를 폐기한다. ## Phase 경계 -- OpenAI-compatible API와 A2A API에 terminal 제어 기능을 억지로 싣지 않는다. -- Edge는 실행 요청의 broker 역할을 하고, Node는 대상 transport 실행자 역할을 유지한다. -- 완료된 `iop-agent`의 Edge 비의존 headless CLI, 단일 active supervisor와 same-user local-control 동작은 선별 이전 source invariant다. IOP 선행 분리 Milestone이 끝나면 IOP에는 해당 standalone binary와 supervisor/client lifecycle 소유권을 남기지 않는다. -- 단일 `iop-agent`의 기존 project 관측·client process 기능은 IOP 선행 Milestone의 transfer manifest와 behavior fixture 입력으로만 취급하고, 새 client lifecycle·local control 기능은 IOP에 추가하지 않는다. -- 설치 가능한 대상은 bootstrap/enrollment 경로로, 설치가 어렵거나 일회성 유지보수 대상은 remote terminal bridge 경로로 구분한다. -- OpenAI-compatible Responses 표면은 외부 모델 호출 호환을 위한 입력 표면이며, IOP 고유 운영 제어는 native protocol이나 명시 운영 API로 분리한다. -- NomadCode 지원을 위한 `metadata.workspace` 실행 계약은 provider 확장, Lemonade 추가, remote terminal bridge보다 먼저 닫는다. -- 완료된 `iop-agent`와 공통 Agent Task runtime의 workspace guard, selection, recovery와 상태 동작은 IOP 선행 Milestone에서 Chronos-owned/IOP-retained로 분류한다. 전달된 standalone 동작은 Chronos가 이어받고, IOP에는 잔류 finite provider 실행에 필요한 코드만 유지한다. -- Plan/Review·Milestone·Roadmap lifecycle, 일반 요청 triage, task filename lane/grade 해석과 route policy는 Chronos가 소유한다. IOP provider host는 Chronos가 고정한 typed `adapter + target`을 실행할 뿐 artifact 원문이나 filename 의미를 재해석하지 않는다. -- provider 실행, quota/status, stream/session과 finite retry/failure capability는 선별 이전 전후 모두 IOP가 유지한다. 선행 Milestone 완료 뒤에는 IOP에 standalone workflow state, client lifecycle, forwarding runtime 또는 Chronos application runtime dependency를 남기지 않는다. +- OpenAI-compatible, Anthropic-compatible와 A2A 호환 표면은 IOP의 추론 provider 호출에 한정하며 terminal·workspace·agent loop 제어를 싣지 않는다. +- Edge는 IOP provider 요청의 broker 역할을 하고, IOP Node는 model/provider/device 실행자 역할만 유지한다. +- 완료된 `iop-agent`의 Edge 비의존 headless CLI, 단일 active supervisor와 same-user local-control 동작은 전체 이전 기준선이다. IOP 선행 분리 Milestone이 끝나면 IOP에는 해당 binary, supervisor/client lifecycle, 작업 상태와 관련 계약을 남기지 않는다. +- 단일 `iop-agent`의 기존 project 관측·client process 기능과 저장 상태는 IOP 선행 Milestone의 전체 이전 목록과 동작 검증 입력으로 취급하고, IOP에 새 client lifecycle·local control 기능을 추가하지 않는다. +- OpenAI-compatible Responses 표면은 외부 모델 호출 호환을 위한 입력 표면이며, IOP 고유 provider 운영 제어는 native protocol이나 명시 운영 API로 분리한다. `metadata.workspace`는 IOP Node의 workspace agent 실행이나 원격 mutation 권한으로 해석하지 않는다. +- 완료된 `iop-agent`와 공통 Agent Task runtime의 작업공간 보호, 대상 선택, 복구, 상태·검토·반영 동작은 Chronos로 전부 이전한다. IOP Node에는 IOP가 소유한 provider 실행·취소·상태·usage와 model/device lifecycle만 유지한다. +- Plan/Review·Milestone·Roadmap lifecycle, 일반 요청 triage, task filename lane/grade 해석, route policy, terminal/PTY, file/process와 원격 workspace 제어는 Chronos Server와 Chronos Node가 소유한다. +- Chronos Node는 IOP Node와 별도 runtime·identity·registry·wire를 가진다. IOP에는 Chronos를 위한 bridge/API/proto/config, target 등록, forwarding runtime 또는 future control hook을 남기지 않는다. +- Chronos가 모델 추론이 필요하면 IOP의 공개 추론 API를 일반 client로 호출한다. IOP는 Chronos 작업/session/node 의미를 알지 못하고 Chronos는 IOP Node를 제어하지 않는다. - 외부 `model=iop`으로 명시 선택되는 [IOP Hot Path One-shot 실행 경로](../knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md)는 IOP가 계속 소유하는 독립 경로이며 Chronos의 direct/Plan/Milestone 분류, durable artifact와 continuation을 거치거나 공유하지 않는다. - IOP가 quota/status/failure event를 제공할 수는 있지만 macOS/Desktop 알림 delivery와 이력은 Chronos가 소유한다. -- 원격 터미널/CLI 터널링 POC와 oto scheduler/CI-CD 연동은 현재 활성 작업에서 제외하고, provider 상태/capacity queue와 운영 관측 MVP 이후 재개 후보로 둔다. +- Pi 같은 workspace CLI agent, 원격 터미널/CLI 터널링과 oto scheduler/CI-CD는 IOP 재개 후보로 두지 않고 Chronos 책임에서 새로 설계한다. diff --git a/agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md b/agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md index aed3c7bd..6336768b 100644 --- a/agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md +++ b/agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md @@ -1,4 +1,4 @@ -# Milestone: IOP Agent Runtime의 Chronos 선별 이전과 IOP 의존성 제거 +# Milestone: IOP Agent Runtime의 Chronos 전체 이전과 IOP 의존성 제거 ## 위치 @@ -7,74 +7,80 @@ ## 목표 -완료된 `iop-agent`에서 Chronos가 소유해야 할 standalone workflow, durable state, workspace와 local-control 자산만 Chronos 저장소로 선별 이전하고, IOP에서는 standalone host·client lifecycle·workflow 의존성을 제거한다. IOP Node의 finite model/API/CLI provider 실행은 보존하며, 이 Milestone의 전달·회귀 evidence가 완료되어야 Chronos Roadmap을 시작할 수 있다. +완료된 `iop-agent`의 source·contract·test·config·state·build·document 자산을 repository-neutral Chronos acceptance bundle로 전부 전달하고, IOP에서는 `iop-agent`와 Chronos 작업 흐름에 관련된 host·client lifecycle·workspace·CLI agent session·terminal·상태·검토·반영 로직과 의존성을 제거한다. IOP Node에는 model/provider/device 운영에 필요한 실행·취소·상태·usage·lifecycle 경계만 남기고 Chronos를 위한 연결점을 두지 않는다. 이 Milestone의 전달·제거·회귀 evidence가 완료되어야 Chronos Roadmap의 잠금을 해제하고 Chronos가 bundle의 실제 repository import, 외부 접근 가능한 Server, 독립 Chronos Node와 loop/agent/terminal 책임을 설계할 수 있다. ## 상태 -[스케치] +[진행중] ## 승격 조건 -- [ ] 현재 IOP source revision과 파일별 `transfer | retain | remove | reference` disposition이 확정되어 있다. -- [ ] Chronos로 전달할 최소 buildable baseline과 IOP에서 보존할 provider 경계가 구분되어 있다. -- [ ] 기존 config/state의 versioned export 범위에 대한 사용자 결정이 SDD에 반영되어 있다. -- [ ] 양쪽 repository 검증과 Chronos 잠금 해제 evidence가 정의되어 있다. +- [x] Task 03이 기준 source revision `3155be0e275437a8eedc1aa93497955a7d30465b`, original manifest 303행(`file=293`, `state=10`)과 `universe·duplicate=0`을 historical inventory evidence로 남겼고, Task 16 재계획이 corrected pinned-transfer manifest 300행(`file=290`, `state=10`, `retain-generic=135`)과 SHA `d8598134dee99d96fc05a045091dd3d8932d4708d2c980c2a78c8b11825d2ccf`를 current baseline으로 고정했다. historical Task-03 303행 결과는 Task-03 evidence로만 보존하고, `user_review_0.log`는 separate evidence로 분류하며 두 protocol-profile test는 excluded from the revision-3155 historical bundle로 기록한다. +- [x] Chronos로 전달할 독립 build baseline의 조건과 IOP Node에 남길 추론 provider 운영 경계가 승인된 SDD에 구분되어 있다. +- [x] 기존 등록·설정·저장 상태 전체 이전에 대한 사용자 결정이 SDD에 반영되어 있다. +- [x] IOP Node에는 Chronos 연결·제어 경계를 두지 않고 Chronos Server와 Chronos Node를 별도 runtime으로 둔다는 사용자 결정이 SDD에 반영되어 있다. +- [x] 양쪽 repository 검증과 Chronos 잠금 해제 evidence가 SDD Acceptance Scenario와 Evidence Map에 정의되어 있다. ## 구현 잠금 -- 상태: 잠금 +- 상태: 해제 - SDD: 필요 - SDD 문서: [SDD.md](../../../sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/SDD.md) -- SDD 사유: cross-repo 코드 이전과 삭제, legacy state export, 잔류 IOP provider 회귀 및 외부 Milestone 잠금 해제를 함께 다룬다. +- SDD 사유: cross-repo 전체 자산 이전과 삭제, 기존 상태 전체 전달, IOP 전용 provider 운영 경계 회귀, Chronos 연결점 폐쇄 및 외부 Milestone 잠금 해제를 함께 다룬다. - 잠금 해제 조건: - - [ ] SDD 사용자 리뷰가 해결되어 있다. - - [ ] SDD 상태가 `[승인됨]`이고 SDD 잠금이 해제되어 있다. - - [ ] Acceptance Scenario가 Milestone 기능 Task와 연결되어 있다. - - [ ] Evidence Map이 IOP 완료 검토와 Chronos workspace 잠금 해제 근거로 연결되어 있다. + - [x] SDD 사용자 리뷰가 해결되어 있다. + - [x] SDD 상태가 `[승인됨]`이고 SDD 잠금이 해제되어 있다. + - [x] Acceptance Scenario가 Milestone 기능 Task와 연결되어 있다. + - [x] Evidence Map이 IOP 완료 검토와 Chronos workspace 잠금 해제 근거로 연결되어 있다. - 결정 필요: - - [ ] 기존 `iop-agent`의 유효한 project registration, user-local config와 durable state 중 Chronos가 이후 import할 versioned export 입력 범위를 확정한다. + - 없음 ## 범위 -- 현재 IOP `iop-agent` source·contract·test·config·build·document surface의 ownership/disposition manifest -- Chronos가 소유할 standalone runtime source, behavior fixture와 versioned legacy-state export 입력의 선별 이전 -- IOP standalone binary·host·workflow·client lifecycle surface와 전용 의존성 제거 -- IOP Node가 계속 소유할 finite model/API/CLI provider runtime과 Edge wire 회귀 검증 +- 현재 IOP `iop-agent` source·contract·test·config·state·build·document surface 전체의 ownership/disposition manifest +- `iop-agent` 전체 runtime source, 동작 검증 자료와 기존 등록·설정·저장 상태를 repository-neutral versioned Chronos acceptance bundle로 전달 +- IOP standalone binary·host·workflow·client lifecycle·workspace·CLI agent session·terminal·상태·검토·반영 surface와 전용 의존성 제거 +- IOP Node에서 Chronos bridge/API/proto/config와 agent/terminal/workspace 제어 의미를 제거하고, model/provider/device 운영에 필요한 실행·취소·상태·usage·lifecycle만 남긴 뒤 Edge wire 회귀 검증 - cross-repo 전달 receipt, rollback 근거와 Chronos 시작 잠금 해제 handoff ## 기능 -### Epic: [separation] 선별 이전과 책임 분리 +### Epic: [separation] 전체 이전과 책임 분리 -- [ ] [inventory] 현재 source revision을 고정하고 code·config·proto·build·test·docs를 `transfer | retain | remove | reference` 중 하나로 분류한 ownership manifest를 만든다. 검증: manifest에 미분류 활성 파일과 양쪽 product source of truth 중복이 없어야 한다. -- [ ] [transfer] manifest의 Chronos-owned source·contract fixture·behavior test와 승인된 legacy-state export 입력을 Chronos repository의 독립 staging baseline으로 전달한다. 검증: staging baseline이 IOP application/runtime package import 없이 독립 build되고 기존 behavior test가 통과하며 전달 목록과 실제 target이 일치해야 한다. -- [ ] [decouple] IOP의 standalone binary·host·workflow·client lifecycle 및 전용 config/proto/build/document surface를 manifest대로 제거한다. 검증: 제거 대상 잔존 참조와 Chronos application runtime import가 없어야 한다. -- [ ] [retain-node] IOP에 남는 finite model/API/CLI provider execution, Node adapter와 Edge wire가 standalone 제거 뒤에도 동작하도록 경계를 보존한다. 검증: 관련 build·contract·focused regression이 통과해야 한다. -- [ ] [handoff-gate] versioned legacy-state export 결과 또는 명시적 clean-start 결정, 양쪽 검증 결과, rollback 지점과 downstream lock identity를 포함한 transfer receipt를 남긴다. 검증: receipt가 모든 이전·제거 항목과 Chronos 잠금 해제 조건을 추적할 수 있어야 한다. +- [ ] [inventory] Task 03의 source revision·303행(`file=293`, `state=10`)·`universe·duplicate=0` historical evidence를 승계하고, Task 16 corrected pinned-transfer manifest 300행(`file=290`, `state=10`, `retain-generic=135`)과 SHA `d8598134dee99d96fc05a045091dd3d8932d4708d2c980c2a78c8b11825d2ccf`를 current pinned-transfer baseline으로 고정한다. historical Task-03 303행 결과는 Task-03 evidence로만 보존한다. original manifest bytes는 다시 쓰지 않고 D04가 바꾼 137개 처분은 boundary-disposition delta로, original manifest 밖의 D04 활성 surface는 별도 boundary-surface addendum으로 기록해 세 입력을 결합한 effective disposition matrix를 만든다. 검증: Task 03 row/universe evidence와 Task 16 corrected manifest SHA·retain count, 137-row delta·addendum의 digest를 각각 추적할 수 있고, 모든 `iop-agent` 관련 활성 자산은 Chronos 전달과 IOP 제거가 짝지어지며 IOP provider 운영 외 미분류·retain 항목과 양쪽 source of truth 중복이 없어야 한다. +- [ ] [transfer] manifest의 `iop-agent` source·contract·behavior test와 기존 등록·설정·저장 상태 전체를 repository-neutral versioned Chronos acceptance bundle로 만든다. 검증: bundle을 격리 staging root에 풀었을 때 live IOP checkout이나 누락된 IOP source dependency 없이 독립 build되고 기존 behavior test가 통과하며 전달 목록·acceptance layout·bundle digest가 일치해야 한다. +- [ ] [decouple] IOP의 standalone binary·host·workflow·client lifecycle·workspace·CLI agent session·terminal·상태·검토·반영 및 전용 config/proto/build/document surface를 manifest대로 제거한다. 검증: 제거 대상 잔존 참조, Chronos application runtime import와 future Chronos bridge/API/proto/config가 없어야 한다. +- [ ] [retain-node] IOP Node에는 model/provider/device 운영에 필요한 실행·취소·상태·usage·lifecycle과 Edge wire만 남긴다. 검증: CLI agent session·PTY/terminal·workspace mutation·원격 호스트 제어·Chronos target/registry/bridge 참조가 없고 IOP provider build·contract·focused regression이 통과해야 한다. +- [ ] [handoff-gate] Task 13에서 original manifest·137-row delta·D04 surface addendum를 effective matrix로 정합화한 pre-deletion receipt를 고정하고, Task 14의 최종 잔여 migration-surface 삭제 evidence를 더해 Task 15의 tracked `HANDOFF.md`에 final composite receipt를 남긴다. 검증: 최종 receipt가 사전 처분 근거, 전체 상태 이전, 양쪽 검증, 최종 제거, rollback 지점과 downstream lock identity를 모두 추적할 수 있어야 한다. ## 완료 리뷰 - 상태: 없음 - 요청일: 없음 -- 완료 근거: IOP가 소유할 선행 분리 작업과 Chronos 시작 gate를 구체화하는 스케치다. -- 검토 항목: ownership manifest, 양쪽 독립 build, IOP 잔류 provider 회귀와 workspace lock 동기화 +- 완료 근거: Task 03 historical evidence는 source revision, original manifest 303행(`file=293`, `state=10`)과 `universe·duplicate=0`을 고정했다. Task 16 corrected pinned-transfer manifest 300행(`file=290`, `state=10`, `retain-generic=135`)과 SHA `d8598134dee99d96fc05a045091dd3d8932d4708d2c980c2a78c8b11825d2ccf`는 current pinned-transfer baseline이다. D04의 137-row delta·surface addendum·effective matrix와 후속 이전·제거·회귀·handoff evidence는 아직 완료되지 않아 모든 Milestone 기능 Task를 미체크로 유지한다. +- 검토 항목: original manifest·137-row delta·D04 surface addendum 정합성, 양쪽 독립 build, IOP provider 전용 Node 회귀, Task 13/15 receipt, Chronos 연결점 부재와 workspace lock 동기화 - 리뷰 코멘트: 없음 ## 범위 제외 -- Chronos 제품 아키텍처의 후속 확정과 Chronos-owned local control v1 설계 +- Chronos Server, 독립 Chronos Node, 외부 접근 API, loop/agent/terminal과 원격 호스트 제어의 후속 설계·구현 - Plan·Milestone·Roadmap workflow 신규 기능 구현 - IOP Node `agent_bridge`, Edge managed routing와 remote mutation 구현 - OTO adapter와 Flutter·Unity application 구현 -- IOP에 forwarding standalone runtime이나 Chronos application runtime dependency를 남기는 호환 계층 +- IOP에 forwarding standalone runtime, Chronos 작업 로직이나 Chronos application runtime dependency를 남기는 호환 계층 ## 작업 컨텍스트 -- 관련 경로: [IOP Agent CLI Runtime 계약](../../../../agent-contract/inner/iop-agent-cli-runtime.md), `apps/agent`, `packages/go/agent*`, `proto/iop/agent.proto`, `Makefile`, `scripts/e2e-iop-agent-logged-smoke.sh`, `../chronos` -- 표준선(선택): 이 Milestone이 선별 이전과 IOP 제거의 유일한 실행 owner다. source 삭제 전 destination baseline의 독립 build와 behavior fixture 수용을 확인하고, 삭제 뒤에는 git revision과 transfer receipt로만 rollback한다. -- 표준선(선택): IOP는 finite provider 실행을 유지하되 standalone workflow/state/client lifecycle을 보유하거나 Chronos application runtime을 import하지 않는다. -- 표준선(선택): IOP는 legacy state를 versioned export 입력과 blocker manifest로만 전달한다. Chronos state root로의 실제 import·활성화와 이후 write ownership은 외부 잠금 해제 뒤 Chronos 수용 Milestone이 수행한다. +- 관련 기준: 완료된 [IOP Agent CLI Runtime](../../../archive/phase/automation-runtime-bridge/milestones/iop-agent-cli-runtime.md), 기준 source revision의 legacy contract snapshot, `apps/agent`, `packages/go/agent*`, `proto/iop/agent.proto`, `Makefile`, `scripts/e2e-iop-agent-logged-smoke.sh`, `../chronos` +- 표준선(선택): 이 Milestone이 전체 이전 bundle 생성과 IOP 제거의 유일한 실행 owner다. source 삭제 전 bundle의 격리 staging build와 동작 검증을 확인하고, 삭제 뒤에는 git revision과 transfer receipt로만 rollback한다. Chronos repository import와 최종 source layout 결정은 외부 잠금 해제 뒤 Chronos 수용 Milestone이 소유한다. +- 표준선(선택): IOP Node는 IOP model/provider/device 운영 경계만 유지한다. standalone workflow/state/client lifecycle, CLI agent session, terminal/PTY, workspace·원격 호스트 제어 또는 Chronos 전용 bridge/API/proto/config를 보유하지 않는다. +- 표준선(선택): Chronos는 자체 Server와 IOP Node와 별개인 Chronos Node를 소유한다. Chronos가 추론을 사용할 때는 IOP의 외부 API를 일반 client로 호출하며 IOP Node를 연결·등록·제어하지 않는다. +- 표준선(선택): IOP는 기존 등록·설정·저장 상태와 깨진 잔여 기록까지 버전이 있는 읽기 전용 이전 입력으로 전달한 뒤 관련 상태를 남기지 않는다. 실제 import·활성화와 이후 write ownership은 외부 잠금 해제 뒤 Chronos 수용 Milestone이 수행한다. +- 표준선(선택): Task 03의 source revision·303행(`file=293`, `state=10`)·`universe·duplicate=0` evidence를 historical record로 승계하되 Task 03이 manifest SHA나 `retain-generic=137`을 고정했다고 해석하지 않는다. Task 16 corrected pinned-transfer manifest 300행(`file=290`, `state=10`, `retain-generic=135`)과 SHA `d8598134dee99d96fc05a045091dd3d8932d4708d2c980c2a78c8b11825d2ccf`를 current pinned-transfer baseline으로 고정한다. historical Task-03 303행 결과는 Task-03 evidence로만 보존하며, `user_review_0.log`는 separate evidence로 분류하고 두 protocol-profile test는 excluded from the revision-3155 historical bundle로 기록한다. D04 변경은 정확히 137개 행의 boundary-disposition delta와 original manifest 밖 활성 surface addendum로 분리하고, Task 13에서 세 digest를 결합한 effective matrix와 pre-deletion receipt를 고정한다. Task 14의 최종 잔여 migration-surface 삭제 뒤 Task 15의 tracked `HANDOFF.md`가 final composite receipt를 소유한다. +- Workspace 잠금 identity: `.agent-roadmap-sync/locks.yaml`의 선행 target은 정식 프로젝트 `iop:agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md`다. 현재 별도 checkout `iop-s1`의 완료 상태를 같은 identity로 간주하지 않으며, 검토된 commit이 `/config/workspace/iop`에 반영되고 그 정식 Milestone 상태가 동기화되기 전에는 Chronos 잠금을 해제하지 않는다. +- 기준 source revision: `3155be0e275437a8eedc1aa93497955a7d30465b` +- 구현 분류 기준: 모든 기존 `apps/agent/**`와 `packages/go/agent*/**` source는 Chronos 이전 입력에 포함하고 IOP의 기존 agent-named 경로에서는 제거한다. IOP Node가 model/provider/device 운영에 실제로 사용하는 최소 부분만 비(非)Agent 이름의 중립 패키지로 재배치하며 CLI agent·workspace·terminal·Chronos 연결 의미를 포함하지 않는다. - 큐 배치: Chronos 전체 Roadmap의 선행 gate이므로 전역 실행 순서 1번이다. -- 선행 작업: 완료된 [IOP Agent CLI Runtime 계약](../../../../agent-contract/inner/iop-agent-cli-runtime.md) +- 선행 작업: 완료된 [IOP Agent CLI Runtime](../../../archive/phase/automation-runtime-bridge/milestones/iop-agent-cli-runtime.md) - 후속 작업: [Chronos 아키텍처와 프로젝트 소유권 경계 확정](../../../../../chronos/agent-roadmap/phase/runtime-ownership-transition/milestones/chronos-architecture-ownership-boundary.md) -- 확인 필요: [USER_REVIEW.md](../../../sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/USER_REVIEW.md) +- 사용자 결정: [user_review_0.log](../../../sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_0.log), [user_review_1.log](../../../sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_1.log)에서 해결됨. 후자가 IOP Node와 Chronos의 연결 가능성을 남긴 이전 D02 해석을 대체한다. diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md index 7e6625f1..1ca4fdd7 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md @@ -7,8 +7,10 @@ ## 목표 Ollama serving 경로와 운영 기반이 안정화된 뒤, 단계 호출, tool/schema 강제, output validation, retry/fallback과 누적 요청 컨텍스트 구성을 IOP의 추론 최적화 계층으로 확장한다. -1차 MVP는 planner/generator/verifier 같은 단계 호출과 runtime schema 검증의 최소 실행 모드를 스케치하는 데 집중하고, caller-neutral 누적 요청 컨텍스트 최적화, RAG 장기 기억, advisor와 Context Hook은 서로 다른 2차 기능으로 분리한다. -별도 IOP Hot Path는 OpenAI-compatible `model=iop` 한 번의 요청 안에서 빠른 cloud `Gemini 3.6 Flash`와 RTX 5090 local target `ornith-fast`를 조합해 최대 속도와 실사용 품질 하한의 균형을 맞추며, durable 작업 루프와 독립된 one-shot 제품 경로로 둔다. +첫 vertical slice인 IOP Hot Path는 OpenAI-compatible `model=iop` 한 번의 요청 안에서 빠른 cloud `Gemini 3.6 Flash`와 RTX 5090 local target `ornith-fast`를 조합하고, model advisory와 Edge 최종 판정, request-local execution profile, route evidence의 기본을 구축한다. +그 다음 analysis directive/generation/verification을 올바른 request-local plan/review 단계로 일반화하고, Edge가 요청 난이도·기능·예산에 따라 실행 형태와 stage별 adapter/target을 고르는 cloud-first 하이브리드 라우팅으로 연결한다. +cloud-first 운영 근거가 충분히 쌓이면 동일한 decision contract를 쓰는 RAG 기반 local routing model을 shadow/canary로 검증해 운영 기본 경로로 점진 전환한다. +caller-neutral 누적 요청 컨텍스트 최적화, repository 장기 기억 RAG, advisor와 Context Hook은 routing evidence RAG와 서로 다른 후속 기능으로 분리한다. 이 Phase는 특정 Agent Shell에 종속되지 않고 OpenAI-compatible, A2A, IOP native protocol 중 맞는 표면에서 공통 최적화 책임을 제공하는 방향을 다룬다. ## Milestone 흐름 @@ -34,44 +36,52 @@ Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실 - 경로: [stream-evidence-gate-core](../../archive/phase/knowledge-tool-optimization-extension/milestones/stream-evidence-gate-core.md) - 요약: codec의 response-start/event를 첫 safe release까지 stage하고 500-rune rolling, bounded terminal/fragment hold, pre-read 기본값/절대 상한 16 MiB raw-canonical ingress snapshot과 request-snapshot 기반 Filter Registry를 제공한다. Gate Coordinator가 single-flight all-complete evaluation/commit을, RecoveryPlan Coordinator와 host adapter가 strategy별 budget과 최초 실행 제외 기본값/절대 상한 3회의 request 전체 cap 아래 abort·optional one-shot plan prepare·lossless rebuild·cycle별 single re-admission을 담당한다. -- [계획] OpenAI-compatible 출력 검증 필터 - - 경로: [openai-compatible-output-validation-filters](milestones/openai-compatible-output-validation-filters.md) +- [계획] [output-01] OpenAI-compatible 출력 검증 필터 + - 경로: [[output-01] OpenAI-compatible 출력 검증 필터](milestones/openai-compatible-output-validation-filters.md) - 요약: 실제 의미 필터 전에 local/dev deterministic diagnostic mock으로 실제 codec/Core/Arbiter/recovery/ReleaseSink의 pass·observe-only·blocking recovery와 raw-free timeline을 관측하는 smoke를 선행한다. 이후 OpenAI-compatible Chat Completions와 Responses provider stream의 반복, assistant-history anchor, 동일 tool/action, schema/provider error를 caller-neutral하게 판정하는 Core `Filter` 구현체를 제공한다. filter는 model/provider별 on/off와 semantic decision/RecoveryIntent만 소유하고, 병렬 평가·all-complete arbitration·retry budget·request rebuild/re-admission은 Stream Evidence Gate Core의 공통 Coordinator를 소비한다. -- [계획] OpenAI-compatible Incomplete Tool Call Syntax Gate - - 경로: [openai-compatible-incomplete-tool-call-syntax-gate](milestones/openai-compatible-incomplete-tool-call-syntax-gate.md) +- [계획] [output-02] OpenAI-compatible Incomplete Tool Call Syntax Gate + - 경로: [[output-02] OpenAI-compatible Incomplete Tool Call Syntax Gate](milestones/openai-compatible-incomplete-tool-call-syntax-gate.md) - 요약: terminal provider 응답에서 완성된 tool call 수와 raw/reasoning/content tool-call marker scanner 결과가 불일치하는 케이스를 runtime에서 deterministic하게 판정해 incomplete tool-call syntax로 분류한다. -- [스케치] OpenAI-compatible Runtime Output Integrity Filter - - 경로: [openai-compatible-runtime-output-integrity-filter](milestones/openai-compatible-runtime-output-integrity-filter.md) +- [스케치] [output-03] OpenAI-compatible Runtime Output Integrity Filter + - 경로: [[output-03] OpenAI-compatible Runtime Output Integrity Filter](milestones/openai-compatible-runtime-output-integrity-filter.md) - 요약: terminal assistant 응답이 content, valid tool call, 명시 허용 structured/error finish 중 하나를 만족해야 한다는 runtime invariant를 정의하고, empty terminal, reasoning-only, incomplete tool-call syntax 같은 deterministic violation을 공통 filter pipeline과 bounded retry 정책으로 묶는다. -- [스케치] LLM 판별 기반 Missing Tool Call 재시도 Gate - - 경로: [llm-judged-missing-tool-call-retry-gate](milestones/llm-judged-missing-tool-call-retry-gate.md) +- [스케치] [judge-01] LLM 판별 기반 Missing Tool Call 재시도 Gate + - 경로: [[judge-01] LLM 판별 기반 Missing Tool Call 재시도 Gate](milestones/llm-judged-missing-tool-call-retry-gate.md) - 요약: Pi/dev-corp 같은 tool-bearing 요청에서 provider가 tool 사용 의도를 reasoning했지만 tool call 없이 종료하는 케이스를 LLM judge와 buffered retry 후보로 재검토하고, 정확한 종료/재시도 정책이 정의될 때까지 구현을 잠근다. -- [스케치] 단계 호출과 검증 최적화 MVP - - 경로: [knowledge-tool-validation-optimization](milestones/knowledge-tool-validation-optimization.md) - - 요약: 요청 의도 분석, 실제 작업, 검증/schema 강제, 오류 시 회귀를 단계 호출 실행 모드의 MVP 후보로 스케치한다. +- [스케치] [route-01] IOP Hot Path One-shot 실행 경로 + - 경로: [[route-01] IOP Hot Path One-shot 실행 경로](milestones/iop-hot-path-one-shot-execution.md) + - 요약: 외부 `model=iop` 요청을 Gemini 3.6 Flash 즉답 또는 micro-plan, RTX 5090 `ornith-fast` 실행, Gemini 단일 리뷰·보정으로 처리하면서 model advisory, Edge arbiter, request-local profile과 route evidence의 첫 vertical slice를 구축한다. -- [스케치] IOP Hot Path One-shot 실행 경로 - - 경로: [iop-hot-path-one-shot-execution](milestones/iop-hot-path-one-shot-execution.md) - - 요약: 외부 `model=iop` 요청을 Gemini 3.6 Flash 즉답 또는 micro-plan, RTX 5090 `ornith-fast` 실행, Gemini 단일 리뷰·보정으로 처리해 최대 속도와 실사용 품질의 균형을 맞추는 독립 one-shot 경로를 스케치한다. +- [스케치] [route-02] 단계 호출과 검증 최적화 MVP + - 경로: [[route-02] 단계 호출과 검증 최적화 MVP](milestones/knowledge-tool-validation-optimization.md) + - 요약: Hot Path의 micro-plan/review를 analysis directive, generation, verification의 bounded request-local 실행 형태로 일반화하고 Edge가 선택할 stage binding 계약을 스케치한다. -- [스케치] Tool Call 판정 모델 Gate 리뷰 - - 경로: [tool-call-validator-model-gate-review](milestones/tool-call-validator-model-gate-review.md) +- [스케치] [route-03] OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅 + - 경로: [[route-03] OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅](milestones/openai-compatible-hybrid-request-execution-routing.md) + - 요약: 폐기된 하이브리드 라우팅 설계에서 IOP Edge 책임만 복원해 cloud model advisory와 deterministic hard gate를 결합하고, Edge가 요청 난이도에 맞는 execution shape와 stage별 adapter/target을 최종 결정한다. + +- [스케치] [route-04] RAG 기반 Local Routing Model 운영 전환 + - 경로: [[route-04] RAG 기반 Local Routing Model 운영 전환](milestones/rag-local-routing-model-operations.md) + - 요약: cloud-first route evidence가 충분한 품질·규모 gate를 통과하면 같은 decision contract를 쓰는 RAG local router를 shadow, canary, primary 순서로 승격하고 cloud judge를 fallback·audit으로 유지한다. + +- [스케치] [judge-02] Tool Call 판정 모델 Gate 리뷰 + - 경로: [[judge-02] Tool Call 판정 모델 Gate 리뷰](milestones/tool-call-validator-model-gate-review.md) - 요약: 명시적 tool schema만으로 판정할 수 없는 자연어/텍스트/agent-specific tool call 후보를 별도 validator 모델로 분류할지, 어떤 조건에서 허용할지 사용자 리뷰가 필요한 결정 항목으로 스케치한다. -- [스케치] Provider 입력 컨텍스트 선택과 축소 - - 경로: [request-context-assembly-optimization](milestones/request-context-assembly-optimization.md) +- [스케치] [context-01] Provider 입력 컨텍스트 선택과 축소 + - 경로: [[context-01] Provider 입력 컨텍스트 선택과 축소](milestones/request-context-assembly-optimization.md) - 요약: provider 입력으로 누적된 history를 현재 요청 관련성에 따라 과거 요청-답변 단위로 먼저 절단하고, 유지한 답변·tool/search 결과 안에서도 필요한 문단·코드 블록·구간만 남기는 caller-neutral 방향을 스케치한다. provider 응답을 사용자에게 전달하는 출력 경계는 다루지 않는다. -- [스케치] 장기 기억과 RAG 업데이트 사이클 (2차) - - 경로: [long-term-memory-rag-second-wave](milestones/long-term-memory-rag-second-wave.md) +- [스케치] [memory-01] 장기 기억과 RAG 업데이트 사이클 (2차) + - 경로: [[memory-01] 장기 기억과 RAG 업데이트 사이클 (2차)](milestones/long-term-memory-rag-second-wave.md) - 요약: 특정 repo 장기 기억, RAG 저장소, update cycle, MCP 기반 context 절약은 MVP 이후 2차 후보로 스케치한다. -- [스케치] Advisor와 Context Hook 확장 (2차) - - 경로: [advisor-context-hook-second-wave](milestones/advisor-context-hook-second-wave.md) +- [스케치] [advisor-01] Advisor와 Context Hook 확장 (2차) + - 경로: [[advisor-01] Advisor와 Context Hook 확장 (2차)](milestones/advisor-context-hook-second-wave.md) - 요약: advisor 역할과 여러 최적화·검증 기능을 실행 흐름에 연결할 수 있는 Context Hook의 호출·실패·노출 경계를 별도 2차 후보로 스케치한다. ## Phase 경계 @@ -80,6 +90,8 @@ Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실 - 이 Phase는 Control Plane/Client 운영 기반과 운영 관측 MVP 없이 현재 provider 확장 Phase 안으로 당겨 구현하지 않는다. - 기본 `/v1/models`, `/v1/chat/completions`, Edge-Node relay, Ollama option/API passthrough 안정화는 `Ollama 서빙 안정화 기반` Phase 책임이다. - 추가 추론 서버 provider의 adapter/config/target/model 매핑 표준화는 `추론 서버 provider 확장` Phase 책임이다. -- 단계 호출, schema 강제, validation/fallback은 1차 MVP 후보로 검토하되, 누적 요청 컨텍스트 최적화, 장기 기억/RAG, advisor, Context Hook, cloud fallback, 품질 평가 feedback은 서로 책임이 다른 2차 또는 그 이후의 확장으로 둔다. -- direct/Plan/Milestone 분류와 workflow 실행 라우팅은 `Automation Runtime과 Bridge 확장` Phase 책임으로 둔다. -- 이 Phase의 일반 컨텍스트·검증 최적화 계층은 선택된 target과 budget을 소비할 뿐 target을 고르지 않는다. 예외적으로 IOP Hot Path는 외부 `model=iop`으로 명시 선택되는 제품 profile 안에서 Gemini 3.6 Flash와 `ornith-fast`의 고정 역할, stage budget과 one-shot 종료 조건을 소유하되 durable workflow로 전이하거나 그 상태를 공유하지 않는다. +- Hot Path, request-local 단계 호출, 하이브리드 라우팅은 순서대로 첫 profile, 올바른 실행 형태 일반화, Edge 범용 선택 정책을 구성한다. +- IOP Edge는 요청 사실과 model advisory를 바탕으로 execution shape와 stage별 adapter/target을 최종 확정한다. IOP Node는 확정된 stage 실행·취소·상태·usage 보고만 담당한다. +- 이 Phase의 plan/review는 하나의 요청 안에서만 유지되는 transient inference stage다. durable Plan/Milestone/CODE_REVIEW artifact, 승인·continuation·workspace mutation 같은 workflow process는 범위 밖이다. +- cloud model은 초기 semantic judge/teacher 역할을 하고, 충분한 정제 evidence가 쌓인 뒤 RAG local router로 운영 기본을 전환한다. 두 경우 모두 최종 권한은 deterministic hard gate를 적용하는 Edge arbiter에 남는다. +- routing evidence RAG는 route 판정 전용이고, repository 장기 기억 RAG·누적 요청 context·advisor·Context Hook과 corpus/index/평가를 공유하지 않는다. diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/advisor-context-hook-second-wave.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/advisor-context-hook-second-wave.md index 9255c7aa..bb96b5f5 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/advisor-context-hook-second-wave.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/advisor-context-hook-second-wave.md @@ -1,4 +1,4 @@ -# Milestone: Advisor와 Context Hook 확장 (2차) +# Milestone: [advisor-01] Advisor와 Context Hook 확장 (2차) ## 위치 diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md index 097061d4..a9bf581c 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md @@ -1,4 +1,4 @@ -# Milestone: IOP Hot Path One-shot 실행 경로 +# Milestone: [route-01] IOP Hot Path One-shot 실행 경로 ## 위치 @@ -9,7 +9,8 @@ OpenAI-compatible 경계에 외부 `model=iop`으로 보이는 단일 one-shot 실행 표면을 제공하고, 내부에서는 빠른 cloud `Gemini 3.6 Flash`와 RTX 5090 local target `ornith-fast`를 조합하는 Hot Path를 스케치한다. 단순 요청은 Gemini가 즉시 완료하고, 일정 볼륨과 난이도가 있는 요청은 짧은 micro-plan, `ornith-fast` 실행, Gemini 리뷰와 최대 1회의 보정으로 끝낸다. -이 경로의 1차 목적은 최대 품질이 아니라 end-to-end 속도를 최대화하면서 실사용에 충분한 품질을 확보하는 것이며, durable Plan/Milestone 작업 루프와는 독립된 제품 경로로 유지한다. +이 경로의 1차 목적은 최대 품질이 아니라 end-to-end 속도를 최대화하면서 실사용에 충분한 품질을 확보하는 것이다. +동시에 이 마일스톤은 후속 [`OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅`](openai-compatible-hybrid-request-execution-routing.md)의 첫 vertical slice로서, model advisory와 Edge 최종 판정, request-local 실행 profile, route evidence의 기본 계약을 세운다. ## 상태 @@ -23,6 +24,7 @@ OpenAI-compatible 경계에 외부 `model=iop`으로 보이는 단일 one-shot - [ ] Gemini 리뷰와 최대 1회 보정의 입력, 종료 판정, timeout·실패·부분 결과 처리 방식을 확정한다. - [ ] 최대 속도를 1차 목표로 측정할 latency budget과 실사용 품질 하한을 함께 확정한다. - [ ] provider/model alias, route policy, stage budget과 관측 항목의 설정 소유권을 확정한다. +- [ ] Hot Path decision/evidence envelope가 후속 범용 하이브리드 라우팅과 호환되도록 `execution_shape`, advisory, Edge override, fallback과 policy version을 확정한다. - [ ] API/config/composite lifecycle 계약 구현으로 승격할 때 SDD와 후속 구현 단위를 확정한다. ## 구현 잠금 @@ -47,10 +49,12 @@ OpenAI-compatible 경계에 외부 `model=iop`으로 보이는 단일 one-shot - cloud target `Gemini 3.6 Flash`가 최초 triage, 단순 요청의 직접 응답, micro-plan 생성과 local 결과 리뷰를 담당하는 고정 baseline - RTX 5090에서 제공되는 local target `ornith-fast`가 micro-plan에 따라 일정 볼륨의 one-shot 작업을 수행하는 고정 baseline - 요청의 볼륨, 난이도, context, tool/workspace capability와 위험 신호를 이용한 2~3단계 내부 등급 후보 +- deterministic request facts/hard gate를 먼저 계산하고 Gemini가 의미·난이도 advisory를 반환한 뒤 Edge arbiter가 최종 route를 확정하는 권한 경계 - 단순 요청은 local hop과 review 없이 Gemini 응답으로 바로 종료하는 최단 경로 - local 실행 요청은 durable Plan 문서가 아닌 bounded micro-plan prompt를 만들고 `ornith-fast` 결과를 Gemini가 리뷰한 뒤 필요한 경우 최대 1회만 보정하는 경로 - 품질 향상을 위한 추가 model hop보다 end-to-end latency, time-to-first-useful-result와 bounded completion을 우선하는 stage budget - 외부에는 한 번의 `iop` model 요청과 최종 응답으로 보이되 내부에는 triage, direct/local route, review, correction, latency와 terminal outcome을 안전하게 관측하는 방향 +- 후속 cloud-first/Local RAG router가 재사용할 수 있는 versioned decision/evidence envelope의 최소 형태 ## 기능 @@ -59,7 +63,7 @@ OpenAI-compatible 경계에 외부 `model=iop`으로 보이는 단일 one-shot 외부의 단일 모델 호출을 내부 composite route와 속도 우선 등급 판정으로 연결하는 capability를 묶는다. - [ ] [iop-model-surface] OpenAI-compatible `model=iop`이 기존 model route 규칙을 보존하면서 Hot Path composite execution으로 진입하고 `/v1/models`와 성공·오류 응답에서 일관된 외부 identity를 제공한다. -- [ ] [gemini-triage] `Gemini 3.6 Flash`가 요청 볼륨, 난이도, context, capability와 위험 신호를 bounded 구조로 판정하고 direct 또는 local-work 등급과 판단 근거를 반환한다. +- [ ] [gemini-triage] `Gemini 3.6 Flash`가 요청 볼륨, 난이도, context, capability와 위험 신호를 bounded advisory로 반환하고, Edge arbiter가 hard gate와 live capability를 적용해 direct 또는 guided-local profile을 최종 확정한다. - [ ] [direct-complete] direct 등급은 local 호출과 별도 review 없이 같은 Gemini 호출의 결과를 최종 응답으로 사용해 가장 짧은 종료 경로를 제공한다. - [ ] [route-boundary] invalid·불확실·범위 초과 판정이 Hot Path 안에서 무제한 추론이나 durable workflow 진입을 만들지 않고 계약된 terminal 결과로 끝난다. @@ -85,7 +89,7 @@ Hot Path가 최대 품질 경쟁이 아니라 빠른 실용 경로라는 목표 - [ ] [latency-budget] direct와 local-work 등급별 전체 latency, cloud/local stage timeout과 추가 hop 상한이 정의되고 속도 회귀를 검출할 수 있다. - [ ] [quality-floor] 대표 one-shot 요청 세트에서 허용 가능한 정확성·완결성 하한을 정의하되 품질 점수를 높이기 위한 추가 stage는 latency budget을 넘지 않는다. -- [ ] [route-observability] target identity, 등급, stage timing, review/correction 여부와 terminal outcome을 raw prompt·output·credential 없이 관측할 수 있다. +- [ ] [route-observability] route id, target identity, model advisory, Edge override, execution shape, stage timing, review/correction 여부와 terminal outcome을 raw prompt·output·credential 없이 관측할 수 있다. - [ ] [hot-path-smoke] 실제 Gemini cloud target과 RTX 5090 `ornith-fast`를 사용해 direct, local pass, 단일 보정, 범위 초과와 target unavailable 경로를 검증한다. ## 완료 리뷰 @@ -102,9 +106,9 @@ Hot Path가 최대 품질 경쟁이 아니라 빠른 실용 경로라는 목표 - durable Plan/Milestone/CODE_REVIEW artifact 생성, 여러 task 연결, background 실행, 중단 후 재개와 완료 알림을 담당하는 에이전트 작업 루프 오케스트레이션 - Hot Path 실패나 범위 초과 요청을 자동으로 Plan/Milestone 작업 루프에 편입하는 동작 - 여러 번의 review·repair, 무제한 retry, 장기 session과 사람 승인 대기 상태 -- 모든 cloud/local model을 동적으로 조합하는 범용 planner/generator/verifier framework +- 모든 cloud/local model을 동적으로 조합하는 범용 planner/generator/verifier framework. 이는 후속 하이브리드 라우팅 마일스톤에서 다룬다. - provider 설치, 모델 다운로드, RTX 5090 lifecycle·qualification과 credential 관리 -- RAG, 장기 기억, 누적 대화 context 최적화와 학습 기반 route threshold 자동 조정 +- RAG, 장기 기억, 누적 대화 context 최적화와 학습 기반 route threshold 자동 조정. route evidence 기반 Local RAG 전환은 별도 후속 마일스톤에서 다룬다. ## 작업 컨텍스트 @@ -114,10 +118,11 @@ Hot Path가 최대 품질 경쟁이 아니라 빠른 실용 경로라는 목표 - 표준선(선택): `Gemini 3.6 Flash`와 `ornith-fast`는 Hot Path baseline target으로 설정에서 명시하고, core 내부에는 외부 `model` id와 provider id, target 문자열의 의미를 섞어 하드코딩하지 않는다. - 표준선(선택): end-to-end 속도와 bounded completion이 1차 최적화 목표이며, 품질은 정한 하한을 만족하는 범위에서 최대한 확보한다. 미미한 품질 향상을 위해 stage 수를 늘리지 않는다. - 표준선(선택): micro-plan은 한 요청 안의 transient directive이며 durable Plan/Milestone artifact가 아니다. review와 correction을 포함해 전체 실행은 one-shot terminal lifecycle 안에서 닫힌다. -- 표준선(선택): Hot Path는 Chronos의 일반 요청 triage/scoped workflow와 요청 분류, artifact, continuation, retry와 완료 상태를 공유하지 않는다. provider 호출, admission, cancellation, 출력 검증과 관측 같은 하위 runtime capability만 재사용할 수 있다. -- 표준선(선택): [단계 호출과 검증 최적화 MVP](knowledge-tool-validation-optimization.md)는 범용 staged validation mode 후보이고, Hot Path는 고정 target 조합과 latency budget을 소유하는 별도 제품 경로다. -- 큐 배치: IOP Agent Runtime 선행 분리 Milestone 추가에 따라 현재 전역 실행 순서 4번이다. 이 번호는 dependency가 아니라 기본 선택 우선순위다. +- 표준선(선택): Hot Path는 외부 workflow product의 요청 분류, 계약, 상태, 실행과 연결하지 않는다. 여기서 plan/review는 오직 하나의 IOP 요청 안에서 닫히는 transient inference stage다. +- 표준선(선택): [단계 호출과 검증 최적화 MVP](knowledge-tool-validation-optimization.md)는 request-local staged profile을 올바르게 일반화하고, Hot Path는 고정 target 조합과 latency budget을 먼저 검증하는 첫 profile이다. 두 결과는 후속 [하이브리드 요청 수준·실행 형태 라우팅](openai-compatible-hybrid-request-execution-routing.md)에서 연결한다. +- 표준선(선택): model은 route advisory만 제공하고 Edge arbiter가 hard gate, capability, health, budget을 적용해 execution shape와 stage target을 최종 결정한다. Node는 확정된 stage 실행만 담당한다. +- 큐 배치: 현재 전역 실행 순서 2번이다. 이 번호는 dependency가 아니라 기본 선택 우선순위다. - 선행 작업: 없음 - 참조·연결 작업: [단계 호출과 검증 최적화 MVP](knowledge-tool-validation-optimization.md), [요청 실행 로그와 Usage Ledger 기반](../../operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md) -- 후속 작업: Hot Path 구현 계획과 SDD, target·endpoint 확대, 평가 기반 threshold 조정 +- 후속 작업: Hot Path 구현 계획과 SDD, [단계 호출과 검증 최적화 MVP](knowledge-tool-validation-optimization.md), [하이브리드 요청 수준·실행 형태 라우팅](openai-compatible-hybrid-request-execution-routing.md), [RAG 기반 Local Routing Model 운영 전환](rag-local-routing-model-operations.md) - 확인 필요: `구현 잠금 > 결정 필요` diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md index 61638289..8abb443e 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md @@ -1,4 +1,4 @@ -# Milestone: 단계 호출과 검증 최적화 MVP +# Milestone: [route-02] 단계 호출과 검증 최적화 MVP ## 위치 @@ -7,8 +7,9 @@ ## 목표 -로컬 모델 성능 향상을 위해 요청 의도 분석, 실제 작업, 검증과 runtime schema 강제를 나누는 단계 호출 실행 모드를 스케치한다. -검증 실패 시 어느 단계로 되돌릴지, tool/schema 강제를 어느 경계에서 적용할지, 외부 소비자가 어떤 모드로 선택할지를 정하되, 세부 API와 구현은 사용자 검토 뒤 구체화한다. +요청 난이도와 작업 특성에 맞춰 analysis directive, generation, verification을 분리할 수 있는 request-local 단계 호출 실행 형태를 스케치한다. +이 마일스톤은 폐기된 범용 단계 호출 아이디어를 단순히 되살리는 것이 아니라, [`IOP Hot Path One-shot 실행 경로`](iop-hot-path-one-shot-execution.md)의 micro-plan/review를 일반화해 후속 Edge 하이브리드 라우터가 선택할 수 있는 올바른 실행 profile로 정의한다. +각 단계는 같은 요청의 bounded lifecycle 안에서 끝나며, durable Plan/Review artifact나 workflow 상태를 만들지 않는다. ## 상태 @@ -16,37 +17,50 @@ ## 승격 조건 -- [ ] 단계 호출의 MVP 역할 분리를 확정한다. +- [ ] analysis directive, generation, verification의 MVP 역할과 단계 생략 조건을 확정한다. - [ ] tool call/schema 강제와 output validation의 최소 책임 경계를 결정한다. -- [ ] 검증 실패 시 회귀 정책과 사용자 노출 방식을 결정한다. -- [ ] OpenAI-compatible metadata, A2A, IOP native 중 어떤 표면에서 실행 모드를 선택할지 결정한다. +- [ ] 검증 실패 시 어느 단계로 회귀할지와 요청 전체 retry·latency budget을 결정한다. +- [ ] `execution_shape`와 stage binding을 Edge가 명시하고 Node가 그대로 실행하는 계약을 확정한다. +- [ ] Hot Path profile과 staged profile이 공유할 decision/stage evidence 최소 schema를 확정한다. +- [ ] API/config/event schema 구현으로 승격할 때 필수 SDD를 작성·승인한다. ## 구현 잠금 - 상태: 잠금 +- SDD: 불필요 +- SDD 문서: 없음 +- SDD 사유: 현재는 request-local 단계 역할과 하이브리드 라우팅 연결을 바로잡는 스케치다. 실행 shape, stage binding, validation/retry 계약 구현으로 승격할 때 SDD가 필요하다. +- 잠금 해제 조건: 아래 체크리스트 + - [ ] 승격 조건의 미정 항목이 해소되어 있다. + - [ ] Hot Path에서 재사용할 계약과 이 마일스톤에서 일반화할 계약이 분리되어 있다. + - [ ] 구현 가능한 MVP와 후속 profile 확장 범위가 분리되어 있다. + - [ ] 필요한 SDD가 작성·승인되어 있다. - 결정 필요: 아래 체크리스트 - - [ ] 1차 모델, 2차 모델, 3차 모델의 역할을 planner/generator/verifier로 나눌지 다른 이름과 경계로 둘지 결정한다. - - [ ] runtime schema 강제를 Edge API, Node adapter, 별도 validation worker 중 어디에서 시작할지 결정한다. - - [ ] 검증 실패 시 자동 retry/rollback을 기본으로 할지, 사용자 승인 뒤 재시도할지 결정한다. + - [ ] analysis/generation/verification 각 단계의 입력·출력과 생략 가능 조건을 결정한다. + - [ ] runtime schema 강제를 Edge validator, Node adapter, 별도 validation stage 중 어디에서 시작할지 결정한다. + - [ ] validation failure 시 generation correction, analysis 재생성, terminal failure 중 허용할 경로와 최대 횟수를 결정한다. + - [ ] 명시적 client profile 선택을 허용할지, Edge route decision만 허용할지, 둘을 허용하면 우선순위를 어떻게 둘지 결정한다. ## 범위 -- 요청 의도 분석, tool call 계획, 실제 작업, 검증/schema 강제의 단계 호출 MVP 경계 -- validation 실패 시 planner/generator/verifier 중 어느 단계로 회귀할지에 대한 정책 후보 -- 단순 부하 라우팅과 하네스 기반 검증/재시도 모드의 책임 분리 -- 외부 소비자가 선택 가능한 실행 모드 후보 +- 한 IOP 요청 안에서만 유지되는 analysis directive, generation, verification의 bounded stage contract +- 단순 요청에서는 analysis/review 단계를 생략하고 필요한 요청에만 단계 호출을 적용하는 execution profile +- 각 stage에 대한 Edge의 명시적 adapter/target/capability binding과 Node의 실행-only 책임 +- validation failure 시 bounded correction, 이전 단계 회귀, fallback, terminal failure 정책 +- tool call/schema 강제와 output validation의 적용 지점 및 stage evidence +- Hot Path의 direct/guided-local profile과 호환되는 공통 decision/stage envelope ## 기능 -### Epic: [stage-validate] Staged Validation Mode +### Epic: [stage-validate] Request-local Staged Validation Profile -단계 호출과 검증 모드를 구현 계획 전 검토 가능한 수준으로 나누는 산출물을 묶는다. +단계 호출과 검증을 Edge 하이브리드 라우터가 안전하게 선택할 수 있는 실행 profile로 구체화하는 산출물을 묶는다. -- [ ] [role-split] 의도 분석, 실제 작업, 검증/schema 강제의 MVP 역할 경계가 정리되어 있다. -- [ ] [schema-policy] tool call과 runtime schema 강제의 최소 적용 지점 후보가 정리되어 있다. -- [ ] [retry-route] 검증 실패 시 회귀와 retry/fallback 정책 후보가 정리되어 있다. -- [ ] [mode-surface] 외부 소비자가 단계 호출 모드를 선택할 표면 후보가 정리되어 있다. -- [ ] [mvp-review] 사용자가 단계 호출 MVP 범위와 2차 후보를 검토했다. +- [ ] [role-split] analysis directive, generation, verification의 입력·출력·생략 조건과 transient 책임 경계가 정리되어 있다. +- [ ] [schema-policy] tool call과 runtime schema 강제의 최소 적용 지점과 실패 evidence가 정리되어 있다. +- [ ] [retry-route] validation failure 시 correction, 이전 단계 회귀, fallback과 terminal failure가 요청 전체 budget 안에서 정리되어 있다. +- [ ] [shape-contract] Edge가 execution shape와 stage별 adapter/target을 확정하고 Node가 이를 재판정 없이 실행하는 계약 후보가 정리되어 있다. +- [ ] [mvp-review] Hot Path 공통 부분, staged profile 고유 부분, 후속 하이브리드 라우터 연결 범위를 사용자가 검토했다. ## 완료 리뷰 @@ -60,17 +74,19 @@ ## 범위 제외 +- durable Plan/Review 문서, task graph, 승인 상태, 중단 후 재개, background workflow +- 외부 workflow product와의 호출, 상태, 계약, artifact 또는 lifecycle 공유 +- local routing model 학습·RAG index·shadow/canary 운영 전환 - 장기 기억/RAG update loop 구현 -- Claude advisor류 별도 조언자 UX - 누적 요청 컨텍스트 구성·압축과 target별 token budget 최적화 -- cloud fallback과 품질 평가 feedback 제품화 -- 세부 API/schema 구현 확정 +- 모든 route를 model이 최종 결정하거나 Node가 execution shape를 자율 판정하는 설계 ## 작업 컨텍스트 -- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `packages/go/policy`, `packages/go/jobs`, `proto/iop`, [openai-compatible-api.md](../../../../agent-contract/outer/openai-compatible-api.md) -- 표준선(선택): 외부 실행 호출 계약은 OpenAI-compatible shape를 우선 유지하고, IOP 고유 문맥은 `metadata`나 IOP native endpoint의 명시 필드로 전달한다. -- 표준선(선택): 단계 호출은 단순 provider 라우팅과 충돌하는 책임이 아니라, 사용자가 선택할 수 있는 IOP 실행 모드 후보로 본다. -- 선행 작업: Edge 모델 그룹 Queue 스케줄링 전환, 운영 관측과 Provider 관리 -- 후속 작업: [Provider 입력 컨텍스트 선택과 축소](request-context-assembly-optimization.md), [장기 기억과 RAG 업데이트 사이클 (2차)](long-term-memory-rag-second-wave.md), [Advisor와 Context Hook 확장 (2차)](advisor-context-hook-second-wave.md) -- 확인 필요: 역할 분리, schema 강제 지점, 회귀/retry 정책, 실행 모드 선택 표면 +- 관련 경로: `apps/edge`, `apps/node`, `packages/go/policy`, `proto/iop`, [OpenAI-Compatible API Contract](../../../../agent-contract/outer/openai-compatible-api.md) +- 표준선(선택): 이 마일스톤의 plan/review는 하나의 요청 안에서만 존재하는 analysis directive와 verification stage다. durable artifact나 workflow process와 개념·상태·계약을 공유하지 않는다. +- 표준선(선택): Edge가 요청 사실, hard gate와 route policy에 따라 execution shape 및 stage별 adapter/target을 확정한다. Node는 전달받은 stage를 실행·취소하고 상태·usage를 보고한다. +- 표준선(선택): 외부 client의 명시적 profile 선택을 지원하더라도 최종 허용 여부와 stage binding은 Edge arbiter가 결정한다. +- 선행 작업: [IOP Hot Path One-shot 실행 경로](iop-hot-path-one-shot-execution.md) +- 후속 작업: [OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅](openai-compatible-hybrid-request-execution-routing.md), [RAG 기반 Local Routing Model 운영 전환](rag-local-routing-model-operations.md) +- 확인 필요: `구현 잠금 > 결정 필요` diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/llm-judged-missing-tool-call-retry-gate.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/llm-judged-missing-tool-call-retry-gate.md index 79eb7392..b6a202d1 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/llm-judged-missing-tool-call-retry-gate.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/llm-judged-missing-tool-call-retry-gate.md @@ -1,4 +1,4 @@ -# Milestone: LLM 판별 기반 Missing Tool Call 재시도 Gate +# Milestone: [judge-01] LLM 판별 기반 Missing Tool Call 재시도 Gate ## 위치 diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/long-term-memory-rag-second-wave.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/long-term-memory-rag-second-wave.md index 27208cf6..c8327c8f 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/long-term-memory-rag-second-wave.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/long-term-memory-rag-second-wave.md @@ -1,4 +1,4 @@ -# Milestone: 장기 기억과 RAG 업데이트 사이클 (2차) +# Milestone: [memory-01] 장기 기억과 RAG 업데이트 사이클 (2차) ## 위치 diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-hybrid-request-execution-routing.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-hybrid-request-execution-routing.md new file mode 100644 index 00000000..0671ba79 --- /dev/null +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-hybrid-request-execution-routing.md @@ -0,0 +1,131 @@ +# Milestone: [route-03] OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅 + +## 목표 + +- 폐기된 [`OpenAI-compatible Hybrid Routing · Context Optimization`](../../../archive/phase/routing-policy-model-orchestration/milestones/openai-compatible-hybrid-routing-context-optimization.md)의 핵심 의도 중 **IOP 내부 요청 난이도·실행 형태·모델 조합 라우팅**만 현재 책임 경계에 맞게 복원한다. +- IOP Edge가 요청의 난이도, 기능 요구, 컨텍스트 규모, 지연·비용 예산, 장치·모델 가용성을 종합해 요청-local `execution_shape`와 각 단계의 adapter/target을 최종 결정한다. +- 초기 운영에서는 cloud frontier model이 의미 분류와 난이도 판정의 advisory를 제공하고, deterministic hard gate와 Edge arbiter가 최종 결정을 소유한다. +- [`IOP Hot Path One-shot Execution`](iop-hot-path-one-shot-execution.md)이 구축한 고정 profile과 [`Knowledge/Tool 단계 호출 · 검증 최적화`](knowledge-tool-validation-optimization.md)가 정리한 request-local plan/review 단계를 하나의 일반화된 하이브리드 라우팅 정책으로 연결한다. +- route decision/evidence를 축적해 후속 [`RAG 기반 Local Routing Model 운영 전환`](rag-local-routing-model-operations.md)이 동일한 decision contract를 대체 구현할 수 있게 한다. + +## 상태 + +[스케치] + +## 복원 원칙 + +- archive의 폐기 문서는 당시 스냅샷으로 유지하고 직접 수정하지 않는다. +- [`Knowledge/Tool 단계 호출 · 검증 최적화`](knowledge-tool-validation-optimization.md)는 폐기본 전체의 대체가 아니라 request-local plan/review 실행 형태만 이어받은 부분 후속이다. 요청 수준 route selection, cloud-first evidence, local router 전환은 이 마일스톤과 그 후속에서 복원한다. +- 복원 범위에는 과거 설계의 artifact lane, grade, workflow lifecycle, 자동화 런타임 소유권을 포함하지 않는다. +- 이 마일스톤의 `plan/review`는 단일 IOP 요청 안에서 끝나는 transient inference stage다. 저장형 계획 문서, 승인 상태, continuation, workspace mutation을 만들지 않는다. +- 외부 workflow product는 IOP Edge/Node 라우팅 계약, 상태, 실행 흐름에 연결하지 않는다. +- IOP Node는 Edge가 확정한 stage별 adapter/target을 실행·취소하고 상태·usage를 보고할 뿐, 요청 난이도나 실행 형태를 판정하지 않는다. + +## 선행 작업 + +- [`IOP Hot Path One-shot Execution`](iop-hot-path-one-shot-execution.md) +- [`Knowledge/Tool 단계 호출 · 검증 최적화`](knowledge-tool-validation-optimization.md) + +## 승격 조건 + +- `execution_shape`, stage binding, advisory, hard-gate reason, confidence/fallback을 포함한 route decision contract가 확정된다. +- cloud judge와 Edge arbiter 사이의 권한 경계 및 model output 불신 원칙이 확정된다. +- `direct`, Hot Path guided-local, request-local plan/generate/review 형태의 최소 profile taxonomy가 확정된다. +- route 판단 실패, timeout, low-confidence, target unavailable에 대한 deterministic fallback이 확정된다. +- route evidence의 저장 위치, 보존 기간, 민감정보 제거, 학습 후보 승격 기준이 확정된다. +- API/config/event schema가 수반되는 구현 전 필수 SDD가 작성·승인된다. + +## 구현 잠금 + +- 상태: 잠금 +- SDD: 불필요 +- SDD 문서: 없음 +- SDD 사유: 현재는 복원 범위와 후속 마일스톤 관계만 재정의하는 개념 스케치다. 구현 마일스톤 승격 시 API/config/event schema와 라우팅 권한 경계를 다루는 SDD가 필요하다. +- 잠금 해제 조건: 아래 체크리스트 + - [ ] 승격 조건의 미정 항목이 모두 해소되어 있다. + - [ ] Hot Path/staged profile에서 재사용할 계약과 이 마일스톤의 일반화 범위가 분리되어 있다. + - [ ] cloud-first MVP와 RAG local router 후속 범위가 분리되어 있다. + - [ ] 필요한 SDD가 작성·승인되어 있다. +- 결정 필요: 아래 체크리스트 + - [ ] 초기 `execution_shape` taxonomy와 profile별 난이도·비용·지연 임계값을 결정한다. + - [ ] cloud judge model, 호출 budget, timeout 및 judge 부재 시 기본 profile을 결정한다. + - [ ] route evidence 최소 표본·품질·보존 기간과 민감정보 제거 기준을 결정한다. + +## 범위 + +### 1. Route decision contract + +- 모든 route decision은 provider-specific 응답이 아니라 IOP 공통 envelope로 정규화한다. +- 최소 필드는 `route_id`, `execution_shape`, stage별 `adapter_id/target_id`, hard-gate reason, advisory 요약, confidence, fallback, timing, policy version이다. +- cloud judge는 난이도·능력 적합성·예상 작업 형태를 제안할 수 있지만 최종 target과 실행 권한을 갖지 않는다. +- Edge arbiter는 policy/config, live capability, qualification, health, budget으로 advisory를 검증하고 최종 결정을 확정한다. + +### 2. Request-local execution profile + +- `direct`: 단일 model call로 충분한 단순 요청이다. +- `guided-local`: cloud model이 짧은 analysis directive를 만들고 local worker가 생성하며 cloud model이 결과를 검토한다. Hot Path가 이 profile의 첫 vertical slice다. +- `staged`: analysis/generation/verification을 서로 다른 adapter/target에 명시적으로 바인딩하는 일반 request-local 형태다. +- 각 profile은 단계 수, 최대 재시도, review budget, timeout, fallback을 bounded contract로 가진다. +- profile 종료와 함께 transient stage state를 폐기하고 durable workflow state를 남기지 않는다. + +### 3. Cloud-first 판단과 안전 장치 + +- request facts와 deterministic hard gate를 먼저 계산한 뒤 cloud judge에 필요한 최소 semantic context만 전달한다. +- hard gate는 secret policy, unsupported capability, context overflow, deadline, cost ceiling, target health를 포함한다. +- cloud judge timeout·오류·low-confidence·schema failure는 Edge의 보수적 기본 profile로 수렴한다. +- model이 반환한 target, tool, parameter는 capability registry와 정책을 통과하기 전까지 실행하지 않는다. + +### 4. Route evidence + +- request 원문 전체가 아니라 feature snapshot, judge advisory, arbiter override, 선택 결과, latency/cost, 검증 결과, fallback reason을 학습 가능한 evidence로 정규화한다. +- [`요청 실행 로그와 Usage Ledger 기반`](../../operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md)과 [`Provider-Device-Model Qualification 리포트와 Lifecycle 관리`](../../operational-observability-provider-management/milestones/provider-device-model-qualification-report.md)의 운영 지표를 참조하되, 라우팅 정책 소유권은 Edge에 유지한다. +- evidence schema는 후속 local router가 같은 입력·출력 계약을 shadow replay할 수 있어야 한다. +- 민감정보 제거와 retention을 통과하지 못한 기록은 학습 corpus 후보에 포함하지 않는다. + +## 기능 + +### Epic: [route-decision] Route Decision + +- [ ] [decision-contract] 공통 decision/evidence envelope와 versioning을 정의한다. +- [ ] [hard-gates] capability·security·context·budget·health 기반 deterministic gate를 정의한다. +- [ ] [cloud-judge] cloud model advisory 입력/출력, timeout, confidence 계약을 정의한다. +- [ ] [edge-arbiter] advisory 검증, override reason, 최종 profile/target 확정 정책을 구현한다. + +### Epic: [execution-shape] Execution Shape + +- [ ] [shape-registry] request-local execution profile registry와 bounded stage contract를 구현한다. +- [ ] [hot-path-profile] Hot Path의 direct/guided-local 경로를 profile로 편입한다. +- [ ] [staged-profile] analysis/generation/verification 단계를 일반 profile로 편입한다. +- [ ] [stage-binding] 각 stage를 adapter/target/capability에 명시적으로 바인딩한다. + +### Epic: [route-evidence] Route Evidence + +- [ ] [route-events] judge/arbiter/실행 결과를 연결하는 route event를 기록한다. +- [ ] [dataset-curation] redaction, retention, 중복 제거, 품질 label 규칙을 정의한다. +- [ ] [eval-gate] cloud 판단과 실제 결과의 일치도·비용·지연 평가 기준을 정의한다. +- [ ] [local-handoff] 후속 RAG local router가 소비할 corpus/export contract를 고정한다. + +## 제외 범위 + +- 외부 workflow lifecycle, plan artifact, review artifact, workspace 상태와의 연동 +- IOP Node가 요청 난이도, execution shape, model 정책을 자율 판정하는 기능 +- 이 마일스톤에서 local routing model을 production primary로 승격하는 작업 +- 장기 기억용 repository RAG와 routing evidence corpus의 통합 +- 사용자 승인 없는 irreversible side effect 자동 실행 + +## 완료 리뷰 + +- 상태: 없음 +- 요청일: 없음 +- 완료 근거: 복원 범위와 선후 관계를 정리한 스케치이며 승격 조건과 기능 Task가 아직 충족되지 않았다. +- 검토 항목: 없음 +- 리뷰 코멘트: 없음 + +## 작업 컨텍스트 + +- Phase: [`Knowledge / Tool 최적화 확장`](../PHASE.md) +- 복원 근거: [`OpenAI-compatible Hybrid Routing · Context Optimization`](../../../archive/phase/routing-policy-model-orchestration/milestones/openai-compatible-hybrid-routing-context-optimization.md) +- 선행: [`IOP Hot Path One-shot Execution`](iop-hot-path-one-shot-execution.md), [`Knowledge/Tool 단계 호출 · 검증 최적화`](knowledge-tool-validation-optimization.md) +- 후속: [`RAG 기반 Local Routing Model 운영 전환`](rag-local-routing-model-operations.md) +- 큐 배치: [`Knowledge/Tool 단계 호출 · 검증 최적화`](knowledge-tool-validation-optimization.md) 바로 뒤에 배치한다. +- 확인 필요: `구현 잠금 > 결정 필요` diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-incomplete-tool-call-syntax-gate.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-incomplete-tool-call-syntax-gate.md index b6ce21e3..82a813bd 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-incomplete-tool-call-syntax-gate.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-incomplete-tool-call-syntax-gate.md @@ -1,4 +1,4 @@ -# Milestone: OpenAI-compatible Incomplete Tool Call Syntax Gate +# Milestone: [output-02] OpenAI-compatible Incomplete Tool Call Syntax Gate ## 위치 diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-output-validation-filters.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-output-validation-filters.md index 76cff409..d19427c6 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-output-validation-filters.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-output-validation-filters.md @@ -1,4 +1,4 @@ -# Milestone: OpenAI-compatible 출력 검증 필터 +# Milestone: [output-01] OpenAI-compatible 출력 검증 필터 ## 위치 diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-runtime-output-integrity-filter.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-runtime-output-integrity-filter.md index 10727cd5..43b5bafc 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-runtime-output-integrity-filter.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/openai-compatible-runtime-output-integrity-filter.md @@ -1,4 +1,4 @@ -# Milestone: OpenAI-compatible Runtime Output Integrity Filter +# Milestone: [output-03] OpenAI-compatible Runtime Output Integrity Filter ## 위치 diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/rag-local-routing-model-operations.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/rag-local-routing-model-operations.md new file mode 100644 index 00000000..a963d68e --- /dev/null +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/rag-local-routing-model-operations.md @@ -0,0 +1,118 @@ +# Milestone: [route-04] RAG 기반 Local Routing Model 운영 전환 + +## 목표 + +- [`OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅`](openai-compatible-hybrid-request-execution-routing.md)의 cloud-first 운영에서 충분한 route evidence가 축적되면, 동일한 decision contract를 반환하는 RAG 기반 local routing model을 운영한다. +- cloud judge의 과거 판단만 복제하지 않고 실제 실행 품질·지연·비용·fallback 결과가 결합된 curated corpus를 retrieval 근거로 사용한다. +- local router를 shadow → canary → primary 순으로 승격하고, 불확실하거나 분포 밖인 요청은 cloud judge 또는 deterministic Edge policy로 fallback한다. +- cloud model은 초기 teacher와 장기 fallback·drift 재평가 역할을 유지하며, 운영 기본 경로는 검증된 local router로 점진 전환한다. + +## 상태 + +[스케치] + +## 구분 원칙 + +- 이 마일스톤의 RAG는 **라우팅 판정 evidence 검색**을 위한 것으로, [`Long-term Memory RAG 2nd Wave`](long-term-memory-rag-second-wave.md)의 repository 장기 기억·작업 컨텍스트 RAG와 corpus, index, retention, 평가 지표를 공유하지 않는다. +- local model은 advisory를 반환하며 최종 결정 권한은 계속 IOP Edge arbiter에 있다. +- 저장형 Plan/Review artifact와 외부 workflow 상태는 입력 feature나 retrieval corpus에 포함하지 않는다. +- IOP Node는 확정된 stage target을 실행할 뿐 local router를 호스팅하거나 라우팅을 판정하지 않는다. + +## 선행 작업 + +- [`OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅`](openai-compatible-hybrid-request-execution-routing.md) +- [`요청 실행 로그와 Usage Ledger 기반`](../../operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md) +- [`Provider-Device-Model Qualification 리포트와 Lifecycle 관리`](../../operational-observability-provider-management/milestones/provider-device-model-qualification-report.md) + +## 승격 조건 + +- cloud-first route evidence가 합의된 최소 표본·coverage·품질·retention gate를 통과한다. +- routing corpus schema, embedding/index 전략, retrieval freshness와 삭제 전파 방식이 확정된다. +- local model 입력/출력이 기존 route decision contract와 호환되고 confidence/abstain 의미가 확정된다. +- shadow 평가의 disagreement, regret, latency, cost, safety 지표와 통과 기준이 확정된다. +- canary 대상, 비율, 자동 rollback, cloud fallback budget이 확정된다. +- API/config/event schema 및 model lifecycle을 다루는 필수 SDD가 작성·승인된다. + +## 구현 잠금 + +- 상태: 잠금 +- SDD: 불필요 +- SDD 문서: 없음 +- SDD 사유: 현재는 최종 운영 목표와 선행 gate를 정의하는 개념 스케치다. 구현 마일스톤 승격 시 corpus/index, model lifecycle, shadow/canary/rollback 계약을 다루는 SDD가 필요하다. +- 잠금 해제 조건: 아래 체크리스트 + - [ ] 승격 조건의 evidence·corpus·평가·rollout 기준이 모두 확정되어 있다. + - [ ] routing RAG와 repository 장기 기억 RAG의 corpus/index/retention 경계가 검증되어 있다. + - [ ] shadow MVP, canary, primary 승격 범위가 분리되어 있다. + - [ ] 필요한 SDD가 작성·승인되어 있다. +- 결정 필요: 아래 체크리스트 + - [ ] production 학습 corpus로 승격할 최소 표본·coverage·품질·보존 기간을 결정한다. + - [ ] local routing model, embedding model, index backend와 갱신 주기를 결정한다. + - [ ] 허용 disagreement/regret/latency 임계값, cloud audit 비율과 fallback budget을 결정한다. + +## 범위 + +### 1. Routing corpus + +- route feature, cloud advisory, Edge override, 선택 profile/target, 실제 품질·지연·비용, validation/fallback 결과를 연결한다. +- request 원문과 secret을 기본 저장하지 않고, redaction된 feature와 필요한 최소 retrieval evidence만 보존한다. +- 오래된 policy/model/version에 종속된 evidence는 freshness와 drift 정책에 따라 감쇠하거나 제외한다. +- corpus eligibility와 index deletion은 retention 삭제를 정확히 전파한다. + +### 2. RAG local router + +- 현재 request feature로 유사 route evidence를 검색하고, local model이 근거·confidence·abstain을 포함한 advisory를 반환한다. +- local advisory는 cloud judge와 같은 decision envelope를 사용해 Edge arbiter와 profile registry를 변경하지 않고 교체 가능해야 한다. +- retrieval miss, low-confidence, out-of-distribution, index unavailable은 cloud judge 또는 deterministic default로 fallback한다. +- retrieved evidence와 model output은 실행 권한이 아니며 hard gate를 우회할 수 없다. + +### 3. 운영 전환 + +- shadow에서 cloud decision과 local decision을 동시 평가하되 local 결과는 실행에 반영하지 않는다. +- canary에서는 합의된 요청군과 비율에만 local advisory를 적용하고 regret/safety 예산 초과 시 자동 rollback한다. +- primary 전환 뒤에도 sampling 기반 cloud audit와 drift detection으로 corpus/model refresh를 수행한다. +- model/index/policy version별 승격·rollback 이력을 유지한다. + +## 기능 + +### Epic: [route-corpus] Route Corpus + +- [ ] [evidence-gate] corpus 진입을 위한 표본·coverage·품질·privacy gate를 정의한다. +- [ ] [corpus-schema] feature/advisory/outcome/version 연결 schema를 고정한다. +- [ ] [retrieval-index] embedding, index partition, freshness, 삭제 전파를 구현한다. + +### Epic: [local-router] Local Router + +- [ ] [rag-input] request feature와 retrieval evidence 조합 입력을 정의한다. +- [ ] [decision-parity] cloud/local judge가 공유하는 decision envelope 호환성을 구현한다. +- [ ] [uncertainty-fallback] confidence, abstain, OOD, cloud/default fallback을 구현한다. + +### Epic: [route-rollout] Route Rollout + +- [ ] [shadow-eval] disagreement, regret, 품질, latency, cost를 shadow에서 평가한다. +- [ ] [canary-policy] 대상 요청군, 적용 비율, 예산과 safety gate를 정의한다. +- [ ] [promotion-rollback] primary 승격과 자동·수동 rollback 절차를 구현한다. +- [ ] [drift-refresh] sampling audit, drift 감지, corpus/model refresh를 운영한다. + +## 제외 범위 + +- repository 장기 기억·코드 검색·사용자 지식 검색을 위한 일반 RAG +- cloud model을 즉시 제거하거나 모든 요청을 local router로 강제하는 전환 +- Edge hard gate와 arbiter를 local model output으로 대체하는 설계 +- 외부 workflow 상태를 학습 feature로 사용하는 설계 +- IOP Node가 corpus/index/model policy를 관리하는 기능 + +## 완료 리뷰 + +- 상태: 없음 +- 요청일: 없음 +- 완료 근거: 최종 운영 목표와 선행 gate를 정리한 스케치이며 승격 조건과 기능 Task가 아직 충족되지 않았다. +- 검토 항목: 없음 +- 리뷰 코멘트: 없음 + +## 작업 컨텍스트 + +- Phase: [`Knowledge / Tool 최적화 확장`](../PHASE.md) +- 선행: [`OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅`](openai-compatible-hybrid-request-execution-routing.md), [`요청 실행 로그와 Usage Ledger 기반`](../../operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md), [`Provider-Device-Model Qualification 리포트와 Lifecycle 관리`](../../operational-observability-provider-management/milestones/provider-device-model-qualification-report.md) +- 구분 대상: [`Long-term Memory RAG 2nd Wave`](long-term-memory-rag-second-wave.md) +- 큐 배치: [`Provider-Device-Model Qualification 리포트와 Lifecycle 관리`](../../operational-observability-provider-management/milestones/provider-device-model-qualification-report.md) 바로 뒤에 배치한다. +- 확인 필요: `구현 잠금 > 결정 필요` diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/request-context-assembly-optimization.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/request-context-assembly-optimization.md index 82369db6..1d42c2fb 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/request-context-assembly-optimization.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/request-context-assembly-optimization.md @@ -1,4 +1,4 @@ -# Milestone: Provider 입력 컨텍스트 선택과 축소 +# Milestone: [context-01] Provider 입력 컨텍스트 선택과 축소 ## 위치 diff --git a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/tool-call-validator-model-gate-review.md b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/tool-call-validator-model-gate-review.md index aded09de..d954bf19 100644 --- a/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/tool-call-validator-model-gate-review.md +++ b/agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/tool-call-validator-model-gate-review.md @@ -1,4 +1,4 @@ -# Milestone: Tool Call 판정 모델 Gate 리뷰 +# Milestone: [judge-02] Tool Call 판정 모델 Gate 리뷰 ## 위치 diff --git a/agent-roadmap/phase/operational-observability-provider-management/PHASE.md b/agent-roadmap/phase/operational-observability-provider-management/PHASE.md index 20cff53b..fe163522 100644 --- a/agent-roadmap/phase/operational-observability-provider-management/PHASE.md +++ b/agent-roadmap/phase/operational-observability-provider-management/PHASE.md @@ -6,7 +6,7 @@ ## 목표 -IOP가 여러 Edge, Node, CLI Agent, local inference provider와 cloud API provider를 운영할 때 필요한 사용자/토큰/credential/사용량/로그/provider 상태 및 protocol profile 기준을 정리한다. +IOP가 여러 Edge, IOP Node, local inference provider와 cloud API provider를 운영할 때 필요한 사용자/토큰/credential/사용량/로그/provider 상태 및 protocol profile 기준을 정리한다. CLI agent, workspace, terminal과 workflow 운영은 IOP 제품 범위에서 제외한다. 이 Phase는 완성된 billing, enterprise IAM, provider marketplace를 바로 구현하지 않고, 1차 MVP에서 어떤 운영 데이터를 모으고 어떤 화면/명령으로 검토할지 스케치한다. provider 확장 Phase에서 검증한 Ollama, vLLM, SGLang, Lemonade 같은 추론 엔진은 provider/device/model 조합으로 관찰하고, 후반부에서는 모델 lifecycle capability와 qualification report를 운영 데이터로 축적하는 방향을 정리한다. cloud API provider는 Chat Completions 공통 profile과 Edge native Anthropic Messages 표면으로 수렴시키며, Control Plane이 principal token과 사용자별 provider credential slot의 원장을 소유한다. @@ -59,26 +59,26 @@ Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실 - 경로: [principal-provider-credential-slot-routing](../../archive/phase/operational-observability-provider-management/milestones/principal-provider-credential-slot-routing.md) - 요약: Control Plane을 IOP principal token과 provider credential의 원장으로 두고, 사용자/vendor별 여러 token slot과 optional alias를 명시적 model route에 결합해 선택된 credential만 안전하게 실행 경계에 주입한다. -- [계획] Provider 부하 메트릭과 Live Queue Dashboard - - 경로: [provider-load-metrics-queue-dashboard](milestones/provider-load-metrics-queue-dashboard.md) - - 요약: provider별 capacity 사용률, in-flight, queue 적체, queue wait를 Prometheus time series와 Grafana dashboard로 노출해 시간대별 live 부하 분석을 가능하게 한다. - -- [계획] Node Provider 실행 Liveness 관측과 안전 복구 - - 경로: [node-provider-execution-liveness-recovery](milestones/node-provider-execution-liveness-recovery.md) +- [계획] [observe-01] Node Provider 실행 Liveness 관측과 안전 복구 + - 경로: [[observe-01] Node Provider 실행 Liveness 관측과 안전 복구](milestones/node-provider-execution-liveness-recovery.md) - 요약: Node가 provider-originated 진행 신호의 5분 무응답을 request stall로 판정하고 provider health와 local attempt fence를 별도 확정하며, ingress recovery owner가 미커밋 요청만 기존 공통 budget 안에서 재실행한다. -- [스케치] 요청 실행 로그와 Usage Ledger 기반 - - 경로: [request-execution-log-usage-ledger-foundation](milestones/request-execution-log-usage-ledger-foundation.md) +- [계획] [observe-02] Provider 부하 메트릭과 Live Queue Dashboard + - 경로: [[observe-02] Provider 부하 메트릭과 Live Queue Dashboard](milestones/provider-load-metrics-queue-dashboard.md) + - 요약: provider별 capacity 사용률, in-flight, queue 적체, queue wait를 Prometheus time series와 Grafana dashboard로 노출해 시간대별 live 부하 분석을 가능하게 한다. + +- [스케치] [observe-03] 요청 실행 로그와 Usage Ledger 기반 + - 경로: [[observe-03] 요청 실행 로그와 Usage Ledger 기반](milestones/request-execution-log-usage-ledger-foundation.md) - 요약: 사용자 요청 하나의 device/provider/model 선택, queue/dispatch/start/first-token/end 시간, token breakdown, status/error를 구조화된 실행 로그와 usage ledger로 남기는 로그 시스템 개편 후보를 스케치한다. -- [스케치] Provider-Device-Model Qualification 리포트와 Lifecycle 관리 - - 경로: [provider-device-model-qualification-report](milestones/provider-device-model-qualification-report.md) - - 요약: provider catalog와 device 상태 기준선 뒤에, 여러 모델을 각 device/provider에서 측정하고 공식 공개 benchmark와 함께 보여주는 qualification 리포트, compatibility/performance/quality/lifecycle 비교 경계를 깊게 스케치한다. - -- [스케치] Provider Runtime 설정과 모델 획득 오케스트레이션 - - 경로: [provider-runtime-model-acquisition-orchestration](milestones/provider-runtime-model-acquisition-orchestration.md) +- [스케치] [provider-01] Provider Runtime 설정과 모델 획득 오케스트레이션 + - 경로: [[provider-01] Provider Runtime 설정과 모델 획득 오케스트레이션](milestones/provider-runtime-model-acquisition-orchestration.md) - 요약: IOP가 vLLM, vLLM-MLX, Lemonade 같은 provider runtime의 launch/profile 설정과 모델 후보 선정, 다운로드, 캐시, 검증, 적용 경계를 어디까지 소유할지 장기 후속 축으로 스케치한다. +- [스케치] [provider-02] Provider-Device-Model Qualification 리포트와 Lifecycle 관리 + - 경로: [[provider-02] Provider-Device-Model Qualification 리포트와 Lifecycle 관리](milestones/provider-device-model-qualification-report.md) + - 요약: provider catalog와 device 상태 기준선 뒤에, 여러 모델을 각 device/provider에서 측정하고 공식 공개 benchmark와 함께 보여주는 qualification 리포트, compatibility/performance/quality/lifecycle 비교 경계를 깊게 스케치한다. + ## Phase 경계 - Control Plane은 principal, IOP token과 외부 provider credential의 canonical store를 소유한다. Edge/Node provider health, capacity, queue와 실행 중 상태의 canonical store는 계속 Edge이며 Control Plane이 복제 소유하지 않는다. diff --git a/agent-roadmap/phase/operational-observability-provider-management/milestones/node-provider-execution-liveness-recovery.md b/agent-roadmap/phase/operational-observability-provider-management/milestones/node-provider-execution-liveness-recovery.md index 2788ed4e..50e766dc 100644 --- a/agent-roadmap/phase/operational-observability-provider-management/milestones/node-provider-execution-liveness-recovery.md +++ b/agent-roadmap/phase/operational-observability-provider-management/milestones/node-provider-execution-liveness-recovery.md @@ -1,4 +1,4 @@ -# Milestone: Node Provider 실행 Liveness 관측과 안전 복구 +# Milestone: [observe-01] Node Provider 실행 Liveness 관측과 안전 복구 ## 위치 @@ -77,7 +77,7 @@ request stall과 provider health를 운영자가 서로 다른 원인 축으로 ## 범위 제외 - `agent-task` Python dispatcher나 Node를 거치지 않는 직접 Pi/provider 호출의 감시·재시작 -- standalone `iop-agent` 또는 개별 agent가 자체 watchdog을 소유하는 구조 +- standalone supervisor 또는 개별 agent가 자체 watchdog을 소유하는 구조 - provider가 별도 reasoning/progress event를 내지 않을 때 내부에서 실제 추론 중인지 추정하는 기능 - 반복, tool-call syntax, schema, 출력 품질 같은 content filter 판정 - queue wait timeout, request 전체 hard timeout, provider capacity/routing score의 의미 변경 diff --git a/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md b/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md index c3369bf2..1a897811 100644 --- a/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md +++ b/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md @@ -1,4 +1,4 @@ -# Milestone: Provider-Device-Model Qualification 리포트와 Lifecycle 관리 +# Milestone: [provider-02] Provider-Device-Model Qualification 리포트와 Lifecycle 관리 ## 위치 diff --git a/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-load-metrics-queue-dashboard.md b/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-load-metrics-queue-dashboard.md index 4fe4eb4d..91e33a63 100644 --- a/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-load-metrics-queue-dashboard.md +++ b/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-load-metrics-queue-dashboard.md @@ -1,4 +1,4 @@ -# Milestone: Provider 부하 메트릭과 Live Queue Dashboard +# Milestone: [observe-02] Provider 부하 메트릭과 Live Queue Dashboard ## 위치 diff --git a/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-runtime-model-acquisition-orchestration.md b/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-runtime-model-acquisition-orchestration.md index ee53565a..e608b760 100644 --- a/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-runtime-model-acquisition-orchestration.md +++ b/agent-roadmap/phase/operational-observability-provider-management/milestones/provider-runtime-model-acquisition-orchestration.md @@ -1,4 +1,4 @@ -# Milestone: Provider Runtime 설정과 모델 획득 오케스트레이션 +# Milestone: [provider-01] Provider Runtime 설정과 모델 획득 오케스트레이션 ## 위치 @@ -99,6 +99,6 @@ runtime 설정과 모델 변경의 적용, rollback, 운영 상태 및 안전 - 표준선(선택): long-context admission은 routing 필요조건이며, provider runtime/model acquisition orchestration은 그 정책을 실제 runtime에서 만족하게 만드는 충분조건 후보이다. - 표준선(선택): vLLM/vLLM-MLX는 launch profile과 health/capacity verification부터 시작하고, Lemonade는 앱/API 설정 소유권 경계를 먼저 확인한다. - 표준선(선택): 모델 다운로드와 삭제는 disk/resource 영향이 크므로 초기에는 사용자 승인 기반 dry-run/apply 흐름을 우선한다. -- 선행 작업: Model Group Long-Context Admission, Provider-Device-Model Qualification 리포트와 Lifecycle 관리 +- 선행 작업: Model Group Long-Context Admission, Provider Catalog와 로컬 디바이스 상태 관리 - 후속 작업: route recommendation, model marketplace, cross-Edge/cloud fallback 고도화 - 확인 필요: provider runtime 설정 소유권, 모델 다운로드 자동화 수준, cache/delete/rollback 정책, 사용자 승인 경계 diff --git a/agent-roadmap/phase/operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md b/agent-roadmap/phase/operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md index e03bb66b..fac4e314 100644 --- a/agent-roadmap/phase/operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md +++ b/agent-roadmap/phase/operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md @@ -1,4 +1,4 @@ -# Milestone: 요청 실행 로그와 Usage Ledger 기반 +# Milestone: [observe-03] 요청 실행 로그와 Usage Ledger 기반 ## 위치 diff --git a/agent-roadmap/phase/personal-edge-packaging-deployment/PHASE.md b/agent-roadmap/phase/personal-edge-packaging-deployment/PHASE.md index 278a05ea..fd92c15f 100644 --- a/agent-roadmap/phase/personal-edge-packaging-deployment/PHASE.md +++ b/agent-roadmap/phase/personal-edge-packaging-deployment/PHASE.md @@ -18,14 +18,14 @@ Milestone은 완료, 검토중, 진행중, 계획, 스케치 또는 보류 상 Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실행 순서](../../priority-queue.md)를 우선한다. 스케치 Milestone은 아직 구현 가능한 계획이 아니므로 사용자 검토와 구체화 후 `[계획]`으로 승격한다. -- [스케치] Personal Local Edge 패키징과 배포 모드 프로파일 - - 경로: [personal-local-edge-deployment-profiles](milestones/personal-local-edge-deployment-profiles.md) +- [스케치] [package-01] Personal Local Edge 패키징과 배포 모드 프로파일 + - 경로: [[package-01] Personal Local Edge 패키징과 배포 모드 프로파일](milestones/personal-local-edge-deployment-profiles.md) - 요약: 로컬용/서버용 코어를 분기하지 않고 같은 Edge runtime을 personal/server/fleet 배포 모드와 capability gate로 운용하며, 개인 로컬 패키지에서는 Node와 사용자 관리 레이어를 숨기거나 축소하는 방향을 뒤쪽 후보로 스케치한다. ## Phase 경계 - 이 Phase는 제품 배포 토폴로지, packaging target, install/update UX, deployment mode, capability gate의 경계를 소유한다. -- direct/Plan/Milestone 분류와 workflow 실행 라우팅은 `Automation Runtime과 Bridge 확장` Phase, 누적 요청 컨텍스트 최적화는 `지식과 도구 최적화 확장` Phase, provider catalog와 runtime qualification은 `운영 관측과 Provider 관리` Phase 책임으로 둔다. +- direct/Plan/Milestone 분류와 workflow 실행 라우팅은 IOP 제품 범위에서 제외하고, 누적 요청 컨텍스트 최적화는 `지식과 도구 최적화 확장` Phase, provider catalog와 runtime qualification은 `운영 관측과 Provider 관리` Phase 책임으로 둔다. - release manifest, update protocol, host-local manager, rollback 상태 머신은 `Update Plane과 자체 업데이트 기반` Phase 책임으로 두고, 이 Phase는 personal/server 패키징에서 어떤 update capability를 켤지의 제품 경계를 다룬다. -- Edge/Node adapter execution, CLI agent runtime, specialized agent 등록 경로는 `Automation Runtime과 Bridge 확장` Phase 책임으로 둔다. +- Edge/Node adapter execution과 provider/device 실행 경계는 운영 Phase가 다루며, CLI agent runtime·workspace·terminal·workflow는 IOP 제품 범위에서 제외한다. - 사용자/조직 IAM, billing/chargeback, 장기 audit schema 구현은 후속 운영/보안 Milestone에서 결정한다. diff --git a/agent-roadmap/phase/personal-edge-packaging-deployment/milestones/personal-local-edge-deployment-profiles.md b/agent-roadmap/phase/personal-edge-packaging-deployment/milestones/personal-local-edge-deployment-profiles.md index 3b61de63..856d3f61 100644 --- a/agent-roadmap/phase/personal-edge-packaging-deployment/milestones/personal-local-edge-deployment-profiles.md +++ b/agent-roadmap/phase/personal-edge-packaging-deployment/milestones/personal-local-edge-deployment-profiles.md @@ -1,4 +1,4 @@ -# Milestone: Personal Local Edge 패키징과 배포 모드 프로파일 +# Milestone: [package-01] Personal Local Edge 패키징과 배포 모드 프로파일 ## 위치 @@ -36,7 +36,7 @@ - [ ] 승격 조건의 미정 항목이 사용자 검토로 해소되어 있다. - [ ] 구현 가능한 목표, 범위, 기능 Task, 후속 구현 Milestone 후보가 분리되어 있다. - 결정 필요: 아래 체크리스트 - - [ ] 초기 제품 표면을 `iop-edge` 단일 바이너리로 유지할지, 별도 `iop-agent` 또는 tray/app wrapper를 둘지 결정한다. + - [ ] 초기 제품 표면을 `iop-edge` 단일 바이너리로 유지할지, 별도 host/tray/app wrapper를 둘지 결정한다. - [ ] personal/local 모드의 기본 backend를 embedded, local child Node, remote Node disabled 중 어떤 조합으로 시작할지 결정한다. - [ ] personal/local 모드에서 multi-user 관리, 조직 RBAC, fleet audit를 완전히 끌지, minimal local identity/audit만 남길지 결정한다. - [ ] macOS/Windows 개인 배포에서 Docker를 보조 경로로만 둘지, 특정 provider runtime에는 Docker 옵션을 허용할지 결정한다. diff --git a/agent-roadmap/phase/update-plane-self-update-foundation/PHASE.md b/agent-roadmap/phase/update-plane-self-update-foundation/PHASE.md index ff54b263..0953bed3 100644 --- a/agent-roadmap/phase/update-plane-self-update-foundation/PHASE.md +++ b/agent-roadmap/phase/update-plane-self-update-foundation/PHASE.md @@ -22,16 +22,16 @@ Phase를 가로지르는 실제 다음 작업 선택은 [전역 마일스톤 실 - 경로: [runtime-reconnect-config-refresh](../../archive/phase/update-plane-self-update-foundation/milestones/runtime-reconnect-config-refresh.md) - 요약: Edge 단절 후 Node 10초 간격 10회 재접속과 종료 정책, 운영 중 config refresh/diff/apply/Node 전파의 MVP 경계를 구현 가능한 계획으로 정리한다. -- [스케치] Update Plane 안정 프로토콜 - - 경로: [update-plane-stable-protocol](milestones/update-plane-stable-protocol.md) +- [스케치] [update-01] Update Plane 안정 프로토콜 + - 경로: [[update-01] Update Plane 안정 프로토콜](milestones/update-plane-stable-protocol.md) - 요약: 전체 운영 프로토콜이 바뀌어도 업데이트를 지속할 수 있는 hello/status, manifest, command, event, recovery 최소 계약을 스케치한다. -- [스케치] Host-local Manager 기반 자체 업데이트 - - 경로: [host-local-manager-self-update](milestones/host-local-manager-self-update.md) +- [스케치] [update-02] Host-local Manager 기반 자체 업데이트 + - 경로: [[update-02] Host-local Manager 기반 자체 업데이트](milestones/host-local-manager-self-update.md) - 요약: Edge/Node 앱 프로세스 바깥의 manager/updater가 release staging, 검증, 프로세스 종료/재시작, rollback을 담당하는 cross-OS 실행 모델을 스케치한다. -- [스케치] Edge/Node 롤아웃과 복구 정책 - - 경로: [edge-node-rollout-recovery-policy](milestones/edge-node-rollout-recovery-policy.md) +- [스케치] [update-03] Edge/Node 롤아웃과 복구 정책 + - 경로: [[update-03] Edge/Node 롤아웃과 복구 정책](milestones/edge-node-rollout-recovery-policy.md) - 요약: Edge가 Node rolling update와 자기 업데이트를 조율하고, 실패/재연결/rollback 상태를 Control Plane에 보고하는 운영 정책을 스케치한다. ## Phase 경계 diff --git a/agent-roadmap/phase/update-plane-self-update-foundation/milestones/edge-node-rollout-recovery-policy.md b/agent-roadmap/phase/update-plane-self-update-foundation/milestones/edge-node-rollout-recovery-policy.md index 54fa4215..645bd0b8 100644 --- a/agent-roadmap/phase/update-plane-self-update-foundation/milestones/edge-node-rollout-recovery-policy.md +++ b/agent-roadmap/phase/update-plane-self-update-foundation/milestones/edge-node-rollout-recovery-policy.md @@ -1,4 +1,4 @@ -# Milestone: Edge/Node 롤아웃과 복구 정책 +# Milestone: [update-03] Edge/Node 롤아웃과 복구 정책 ## 위치 diff --git a/agent-roadmap/phase/update-plane-self-update-foundation/milestones/host-local-manager-self-update.md b/agent-roadmap/phase/update-plane-self-update-foundation/milestones/host-local-manager-self-update.md index c1f0eb04..fc5e5248 100644 --- a/agent-roadmap/phase/update-plane-self-update-foundation/milestones/host-local-manager-self-update.md +++ b/agent-roadmap/phase/update-plane-self-update-foundation/milestones/host-local-manager-self-update.md @@ -1,4 +1,4 @@ -# Milestone: Host-local Manager 기반 자체 업데이트 +# Milestone: [update-02] Host-local Manager 기반 자체 업데이트 ## 위치 diff --git a/agent-roadmap/phase/update-plane-self-update-foundation/milestones/update-plane-stable-protocol.md b/agent-roadmap/phase/update-plane-self-update-foundation/milestones/update-plane-stable-protocol.md index 4c7ff1a2..2c49aa8b 100644 --- a/agent-roadmap/phase/update-plane-self-update-foundation/milestones/update-plane-stable-protocol.md +++ b/agent-roadmap/phase/update-plane-self-update-foundation/milestones/update-plane-stable-protocol.md @@ -1,4 +1,4 @@ -# Milestone: Update Plane 안정 프로토콜 +# Milestone: [update-01] Update Plane 안정 프로토콜 ## 위치 diff --git a/agent-roadmap/priority-queue.md b/agent-roadmap/priority-queue.md index c1492367..86d5b942 100644 --- a/agent-roadmap/priority-queue.md +++ b/agent-roadmap/priority-queue.md @@ -1,71 +1,95 @@ # 전역 마일스톤 실행 순서 -이 문서는 Phase를 가로지르는 Milestone 실행 순서만 기록한다. 위에 있는 항목을 먼저 검토한다. +이 문서는 Phase를 가로지르는 Milestone 실행 lane과 차단 예외를 기록한다. 같은 prefix는 작은 index부터 순차 실행하고, 다른 prefix는 차단 표기가 없으면 병렬 실행할 수 있다. ## 실행 순서 -1. [IOP Agent Runtime의 Chronos 선별 이전과 IOP 의존성 제거](phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md) - 완료된 `iop-agent`에서 Chronos-owned 자산을 선별 전달하고 IOP standalone 의존성을 제거한 뒤 잔류 Node/provider 회귀와 Chronos 시작 잠금 해제 evidence를 남긴다. +### route -2. [IOP Hot Path One-shot 실행 경로](phase/knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md) - 외부 `model=iop` 요청을 Gemini 3.6 Flash와 RTX 5090 `ornith-fast`의 bounded one-shot 경로로 처리해 최대 속도와 실사용 품질의 균형을 맞춘다. +1. [[route-01] IOP Hot Path One-shot 실행 경로](phase/knowledge-tool-optimization-extension/milestones/iop-hot-path-one-shot-execution.md) + 외부 `model=iop` 요청을 Gemini 3.6 Flash와 RTX 5090 `ornith-fast`의 bounded one-shot 경로로 처리하면서 model advisory, Edge arbiter와 route evidence의 첫 profile을 구축한다. -3. [OpenAI-compatible 출력 검증 필터](phase/knowledge-tool-optimization-extension/milestones/openai-compatible-output-validation-filters.md) +2. [[route-02] 단계 호출과 검증 최적화 MVP](phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md) + Hot Path의 micro-plan/review를 bounded analysis/generation/verification profile로 일반화하고 Edge가 선택할 stage binding을 스케치한다. + +3. [[route-03] OpenAI-compatible 하이브리드 요청 수준·실행 형태 라우팅](phase/knowledge-tool-optimization-extension/milestones/openai-compatible-hybrid-request-execution-routing.md) + cloud model advisory와 deterministic hard gate를 결합해 Edge가 요청 난이도에 맞는 execution shape와 stage target을 최종 결정하고 route evidence를 축적한다. + +4. [[route-04] RAG 기반 Local Routing Model 운영 전환](phase/knowledge-tool-optimization-extension/milestones/rag-local-routing-model-operations.md) + cloud-first route evidence가 품질·규모 gate를 통과하면 RAG local router를 shadow/canary로 검증해 운영 기본 경로로 점진 전환한다. + - 선행 차단: `[observe-03]`, `[provider-02]` + +### output + +1. [[output-01] OpenAI-compatible 출력 검증 필터](phase/knowledge-tool-optimization-extension/milestones/openai-compatible-output-validation-filters.md) 실제 의미 필터 전에 deterministic diagnostic mock으로 실제 Stream Evidence Gate의 pass·observe-only·blocking recovery를 관측하는 smoke를 통과시키고, OpenAI-compatible single-stream 반복과 incoming request history에 누적된 assistant 반복, JSON contract 검증/repair 경로를 안정화한다. + - 동시 차단: `[route-01]` -4. [OpenAI-compatible Incomplete Tool Call Syntax Gate](phase/knowledge-tool-optimization-extension/milestones/openai-compatible-incomplete-tool-call-syntax-gate.md) +2. [[output-02] OpenAI-compatible Incomplete Tool Call Syntax Gate](phase/knowledge-tool-optimization-extension/milestones/openai-compatible-incomplete-tool-call-syntax-gate.md) terminal provider 응답의 incomplete tool-call syntax를 deterministic하게 판정한다. -5. [OpenAI-compatible Runtime Output Integrity Filter](phase/knowledge-tool-optimization-extension/milestones/openai-compatible-runtime-output-integrity-filter.md) +3. [[output-03] OpenAI-compatible Runtime Output Integrity Filter](phase/knowledge-tool-optimization-extension/milestones/openai-compatible-runtime-output-integrity-filter.md) terminal output invariant와 공통 filter/retry pipeline을 정의한다. -6. [LLM 판별 기반 Missing Tool Call 재시도 Gate](phase/knowledge-tool-optimization-extension/milestones/llm-judged-missing-tool-call-retry-gate.md) - tool 사용 의도 누락 케이스를 LLM judge와 buffered retry 후보로 검토한다. +### judge -7. [Tool Call 판정 모델 Gate 리뷰](phase/knowledge-tool-optimization-extension/milestones/tool-call-validator-model-gate-review.md) +1. [[judge-01] LLM 판별 기반 Missing Tool Call 재시도 Gate](phase/knowledge-tool-optimization-extension/milestones/llm-judged-missing-tool-call-retry-gate.md) + tool 사용 의도 누락 케이스를 LLM judge와 buffered retry 후보로 검토한다. + - 선행 차단: `[output-01]` + +2. [[judge-02] Tool Call 판정 모델 Gate 리뷰](phase/knowledge-tool-optimization-extension/milestones/tool-call-validator-model-gate-review.md) schema만으로 어려운 tool-call 후보에 validator 모델을 쓸지 검토한다. -8. [Provider 부하 메트릭과 Live Queue Dashboard](phase/operational-observability-provider-management/milestones/provider-load-metrics-queue-dashboard.md) +### observe + +1. [[observe-01] Node Provider 실행 Liveness 관측과 안전 복구](phase/operational-observability-provider-management/milestones/node-provider-execution-liveness-recovery.md) + Node가 5분간 provider 진행이 없는 request를 health와 분리 판정하고 local attempt를 fence한 뒤 기존 recovery owner가 안전한 요청만 공통 budget 안에서 재실행한다. + +2. [[observe-02] Provider 부하 메트릭과 Live Queue Dashboard](phase/operational-observability-provider-management/milestones/provider-load-metrics-queue-dashboard.md) Edge provider-pool의 capacity, in-flight, queued와 queue wait를 Prometheus/Grafana로 관측해 provider별 live 부하와 적체·회복을 분석한다. -9. [Pi CLI Provider Integration](phase/automation-runtime-bridge/milestones/pi-cli-provider-integration.md) - Pi를 Node CLI provider 실행 후보에 추가하고 OpenAI-compatible route smoke로 안정화한다. +3. [[observe-03] 요청 실행 로그와 Usage Ledger 기반](phase/operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md) + 요청별 provider/model 선택, timing, token, status/error를 구조화된 ledger로 남기는 기반을 스케치한다. -10. [단계 호출과 검증 최적화 MVP](phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md) - planner/generator/verifier 단계 호출과 runtime schema 검증 실행 모드를 스케치한다. +### update -11. [Personal Local Edge 패키징과 배포 모드 프로파일](phase/personal-edge-packaging-deployment/milestones/personal-local-edge-deployment-profiles.md) - personal/server/fleet 배포 모드와 capability gate 경계를 스케치한다. +1. [[update-01] Update Plane 안정 프로토콜](phase/update-plane-self-update-foundation/milestones/update-plane-stable-protocol.md) + hello/status, manifest, command, event, recovery 최소 계약을 스케치한다. -12. [요청 실행 로그와 Usage Ledger 기반](phase/operational-observability-provider-management/milestones/request-execution-log-usage-ledger-foundation.md) - 요청별 provider/model 선택, timing, token, status/error를 구조화된 ledger로 남기는 기반을 스케치한다. +2. [[update-02] Host-local Manager 기반 자체 업데이트](phase/update-plane-self-update-foundation/milestones/host-local-manager-self-update.md) + manager/updater의 release staging, 검증, restart, rollback 실행 모델을 정리한다. -13. [Update Plane 안정 프로토콜](phase/update-plane-self-update-foundation/milestones/update-plane-stable-protocol.md) - hello/status, manifest, command, event, recovery 최소 계약을 스케치한다. +3. [[update-03] Edge/Node 롤아웃과 복구 정책](phase/update-plane-self-update-foundation/milestones/edge-node-rollout-recovery-policy.md) + Edge/Node rolling update, 실패/재연결/rollback 보고 정책을 스케치한다. -14. [Host-local Manager 기반 자체 업데이트](phase/update-plane-self-update-foundation/milestones/host-local-manager-self-update.md) - manager/updater의 release staging, 검증, restart, rollback 실행 모델을 정리한다. +### package -15. [Edge/Node 롤아웃과 복구 정책](phase/update-plane-self-update-foundation/milestones/edge-node-rollout-recovery-policy.md) - Edge/Node rolling update, 실패/재연결/rollback 보고 정책을 스케치한다. +1. [[package-01] Personal Local Edge 패키징과 배포 모드 프로파일](phase/personal-edge-packaging-deployment/milestones/personal-local-edge-deployment-profiles.md) + personal/server/fleet 배포 모드와 capability gate 경계를 스케치한다. + - 선행 차단: `[update-02]` -16. [Provider Runtime 설정과 모델 획득 오케스트레이션](phase/operational-observability-provider-management/milestones/provider-runtime-model-acquisition-orchestration.md) - provider runtime launch/profile, model download/cache/verification 경계를 스케치한다. +### provider -17. [Provider-Device-Model Qualification 리포트와 Lifecycle 관리](phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md) - provider/device/model별 compatibility, performance, quality, lifecycle 리포트 경계를 정리한다. +1. [[provider-01] Provider Runtime 설정과 모델 획득 오케스트레이션](phase/operational-observability-provider-management/milestones/provider-runtime-model-acquisition-orchestration.md) + provider runtime launch/profile, model download/cache/verification 경계를 스케치한다. -18. [Provider 입력 컨텍스트 선택과 축소](phase/knowledge-tool-optimization-extension/milestones/request-context-assembly-optimization.md) - provider dispatch 전에 무관한 과거 요청-답변 단위를 제거하고, 유지한 답변·tool/search 결과 안에서도 필요한 문단·코드 블록·구간만 남기는 입력 context 최적화를 스케치한다. +2. [[provider-02] Provider-Device-Model Qualification 리포트와 Lifecycle 관리](phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md) + provider/device/model별 compatibility, performance, quality, lifecycle 리포트 경계를 정리한다. -19. [장기 기억과 RAG 업데이트 사이클 (2차)](phase/knowledge-tool-optimization-extension/milestones/long-term-memory-rag-second-wave.md) - repo 장기 기억, RAG 저장소, update cycle, MCP 기반 context 절약 후보를 스케치한다. +### context -20. [Advisor와 Context Hook 확장 (2차)](phase/knowledge-tool-optimization-extension/milestones/advisor-context-hook-second-wave.md) - advisor 역할과 여러 기능을 실행 흐름에 연결하는 Context Hook 경계를 스케치한다. +1. [[context-01] Provider 입력 컨텍스트 선택과 축소](phase/knowledge-tool-optimization-extension/milestones/request-context-assembly-optimization.md) + provider dispatch 전에 무관한 과거 요청-답변 단위를 제거하고, 유지한 답변·tool/search 결과 안에서도 필요한 문단·코드 블록·구간만 남기는 입력 context 최적화를 스케치한다. + - 선행 차단: `[observe-03]` -21. [oto 자동화 스케줄러와 CI-CD 연동 (2차)](phase/automation-runtime-bridge/milestones/oto-automation-scheduler-second-wave.md) - oto 기반 자동화, scheduler, CI-CD 연동 후보를 스케치한다. +### memory -22. [Node Provider 실행 Liveness 관측과 안전 복구](phase/operational-observability-provider-management/milestones/node-provider-execution-liveness-recovery.md) - Node가 5분간 provider 진행이 없는 request를 health와 분리 판정하고 local attempt를 fence한 뒤 기존 recovery owner가 안전한 요청만 공통 budget 안에서 재실행한다. +1. [[memory-01] 장기 기억과 RAG 업데이트 사이클 (2차)](phase/knowledge-tool-optimization-extension/milestones/long-term-memory-rag-second-wave.md) + repo 장기 기억, RAG 저장소, update cycle, MCP 기반 context 절약 후보를 스케치한다. + - 선행 차단: `[route-02]`, `[observe-03]` + +### advisor + +1. [[advisor-01] Advisor와 Context Hook 확장 (2차)](phase/knowledge-tool-optimization-extension/milestones/advisor-context-hook-second-wave.md) + advisor 역할과 여러 기능을 실행 흐름에 연결하는 Context Hook 경계를 스케치한다. + - 선행 차단: `[route-02]` diff --git a/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/SDD.md b/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/SDD.md index cfbe2042..a07f348b 100644 --- a/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/SDD.md +++ b/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/SDD.md @@ -1,4 +1,4 @@ -# SDD: IOP Agent Runtime의 Chronos 선별 이전과 IOP 의존성 제거 +# SDD: IOP Agent Runtime의 Chronos 전체 이전과 IOP 의존성 제거 ## 위치 @@ -7,100 +7,134 @@ ## 상태 -[초안] +[승인됨] ## SDD 잠금 -- 상태: 잠금 -- 사용자 리뷰: [USER_REVIEW.md](USER_REVIEW.md) +- 상태: 해제 +- 사용자 리뷰: [user_review_0.log](user_review_0.log), [user_review_1.log](user_review_1.log) - 잠금 항목: - - [ ] [D01] 기존 config/state versioned export 범위 + - [x] [D01] 기존 등록·설정·저장 상태 전체 이전 + - [x] [D02] IOP Node의 범용 실행·제어 경계(이전 결정, D04로 대체) + - [x] [D03] 반영된 설계로 SDD 잠금 해제 승인 + - [x] [D04] 독립 Chronos Server/Node와 IOP 연결점 폐쇄 ## 문제 / 비목표 -- 문제: 완료된 `iop-agent`에는 Chronos로 넘길 standalone workflow/state 책임과 IOP가 계속 사용할 finite provider 책임이 한 repository 안에 공존한다. Chronos 작업을 시작하기 전에 IOP가 필요한 자산을 선별 전달하고 source/runtime 의존성을 제거해야 한다. +- 문제: 완료된 `iop-agent`의 source·contract·test·config·state·build·document 자산과 Chronos가 소유할 작업 흐름·CLI agent session·terminal/workspace 제어가 IOP repository에 남아 있다. Chronos 작업을 시작하기 전에 관련 자산을 repository-neutral Chronos acceptance bundle로 전부 전달하고, IOP와 IOP Node에서 Chronos 작업 의미뿐 아니라 향후 연결을 위한 bridge/API/proto/config까지 제거해야 한다. IOP Node에는 model/provider/device 운영에 필요한 실행 경계만 남긴다. - 비목표: - - Chronos 후속 제품 아키텍처와 local control v1 설계 + - Chronos Server, 독립 Chronos Node, 외부 접근 API와 local/remote control의 후속 상세 설계 - Chronos state root로의 실제 import·활성화와 이후 state write - - IOP managed `agent_bridge` 또는 원격 제어 구현 + - Chronos Node의 loop engineering, agent/CLI, terminal/PTY, file/process와 원격 workspace 제어 구현 + - IOP managed `agent_bridge`, Chronos-to-IOP Node 연결 계약 또는 원격 제어 구현 - 새로운 workflow scope와 desktop client 기능 구현 ## Source of Truth | 영역 | 기준 | 메모 | |------|------|------| -| Roadmap | [Milestone 문서](../../../phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md) | 선별 이전·제거 범위와 완료 상태의 원본 | -| Code | IOP `apps/agent`, `packages/go/agent*`, `proto/iop/agent.proto`와 Chronos transfer target | 작업 시작 시 source revision과 disposition manifest를 고정한다 | -| External Provider | 없음 | Chronos repository는 provider가 아니라 [Cross-repo Dependencies](#cross-repo-dependencies)의 잠긴 전달 대상이다 | -| User Decision | D01 | 기존 project/config/state의 versioned export 범위 | +| Roadmap | [Milestone 문서](../../../phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md) | 전체 이전·제거 범위와 완료 상태의 원본 | +| Code | IOP revision `3155be0e275437a8eedc1aa93497955a7d30465b`, `apps/agent`, `packages/go/agent*`, `proto/iop/agent.proto`와 repository-neutral acceptance bundle layout | 모든 기존 agent-named 자산은 transfer bundle 전달 뒤 IOP 제거로 연결한다. IOP Node의 model/provider/device 운영에 실제로 필요한 최소 실행 부분만 중립 패키지로 재배치하고 agent session·terminal·workspace·Chronos 연결 의미는 제거한다 | +| External Provider | 없음 | Chronos repository는 잠금 해제 뒤 bundle을 import하는 [Cross-repo Dependencies](#cross-repo-dependencies)의 downstream owner다 | +| User Decision | D01, D04 | 기존 등록·설정·저장 상태 전체 이전, 독립 Chronos Server/Node와 IOP 연결점 폐쇄. D04가 D02의 향후 Chronos-to-IOP Node 연결 가능성을 대체한다 | ## State Machine | 상태 | 진입 조건 | 다음 상태 | 근거 | |------|-----------|-----------|------| -| inventoried | source revision과 disposition manifest가 고정됨 | transfer-ready | ownership manifest review | -| transfer-ready | D01 export 정책과 destination layout이 확정됨 | transferred | 독립 build 가능한 staging baseline, state export와 transfer receipt 초안 | -| transferred | 전달 목록·fixture 검증이 통과함 | decoupled | IOP removal diff와 no-import 검증 | -| transfer-ready 또는 transferred | ambiguous live state, 누락된 target 또는 회귀가 발견됨 | blocked | actionable blocker와 보존된 source revision | -| decoupled | IOP 잔류 provider 회귀와 양쪽 최종 검증이 통과함 | handoff-ready | 확정 transfer receipt와 workspace lock 동기화 근거 | +| inventory-baselined | Task 03의 source revision·303행(`file=293`, `state=10`)·`universe·duplicate=0` evidence를 승계하고 Task 16 재계획이 corrected pinned-transfer manifest 300행(`file=290`, `state=10`, `retain-generic=135`)과 SHA `d8598134dee99d96fc05a045091dd3d8932d4708d2c980c2a78c8b11825d2ccf`를 current baseline으로 고정함. historical Task-03 303행 결과는 Task-03 evidence로만 보존함 | transfer-ready | original manifest review와 D04 137-row delta·surface addendum schema review | +| transfer-ready | D01 전체 상태 이전 정책, D04 IOP/Chronos 책임 경계, repository-neutral acceptance layout과 original manifest + 137-row delta + surface addendum → effective matrix 계약이 확정됨 | transferred | 격리 staging root에서 독립 build 가능한 versioned transfer bundle과 전체 상태 export 검증 | +| transferred | 전달 목록·bundle digest·behavior fixture·전체 상태 export 검증이 통과함 | decoupled | IOP removal diff, forbidden-reference audit와 provider regression | +| decoupled | IOP에서 Chronos 작업 로직·agent/terminal/workspace surface·연결점이 제거되고 IOP provider 전용 Node 회귀가 통과함 | disposition-reconciled | original manifest, 정확히 137개 행의 delta와 D04 surface addendum를 결합한 effective matrix 및 Task 13 pre-deletion receipt | +| disposition-reconciled | Task 13 pre-deletion receipt가 세 입력 digest, 항목별 처분, 상태 이전 결과와 rollback 지점을 고정함 | handoff-ready | Task 14 최종 잔여 migration-surface 삭제 evidence와 Task 15 tracked `HANDOFF.md` final composite receipt | +| handoff-ready | Task 15 final composite receipt가 Task 13 receipt, Task 14 최종 삭제·회귀 evidence와 downstream lock identity를 모두 인용함 | 없음 | 양쪽 최종 검증과 workspace lock 동기화 근거 | ## Interface Contract -- 계약 원문: [IOP Agent CLI Runtime 계약](../../../../agent-contract/inner/iop-agent-cli-runtime.md) +- 이전 계약 기준: 완료된 [IOP Agent CLI Runtime](../../../archive/phase/automation-runtime-bridge/milestones/iop-agent-cli-runtime.md)과 `source_revision`에서 고정한 legacy contract snapshot. 활성 IOP 계약 파일은 decouple 단계에서 제거한다. - 입력: - - `source_revision`: 선별 이전의 기준이 되는 현재 IOP commit - - `disposition_manifest`: 각 활성 code/config/proto/build/test/doc의 `transfer | retain | remove | reference` 분류 - - `legacy_state_export_policy`: D01에서 확정한 기존 project/config/state export 또는 clean-start 방식 + - `source_revision`: Task 03 inventory 기준으로 고정된 historical IOP commit + - `disposition_manifest`: Task 03의 source revision·303행(`file=293`, `state=10`)·`universe·duplicate=0` historical evidence를 승계하고, Task 16 corrected pinned-transfer manifest 300행(`file=290`, `state=10`, `retain-generic=135`)과 SHA `d8598134dee99d96fc05a045091dd3d8932d4708d2c980c2a78c8b11825d2ccf`를 current pinned-transfer baseline으로 추가로 고정한 original historical `transfer | retain-generic | remove | reference` 분류. Task 16 이후 manifest bytes는 pinned-tree 파생으로 교정되었다. D04 반영을 위해 원본 bytes는 다시 쓰지 않는다. + - `boundary_disposition_delta`: D04에 따라 기존 `retain-generic` 후보를 IOP provider 최소 primitive 또는 `transfer` 후 `remove`로 재판정한 정확히 137개 행의 versioned delta와 digest + - `boundary_surface_addendum`: original manifest에 없지만 D04 책임 경계의 영향을 받는 활성 surface를 version, digest, disposition과 최종 owner로 고정한 별도 addendum + - `legacy_state_export_policy`: D01에서 확정한 기존 등록·설정·저장 상태 전체와 깨진 잔여 기록의 버전이 있는 읽기 전용 이전 방식 + - `iop_node_boundary`: D04에서 확정한 model/provider/device 운영용 실행·취소·상태·usage·lifecycle 경계 - 출력: - - `chronos_staging_baseline`: IOP application/runtime import 없이 독립 build 가능한 선별 전달 source와 통과한 behavior fixture - - `legacy_state_export`: version·source revision·integrity metadata를 가진 import 입력 또는 clean-start marker와 ambiguous-state blocker manifest - - `iop_decoupling`: standalone surface 제거 diff와 잔류 Node/provider 경계 - - `transfer_receipt`: revision, 항목별 결과, state export 결과, 회귀 evidence, rollback 지점과 downstream lock identity + - `chronos_transfer_bundle`: repository-neutral acceptance layout, source revision, 항목 digest와 전체 bundle digest를 포함하고 격리 staging root에서 live IOP checkout이나 누락된 IOP source dependency 없이 독립 build 가능한 전체 전달 source와 통과한 behavior fixture + - `legacy_state_export`: version·source revision·integrity metadata를 가진 전체 import 입력과 즉시 재개할 수 없는 깨진 기록의 격리 보관 자료 + - `effective_disposition_matrix`: original manifest digest, 정확히 137개 행의 boundary delta digest와 D04 surface addendum digest를 결합해 최종 IOP retain/remove 및 Chronos transfer 결과를 고정한 감사 표 + - `iop_decoupling`: `iop-agent`·CLI agent session·terminal/workspace·Chronos 연결 surface 제거 diff와 IOP provider 전용 Node 경계 + - `pre_deletion_receipt`: Task 13에서 effective matrix, state export 결과, 사전 회귀 evidence와 rollback 지점을 고정한 receipt + - `final_composite_receipt`: Task 15의 tracked `HANDOFF.md`에서 Task 13 receipt, Task 14 최종 잔여 migration-surface 삭제·회귀 evidence와 downstream lock identity를 결합한 최종 receipt - 금지: - Chronos Milestone 구현을 `handoff-ready` 전에 시작하지 않는다. - Chronos가 IOP application 또는 runtime package를 장기 dependency로 import하지 않는다. - - destination baseline과 fixture 수용을 확인하기 전에 IOP source를 제거하지 않는다. - - IOP Node의 finite model/API/CLI provider 실행을 standalone 제거 대상으로 분류하지 않는다. + - transfer bundle의 acceptance layout·digest·격리 staging build와 fixture를 확인하기 전에 IOP source를 제거하지 않는다. + - IOP Node에 Chronos 전용 작업 흐름, 상태, 대상 선택, 재시도, 검토·반영, CLI agent session, PTY/terminal, workspace·원격 호스트 제어를 남기지 않는다. + - IOP에 future Chronos bridge/API/proto/config, Chronos target·registry, forwarding runtime 또는 Chronos application runtime import를 남기지 않는다. + - IOP Node의 중립 실행 경계를 arbitrary command/terminal gateway로 확장하지 않고 IOP model/provider/device 운영에 필요한 capability로 제한한다. + - Chronos는 자체 Server와 별도 Chronos Node를 소유하며, 추론이 필요할 때 IOP의 외부 API를 일반 client로만 소비한다. - IOP Milestone에서 Chronos state root로 import하거나 Chronos runtime을 활성화하지 않는다. - - ambiguous live execution을 export 가능한 state로 포장하거나 성공한 이전으로 기록하지 않는다. + - 귀속이나 완결성을 확인할 수 없는 실행 상태를 재개 가능한 상태로 포장하거나 성공한 이전으로 기록하지 않는다. ## Acceptance Scenarios | ID | Milestone Task | Given | When | Then | |----|----------------|-------|------|------| -| S01 | `inventory` | 현재 IOP source와 계약이 있음 | disposition manifest를 작성함 | 모든 활성 자산이 단일 owner/action에 배정되고 중복 source of truth가 없다 | -| S02 | `transfer` | 승인된 manifest·export 정책과 Chronos scaffold가 있음 | 선별 자산과 legacy-state 입력을 전달함 | staging baseline이 IOP runtime import 없이 독립 build되고 behavior fixture가 통과하며 export provenance가 남는다 | -| S03 | `decouple` | 전달 baseline 검증이 통과함 | IOP standalone surface를 제거함 | 제거 대상 참조와 standalone 실행 surface가 IOP에 남지 않는다 | -| S04 | `retain-node` | IOP 잔류 provider 경계가 정의됨 | build·contract·focused regression을 실행함 | finite provider와 Node/Edge 실행 기준선이 유지된다 | -| S05 | `handoff-gate` | 이전·제거와 state export 또는 clean-start 결과가 존재함 | final receipt를 감사함 | 모든 항목·evidence·rollback과 Chronos lock 해제 조건을 추적할 수 있다 | +| S01 | `inventory` | Task 03의 source revision·303행(`file=293`, `state=10`)·`universe·duplicate=0` evidence와 Task 16에서 추가 고정한 corrected pinned-transfer manifest SHA·`retain-generic=135` baseline이 있음 | original manifest bytes를 보존하고 정확히 137개 행의 boundary-disposition delta와 original manifest 밖 D04 surface addendum를 작성해 effective matrix로 결합함 | Task 03 historical evidence와 Task 16 corrected baseline, 세 처분 입력과 digest가 모두 추적되고 모든 `iop-agent` 관련 활성 자산이 Chronos 전달과 IOP 제거에 연결되며, `retain-generic`은 IOP provider 운영에 필요한 최소 경계로만 제한된다 | +| S02 | `transfer` | 승인된 manifest·전체 상태 이전 정책과 repository-neutral acceptance layout이 있음 | 모든 관련 자산과 기존 상태를 versioned bundle로 전달함 | bundle의 격리 staging baseline이 live IOP checkout이나 누락된 IOP source dependency 없이 독립 build되고 behavior fixture가 통과하며 전체 이전 provenance와 digest가 남는다 | +| S03 | `decouple` | 전달 baseline 검증이 통과함 | IOP의 관련 surface를 제거함 | `iop-agent`와 Chronos 작업 로직, 상태와 전용 실행 surface가 IOP에 남지 않는다 | +| S04 | `retain-node` | IOP provider 전용 Node 경계가 정의됨 | build·contract·focused regression과 forbidden-reference audit을 실행함 | IOP Node가 model/provider/device 운영 capability만 유지하고 CLI agent·terminal·workspace·원격 제어·Chronos 연결 surface를 갖지 않는다 | +| S05 | `handoff-gate` | effective matrix, 전체 상태 이전과 제거 결과가 존재함 | Task 13 pre-deletion receipt를 고정하고 Task 14 최종 삭제 evidence를 더해 Task 15 tracked `HANDOFF.md` final composite receipt를 감사함 | 모든 처분 입력·상태 이전·삭제·회귀 evidence·rollback과 Chronos lock 해제 조건을 추적할 수 있다 | ## Evidence Map | Scenario | Required Evidence | `agent-task` 연결 | 완료 Evidence 기대 | |----------|-------------------|------------------|---------------------------| -| S01 | source revision, import graph와 disposition audit | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | 미분류·중복 owner가 없는 manifest | -| S02 | Chronos 독립 build, existing behavior test, forbidden-import scan과 versioned export fixture | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | staging baseline PASS와 항목별 receipt | -| S03 | removed-path/reference audit와 IOP clean build | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | standalone surface 부재 evidence | -| S04 | IOP Node/provider focused test와 contract regression | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | 잔류 provider 기준선 PASS | -| S05 | state export fixture 또는 clean-start marker, final cross-repo matrix와 lock check | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | Roadmap Completion에서 인용 가능한 transfer receipt | +| S01 | Task 03 source revision·303행(`file=293`, `state=10`)·`universe·duplicate=0` evidence, Task 16 corrected manifest SHA·`retain-generic=135`, 정확히 137개 행의 D04 boundary delta와 digest, D04 surface addendum와 digest, effective disposition 및 import graph audit | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | historical evidence를 과장하거나 원본 bytes를 변조하지 않고 세 처분 입력 digest를 결합해 모든 관련 자산을 전달·제거에 연결하며 IOP provider 운영 외 `retain-generic`이 없는 effective matrix | +| S02 | bundle 격리 staging build, existing behavior test, forbidden-import scan과 전체 상태 이전 fixture | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | versioned bundle digest, staging baseline PASS와 항목별 receipt | +| S03 | removed-path/reference audit와 IOP clean build | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | `iop-agent`와 Chronos 작업 surface 부재 evidence | +| S04 | IOP provider 실행 focused test, contract regression과 bridge/API/proto/config·CLI agent·PTY/terminal·workspace forbidden-reference audit | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | IOP provider 전용 Node 기준선과 Chronos 연결점 부재 PASS | +| S05 | 전체 상태 이전 fixture, effective cross-repo matrix, Task 13 pre-deletion receipt, Task 14 최종 삭제·회귀 evidence, Task 15 tracked `HANDOFF.md`와 lock check | `agent-task/m-iop-agent-chronos-extraction-decoupling/...` | Roadmap Completion에서 인용 가능한 final composite receipt | ## Cross-repo Dependencies - downstream Milestone: `chronos:agent-roadmap/phase/runtime-ownership-transition/milestones/chronos-architecture-ownership-boundary.md` - `.agent-roadmap-sync/locks.yaml` entry: `chronos:chronos-architecture-ownership-boundary` +- predecessor identity는 정식 `iop:agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md`다. 별도 checkout `iop-s1`의 task/마일스톤 결과는 검토된 commit이 `/config/workspace/iop`에 반영되고 정식 `iop:` Milestone 상태가 동기화된 뒤에만 이 lock의 해제 근거가 된다. ## Drift Check -- [ ] Milestone 기능 Task와 Acceptance Scenario가 일치한다. -- [ ] Evidence Map이 IOP 완료 검토와 Chronos lock 해제 근거로 검증 가능하다. -- [ ] [IOP Agent CLI Runtime 계약](../../../../agent-contract/inner/iop-agent-cli-runtime.md)을 복제하지 않고 이전 입력으로 참조했다. -- [ ] 사용자 리뷰가 필요한 legacy-state export 정책은 [USER_REVIEW.md](USER_REVIEW.md)에만 남겼다. +- [x] Milestone 기능 Task와 Acceptance Scenario가 일치한다. +- [x] Evidence Map이 IOP 완료 검토와 Chronos lock 해제 근거로 검증 가능하다. +- [x] 완료된 [IOP Agent CLI Runtime](../../../archive/phase/automation-runtime-bridge/milestones/iop-agent-cli-runtime.md)과 source revision의 legacy contract snapshot을 복제하지 않고 이전 입력으로 참조했다. +- [x] 사용자 결정이 SDD에 반영되고 해결 기록이 [user_review_0.log](user_review_0.log), [user_review_1.log](user_review_1.log)로 보존되어 있다. ## 사용자 리뷰 이력 -- 없음 +- 2026-08-01: [user_review_0.log](user_review_0.log) — 전체 상태 이전과 IOP Node 책임 경계를 승인하고 SDD 잠금을 해제했다. +- 2026-08-01: [user_review_1.log](user_review_1.log) — Chronos가 자체 Server와 별도 Chronos Node를 소유하고 IOP에는 Chronos 연결점과 agent/terminal/workspace 제어를 남기지 않는 방향으로 D02를 대체했다. ## 작업 컨텍스트 -- 표준선: ownership manifest 기반의 parity-before-delete, no cross-repo application import, fail-closed state export와 repository-local execution ownership을 적용한다. 실제 Chronos state import는 후속 Chronos SDD가 소유한다. +- 표준선: ownership manifest 기반의 parity-before-delete, cross-repo application import 금지, 전체 상태의 읽기 전용 이전과 repository-local execution ownership을 적용한다. 깨진 잔여 기록은 재개 가능한 상태로 포장하지 않고 격리 보관 자료로 전달한다. 실제 Chronos state import와 Chronos Server/Node·loop/agent/terminal 설계는 후속 Chronos SDD가 소유하고, IOP는 외부 추론 API 외의 Chronos 연결점을 제공하지 않는다. - 후속 SDD: [Chronos Architecture SDD](../../../../../chronos/agent-roadmap/sdd/runtime-ownership-transition/chronos-architecture-ownership-boundary/SDD.md) + +### 승격 기준 분류표 + +| 처분 | 현재 IOP 경로군 | 완료 시 경계 | +|------|-----------------|--------------| +| `transfer` 후 `remove` | `apps/agent/**` | CLI·daemon·task loop·project log·local control·client process 전체를 Chronos 수용용 bundle로 전달하고 IOP에서 제거한다. | +| `transfer` 후 `remove` | `packages/go/agentconfig/**`, `agentguard/**`, `agentpolicy/**`, `agentstate/**`, `agenttask/**`, `agentworkspace/**`, `agentprovider/catalog/**` | 설정·작업 상태·선택·재시도·격리·검토·반영·catalog 원본을 Chronos로 넘기고 IOP에서 제거한다. | +| `transfer` 후 `remove` | `proto/iop/agent.proto`, 생성물, `configs/iop-agent*`, `Makefile`의 agent target, agent smoke·fixture, agent contract/spec/domain 문서 | 계약·설정·빌드·검증·설명 surface를 Chronos로 넘기고 IOP 활성 경로에서 제거하거나 IOP 범용 문서로 재작성한다. | +| `transfer` 후 `remove` | `packages/flutter/iop_console`의 `IopAgentPanel`과 Client 연결, 관련 테스트 | 기존 UI 자산을 Chronos 수용 입력으로 넘기고 IOP Client/console에서 agent 전용 surface를 제거한다. 새 Chronos UI 구현은 후속 범위다. | +| `retain-generic` | `packages/go/agentruntime/**`, `packages/go/agentprovider/cli/**` 중 IOP model/provider/device 운영에도 필요한 부분 | 원본은 Chronos 수용용 bundle에 전달한다. IOP에는 provider process lifecycle에 실제로 필요한 최소 실행 primitive만 비(非)Agent 이름으로 재배치하며 CLI agent profile/session·PTY·workspace·tool execution·quota/status adapter 의미는 남기지 않는다. 필요성이 입증되지 않은 부분은 transfer 후 remove로 재분류한다. | +| `retain-generic` | `apps/node/**`, Edge-IOP Node provider wire와 Node adapter/store | model/provider/device의 실행·취소·상태·usage·lifecycle만 유지한다. arbitrary command, session list/terminate, terminal/PTY, workspace·file/process remote control, Chronos target/registry/bridge와 Chronos package 의미는 제거한다. | +| `reference` | 위 source revision, 이전 전 계약, 동작 fixture와 최종 transfer receipt | 삭제 뒤 추적과 rollback 근거로만 보존하며 IOP의 활성 application/runtime source of truth로 사용하지 않는다. | + +### 독립 baseline과 검증 기준 + +- Transfer bundle은 source/state/contract/behavior fixture/provenance가 분리된 repository-neutral acceptance layout으로 만들고, 임시 격리 staging root에 풀어 live IOP checkout이나 bundle 밖의 IOP source dependency 없이 build되어야 한다. 이 layout은 최종 Chronos source tree 결정을 선점하지 않으며 Chronos repository에는 이 Milestone 동안 직접 쓰지 않는다. +- Task 03 historical evidence는 source revision `3155be0e275437a8eedc1aa93497955a7d30465b`, original manifest 303행(`file=293`, `state=10`)과 `universe·duplicate=0`만 고정하며 manifest SHA나 `retain-generic=137`을 Task 03 receipt에 귀속하지 않는다. Task 16 corrected pinned-transfer manifest 300행(`file=290`, `state=10`, `retain-generic=135`)과 SHA `d8598134dee99d96fc05a045091dd3d8932d4708d2c980c2a78c8b11825d2ccf`를 current pinned-transfer baseline으로 추가 고정한다. historical Task-03 303행 결과는 Task-03 evidence로만 보존하며, `user_review_0.log`는 separate evidence로 분류하고 두 protocol-profile test는 excluded from the revision-3155 historical bundle로 기록한다. D04 이후 기존 행의 처분 변경은 원본 bytes를 수정하지 않고 정확히 137개 행의 boundary-disposition delta로 기록하고, 원본에 없던 D04 활성 surface는 versioned·digested boundary-surface addendum로 기록한다. Task 13 pre-deletion receipt는 세 처분 입력 digest를 결합한 effective matrix를 인용하며, Task 14의 최종 잔여 migration-surface 삭제 뒤 Task 15 tracked `HANDOFF.md`가 최종 삭제·회귀 evidence와 lock identity를 더한 final composite receipt를 소유한다. 미분류 활성 파일과 두 repository의 중복 application source of truth를 허용하지 않는다. +- IOP 검증은 모든 기존 agent-named application/runtime import와 surface의 제거, CLI agent session·terminal/workspace·Chronos bridge/API/proto/config 부재, 중립화된 IOP provider 실행 build, Edge-IOP Node wire와 provider 회귀를 포함한다. +- Bundle 검증은 격리 staging 독립 build, 이전된 동작 fixture, 전체 상태 이전 형식, 항목·bundle digest와 bundle 외부 IOP source dependency scan을 포함한다. 실제 Chronos repository import, 최종 layout 결정과 수용 검증은 workspace lock 해제 뒤 downstream Chronos Milestone이 수행한다. diff --git a/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/USER_REVIEW.md b/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/USER_REVIEW.md deleted file mode 100644 index 1dab9da4..00000000 --- a/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/USER_REVIEW.md +++ /dev/null @@ -1,37 +0,0 @@ -# SDD User Review - -## 상태 - -요청됨 - -## 검토 대상 - -- SDD: [SDD.md](SDD.md) -- Milestone: [Milestone 문서](../../../phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md) - -## 사용자 결정 항목 - -### [D01] 기존 config/state versioned export 범위 - -- 결정 필요: 기존 `iop-agent`의 유효한 project registration, user-local config와 durable state 중 무엇을 versioned export로 전달해 잠금 해제 뒤 Chronos가 import할 수 있게 할지 결정한다. -- 추천안: 유효한 project registration·user-local config·중단된 durable state는 source revision·schema version·integrity metadata와 함께 read-only export로 전달하고, 실행 중이거나 identity가 모호한 state는 export하지 않고 blocker manifest에만 남긴다. 실제 import와 활성화는 Chronos 수용 Milestone에서 수행한다. -- 대안: 기존 state export 없이 clean registration만 지원한다. -- 영향: IOP transfer bundle과 fixture 범위, Chronos 수용 단계의 import 범위, 사용자 연속성과 crash recovery 위험을 결정한다. -- 적용 위치: - - SDD: `State Machine`, `Interface Contract`, `Acceptance Scenarios S02/S05` - - Milestone: `transfer`, `handoff-gate`, `구현 잠금` - -## 승인 항목 - -- [ ] 위 결정 항목을 승인했다. -- [ ] SDD 잠금 해제를 승인했다. - -## 답변 기록 - -- 없음 - -## 해결 조건 - -- 모든 사용자 결정 항목의 답변이 SDD에 반영되어 있다. -- `USER_REVIEW.md`가 `user_review_N.log`로 이동되어 있다. -- 남은 잠금 항목이 없으면 SDD 상태가 `[승인됨]`이고 `SDD 잠금` 상태가 `해제`다. diff --git a/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_0.log b/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_0.log new file mode 100644 index 00000000..24edcd73 --- /dev/null +++ b/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_0.log @@ -0,0 +1,45 @@ +# SDD User Review + +## 상태 + +해결됨 + +## 검토 대상 + +- SDD: [SDD.md](SDD.md) +- Milestone: [Milestone 문서](../../../phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md) + +## 사용자 결정 항목 + +### [D01] 기존 등록·설정·저장 상태 전체 이전 + +- 결정: `iop-agent`의 정상적인 프로젝트 등록, 사용자 설정과 저장 상태를 전부 Chronos로 전달한다. 이전 버전의 오류나 비정상 종료로 생긴 깨진 잔여 기록도 재개 가능한 상태로 포장하지 않고 격리 보관 자료로 함께 전달한다. 이전 완료 뒤 IOP에는 관련 상태를 남기지 않는다. +- 영향: Chronos 수용 단계는 전체 상태 이전 묶음과 격리 보관 자료를 입력으로 받고, 실제 import·활성화 여부를 후속 Milestone에서 검증한다. +- 적용 위치: + - SDD: `State Machine`, `Interface Contract`, `Acceptance Scenarios S02/S05` + - Milestone: `transfer`, `handoff-gate`, `구현 잠금` + +### [D02] IOP Node의 책임 경계 + +- 결정: `iop-agent`와 Chronos가 소유할 작업 흐름, 상태, 대상 선택, 재시도, 검토·반영 로직은 IOP Node에 남기지 않는다. Chronos가 완성된 뒤 Node와 연결할 수 있지만, Node에는 Chronos 의미를 모르는 범용 실행·제어 경계만 둔다. +- 영향: IOP 제거 범위와 Node 회귀 기준이 바뀌며, Chronos-to-Node 연결 계약 구현은 현재 Milestone 범위에서 제외하고 후속 작업으로 둔다. +- 적용 위치: + - SDD: `문제 / 비목표`, `Interface Contract`, `Acceptance Scenarios S03/S04` + - Milestone: `decouple`, `retain-node`, `범위 제외`, `작업 컨텍스트` + +## 승인 항목 + +- [x] 위 결정 항목을 승인했다. +- [x] SDD 잠금 해제를 승인했다. + +## 답변 기록 + +- 2026-08-01: D01 — `iop-agent` 관련 상태 전체와 깨진 잔여 기록을 Chronos로 전달하고 IOP에는 남기지 않는다. +- 2026-08-01: D02 — IOP Node에는 Chronos 작업 로직을 남기지 않고 범용 실행·제어 경계만 유지한다. +- 2026-08-01: D03 — 반영된 설계로 SDD 잠금을 해제한다. + +## 해결 조건 + +- 모든 사용자 결정 항목의 답변이 SDD에 반영되어 있다. +- `USER_REVIEW.md`가 이 해결 기록으로 이동되어 있다. +- 남은 잠금 항목이 없으며 SDD 상태는 `[승인됨]`, `SDD 잠금` 상태는 `해제`다. diff --git a/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_1.log b/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_1.log new file mode 100644 index 00000000..5a5ae55d --- /dev/null +++ b/agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/user_review_1.log @@ -0,0 +1,39 @@ +# SDD User Review + +## 상태 + +해결됨 + +## 검토 대상 + +- SDD: [SDD.md](SDD.md) +- Milestone: [Milestone 문서](../../../phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md) + +## 사용자 결정 항목 + +### [D04] 독립 Chronos Server/Node와 IOP 연결점 폐쇄 + +- 결정: Chronos는 외부에서 접근 가능한 자체 Server와 IOP Node와 별개인 Chronos Node를 소유한다. Chronos Server는 canonical work/session state, loop engineering, scheduling, retry와 review를 소유하고, Chronos Node는 원격 workspace, Agent/CLI 실행, terminal/PTY, file/process와 로그/event를 소유한다. IOP Node는 Chronos의 Node, target 또는 bridge가 아니며 Chronos가 연결하거나 제어하지 않는다. IOP에는 model/provider/device 운영에 필요한 실행·취소·상태·usage·lifecycle만 남긴다. +- 영향: 이전 D02에서 열어 두었던 향후 Chronos-to-IOP Node 범용 제어 연결 가능성을 폐기한다. 현재 분리 Milestone 안에서 CLI agent session·terminal/workspace·원격 제어와 future Chronos bridge/API/proto/config를 제거하고, 별도 IOP cleanup Milestone은 만들지 않는다. Chronos가 추론을 사용할 때는 IOP의 외부 API를 일반 client로 호출한다. +- 적용 위치: + - SDD: `문제 / 비목표`, `Source of Truth`, `State Machine`, `Interface Contract`, `Acceptance Scenarios S01/S03/S04`, `Evidence Map`, `승격 기준 분류표` + - Milestone: `목표`, `범위`, `decouple`, `retain-node`, `범위 제외`, `작업 컨텍스트` + - 실행 계획: 완료 evidence가 고정된 03은 변경하지 않고, 미착수 또는 재개 전인 후속 Plan에서 새 책임 경계와 forbidden-reference 검증을 반영한다. + +## 승인 항목 + +- [x] 위 결정 항목을 승인했다. +- [x] 갱신된 SDD 잠금 해제 상태를 유지한다. +- [x] 현재 분리 Milestone이 IOP 연결점 폐쇄까지 흡수하는 방향을 승인했다. + +## 답변 기록 + +- 2026-08-01: Chronos는 자체 Server와 별도 Chronos Node를 두고 loop engineering, agent, terminal과 원격 제어를 직접 소유한다. +- 2026-08-01: IOP Node는 Chronos와 연결하지 않으며 IOP 고유의 model/provider/device 운영 책임만 가진다. +- 2026-08-01: 03 완료 evidence는 유지하고 현재 Milestone과 후속 Plan을 즉시 새 방향으로 조정한다. + +## 해결 조건 + +- D04가 SDD와 Milestone의 IOP/Chronos 책임 경계에 반영되어 있다. +- D04가 D02의 향후 Chronos-to-IOP Node 연결 가능성을 명시적으로 대체한다. +- 활성 `USER_REVIEW.md` 없이 SDD 상태는 `[승인됨]`, `SDD 잠금` 상태는 `해제`다. diff --git a/agent-roadmap/sdd/operational-observability-provider-management/node-provider-execution-liveness-recovery/SDD.md b/agent-roadmap/sdd/operational-observability-provider-management/node-provider-execution-liveness-recovery/SDD.md index 83771310..0451fe8f 100644 --- a/agent-roadmap/sdd/operational-observability-provider-management/node-provider-execution-liveness-recovery/SDD.md +++ b/agent-roadmap/sdd/operational-observability-provider-management/node-provider-execution-liveness-recovery/SDD.md @@ -19,7 +19,7 @@ - 문제: 현재 Node 실행 경로에는 provider request가 terminal 없이 멈췄을 때 request liveness를 판정하고 provider 전체 health를 별도 점검한 뒤 old attempt를 fence하여 Edge 복구로 넘기는 공통 pipeline이 없다. CLI persistent idle은 일부 profile에서 `idle-timeout`을 정상 complete로 취급하고, Node heartbeat·process/socket 생존과 독립 provider probe 성공만으로는 원 요청이 실제 추론 중인지 알 수 없다. - 비목표: - - Node를 거치지 않는 Python dispatcher, 직접 Pi/provider 호출과 standalone `iop-agent` 감시 + - Node를 거치지 않는 Python dispatcher, 직접 Pi/provider 호출과 standalone supervisor 감시 - content 반복, tool-call/schema/품질 검증과 queue wait 정책 변경 - provider가 progress event를 내지 않을 때 내부 reasoning 상태 추정 - provider runtime restart, credential/login 또는 model lifecycle 자동화