chore: update docs, roadmap and agent-ops (excluding agent-task)

README.md

@@ -221,13 +221,13 @@ NomadCode
 - 현재 실행 이력은 Node local SQLite store에서 검증 중이다. Edge 단위 이력 집계와 로컬 실행 그룹 상태 소유권은 로드맵에 따라 정리한다.
 - `mock` adapter와 dummy/TODO 구현은 개발 단계에서 정상적인 구성이다.
 - Ollama/vLLM 등 모델 runtime adapter는 단계적으로 확장한다.
-- Control Plane은 향후 여러 Edge 관리와 프론트 페이지 제공을 위해 추가된다.
+- Control Plane은 향후 여러 Edge 관리와 Portal 제공을 위해 추가된다.
 
 현재 앱 구성은 다음과 같다.
 
 | 경로 | 현재 의미 |
 |---|---|
-| `apps/web` | IOP 전체 Web Portal을 위한 Next.js 스캐폴드 |
+| `apps/web` | 삭제 예정인 legacy Next.js Web Portal 스캐폴드. 장기 UI는 Flutter-first Portal과 Flutter Web 산출물로 전환한다 |
 | `apps/node` | Edge에 연결되어 adapter execution을 수행하는 Node agent |
 | `apps/edge` | Node/domain agent registry, 설정 전달, bootstrap, routing, stream relay를 담당하는 Edge skeleton |
 | `apps/control-plane` | 여러 Edge를 연결하고 Portal과 통신할 Go 기반 운영 제어 서버 스캐폴드 |
@@ -236,7 +236,7 @@ NomadCode
 | `proto` | 앱 간 메시지 계약 원본과 생성물 |
 | `configs` | 현재 개발용 설정 예시 |
 
-`apps/web`은 IOP 전체 Web Portal이며, `apps/control-plane`은 Go 기반 운영 제어 서버다. 주요 통신은 edge-node에서 사용 중인 protobuf-socket을 IOP Wire Protocol 기준으로 Portal-Control Plane, Control Plane-Edge, Edge-Node 방향으로 확장한다. `net/http`는 health/readiness/bootstrap 같은 보조 endpoint 용도로 유지한다.
+Portal의 장기 UI 기준은 Flutter 앱이며, 필요한 웹 표면은 Flutter Web 산출물로 제공한다. `apps/control-plane`은 Go 기반 운영 제어 서버다. 주요 통신은 edge-node에서 사용 중인 proto-socket을 IOP Wire Protocol 기준으로 Portal-Control Plane, Control Plane-Edge, Edge-Node 방향으로 확장한다. Portal-Control Plane은 앱/브라우저 경계를 고려해 proto-socket WebSocket/WSS를 우선하고, `net/http`는 health/readiness/bootstrap 같은 보조 endpoint 용도로 유지한다.
 
 ## 로드맵
 
@@ -248,8 +248,8 @@ NomadCode
 ## Development Notes
 
 - 기존 구조를 우선하며, 세부 구현은 각 작업의 domain rule과 현재 코드 경계를 먼저 확인한 뒤 진행한다.
-- 내부 통신은 TCP/protobuf 기반 소켓 흐름을 우선한다.
-- gRPC 도입, WebSocket 기본 transport 전환, actor/FSM/plugin framework 도입은 현재 단계의 기본 방향이 아니다.
+- Edge-Node 내부 통신은 TCP/protobuf 기반 소켓 흐름을 우선한다.
+- Portal-Control Plane처럼 앱/브라우저 표면이 필요한 경계는 proto-socket WebSocket/WSS를 사용할 수 있다. Edge-Node 기본 transport를 WebSocket으로 전환하거나 gRPC, actor/FSM/plugin framework를 도입하는 것은 현재 단계의 기본 방향이 아니다.
 - OpenAI-compatible API 계층은 외부 모델 호출 호환을 위한 표면이며, 내부 실행 모델 전체를 대표하지 않는다.
 - OpenAI-compatible API는 현재 chat completions baseline을 가지며, Responses API 호환 표면까지 지원하는 방향으로 확장한다.
 - A2A API 계층은 agent 간 작업 위임과 상태 공유를 위한 표면이며, 단순 모델 호출 호환은 OpenAI-compatible API를 사용한다. NomadCode의 A2A 도입 시점은 아직 강제하지 않는다.

agent-ops/roadmap/ROADMAP.md

@@ -39,6 +39,7 @@ RAG, context 구성/압축, web search, MCP 정책, tool policy, output validati
 
 ### Control Plane과 Portal 운영
 
+- [Flutter-first Portal 마이그레이션](milestones/flutter-first-portal-migration.md) - 상태: 계획; 목표: IOP Portal의 장기 UI 기준을 Flutter 앱으로 정하고 Next.js scaffold를 제품 경로에서 제거하거나 격리한다.
 - [Control Plane과 Portal](milestones/control-plane-portal.md) - 상태: 계획; 목표: 여러 Edge를 연결하고 관찰하며 Edge 설정 변경, 명령 전달, 이벤트 수신을 담당하는 중앙 제어면과 Web Portal 운영면을 구축한다.
 - [정책, 이력, 감사](milestones/policy-history-audit.md) - 상태: 계획; 목표: 권한, 정책, 실행 이력, 감사 로그를 제품 운영에 필요한 수준으로 확장한다.
 - [Multi-Edge 운영](milestones/multi-edge-operations.md) - 상태: 계획; 목표: 여러 Edge group을 관찰하고 운영하는 fleet-level 기능을 구축한다.

agent-ops/roadmap/current.md

@@ -2,6 +2,7 @@
 
 ## 활성 Milestone
 
+- Flutter-first Portal 마이그레이션: agent-ops/roadmap/milestones/flutter-first-portal-migration.md
 - 원격 터미널 브리지 POC: agent-ops/roadmap/milestones/remote-terminal-bridge-poc.md
 - Specialized Agent proto-socket 연결 기반: agent-ops/roadmap/milestones/specialized-agent-proto-socket-foundation.md
 - Agent Bootstrap과 OTO 등록: agent-ops/roadmap/milestones/agent-bootstrap-oto-enrollment.md

agent-ops/roadmap/milestones/flutter-first-portal-migration.md

@@ -0,0 +1,66 @@
+# Flutter-first Portal 마이그레이션
+
+## 목표
+
+IOP Portal의 장기 UI source of truth를 Flutter 앱으로 정하고, TypeScript/Next.js Web Portal scaffold를 제품 경로에서 삭제한다.
+모바일/데스크톱 앱은 필수 표면으로 두며, 필요한 웹 표면은 Flutter Web과 proto-socket WebSocket/WSS 경로로 출력한다.
+
+## 단계
+
+Control Plane과 Portal 운영
+
+## 상태
+
+계획
+
+## 구현 잠금
+
+- 상태: 해제
+- 결정 필요: 없음
+
+## 범위
+
+- Flutter 앱을 IOP Portal의 기준 구현으로 선언
+- TypeScript/Next.js 기반 `apps/web` scaffold, npm 의존성, Next.js standalone 배포 흐름 제거
+- Flutter Web 산출물을 기존 Web Portal 배포 단위로 서빙하는 Docker 흐름 정리
+- Portal-Control Plane 통신을 proto-socket WebSocket/WSS 기준으로 정리
+- Flutter mobile/desktop과 Flutter Web이 같은 Portal client 경계를 공유하도록 정리
+- Flutter Web 브라우저 타깃을 위한 Dart proto-socket browser WebSocket transport 또는 조건부 transport 구현
+- `bin/web.sh`, `docker-compose.yml`, Portal 검증 entrypoint를 Flutter-first 기준으로 갱신
+
+## 필수 기능
+
+- [ ] [ui-source] Flutter 앱을 IOP Portal UI source of truth로 선언하고 Next.js를 기준 구현에서 제외한다.
+- [ ] [next-retire] `apps/web`의 TypeScript/Next.js scaffold와 npm 기반 제품 UI 경로를 삭제한다.
+- [ ] [proto-ws] Portal-Control Plane wire 경계는 proto-socket WebSocket/WSS를 기본으로 둔다.
+- [ ] [dart-web-transport] Flutter Web 브라우저 타깃에서 사용할 proto-socket Dart browser WebSocket transport 기준을 마련한다.
+- [ ] [entrypoints] `bin/web.sh`, compose web service, Portal 검증 명령이 Flutter-first 구조와 충돌하지 않게 정리한다.
+- [ ] [docker-flutter-web] 기존 Next.js Docker 배포를 Flutter Web build 산출물 서빙 흐름으로 교체한다.
+- [ ] [contract-gen] IOP protobuf 계약을 Flutter/Dart client가 소비할 생성물과 parser map 기준으로 정리한다.
+
+## 완료 기준
+
+- [ ] 로드맵과 Portal 관련 문서에서 Next.js가 장기 제품 UI 기준 구현으로 설명되지 않는다.
+- [ ] Flutter 앱이 모바일/데스크톱/웹 Portal의 기준 클라이언트로 설명된다.
+- [ ] proto-socket WS/WSS가 Portal-Control Plane 통신의 기본 transport로 문서화된다.
+- [ ] Flutter Web 브라우저 타깃에서 `dart:io` 의존 없이 WebSocket binary frame을 쓰는 경로가 정해져 있다.
+- [ ] `apps/web`에 TypeScript/Next.js 제품 UI 코드와 npm 기반 배포 경로가 남아 있지 않다.
+- [ ] Docker compose의 `web` 서비스가 Flutter Web 산출물을 빌드/서빙하는 흐름으로 동작한다.
+
+## 범위 제외
+
+- 전체 Portal 화면 구현
+- Control Plane의 모든 Edge 운영 API 구현
+- 권한, 정책, 감사, 이력 저장의 세부 구현
+- App Store, Play Store 배포와 심사 대응
+- TypeScript/Next.js 화면을 Flutter 앱 내부 WebView로 감싸는 구조
+
+## 작업 컨텍스트
+
+- 관련 경로: `apps/web/`, `apps/control-plane/`, `bin/web.sh`, `docker-compose.yml`, `apps/web/Dockerfile`, `proto/iop/`, `../proto-socket/dart/`, `../proto-socket/go/`
+- 표준선(선택): 앱은 필수 제품 표면이므로 Flutter를 Portal UI source of truth로 둔다. Next.js는 제품 UI 기준 구현으로 키우지 않는다.
+- 표준선(선택): proto-socket은 TCP뿐 아니라 WebSocket/WSS를 지원한다. Go 구현에는 `NewWsServer`, `DialWs`, `NewWsServerTLS`, `DialWss`가 있고 Dart 구현에는 `WsProtobufClient`, `WsProtobufServer`가 있다.
+- 표준선(선택): 현재 Dart proto-socket WebSocket 구현은 `dart:io` 기반이므로 mobile/desktop/server에는 맞지만 Flutter Web 브라우저 타깃에는 조건부 browser WebSocket transport가 필요하다.
+- 선행 작업: Specialized Agent proto-socket 연결 기반
+- 후속 작업: Control Plane과 Portal, 정책/이력/감사
+- 확인 필요: 없음

agent-ops/rules/project/rules.md

@@ -7,10 +7,10 @@
 
 ## 프로젝트 개요
 
-- IOP(Inference Operations Platform)는 Control Plane - Edge - Node 계층 구조를 기반으로 모델 서빙과 CLI Agent/Automation 실행을 함께 다루는 실행 오케스트레이션 모노레포이다. 핵심 서비스는 Go이고 Web Portal은 Next.js 스캐폴드로 둔다.
+- IOP(Inference Operations Platform)는 Control Plane - Edge - Node 계층 구조를 기반으로 모델 서빙과 CLI Agent/Automation 실행을 함께 다루는 실행 오케스트레이션 모노레포이다. 핵심 서비스는 Go이고 Portal UI의 장기 기준은 Flutter-first로 둔다.
 - 내부 실행 개념은 model 중심이 아니라 `adapter + target` 중심으로 정리한다. 외부 OpenAI-compatible 경계나 외부 CLI 인자에서는 호환성을 위해 `model` 표현이 남을 수 있다.
 - 현재 1차 구현 중심은 `apps/node`와 `apps/edge`의 Edge-Node 실행 스켈레톤이며, CLI adapter, node 등록/레지스트리/transport, edge input surface가 우선 검증되고 있다.
-- `apps/control-plane`은 health/readiness HTTP와 wire endpoint 예약을 가진 scaffold이고, `apps/web`은 Next.js Portal scaffold이다. 본격 구현 전 별도 domain rule을 만들거나 갱신한다.
+- `apps/control-plane`은 health/readiness HTTP와 wire endpoint 예약을 가진 scaffold이고, `apps/web`은 삭제 예정인 legacy Next.js Portal scaffold이다. Portal 본격 구현은 `Flutter-first Portal 마이그레이션` 마일스톤과 별도 domain rule 생성/갱신을 먼저 따른다.
 - `apps/worker`는 CLI placeholder 수준이므로 본격 구현 전 별도 domain rule을 만들거나 갱신한다.
 
 ## 주요 구조
@@ -18,7 +18,7 @@
 - `apps/node/` — Edge에 연결되는 실행자. 런타임 라우팅, adapter execution, CLI/model runtime 실행, 현재 단계의 로컬 실행 이력 저장을 담당한다.
 - `apps/edge/` — 여러 Node를 묶는 백엔드 실행 그룹 컨트롤러. token 기반 등록, node registry, node 설정 전달, routing, stream relay, ops console, OpenAI-compatible/A2A 입력 표면을 담당한다.
 - `apps/control-plane/` — 향후 여러 Edge를 연결하고 상태 조회/설정 변경/명령 전달/이벤트 수신/운영 제어 API 제공을 담당할 Go 기반 중앙 관리 서버 scaffold이다.
-- `apps/web/` — IOP 전체 Web Portal을 위한 Next.js scaffold이다.
+- `apps/web/` — 삭제 예정인 legacy Next.js Web Portal scaffold이다. 장기 제품 UI는 Flutter 앱과 Flutter Web 산출물 기준으로 전환한다.
 - `apps/worker/` — 비동기 작업 처리 예정 영역이다. 현재 placeholder이다.
 - `packages/` — 설정, 인증, 이벤트 helper, host setup, 정책, 메타데이터, 작업, 관측성, 버전 등 공통 패키지이다.
 - `proto/iop/` — IOP 메시지 계약 원본이다.
@@ -32,7 +32,7 @@
 ## 기술 스택
 
 - 언어/모듈: Go `1.24`, module `iop`
-- Web Portal: Next.js `16`, React `19`, TypeScript, Tailwind CSS
+- Portal UI: Flutter-first 앱과 Flutter Web 산출물 기준으로 전환 예정. 현재 `apps/web`의 Next.js/React/TypeScript scaffold는 제품 경로에서 삭제한다.
 - CLI: `github.com/spf13/cobra`
 - 설정: `github.com/spf13/viper`, YAML
 - DI: `go.uber.org/fx`
@@ -48,7 +48,7 @@
 - 새 node 어댑터는 `runtime.Adapter`를 구현하고 `apps/node/internal/bootstrap/module.go`에서 registry에 등록한다.
 - 내부 실행 요청과 상태 저장에서는 `adapter`, `target`, `execution` 용어를 우선한다. `model`은 외부 API 호환이나 legacy placeholder일 때만 허용한다.
 - Control Plane은 Node를 직접 연결/스케줄링하지 않고 Edge를 통해 시스템을 제어한다. Edge는 자신의 로컬 런타임 상태와 Node registry를 소유한다.
-- 내부 통신은 TCP 기반 protobuf 메시지 흐름을 우선한다. gRPC 도입, WebSocket 기본 transport 전환, actor/FSM/plugin framework 도입은 금지한다.
+- Edge-Node 내부 통신은 TCP 기반 protobuf 메시지 흐름을 우선한다. Portal-Control Plane처럼 브라우저/앱 표면이 필요한 경계는 proto-socket WebSocket/WSS를 사용할 수 있다. gRPC 도입, Edge-Node 기본 transport의 WebSocket 전환, actor/FSM/plugin framework 도입은 금지한다.
 - protobuf 계약 변경 시 `proto/iop/*.proto`를 먼저 수정하고 `make proto`로 `proto/gen/iop/*.pb.go`를 갱신한다. 생성 파일은 직접 수정하지 않는다.
 - 앱 설정 구조 변경 시 `packages/config`의 struct/default와 `configs/*.yaml` 예시를 함께 확인한다.
 - 테스트는 변경 범위에 맞춰 `go test ./...` 또는 대상 패키지 테스트를 실행한다.
@@ -77,7 +77,7 @@
 ## 도메인 후보
 
 - `control-plane`: `apps/control-plane/**`가 scaffold를 넘어 여러 Edge 연결 관리, Edge 상태 조회, Edge 설정 변경, Edge 명령 전달, 이벤트 수신, 운영 제어 API 제공을 구현하기 시작할 때 생성한다.
-- `web`: `apps/web/**`가 Portal scaffold를 넘어 노드/모델/작업/운영 화면과 Control Plane 통신을 본격 구현하기 시작할 때 생성한다.
+- `portal`: Flutter-first Portal 또는 legacy `apps/web/**` 제거/대체가 본격 구현될 때 생성한다. 기존 Next.js `apps/web/**`는 확장하지 않고 삭제 또는 Flutter Web 산출물 서빙 경로로 대체한다.
 - `worker`: `apps/worker/**`가 placeholder를 넘어 작업 큐 소비/재시도/결과 저장을 구현하기 시작할 때 생성한다.
 
 ## 스킬 라우팅

apps/control-plane/README.md

@@ -6,7 +6,7 @@
 
 현재 Control Plane은 실행 가능한 최소 서버 스캐폴드 단계다. Node를 직접 등록하거나 직접 스케줄링하는 계층으로 확정하지 않는다. Control Plane은 Edge를 통해 시스템을 제어하고, Edge가 자신의 로컬 런타임 상태와 Node registry를 운영하는 방향을 따른다.
 
-IOP의 프론트엔드는 Control Plane 내부 UI가 아니라 `apps/web`의 React + Next.js 기반 Web Portal로 둔다. Portal은 별도 Docker 컨테이너로 운영하며, Control Plane과의 주요 통신은 edge-node에서 사용 중인 protobuf-socket을 IOP Wire Protocol 기준으로 확장한다. `net/http`는 health/readiness/bootstrap 같은 보조 endpoint 용도로만 둔다.
+IOP의 프론트엔드는 Control Plane 내부 UI가 아니라 Flutter-first Portal로 둔다. 현재 `apps/web`의 React + Next.js scaffold는 삭제 예정인 legacy 표면이며, Portal web 배포는 Flutter Web 산출물을 서빙하는 흐름으로 전환한다. Portal-Control Plane 통신은 proto-socket WebSocket/WSS를 우선하고, Control Plane-Edge 통신은 edge-node에서 사용 중인 proto-socket 흐름을 IOP Wire Protocol 기준으로 확장한다. `net/http`는 health/readiness/bootstrap 같은 보조 endpoint 용도로만 둔다.
 
 ## 현재 실행 표면
 

apps/web/README.md

@@ -1,8 +1,12 @@
-# web - IOP Web Portal
+# web - Legacy IOP Web Portal
 
-`apps/web`은 IOP 전체 Web Portal을 위한 Next.js 스캐폴드다. 현재는 root dummy 화면만 제공하며, `/nodes`, `/models`, `/jobs` 같은 도메인 페이지는 아직 만들지 않는다.
+`apps/web`은 삭제 예정인 legacy Next.js 스캐폴드다. IOP Portal의 장기 UI 기준은 Flutter-first 앱이며, 웹 표면은 Flutter Web 산출물로 대체한다. 이 디렉터리에서 `/nodes`, `/models`, `/jobs` 같은 도메인 페이지를 새로 구현하지 않는다.
 
-Control Plane과의 주요 통신은 edge-node에서 사용 중인 protobuf-socket을 IOP Wire Protocol 기준으로 확장한다. 현재 `src/lib/iop-client/`에는 TypeScript 클라이언트 연결 위치와 TODO만 둔다. 브라우저 직접 WebSocket transport가 확정되기 전까지는 Next.js server-side bridge가 필요할 수 있다.
+Control Plane과의 주요 통신은 edge-node에서 사용 중인 proto-socket을 IOP Wire Protocol 기준으로 확장한다. Portal-Control Plane은 Flutter mobile/desktop과 Flutter Web을 고려해 proto-socket WebSocket/WSS를 우선한다. 현재 TypeScript 클라이언트 TODO는 제품 경로로 확장하지 않는다.
+
+## Migration
+
+현재 최상위 작업은 `agent-ops/roadmap/milestones/flutter-first-portal-migration.md`다. 이 마일스톤에서 `apps/web`의 TypeScript/Next.js scaffold와 npm 기반 배포 흐름을 삭제하고, Docker/compose web 서비스는 Flutter Web build 산출물을 서빙하는 흐름으로 바꾼다.
 
 ## Local
 

docs/architecture.md

@@ -129,12 +129,12 @@ type Adapter interface {
 - Control Plane은 향후 Edge와 소켓 기반 연결을 맺는다.
 - Control Plane이 Node에 직접 연결하거나 매 요청마다 Node를 직접 스케줄링하는 구조는 목표가 아니다.
 - OTO agent는 Control Plane이나 `iop-node`에 직접 종속되지 않고 Edge의 agent registry와 bootstrap/enrollment 계약을 따른다.
-- Portal-Control Plane, Control Plane-Edge, Edge-Node의 장기 통신 기준은 IOP Wire Protocol(protobuf-socket)이다. 브라우저가 직접 TCP를 사용할 수 없는 구간은 Web Portal이 직접 wire client가 되기보다 Control Plane의 server-side bridge를 통해 연결한다.
+- Portal-Control Plane, Control Plane-Edge, Edge-Node의 장기 통신 기준은 IOP Wire Protocol(proto-socket)이다. Edge-Node와 Control Plane-Edge의 기본 transport는 TCP 기반 proto-socket으로 유지하고, Portal-Control Plane은 Flutter mobile/desktop과 Flutter Web을 고려해 proto-socket WebSocket/WSS를 우선한다. Flutter Web 브라우저 타깃은 raw TCP가 아니라 WebSocket binary frame 기반 transport를 사용한다.
 - OpenAI-compatible HTTP API와 A2A JSON-RPC HTTP API는 Edge 외부 입력 표면으로 유지하며, Control Plane 운영 제어 프로토콜의 기본값으로 삼지 않는다.
 
 ## 배포 철학
 
-Control Plane과 Web은 중앙 운영면으로 묶어 compose 기반 서비스로 배포한다. dev 필드 테스트 compose에는 Control Plane DB와 Redis 후보를 함께 포함해 이후 schema, audit, event, queue 작업을 같은 배포 단위 안에서 진행한다.
+Control Plane과 Portal은 중앙 운영면으로 묶어 compose 기반 서비스로 배포한다. Portal의 장기 UI 기준은 Flutter-first 앱이며, web 배포는 Flutter Web 산출물을 서빙하는 흐름으로 전환한다. dev 필드 테스트 compose에는 Control Plane DB와 Redis 후보를 함께 포함해 이후 schema, audit, event, queue 작업을 같은 배포 단위 안에서 진행한다.
 
 Edge와 Node는 Docker 이미지로 만들지 않고 호스트 단일 바이너리로 배포한다. Jenkins는 Edge/Node 바이너리만 빌드하고, 각 호스트는 배포된 바이너리의 `setup` 명령을 통해 systemd 실행 환경을 준비한다. OTO는 별도 프로젝트의 단일 바이너리 build/deploy agent로 두고, 장기적으로는 Edge가 OTO agent 생성과 bootstrap command 발급을 담당한다.
 
@@ -181,7 +181,7 @@ oto build host:
 ## 금지 사항
 
 - gRPC (`grpc-go`) 사용 금지
-- WebSocket 기본 transport 사용 금지
+- Edge-Node 기본 transport를 WebSocket으로 전환 금지. Portal-Control Plane의 proto-socket WebSocket/WSS 사용은 예외로 허용
 - Actor framework 사용 금지
 - External worker pool 사용 금지
 - FSM framework 사용 금지