update roadmap and milestones
This commit is contained in:
parent
812a3a1788
commit
5948efcf42
14 changed files with 144 additions and 58 deletions
21
README.md
21
README.md
|
|
@ -4,6 +4,10 @@ IOP(Inference Operations Platform)는 단순한 모델 라우터나 OpenAI API p
|
|||
|
||||
IOP는 **Control Plane - Edge - Node** 계층 구조를 기반으로, 여러 로컬 모델 런타임과 CLI Agent 실행 환경을 통합 관리하는 실행 오케스트레이션 플랫폼을 지향한다. 모델 서빙, CLI Agent 실행, shell/git/docker/code workspace 작업, node maintenance 작업을 같은 실행 파이프라인에서 다룰 수 있도록 만드는 것이 핵심 방향이다.
|
||||
|
||||
IOP는 NomadCode 전용 Agent Shell이 아니라, NomadCode와 외부 agent, 운영 CLI, Portal, 자동화 도구가 함께 소비할 수 있는 범용 추론/자동화 운영 엔진이다. NomadCode는 IOP의 중요한 소비자 중 하나지만, IOP의 프로토콜과 운영 계층은 특정 제품 UX에 종속되지 않는다.
|
||||
|
||||
모델 선택, 로컬/클라우드 라우팅, 모델별 profile, token/속도/품질 최적화, 모델 호출 로그와 품질 평가는 IOP 책임으로 둔다. RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback은 기본 모델 서빙과 부하 라우팅이 가능해진 뒤 확장하는 최적화 계층으로 본다.
|
||||
|
||||
현재 프로젝트는 완성된 운영 시스템이 아니라 스켈레톤 단계다. 이 README는 현재 구현의 세부 사용법보다, 프로젝트가 향하는 구조와 경계를 명확히 설명한다.
|
||||
|
||||
## Overview
|
||||
|
|
@ -11,6 +15,7 @@ IOP는 **Control Plane - Edge - Node** 계층 구조를 기반으로, 여러 로
|
|||
IOP의 실행 대상은 크게 두 가지다.
|
||||
|
||||
- **Model Serving**
|
||||
- OpenAI-compatible model calls
|
||||
- Ollama
|
||||
- vLLM
|
||||
- MLX
|
||||
|
|
@ -171,13 +176,17 @@ IOP 내부 실행은 model 중심이 아니라 adapter 중심으로 정리한다
|
|||
|
||||
Runtime Domain은 모델 서빙 중심 실행 영역이다.
|
||||
|
||||
- OpenAI API 호환 요청
|
||||
- OpenAI-compatible `/v1/models`, `/v1/chat/completions` baseline
|
||||
- OpenAI-compatible `/v1/responses` 계획 표면
|
||||
- Ollama, vLLM, MLX 같은 모델 런타임
|
||||
- 모델 라우팅
|
||||
- 로컬/클라우드 모델 라우팅
|
||||
- 모델 profile과 부하 라우팅
|
||||
- 추론 요청 처리
|
||||
- usage, 호출 로그, 품질 평가 신호
|
||||
- 모델 런타임 adapter 확장
|
||||
|
||||
이 영역에서도 내부적으로는 `adapter + target` 개념을 사용한다. 예를 들어 OpenAI 호환 요청의 `model` 값은 내부에서 특정 adapter와 target으로 해석될 수 있다.
|
||||
RAG, context 구성/압축, web search, MCP 정책, tool policy, output validation, retry/fallback은 이 기본 serving/load routing 기반이 정리된 뒤 Runtime 최적화 계층으로 확장한다.
|
||||
|
||||
### Automation Domain
|
||||
|
||||
|
|
@ -207,6 +216,7 @@ NomadCode
|
|||
- Node 등록, 설정 전달, 실행 요청, 스트리밍 이벤트 흐름이 점진적으로 정리되고 있다.
|
||||
- Edge 내부에는 API 전환을 고려한 `apps/edge/internal/service`와 in-process event fanout인 `apps/edge/internal/events`가 있다.
|
||||
- cli adapter(node execution implementation) 쪽 구현이 먼저 진행되고 있다.
|
||||
- OpenAI-compatible API는 현재 `/v1/models`, `/v1/chat/completions` baseline을 기준으로 정리되어 있으며, `/v1/responses` 호환은 후속 모델 서빙/라우팅 단계의 필수 표면으로 둔다.
|
||||
- edge-local ops console의 `/` 명령은 수동 테스트 표면이며, 장기 인터페이스는 별도 HTTP/API 표면으로 추가한다.
|
||||
- 현재 실행 이력은 Node local SQLite store에서 검증 중이다. Edge 단위 이력 집계와 로컬 실행 그룹 상태 소유권은 로드맵에 따라 정리한다.
|
||||
- `mock` adapter와 dummy/TODO 구현은 개발 단계에서 정상적인 구성이다.
|
||||
|
|
@ -233,15 +243,16 @@ NomadCode
|
|||
제품 방향, 단계, 마일스톤, 우선순위의 단일 기준 문서는 `agent-ops/roadmap/ROADMAP.md`다.
|
||||
일반 작업에서 AI가 읽어야 하는 현재 작업 기준은 `agent-ops/roadmap/current.md`가 가리키는 기본 마일스톤 또는 요청에 맞는 활성 마일스톤 문서다.
|
||||
|
||||
로드맵의 큰 축은 Edge-Node 실행 기반, Edge input surface, CLI Automation runtime, remote terminal bridge, agent bootstrap/OTO enrollment, Control Plane/Portal, policy/history/audit, multi-edge operations로 관리한다.
|
||||
로드맵의 큰 축은 Edge-Node 실행 기반, Edge input surface, CLI Automation runtime, remote terminal bridge, agent bootstrap/OTO enrollment, 모델 서빙과 부하 라우팅, RAG/web search/MCP/tool policy/검증 최적화, Control Plane/Portal, policy/history/audit, multi-edge operations로 관리한다.
|
||||
|
||||
## Development Notes
|
||||
|
||||
- 기존 구조를 우선하며, 세부 구현은 각 작업의 domain rule과 현재 코드 경계를 먼저 확인한 뒤 진행한다.
|
||||
- 내부 통신은 TCP/protobuf 기반 소켓 흐름을 우선한다.
|
||||
- gRPC 도입, WebSocket 기본 transport 전환, actor/FSM/plugin framework 도입은 현재 단계의 기본 방향이 아니다.
|
||||
- OpenAI API 호환 계층은 외부 호환을 위한 표면이며, 내부 실행 모델 전체를 대표하지 않는다.
|
||||
- A2A API 계층은 agent 간 작업 위임과 상태 공유를 위한 표면이며, 단순 모델 호출 호환은 OpenAI-compatible API를 사용한다.
|
||||
- OpenAI-compatible API 계층은 외부 모델 호출 호환을 위한 표면이며, 내부 실행 모델 전체를 대표하지 않는다.
|
||||
- OpenAI-compatible API는 현재 chat completions baseline을 가지며, Responses API 호환 표면까지 지원하는 방향으로 확장한다.
|
||||
- A2A API 계층은 agent 간 작업 위임과 상태 공유를 위한 표면이며, 단순 모델 호출 호환은 OpenAI-compatible API를 사용한다. NomadCode의 A2A 도입 시점은 아직 강제하지 않는다.
|
||||
- IOP native protocol은 OpenAI-compatible API나 A2A API를 대체하는 것이 아니라, Edge/Node 운영 제어와 CLI/session/command/event 같은 IOP 고유 기능을 제공하는 병행 표면이다.
|
||||
- Remote terminal bridge는 Edge/Node 운영 제어 기능으로 분류하며, OpenAI-compatible API가 아니라 IOP native protocol과 정책/audit 계층에서 다룬다.
|
||||
- 앱별 README에는 현재 수동 테스트나 구현 세부가 더 많이 남아 있을 수 있다. 루트 README는 전체 방향과 경계를 설명하는 문서로 유지한다.
|
||||
|
|
|
|||
|
|
@ -35,6 +35,7 @@ RAG, context 구성/압축, web search, MCP 정책, tool policy, output validati
|
|||
|
||||
- [CLI Automation Runtime 안정화](milestones/cli-automation-runtime-stabilization.md) - 상태: 완료; 목표: one-shot, persistent terminal, opencode SSE, codex exec 같은 CLI 실행 모드를 같은 adapter execution 모델 안에서 안정화한다.
|
||||
- [원격 터미널 브리지 POC](milestones/remote-terminal-bridge-poc.md) - 상태: 계획; 목표: Agent를 설치하기 어려운 host/device를 위해 Edge broker와 Node terminal transport 기반 원격 터미널 브리지 POC를 만든다.
|
||||
- [Specialized Agent proto-socket 연결 기반](milestones/specialized-agent-proto-socket-foundation.md) - 상태: 계획; 목표: generic Node와 OTO 같은 specialized domain agent가 Edge와 proto-socket으로 직접 통신하기 위한 transport/handshake 책임 경계를 정리한다.
|
||||
- [Agent Bootstrap과 OTO 등록](milestones/agent-bootstrap-oto-enrollment.md) - 상태: 계획; 목표: specialized domain agent의 bootstrap command 발급, 설치, 등록, 장기 credential 흐름을 설계한다.
|
||||
|
||||
### 서빙 라우팅과 최적화 기반
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@
|
|||
## 활성 Milestone
|
||||
|
||||
- 원격 터미널 브리지 POC: agent-ops/roadmap/milestones/remote-terminal-bridge-poc.md
|
||||
- Specialized Agent proto-socket 연결 기반: agent-ops/roadmap/milestones/specialized-agent-proto-socket-foundation.md
|
||||
|
||||
## 선택 규칙
|
||||
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ Automation Runtime과 Bridge 확장
|
|||
- 상태: 잠금
|
||||
- 이유: specialized domain agent 등록과 bootstrap 책임 경계를 정리하는 게이트 문서이며, 구현 가능한 세부 설계가 아직 확정되지 않았다.
|
||||
- 해제 조건:
|
||||
- [ ] Specialized Agent proto-socket 연결 기반에서 generic Node와 specialized domain agent의 transport/handshake 경계가 문서화됨
|
||||
- [ ] agent registry, bootstrap command, credential 흐름, 보안 검증 기준이 문서화됨
|
||||
- [ ] generic Node와 OTO 같은 specialized domain agent의 protocol 경계가 구체화됨
|
||||
- [ ] 사용자가 이 Milestone의 구현 구체화와 잠금 해제를 명시적으로 승인함
|
||||
|
|
@ -36,16 +37,20 @@ Automation Runtime과 Bridge 확장
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] OTO agent는 `iop-node` 하위 프로세스가 아니라 Edge에 직접 outbound 연결하는 specialized domain agent로 둔다.
|
||||
- [ ] Agent를 설치할 수 있는 대상은 bootstrap/enrollment를 우선한다.
|
||||
- [ ] Agent 설치가 어렵거나 일회성 유지보수 대상이면 remote terminal bridge 경로와 구분한다.
|
||||
- [ ] HTTP local/insecure bootstrap 모드는 명시 선택과 추가 검증 조건을 요구한다.
|
||||
- [ ] [direct-agent] OTO agent는 `iop-node` 하위 프로세스가 아니라 Edge에 직접 outbound 연결하는 specialized domain agent로 둔다.
|
||||
- [ ] [bootstrap-first] Agent를 설치할 수 있는 대상은 bootstrap/enrollment를 우선한다.
|
||||
- [ ] [bridge-split] Agent 설치가 어렵거나 일회성 유지보수 대상이면 remote terminal bridge 경로와 구분한다.
|
||||
- [ ] [insecure-policy] HTTP local/insecure bootstrap 모드는 명시 선택과 추가 검증 조건을 요구한다.
|
||||
- [ ] [ownership] iop와 OTO의 책임 경계가 문서화되어 있다.
|
||||
- [ ] [iop-ownership] iop는 Edge agent registry, bootstrap command 발급, credential, 보안 검증 기준을 소유한다.
|
||||
- [ ] [oto-ownership] OTO는 build/deploy domain agent의 설치 산출물, 설정 생성, YAML run/capability/event 의미를 소유한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- [ ] Edge가 agent 생성과 bootstrap command 발급 상태를 표현할 수 있다.
|
||||
- [ ] bootstrap command 실행 후 agent config/service 등록과 Edge outbound enrollment 흐름이 문서화된다.
|
||||
- [ ] OTO agent와 generic Node의 책임 경계가 registry와 protocol 수준에서 구분된다.
|
||||
- [ ] OTO의 Edge bootstrap 계약 문서가 이 Milestone의 산출물을 참조해 재개 가능한 상태가 된다.
|
||||
|
||||
## 범위 제외
|
||||
|
||||
|
|
@ -57,4 +62,6 @@ Automation Runtime과 Bridge 확장
|
|||
|
||||
- 관련 앱: `apps/edge`, 향후 OTO agent repository
|
||||
- 관련 문서: `docs/deploy-dev.md`, `docs/architecture.md`
|
||||
- 선행 Milestone: Edge-Node 실행 스켈레톤, Edge 입력 표면
|
||||
- 선행 Milestone: Edge-Node 실행 스켈레톤, Edge 입력 표면, Specialized Agent proto-socket 연결 기반
|
||||
- 후속 OTO Milestone: `../oto/agent-ops/roadmap/milestones/edge-bootstrap-contract.md`
|
||||
- OTO 쪽 Edge bootstrap 계약은 이 Milestone에서 사용자 흐름, bootstrap command 요구사항, 보안 모드 기준이 정리된 뒤 재개한다.
|
||||
|
|
|
|||
|
|
@ -34,15 +34,15 @@ Automation Runtime과 Bridge 확장
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [x] CLI adapter는 profile별 실행 모드를 `node.Node` 분기 없이 adapter 내부에서 처리한다.
|
||||
- [x] output format별 파싱은 `lineEmitter` 또는 모드별 구현으로 분리한다.
|
||||
- [x] persistent terminal profile은 idle timeout, completion marker, cancel drain 기준을 명확히 가진다.
|
||||
- [x] `NodeCommandRequest` 경로는 실행 요청과 분리된 조회/제어 명령으로 유지한다.
|
||||
- [x] 운영 명령 응답과 검증 기준을 마무리한다.
|
||||
- [x] `SESSION_LIST`, `USAGE_STATUS`, `TRANSPORT_STATUS` 응답 payload를 운영자가 읽기 쉬운 필드로 정리한다.
|
||||
- [x] 대상 패키지 테스트와 field smoke 절차로 운영 명령 응답을 검증한다.
|
||||
- [x] Node local execution history와 Edge event aggregation의 책임 경계를 확인한다.
|
||||
- [x] 주요 CLI profile별 field smoke 결과를 수집하고 마일스톤 종료 여부를 결정한다.
|
||||
- [x] [profile-modes] CLI adapter는 profile별 실행 모드를 `node.Node` 분기 없이 adapter 내부에서 처리한다.
|
||||
- [x] [output-parsing] output format별 파싱은 `lineEmitter` 또는 모드별 구현으로 분리한다.
|
||||
- [x] [persistent-session] persistent terminal profile은 idle timeout, completion marker, cancel drain 기준을 명확히 가진다.
|
||||
- [x] [command-path] `NodeCommandRequest` 경로는 실행 요청과 분리된 조회/제어 명령으로 유지한다.
|
||||
- [x] [ops-command] 운영 명령 응답과 검증 기준을 마무리한다.
|
||||
- [x] [ops-payload] `SESSION_LIST`, `USAGE_STATUS`, `TRANSPORT_STATUS` 응답 payload를 운영자가 읽기 쉬운 필드로 정리한다.
|
||||
- [x] [ops-smoke] 대상 패키지 테스트와 field smoke 절차로 운영 명령 응답을 검증한다.
|
||||
- [x] [history-boundary] Node local execution history와 Edge event aggregation의 책임 경계를 확인한다.
|
||||
- [x] [profile-smoke] 주요 CLI profile별 field smoke 결과를 수집하고 마일스톤 종료 여부를 결정한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -38,11 +38,11 @@ Control Plane과 Portal 운영
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] Control Plane은 Node를 직접 연결하거나 직접 스케줄링하지 않는다.
|
||||
- [ ] Portal은 Control Plane을 통해 Edge 운영 상태를 조회한다.
|
||||
- [ ] Portal은 IOP 자체 운영 UI/UX이며 NomadCode에 맞춘 전용 shell로 만들지 않는다.
|
||||
- [ ] 브라우저 직접 TCP가 어려운 구간은 Control Plane server-side bridge를 둔다.
|
||||
- [ ] `net/http`는 health/readiness/bootstrap 같은 보조 endpoint 용도로 유지한다.
|
||||
- [ ] [edge-mediated] Control Plane은 Node를 직접 연결하거나 직접 스케줄링하지 않는다.
|
||||
- [ ] [portal-via-cp] Portal은 Control Plane을 통해 Edge 운영 상태를 조회한다.
|
||||
- [ ] [portal-boundary] Portal은 IOP 자체 운영 UI/UX이며 NomadCode에 맞춘 전용 shell로 만들지 않는다.
|
||||
- [ ] [server-bridge] 브라우저 직접 TCP가 어려운 구간은 Control Plane server-side bridge를 둔다.
|
||||
- [ ] [http-boundary] `net/http`는 health/readiness/bootstrap 같은 보조 endpoint 용도로 유지한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -33,11 +33,11 @@ Edge-Node 실행 기반
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [x] OpenAI-compatible API는 모델/chat completion 호환 입력 표면으로 유지한다.
|
||||
- [x] A2A API는 외부 agent의 작업 위임과 task 상태 공유 표면으로 유지한다.
|
||||
- [x] 두 입력 표면 모두 Edge service와 edge-node transport를 우회하지 않는다.
|
||||
- [x] OpenAI-compatible API에 IOP 고유 운영 제어 기능을 억지로 싣지 않는다.
|
||||
- [x] A2A API를 Control Plane 운영 제어 프로토콜로 확장하지 않는다.
|
||||
- [x] [openai-surface] OpenAI-compatible API는 모델/chat completion 호환 입력 표면으로 유지한다.
|
||||
- [x] [a2a-surface] A2A API는 외부 agent의 작업 위임과 task 상태 공유 표면으로 유지한다.
|
||||
- [x] [edge-service-path] 두 입력 표면 모두 Edge service와 edge-node transport를 우회하지 않는다.
|
||||
- [x] [openai-boundary] OpenAI-compatible API에 IOP 고유 운영 제어 기능을 억지로 싣지 않는다.
|
||||
- [x] [a2a-boundary] A2A API를 Control Plane 운영 제어 프로토콜로 확장하지 않는다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -34,12 +34,12 @@ Edge-Node 실행 기반
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [x] NodeStore와 Registry가 사전 등록 node와 연결 node를 구분해 관리한다.
|
||||
- [x] Edge가 node 설정을 mapper를 통해 NodeConfigPayload로 전달한다.
|
||||
- [x] Node가 adapter registry를 구성하고 `runtime.Adapter` 계약으로 실행한다.
|
||||
- [x] CLI adapter가 logical session과 cancel/terminate-session을 지원한다.
|
||||
- [x] Edge console이 `/nodes`, `/node`, `/session`, `/background`, `/terminate-session`, `/status`, `/capabilities`, `/sessions`, `/transport`를 통해 기본 진단을 제공한다.
|
||||
- [x] Field smoke에서 메시지 2회 왕복, start/delta/complete event, command 응답을 확인할 수 있다.
|
||||
- [x] [node-registry] NodeStore와 Registry가 사전 등록 node와 연결 node를 구분해 관리한다.
|
||||
- [x] [node-config] Edge가 node 설정을 mapper를 통해 NodeConfigPayload로 전달한다.
|
||||
- [x] [adapter-registry] Node가 adapter registry를 구성하고 `runtime.Adapter` 계약으로 실행한다.
|
||||
- [x] [cli-session] CLI adapter가 logical session과 cancel/terminate-session을 지원한다.
|
||||
- [x] [edge-console] Edge console이 `/nodes`, `/node`, `/session`, `/background`, `/terminate-session`, `/status`, `/capabilities`, `/sessions`, `/transport`를 통해 기본 진단을 제공한다.
|
||||
- [x] [field-smoke] Field smoke에서 메시지 2회 왕복, start/delta/complete event, command 응답을 확인할 수 있다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -36,10 +36,10 @@ NomadCode는 이 계층의 소비자 중 하나이며, 이 Milestone은 특정 A
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] RAG, context, web search, MCP, tool policy, validation은 IOP 책임으로 정의한다.
|
||||
- [ ] 외부 client는 NomadCode 전용 metadata가 아니라 OpenAI-compatible, A2A, IOP native protocol 경계 중 맞는 표면을 통해 IOP를 소비한다.
|
||||
- [ ] 특정 Agent Shell이나 Project Workspace UI 요구가 IOP 최적화 책임을 오염시키지 않도록 범위를 분리한다.
|
||||
- [ ] 검증과 fallback은 모델 선택/라우팅 결과를 보완하는 IOP 내부 정책으로 정의한다.
|
||||
- [ ] [knowledge-policy] RAG, context, web search, MCP, tool policy, validation은 IOP 책임으로 정의한다.
|
||||
- [ ] [client-surface] 외부 client는 NomadCode 전용 metadata가 아니라 OpenAI-compatible, A2A, IOP native protocol 경계 중 맞는 표면을 통해 IOP를 소비한다.
|
||||
- [ ] [shell-boundary] 특정 Agent Shell이나 Project Workspace UI 요구가 IOP 최적화 책임을 오염시키지 않도록 범위를 분리한다.
|
||||
- [ ] [validation-policy] 검증과 fallback은 모델 선택/라우팅 결과를 보완하는 IOP 내부 정책으로 정의한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -38,13 +38,13 @@ RAG, MCP, web search, output validation 같은 최적화 계층으로 넘어가
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] 모델 선택과 local/cloud routing은 IOP 책임으로 정의한다.
|
||||
- [ ] 로컬 모델 우선 활용과 cloud fallback 기준을 함께 정의한다.
|
||||
- [ ] OpenAI-compatible API는 chat completions와 Responses API를 포함하는 외부 모델 기반 호출 표면으로 정의한다.
|
||||
- [ ] A2A API는 외부 agent의 작업 위임 표면으로 제한한다.
|
||||
- [ ] NomadCode의 A2A 도입 시점은 이 Milestone에서 강제하지 않고 별도 판단으로 남긴다.
|
||||
- [ ] IOP native protocol은 proto-socket 기반 내부/운영 호출 기준으로 둔다.
|
||||
- [ ] RAG, MCP, web search, output validation은 기본 serving/load routing 이후 단계로 명시한다.
|
||||
- [ ] [model-routing] 모델 선택과 local/cloud routing은 IOP 책임으로 정의한다.
|
||||
- [ ] [cloud-fallback] 로컬 모델 우선 활용과 cloud fallback 기준을 함께 정의한다.
|
||||
- [ ] [responses-api] OpenAI-compatible API는 chat completions와 Responses API를 포함하는 외부 모델 기반 호출 표면으로 정의한다.
|
||||
- [ ] [a2a-boundary] A2A API는 외부 agent의 작업 위임 표면으로 제한한다.
|
||||
- [ ] [nomadcode-a2a] NomadCode의 A2A 도입 시점은 이 Milestone에서 강제하지 않고 별도 판단으로 남긴다.
|
||||
- [ ] [native-protocol] IOP native protocol은 proto-socket 기반 내부/운영 호출 기준으로 둔다.
|
||||
- [ ] [optimization-later] RAG, MCP, web search, output validation은 기본 serving/load routing 이후 단계로 명시한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -37,10 +37,10 @@ Control Plane과 Portal 운영
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] Multi-edge 운영 명령과 이벤트 집계는 IOP native protocol을 기준으로 설계한다.
|
||||
- [ ] OpenAI-compatible 표면은 특정 Edge/adapter로 라우팅되는 inference 호환 경로로 제한한다.
|
||||
- [ ] A2A 표면은 특정 Edge/adapter로 위임되는 agent task 경로로 제한한다.
|
||||
- [ ] Edge는 자신의 로컬 런타임 상태와 registry 소유권을 유지한다.
|
||||
- [ ] [native-fleet] Multi-edge 운영 명령과 이벤트 집계는 IOP native protocol을 기준으로 설계한다.
|
||||
- [ ] [openai-routing] OpenAI-compatible 표면은 특정 Edge/adapter로 라우팅되는 inference 호환 경로로 제한한다.
|
||||
- [ ] [a2a-routing] A2A 표면은 특정 Edge/adapter로 위임되는 agent task 경로로 제한한다.
|
||||
- [ ] [edge-ownership] Edge는 자신의 로컬 런타임 상태와 registry 소유권을 유지한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -37,10 +37,10 @@ Control Plane과 Portal 운영
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] Edge는 로컬 런타임 상태와 실행 이력의 원본을 유지한다.
|
||||
- [ ] Control Plane은 Edge 데이터를 조회/집계하되 Edge 내부 상태 소유권을 대체하지 않는다.
|
||||
- [ ] 원격 터미널 브리지는 target allowlist, credential 관리, command/session audit를 필수로 요구한다.
|
||||
- [ ] policy/audit 상세 schema는 구현 단계에서 명확한 evidence와 함께 확정한다.
|
||||
- [ ] [edge-source] Edge는 로컬 런타임 상태와 실행 이력의 원본을 유지한다.
|
||||
- [ ] [cp-aggregation] Control Plane은 Edge 데이터를 조회/집계하되 Edge 내부 상태 소유권을 대체하지 않는다.
|
||||
- [ ] [terminal-audit] 원격 터미널 브리지는 target allowlist, credential 관리, command/session audit를 필수로 요구한다.
|
||||
- [ ] [schema-evidence] policy/audit 상세 schema는 구현 단계에서 명확한 evidence와 함께 확정한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
|
|||
|
|
@ -36,10 +36,10 @@ Automation Runtime과 Bridge 확장
|
|||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] 원격 터미널 브리지는 완전 agentless 제어가 아니라 target device에 IOP agent를 설치하지 않는 운영 경로로 정의한다.
|
||||
- [ ] Control Plane/Portal/운영 CLI는 Edge에 terminal session을 요청하고, Node에 직접 붙지 않는다.
|
||||
- [ ] Node terminal transport는 adapter/profile 또는 별도 adapter 경계에서 실행된다.
|
||||
- [ ] stdin/stdout/stderr, resize, signal, close lifecycle을 IOP native protocol에서 표현하는 방향을 검증한다.
|
||||
- [ ] [agentless-boundary] 원격 터미널 브리지는 완전 agentless 제어가 아니라 target device에 IOP agent를 설치하지 않는 운영 경로로 정의한다.
|
||||
- [ ] [edge-broker] Control Plane/Portal/운영 CLI는 Edge에 terminal session을 요청하고, Node에 직접 붙지 않는다.
|
||||
- [ ] [node-transport] Node terminal transport는 adapter/profile 또는 별도 adapter 경계에서 실행된다.
|
||||
- [ ] [terminal-events] stdin/stdout/stderr, resize, signal, close lifecycle을 IOP native protocol에서 표현하는 방향을 검증한다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
|
|
@ -60,3 +60,4 @@ Automation Runtime과 Bridge 확장
|
|||
- 관련 앱: `apps/edge`, `apps/node`
|
||||
- 관련 문서: `docs/architecture.md`, `docs/deploy-dev.md`
|
||||
- 선행 Milestone: Edge-Node 실행 스켈레톤, CLI Automation Runtime 안정화
|
||||
- 병렬 후보: Agent Bootstrap과 OTO 등록. 설치 가능한 대상은 bootstrap/enrollment 경로로, 설치가 어렵거나 일회성 유지보수 대상은 remote terminal bridge 경로로 구분한다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,65 @@
|
|||
# Specialized Agent proto-socket 연결 기반
|
||||
|
||||
## 목표
|
||||
|
||||
generic `iop-node`와 OTO 같은 specialized domain agent가 Edge와 proto-socket으로 직접 통신할 때 공유할 transport 기반과 분리할 protocol 경계를 정리한다.
|
||||
현재 Edge-Node 등록, config 전달, run/event, command, heartbeat 흐름을 기준으로 specialized agent가 bootstrap보다 먼저 갖춰야 할 최소 연결 계약을 정의한다.
|
||||
|
||||
## 단계
|
||||
|
||||
Automation Runtime과 Bridge 확장
|
||||
|
||||
## 상태
|
||||
|
||||
계획
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 이유: specialized domain agent 연결 기반을 설계하는 게이트 문서이며, 기존 Edge-Node 메시지를 재사용할지 별도 specialized agent 메시지를 둘지 아직 확정되지 않았다.
|
||||
- 해제 조건:
|
||||
- [ ] Edge-Node `RegisterRequest/RegisterResponse`, `NodeConfigPayload`, `RunRequest/RunEvent`, `NodeCommandRequest/Response`, heartbeat 흐름 중 specialized agent가 공유할 범위가 문서화됨
|
||||
- [ ] OTO 같은 specialized domain agent를 Edge registry에서 generic Node와 어떻게 구분할지 결정 후보가 정리됨
|
||||
- [ ] 사용자가 이 Milestone의 구현 구체화와 잠금 해제를 명시적으로 승인함
|
||||
- 잠금 중 금지:
|
||||
- 코드 구현 또는 `agent-task` 구현 계획 생성
|
||||
- proto schema, registry schema, API/package/file 구조를 추측해 확정
|
||||
- OTO 구현을 `apps/node` adapter로 흡수하는 방향 선확정
|
||||
|
||||
## 범위
|
||||
|
||||
- 기존 Edge-Node proto-socket 흐름을 specialized agent 관점에서 분해한다.
|
||||
- generic Node와 specialized domain agent가 공유할 transport, heartbeat, request-response 기반을 정의한다.
|
||||
- OTO agent의 직접 outbound 연결을 받아들이기 위해 Edge가 구분해야 할 agent identity, capability, lifecycle 후보를 정리한다.
|
||||
- OTO 쪽 Dart `proto_socket` 소비와 iop Go Edge transport 사이의 교차 검증 기준을 잡는다.
|
||||
|
||||
## 필수 기능
|
||||
|
||||
- [ ] [node-flow-map] 기존 Edge-Node 등록, config, run/event, command, heartbeat 흐름이 specialized agent 관점에서 매핑되어 있다.
|
||||
- [ ] [agent-kind] Edge registry에서 generic Node와 specialized domain agent를 구분하는 기준 후보가 정리되어 있다.
|
||||
- [ ] [message-boundary] 기존 Node 메시지 재사용과 specialized agent 전용 메시지 분리 기준이 문서화되어 있다.
|
||||
- [ ] [oto-interop] OTO Dart `proto_socket` consumer와 iop Go Edge transport 사이의 최소 호환 검증 기준이 정의되어 있다.
|
||||
- [ ] [bootstrap-precondition] Agent Bootstrap과 OTO 등록이 의존할 transport/handshake 선행 조건이 명확하다.
|
||||
|
||||
## 완료 기준
|
||||
|
||||
- [ ] Agent Bootstrap과 OTO 등록이 통신 기반을 추측하지 않고 후속 계약을 작성할 수 있다.
|
||||
- [ ] OTO의 proto-socket 통신 기반 Milestone과 같은 책임 경계를 참조한다.
|
||||
- [ ] generic Node, specialized domain agent, remote terminal bridge 경로가 제품/transport 수준에서 구분된다.
|
||||
- [ ] proto schema나 registry schema를 구현하기 전에 결정해야 할 후보와 확인 필요 항목이 정리되어 있다.
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- proto schema와 생성 코드를 변경하지 않는다.
|
||||
- Edge registry/API/DB schema를 구현하지 않는다.
|
||||
- OTO agent를 `apps/node` adapter나 하위 프로세스로 흡수하지 않는다.
|
||||
- bootstrap command 발급, credential 발급, 장기 credential 재발급을 구현하지 않는다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 iop 경로: `proto/iop/runtime.proto`, `apps/edge/internal/transport/server.go`, `apps/node/internal/transport/client.go`, `apps/node/internal/transport/session.go`, `apps/edge/internal/node/registry.go`
|
||||
- 관련 OTO Milestone: `../oto/agent-ops/roadmap/milestones/oto-iop-proto-socket-foundation.md`
|
||||
- 관련 proto-socket 프로젝트: `../proto-socket/`
|
||||
- 선행 Milestone: Edge-Node 실행 스켈레톤, CLI Automation Runtime 안정화
|
||||
- 후속 Milestone: Agent Bootstrap과 OTO 등록
|
||||
- 확인 필요: 기존 `RegisterRequest/RegisterResponse`를 specialized agent에 확장 적용할지, agent kind를 가진 새 handshake를 둘지 결정해야 한다.
|
||||
Loading…
Reference in a new issue