update roadmap files for inference provider and knowledge tool optimization

agent-roadmap/phase/inference-provider-extension/PHASE.md

@@ -8,7 +8,7 @@
 
 Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade를 우선 provider로 올리고 이후 vLLM, SGLang 같은 추가 추론 서버 provider를 붙인다.
 이 Phase는 하나의 Node transport 위에서 여러 CLI profile, terminal gateway, 추론 엔진, model target을 함께 쓰는 구조를 기준선으로 삼고, provider별 adapter/config/target/model 매핑을 단계적으로 검증한다.
-추가 provider를 붙이기 전에 Node가 Ollama/Lemonade/vLLM/SGLang 같은 provider의 최소 가용 상태와 IOP-owned capacity/queue 상태를 공통 형태로 Edge에 제공하는 기반을 선행한다.
+추가 provider를 붙이기 전에 Node가 Ollama/Lemonade/vLLM/SGLang 같은 provider의 최소 가용 상태를 공통 형태로 Edge에 제공하고, Edge가 OpenAI-compatible `model` 값을 group key로 삼아 capacity/queue/admission 상태를 소유하는 기준선을 선행한다.
 다만 현재 제품 우선순위에서는 NomadCode가 IOP Edge OpenAI-compatible Responses를 workspace agent 실행 백엔드로 사용할 수 있는 계약 하드닝이 먼저이며, 이 Phase의 provider/capacity 작업은 그 뒤의 운영 품질 확장으로 둔다.
 
 ## Milestone 흐름
@@ -28,6 +28,10 @@ Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade
   - 경로: `agent-roadmap/archive/phase/inference-provider-extension/milestones/lemonade-provider-serving-validation.md`
   - 요약: Node provider 상태와 capacity queue 기반 위에서 Lemonade provider의 adapter/config/target/model 매핑과 모델 조회, non-streaming/streaming chat 경로를 검증했고, 사용자 승인에 따라 archive했다.
 
+- [진행중] Edge 모델 그룹 Queue 스케줄링 전환
+  - 경로: `agent-roadmap/phase/inference-provider-extension/milestones/edge-model-group-queue-scheduling.md`
+  - 요약: OpenAI-compatible 요청의 `model` 값을 queue group key로 사용하고, Node-local admission queue를 Edge-owned model-group FIFO와 node dispatch scheduler로 전환한다.
+
 - [진행중] vLLM provider 서빙 경로 추가
   - 경로: `agent-roadmap/phase/inference-provider-extension/milestones/vllm-provider-serving-validation.md`
   - 요약: Ollama 경로와 Node 단일 통로 멀티 타겟 기준선을 바탕으로 vLLM OpenAI-compatible provider를 붙이고, 모델 조회와 non-streaming/streaming chat을 검증한다.
@@ -42,6 +46,6 @@ Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade
 - 진행중인 Ollama 실테스트와 후속 안정화 작업을 이 Phase로 흡수하지 않는다.
 - provider 작업 우선순위는 Ollama 기준선 다음 Lemonade를 우선하고, vLLM/SGLang은 그 뒤 후보로 둔다.
 - 여러 추론 서버 provider 표준화는 Ollama 경로가 안정화된 결과와 Node 단일 통로 멀티 타겟 기준선을 함께 기준으로 삼아 진행한다.
-- provider 공통 상태 확인과 Node-owned capacity/FIFO queue는 추가 provider 검증 전에 필요한 기반으로 이 Phase에서 다룬다.
+- provider 공통 상태 확인과 Edge-owned model-group capacity/FIFO queue는 추가 provider 검증 전에 필요한 기반으로 이 Phase에서 다룬다.
 - NomadCode `metadata.workspace` 기반 실행 계약과 `/v1/responses` workspace smoke가 충족되기 전에는 이 Phase를 제품 최우선 작업으로 끌어올리지 않는다.
 - model group alias, 여러 Node/Edge 후보 간 자동 부하 라우팅, cloud fallback, 품질 평가 feedback과 후속 최적화 계층은 이 Phase에서 다루지 않는다.

agent-roadmap/phase/inference-provider-extension/milestones/edge-model-group-queue-scheduling.md

@@ -0,0 +1,71 @@
+# Milestone: Edge 모델 그룹 Queue 스케줄링 전환
+
+## 위치
+
+- Roadmap: `agent-roadmap/ROADMAP.md`
+- Phase: `agent-roadmap/phase/inference-provider-extension/PHASE.md`
+
+## 목표
+
+OpenAI-compatible 요청의 `model` 필드를 그대로 queue group key로 사용해, 같은 모델 그룹의 요청은 Edge에 있는 단일 FIFO queue에 세운다.
+Node는 Edge가 dispatch한 실행을 수행하고 현재 실행 상태를 보고하는 역할로 단순화하며, Edge는 각 Node의 완료/실패/취소/연결 종료 이벤트를 기준으로 다음 대기 요청을 순차 dispatch한다.
+
+## 상태
+
+[진행중]
+
+## 승격 조건
+
+- 없음
+
+## 구현 잠금
+
+- 상태: 해제
+- 결정 필요: 없음
+
+## 범위
+
+- OpenAI-compatible `model` 값을 model group queue key로 사용한다.
+- Edge service 계층이 model group별 FIFO queue, capacity, in-flight, queued, queue timeout을 소유한다.
+- 같은 model group에 연결된 여러 Node 후보가 있어도 queue는 Edge에 하나만 두고, runnable slot이 생긴 Node로 순차 dispatch한다.
+- Node의 provider/adapter admission queue는 제거하거나 Edge dispatch 이후의 실행 안전장치 수준으로 축소한다.
+- Node command/capability snapshot의 queued/in-flight 의미를 Edge-owned runtime snapshot과 충돌하지 않게 정리한다.
+- OpenAI Chat Completions/Responses, A2A/console 경로가 같은 Edge-owned dispatch 경계로 수렴하는지 확인한다.
+
+## 기능
+
+### Epic: [edge-queue] Edge-Owned Model Queue
+
+- [ ] [group-key] OpenAI-compatible 요청의 `model` 값을 그대로 model group queue key로 쓰는 routing 계약이 정리되어 있다.
+- [ ] [edge-admission] Edge service가 model group별 FIFO admission queue, capacity, max_queue, queue_timeout, in-flight 상태를 소유한다.
+- [ ] [node-dispatch] Edge가 Node별 실행 가능 slot과 terminal run event를 기준으로 queue head를 다음 Node에 순차 dispatch한다.
+- [ ] [node-simplify] Node-local provider FIFO queue가 제거되거나 Edge dispatch 이후의 실행 안전장치로 축소되어, 각 Node가 queue owner가 되지 않는다.
+- [ ] [snapshot-contract] Edge-visible capacity/in-flight/queued snapshot이 Edge-owned model group 상태를 기준으로 표현되고 Node capability snapshot과 충돌하지 않는다.
+- [ ] [surface-coverage] OpenAI Chat Completions/Responses와 A2A/console 실행 경로가 Edge-owned queue 경계를 우회하지 않는다.
+- [ ] [verification] Edge-owned queue의 FIFO 순서, queue overflow/timeout, run terminal release, node disconnect release, multi-node dispatch가 테스트로 검증되어 있다. 검증: 대상 Go 패키지 테스트와 queue 관련 regression test가 통과한다.
+
+## 완료 리뷰
+
+- 상태: 없음
+- 요청일: 없음
+- 완료 근거: 모든 기능 Task가 아직 충족되지 않았다.
+- 리뷰 필요:
+  - [ ] 사용자가 완료 결과를 확인했다
+  - [ ] archive 이동을 승인했다
+- 리뷰 코멘트: 없음
+
+## 범위 제외
+
+- cloud fallback, 자동 품질 평가 feedback, cross-Edge 부하 라우팅
+- provider별 실제 endpoint 운영/배포 제품화
+- vLLM/SGLang provider 실테스트 완료 판정
+- OpenAI-compatible `model` 외 별도 `model_group` 공개 필드 추가
+
+## 작업 컨텍스트
+
+- 관련 경로: `apps/edge`, `apps/node`, `packages/go/config`, `proto/iop`, `configs`
+- 표준선(선택): 내부 실행은 계속 `adapter + target` 기준을 유지하고, OpenAI-compatible 외부 경계의 `model` 값만 Edge queue group key로 사용한다.
+- 표준선(선택): queue owner는 Edge이며, Node는 dispatch된 실행과 provider availability/probe 결과를 제공하는 실행자다.
+- 선행 작업: Node provider 상태와 Capacity Queue 기반, Lemonade provider 서빙 경로 추가
+- 후속 작업: vLLM provider 서빙 경로 추가, SGLang provider 서빙 경로 추가
+- 확인 필요: 없음

agent-roadmap/phase/knowledge-tool-optimization-extension/milestones/knowledge-tool-validation-optimization.md

@@ -9,6 +9,8 @@
 
 기본 모델 서빙과 부하 라우팅이 가능해진 뒤, RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback을 IOP의 추론 최적화 계층으로 확장한다.
 NomadCode는 이 계층의 소비자 중 하나이며, 이 Milestone은 특정 Agent Shell에 종속되지 않는 공통 IOP 책임을 정의한다.
+RAG에는 대규모 프로젝트의 문서/코드 변경을 따라가는 knowledge ingestion/update loop, chunking, embedding 생성, vector index 갱신, 권한 metadata 동기화 같은 비동기 작업 라인을 포함한다.
+검증 최적화에는 단순 부하 라우팅 이후의 실행 방식으로, Edge API 하네스 기반 검증/재시도 루프와 모델별 역할을 분리한 단계적 호출을 포함한다.
 
 ## 상태
 
@@ -21,13 +23,17 @@ NomadCode는 이 계층의 소비자 중 하나이며, 이 Milestone은 특정 A
   - [ ] 첫 최적화 범위를 RAG, web search, MCP/tool policy, validation/fallback 중 어디까지로 둘지 결정한다.
   - [ ] MCP/tool policy와 web search의 보안 기본값을 허용 중심으로 둘지 차단/승인 중심으로 둘지 결정한다.
   - [ ] validation/fallback의 품질 기준을 어떤 신호와 임계값으로 시작할지 결정한다.
+  - [ ] RAG ingestion/update loop를 담당할 worker/background job 경계, index 저장소, 변경 감지 기준을 결정한다.
+  - [ ] IOP 실행 모드 중 단순 부하 라우팅, 하네스 기반 검증/재시도 루프, 모델별 역할 분리 단계 호출의 우선순위와 최소 계약을 결정한다.
 
 ## 범위
 
 - RAG 검색과 context 구성/압축 책임 경계
+- RAG/MCP 확장을 위한 knowledge ingestion/update loop, chunking, embedding 생성, vector index 갱신, incremental reindex, 권한 metadata 동기화 기준
 - web search를 IOP 지식 소스로 통합하는 기준
 - MCP allow/block/injection 정책과 tool policy 기준
 - output validation, retry/fallback, token/속도/품질 최적화 기준
+- Edge API 하네스 기반 검증/재시도 루프와 모델별 역할 분리 단계 호출을 IOP 실행 모드로 제공하는 기준
 - 모델 호출 로그와 품질 평가 결과를 후속 routing 판단에 연결하는 방향
 
 ## 기능
@@ -35,10 +41,12 @@ NomadCode는 이 계층의 소비자 중 하나이며, 이 Milestone은 특정 A
 ### Epic: [knowledge-policy] Knowledge and Tool Policy
 
 - [ ] [knowledge-policy] 지식 소스, context 구성/압축, MCP/tool policy, validation/fallback 책임 경계가 IOP 책임으로 문서화되어 있다.
+- [ ] [rag-index-loop] 대규모 프로젝트 RAG를 위한 ingestion/update loop, chunking, embedding 생성, vector index 갱신, incremental reindex, 권한 metadata 동기화, worker/background job 경계가 RAG/MCP 하위 라인으로 정리되어 있다.
 - [ ] [web-search-context] web search는 RAG/context 최적화 후보에 포함되어 IOP 지식 소스 경계에서 다룬다.
 - [ ] [client-surface] NomadCode와 다른 외부 agent는 OpenAI-compatible API를 기본 호출 표면으로 사용하고, IOP 전용 workspace/session/agent/policy 문맥은 별도 `iop` wrapper field가 아니라 `metadata` 확장 또는 IOP native endpoint의 명시 필드로 전달한다.
 - [ ] [shell-boundary] 특정 Agent Shell이나 Project Workspace UI 요구가 IOP 최적화 책임을 오염시키지 않도록 범위를 분리한다.
-- [ ] [validation-policy] 검증과 fallback은 모델 선택/라우팅 결과를 보완하는 IOP 내부 정책으로 정의한다.
+- [ ] [validation-policy] 검증과 fallback은 모델 선택/라우팅 결과를 보완하는 IOP 내부 정책으로 정의하고, Edge API 하네스 기반 검증/재시도 루프를 그 실행 모드 중 하나로 정리한다.
+- [ ] [orchestration-modes] 단순 부하 라우팅, 하네스 기반 검증/재시도 루프, 모델별 역할 분리 단계 호출을 Cline 등 외부 소비자가 선택할 수 있는 IOP 실행 모드로 정리한다.
 
 ## 완료 리뷰
 
@@ -53,15 +61,19 @@ NomadCode는 이 계층의 소비자 중 하나이며, 이 Milestone은 특정 A
 ## 범위 제외
 
 - 기본 모델 serving/load routing 없이 RAG/MCP/validation부터 구현
+- RAG ingestion/update loop의 배치 형태와 저장소 계약 없이 embedding/indexing worker 구현부터 시작
 - NomadCode Agent Shell 자체 구현
 - NomadCode 전용 Project Workspace, diff/PR/branch/commit UX
 - OpenCode, Aider, Claude Code, Gemini CLI, Codex CLI adapter 직접 추가 구현
 
 ## 작업 컨텍스트
 
-- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `packages/go/policy`, `packages/go/observability`, `proto/iop`, `README.md`, `agent-roadmap/archive/phase/serving-routing-optimization/milestones/model-serving-load-routing.md`
+- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `apps/worker`, `packages/go/jobs`, `packages/go/policy`, `packages/go/observability`, `proto/iop`, `README.md`, `agent-roadmap/archive/phase/serving-routing-optimization/milestones/model-serving-load-routing.md`
 - 표준선(선택): 기본 모델 serving/load routing이 먼저 안정화된 뒤 최적화 계층을 붙인다.
 - 표준선(선택): 외부 실행 호출 계약은 OpenAI-compatible shape를 우선 유지하고, IOP 고유 문맥은 `metadata`로 확장한다. 완전 신규 프로토콜은 OpenAI-compatible 표면으로 lifecycle, artifact, cancel, approval, streaming 요구를 감당하기 어렵다는 근거가 생길 때 재검토한다.
+- 표준선(선택): 임베딩 생성/인덱싱 worker는 별도 불일치 항목이 아니라 RAG/MCP 확장을 운영 가능한 수준으로 만들기 위한 knowledge ingestion/update loop 하위 라인으로 본다. 배치 형태는 서비스 내부 worker 모듈과 별도 `apps/worker` 앱 후보를 함께 열어둔다.
+- 표준선(선택): Edge API 검증 재시도 루프는 단순 provider 라우팅과 충돌하는 책임이 아니라, IOP가 제공할 여러 실행 방식 중 하나인 하네스 기반 검증/재시도 모드로 본다.
+- 표준선(선택): 모델별 역할 분리 단계 호출은 planner/generator/verifier 같은 역할을 필요에 따라 나누고, 최종 응답은 Edge API 사용자가 선택한 모드의 결과로 반환하는 방향에서 검토한다.
 - 선행 작업: Ollama 서빙 안정화, Control Plane과 Client 운영
 - 후속 작업: 정책/이력/감사와 품질 기반 routing/fallback 고도화
-- 확인 필요: 첫 최적화 범위, tool/web 보안 기본값, validation/fallback 품질 기준
+- 확인 필요: 첫 최적화 범위, tool/web 보안 기본값, validation/fallback 품질 기준, RAG update loop worker 배치 경계, IOP 실행 모드 우선순위와 최소 계약