<!-- task=07_cli_profile_proto_message plan=1 tag=REVIEW_API -->

# Plan - REVIEW_API

## 이 파일을 읽는 구현 에이전트에게

아래 체크리스트를 순서대로 완료하고, 각 항목의 중간 검증과 최종 검증을 실제로 실행하세요. 구현이 끝나면 `agent-task/07_cli_profile_proto_message/CODE_REVIEW-cloud-G10.md`의 모든 섹션을 실제 구현 내용과 명령 출력으로 채우세요. `CODE_REVIEW-cloud-G10.md`의 `이 파일을 읽는 리뷰 에이전트에게` 섹션에 있는 아카이브 지시(`*.log`로 이름 변경, `complete.log` 작성)는 구현 에이전트가 수행하면 안 되며, 리뷰 스킬 전용입니다.

## 개요

date=2026-05-04
task=07_cli_profile_proto_message, plan=1, tag=REVIEW_API
parent=API (code_review_cloud_G10_0.log)

## 배경

이번 루프에서 `AdapterConfig.settings`를 `legacy/compat path`로 유지한다고 명시했지만, node 쪽 `BuildFromPayload`는 새 oneof만 읽고 기존 `settings` 역직렬화 경로를 완전히 제거했습니다. 그 결과 구버전 edge나 oneof 미사용 payload가 들어오면 `ollama`/`vllm`은 빈 endpoint로, `cli`는 빈 profiles로 등록되어 호환성 계약이 실제로 깨집니다.

## 의존 관계 및 구현 순서

1. `REVIEW_API-1`에서 node 역직렬화에 legacy fallback 정책을 복구하거나, 호환 제거를 명시적 breaking change로 정리한다.
2. 같은 항목에서 legacy payload 회귀 테스트를 추가해 `settings` 전용 입력도 원하는 동작을 보장한다.
3. 구현 후 `CODE_REVIEW` 문서의 변경 사항/설계 결정/검증 결과를 실제 상태로 갱신한다.

## [REVIEW_API-1] legacy settings payload 호환성 복구

### 문제

- `proto/iop/runtime.proto`는 `settings = 3`를 `legacy/compat path`로 남겨 두었음
- 하지만 `apps/node/internal/adapters/factory.go`는 `GetCli()`/`GetOllama()`/`GetVllm()`만 사용해, oneof가 비어 있고 `settings`만 있는 payload를 더 이상 읽지 못함
- 현재 테스트는 typed payload만 검증하므로 이 회귀를 잡지 못함

### 해결 방법

우선순위는 실제 호환성 복구입니다. `BuildFromPayload`에서 typed config가 있으면 그것을 우선 사용하되, 없고 `settings`가 있으면 기존 struct 기반 디코드로 fallback 하도록 복원합니다. `cli`/`ollama`/`vllm` 모두 동일 원칙을 적용합니다.

만약 이번 작업에서 호환 제거가 의도라면, 그 결정은 proto 주석, plan/review 문서, 배포 계약에 모두 breaking change로 명시되어야 하며, 구버전 혼합 배포를 금지하는 근거와 검증도 함께 남겨야 합니다. 다만 현재 문서/주석은 호환 유지 쪽을 가리키므로 기본 해법은 fallback 복구입니다.

### 수정 파일 및 체크리스트

- [ ] `apps/node/internal/adapters/factory.go`에서 oneof가 nil일 때 `settings` legacy 경로로 fallback 하도록 복구
- [ ] `cli`/`ollama`/`vllm` 모두 typed 우선, legacy fallback 순서를 일관되게 적용
- [ ] `apps/node/internal/adapters/factory_test.go` 또는 `factory_internal_test.go`에 legacy payload 회귀 테스트 추가
- [ ] 새 테스트가 endpoint/base_url/profiles 같은 핵심 값이 실제로 복원되는지 단언
- [ ] `CODE_REVIEW-cloud-G10.md`의 `계획 대비 변경 사항`, `주요 설계 결정`, `검증 결과`를 실제 구현/출력에 맞게 갱신

### 테스트 작성

최소 1개 이상의 legacy payload 회귀 테스트가 필요합니다.

- `ollama` 또는 `vllm`: `settings`만 채운 payload에서 URL/endpoint가 복원되는지 검증
- `cli`: `settings.profiles`만 채운 payload에서 command/args 또는 completion_marker가 복원되는지 검증

### 중간 검증

```bash
go test ./apps/node/internal/adapters/... -count=1
```

기대 결과: typed 경로와 legacy fallback 경로를 모두 포함한 테스트가 PASS한다.

## 최종 검증

```bash
make proto
go build ./...
go test ./...
```

기대 결과: 전체 빌드/테스트가 PASS하고, review 문서의 검증 출력이 실제 결과와 일치한다.
