update roadmap files

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`

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`
 

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`

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}"`를 기준으로 한다.

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 등록

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 기준만 가져온다.

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 운영
+- 확인 필요: 구현 잠금의 결정 필요 항목 참고.

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 반영 범위

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 상태 포함 여부

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 소유 주체