diff --git a/agent-ops/roadmap/ROADMAP.md b/agent-ops/roadmap/ROADMAP.md index 8df89d2..8f17b98 100644 --- a/agent-ops/roadmap/ROADMAP.md +++ b/agent-ops/roadmap/ROADMAP.md @@ -5,7 +5,7 @@ IOP(Inference Operations Platform)는 Control Plane - Edge - Node 계층 구조를 기반으로 모델 서빙과 CLI Agent/Automation 실행을 함께 운영하는 실행 오케스트레이션 플랫폼을 만든다. 내부 실행 모델은 `adapter + target`을 기준으로 하며, Edge가 로컬 실행 그룹의 상태와 라우팅을 소유하고 Control Plane은 Edge를 통해 시스템을 관찰하고 제어한다. -IOP는 NomadCode에 종속된 Agent Shell이 아니라, NomadCode와 외부 agent, 운영 CLI, Portal, 자동화 도구가 함께 소비할 수 있는 범용 추론/자동화 운영 엔진이다. +IOP는 NomadCode에 종속된 Agent Shell이 아니라, NomadCode와 외부 agent, 운영 CLI, client, 자동화 도구가 함께 소비할 수 있는 범용 추론/자동화 운영 엔진이다. 로드맵 전반에서 OpenAI-compatible API는 외부 클라이언트의 모델 기반 호출 표면으로, A2A API는 외부 agent의 agent-to-agent 작업 위임 표면으로, IOP native protocol은 운영 제어, logical session, background run, command, lifecycle event, remote terminal session 같은 IOP 고유 기능의 기준으로 둔다. OpenAI-compatible API는 현재 chat completions baseline을 넘어 Responses API 호환 표면까지 지원해야 한다. IOP native protocol은 proto-socket을 기본으로 하며, HTTP는 OpenAI-compatible/A2A/health/bootstrap처럼 필요한 경계에서만 사용한다. @@ -29,9 +29,9 @@ RAG, context 구성/압축, web search, MCP 정책, tool policy, output validati - 경로: `agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md` - 요약: Runtime과 Automation 실행 흐름을 공통화하고, agent 설치형/비설치형 대상 제어 경로를 분리해 확장하는 단계다. -- [진행중] Control Plane과 Portal 운영 +- [진행중] Control Plane과 Client 운영 - 경로: `agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md` - - 요약: 여러 Edge를 관찰하고 운영하는 중앙 제어면과 Flutter Portal 운영면을 구축하는 단계다. + - 요약: 여러 Edge를 관찰하고 운영하는 중앙 제어면과 Flutter client 운영면을 구축하는 단계다. - [계획] 서빙 라우팅과 최적화 기반 - 경로: `agent-ops/roadmap/phase/serving-routing-optimization/PHASE.md` diff --git a/agent-ops/roadmap/current.md b/agent-ops/roadmap/current.md index fd068d9..bfdd807 100644 --- a/agent-ops/roadmap/current.md +++ b/agent-ops/roadmap/current.md @@ -5,12 +5,12 @@ - [진행중] Automation Runtime과 Bridge 확장 - 경로: `agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md` -- [진행중] Control Plane과 Portal 운영 +- [진행중] Control Plane과 Client 운영 - 경로: `agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md` ## 활성 Milestone -- [진행중] Specialized Agent proto-socket 연결 기반 +- [검토중] Specialized Agent proto-socket 연결 기반 - Phase: `agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md` - 경로: `agent-ops/roadmap/phase/automation-runtime-bridge/milestones/specialized-agent-proto-socket-foundation.md` @@ -18,7 +18,11 @@ - Phase: `agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md` - 경로: `agent-ops/roadmap/phase/automation-runtime-bridge/milestones/agent-bootstrap-oto-enrollment.md` -- [진행중] Control Plane과 Portal +- [계획] Client Integration Clone Adoption + - Phase: `agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md` + - 경로: `agent-ops/roadmap/phase/control-plane-portal-ops/milestones/client-integration-clone-adoption.md` + +- [진행중] Control Plane과 Client - Phase: `agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md` - 경로: `agent-ops/roadmap/phase/control-plane-portal-ops/milestones/control-plane-portal.md` diff --git a/agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md b/agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md index b12ab9b..48965a5 100644 --- a/agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md +++ b/agent-ops/roadmap/phase/automation-runtime-bridge/PHASE.md @@ -18,9 +18,9 @@ CLI 실행, specialized agent 등록, bootstrap/enrollment, 원격 터미널 브 - 경로: `agent-ops/roadmap/archive/phase/automation-runtime-bridge/milestones/cli-automation-runtime-stabilization.md` - 요약: one-shot, persistent terminal, opencode SSE, codex exec 계열 CLI 실행 모드와 운영 command 응답을 같은 adapter execution 모델 안에서 안정화했다. -- [진행중] Specialized Agent proto-socket 연결 기반 +- [검토중] Specialized Agent proto-socket 연결 기반 - 경로: `agent-ops/roadmap/phase/automation-runtime-bridge/milestones/specialized-agent-proto-socket-foundation.md` - - 요약: OTO의 node-compatible proto-socket registration smoke를 바탕으로 Edge의 specialized agent kind, registry/config, message boundary, reconnect 정책을 정리한다. + - 요약: OTO의 node-compatible proto-socket registration smoke를 바탕으로 Edge의 specialized agent kind, registry/config, message boundary, reconnect 정책과 runtime 경로 구분을 완료 후보로 정리했다. - [진행중] Agent Bootstrap과 OTO 등록 - 경로: `agent-ops/roadmap/phase/automation-runtime-bridge/milestones/agent-bootstrap-oto-enrollment.md` diff --git a/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/agent-bootstrap-oto-enrollment.md b/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/agent-bootstrap-oto-enrollment.md index 36eb078..63873b8 100644 --- a/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/agent-bootstrap-oto-enrollment.md +++ b/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/agent-bootstrap-oto-enrollment.md @@ -82,7 +82,8 @@ OTO는 build/deploy domain agent의 대표 후보로 둔다. ## 작업 컨텍스트 -- 관련 경로: `apps/edge`, `docs/deploy-dev.md`, `docs/architecture.md`, `../oto/agent-ops/roadmap/milestones/oto-agent-registration.md`, `../oto/agent-ops/roadmap/milestones/agent-message-protocol.md`, `../oto/assets/script/shell/oto_agent_bootstrap.sh` +- 관련 경로: `apps/edge`, `docs/deploy-dev.md`, `docs/architecture.md`, `../oto/agent-ops/roadmap/phase/edge-direct-oto-agent/milestones/oto-agent-registration.md`, `../oto/agent-ops/roadmap/phase/message-based-build-agent/milestones/agent-message-protocol.md`, `../oto/assets/script/shell/oto_agent_bootstrap.sh` +- 전환 상태: `Specialized Agent proto-socket 연결 기반`이 `[검토중]`으로 전환되어 이 마일스톤이 다음 구현 후보이며, 구현 시작 전 `enrollment_token` 범위와 HTTP local/insecure bootstrap 정책 결정을 먼저 해소한다. - 표준선(선택): OTO agent는 `iop-node` 하위 프로세스가 아니라 Edge에 직접 outbound 연결하는 specialized domain agent로 둔다. - 표준선(선택): Edge는 `oto-agent` record를 만들고, agent id/alias/enrollment token/release base URL/bootstrap script URL을 포함한 one-line command를 발급한다. - 표준선(선택): OTO Linux MVP command 형식은 `curl -fsSL "${OTO_BOOTSTRAP_URL}" | bash -s -- --edge-url "${EDGE_URL}" --agent-id "${AGENT_ID}" --enrollment-token "${ENROLLMENT_TOKEN}" --release-base-url "${OTO_RELEASE_BASE_URL}" --agent-alias "${AGENT_ALIAS}"`를 기준으로 한다. diff --git a/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/specialized-agent-proto-socket-foundation.md b/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/specialized-agent-proto-socket-foundation.md index 3a8b2d2..e23c738 100644 --- a/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/specialized-agent-proto-socket-foundation.md +++ b/agent-ops/roadmap/phase/automation-runtime-bridge/milestones/specialized-agent-proto-socket-foundation.md @@ -12,7 +12,7 @@ OTO 쪽 Dart `proto_socket` 연결과 iop Edge 등록 smoke가 이미 시작된 ## 상태 -[진행중] +[검토중] ## 구현 잠금 @@ -50,21 +50,21 @@ OTO 쪽 Dart `proto_socket` 연결과 iop Edge 등록 smoke가 이미 시작된 ## 완료 기준 - [x] Agent Bootstrap과 OTO 등록이 통신 기반을 추측하지 않고 후속 계약을 작성할 수 있다. -- [ ] OTO의 proto-socket 통신 기반 Milestone과 같은 책임 경계를 참조한다. -- [ ] generic Node, specialized domain agent, remote terminal bridge 경로가 제품/transport 수준에서 구분된다. +- [x] OTO의 proto-socket 통신 기반 Milestone과 같은 책임 경계를 참조한다. +- [x] generic Node, specialized domain agent, remote terminal bridge 경로가 제품/transport 수준에서 구분된다. - [x] OTO Dart client의 iop Edge registration smoke를 기준으로, 후속 run/command smoke를 어디까지 요구할지 결정되어 있다. - [x] specialized agent를 처음에는 node-compatible handshake로 받아들이되, proto field 추가가 필요한 시점과 조건이 정리되어 있다. - [x] proto schema나 registry schema를 구현하기 전에 결정해야 할 후보와 확인 필요 항목이 정리되어 있다. ## 완료 리뷰 -- 상태: 없음 -- 요청일: 없음 -- 완료 근거: 모든 필수 Task는 충족됐지만 완료 기준 일부가 아직 남아 있다. +- 상태: 요청됨 +- 요청일: 2026-05-25 +- 완료 근거: 필수 Epic/Task와 완료 기준이 모두 충족되어 완료 후보로 정리했다. 기존 Edge-Node proto-socket 재사용, Edge-side agent kind 판별, config/message boundary, reconnect 정책, bootstrap 선행 조건이 계약 결정에 반영되어 있다. OTO 직접 연결 Phase와 remote terminal bridge Phase 경계를 참조해 generic Node, specialized agent, agentless terminal bridge 경로를 분리했다. - 리뷰 필요: - [ ] 사용자가 완료 결과를 확인했다 - [ ] archive 이동을 승인했다 -- 리뷰 코멘트: 없음 +- 리뷰 코멘트: 사용자 승인 전까지 archive 이동은 하지 않는다. ## 범위 제외 @@ -76,6 +76,20 @@ OTO 쪽 Dart `proto_socket` 연결과 iop Edge 등록 smoke가 이미 시작된 ## 계약 결정 +### Runtime Path Boundary + +- generic Node는 기존 `iop-node`가 Edge-Node proto-socket transport로 연결되고, Node runtime/adapter execution을 소유하는 경로다. +- specialized domain agent는 OTO처럼 Edge에 직접 outbound 연결하는 node-compatible peer이며, 초기 handshake와 heartbeat는 재사용하되 build/deploy domain payload는 필요 시 전용 typed payload로 분리한다. +- remote terminal bridge는 agent 설치가 어렵거나 일회성 유지보수 대상에 쓰는 별도 운영 경로이며, Edge가 session broker가 되고 Node terminal transport가 대상 shell/SSH/WinRM/serial 실행을 맡는다. +- 세 경로는 OpenAI-compatible/A2A 입력 표면에 terminal 제어를 억지로 싣지 않고, 제품 UX와 transport 책임을 분리한다. + +### OTO Responsibility Boundary + +- OTO의 직접 연결 기준은 `../oto/agent-ops/roadmap/phase/edge-direct-oto-agent/PHASE.md`와 완료된 `../oto/agent-ops/roadmap/archive/phase/edge-direct-oto-agent/milestones/oto-iop-proto-socket-foundation.md`를 참조한다. +- iop는 Edge-side registration, token/agent kind 판별, config 전달, reconnect policy, envelope 재사용 기준을 소유한다. +- OTO는 Dart `proto_socket` client, Linux agent 설치 산출물, OTO build/deploy domain config와 event 의미를 소유한다. +- registration 이후 run/command는 이번 마일스톤에서 envelope compatibility 확인 기준까지만 요구하고, OTO build/deploy payload 상세는 후속 OTO agent message protocol로 넘긴다. + ### Agent Kind / Registry Entry - `RegisterRequest`에는 당장 kind field를 추가하지 않는다. @@ -106,7 +120,7 @@ OTO 쪽 Dart `proto_socket` 연결과 iop Edge 등록 smoke가 이미 시작된 ## 작업 컨텍스트 -- 관련 경로: `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/agent-ops/roadmap/milestones/oto-agent-registration.md`, `../oto/test/oto_iop_connection_smoke_test.dart`, `../proto-socket/` +- 관련 경로: `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/agent-ops/roadmap/phase/edge-direct-oto-agent/PHASE.md`, `../oto/agent-ops/roadmap/phase/edge-direct-oto-agent/milestones/oto-agent-registration.md`, `../oto/agent-ops/roadmap/phase/message-based-build-agent/milestones/agent-message-protocol.md`, `../oto/test/oto_iop_connection_smoke_test.dart`, `../proto-socket/` - 표준선(선택): 기존 Edge-Node proto-socket transport와 `RegisterRequest/RegisterResponse`를 우선 재사용하고, agent kind는 Edge-side registration record에서 판별한다. - 선행 작업: Edge-Node 실행 스켈레톤, CLI Automation Runtime 안정화 - 후속 작업: Agent Bootstrap과 OTO 등록 diff --git a/agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md b/agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md index f185cac..3070b8c 100644 --- a/agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md +++ b/agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md @@ -1,4 +1,4 @@ -# Phase: Control Plane과 Portal 운영 +# Phase: Control Plane과 Client 운영 ## 상태 @@ -6,7 +6,7 @@ ## 목표 -여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 중앙 제어면과 Flutter Portal 운영면을 구축한다. +여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 중앙 제어면과 Flutter client 운영면을 구축한다. ## Milestone 흐름 @@ -17,9 +17,13 @@ - 경로: `agent-ops/roadmap/archive/phase/control-plane-portal-ops/milestones/flutter-first-portal-migration.md` - 요약: Next.js `apps/web` scaffold를 제거하고 `apps/portal` Flutter 앱, Flutter Web compose 배포 흐름, Portal-Control Plane proto-socket WS hello 기반을 세웠다. -- [진행중] Control Plane과 Portal +- [계획] Client Integration Clone Adoption + - 경로: `agent-ops/roadmap/phase/control-plane-portal-ops/milestones/client-integration-clone-adoption.md` + - 요약: NomadCode client 표준을 IOP client에 복제하기 위한 모듈명, bootstrap, proto-socket, Mattermost push host integration 기준을 정리한다. + +- [진행중] Control Plane과 Client - 경로: `agent-ops/roadmap/phase/control-plane-portal-ops/milestones/control-plane-portal.md` - - 요약: 여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 중앙 제어면과 Flutter Portal 운영면을 구축한다. + - 요약: 여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 중앙 제어면과 Flutter client 운영면을 구축한다. - [계획] 정책, 이력, 감사 - 경로: `agent-ops/roadmap/phase/control-plane-portal-ops/milestones/policy-history-audit.md` @@ -32,5 +36,6 @@ ## Phase 경계 - Control Plane은 Node를 직접 스케줄링하지 않고 Edge를 통해 관찰/제어한다. -- Portal은 IOP 자체 운영 UI/UX이며 NomadCode 전용 shell로 만들지 않는다. +- Flutter client는 IOP 자체 운영 UI/UX이며 NomadCode 전용 shell로 만들지 않는다. - Multi-Edge 운영은 Edge의 로컬 상태 소유권을 침범하지 않는 범위에서 확장한다. +- `../nomadcode`에서 정리한 client 표준을 복제할 때는 제품 feature 전체가 아니라 client skeleton, integration boundary, bootstrap convention, 문서화된 handoff 기준만 가져온다. diff --git a/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/client-integration-clone-adoption.md b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/client-integration-clone-adoption.md new file mode 100644 index 0000000..30b648d --- /dev/null +++ b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/client-integration-clone-adoption.md @@ -0,0 +1,93 @@ +# Milestone: Client Integration Clone Adoption + +## 위치 + +- Roadmap: `agent-ops/roadmap/ROADMAP.md` +- Phase: `agent-ops/roadmap/phase/control-plane-portal-ops/PHASE.md` + +## 목표 + +NomadCode의 `Client Integration Standardization` 결과를 IOP Flutter client에 복제 가능한 형태로 반영한다. `client` 모듈명, Web + Android 우선 Dart bootstrap, proto-socket, Mattermost push host integration, iOS 후속 확장 경계를 IOP 운영면에 맞게 정리한다. + +## 상태 + +[계획] + +## 구현 잠금 + +- 상태: 잠금 +- 결정 필요: 아래 체크리스트 + - [ ] NomadCode client 표준화 산출물을 받은 뒤 IOP client에 복제할 파일/구조/설정 범위를 확정한다. + - [ ] 기존 `apps/portal` 경로를 `apps/client`로 전환할지, 호환 경로를 둘지 결정한다. + - [ ] IOP client에서 Mattermost push routing을 내부 화면, 외부 링크, 운영 이벤트 중 어디로 연결할지 결정한다. + +## 범위 + +- Flutter host 모듈을 `client` 기준으로 정리 +- Web + Android 우선 bootstrap과 platform guard 반영 +- proto-socket Dart client 설정, endpoint 주입, connection lifecycle 정리 +- Mattermost push plugin host integration 반영 +- Firebase host 설정과 token/auth/signing key 전달 경계 정리 +- iOS는 동일 Dart API 위의 후속 native 확장 대상으로 문서화 +- NomadCode에서 복제할 skeleton과 IOP에서 치환할 product-specific 항목 문서화 + +## 필수 기능 + +### Epic: [client-clone] Client standard clone + +NomadCode client 표준을 IOP client에 맞게 복제한다. + +- [ ] [module-name] Flutter host 경로와 모듈명을 `client` 기준으로 정리한다. +- [ ] [bootstrap] Web + Android 우선 bootstrap과 platform-specific initialization guard를 반영한다. +- [ ] [folder-layout] `src/app`, `src/integrations`, `src/features` 기준의 client skeleton을 정리한다. + +### Epic: [integration-clone] Integration clone boundary + +공통 integration 경계를 IOP 운영면에 맞춰 연결한다. + +- [ ] [proto-socket] proto-socket connection lifecycle과 endpoint configuration을 client integration으로 정리한다. +- [ ] [mattermost-push] Mattermost push는 plugin runtime을 사용하고 host는 Firebase config, auth/token/signing key, routing callback만 소유한다. +- [ ] [platform-targets] Web과 Android를 1차 target으로 검증하고 iOS 후속 확장 경계를 문서화한다. + +### Epic: [handoff] Clone handoff + +NomadCode 표준과 IOP 차이를 추적 가능하게 남긴다. + +- [ ] [clone-checklist] NomadCode에서 가져올 항목과 IOP에서 치환할 항목을 checklist로 남긴다. +- [ ] [naming] IOP 제품 표면에서는 Portal 명칭을 강조하지 않고 client/product surface 기준으로 정리한다. +- [ ] [related-locks] Flutter client 진행 milestone은 이 milestone의 표준 적용 범위가 확정되기 전까지 잠금 상태로 둔다. + +## 완료 기준 + +- [ ] IOP Flutter host가 `client` 기준 모듈/문서 표준을 따른다. +- [ ] Web build와 Android integration이 같은 Dart bootstrap 기준에서 설명되고 검증된다. +- [ ] proto-socket과 Mattermost push integration 책임 경계가 host/plugin/control-plane 사이에서 충돌 없이 설명된다. +- [ ] iOS가 Android-only 예외가 아니라 동일 Dart API 위의 후속 확장 대상으로 문서화된다. +- [ ] 기존 Control Plane client milestone과 충돌하는 범위가 잠금 또는 후속 작업으로 정리되어 있다. + +## 완료 리뷰 + +- 상태: 없음 +- 요청일: 없음 +- 완료 근거: 없음 +- 리뷰 필요: + - [ ] 사용자가 완료 결과를 확인했다 + - [ ] archive 이동을 승인했다 +- 리뷰 코멘트: 없음 + +## 범위 제외 + +- NomadCode 제품 feature 전체 복제 +- IOP Edge/Node runtime 내부 정책 변경 +- iOS native push full implementation +- Mattermost push plugin runtime 대규모 재작성 +- Control Plane-Edge wire protocol 세부 확정 + +## 작업 컨텍스트 + +- 관련 경로: `apps/portal/`, `apps/control-plane/`, `docs/`, `bin/web.sh`, `../nomadcode/apps/client`, `../mattermost-push-plugin/` +- 표준선(선택): IOP 제품 표면은 client로 부르고, 기존 Portal 명칭은 legacy 경로 또는 wire endpoint 명칭에 남은 경우에만 제한적으로 다룬다. +- 표준선(선택): NomadCode에서 가져올 것은 client skeleton, integration boundary, bootstrap convention, handoff 문서이며 제품 feature는 복제하지 않는다. +- 선행 작업: NomadCode `Client Integration Standardization` +- 후속 작업: Control Plane과 Client, Multi-Edge 운영 +- 확인 필요: 구현 잠금의 결정 필요 항목 참고. diff --git a/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/control-plane-portal.md b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/control-plane-portal.md index 3f6d8a0..8e5cd9d 100644 --- a/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/control-plane-portal.md +++ b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/control-plane-portal.md @@ -1,4 +1,4 @@ -# Milestone: Control Plane과 Portal +# Milestone: Control Plane과 Client ## 위치 @@ -7,8 +7,8 @@ ## 목표 -여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 Control Plane과 Flutter Portal 운영면을 구축한다. -Portal은 NomadCode 전용 화면이 아니라 IOP가 독립적으로 운영되기 위한 범용 운영/UX 계층으로 둔다. +여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 Control Plane과 Flutter client 운영면을 구축한다. +Client는 NomadCode 전용 화면이 아니라 IOP가 독립적으로 운영되기 위한 범용 운영/UX 계층으로 둔다. ## 상태 @@ -18,15 +18,16 @@ Portal은 NomadCode 전용 화면이 아니라 IOP가 독립적으로 운영되 - 상태: 잠금 - 결정 필요: 아래 체크리스트 - - [ ] Portal의 첫 운영 화면 범위를 Edge/Node 상태 조회 중심으로 둘지, 명령/설정 변경까지 포함할지 결정한다. + - [ ] Client의 첫 운영 화면 범위를 Edge/Node 상태 조회 중심으로 둘지, 명령/설정 변경까지 포함할지 결정한다. - [ ] Control Plane-Edge 연결에서 우선 구현할 IOP Wire Protocol 범위를 결정한다. - - [ ] Portal이 IOP 범용 운영 UI로 남기 위해 제외할 NomadCode 전용 UX 경계를 결정한다. + - [ ] IOP client가 범용 운영 UI로 남기 위해 제외할 NomadCode 전용 UX 경계를 결정한다. + - [ ] Client Integration Clone Adoption 완료 전 Flutter client 화면 구현을 어디까지 진행할지 결정한다. ## 범위 - Control Plane Go server의 Edge connection 관리 -- Portal-Control Plane, Control Plane-Edge IOP Wire Protocol 확장 -- Flutter Portal의 Runtime/Automation/Serving 운영 화면 기초 +- Client-Control Plane, Control Plane-Edge IOP Wire Protocol 확장 +- Flutter client의 Runtime/Automation/Serving 운영 화면 기초 - Edge 상태 조회, 설정 변경, 명령 전달, 이벤트 수신 - Edge agent 생성과 bootstrap command 발급 상태 조회/관리 - remote terminal bridge session 생성/조회/권한 확인 표면 @@ -37,22 +38,22 @@ Portal은 NomadCode 전용 화면이 아니라 IOP가 독립적으로 운영되 ### Epic: [edge-ops-boundary] Edge Operations Boundary - [ ] [edge-mediated] Control Plane은 Node를 직접 연결하거나 직접 스케줄링하지 않는다. -- [ ] [portal-via-cp] Portal은 Control Plane을 통해 Edge 운영 상태를 조회한다. +- [ ] [portal-via-cp] Client는 Control Plane을 통해 Edge 운영 상태를 조회한다. -### Epic: [portal-wire-surface] Portal Wire Surface +### Epic: [portal-wire-surface] Client Wire Surface -- [x] [portal-boundary] Portal은 IOP 자체 운영 UI/UX이며 NomadCode에 맞춘 전용 shell로 만들지 않는다. +- [x] [portal-boundary] Flutter client는 IOP 자체 운영 UI/UX이며 NomadCode에 맞춘 전용 shell로 만들지 않는다. - [x] [server-bridge] 브라우저 직접 TCP가 어려운 구간은 Control Plane server-side bridge를 둔다. -- [x] [portal-wire-hello] Portal-Control Plane proto-socket WebSocket hello handshake scaffold가 구현되고 테스트되어 있다. +- [x] [portal-wire-hello] Client-Control Plane proto-socket WebSocket hello handshake scaffold가 구현되고 테스트되어 있다. - [x] [http-boundary] `net/http`는 health/readiness/bootstrap 같은 보조 endpoint 용도로 유지한다. ## 완료 기준 - [ ] Control Plane이 하나 이상의 Edge 연결 상태를 조회할 수 있다. -- [ ] Portal이 Edge/Node/agent 상태를 사용자에게 보여줄 수 있다. +- [ ] Client가 Edge/Node/agent 상태를 사용자에게 보여줄 수 있다. - [ ] Edge 명령 전달과 이벤트 수신 흐름이 IOP Wire Protocol 기준으로 문서화된다. -- [x] Control Plane과 Flutter Portal의 배포/검증 절차가 `docs/deploy-dev.md`와 일치한다. -- [x] Portal-Control Plane proto-socket WebSocket hello handshake가 Control Plane과 Portal 테스트에서 검증된다. +- [x] Control Plane과 Flutter client의 배포/검증 절차가 `docs/deploy-dev.md`와 일치한다. +- [x] Client-Control Plane proto-socket WebSocket hello handshake가 Control Plane과 client 테스트에서 검증된다. ## 완료 리뷰 @@ -76,7 +77,7 @@ Portal은 NomadCode 전용 화면이 아니라 IOP가 독립적으로 운영되 - 관련 경로: `apps/control-plane`, `apps/portal`, `apps/control-plane/README.md`, `apps/portal/README.md`, `docs/deploy-dev.md`, `docker-compose.yml`, `bin/web.sh` - 표준선(선택): Control Plane은 Node를 직접 스케줄링하지 않고 Edge를 통해 관찰/제어한다. -- 표준선(선택): Portal-Control Plane의 첫 wire surface는 `/portal` WebSocket의 hello handshake이며, Edge 운영 조회와 명령 전달은 후속 IOP Wire Protocol 확장에서 붙인다. -- 선행 작업: Flutter-first Portal 마이그레이션, Agent Bootstrap과 OTO 등록, 정책/이력/감사 일부 기준 +- 표준선(선택): Client-Control Plane의 첫 wire surface는 기존 `/portal` WebSocket hello handshake를 유지할 수 있으며, Edge 운영 조회와 명령 전달은 후속 IOP Wire Protocol 확장에서 붙인다. +- 선행 작업: Flutter-first Portal 마이그레이션, Client Integration Clone Adoption, Agent Bootstrap과 OTO 등록, 정책/이력/감사 일부 기준 - 후속 작업: Multi-Edge 운영 -- 확인 필요: Portal 첫 화면 범위, Control Plane-Edge wire 우선순위, NomadCode 전용 UX 제외 기준 +- 확인 필요: Client 첫 화면 범위, Control Plane-Edge wire 우선순위, NomadCode 전용 UX 제외 기준, client 표준 clone 반영 범위 diff --git a/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/multi-edge-operations.md b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/multi-edge-operations.md index 1ee9dcd..498fbf9 100644 --- a/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/multi-edge-operations.md +++ b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/multi-edge-operations.md @@ -66,6 +66,6 @@ Multi-edge scheduling과 fleet-wide state ownership은 Control Plane과 IOP nati - 관련 경로: `apps/control-plane`, `apps/portal`, `apps/edge`, `docs/architecture.md` - 표준선(선택): Edge는 로컬 런타임 상태와 registry 소유권을 유지하고, Control Plane은 관찰/집계 계층으로 시작한다. -- 선행 작업: Control Plane과 Portal, 정책/이력/감사 +- 선행 작업: Control Plane과 Client, 정책/이력/감사 - 후속 작업: 없음 - 확인 필요: observe-only 여부, fleet-wide 명령 범위, domain agent fleet 상태 포함 여부 diff --git a/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/policy-history-audit.md b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/policy-history-audit.md index 709cb53..7c606e3 100644 --- a/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/policy-history-audit.md +++ b/agent-ops/roadmap/phase/control-plane-portal-ops/milestones/policy-history-audit.md @@ -66,6 +66,6 @@ - 관련 경로: `apps/edge`, `apps/node`, `apps/control-plane`, `packages/auth`, `packages/jobs` - 표준선(선택): Edge는 로컬 실행 이력 원본을 유지하고, Control Plane은 필요한 범위에서 조회/집계한다. -- 선행 작업: 원격 터미널 브리지 POC, Agent Bootstrap과 OTO 등록, Control Plane과 Portal +- 선행 작업: 원격 터미널 브리지 POC, Agent Bootstrap과 OTO 등록, Control Plane과 Client - 후속 작업: Multi-Edge 운영 - 확인 필요: audit retention, policy enforcement 위치, credential/allowlist 소유 주체