feat: update roadmaps for inference provider extension and operational observability

- Update ROADMAP.md and phase documents
- Update vllm/sglang provider serving validation milestones
- Update operational observability PHASE and milestones
- Add provider device model qualification report milestone

agent-roadmap/ROADMAP.md

@@ -14,12 +14,14 @@ A2A는 표면으로 유지하되, NomadCode가 A2A를 도입하는 시점은 현
 현재 제1 active delivery는 NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 OpenAI-compatible Responses 요청의 `metadata.workspace`, task/source metadata, 내부 workspace-bound agent 실행 경로를 먼저 안정화하는 것이다.
 
 모델 선택, 로컬/클라우드 라우팅, 모델별 profile, token/속도/품질 최적화, 모델 호출 로그와 품질 평가는 IOP 책임으로 둔다.
+또한 원격지와 로컬의 Ollama, vLLM, SGLang, Lemonade 같은 추론 엔진은 단순 endpoint가 아니라 provider/device/model 조합으로 관리하고, provider별 lifecycle capability, device 상태, 모델 qualification, 테스트 결과 리포트를 운영 데이터로 축적하는 방향을 목표로 한다.
 특히 로컬 모델을 우선 활용하되, cloud fallback과 품질 평가를 결합해 엔터프라이즈 모델 서비스에 가까운 운영 품질을 목표로 한다.
 RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback은 기본 모델 서빙과 부하 라우팅이 가능해진 뒤 확장한다.
 
 ## MVP 경계
 
 1차 MVP는 다중 Node/디바이스의 model group queue와 추가 provider 검증, 운영을 위한 CLI Agent 사용량/알림, 사용자/토큰/사용량/로그 추적, provider catalog와 로컬 디바이스 상태 관찰, 단계 호출과 runtime schema 검증의 최소 실행 모드를 기준으로 둔다.
+provider/device/model별 qualification report와 모델 lifecycle 관리는 provider serving 경로와 capacity/concurrency 기준선이 잡힌 뒤 `운영 관측과 Provider 관리` Phase의 후반부에서 깊게 구체화한다.
 `(2차)`로 분류한 장기 기억/RAG update loop, advisor, context compression hook, 특정 Node CLI agent의 원격 터널링, oto 기반 자동화 scheduler/CI-CD, cross-Edge/cloud fallback 고도화는 MVP 이후 스케치로 잠근다.
 새로 추가되는 MVP/2차 Milestone은 모두 사용자 검토 전까지 `구현 잠금: 잠금` 상태를 유지하고, 구현 계획이나 세부 API 확정은 별도 구체화 요청에서 다룬다.
 
@@ -47,7 +49,7 @@ RAG, context 구성/압축, web search, MCP 정책, tool policy, output validati
 
 - [계획] 운영 관측과 Provider 관리
   - 경로: `agent-roadmap/phase/operational-observability-provider-management/PHASE.md`
-  - 요약: 사용자/토큰/사용량/로그 추적과 API/CLI/local inference provider catalog, 로컬 디바이스 provider 상태 관리를 MVP 운영 축으로 스케치한다.
+  - 요약: 사용자/토큰/사용량/로그 추적과 API/CLI/local inference provider catalog, 로컬 디바이스 provider 상태 관리, provider/device/model qualification report와 모델 lifecycle 관리 방향을 MVP 운영 축과 후속 심화 축으로 스케치한다.
 
 - [계획] Automation Runtime과 Bridge 확장
   - 경로: `agent-roadmap/phase/automation-runtime-bridge/PHASE.md`

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

@@ -9,6 +9,7 @@
 Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade를 우선 provider로 올리고 이후 vLLM, SGLang 같은 추가 추론 서버 provider를 붙인다.
 이 Phase는 1차 MVP의 속도 향상 축으로, 하나의 Node transport 위에서 여러 CLI profile, terminal gateway, 추론 엔진, model target을 함께 쓰는 구조를 기준선으로 삼고, provider별 adapter/config/target/model 매핑을 단계적으로 검증한다.
 추가 provider를 붙이기 전에 Node가 Ollama/Lemonade/vLLM/SGLang 같은 provider의 최소 가용 상태를 공통 형태로 Edge에 제공하고, Edge가 OpenAI-compatible `model` 값을 group key로 삼아 capacity/queue/admission 상태를 소유하는 기준선을 선행한다.
+이 Phase의 초점은 provider serving path, adapter 경계, model route, capacity, concurrency, queue 성능 검증이며, provider/device/model qualification report와 모델 lifecycle 관리는 후속 운영 관측 Phase의 책임으로 넘긴다.
 다만 현재 제품 우선순위에서는 NomadCode가 IOP Edge OpenAI-compatible Responses를 workspace agent 실행 백엔드로 사용할 수 있는 계약 하드닝이 먼저이며, 이 Phase의 provider/capacity 작업은 그 뒤의 운영 품질 확장으로 둔다.
 
 ## Milestone 흐름
@@ -53,3 +54,4 @@ Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade
 - provider 공통 상태 확인과 Edge-owned model-group capacity/FIFO queue는 추가 provider 검증 전에 필요한 기반으로 이 Phase에서 다룬다.
 - NomadCode `metadata.workspace` 기반 실행 계약과 `/v1/responses` workspace smoke가 충족되기 전에는 이 Phase를 제품 최우선 작업으로 끌어올리지 않는다.
 - OpenAI-compatible `model` 값 기반의 같은 Edge 내부 후보 Node 순차 dispatch는 이 Phase에서 다루되, 별도 model group alias, cross-Edge 자동 부하 라우팅, cloud fallback, 품질 평가 feedback과 후속 최적화 계층은 이 Phase에서 다루지 않는다.
+- 원격 provider의 모델 설치/삭제/load/unload, provider별 container/process lifecycle, provider/device/model qualification report, benchmark/품질 리포트 저장/조회/비교는 `운영 관측과 Provider 관리` Phase의 후반부에서 다룬다.

agent-roadmap/phase/inference-provider-extension/milestones/sglang-provider-serving-validation.md

@@ -21,6 +21,9 @@ Ollama 실테스트에서 안정화한 모델 조회, non-streaming/streaming ch
 ## 구현 잠금
 
 - 상태: 잠금
+- SDD: 필요
+- SDD 경로: `agent-roadmap/sdd/inference-provider-extension/sglang-provider-serving-validation/SDD.md`
+- 잠금 해제 조건: SDD가 승인되고, SGLang provider 경계와 실테스트 endpoint/model/auth/streaming 기대 동작이 구현 계획을 만들 수 있을 만큼 확정되어야 한다.
 - 결정 필요: 아래 체크리스트
   - [ ] SGLang provider를 독립 `sglang` adapter로 둘지, OpenAI-compatible inference server 공통 adapter 계열로 둘지 결정한다.
   - [ ] 실테스트에 사용할 SGLang endpoint, 기준 model, 인증/헤더 필요 여부, streaming 지원 기대 동작을 확인한다.
@@ -56,6 +59,8 @@ Ollama 실테스트에서 안정화한 모델 조회, non-streaming/streaming ch
 ## 범위 제외
 
 - cloud fallback, 자동 부하 라우팅, 품질 평가 feedback의 본격 구현
+- provider/device/model qualification report 저장/조회/비교 제품화
+- 원격 provider 모델 lifecycle 관리 제품화
 - 후속 최적화 계층 구현
 - Responses API 세부 호환 구현
 - 진행중인 Ollama 실테스트와 후속 안정화 범위 변경
@@ -66,6 +71,7 @@ Ollama 실테스트에서 안정화한 모델 조회, non-streaming/streaming ch
 - 관련 경로: `apps/edge`, `apps/node`, `packages/go/config`, `proto/iop`, `configs`, `bin/edge.sh`, `bin/node.sh`, `agent-test/local/edge-smoke.md`, `agent-test/local/node-smoke.md`, `agent-test/local/platform-common-smoke.md`
 - 표준선(선택): 내부 실행 계약은 `adapter + target`을 유지하고, OpenAI-compatible API는 외부 호환 입력 표면으로 둔다.
 - 표준선(선택): Ollama provider에서 안정화한 field smoke 기준을 SGLang provider에도 그대로 적용한다.
+- 표준선(선택): 이 Milestone은 SGLang serving path와 adapter/config/target 매핑 검증에 집중하고, provider/device/model 리포트 제품화는 `운영 관측과 Provider 관리` Phase 후반부에서 다룬다.
 - 선행 작업: Ollama 실테스트와 후속 안정화, Node 단일 통로 멀티 타겟 서빙 기반
 - 후속 작업: SGLang provider 실테스트에서 확인된 serving 경로 안정화 보완
 - 확인 필요: SGLang adapter 경계, 실테스트 endpoint/model, 인증/헤더 필요 여부, streaming 기대 동작

agent-roadmap/phase/inference-provider-extension/milestones/vllm-provider-serving-validation.md

@@ -21,13 +21,19 @@ Edge OpenAI-compatible 입력 표면에서 vLLM의 모델 조회, non-streaming/
 ## 구현 잠금
 
 - 상태: 잠금
+- SDD: 필요
+- SDD 경로: `agent-roadmap/sdd/inference-provider-extension/vllm-provider-serving-validation/SDD.md`
+- 잠금 해제 조건: SDD가 승인되고, vLLM provider 경계와 DGX Spark 실테스트 endpoint/served model/auth/streaming 기대 동작이 구현 계획을 만들 수 있을 만큼 확정되어야 한다.
 - 결정 필요: 아래 체크리스트
   - [ ] vLLM provider를 독립 `vllm` adapter로 둘지, OpenAI-compatible inference server 공통 adapter 계열로 둘지 결정한다.
-  - [ ] 실테스트에 사용할 vLLM endpoint, served model name, 기준 model, 인증/헤더 필요 여부, streaming 지원 기대 동작을 확인한다.
+  - [ ] DGX Spark 실테스트의 vLLM base URL/port, IOP에서 노출할 served model alias, 인증/헤더 필요 여부, streaming 지원 기대 동작을 확인한다.
 
 ## 범위
 
 - vLLM provider를 Ollama 이후의 추가 추론 서버 provider 후보로 로드맵에 추가한다.
+- 실테스트 기준 host는 `agent-test/local/rules.md`에 기록된 DGX Spark field host로 둔다.
+- vLLM 관련 사전 세팅이 없다는 전제로 DGX Spark ARM64/Blackwell용 vLLM container를 올리는 작업부터 범위에 포함한다.
+- 기준 모델은 DGX Spark vLLM recipe의 NVFP4 checkpoint인 `nvidia/Qwen3.6-35B-A3B-NVFP4`로 둔다. 원천 BF16 모델 ID는 `Qwen/Qwen3.6-35B-A3B`이며, Ollama식 사용 의도 `qwen3.6:35b`는 IOP model alias 또는 served model alias 후보로 검증한다.
 - Edge OpenAI-compatible API의 `/v1/models`, `/v1/chat/completions` non-streaming/streaming 요청이 vLLM provider 경로로 수렴하는 기준을 정한다.
 - vLLM provider의 모델 조회, chat completion, streaming chunk, usage/finish reason, option/API passthrough 기대 동작을 실제 endpoint 기준으로 검증한다.
 - split-host field smoke 기준을 vLLM provider에도 재사용한다.
@@ -38,6 +44,7 @@ Edge OpenAI-compatible 입력 표면에서 vLLM의 모델 조회, non-streaming/
 ### Epic: [vllm-provider] vLLM Provider Serving Path
 
 - [ ] [provider-boundary] vLLM provider를 독립 adapter로 둘지 OpenAI-compatible inference server 공통 adapter로 둘지 결정 근거가 정리되어 있다.
+- [ ] [spark-container] `agent-test/local/rules.md`의 DGX Spark field host에서 ARM64/Blackwell용 vLLM container image/tag, model cache/volume, launch command, health check 기준이 정리되고 container 기동이 검증되어 있다. 검증: DGX Spark vLLM endpoint의 OpenAI-compatible `/v1/models`가 응답한다.
 - [ ] [config-contract] vLLM endpoint, served model name, model alias, auth/header, timeout, option passthrough 설정 계약이 정리되어 있다.
 - [ ] [models-chat] Edge OpenAI-compatible `/v1/models`와 non-streaming `/v1/chat/completions`가 vLLM provider로 수렴하는 기준이 검증되어 있다.
 - [ ] [streaming] streaming `/v1/chat/completions`에서 SSE chunk, finish reason, 종료 신호가 vLLM provider 경로로 안정적으로 전달되는지 검증되어 있다.
@@ -57,6 +64,8 @@ Edge OpenAI-compatible 입력 표면에서 vLLM의 모델 조회, non-streaming/
 ## 범위 제외
 
 - cloud fallback, 자동 부하 라우팅, 품질 평가 feedback의 본격 구현
+- provider/device/model qualification report 저장/조회/비교 제품화
+- 원격 provider 모델 lifecycle 관리 제품화
 - 후속 최적화 계층 구현
 - Responses API 세부 호환 구현
 - vLLM 서버 배포/운영 자체의 제품화
@@ -67,6 +76,10 @@ Edge OpenAI-compatible 입력 표면에서 vLLM의 모델 조회, non-streaming/
 - 관련 경로: `apps/edge`, `apps/node`, `packages/go/config`, `proto/iop`, `configs`, `agent-test/local/edge-smoke.md`, `agent-test/local/node-smoke.md`, `agent-test/local/platform-common-smoke.md`
 - 표준선(선택): 내부 실행 계약은 `adapter + target`을 유지하고, OpenAI-compatible API는 외부 호환 입력 표면으로 둔다.
 - 표준선(선택): Ollama provider에서 안정화한 field smoke 기준을 vLLM provider에도 그대로 적용한다.
+- 표준선(선택): 이 Milestone의 DGX Spark vLLM 결과는 후속 qualification report의 seed evidence로 남길 수 있지만, report 저장/조회/비교 제품화는 `운영 관측과 Provider 관리` Phase 후반부에서 다룬다.
+- 결정됨: vLLM 실테스트 host는 `agent-test/local/rules.md`에 기록된 DGX Spark field host이며, vLLM container 세팅부터 시작한다.
+- 결정됨: DGX Spark 기준 vLLM 모델 handle은 `nvidia/Qwen3.6-35B-A3B-NVFP4`로 둔다. 원천 모델은 `Qwen/Qwen3.6-35B-A3B`이고, `qwen3.6:35b`는 IOP model alias 또는 vLLM served model alias 후보로 검증한다.
+- 외부 근거: `https://recipes.vllm.ai/Qwen/Qwen3.6-35B-A3B`, `https://huggingface.co/Qwen/Qwen3.6-35B-A3B`, `https://build.nvidia.com/spark/vllm`
 - 선행 작업: Ollama 실테스트와 후속 안정화, Node 단일 통로 멀티 타겟 서빙 기반
 - 후속 작업: vLLM provider 실테스트에서 확인된 serving 경로 안정화 보완
-- 확인 필요: vLLM adapter 경계, 실테스트 endpoint/served model name, 인증/헤더 필요 여부, streaming 기대 동작
+- 확인 필요: vLLM adapter 경계, DGX Spark vLLM base URL/port, IOP에서 노출할 served model alias, 인증/헤더 필요 여부, streaming 기대 동작

agent-roadmap/phase/operational-observability-provider-management/PHASE.md

@@ -8,6 +8,7 @@
 
 IOP가 여러 Edge, Node, CLI Agent, local inference provider를 운영할 때 필요한 사용자/토큰/사용량/로그/provider 상태 관찰 기준을 정리한다.
 이 Phase는 완성된 billing, enterprise IAM, provider marketplace를 바로 구현하지 않고, 1차 MVP에서 어떤 운영 데이터를 모으고 어떤 화면/명령으로 검토할지 스케치한다.
+provider 확장 Phase에서 검증한 Ollama, vLLM, SGLang, Lemonade 같은 추론 엔진은 provider/device/model 조합으로 관찰하고, 후반부에서는 모델 lifecycle capability와 qualification report를 운영 데이터로 축적하는 방향을 정리한다.
 
 ## Milestone 흐름
 
@@ -23,9 +24,14 @@ IOP가 여러 Edge, Node, CLI Agent, local inference provider를 운영할 때
   - 경로: `agent-roadmap/phase/operational-observability-provider-management/milestones/provider-catalog-device-status.md`
   - 요약: API, CLI, local inference provider를 같은 운영 catalog에서 보고 vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider 상태를 추적하는 경계를 스케치한다.
 
+- [스케치] Provider-Device-Model Qualification 리포트와 Lifecycle 관리
+  - 경로: `agent-roadmap/phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md`
+  - 요약: provider catalog와 device 상태 기준선 뒤에, provider/device/model 조합별 compatibility, performance, quality, lifecycle capability 테스트와 운영 리포트 저장/조회/비교 경계를 깊게 스케치한다.
+
 ## Phase 경계
 
 - Control Plane은 Edge/Node 상태를 보기 쉽게 연결하지만 Edge 내부 상태의 canonical store가 되지 않는다.
 - provider adapter 구현과 endpoint별 serving 검증은 `추론 서버 provider 확장` Phase 책임으로 둔다.
+- provider/device/model qualification report는 provider serving path와 capacity/concurrency 기준선이 잡힌 뒤 이 Phase의 후반부에서 다룬다.
 - 이 Phase는 운영 데이터와 제어 표면의 MVP 경계를 다루며, billing/chargeback, 조직 IAM, 상세 audit schema, 장기 retention 정책은 후속 구체화에서 결정한다.
 - RAG, advisor, context compression hook, output validation 실행 모드는 `지식과 도구 최적화 확장` Phase 책임으로 둔다.

agent-roadmap/phase/operational-observability-provider-management/milestones/provider-catalog-device-status.md

@@ -8,7 +8,8 @@
 ## 목표
 
 API provider, CLI provider, local inference provider를 운영자가 같은 catalog에서 볼 수 있는 MVP 경계를 스케치한다.
-vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider는 adapter 구현 자체가 아니라 상태, capability, 가용성, 운영 표시 기준을 우선 정리한다.
+vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider는 adapter 구현 자체가 아니라 상태, lifecycle capability, 가용성, 운영 표시 기준을 우선 정리한다.
+provider/device/model별 qualification report와 benchmark/품질 비교는 이 Milestone의 직접 구현 범위가 아니라 후속 심화 Milestone으로 분리한다.
 
 ## 상태
 
@@ -18,21 +19,27 @@ vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider는 adapter
 
 - [ ] provider catalog가 다룰 provider category와 표시 필드를 결정한다.
 - [ ] local inference provider의 상태 추적 기준을 결정한다.
+- [ ] provider별 model lifecycle capability를 catalog 표시 필드로 볼지 후속 리포트 Milestone의 입력으로만 둘지 결정한다.
 - [ ] 기존 provider validation Milestone과 중복되지 않는 운영 책임 경계를 정리한다.
 - [ ] Control Plane/Client/CLI 중 provider 관리 MVP 표면을 결정한다.
 
 ## 구현 잠금
 
 - 상태: 잠금
+- SDD: 필요
+- SDD 경로: `agent-roadmap/sdd/operational-observability-provider-management/provider-catalog-device-status/SDD.md`
+- 잠금 해제 조건: SDD가 승인되고, provider catalog의 상태 필드, lifecycle capability 표시 범위, 운영 표면 책임 경계가 구현 계획을 만들 수 있을 만큼 확정되어야 한다.
 - 결정 필요: 아래 체크리스트
   - [ ] provider category를 API, CLI, local inference 외에 어디까지 포함할지 결정한다.
   - [ ] local device/provider 상태를 health, capacity, model list, queue, runtime process 중 어디까지 추적할지 결정한다.
+  - [ ] Ollama/Lemonade처럼 모델 lifecycle API가 있는 provider와 vLLM/SGLang처럼 process/container lifecycle 중심인 provider를 catalog에서 어떻게 구분할지 결정한다.
   - [ ] provider catalog를 읽기 전용 관찰로 시작할지, enable/disable 같은 제어까지 포함할지 결정한다.
 
 ## 범위
 
 - API, CLI, local inference provider category와 catalog 표시 기준
 - local device/provider 상태 추적 기준
+- provider별 model lifecycle capability 표시 기준
 - vLLM, vLLM-MLX, Lemonade, SGLang 같은 provider의 운영 표시 후보
 - provider validation과 운영 catalog의 책임 분리
 
@@ -44,6 +51,7 @@ vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider는 adapter
 
 - [ ] [category-map] API, CLI, local inference provider category와 MVP 표시 필드가 정리되어 있다.
 - [ ] [device-status] 로컬 디바이스 provider의 health, capacity, model, queue 상태 후보가 정리되어 있다.
+- [ ] [lifecycle-cap] Ollama, Lemonade, vLLM, SGLang의 model lifecycle capability 차이를 catalog 필드 또는 후속 report 입력으로 정리한다.
 - [ ] [boundary] provider adapter 구현과 운영 catalog의 책임 경계가 정리되어 있다.
 - [ ] [ops-review] 사용자가 provider catalog MVP 범위와 2차 후보를 검토했다.
 
@@ -60,7 +68,8 @@ vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider는 adapter
 ## 범위 제외
 
 - vLLM, vLLM-MLX, Lemonade, SGLang provider adapter 구현 자체
-- provider marketplace, 자동 설치, 자동 benchmark, cross-Edge provider balancing
+- provider/device/model qualification report 저장/조회/비교
+- 자동 benchmark, 품질 평가, provider marketplace, cross-Edge provider balancing
 - cloud fallback과 품질 평가 feedback 구현
 
 ## 작업 컨텍스트
@@ -68,5 +77,5 @@ vLLM, vLLM-MLX, Lemonade, SGLang 같은 로컬 디바이스 provider는 adapter
 - 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `apps/client`, `packages/go/config`, `proto/iop/runtime.proto`
 - 표준선(선택): provider 실행 구현은 `adapter + target` 기준을 유지하고, catalog는 운영 관찰과 제어 경계를 별도로 정의한다.
 - 선행 작업: Node provider 상태와 Capacity Queue 기반, Edge 모델 그룹 Queue 스케줄링 전환
-- 후속 작업: provider 운영 리포트, provider enable/disable, benchmark/품질 평가
+- 후속 작업: Provider-Device-Model Qualification 리포트와 Lifecycle 관리, provider enable/disable, benchmark/품질 평가
 - 확인 필요: provider category, 상태 추적 필드, 읽기 전용/제어 포함 여부

agent-roadmap/phase/operational-observability-provider-management/milestones/provider-device-model-qualification-report.md

@@ -0,0 +1,87 @@
+# Milestone: Provider-Device-Model Qualification 리포트와 Lifecycle 관리
+
+## 위치
+
+- Roadmap: `agent-roadmap/ROADMAP.md`
+- Phase: `agent-roadmap/phase/operational-observability-provider-management/PHASE.md`
+
+## 목표
+
+Provider Catalog와 로컬 디바이스 상태 기준선 뒤에, Ollama, vLLM, SGLang, Lemonade 같은 provider의 device/model 조합을 테스트하고 결과를 운영 리포트로 축적하는 제품 경계를 스케치한다.
+provider별 모델 lifecycle capability 차이를 IOP가 어떻게 흡수하고, 어떤 결과를 production route 후보 판단에 사용할지 정리한다.
+
+## 상태
+
+[스케치]
+
+## 승격 조건
+
+- [ ] provider/device/model qualification report의 최소 스키마와 저장 책임을 결정한다.
+- [ ] Ollama/Lemonade의 model API 관리와 vLLM/SGLang의 process/container lifecycle 관리 차이를 어떻게 추상화할지 결정한다.
+- [ ] compatibility, performance, quality, resource, failure report 중 MVP에 포함할 항목을 결정한다.
+- [ ] Control Plane, Edge-local CLI, Client 중 report 조회와 lifecycle 제어 표면을 어디에 둘지 결정한다.
+- [ ] 현재 provider 확장 Phase의 vLLM/SGLang serving path 검증 결과를 seed evidence로 어떻게 연결할지 결정한다.
+
+## 구현 잠금
+
+- 상태: 잠금
+- SDD: 필요
+- SDD 경로: `agent-roadmap/sdd/operational-observability-provider-management/provider-device-model-qualification-report/SDD.md`
+- SDD 사유: provider lifecycle 제어, report schema, 저장 책임, 운영 UI/API 경계가 함께 걸리는 제품 설계 Milestone이다.
+- 잠금 해제 조건: 아래 체크리스트
+  - [ ] SDD 잠금이 해제되어 있다.
+  - [ ] SDD 사용자 리뷰가 없거나 승인/해결되었다.
+  - [ ] provider lifecycle 추상화와 report MVP 범위가 구현 계획을 만들 수 있을 만큼 확정되어 있다.
+- 결정 필요: 아래 체크리스트
+  - [ ] IOP가 provider별 모델 설치/삭제/load/unload 또는 container/process start/stop을 어느 수준까지 직접 제어할지 결정한다.
+  - [ ] qualification report를 route recommendation에 바로 사용할지, 초기에는 관찰/리포트로만 둘지 결정한다.
+  - [ ] 성능/품질 테스트가 자동 실행이어야 하는지, 사용자 승인 기반 수동 실행으로 시작할지 결정한다.
+
+## 범위
+
+- provider/device/model 조합별 compatibility, performance, quality, resource, failure report의 최소 필드
+- Ollama, Lemonade, vLLM, SGLang의 model lifecycle capability 차이를 표현하는 공통 추상화
+- vLLM/SGLang처럼 single-model serving process/container 중심인 provider와 Ollama/Lemonade처럼 model API가 있는 provider의 운영 차이
+- provider 확장 Phase에서 나온 serving smoke/field evidence를 qualification seed report로 연결하는 기준
+- 운영자가 provider/device/model 조합을 비교하고 production route 후보, experimental, blocked 같은 상태를 판단하는 MVP 표면
+
+## 기능
+
+### Epic: [qualification-report] Provider Device Model Qualification
+
+provider/device/model 조합을 테스트하고 운영 판단에 쓸 수 있는 리포트로 남기는 capability를 묶는다.
+
+- [ ] [report-schema] provider, device, model alias, checkpoint, served model, runtime version, launch/container args, endpoint, auth policy, test timestamp, result status를 포함한 최소 report schema가 정리되어 있다.
+- [ ] [compat-suite] `/v1/models`, non-streaming chat, streaming chat, usage/finish reason, timeout/error mapping 같은 compatibility test matrix가 정리되어 있다.
+- [ ] [perf-suite] TTFT, tokens/sec, latency p50/p95, concurrency, queue wait, resource usage 후보와 필수/선택 구분이 정리되어 있다.
+- [ ] [quality-suite] canonical prompt set, structured output, reasoning/content handling, tool/schema readiness 같은 quality/eval 후보와 MVP 제외 범위가 정리되어 있다.
+- [ ] [lifecycle-map] Ollama/Lemonade의 model API와 vLLM/SGLang의 process/container lifecycle을 IOP lifecycle action으로 매핑하는 후보가 정리되어 있다.
+- [ ] [ops-surface] Control Plane, Client, Edge-local CLI에서 report 조회, 비교, lifecycle action을 어디까지 노출할지 후보가 정리되어 있다.
+- [ ] [routing-use] report 결과를 route recommendation 또는 production readiness 상태로 사용할지 여부와 보류 기준이 정리되어 있다.
+
+## 완료 리뷰
+
+- 상태: 없음
+- 요청일: 없음
+- 완료 근거: 스케치 Milestone이며 기능 Task가 아직 충족되지 않았다.
+- 리뷰 필요:
+  - [ ] 사용자가 완료 결과를 확인했다
+  - [ ] archive 이동을 승인했다
+- 리뷰 코멘트: 없음
+
+## 범위 제외
+
+- 현재 provider 확장 Phase의 vLLM/SGLang adapter 구현 자체
+- 개별 provider serving path의 최초 연결 검증
+- cloud fallback 자동화와 cross-Edge/global balancing
+- billing/chargeback, 조직 IAM, 장기 audit retention
+- fully automated model marketplace
+
+## 작업 컨텍스트
+
+- 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `apps/client`, `packages/go/config`, `proto/iop`, `agent-test/local`
+- 표준선(선택): provider serving path와 capacity/concurrency 검증은 `추론 서버 provider 확장` Phase에서 먼저 닫고, 이 Milestone은 그 결과를 운영 데이터와 lifecycle 제어 모델로 승격한다.
+- 표준선(선택): OpenAI-compatible compatibility는 공통 test matrix로 보되, provider별 native lifecycle API는 capability 기반으로 optional 처리한다.
+- 선행 작업: Provider Catalog와 로컬 디바이스 상태 관리, vLLM/SGLang provider 서빙 경로 추가
+- 후속 작업: route recommendation, cloud fallback, 품질 기반 routing/fallback 고도화
+- 확인 필요: report schema, lifecycle 제어 범위, 자동/수동 테스트 실행 경계, 운영 표면