toki/oto
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(agent-ops): 모노레포 규칙과 로드맵을 정리한다

Browse source 
현재 workspace 구조와 맞지 않던 agent-ops 규칙, domain rule, 로드맵 항목을 함께 정리해 후속 작업이 올바른 경로와 검증 기준을 참조하도록 한다.
This commit is contained in:
toki 2026-06-07 04:31:32 +09:00
parent fac57a96fd
commit ba5abbf9d8
23 changed files with 1461 additions and 162 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
agent-ops/rules/project/domain/agent/rules.md
View file

@ -13,20 +13,20 @@ OTO Edge 서버에 CLI 기반 agent 노드를 등록하고, agent 실행에 필
## 포함 경로
- `lib/cli/commands/command_agent.dart` — `agent run --config <path>` CLI 표면과 오류 출력
- `lib/oto/agent/` — agent config, runner, Edge 등록 client, generated protobuf 런타임 코드
- `assets/script/shell/oto_agent_bootstrap.sh` — Linux agent 다운로드, config 생성, background 실행 bootstrap
- `apps/runner/lib/cli/commands/command_agent.dart` — `agent run --config <path>` CLI 표면과 오류 출력
- `apps/runner/lib/oto/agent/` — agent config, runner, Edge 등록 client, generated protobuf 런타임 코드
- `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` — Linux agent 다운로드, config 생성, background 실행 bootstrap
## 제외 경로
- `lib/cli/cli.dart` — 일반 CLI 출력/초기화 (`cli` 도메인)
- `lib/cli/commands/command_catalog.dart` — command catalog 출력 (`cli` 도메인)
- `lib/cli/commands/command_validate.dart` — pipeline YAML 검증 (`cli`/`core` 도메인)
- `lib/cli/commands/command_scheduler.dart` — scheduler 명령 진입 (`scheduler` 도메인)
- `lib/oto/application.dart` — pipeline build 오케스트레이션 (`core` 도메인)
- `lib/oto/pipeline/` — pipeline workflow 실행 (`pipeline` 도메인)
- `lib/oto/commands/` — pipeline에서 호출되는 커맨드 구현체 (`command` 도메인)
- `assets/script/`의 기타 build/package helper — CLI/배포 보조 asset (`cli` 도메인)
- `apps/runner/lib/cli/cli.dart` — 일반 CLI 출력/초기화 (`cli` 도메인)
- `apps/runner/lib/cli/commands/command_catalog.dart` — command catalog 출력 (`cli` 도메인)
- `apps/runner/lib/cli/commands/command_validate.dart` — pipeline YAML 검증 (`cli`/`core` 도메인)
- `apps/runner/lib/cli/commands/command_scheduler.dart` — scheduler 명령 진입 (`scheduler` 도메인)
- `apps/runner/lib/oto/application.dart` — pipeline build 오케스트레션 (`core` 도메인)
- `apps/runner/lib/oto/pipeline/` — pipeline workflow 실행 (`pipeline` 도메인)
- `apps/runner/lib/oto/commands/` — pipeline에서 호출되는 커맨드 구현체 (`command` 도메인)
- `apps/runner/assets/script/`의 기타 build/package helper — CLI/배포 보조 asset (`cli` 도메인)
## 주요 구성 요소
@ -39,8 +39,8 @@ OTO Edge 서버에 CLI 기반 agent 노드를 등록하고, agent 실행에 필
- `EdgeRegistrationClient` — `proto_socket` 기반 RegisterRequest 전송
- `RegistrationResult` — RegisterResponse accepted/rejected 결과 변환
- `_OtoIopClient` — agent iop protobuf message registry를 가진 proto_socket client
- `lib/oto/agent/iop/*.pb*.dart` — `iop/runtime.proto` generated protobuf 코드
- `lib/oto/agent/google/protobuf/*.pb*.dart` — `google/protobuf/struct.proto` generated protobuf 코드
- `apps/runner/lib/oto/agent/iop/*.pb*.dart` — `iop/runtime.proto` generated protobuf 코드
- `apps/runner/lib/oto/agent/google/protobuf/*.pb*.dart` — `google/protobuf/struct.proto` generated protobuf 코드
- `oto_agent_bootstrap.sh` — agent config 파일 생성, 권한 설정, background 실행 bootstrap
## 유지할 패턴
@ -54,15 +54,15 @@ OTO Edge 서버에 CLI 기반 agent 노드를 등록하고, agent 실행에 필
- RegisterResponse 변환은 `RegistrationResult.fromResponse()`에 모아 accepted/rejected와 runtime config 추출을 한 곳에서 처리한다.
- generated protobuf 파일은 직접 수정하지 않고 원본 proto와 생성 절차를 확인해 재생성한다.
- bootstrap 스크립트는 `--release-base-url`에 https만 허용하고, 생성한 config 파일은 `chmod 600`을 유지한다.
- agent 변경 후 `dart analyze`와 agent 관련 테스트(`test/oto_agent_*`, 필요 시 `test/oto_iop_connection_smoke_test.dart`)를 확인한다.
- agent 변경 후 `dart analyze`와 agent 관련 테스트(`apps/runner/test/oto_agent_*`, 필요 시 `apps/runner/test/oto_iop_connection_smoke_test.dart`)를 확인한다.
## 다른 도메인과의 경계
- **cli**: `bin/main.dart` 등록과 일반 출력/스타일은 cli 도메인이다. `CommandAgent` 내부의 agent subcommand 정책부터는 agent 도메인이다.
- **cli**: `apps/runner/bin/main.dart` 등록과 일반 출력/스타일은 cli 도메인이다. `CommandAgent` 내부의 agent subcommand 정책부터는 agent 도메인이다.
- **core/pipeline/command**: agent 등록은 pipeline build 실행과 별개다. agent 도메인에서 `Application.build()`, `Pipeline.pipelineInitialize()`, `Command.byType()`을 직접 호출하지 않는다.
- **scheduler**: scheduler는 YAML 파이프라인을 cron/interval로 실행한다. agent bootstrap의 background 실행과 scheduler 등록/로그 정책을 섞지 않는다.
- **framework**: `proto_socket`, `protobuf`, `fixnum` dependency 선언은 framework 도메인에서 관리하고, Edge protocol 사용 방식은 agent 도메인에서 관리한다.
- **sample**: agent config YAML은 pipeline sample YAML이 아니다. `assets/yaml/sample/**`에 agent bootstrap config를 섞지 않는다.
- **sample**: agent config YAML은 pipeline sample YAML이 아니다. `apps/runner/assets/yaml/sample/**`에 agent bootstrap config를 섞지 않는다.
## 금지 사항

60
agent-ops/rules/project/domain/cli/rules.md
View file

@ -13,34 +13,34 @@ last_rule_updated_at: 2026-06-01
## 포함 경로
- `bin/main.dart` — 외부 `dart_framework` 앱 래퍼를 통해 CLI를 초기화하는 실행 진입점
- `lib/cli/cli.dart` — CLI 루트 객체, 출력/스타일 처리
- `lib/cli/printer.dart` — OS별 콘솔 출력과 ANSI 스타일 처리
- `lib/cli/cli_style.dart` — 콘솔 색상/스타일 enum
- `lib/cli/commands/command_base.dart` — CLI 커맨드 공통 베이스
- `lib/cli/commands/command_manager.dart` — CLI 커맨드 라우팅
- `lib/cli/commands/command_const.dart` — OS별 설치 경로 상수
- `lib/cli/commands/command_exe.dart` — `exe` 명령과 `Application.build()` 진입
- `lib/cli/commands/command_catalog.dart` — 등록된 OTO 커맨드 catalog 출력 명령
- `lib/cli/commands/command_validate.dart` — YAML 구조/의미 검증 명령
- `lib/cli/commands/command_template.dart` — 템플릿 출력
- `lib/cli/commands/command_start.dart` — 시작/중지 커맨드
- `lib/cli/commands/command_install.dart` — 설치/제거 명령
- `lib/cli/commands/install/` — PATH 등록 등 설치 보조 로직
- `lib/resources.resource_importer.dart` — 설치/패키징 asset용 `resource_importer` 생성 파일
- `assets/package/` — 배포/패키징 보조 파일
- `assets/bin/` — 설치 또는 패키징에 포함되는 보조 바이너리
- `assets/script/` — 빌드/패키징/실행 보조 스크립트. Jenkins env helper는 core 경계도 함께 확인
- `apps/runner/bin/main.dart` — 외부 `dart_framework` 앱 래퍼를 통해 CLI를 초기화하는 실행 진입점
- `apps/runner/lib/cli/cli.dart` — CLI 루트 객체, 출력/스타일 처리
- `apps/runner/lib/cli/printer.dart` — OS별 콘솔 출력과 ANSI 스타일 처리
- `apps/runner/lib/cli/cli_style.dart` — 콘솔 색상/스타일 enum
- `apps/runner/lib/cli/commands/command_base.dart` — CLI 커맨드 공통 베이스
- `apps/runner/lib/cli/commands/command_manager.dart` — CLI 커맨드 라우팅
- `apps/runner/lib/cli/commands/command_const.dart` — OS별 설치 경로 상수
- `apps/runner/lib/cli/commands/command_exe.dart` — `exe` 명령과 `Application.build()` 진입
- `apps/runner/lib/cli/commands/command_catalog.dart` — 등록된 OTO 커맨드 catalog 출력 명령
- `apps/runner/lib/cli/commands/command_validate.dart` — YAML 구조/의미 검증 명령
- `apps/runner/lib/cli/commands/command_template.dart` — 템플릿 출력
- `apps/runner/lib/cli/commands/command_start.dart` — 시작/중지 커맨드
- `apps/runner/lib/cli/commands/command_install.dart` — 설치/제거 명령
- `apps/runner/lib/cli/commands/install/` — PATH 등록 등 설치 보조 로직
- `apps/runner/lib/resources.resource_importer.dart` — 설치/패키징 asset용 `resource_importer` 생성 파일
- `apps/runner/assets/package/` — 배포/패키징 보조 파일
- `apps/runner/assets/bin/` — 설치 또는 패키징에 포함되는 보조 바이너리
- `apps/runner/assets/script/` — 빌드/패키징/실행 보조 스크립트. Jenkins env helper는 core 경계도 함께 확인
## 제외 경로
- `lib/oto/` — 비즈니스 로직·파이프라인 엔진 (cli는 진입만 담당)
- `lib/cli/commands/command_agent.dart` — OTO Edge agent 실행 명령 (`agent` 도메인)
- `lib/cli/commands/command_scheduler.dart` — scheduler 명령 파싱과 등록/실행 진입점 (`scheduler` 도메인)
- `lib/cli/commands/scheduler/` — 스케줄러 실행/등록/OS별 백그라운드 처리 (`scheduler` 도메인)
- `lib/oto/agent/` — agent 설정/등록/Edge 통신 (`agent` 도메인)
- `assets/script/shell/oto_agent_bootstrap.sh` — agent 설치/실행 bootstrap (`agent` 도메인)
- `assets/template/` — 커맨드 실행 중 사용하는 템플릿 (`command` 도메인)
- `apps/runner/lib/oto/` — 비즈니스 로직·파이프라인 엔진 (cli는 진입만 담당)
- `apps/runner/lib/cli/commands/command_agent.dart` — OTO Edge agent 실행 명령 (`agent` 도메인)
- `apps/runner/lib/cli/commands/command_scheduler.dart` — scheduler 명령 파싱과 등록/실행 진입점 (`scheduler` 도메인)
- `apps/runner/lib/cli/commands/scheduler/` — 스케줄러 실행/등록/OS별 백그라운드 처리 (`scheduler` 도메인)
- `apps/runner/lib/oto/agent/` — agent 설정/등록/Edge 통신 (`agent` 도메인)
- `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` — agent 설치/실행 bootstrap (`agent` 도메인)
- `apps/runner/assets/template/` — 커맨드 실행 중 사용하는 템플릿 (`command` 도메인)
## 주요 구성 요소
@ -57,17 +57,17 @@ last_rule_updated_at: 2026-06-01
- `CommandTemplate` — 템플릿 출력
- `CommandManager` — CLI 커맨드 등록 관리
- `RegistPath` — OS별 PATH 등록/해제
- `bin/main.dart` — CLI 초기화 시 등록할 top-level 명령 목록을 정의
- `apps/runner/bin/main.dart` — CLI 초기화 시 등록할 top-level 명령 목록을 정의
## 유지할 패턴
- CLI 커맨드는 `CommandBase` 상속
- top-level 명령 등록은 `bin/main.dart`의 `CLI.initialize(..., [Command...])` 목록에서 관리
- top-level 명령 등록은 `apps/runner/bin/main.dart`의 `CLI.initialize(..., [Command...])` 목록에서 관리
- CLI는 인자 파싱과 진입점 역할만 수행하고, 파이프라인 실행은 `Application.build()`에 위임
- `CommandExe`는 `BuildType` 선택과 YAML 파일 읽기까지만 담당
- `catalog`/`validate`처럼 JSON 출력을 지원하는 CLI는 stdout에 구조화 결과만 쓰고 일반 실행 로그는 억제한다
- 콘솔 출력은 `CLI.print*`, `CLI.style`, `Printer`, 또는 `CommandBase` 출력 헬퍼를 사용
- CLI 변경 후 `dart analyze`를 실행하고, CLI 진입 변경이면 최소 `dart run bin/main.dart` 수준의 스모크 실행 가능 여부를 확인
- CLI 변경 후 `dart analyze`를 실행하고, CLI 진입 변경이면 최소 `dart run apps/runner/bin/main.dart` 수준의 스모크 실행 가능 여부를 확인
- 배포/설치 asset 변경 시 관련 CLI 설치/패키징 경로가 실제 파일명을 참조하는지 확인
## 다른 도메인과의 경계
@ -75,8 +75,8 @@ last_rule_updated_at: 2026-06-01
- **pipeline/command**: cli는 `Application.build()`만 호출. 파이프라인·커맨드 내부를 직접 참조하지 않는다
- **core**: DataComposer 호출은 Application 내부에서 이루어지며 cli는 관여하지 않는다
- **agent**: `agent` 명령과 `CommandAgent`는 agent 도메인이다. 일반 CLI 변경에서 Edge 등록/agent config 정책을 함께 수정하지 않는다
- **scheduler**: `CommandScheduler`, `lib/cli/commands/command_scheduler.dart`, `lib/cli/commands/scheduler/**`는 scheduler 도메인이다. 일반 CLI 변경에서 scheduler 내부 동작을 함께 수정하지 않는다
- **framework**: `bin/main.dart`는 외부 framework Application을 소비하지만 framework 의존성 자체는 framework 도메인에서 다룬다
- **scheduler**: `CommandScheduler`, `apps/runner/lib/cli/commands/command_scheduler.dart`, `apps/runner/lib/cli/commands/scheduler/**`는 scheduler 도메인이다. 일반 CLI 변경에서 scheduler 내부 동작을 함께 수정하지 않는다
- **framework**: `apps/runner/bin/main.dart`는 외부 framework Application을 소비하지만 framework 의존성 자체는 framework 도메인에서 다룬다
## 금지 사항

40
agent-ops/rules/project/domain/command/rules.md
View file

@ -13,16 +13,16 @@ last_rule_updated_at: 2026-06-01
## 포함 경로
- `lib/oto/commands/` — 커맨드 구현체 (카테고리별 하위 폴더)
- `lib/oto/data/` — 커맨드 파라미터 데이터 모델 (`*_data.dart`, `*.g.dart`). `pipeline_data.dart`는 pipeline 도메인
- `assets/template/` — 커맨드 실행 중 사용하는 템플릿 파일
- `apps/runner/lib/oto/commands/` — 커맨드 구현체 (카테고리별 하위 폴더)
- `apps/runner/lib/oto/data/` — 커맨드 파라미터 데이터 모델 (`*_data.dart`, `*.g.dart`). `pipeline_data.dart`는 pipeline 도메인
- `apps/runner/assets/template/` — 커맨드 실행 중 사용하는 템플릿 파일
## 제외 경로
- `lib/oto/pipeline/` — 실행 흐름 제어 (커맨드 dispatch 이전)
- `lib/oto/core/` — 태그 치환, 데이터 합성 (커맨드 실행 이전)
- `lib/oto/data/pipeline_data.dart` — workflow/조건/반복 데이터 모델 (`pipeline` 도메인)
- `assets/yaml/sample/` — YAML 사용 예시 (`sample` 도메인)
- `apps/runner/lib/oto/pipeline/` — 실행 흐름 제어 (커맨드 dispatch 이전)
- `apps/runner/lib/oto/core/` — 태그 치환, 데이터 합성 (커맨드 실행 이전)
- `apps/runner/lib/oto/data/pipeline_data.dart` — workflow/조건/반복 데이터 모델 (`pipeline` 도메인)
- `apps/runner/assets/yaml/sample/` — YAML 사용 예시 (`sample` 도메인)
## 주요 구성 요소
@ -35,25 +35,27 @@ last_rule_updated_at: 2026-06-01
- `DataBuild` / `DataScheduler` (`command_data.dart`) — YAML 최상위 build/scheduler 데이터
- `DataCommand` (`command_data.dart`) — 모든 커맨드에 전달되는 통합 컨테이너
배포/패키징 보조 파일 및 스크립트는 이 도메인의 대상이 아니다.
커맨드 카테고리와 우선 참조 파일:
| 범주 | 구현 경로 | 데이터 모델 |
|------|-----------|-------------|
| build | `lib/oto/commands/build/` | `lib/oto/data/build_data.dart` |
| file | `lib/oto/commands/file/` | `lib/oto/data/file_data.dart` |
| git / GitHub | `lib/oto/commands/git/` | `lib/oto/data/git_data.dart` |
| ftp / web | `lib/oto/commands/ftp/`, `lib/oto/commands/web/` | `lib/oto/data/network_data.dart` |
| notification | `lib/oto/commands/notification/`, `lib/oto/utils/mattermost/` | `lib/oto/data/notification_data.dart` |
| jira / jenkins | `lib/oto/commands/jira/`, `lib/oto/commands/jenkins/` | `lib/oto/data/integration_data.dart`, `lib/oto/data/jira_data.dart` |
| infra / external tool | `lib/oto/commands/aws/`, `docker/`, `gradle/`, `infra/`, `proto/` | `lib/oto/data/infra_data.dart`, `lib/oto/data/util_data.dart` |
| shell / process / util | `lib/oto/commands/shell/`, `process/`, `util/` | `lib/oto/data/util_data.dart` |
| build | `apps/runner/lib/oto/commands/build/` | `apps/runner/lib/oto/data/build_data.dart` |
| file | `apps/runner/lib/oto/commands/file/` | `apps/runner/lib/oto/data/file_data.dart` |
| git / GitHub | `apps/runner/lib/oto/commands/git/` | `apps/runner/lib/oto/data/git_data.dart` |
| ftp / web | `apps/runner/lib/oto/commands/ftp/`, `apps/runner/lib/oto/commands/web/` | `apps/runner/lib/oto/data/network_data.dart` |
| notification | `apps/runner/lib/oto/commands/notification/`, `apps/runner/lib/oto/utils/mattermost/` | `apps/runner/lib/oto/data/notification_data.dart` |
| jira / jenkins | `apps/runner/lib/oto/commands/jira/`, `apps/runner/lib/oto/commands/jenkins/` | `apps/runner/lib/oto/data/integration_data.dart`, `apps/runner/lib/oto/data/jira_data.dart` |
| infra / external tool | `apps/runner/lib/oto/commands/aws/`, `apps/runner/lib/oto/commands/docker/`, `apps/runner/lib/oto/commands/gradle/`, `apps/runner/lib/oto/commands/infra/`, `apps/runner/lib/oto/commands/proto/` | `apps/runner/lib/oto/data/infra_data.dart`, `apps/runner/lib/oto/data/util_data.dart` |
| shell / process / util | `apps/runner/lib/oto/commands/shell/`, `apps/runner/lib/oto/commands/process/`, `apps/runner/lib/oto/commands/util/` | `apps/runner/lib/oto/data/util_data.dart` |
커맨드 asset:
| asset | 사용처 |
|-------|--------|
| `assets/template/index.html` | iOS publish HTML 템플릿 |
| `assets/template/manifest.plist` | iOS publish manifest 템플릿 |
| `apps/runner/assets/template/index.html` | iOS publish HTML 템플릿 |
| `apps/runner/assets/template/manifest.plist` | iOS publish manifest 템플릿 |
## 유지할 패턴
@ -66,8 +68,8 @@ last_rule_updated_at: 2026-06-01
- 커맨드 파라미터는 `getParam(command)`를 통해 태그 치환과 workspace resolve를 거친 뒤 `Data*` 모델로 파싱한다
- 결과 저장은 `<@property.key>` 형태의 쓰기 태그와 `setProperty()` / `complete()`의 `setResult`, `setExitCode` 흐름을 우선 사용한다
- 외부 프로세스 실행은 `Command.runtime`을 통해 `CommandRuntime.start()`, `run()`, `runExecutable()`, `startDetached()` 중 목적에 맞게 사용한다
- 커맨드 추가/파라미터 변경 시 관련 `assets/yaml/sample/**`와 README 커맨드 목록 갱신 필요 여부를 확인한다
- 커맨드가 `assets/template/**`를 읽거나 출력 형식에 의존하면 템플릿 경로와 placeholder 계약을 함께 확인한다
- 커맨드 추가/파라미터 변경 시 관련 `apps/runner/assets/yaml/sample/**`와 README 커맨드 목록 갱신 필요 여부를 확인한다
- 커맨드가 `apps/runner/assets/template/**`를 읽거나 출력 형식에 의존하면 템플릿 경로와 placeholder 계약을 함께 확인한다
- 데이터 모델 변경 후 `dart run build_runner build`와 `dart analyze`를 실행한다
## 다른 도메인과의 경계

18
agent-ops/rules/project/domain/core/rules.md
View file

@ -13,18 +13,18 @@ last_rule_updated_at: 2026-06-01
## 포함 경로
- `lib/oto/application.dart` — 싱글턴 오케스트레이터 (BuildType enum, 빌드 진입점)
- `lib/oto/core/` — 태그 시스템, 데이터 합성, 정의 데이터
- `lib/oto/utils/` — 공통 유틸리티 (Mattermost 등 재사용 헬퍼)
- `assets/script/batch/jenkins_env_params.bat` — Jenkins 환경 변수 합성에 쓰이는 Windows helper script
- `assets/script/shell/jenkins_env_params.sh` — Jenkins 환경 변수 합성 helper script
- `apps/runner/lib/oto/application.dart` — 싱글턴 오케스트레이터 (BuildType enum, 빌드 진입점)
- `apps/runner/lib/oto/core/` — 태그 시스템, 데이터 합성, 정의 데이터
- `apps/runner/lib/oto/utils/` — 공통 유틸리티 (Mattermost 등 재사용 헬퍼)
- `apps/runner/assets/script/batch/jenkins_env_params.bat` — Jenkins 환경 변수 합성에 쓰이는 Windows helper script
- `apps/runner/assets/script/shell/jenkins_env_params.sh` — Jenkins 환경 변수 합성 helper script
## 제외 경로
- `lib/oto/pipeline/` — 실행 흐름 (core 처리 이후)
- `lib/oto/commands/` — 커맨드 구현체 (core 결과물을 소비)
- `lib/oto/agent/` — OTO Edge agent 설정/등록/통신 (`agent` 도메인)
- `assets/script/`의 빌드/패키징 보조 스크립트 — CLI/배포 보조 asset이며 core가 직접 해석하지 않는다
- `apps/runner/lib/oto/pipeline/` — 실행 흐름 (core 처리 이후)
- `apps/runner/lib/oto/commands/` — 커맨드 구현체 (core 결과물을 소비)
- `apps/runner/lib/oto/agent/` — OTO Edge agent 설정/등록/통신 (`agent` 도메인)
- `apps/runner/assets/script/`의 빌드/패키징 보조 스크립트 — CLI/배포 보조 asset이며 core가 직접 해석하지 않는다
## 주요 구성 요소

28
agent-ops/rules/project/domain/framework/rules.md
View file

@ -9,42 +9,48 @@ last_rule_updated_at: 2026-06-01
## 목적 / 책임
현재 프로젝트에는 `lib/framework/` 모듈이 없다.
이 도메인은 외부 Git 의존성인 `dart_framework` 사용 규칙, Dart toolchain 설정, 의존성 경계를 기록한다.
이 도메인은 runner, client, console, core service의 패키지 선언(manifest), 분석기(analyzer/lint), protobuf 계약 정의 및 생성 코드 관리, 외부 의존성 경계와 빌드 도구 설정을 기록한다.
단, 전용 도메인 규칙(dedicated domain rule)이 아직 존재하지 않는 `apps/client/lib/**`, `packages/flutter/oto_console/lib/**`, `services/core/internal/**` 등의 구현 코드가 가진 구체적인 비즈니스 동작 규칙은 이 framework 도메인이나 기존 runner 도메인 규칙으로 무리하게 확장하여 단정하지 않고, 추후 별도 도메인 규칙 생성 또는 후속 milestone 작업을 통해 정리한다.
## 포함 경로
- `pubspec.yaml` — `dart_framework` 외부 Git 의존성 선언
- `analysis_options.yaml` — Dart analyzer/lint 기준
- `apps/runner/pubspec.yaml` — runner Dart dependency와 `dart_framework` Git 의존성 선언
- `apps/runner/analysis_options.yaml` — runner Dart analyzer/lint 기준
- `apps/client/pubspec.yaml` — Flutter client dependency 선언
- `apps/client/analysis_options.yaml` — Flutter client analyzer/lint 기준
- `packages/flutter/oto_console/pubspec.yaml` — embeddable console package dependency 선언
- `services/core/go.mod` — Go core service dependency 선언
- `proto/` — runner/server protobuf 계약 정의
## 제외 경로
- `lib/framework/` — 제거된 로컬 모듈. 새로 만들지 않는다
- `lib/oto/` — OTO 비즈니스 로직 (framework 위에서 동작)
- `lib/cli/` — CLI 레이어 (framework를 소비)
- `apps/runner/lib/oto/` — OTO 비즈니스 로직 (framework 위에서 동작)
- `apps/runner/lib/cli/` — CLI 레이어 (framework를 소비)
## 주요 구성 요소
- `dart_framework/core/application.dart` — `bin/main.dart`에서 앱 진입 래퍼로 사용
- `dart_framework/core/application.dart` — `apps/runner/bin/main.dart`에서 앱 진입 래퍼로 사용
- `dart_framework/platform/process.dart` — 커맨드 실행에서 `ProcessExecutor`, `ProcessData` 사용
- `dart_framework/platform/isolate_manager.dart` — CLI 실행/스케줄러 isolate 처리에서 사용
- `dart_framework/utils/*` — `simpleFuture`, path/system/string/os startup 유틸 사용
- `dart_framework/log/log.dart` — `Application.logWithType()`의 로그 타입에 사용
- `proto_socket` — agent Edge 등록 통신에서 사용하는 workspace 상위 path dependency
- `protobuf` / `fixnum` — `lib/oto/agent/**`의 generated protobuf 코드 런타임 의존성
- `resource_importer` — `lib/resources.resource_importer.dart` 생성 파일과 asset 임베딩 설정
- `protobuf` / `fixnum` — generated protobuf 코드 런타임 의존성
- `resource_importer` — `apps/runner/lib/resources.resource_importer.dart` 생성 파일과 asset 임베딩 설정
## 유지할 패턴
- 프로세스 실행은 `ProcessExecutor.start()` (스트리밍, stdout/stderr 실시간 수신) 또는 `ProcessExecutor.run()` (블로킹, 결과만 필요) 중 목적에 맞게 선택
- `dart_framework` API 사용 시 기존 import 패턴을 따른다
- 외부 의존성 ref 변경은 `pubspec.yaml`에서만 수행하고, 변경 후 `dart pub get` 및 `dart analyze`를 확인한다
- 외부 의존성 ref 변경은 각 `pubspec.yaml` 또는 `go.mod`에서 수행하고, 변경 후 패키지 갱신 및 `dart analyze` 또는 빌드 확인을 한다
- analyzer/lint 기준 변경은 기존 코드 전체에 영향을 줄 수 있으므로 `dart analyze` 결과와 필요한 수정 범위를 함께 확인한다
- generated protobuf lint 예외는 `analysis_options.yaml`의 analyzer exclude 또는 파일 생성 주석으로 관리한다
- 로컬에 `lib/framework/`를 되살리는 대신 필요한 OTO 로직은 `lib/oto/` 또는 `lib/cli/`의 해당 도메인에 둔다
- 로컬에 `lib/framework/`를 되살리는 대신 필요한 OTO 로직은 `apps/runner/lib/oto/` 또는 `apps/runner/lib/cli/`의 해당 도메인에 둔다
## 다른 도메인과의 경계
- **core**: `lib/oto/application.dart`는 OTO 오케스트레이터이며 외부 framework의 Application과 별개다
- **core**: `apps/runner/lib/oto/application.dart`는 OTO 오케스트레이터이며 외부 framework의 Application과 별개다
- **cli/scheduler**: isolate, process, OS startup 유틸을 소비하지만 스케줄러 정책은 scheduler 도메인에 둔다
- **command**: 커맨드들은 `ProcessExecutor`를 소비하지만 커맨드별 비즈니스 로직은 command 도메인에 둔다
- **agent**: `proto_socket`, `protobuf`, `fixnum` 의존성은 framework 도메인에서 관리하지만 Edge 등록 프로토콜과 agent 정책은 agent 도메인에 둔다

12
agent-ops/rules/project/domain/pipeline/rules.md
View file

@ -13,13 +13,13 @@ YAML에서 파싱된 `DataCommand` 리스트를 순차 실행하고, 조건 분
## 포함 경로
- `lib/oto/pipeline/` — 파이프라인 실행 엔진 전체
- `lib/oto/data/pipeline_data.dart` — workflow, 조건, 반복, switch 등 pipeline 데이터 모델
- `apps/runner/lib/oto/pipeline/` — 파이프라인 실행 엔진 전체
- `apps/runner/lib/oto/data/pipeline_data.dart` — workflow, 조건, 반복, switch 등 pipeline 데이터 모델
## 제외 경로
- `lib/oto/commands/` — 실제 커맨드 구현체 (pipeline은 dispatch만 한다)
- `lib/oto/core/` — 태그 치환·데이터 합성 (pipeline 이전 단계)
- `apps/runner/lib/oto/commands/` — 실제 커맨드 구현체 (pipeline은 dispatch만 한다)
- `apps/runner/lib/oto/core/` — 태그 치환·데이터 합성 (pipeline 이전 단계)
## 주요 구성 요소
@ -40,7 +40,7 @@ YAML에서 파싱된 `DataCommand` 리스트를 순차 실행하고, 조건 분
- 파이프라인 노드는 단일 책임: 흐름 제어만 한다, I/O는 커맨드에 위임
- 새 흐름 제어 유형은 `Pipeline*` 네이밍으로 추가
- 새 흐름 제어 유형은 `Pipeline.exeMap`에 등록하고, 필요한 데이터 모델은 `lib/oto/data/pipeline_data.dart`에 둔다
- 새 흐름 제어 유형은 `Pipeline.exeMap`에 등록하고, 필요한 데이터 모델은 `apps/runner/lib/oto/data/pipeline_data.dart`에 둔다
- 파이프라인 validate 단계에서 workflow task key, command ID 존재 여부, 하위 task 구조를 가능한 한 먼저 확인한다
- 조건식은 `PipelineCondition`의 type caster와 `Command.replaceTagValue()` 흐름을 유지한다
- pipeline 변경 후 `dart analyze`를 실행하고, if/foreach/while/switch/wait-until 중 영향을 받는 샘플 YAML 파싱 또는 실행 테스트를 확인한다
@ -50,7 +50,7 @@ YAML에서 파싱된 `DataCommand` 리스트를 순차 실행하고, 조건 분
- **command**: `Pipeline`이 `Command.byType()`을 호출하는 시점이 경계. 커맨드 내부 로직은 pipeline이 모른다
- **command data**: `DataCommand`와 커맨드 파라미터 모델은 command 도메인이고, workflow 흐름 모델인 `pipeline_data.dart`만 pipeline 도메인이다
- **core**: `DataComposer`가 YAML → `DataCommand` 변환을 마친 후 pipeline이 실행 시작
- **sample**: workflow 문법 변경 시 `assets/yaml/sample/02_*`~`05_*`와 README 흐름 제어 예시를 함께 점검
- **sample**: workflow 문법 변경 시 `apps/runner/assets/yaml/sample/02_*`~`05_*`와 README 흐름 제어 예시를 함께 점검
## 금지 사항

10
agent-ops/rules/project/domain/sample/rules.md
View file

@ -14,17 +14,17 @@ AI가 파이프라인 YAML을 작성하거나 검토할 때 가장 먼저 읽는
## 포함 경로
- `assets/yaml/sample/` — 카테고리별 샘플 YAML 파일
- `apps/runner/assets/yaml/sample/` — 카테고리별 샘플 YAML 파일
## 레거시 / 비사용 경로
- `assets/yaml/example/` — 현재 tracked 샘플 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
- `assets/templates/` — 현재 tracked 템플릿 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
- 루트/`assets/` 하위의 구형 테스트 YAML/XML (`build_*.yaml`, `slack_test.yaml`, `pipeline-test*.yaml`, `scheduler*.yaml`, `assets/config.xml`, `assets/example.yaml`)은 현재 형상과 맞지 않아 제거됨
- `apps/runner/assets/yaml/example/` — 현재 tracked 샘플 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
- `apps/runner/assets/templates/` — 현재 tracked 템플릿 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
- 루트/`apps/runner/assets/` 하위의 구형 테스트 YAML/XML (`build_*.yaml`, `slack_test.yaml`, `pipeline-test*.yaml`, `scheduler*.yaml`, `assets/config.xml`, `assets/example.yaml`)은 현재 형상과 맞지 않아 제거됨
## 제외 경로
- `lib/oto/data/` — 실제 파라미터 모델은 command 도메인
- `apps/runner/lib/oto/data/` — 실제 파라미터 모델은 command 도메인
## 주요 구성 요소

16
agent-ops/rules/project/domain/scheduler/rules.md
View file

@ -13,16 +13,16 @@ CLI의 `scheduler` 명령, OS별 실행 경로, isolate 기반 실행, 등록
## 포함 경로
- `lib/cli/commands/command_scheduler.dart` — `scheduler` CLI 명령 파싱과 진입점
- `lib/cli/commands/scheduler/` — 스케줄러 등록/해제/실행/OS별 구현
- `lib/cli/commands/scheduler/data/` — 스케줄러 설정 JSON 직렬화 모델
- `apps/runner/lib/cli/commands/command_scheduler.dart` — `scheduler` CLI 명령 파싱과 진입점
- `apps/runner/lib/cli/commands/scheduler/` — 스케줄러 등록/해제/실행/OS별 구현
- `apps/runner/lib/cli/commands/scheduler/data/` — 스케줄러 설정 JSON 직렬화 모델
## 제외 경로
- `lib/cli/cli.dart` — 일반 CLI 출력/명령 라우팅 (`cli` 도메인)
- `lib/cli/commands/command_exe.dart` — 파이프라인 실행 isolate 진입 (`cli` 도메인). 단, scheduler가 실행을 위임한다
- `lib/oto/pipeline/` — 실제 파이프라인 실행 흐름 (`pipeline` 도메인)
- `lib/oto/commands/` — 실제 커맨드 실행 (`command` 도메인)
- `apps/runner/lib/cli/cli.dart` — 일반 CLI 출력/명령 라우팅 (`cli` 도메인)
- `apps/runner/lib/cli/commands/command_exe.dart` — 파이프라인 실행 isolate 진입 (`cli` 도메인). 단, scheduler가 실행을 위임한다
- `apps/runner/lib/oto/pipeline/` — 실제 파이프라인 실행 흐름 (`pipeline` 도메인)
- `apps/runner/lib/oto/commands/` — 실제 커맨드 실행 (`command` 도메인)
## 주요 구성 요소
@ -47,7 +47,7 @@ CLI의 `scheduler` 명령, OS별 실행 경로, isolate 기반 실행, 등록
- **cli**: 일반 CLI 라우팅과 출력은 cli 도메인이다. scheduler 도메인은 `scheduler` 명령 이후의 등록/실행 정책을 담당한다
- **core**: YAML 파싱과 `Application.build()`는 core 도메인이다. scheduler는 실행 타이밍과 로그 파일을 준비해 위임한다
- **pipeline/command**: scheduler는 파이프라인과 커맨드를 직접 실행하지 않고 `CommandExe.executeScheduler()`를 통해 실행한다
- **sample**: scheduler YAML 예시는 `assets/yaml/sample/12_scheduler.yaml`에서 관리한다
- **sample**: scheduler YAML 예시는 `apps/runner/assets/yaml/sample/12_scheduler.yaml`에서 관리한다
## 금지 사항

145
agent-ops/rules/project/rules.md
View file

@ -6,41 +6,73 @@
## 프로젝트 개요
OTO CLI는 YAML 파일로 정의된 빌드/배포 파이프라인을 실행하는 Dart CLI 도구다.
Jenkins, FTP, Git, Slack/Mattermost, iOS/Flutter/Android 빌드 등 다양한 CI/CD 작업을 커맨드로 추상화하고 파이프라인 엔진이 순차 실행한다.
OTO는 YAML 파일로 정의된 빌드/배포 파이프라인을 실행하는 Dart runner에서 출발해, Flutter client와 Go core service를 함께 가진 모노레포형 CI/CD runner/control plane 제품이다.
Jenkins, FTP, Git, Slack/Mattermost, iOS/Flutter/Android 빌드 등 다양한 CI/CD 작업을 runner 커맨드로 추상화하고, 필요하면 OTO Server가 runner registry, bootstrap, job, log, artifact 상태를 소유한다.
## 실행 흐름
### 로컬 runner 실행
```text
apps/runner/bin/main.dart
-> CLI / CommandManager
-> Application
-> DataComposer # YAML + Jenkins env 파싱
-> Pipeline
-> Command.byType(CommandType) -> Command.execute(DataCommand)
```
bin/main.dart
└── Application (singleton)
└── DataComposer ← YAML + Jenkins env 파싱
└── Pipeline
└── Command.byType(CommandType) → Command.execute(DataCommand)
### Control Plane 실행
```text
services/core/cmd/oto-core/main.go
-> httpserver
-> runnerregistry / cicdstate
apps/client/lib/main.dart
-> oto_client_app
-> oto_console package
```
## 주요 구조
```
lib/
├── cli/ # CLI 레이어 (명령 파싱, 스케줄러 관리)
└── oto/
├── agent/ # OTO Edge agent 등록/통신
├── application.dart # 싱글턴 오케스트레이터, BuildType enum
├── commands/ # 커맨드 구현체 (카테고리별)
├── core/ # 태그 시스템, 데이터 합성, 정의 데이터
├── data/ # JSON 직렬화 데이터 모델
└── pipeline/ # 파이프라인 실행 엔진
```text
apps/
├── runner/ # Dart CLI runner/runtime
│ ├── bin/main.dart # runner CLI entrypoint
│ ├── lib/cli/ # CLI 레이어
│ ├── lib/oto/agent/ # OTO Server runner 등록/agent 실행
│ ├── lib/oto/application.dart # runner 오케스트레이터, BuildType enum
│ ├── lib/oto/commands/ # typed command 구현체
│ ├── lib/oto/core/ # 태그 시스템, 데이터 합성, 실행 컨텍스트
│ ├── lib/oto/data/ # JSON 직렬화 데이터 모델
│ ├── lib/oto/pipeline/ # 파이프라인 실행 엔진
│ └── assets/ # sample YAML, script, packaging asset
├── client/ # Flutter OTO client app
│ └── lib/src/app/ # app bootstrap/shell
services/
└── core/ # Go OTO Server
├── cmd/oto-core/ # server entrypoint
├── internal/httpserver/ # HTTP API
├── internal/cicdstate/ # job/execution/log/artifact state
└── internal/runnerregistry/ # runner registration state
packages/
└── flutter/oto_console/ # Flutter embeddable OTO console package
proto/ # OTO runner/server protobuf contract
```
> **참고**: `lib/framework/` 모듈이 제거되었습니다. 기존 기능은 `lib/oto/` 내부로 통합되었습니다.
> 현재 `dart_framework`는 외부 Git 의존성으로만 사용합니다.
> 참고: root `lib/` 기반 구조와 `lib/framework/` 모듈은 현재 구조가 아니다. runner 코드는 `apps/runner/lib/` 아래에 있고, `dart_framework`는 `apps/runner/pubspec.yaml`의 외부 Git 의존성으로만 사용한다.
## 기술 스택
- 언어: Dart (SDK >=3.2.3 <4.0.0)
- 의존성: dart_framework (커스텀), proto_socket (상위 `../proto-socket/dart` path dependency), http, json_annotation, cron, xml, protobuf/fixnum, resource_importer
- 코드 생성: json_serializable + build_runner (`dart run build_runner build`)
- runner: Dart SDK `>=3.8.0 <4.0.0`, `apps/runner/pubspec.yaml`
- client: Flutter/Dart SDK `^3.11.3`, `apps/client/pubspec.yaml`
- console package: Flutter/Dart SDK `^3.11.3`, `packages/flutter/oto_console/pubspec.yaml`
- core service: Go `1.26`, `services/core/go.mod`
- runner 주요 의존성: `dart_framework` Git dependency, `proto_socket` 상위 workspace path dependency, `http`, `json_annotation`, `yaml`, `cron`, `xml`, `protobuf`, `fixnum`, `resource_importer`
- client 주요 의존성: Flutter SDK, `agent_shell` 상위 workspace path dependency, `oto_console` local path dependency
- protobuf 생성: `make proto-go`, `make proto-dart`
- Dart 코드 생성: json_serializable + build_runner (`cd apps/runner && dart run build_runner build`)
## BuildType
@ -51,7 +83,7 @@ lib/
| `file` | 로컬 파일 경로에서 파이프라인 YAML 읽기 |
| `scheduler` | 스케줄러 데몬 모드 |
## 태그 시스템 (`lib/oto/core/tag_system.dart`)
## 태그 시스템 (`apps/runner/lib/oto/core/tag_system.dart`)
- **읽기 태그** `<!namespace.key>` — 런타임 저장소에서 값 치환
- **쓰기 태그** `<@namespace.key>` — 커맨드 결과를 property에 저장
@ -60,7 +92,7 @@ lib/
## 데이터 모델 컨벤션
- 모든 커맨드 파라미터는 `DataParam` (`lib/oto/data/base_data.dart`) 상속
- 모든 커맨드 파라미터는 `DataParam` (`apps/runner/lib/oto/data/base_data.dart`) 상속
- JSON 직렬화: `json_annotation` 사용, 생성 파일은 `*.g.dart`
- `CommandSpec` — 커맨드의 category, dataModel, samplePath 메타데이터
- `DataCommon` – Jenkins 환경 데이터 (workspace, job name, build number 등)
@ -68,13 +100,13 @@ lib/
## 새 커맨드 추가 절차
1. `lib/oto/data/*_data.dart`에 데이터 모델 정의 (`DataParam` 상속)
2. `lib/oto/commands/command.dart`의 `CommandType` enum에 값 추가
1. `apps/runner/lib/oto/data/*_data.dart`에 데이터 모델 정의 (`DataParam` 상속)
2. `apps/runner/lib/oto/commands/command.dart`의 `CommandType` enum에 값 추가
3. `Command` 상속하여 커맨드 클래스 구현
4. `Command.register(..., spec: CommandSpec(...))`에 구현체/데이터 모델/샘플 경로 등록
5. `lib/oto/commands/command_registry.dart`의 `registerAllCommands()`에 등록 함수 연결
6. 관련 `assets/yaml/sample/**` 샘플 갱신 필요 여부 확인
7. `@JsonSerializable` 클래스 추가/변경 시 `dart run build_runner build` 실행
5. `apps/runner/lib/oto/commands/command_registry.dart`의 `registerAllCommands()`에 등록 함수 연결
6. 관련 `apps/runner/assets/yaml/sample/**` 샘플 갱신 필요 여부 확인
7. `@JsonSerializable` 클래스 추가/변경 시 `cd apps/runner && dart run build_runner build` 실행
## 에러 처리
@ -86,7 +118,7 @@ lib/
- agent-ops 초기화, domain rule 생성, skill 생성, commit/push, agent-ops sync 계열 요청은 사용자가 명시적으로 요청한 경우에만 `agent-ops/skills/common/router.md`를 먼저 읽고 해당 `SKILL.md`를 따른다.
- 도메인 룰 갱신/검토 요청은 `agent-ops/skills/common/update-domain-rule/SKILL.md`를 따른다.
- 새 도메인 rule 생성이 필요한 경우 `agent-ops/skills/common/create-domain-rule/SKILL.md`를 따른다.
- YAML 작성 요청은 코드 분석보다 `sample` 도메인 rule과 `assets/yaml/sample/**`를 우선 참조한다.
- YAML 작성 요청은 코드 분석보다 `sample` 도메인 rule과 `apps/runner/assets/yaml/sample/**`를 우선 참조한다.
- 코드 변경 요청은 먼저 아래 도메인 매핑에서 해당 rule을 읽고, 변경 후 도메인 rule의 검증 기준을 따른다.
## 도메인 룰 로딩
@ -99,32 +131,39 @@ lib/
| 경로 패턴 | 도메인 | rules.md |
|----------|--------|----------|
| `bin/main.dart` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `lib/resources.resource_importer.dart` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `lib/oto/pipeline/**` | pipeline | `agent-ops/rules/project/domain/pipeline/rules.md` |
| `lib/oto/commands/**` | command | `agent-ops/rules/project/domain/command/rules.md` |
| `lib/oto/data/pipeline_data.dart` | pipeline | `agent-ops/rules/project/domain/pipeline/rules.md` |
| `lib/oto/data/**` | command | `agent-ops/rules/project/domain/command/rules.md` |
| `lib/cli/commands/command_agent.dart` | agent | `agent-ops/rules/project/domain/agent/rules.md` |
| `lib/cli/commands/scheduler/**` | scheduler | `agent-ops/rules/project/domain/scheduler/rules.md` |
| `lib/cli/commands/command_scheduler.dart` | scheduler | `agent-ops/rules/project/domain/scheduler/rules.md` |
| `lib/cli/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `lib/oto/agent/**` | agent | `agent-ops/rules/project/domain/agent/rules.md` |
| `lib/oto/application.dart` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `lib/oto/core/**` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `lib/oto/utils/**` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `assets/script/**/jenkins_env_params.*` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `assets/template/**` | command | `agent-ops/rules/project/domain/command/rules.md` |
| `assets/yaml/sample/**` | sample | `agent-ops/rules/project/domain/sample/rules.md` |
| `assets/package/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `assets/bin/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `assets/script/shell/oto_agent_bootstrap.sh` | agent | `agent-ops/rules/project/domain/agent/rules.md` |
| `assets/script/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `analysis_options.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `apps/runner/bin/main.dart` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `apps/runner/lib/resources.resource_importer.dart` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `apps/runner/lib/oto/pipeline/**` | pipeline | `agent-ops/rules/project/domain/pipeline/rules.md` |
| `apps/runner/lib/oto/commands/**` | command | `agent-ops/rules/project/domain/command/rules.md` |
| `apps/runner/lib/oto/data/pipeline_data.dart` | pipeline | `agent-ops/rules/project/domain/pipeline/rules.md` |
| `apps/runner/lib/oto/data/**` | command | `agent-ops/rules/project/domain/command/rules.md` |
| `apps/runner/lib/cli/commands/command_agent.dart` | agent | `agent-ops/rules/project/domain/agent/rules.md` |
| `apps/runner/lib/cli/commands/scheduler/**` | scheduler | `agent-ops/rules/project/domain/scheduler/rules.md` |
| `apps/runner/lib/cli/commands/command_scheduler.dart` | scheduler | `agent-ops/rules/project/domain/scheduler/rules.md` |
| `apps/runner/lib/cli/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `apps/runner/lib/oto/agent/**` | agent | `agent-ops/rules/project/domain/agent/rules.md` |
| `apps/runner/lib/oto/application.dart` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `apps/runner/lib/oto/core/**` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `apps/runner/lib/oto/utils/**` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `apps/runner/assets/script/**/jenkins_env_params.*` | core | `agent-ops/rules/project/domain/core/rules.md` |
| `apps/runner/assets/template/**` | command | `agent-ops/rules/project/domain/command/rules.md` |
| `apps/runner/assets/yaml/sample/**` | sample | `agent-ops/rules/project/domain/sample/rules.md` |
| `apps/runner/assets/package/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `apps/runner/assets/bin/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` | agent | `agent-ops/rules/project/domain/agent/rules.md` |
| `apps/runner/assets/script/**` | cli | `agent-ops/rules/project/domain/cli/rules.md` |
| `apps/runner/pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `apps/runner/analysis_options.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `apps/client/pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `apps/client/analysis_options.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `packages/flutter/oto_console/pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `services/core/go.mod` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
| `proto/**` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
`test/**`는 별도 도메인으로 고정하지 않는다. 테스트 변경 시 검증 대상 production 경로의 domain rule을 읽고, 여러 도메인을 검증하는 테스트면 관련 domain rule을 함께 읽는다.
`apps/client/lib/**`, `packages/flutter/oto_console/lib/**`, `services/core/internal/**`처럼 아직 dedicated domain rule이 없는 구현 경로는 기존 domain rule로 단정하지 않는다. 해당 경로의 동작 변경 전에는 관련 roadmap Milestone 또는 domain rule 갱신/생성을 먼저 확인한다.
## 스킬 라우팅
| 요청 키워드 | 수행 방법 |

15
agent-roadmap/phase/independent-control-plane/PHASE.md
View file

@ -18,6 +18,21 @@ OTO를 iop Edge에 직접 붙는 domain agent가 아니라, 독립 실행 가능
- [완료] 독립 Control Plane 분리 마이그레이션
- 경로: `agent-roadmap/archive/phase/independent-control-plane/milestones/control-plane-separation-migration.md`
- 요약: iop에 구현된 OTO 등록/heartbeat/bootstrap 구조를 OTO 전용 Server/Runner 계약으로 이관하고, repo를 `apps/runner`, `apps/client`, `services/core` monorepo로 전환한다.
- [진행중] agent-ops 규칙 모노레포 정합화
- 경로: `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- 요약: 프로젝트 규칙과 domain rule을 현재 `apps/runner`, `apps/client`, `services/core`, `packages/flutter/oto_console` 구조에 맞게 최신화한다.
- [계획] runner 출력 경계 분리
- 경로: `agent-roadmap/phase/independent-control-plane/milestones/runner-output-boundary.md`
- 요약: pipeline/core 실행 로직의 CLI 출력 직접 의존을 output/progress port와 adapter 구조로 분리한다.
- [계획] oto_console 계약 경계 정리
- 경로: `agent-roadmap/phase/independent-control-plane/milestones/oto-console-contract-boundary.md`
- 요약: Flutter console contract와 shell 구현의 순환형 의존을 contract/model 소유 경계로 정리한다.
- [계획] core server 모듈 경계 정리
- 경로: `agent-roadmap/phase/independent-control-plane/milestones/core-server-boundary-cleanup.md`
- 요약: Go core service의 HTTP routing, handler, DTO, clock 의존을 모듈 경계별로 분리한다.
- [계획] workspace 메타데이터와 재현성 정리
- 경로: `agent-roadmap/phase/independent-control-plane/milestones/workspace-metadata-reproducibility.md`
- 요약: lockfile, local test 문서, package metadata, 배포 템플릿의 추적/설명 기준을 정리한다.
## Phase 경계

41
agent-roadmap/phase/independent-control-plane/milestones/core-server-boundary-cleanup.md Normal file
View file

@ -0,0 +1,41 @@
# Milestone: core server 모듈 경계 정리
## 상태
[계획]
## 목표
Go core service의 HTTP server, DTO 변환, runner/job handler, 시간 의존성을 모듈 경계별로 분리해 유지보수성과 테스트 가능성을 높인다.
## 범위
- `services/core/internal/httpserver/server.go`의 라우팅, handler, DTO 변환 책임을 작은 파일 또는 내부 모듈로 분리한다.
- runner registry, job/execution, log/artifact handler가 독립적으로 읽히도록 경계를 만든다.
- `cicdstate.Store`의 clock 주입과 entity timestamp 생성 경로를 일관되게 만든다.
## 범위 제외
- OTO Server API endpoint 의미 변경
- 저장소 backend 교체
- 인증/권한 정책 추가
## 구현 잠금
- 상태: 해제
- 결정 필요: 없음
## 작업 컨텍스트
- `services/core/internal/httpserver/server.go`는 route 등록, 수동 subrouter, 여러 handler와 DTO 변환이 한 파일에 집중되어 있다.
- `services/core/internal/cicdstate/store.go`는 `Store`에 clock을 주입하지만 일부 entity 생성 메서드는 직접 `time.Now()`를 호출한다.
- 표준선: behavior는 유지하고 파일/책임 경계와 clock 주입 일관성만 정리한다.
## 기능
### Epic: [http] server module boundary
- [ ] [routes] route 등록과 subrouter 구성을 handler 구현에서 분리한다.
- [ ] [handlers] runner, job/execution, log/artifact handler 책임을 기능별 파일 또는 내부 모듈로 나눈다.
- [ ] [dto] HTTP DTO 변환과 domain state 조작 경계를 명확히 한다.
- [ ] [clock] timestamp 생성이 `Store`의 clock 주입 경로를 일관되게 사용하도록 정리한다. 검증: `make core-test`가 통과한다.

41
agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md Normal file
View file

@ -0,0 +1,41 @@
# Milestone: agent-ops 규칙 모노레포 정합화
## 상태
[진행중]
## 목표
프로젝트 규칙과 domain rule을 현재 `apps/runner`, `apps/client`, `services/core`, `packages/flutter/oto_console` 모노레포 구조에 맞게 최신화한다.
## 범위
- `agent-ops/rules/project/rules.md`의 오래된 root `lib/` 중심 설명을 현재 모노레포 경로로 갱신한다.
- Dart SDK, package dependency, 테스트 target 설명을 실제 workspace 구조와 맞춘다.
- domain rule의 책임 경계와 파일 경로 예시가 현재 코드 위치를 가리키도록 정리한다.
## 범위 제외
- 사람용 공개 가이드로 관리되는 tracked `docs/`의 대규모 재작성
- domain rule의 철학 또는 agent-ops 구조 변경
- 코드 구조 변경
## 구현 잠금
- 상태: 해제
- 결정 필요: 없음
## 작업 컨텍스트
- 현재 프로젝트 규칙은 root `lib/` 구조, 오래된 Dart SDK 기준, path dependency 설명을 일부 유지한다.
- 실제 구현은 `apps/runner`, `apps/client`, `services/core`, `packages/flutter/oto_console`에 분산되어 있다.
- 코드 변경 전 domain rule 확인 규칙이 있으므로, 규칙 문서의 stale path는 후속 구현 판단을 흐릴 수 있다.
## 기능
### Epic: [rules] monorepo rule alignment
- [x] [project-map] 프로젝트 구조, 패키지 경계, 주요 entrypoint 설명을 현재 모노레포 경로로 갱신한다.
- [x] [sdk-deps] Dart/Flutter/Go dependency와 SDK 설명을 실제 package 기준으로 정리한다.
- [ ] [domain-paths] domain rule의 파일 경로 예시와 책임 경계 설명이 현재 코드 위치와 맞는지 검토해 갱신한다.
- [ ] [test-rules] local test rule과 smoke 문서가 모노레포 target 이름과 일치하는지 확인한다.

40
agent-roadmap/phase/independent-control-plane/milestones/oto-console-contract-boundary.md Normal file
View file

@ -0,0 +1,40 @@
# Milestone: oto_console 계약 경계 정리
## 상태
[계획]
## 목표
Flutter `oto_console` 패키지에서 contract와 shell 구현의 순환형 의존을 풀고, 외부 소비자가 의존할 수 있는 UI 계약 모델을 분리한다.
## 범위
- `OtoConsoleContract`가 shell 구현 파일을 import하지 않도록 contract model을 분리한다.
- navigation section, shell tab, contract option처럼 외부 API가 되는 타입의 소유 위치를 명확히 한다.
- 기존 package public export와 client 동작은 유지한다.
## 범위 제외
- console UI 디자인 개편
- Flutter client routing 전면 재구성
- Server API 계약 변경
## 구현 잠금
- 상태: 해제
- 결정 필요: 없음
## 작업 컨텍스트
- `packages/flutter/oto_console/lib/src/oto_console_contract.dart`는 `oto_console_shell.dart`의 `OtoConsoleSection`에 의존하고, shell 파일은 contract를 다시 import한다.
- 표준선: 공용 contract/model 타입은 shell 구현보다 안쪽의 neutral model 파일이 소유하고, shell은 이를 소비한다.
## 기능
### Epic: [contract] console contract boundary
- [ ] [model-owner] `OtoConsoleSection` 등 공용 UI 계약 타입의 소유 파일을 contract/model 계층으로 이동한다.
- [ ] [shell-dep] shell 구현이 contract/model을 소비하도록 dependency 방향을 단방향으로 정리한다.
- [ ] [exports] 기존 public export와 client import 경로가 깨지지 않도록 package export를 조정한다.
- [ ] [verify] Flutter package/client analyzer와 widget 또는 unit test가 통과한다.

41
agent-roadmap/phase/independent-control-plane/milestones/runner-output-boundary.md Normal file
View file

@ -0,0 +1,41 @@
# Milestone: runner 출력 경계 분리
## 상태
[계획]
## 목표
pipeline/core 실행 로직이 CLI 출력 구현에 직접 의존하지 않도록 output/progress port를 도입하고, CLI는 해당 port의 adapter로만 연결한다.
## 범위
- pipeline 실행 코드에서 `CLI.println`과 `Application.instance.printBuildStep` 직접 호출을 분리한다.
- core data composition 경로가 CLI color/printer 구현에 묶이지 않도록 출력 계약을 정리한다.
- 기존 CLI 사용자 출력은 adapter를 통해 동일한 의미로 유지한다.
## 범위 제외
- 로그 포맷 전면 개편
- OTO Server remote log streaming 재설계
- YAML pipeline 문법 변경
## 구현 잠금
- 상태: 해제
- 결정 필요: 없음
## 작업 컨텍스트
- `apps/runner/lib/oto/pipeline/pipeline_exe.dart`와 `pipeline_foreach.dart`는 CLI 출력 계층을 직접 import한다.
- `apps/runner/lib/oto/core/data_composer.dart`는 CLI color/printer 형태를 core 동작으로 노출한다.
- 표준선: domain 실행 로직은 출력 port를 호출하고, CLI/UI/server는 port adapter를 제공한다.
## 기능
### Epic: [output] output port boundary
- [ ] [port] runner 실행 progress와 일반 출력에 필요한 최소 output port 계약을 정의한다.
- [ ] [pipeline] pipeline domain이 CLI 구현체 대신 output port를 사용하도록 분리한다. 검증: runner analyze와 pipeline 관련 테스트가 통과한다.
- [ ] [core] data composition 경로의 printer/color 의존을 output port 또는 domain-neutral 계약으로 정리한다.
- [ ] [cli-adapter] 기존 CLI 출력 의미를 유지하는 adapter를 연결한다. 검증: CLI smoke 출력이 회귀하지 않는다.

43
agent-roadmap/phase/independent-control-plane/milestones/workspace-metadata-reproducibility.md Normal file
View file

@ -0,0 +1,43 @@
# Milestone: workspace 메타데이터와 재현성 정리
## 상태
[계획]
## 목표
모노레포의 lockfile, local test 문서, package metadata, 배포 템플릿 상태를 정리해 새 작업과 배포 검증이 일관되게 재현되도록 만든다.
## 범위
- `.gitignore`의 `pubspec.lock`과 `agent-test/local/` ignore 정책을 현재 추적 파일과 맞춘다.
- Flutter client와 runner package description, web manifest, Chocolatey package placeholder를 제품 상태에 맞게 갱신한다.
- package별 lockfile 추적 또는 비추적 기준을 명시한다.
## 범위 제외
- 배포 채널 추가
- package versioning 정책 전면 개편
- secret 또는 private 설정 문서화
## 구현 잠금
- 상태: 잠금
- 결정 필요:
- [ ] Flutter/Dart application package의 `pubspec.lock`을 추적할지, library package는 계속 비추적할지 결정한다.
## 작업 컨텍스트
- `.gitignore`는 모든 `pubspec.lock`을 ignore해 application lockfile도 기본적으로 추적되지 않는다.
- `.gitignore`는 `agent-test/local/`을 ignore하지만, 현재 local test rule과 smoke 문서는 일부 tracked 상태다.
- `apps/client`와 `apps/runner` metadata에는 Flutter/Dart 기본 템플릿 문구가 남아 있다.
- `apps/runner/assets/package/chocolatey/_TODO.txt`는 배포 템플릿 후속 정리 필요 신호로 남아 있다.
## 기능
### Epic: [metadata] workspace metadata
- [ ] [lock-policy] application/library package별 `pubspec.lock` 추적 기준을 확정하고 `.gitignore`를 그 기준에 맞춘다.
- [ ] [test-docs] `agent-test/local/` ignore 정책과 tracked smoke 문서 운영 방식이 충돌하지 않도록 정리한다.
- [ ] [descriptions] Flutter client, web manifest, runner package description의 기본 템플릿 문구를 제품 설명으로 갱신한다.
- [ ] [package-todo] Chocolatey package placeholder의 처리 방향을 결정하고 배포 템플릿 상태를 문서 또는 파일 구조에 반영한다.

16
agent-roadmap/phase/message-based-build-agent/PHASE.md
View file

@ -20,18 +20,24 @@ OTO를 generic remote shell이 아니라 build/deploy 전용 runner로 노출하
- [완료] 원격 실행 생명주기
- 경로: `agent-roadmap/archive/phase/message-based-build-agent/milestones/remote-run-lifecycle.md`
- 요약: OTO Server가 소유하는 원격 실행, 로그, artifact, cancel, status, self-update 생명주기를 완성한다.
- [계획] agent 등록 capability 경계 정리
- 경로: `agent-roadmap/phase/message-based-build-agent/milestones/agent-registration-capability-boundary.md`
- 요약: agent 등록 경로가 command catalog를 직접 해석하지 않도록 capability provider port와 command adapter로 분리한다.
- [계획] runner 검증 기준 정합화
- 경로: `agent-roadmap/phase/message-based-build-agent/milestones/runner-verification-baseline.md`
- 요약: 현재 OTO Server/Runner 경로 기준으로 runner test, root analyzer, smoke 문서의 기본 검증 범위를 일치시킨다.
## 완료 리뷰
- 상태: 요청됨
- 상태: 보류
- 요청일: 2026-06-06
- 완료 근거:
- 보류 근거:
- `agent 메시지 프로토콜` Milestone이 완료되어 archive 경로로 정리되어 있다.
- `원격 실행 생명주기` Milestone이 완료되어 archive 경로로 정리되어 있다.
- `agent 등록 capability 경계 정리`, `runner 검증 기준 정합화` Milestone이 새 활성 계획으로 추가되어 Phase 완료 후보가 아니다.
- 리뷰 필요:
- [ ] 사용자가 Phase 완료 결과를 확인했다
- [ ] Phase archive 이동을 승인했다
- 리뷰 코멘트: 하위 Milestone이 모두 `[완료]` 상태이며, 다음 활성 Milestone 후보는 현재 Phase 안에 없다.
- [ ] 신규 계획 Milestone 완료 후 Phase 완료 리뷰를 다시 요청한다
- 리뷰 코멘트: 하위 완료 Milestone의 근거는 유지하되, 신규 정리 Milestone이 추가되어 archive 이동은 보류한다.
## Phase 경계

41
agent-roadmap/phase/message-based-build-agent/milestones/agent-registration-capability-boundary.md Normal file
View file

@ -0,0 +1,41 @@
# Milestone: agent 등록 capability 경계 정리
## 상태
[계획]
## 목표
`oto agent` 등록 경로가 command catalog를 직접 해석하지 않도록 분리하고, build/deploy runner가 노출할 capability 목록을 agent/runner 경계의 명시적 port로 제공한다.
## 범위
- `apps/runner`의 agent registration client가 command domain 구현체를 직접 import하는 경로를 제거한다.
- command catalog 기반 capability 산출은 command domain adapter가 담당하고, agent 등록 경로는 adapter 계약만 소비한다.
- 기존 OTO Server registration payload와 smoke 동작은 유지한다.
## 범위 제외
- 메시지 프로토콜 필드 확장
- generic remote shell capability 추가
- iop Edge 직접 연결 경로 복원
## 구현 잠금
- 상태: 해제
- 결정 필요: 없음
## 작업 컨텍스트
- Agent domain rule은 agent 영역에서 command catalog 직접 실행/해석을 금지한다.
- 현재 `apps/runner/lib/oto/agent/edge_registration_client.dart`는 command registry를 import하고 `Command.catalogRows`를 직접 읽어 기본 command type 목록을 만든다.
- 표준선: agent 등록 경로는 capability provider port를 받고, command domain은 해당 port의 adapter 구현으로 연결한다.
## 기능
### Epic: [boundary] agent-command capability boundary
- [ ] [agent-port] agent 등록에 필요한 capability provider 계약과 기본값 주입 지점을 정의한다.
- [ ] [command-adapter] command catalog 조회와 `registerAllCommands()` 호출을 command domain adapter 뒤로 이동한다.
- [ ] [registration] 기존 registration payload 의미를 유지하면서 agent registration client가 adapter 계약만 소비하도록 바꾼다. 검증: runner registration 관련 테스트와 OTO Server connection smoke가 통과한다.
- [ ] [rule-evidence] 변경 후 agent domain rule 위반 import가 남아 있지 않은지 확인한다.

41
agent-roadmap/phase/message-based-build-agent/milestones/runner-verification-baseline.md Normal file
View file

@ -0,0 +1,41 @@
# Milestone: runner 검증 기준 정합화
## 상태
[계획]
## 목표
현재 제품 경로인 독립 OTO Server/Runner 기준에 맞게 runner 테스트, root analyzer, smoke 문서의 기본 검증 범위를 정합화한다.
## 범위
- `make runner-test`와 `make test`가 현재 필수 smoke 범위와 충돌하지 않도록 정리한다.
- 폐기된 iop Edge 직접 연결 smoke를 기본 검증에서 분리하거나 명시적 legacy 검증으로 격리한다.
- root `dart analyze`를 깨뜨리는 임시 Dart 파일의 위치 또는 분석 범위를 정리한다.
## 범위 제외
- iop Edge 직접 연결 기능 복원
- 신규 remote execution 기능 추가
- CI provider별 matrix 재설계
## 구현 잠금
- 상태: 해제
- 결정 필요: 없음
## 작업 컨텍스트
- `agent-test/local/agent-smoke.md`는 legacy iop smoke를 필수 agent smoke에서 제외하지만, `Makefile`의 `runner-test`는 전체 `dart test`를 실행한다.
- `apps/runner/test/oto_iop_connection_smoke_test.dart`는 현재 iop Edge가 허용하지 않는 `agent_kind: "oto-agent"`를 사용해 기본 test suite를 실패시킨다.
- root `test_regist.dart`는 root package 경계 밖 import로 `dart analyze`를 실패시킨다.
## 기능
### Epic: [baseline] verification baseline
- [ ] [test-scope] `Makefile`의 runner/root 테스트 target과 `agent-test/local` smoke 문서의 필수 검증 범위를 일치시킨다.
- [ ] [legacy-iop] iop Edge 직접 연결 smoke를 기본 runner test에서 제외하거나 legacy 전용 명령으로 명시한다. 검증: `make runner-test`가 현재 필수 검증 기준으로 통과한다.
- [ ] [root-analyze] root analyzer를 깨뜨리는 임시 Dart 파일을 제거, 이동 또는 분석 제외 범위로 정리한다. 검증: root 분석 명령이 실패하지 않는다.
- [ ] [smoke-evidence] 필수 agent smoke 명령과 제외된 legacy smoke의 상태가 문서와 명령 양쪽에서 같은 의미를 갖도록 확인한다.

368
agent-task/archive/2026/06/m-ops-rule-monorepo-alignment/01_domain_rules/code_review_local_G04_0.log Normal file
View file

@ -0,0 +1,368 @@
<!-- task=m-ops-rule-monorepo-alignment/01_domain_rules plan=0 tag=RULES -->
# Code Review Reference - RULES
> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
> The task is NOT complete until every implementation-owned section below is filled in.
> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
> Fill implementation-owned sections, then stop with active files in place and report ready for review.
> If implementation is blocked by a user-only decision, user-owned external environment prerequisite, or scope conflict, fill `사용자 리뷰 요청` with evidence and stop with active files in place; code-review decides whether to write `USER_REVIEW.md`. Evidence gaps that a follow-up agent can close by rerunning commands or collecting artifacts are normal follow-up issues, not user-review blockers by themselves.
> Do not ask the user directly, present choices in chat, or call `request_user_input` during implementation; record the needed decision in `사용자 리뷰 요청` and stop for code-review.
> Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, `코드리뷰 전용 체크리스트`) is review-agent-only, even after compaction/resume.
> Follow the ownership table at the bottom of this file for which sections you own.
## 개요
date=2026-06-07
task=m-ops-rule-monorepo-alignment/01_domain_rules, plan=0, tag=RULES
## Roadmap Targets
- Milestone: `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- Task ids:
- `domain-paths`: domain rule의 파일 경로 예시와 책임 경계 설명이 현재 코드 위치와 맞는지 검토해 갱신한다.
- Completion mode: check-on-pass
## 이 파일을 읽는 리뷰 에이전트에게
> **[REVIEW AGENT ONLY]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.
각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.
1. 판정을 append한다.
2. `CODE_REVIEW-local-G04.md` -> `code_review_local_G04_N.log`, `PLAN-local-G04.md` -> `plan_local_G04_M.log`로 아카이브한다.
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/m-ops-rule-monorepo-alignment/01_domain_rules/`로 이동한다. WARN/FAIL이면 user-review gate를 확인한 뒤 다음 active plan/review 파일 또는 `USER_REVIEW.md`를 작성한다. `USER_REVIEW.md`가 사용자 결정으로 완료/PASS 해소되면 code-review가 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log` 작성 후 archive 이동한다.
4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
---
## 구현 항목별 완료 여부
| 항목 | 완료 여부 |
|------|---------|
| [RULES-1] Runner domain path prefixes | [x] |
| [RULES-2] Framework and non-runner boundary wording | [x] |
## 구현 체크리스트
- [x] `agent-ops/rules/project/domain/**/rules.md`의 root `lib/`, `bin/main.dart`, root `assets/` 경로를 현재 `apps/runner/...` 경로로 갱신하고, legacy/external exception은 명시한다.
- [x] `framework` rule이 runner/client/console/core service의 package/toolchain/proto 경계만 담당하도록 설명을 정리하고, dedicated domain rule이 없는 구현 경로를 기존 domain으로 단정하지 않는다.
- [x] `rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain` 결과의 남은 항목이 모두 의도된 legacy/external exception인지 확인한다.
- [x] `git diff --check`를 실행해 markdown whitespace 오류가 없는지 확인한다.
- [x] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.
## 코드리뷰 전용 체크리스트
> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.
- [x] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
- [x] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
- [x] active `CODE_REVIEW-*-G??.md`를 `code_review_local_G04_N.log`로 아카이브한다.
- [x] active `PLAN-*-G??.md`를 `plan_local_G04_M.log`로 아카이브한다.
- [x] `.gitignore`의 Agent-Ops 관리 block이 `agent-task/**/*.md`와 `agent-task/**/*.log`를 unignore하고 `agent-roadmap/current.md`를 ignore하는지 확인한다.
- [x] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
- [x] PASS이면 active task 디렉터리 `agent-task/m-ops-rule-monorepo-alignment/01_domain_rules/`를 `agent-task/archive/YYYY/MM/m-ops-rule-monorepo-alignment/01_domain_rules/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
- [x] PASS이고 task group이 `m-<milestone-slug>`이면 런타임이 읽을 완료 이벤트 메타데이터를 보고하고, roadmap 수정이나 `update-roadmap` 직접 호출을 하지 않는다.
- [x] PASS split 작업이면 이동 후 빈 active parent `agent-task/m-ops-rule-monorepo-alignment/`를 제거하거나, 남은 sibling/file이 있어 유지했다고 확인한다.
- [ ] WARN/FAIL이고 user-review gate가 트리거되지 않았으면 다음 active `PLAN-local-G04.md`와 `CODE_REVIEW-local-G04.md`를 작성하고 `complete.log`를 작성하지 않는다.
- [ ] USER_REVIEW이면 `agent-ops/skills/common/code-review/templates/user-review-template.md` 기준으로 `USER_REVIEW.md`를 작성하고 active `PLAN-*.md`, `CODE_REVIEW-*.md`, `complete.log`를 남기지 않는다.
- [ ] USER_REVIEW가 사용자 결정으로 완료/PASS 해소되면 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log`를 작성한 뒤 task directory를 archive로 이동한다.
## 계획 대비 변경 사항
- 없음. 계획된 모든 8개 domain rule 파일을 정확히 수정 완료하였습니다.
## 주요 설계 결정
- framework 도메인 규칙을 모노레포에 알맞게 runner, client, console, core service 의 패키지 선언(pubspec.yaml, go.mod), 린터 설정(analysis_options.yaml), proto 정의 경로로 확장 및 정리하고 비-runner 구현 경로(dedicated domain rule이 정의되지 않은 client, console, core internal 소스)에 대한 규칙을 억지로 기존 러너 도메인에 단정 짓지 않도록 명시했습니다.
## 사용자 리뷰 요청
- 상태: 없음
- 사유 유형: 없음
- 결정 필요: 없음
- 차단 근거: 없음
- 실행한 검증/명령: 없음
- 자동 후속 불가 이유: 없음
- 재개 조건: 없음
## 리뷰어를 위한 체크포인트
- domain rule의 stale root path가 현재 모노레포 경로로 바뀌었는지 확인한다.
- `framework` rule이 비-runner 구현 경로의 behavior rule처럼 과장되지 않았는지 확인한다.
- 남은 root path가 legacy/external exception으로 명시되어 있는지 확인한다.
## 검증 결과
### RULES-1 중간 검증
```bash
$ rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain
agent-ops/rules/project/domain/agent/rules.md:16:- `apps/runner/lib/cli/commands/command_agent.dart` — `agent run --config <path>` CLI 표면과 오류 출력
agent-ops/rules/project/domain/agent/rules.md:17:- `apps/runner/lib/oto/agent/` — agent config, runner, Edge 등록 client, generated protobuf 런타임 코드
agent-ops/rules/project/domain/agent/rules.md:18:- `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` — Linux agent 다운로드, config 생성, background 실행 bootstrap
agent-ops/rules/project/domain/agent/rules.md:22:- `apps/runner/lib/cli/cli.dart` — 일반 CLI 출력/초기화 (`cli` 도메인)
agent-ops/rules/project/domain/agent/rules.md:23:- `apps/runner/lib/cli/commands/command_catalog.dart` — command catalog 출력 (`cli` 도메인)
agent-ops/rules/project/domain/agent/rules.md:24:- `apps/runner/lib/cli/commands/command_validate.dart` — pipeline YAML 검증 (`cli`/`core` 도메인)
agent-ops/rules/project/domain/agent/rules.md:25:- `apps/runner/lib/cli/commands/command_scheduler.dart` — scheduler 명령 진입 (`scheduler` 도메인)
agent-ops/rules/project/domain/agent/rules.md:26:- `apps/runner/lib/oto/application.dart` — pipeline build 오케스트레션 (`core` 도메인)
agent-ops/rules/project/domain/agent/rules.md:27:- `apps/runner/lib/oto/pipeline/` — pipeline workflow 실행 (`pipeline` 도메인)
agent-ops/rules/project/domain/agent/rules.md:28:- `apps/runner/lib/oto/commands/` — pipeline에서 호출되는 커맨드 구현체 (`command` 도메인)
agent-ops/rules/project/domain/agent/rules.md:29:- `apps/runner/assets/script/`의 기타 build/package helper — CLI/배포 보조 asset (`cli` 도메인)
agent-ops/rules/project/domain/agent/rules.md:42:- `apps/runner/lib/oto/agent/iop/*.pb*.dart` — `iop/runtime.proto` generated protobuf 코드
agent-ops/rules/project/domain/agent/rules.md:43:- `apps/runner/lib/oto/agent/google/protobuf/*.pb*.dart` — `google/protobuf/struct.proto` generated protobuf 코드
agent-ops/rules/project/domain/agent/rules.md:61:- **cli**: `apps/runner/bin/main.dart` 등록과 일반 출력/스타일은 cli 도메인이다. `CommandAgent` 내부의 agent subcommand 정책부터는 agent 도메인이다.
agent-ops/rules/project/domain/agent/rules.md:65:- **sample**: agent config YAML은 pipeline sample YAML이 아니다. `apps/runner/assets/yaml/sample/**`에 agent bootstrap config를 섞지 않는다.
agent-ops/rules/project/domain/cli/rules.md:16:- `apps/runner/bin/main.dart` — 외부 `dart_framework` 앱 래퍼를 통해 CLI를 초기화하는 실행 진입점
agent-ops/rules/project/domain/cli/rules.md:17:- `apps/runner/lib/cli/cli.dart` — CLI 루트 객체, 출력/스타일 처리
agent-ops/rules/project/domain/cli/rules.md:18:- `apps/runner/lib/cli/printer.dart` — OS별 콘솔 출력과 ANSI 스타일 처리
agent-ops/rules/project/domain/cli/rules.md:19:- `apps/runner/lib/cli/cli_style.dart` — 콘솔 색상/스타일 enum
agent-ops/rules/project/domain/cli/rules.md:20:- `apps/runner/lib/cli/commands/command_base.dart` — CLI 커맨드 공통 베이스
agent-ops/rules/project/domain/cli/rules.md:21:- `apps/runner/lib/cli/commands/command_manager.dart` — CLI 커맨드 라우팅
agent-ops/rules/project/domain/cli/rules.md:22:- `apps/runner/lib/cli/commands/command_const.dart` — OS별 설치 경로 상수
agent-ops/rules/project/domain/cli/rules.md:23:- `apps/runner/lib/cli/commands/command_exe.dart` — `exe` 명령과 `Application.build()` 진입
agent-ops/rules/project/domain/cli/rules.md:24:- `apps/runner/lib/cli/commands/command_catalog.dart` — 등록된 OTO 커맨드 catalog 출력 명령
agent-ops/rules/project/domain/cli/rules.md:25:- `apps/runner/lib/cli/commands/command_validate.dart` — YAML 구조/의미 검증 명령
agent-ops/rules/project/domain/cli/rules.md:26:- `apps/runner/lib/cli/commands/command_template.dart` — 템플릿 출력
agent-ops/rules/project/domain/cli/rules.md:27:- `apps/runner/lib/cli/commands/command_start.dart` — 시작/중지 커맨드
agent-ops/rules/project/domain/cli/rules.md:28:- `apps/runner/lib/cli/commands/command_install.dart` — 설치/제거 명령
agent-ops/rules/project/domain/cli/rules.md:29:- `apps/runner/lib/cli/commands/install/` — PATH 등록 등 설치 보조 로직
agent-ops/rules/project/domain/cli/rules.md:30:- `apps/runner/lib/resources.resource_importer.dart` — 설치/패키징 asset용 `resource_importer` 생성 파일
agent-ops/rules/project/domain/cli/rules.md:31:- `apps/runner/assets/package/` — 배포/패키징 보조 파일
agent-ops/rules/project/domain/cli/rules.md:32:- `apps/runner/assets/bin/` — 설치 또는 패키징에 포함되는 보조 바이너리
agent-ops/rules/project/domain/cli/rules.md:33:- `apps/runner/assets/script/` — 빌드/패키징/실행 보조 스크립트. Jenkins env helper는 core 경계도 함께 확인
agent-ops/rules/project/domain/cli/rules.md:37:- `apps/runner/lib/oto/` — 비즈니스 로직·파이프라인 엔진 (cli는 진입만 담당)
agent-ops/rules/project/domain/cli/rules.md:38:- `apps/runner/lib/cli/commands/command_agent.dart` — OTO Edge agent 실행 명령 (`agent` 도메인)
agent-ops/rules/project/domain/cli/rules.md:39:- `apps/runner/lib/cli/commands/command_scheduler.dart` — scheduler 명령 파싱과 등록/실행 진입점 (`scheduler` 도메인)
agent-ops/rules/project/domain/cli/rules.md:40:- `apps/runner/lib/cli/commands/scheduler/` — 스케줄러 실행/등록/OS별 백그라운드 처리 (`scheduler` 도메인)
agent-ops/rules/project/domain/cli/rules.md:41:- `apps/runner/lib/oto/agent/` — agent 설정/등록/Edge 통신 (`agent` 도메인)
agent-ops/rules/project/domain/cli/rules.md:42:- `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` — agent 설치/실행 bootstrap (`agent` 도메인)
agent-ops/rules/project/domain/cli/rules.md:43:- `apps/runner/assets/template/` — 커맨드 실행 중 사용하는 템플릿 (`command` 도메인)
agent-ops/rules/project/domain/cli/rules.md:60:- `apps/runner/bin/main.dart` — CLI 초기화 시 등록할 top-level 명령 목록을 정의
agent-ops/rules/project/domain/cli/rules.md:65:- top-level 명령 등록은 `apps/runner/bin/main.dart`의 `CLI.initialize(..., [Command...])` 목록에서 관리
agent-ops/rules/project/domain/cli/rules.md:70:- CLI 변경 후 `dart analyze`를 실행하고, CLI 진입 변경이면 최소 `dart run apps/runner/bin/main.dart` 수준의 스모크 실행 가능 여부를 확인
agent-ops/rules/project/domain/cli/rules.md:78:- **scheduler**: `CommandScheduler`, `apps/runner/lib/cli/commands/command_scheduler.dart`, `apps/runner/lib/cli/commands/scheduler/**`는 scheduler 도메인이다. 일반 CLI 변경에서 scheduler 내부 동작을 함께 수정하지 않는다
agent-ops/rules/project/domain/cli/rules.md:79:- **framework**: `apps/runner/bin/main.dart`는 외부 framework Application을 소비하지만 framework 의존성 자체는 framework 도메인에서 다룬다
agent-ops/rules/project/domain/command/rules.md:16:- `apps/runner/lib/oto/commands/` — 커맨드 구현체 (카테고리별 하위 폴더)
agent-ops/rules/project/domain/command/rules.md:17:- `apps/runner/lib/oto/data/` — 커맨드 파라미터 데이터 모델 (`*_data.dart`, `*.g.dart`). `pipeline_data.dart`는 pipeline 도메인
agent-ops/rules/project/domain/command/rules.md:18:- `apps/runner/assets/template/` — 커맨드 실행 중 사용하는 템플릿 파일
agent-ops/rules/project/domain/command/rules.md:22:- `apps/runner/lib/oto/pipeline/` — 실행 흐름 제어 (커맨드 dispatch 이전)
agent-ops/rules/project/domain/command/rules.md:23:- `apps/runner/lib/oto/core/` — 태그 치환, 데이터 합성 (커맨드 실행 이전)
agent-ops/rules/project/domain/command/rules.md:24:- `apps/runner/lib/oto/data/pipeline_data.dart` — workflow/조건/반복 데이터 모델 (`pipeline` 도메인)
agent-ops/rules/project/domain/command/rules.md:25:- `apps/runner/assets/yaml/sample/` — YAML 사용 예시 (`sample` 도메인)
agent-ops/rules/project/domain/command/rules.md:44:| build | `apps/runner/lib/oto/commands/build/` | `apps/runner/lib/oto/data/build_data.dart` |
agent-ops/rules/project/domain/command/rules.md:45:| file | `apps/runner/lib/oto/commands/file/` | `apps/runner/lib/oto/data/file_data.dart` |
agent-ops/rules/project/domain/command/rules.md:46:| git / GitHub | `apps/runner/lib/oto/commands/git/` | `apps/runner/lib/oto/data/git_data.dart` |
agent-ops/rules/project/domain/command/rules.md:47:| ftp / web | `apps/runner/lib/oto/commands/ftp/`, `apps/runner/lib/oto/commands/web/` | `apps/runner/lib/oto/data/network_data.dart` |
agent-ops/rules/project/domain/command/rules.md:48:| notification | `apps/runner/lib/oto/commands/notification/`, `apps/runner/lib/oto/utils/mattermost/` | `apps/runner/lib/oto/data/notification_data.dart` |
agent-ops/rules/project/domain/command/rules.md:49:| jira / jenkins | `apps/runner/lib/oto/commands/jira/`, `apps/runner/lib/oto/commands/jenkins/` | `apps/runner/lib/oto/data/integration_data.dart`, `apps/runner/lib/oto/data/jira_data.dart` |
agent-ops/rules/project/domain/command/rules.md:50:| infra / external tool | `apps/runner/lib/oto/commands/aws/`, `docker/`, `gradle/`, `infra/`, `proto/` | `apps/runner/lib/oto/data/infra_data.dart`, `apps/runner/lib/oto/data/util_data.dart` |
agent-ops/rules/project/domain/command/rules.md:51:| shell / process / util | `apps/runner/lib/oto/commands/shell/`, `process/`, `util/` | `apps/runner/lib/oto/data/util_data.dart` |
agent-ops/rules/project/domain/command/rules.md:57:| `apps/runner/assets/template/index.html` | iOS publish HTML 템플릿 |
agent-ops/rules/project/domain/command/rules.md:58:| `apps/runner/assets/template/manifest.plist` | iOS publish manifest 템플릿 |
agent-ops/rules/project/domain/command/rules.md:71:- 커맨드 추가/파라미터 변경 시 관련 `apps/runner/assets/yaml/sample/**`와 README 커맨드 목록 갱신 필요 여부를 확인한다
agent-ops/rules/project/domain/command/rules.md:72:- 커맨드가 `apps/runner/assets/template/**`를 읽거나 출력 형식에 의존하면 템플릿 경로와 placeholder 계약을 함께 확인한다
agent-ops/rules/project/domain/core/rules.md:16:- `apps/runner/lib/oto/application.dart` — 싱글턴 오케스트레이터 (BuildType enum, 빌드 진입점)
agent-ops/rules/project/domain/core/rules.md:17:- `apps/runner/lib/oto/core/` — 태그 시스템, 데이터 합성, 정의 데이터
agent-ops/rules/project/domain/core/rules.md:18:- `apps/runner/lib/oto/utils/` — 공통 유틸리티 (Mattermost 등 재사용 헬퍼)
agent-ops/rules/project/domain/core/rules.md:19:- `apps/runner/assets/script/batch/jenkins_env_params.bat` — Jenkins 환경 변수 합성에 쓰이는 Windows helper script
agent-ops/rules/project/domain/core/rules.md:20:- `apps/runner/assets/script/shell/jenkins_env_params.sh` — Jenkins 환경 변수 합성 helper script
agent-ops/rules/project/domain/core/rules.md:24:- `apps/runner/lib/oto/pipeline/` — 실행 흐름 (core 처리 이후)
agent-ops/rules/project/domain/core/rules.md:25:- `apps/runner/lib/oto/commands/` — 커맨드 구현체 (core 결과물을 소비)
agent-ops/rules/project/domain/core/rules.md:26:- `apps/runner/lib/oto/agent/` — OTO Edge agent 설정/등록/통신 (`agent` 도메인)
agent-ops/rules/project/domain/core/rules.md:27:- `apps/runner/assets/script/`의 빌드/패키징 보조 스크립트 — CLI/배포 보조 asset이며 core가 직접 해석하지 않는다
agent-ops/rules/project/domain/framework/rules.md:11:현재 프로젝트에는 `lib/framework/` 모듈이 없다.
agent-ops/rules/project/domain/framework/rules.md:13:단, 전용 도메인 규칙(dedicated domain rule)이 아직 존재하지 않는 `apps/client/lib/**`, `packages/flutter/oto_console/lib/**`, `services/core/internal/**` 등의 구현 코드가 가진 구체적인 비즈니스 동작 규칙은 이 framework 도메인이나 기존 runner 도메인 규칙으로 무리하게 확장하여 단정하지 않고, 추후 별도 도메인 규칙 생성 또는 후속 milestone 작업을 통해 정리한다.
agent-ops/rules/project/domain/framework/rules.md:27:- `lib/framework/` — 제거된 로컬 모듈. 새로 만들지 않는다
agent-ops/rules/project/domain/framework/rules.md:28:- `apps/runner/lib/oto/` — OTO 비즈니스 로직 (framework 위에서 동작)
agent-ops/rules/project/domain/framework/rules.md:29:- `apps/runner/lib/cli/` — CLI 레이어 (framework를 소비)
agent-ops/rules/project/domain/framework/rules.md:33:- `dart_framework/core/application.dart` — `apps/runner/bin/main.dart`에서 앱 진입 래퍼로 사용
agent-ops/rules/project/domain/framework/rules.md:40:- `resource_importer` — `apps/runner/lib/resources.resource_importer.dart` 생성 파일과 asset 임베딩 설정
agent-ops/rules/project/domain/framework/rules.md:49:- 로컬에 `lib/framework/`를 되살리는 대신 필요한 OTO 로직은 `apps/runner/lib/oto/` 또는 `apps/runner/lib/cli/`의 해당 도메인에 둔다
agent-ops/rules/project/domain/framework/rules.md:53:- **core**: `apps/runner/lib/oto/application.dart`는 OTO 오케스트레이터이며 외부 framework의 Application과 별개다
agent-ops/rules/project/domain/framework/rules.md:60:- `lib/framework/` 디렉터리를 새로 만들지 않는다
agent-ops/rules/project/domain/pipeline/rules.md:16:- `apps/runner/lib/oto/pipeline/` — 파이프라인 실행 엔진 전체
agent-ops/rules/project/domain/pipeline/rules.md:17:- `apps/runner/lib/oto/data/pipeline_data.dart` — workflow, 조건, 반복, switch 등 pipeline 데이터 모델
agent-ops/rules/project/domain/pipeline/rules.md:21:- `apps/runner/lib/oto/commands/` — 실제 커맨드 구현체 (pipeline은 dispatch만 한다)
agent-ops/rules/project/domain/pipeline/rules.md:22:- `apps/runner/lib/oto/core/` — 태그 치환·데이터 합성 (pipeline 이전 단계)
agent-ops/rules/project/domain/pipeline/rules.md:43:- 새 흐름 제어 유형은 `Pipeline.exeMap`에 등록하고, 필요한 데이터 모델은 `apps/runner/lib/oto/data/pipeline_data.dart`에 둔다
agent-ops/rules/project/domain/pipeline/rules.md:53:- **sample**: workflow 문법 변경 시 `apps/runner/assets/yaml/sample/02_*`~`05_*`와 README 흐름 제어 예시를 함께 점검
agent-ops/rules/project/domain/sample/rules.md:17:- `apps/runner/assets/yaml/sample/` — 카테고리별 샘플 YAML 파일
agent-ops/rules/project/domain/sample/rules.md:21:- `apps/runner/assets/yaml/example/` — 현재 tracked 샘플 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
agent-ops/rules/project/domain/sample/rules.md:22:- `apps/runner/assets/templates/` — 현재 tracked 템플릿 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
agent-ops/rules/project/domain/sample/rules.md:23:- 루트/`apps/runner/assets/` 하위의 구형 테스트 YAML/XML (`build_*.yaml`, `slack_test.yaml`, `pipeline-test*.yaml`, `scheduler*.yaml`, `assets/config.xml`, `assets/example.yaml`)은 현재 형상과 맞지 않아 제거됨
agent-ops/rules/project/domain/sample/rules.md:27:- `apps/runner/lib/oto/data/` — 실제 파라미터 모델은 command 도메인
agent-ops/rules/project/domain/scheduler/rules.md:16:- `apps/runner/lib/cli/commands/command_scheduler.dart` — `scheduler` CLI 명령 파싱과 진입점
agent-ops/rules/project/domain/scheduler/rules.md:17:- `apps/runner/lib/cli/commands/scheduler/` — 스케줄러 등록/해제/실행/OS별 구현
agent-ops/rules/project/domain/scheduler/rules.md:18:- `apps/runner/lib/cli/commands/scheduler/data/` — 스케줄러 설정 JSON 직렬화 모델
agent-ops/rules/project/domain/scheduler/rules.md:22:- `apps/runner/lib/cli/cli.dart` — 일반 CLI 출력/명령 라우팅 (`cli` 도메인)
agent-ops/rules/project/domain/scheduler/rules.md:23:- `apps/runner/lib/cli/commands/command_exe.dart` — 파이프라인 실행 isolate 진입 (`cli` 도메인). 단, scheduler가 실행을 위임한다
agent-ops/rules/project/domain/scheduler/rules.md:24:- `apps/runner/lib/oto/pipeline/` — 실제 파이프라인 실행 흐름 (`pipeline` 도메인)
agent-ops/rules/project/domain/scheduler/rules.md:25:- `apps/runner/lib/oto/commands/` — 실제 커맨드 실행 (`command` 도메인)
agent-ops/rules/project/domain/scheduler/rules.md:50:- **sample**: scheduler YAML 예시는 `apps/runner/assets/yaml/sample/12_scheduler.yaml`에서 관리한다
```
### RULES-2 중간 검증
```bash
$ rg --sort path -n 'pubspec.yaml|analysis_options.yaml|go.mod|proto/' agent-ops/rules/project/domain/framework/rules.md agent-ops/rules/project/rules.md
agent-ops/rules/project/domain/framework/rules.md:17:- `apps/runner/pubspec.yaml` — runner Dart dependency와 `dart_framework` Git 의존성 선언
agent-ops/rules/project/domain/framework/rules.md:18:- `apps/runner/analysis_options.yaml` — runner Dart analyzer/lint 기준
agent-ops/rules/project/domain/framework/rules.md:19:- `apps/client/pubspec.yaml` — Flutter client dependency 선언
agent-ops/rules/project/domain/framework/rules.md:20:- `apps/client/analysis_options.yaml` — Flutter client analyzer/lint 기준
agent-ops/rules/project/domain/framework/rules.md:21:- `packages/flutter/oto_console/pubspec.yaml` — embeddable console package dependency 선언
agent-ops/rules/project/domain/framework/rules.md:22:- `services/core/go.mod` — Go core service dependency 선언
agent-ops/rules/project/domain/framework/rules.md:23:- `proto/` — runner/server protobuf 계약 정의
agent-ops/rules/project/domain/framework/rules.md:46:- 외부 의존성 ref 변경은 각 `pubspec.yaml` 또는 `go.mod`에서 수행하고, 변경 후 패키지 갱신 및 `dart analyze` 또는 빌드 확인을 한다
agent-ops/rules/project/domain/framework/rules.md:48:- generated protobuf lint 예외는 `analysis_options.yaml`의 analyzer exclude 또는 파일 생성 주석으로 관리한다
agent-ops/rules/project/rules.md:61:proto/ # OTO runner/server protobuf contract
agent-ops/rules/project/rules.md:64:> 참고: root `lib/` 기반 구조와 `lib/framework/` 모듈은 현재 구조가 아니다. runner 코드는 `apps/runner/lib/` 아래에 있고, `dart_framework`는 `apps/runner/pubspec.yaml`의 외부 Git 의존성으로만 사용한다.
agent-ops/rules/project/rules.md:68:- runner: Dart SDK `>=3.8.0 <4.0.0`, `apps/runner/pubspec.yaml`
agent-ops/rules/project/rules.md:69:- client: Flutter/Dart SDK `^3.11.3`, `apps/client/pubspec.yaml`
agent-ops/rules/project/rules.md:70:- console package: Flutter/Dart SDK `^3.11.3`, `packages/flutter/oto_console/pubspec.yaml`
agent-ops/rules/project/rules.md:71:- core service: Go `1.26`, `services/core/go.mod`
agent-ops/rules/project/rules.md:155:| `apps/runner/pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
agent-ops/rules/project/rules.md:156:| `apps/runner/analysis_options.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
agent-ops/rules/project/rules.md:157:| `apps/client/pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
agent-ops/rules/project/rules.md:158:| `apps/client/analysis_options.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
agent-ops/rules/project/rules.md:159:| `packages/flutter/oto_console/pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
agent-ops/rules/project/rules.md:160:| `services/core/go.mod` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
agent-ops/rules/project/rules.md:161:| `proto/**` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
```
### 최종 검증
```bash
$ rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain
agent-ops/rules/project/domain/agent/rules.md:16:- `apps/runner/lib/cli/commands/command_agent.dart` — `agent run --config <path>` CLI 표면과 오류 출력
agent-ops/rules/project/domain/agent/rules.md:17:- `apps/runner/lib/oto/agent/` — agent config, runner, Edge 등록 client, generated protobuf 런타임 코드
agent-ops/rules/project/domain/agent/rules.md:18:- `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` — Linux agent 다운로드, config 생성, background 실행 bootstrap
agent-ops/rules/project/domain/agent/rules.md:22:- `apps/runner/lib/cli/cli.dart` — 일반 CLI 출력/초기화 (`cli` 도메인)
agent-ops/rules/project/domain/agent/rules.md:23:- `apps/runner/lib/cli/commands/command_catalog.dart` — command catalog 출력 (`cli` 도메인)
agent-ops/rules/project/domain/agent/rules.md:24:- `apps/runner/lib/cli/commands/command_validate.dart` — pipeline YAML 검증 (`cli`/`core` 도메인)
agent-ops/rules/project/domain/agent/rules.md:25:- `apps/runner/lib/cli/commands/command_scheduler.dart` — scheduler 명령 진입 (`scheduler` 도메인)
agent-ops/rules/project/domain/agent/rules.md:26:- `apps/runner/lib/oto/application.dart` — pipeline build 오케스트레션 (`core` 도메인)
agent-ops/rules/project/domain/agent/rules.md:27:- `apps/runner/lib/oto/pipeline/` — pipeline workflow 실행 (`pipeline` 도메인)
agent-ops/rules/project/domain/agent/rules.md:28:- `apps/runner/lib/oto/commands/` — pipeline에서 호출되는 커맨드 구현체 (`command` 도메인)
agent-ops/rules/project/domain/agent/rules.md:29:- `apps/runner/assets/script/`의 기타 build/package helper — CLI/배포 보조 asset (`cli` 도메인)
agent-ops/rules/project/domain/agent/rules.md:42:- `apps/runner/lib/oto/agent/iop/*.pb*.dart` — `iop/runtime.proto` generated protobuf 코드
agent-ops/rules/project/domain/agent/rules.md:43:- `apps/runner/lib/oto/agent/google/protobuf/*.pb*.dart` — `google/protobuf/struct.proto` generated protobuf 코드
agent-ops/rules/project/domain/agent/rules.md:61:- **cli**: `apps/runner/bin/main.dart` 등록과 일반 출력/스타일은 cli 도메인이다. `CommandAgent` 내부의 agent subcommand 정책부터는 agent 도메인이다.
agent-ops/rules/project/domain/agent/rules.md:65:- **sample**: agent config YAML은 pipeline sample YAML이 아니다. `apps/runner/assets/yaml/sample/**`에 agent bootstrap config를 섞지 않는다.
agent-ops/rules/project/domain/cli/rules.md:16:- `apps/runner/bin/main.dart` — 외부 `dart_framework` 앱 래퍼를 통해 CLI를 초기화하는 실행 진입점
agent-ops/rules/project/domain/cli/rules.md:17:- `apps/runner/lib/cli/cli.dart` — CLI 루트 객체, 출력/스타일 처리
agent-ops/rules/project/domain/cli/rules.md:18:- `apps/runner/lib/cli/printer.dart` — OS별 콘솔 출력과 ANSI 스타일 처리
agent-ops/rules/project/domain/cli/rules.md:19:- `apps/runner/lib/cli/cli_style.dart` — 콘솔 색상/스타일 enum
agent-ops/rules/project/domain/cli/rules.md:20:- `apps/runner/lib/cli/commands/command_base.dart` — CLI 커맨드 공통 베이스
agent-ops/rules/project/domain/cli/rules.md:21:- `apps/runner/lib/cli/commands/command_manager.dart` — CLI 커맨드 라우팅
agent-ops/rules/project/domain/cli/rules.md:22:- `apps/runner/lib/cli/commands/command_const.dart` — OS별 설치 경로 상수
agent-ops/rules/project/domain/cli/rules.md:23:- `apps/runner/lib/cli/commands/command_exe.dart` — `exe` 명령과 `Application.build()` 진입
agent-ops/rules/project/domain/cli/rules.md:24:- `apps/runner/lib/cli/commands/command_catalog.dart` — 등록된 OTO 커맨드 catalog 출력 명령
agent-ops/rules/project/domain/cli/rules.md:25:- `apps/runner/lib/cli/commands/command_validate.dart` — YAML 구조/의미 검증 명령
agent-ops/rules/project/domain/cli/rules.md:26:- `apps/runner/lib/cli/commands/command_template.dart` — 템플릿 출력
agent-ops/rules/project/domain/cli/rules.md:27:- `apps/runner/lib/cli/commands/command_start.dart` — 시작/중지 커맨드
agent-ops/rules/project/domain/cli/rules.md:28:- `apps/runner/lib/cli/commands/command_install.dart` — 설치/제거 명령
agent-ops/rules/project/domain/cli/rules.md:29:- `apps/runner/lib/cli/commands/install/` — PATH 등록 등 설치 보조 로직
agent-ops/rules/project/domain/cli/rules.md:30:- `apps/runner/lib/resources.resource_importer.dart` — 설치/패키징 asset용 `resource_importer` 생성 파일
agent-ops/rules/project/domain/cli/rules.md:31:- `apps/runner/assets/package/` — 배포/패키징 보조 파일
agent-ops/rules/project/domain/cli/rules.md:32:- `apps/runner/assets/bin/` — 설치 또는 패키징에 포함되는 보조 바이너리
agent-ops/rules/project/domain/cli/rules.md:33:- `apps/runner/assets/script/` — 빌드/패키징/실행 보조 스크립트. Jenkins env helper는 core 경계도 함께 확인
agent-ops/rules/project/domain/cli/rules.md:37:- `apps/runner/lib/oto/` — 비즈니스 로직·파이프라인 엔진 (cli는 진입만 담당)
agent-ops/rules/project/domain/cli/rules.md:38:- `apps/runner/lib/cli/commands/command_agent.dart` — OTO Edge agent 실행 명령 (`agent` 도메인)
agent-ops/rules/project/domain/cli/rules.md:39:- `apps/runner/lib/cli/commands/command_scheduler.dart` — scheduler 명령 파싱과 등록/실행 진입점 (`scheduler` 도메인)
agent-ops/rules/project/domain/cli/rules.md:40:- `apps/runner/lib/cli/commands/scheduler/` — 스케줄러 실행/등록/OS별 백그라운드 처리 (`scheduler` 도메인)
agent-ops/rules/project/domain/cli/rules.md:41:- `apps/runner/lib/oto/agent/` — agent 설정/등록/Edge 통신 (`agent` 도메인)
agent-ops/rules/project/domain/cli/rules.md:42:- `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` — agent 설치/실행 bootstrap (`agent` 도메인)
agent-ops/rules/project/domain/cli/rules.md:43:- `apps/runner/assets/template/` — 커맨드 실행 중 사용하는 템플릿 (`command` 도메인)
agent-ops/rules/project/domain/cli/rules.md:60:- `apps/runner/bin/main.dart` — CLI 초기화 시 등록할 top-level 명령 목록을 정의
agent-ops/rules/project/domain/cli/rules.md:65:- top-level 명령 등록은 `apps/runner/bin/main.dart`의 `CLI.initialize(..., [Command...])` 목록에서 관리
agent-ops/rules/project/domain/cli/rules.md:70:- CLI 변경 후 `dart analyze`를 실행하고, CLI 진입 변경이면 최소 `dart run apps/runner/bin/main.dart` 수준의 스모크 실행 가능 여부를 확인
agent-ops/rules/project/domain/cli/rules.md:78:- **scheduler**: `CommandScheduler`, `apps/runner/lib/cli/commands/command_scheduler.dart`, `apps/runner/lib/cli/commands/scheduler/**`는 scheduler 도메인이다. 일반 CLI 변경에서 scheduler 내부 동작을 함께 수정하지 않는다
agent-ops/rules/project/domain/cli/rules.md:79:- **framework**: `apps/runner/bin/main.dart`는 외부 framework Application을 소비하지만 framework 의존성 자체는 framework 도메인에서 다룬다
agent-ops/rules/project/domain/command/rules.md:16:- `apps/runner/lib/oto/commands/` — 커맨드 구현체 (카테고리별 하위 폴더)
agent-ops/rules/project/domain/command/rules.md:17:- `apps/runner/lib/oto/data/` — 커맨드 파라미터 데이터 모델 (`*_data.dart`, `*.g.dart`). `pipeline_data.dart`는 pipeline 도메인
agent-ops/rules/project/domain/command/rules.md:18:- `apps/runner/assets/template/` — 커맨드 실행 중 사용하는 템플릿 파일
agent-ops/rules/project/domain/command/rules.md:22:- `apps/runner/lib/oto/pipeline/` — 실행 흐름 제어 (커맨드 dispatch 이전)
agent-ops/rules/project/domain/command/rules.md:23:- `apps/runner/lib/oto/core/` — 태그 치환, 데이터 합성 (커맨드 실행 이전)
agent-ops/rules/project/domain/command/rules.md:24:- `apps/runner/lib/oto/data/pipeline_data.dart` — workflow/조건/반복 데이터 모델 (`pipeline` 도메인)
agent-ops/rules/project/domain/command/rules.md:25:- `apps/runner/assets/yaml/sample/` — YAML 사용 예시 (`sample` 도메인)
agent-ops/rules/project/domain/command/rules.md:44:| build | `apps/runner/lib/oto/commands/build/` | `apps/runner/lib/oto/data/build_data.dart` |
agent-ops/rules/project/domain/command/rules.md:45:| file | `apps/runner/lib/oto/commands/file/` | `apps/runner/lib/oto/data/file_data.dart` |
agent-ops/rules/project/domain/command/rules.md:46:| git / GitHub | `apps/runner/lib/oto/commands/git/` | `apps/runner/lib/oto/data/git_data.dart` |
agent-ops/rules/project/domain/command/rules.md:47:| ftp / web | `apps/runner/lib/oto/commands/ftp/`, `apps/runner/lib/oto/commands/web/` | `apps/runner/lib/oto/data/network_data.dart` |
agent-ops/rules/project/domain/command/rules.md:48:| notification | `apps/runner/lib/oto/commands/notification/`, `apps/runner/lib/oto/utils/mattermost/` | `apps/runner/lib/oto/data/notification_data.dart` |
agent-ops/rules/project/domain/command/rules.md:49:| jira / jenkins | `apps/runner/lib/oto/commands/jira/`, `apps/runner/lib/oto/commands/jenkins/` | `apps/runner/lib/oto/data/integration_data.dart`, `apps/runner/lib/oto/data/jira_data.dart` |
agent-ops/rules/project/domain/command/rules.md:50:| infra / external tool | `apps/runner/lib/oto/commands/aws/`, `docker/`, `gradle/`, `infra/`, `proto/` | `apps/runner/lib/oto/data/infra_data.dart`, `apps/runner/lib/oto/data/util_data.dart` |
agent-ops/rules/project/domain/command/rules.md:51:| shell / process / util | `apps/runner/lib/oto/commands/shell/`, `process/`, `util/` | `apps/runner/lib/oto/data/util_data.dart` |
agent-ops/rules/project/domain/command/rules.md:57:| `apps/runner/assets/template/index.html` | iOS publish HTML 템플릿 |
agent-ops/rules/project/domain/command/rules.md:58:| `apps/runner/assets/template/manifest.plist` | iOS publish manifest 템플릿 |
agent-ops/rules/project/domain/command/rules.md:71:- 커맨드 추가/파라미터 변경 시 관련 `apps/runner/assets/yaml/sample/**`와 README 커맨드 목록 갱신 필요 여부를 확인한다
agent-ops/rules/project/domain/command/rules.md:72:- 커맨드가 `apps/runner/assets/template/**`를 읽거나 출력 형식에 의존하면 템플릿 경로와 placeholder 계약을 함께 확인한다
agent-ops/rules/project/domain/core/rules.md:16:- `apps/runner/lib/oto/application.dart` — 싱글턴 오케스트레이터 (BuildType enum, 빌드 진입점)
agent-ops/rules/project/domain/core/rules.md:17:- `apps/runner/lib/oto/core/` — 태그 시스템, 데이터 합성, 정의 데이터
agent-ops/rules/project/domain/core/rules.md:18:- `apps/runner/lib/oto/utils/` — 공통 유틸리티 (Mattermost 등 재사용 헬퍼)
agent-ops/rules/project/domain/core/rules.md:19:- `apps/runner/assets/script/batch/jenkins_env_params.bat` — Jenkins 환경 변수 합성에 쓰이는 Windows helper script
agent-ops/rules/project/domain/core/rules.md:20:- `apps/runner/assets/script/shell/jenkins_env_params.sh` — Jenkins 환경 변수 합성 helper script
agent-ops/rules/project/domain/core/rules.md:24:- `apps/runner/lib/oto/pipeline/` — 실행 흐름 (core 처리 이후)
agent-ops/rules/project/domain/core/rules.md:25:- `apps/runner/lib/oto/commands/` — 커맨드 구현체 (core 결과물을 소비)
agent-ops/rules/project/domain/core/rules.md:26:- `apps/runner/lib/oto/agent/` — OTO Edge agent 설정/등록/통신 (`agent` 도메인)
agent-ops/rules/project/domain/core/rules.md:27:- `apps/runner/assets/script/`의 빌드/패키징 보조 스크립트 — CLI/배포 보조 asset이며 core가 직접 해석하지 않는다
agent-ops/rules/project/domain/framework/rules.md:11:현재 프로젝트에는 `lib/framework/` 모듈이 없다.
agent-ops/rules/project/domain/framework/rules.md:13:단, 전용 도메인 규칙(dedicated domain rule)이 아직 존재하지 않는 `apps/client/lib/**`, `packages/flutter/oto_console/lib/**`, `services/core/internal/**` 등의 구현 코드가 가진 구체적인 비즈니스 동작 규칙은 이 framework 도메인이나 기존 runner 도메인 규칙으로 무리하게 확장하여 단정하지 않고, 추후 별도 도메인 규칙 생성 또는 후속 milestone 작업을 통해 정리한다.
agent-ops/rules/project/domain/framework/rules.md:27:- `lib/framework/` — 제거된 로컬 모듈. 새로 만들지 않는다
agent-ops/rules/project/domain/framework/rules.md:28:- `apps/runner/lib/oto/` — OTO 비즈니스 로직 (framework 위에서 동작)
agent-ops/rules/project/domain/framework/rules.md:29:- `apps/runner/lib/cli/` — CLI 레이어 (framework를 소비)
agent-ops/rules/project/domain/framework/rules.md:33:- `dart_framework/core/application.dart` — `apps/runner/bin/main.dart`에서 앱 진입 래퍼로 사용
agent-ops/rules/project/domain/framework/rules.md:40:- `resource_importer` — `apps/runner/lib/resources.resource_importer.dart` 생성 파일과 asset 임베딩 설정
agent-ops/rules/project/domain/framework/rules.md:49:- 로컬에 `lib/framework/`를 되살리는 대신 필요한 OTO 로직은 `apps/runner/lib/oto/` 또는 `apps/runner/lib/cli/`의 해당 도메인에 둔다
agent-ops/rules/project/domain/framework/rules.md:53:- **core**: `apps/runner/lib/oto/application.dart`는 OTO 오케스트레이터이며 외부 framework의 Application과 별개다
agent-ops/rules/project/domain/framework/rules.md:60:- `lib/framework/` 디렉터리를 새로 만들지 않는다
agent-ops/rules/project/domain/pipeline/rules.md:16:- `apps/runner/lib/oto/pipeline/` — 파이프라인 실행 엔진 전체
agent-ops/rules/project/domain/pipeline/rules.md:17:- `apps/runner/lib/oto/data/pipeline_data.dart` — workflow, 조건, 반복, switch 등 pipeline 데이터 모델
agent-ops/rules/project/domain/pipeline/rules.md:21:- `apps/runner/lib/oto/commands/` — 실제 커맨드 구현체 (pipeline은 dispatch만 한다)
agent-ops/rules/project/domain/pipeline/rules.md:22:- `apps/runner/lib/oto/core/` — 태그 치환·데이터 합성 (pipeline 이전 단계)
agent-ops/rules/project/domain/pipeline/rules.md:43:- 새 흐름 제어 유형은 `Pipeline.exeMap`에 등록하고, 필요한 데이터 모델은 `apps/runner/lib/oto/data/pipeline_data.dart`에 둔다
agent-ops/rules/project/domain/pipeline/rules.md:53:- **sample**: workflow 문법 변경 시 `apps/runner/assets/yaml/sample/02_*`~`05_*`와 README 흐름 제어 예시를 함께 점검
agent-ops/rules/project/domain/sample/rules.md:17:- `apps/runner/assets/yaml/sample/` — 카테고리별 샘플 YAML 파일
agent-ops/rules/project/domain/sample/rules.md:21:- `apps/runner/assets/yaml/example/` — 현재 tracked 샘플 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
agent-ops/rules/project/domain/sample/rules.md:22:- `apps/runner/assets/templates/` — 현재 tracked 템플릿 파일은 없으며 샘플 작성 기준으로 사용하지 않는다
agent-ops/rules/project/domain/sample/rules.md:23:- 루트/`apps/runner/assets/` 하위의 구형 테스트 YAML/XML (`build_*.yaml`, `slack_test.yaml`, `pipeline-test*.yaml`, `scheduler*.yaml`, `assets/config.xml`, `assets/example.yaml`)은 현재 형상과 맞지 않아 제거됨
agent-ops/rules/project/domain/sample/rules.md:27:- `apps/runner/lib/oto/data/` — 실제 파라미터 모델은 command 도메인
agent-ops/rules/project/domain/scheduler/rules.md:16:- `apps/runner/lib/cli/commands/command_scheduler.dart` — `scheduler` CLI 명령 파싱과 진입점
agent-ops/rules/project/domain/scheduler/rules.md:17:- `apps/runner/lib/cli/commands/scheduler/` — 스케줄러 등록/해제/실행/OS별 구현
agent-ops/rules/project/domain/scheduler/rules.md:18:- `apps/runner/lib/cli/commands/scheduler/data/` — 스케줄러 설정 JSON 직렬화 모델
agent-ops/rules/project/domain/scheduler/rules.md:22:- `apps/runner/lib/cli/cli.dart` — 일반 CLI 출력/명령 라우팅 (`cli` 도메인)
agent-ops/rules/project/domain/scheduler/rules.md:23:- `apps/runner/lib/cli/commands/command_exe.dart` — 파이프라인 실행 isolate 진입 (`cli` 도메인). 단, scheduler가 실행을 위임한다
agent-ops/rules/project/domain/scheduler/rules.md:24:- `apps/runner/lib/oto/pipeline/` — 실제 파이프라인 실행 흐름 (`pipeline` 도메인)
agent-ops/rules/project/domain/scheduler/rules.md:25:- `apps/runner/lib/oto/commands/` — 실제 커맨드 실행 (`command` 도메인)
agent-ops/rules/project/domain/scheduler/rules.md:50:- **sample**: scheduler YAML 예시는 `apps/runner/assets/yaml/sample/12_scheduler.yaml`에서 관리한다
$ git diff --check
(exit code: 0, no output)
```
---
> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
> If anything is blank, go back and fill it in before saving this file.
> Leave review-agent-only sections unchanged.
## 코드리뷰 결과
- 종합 판정: PASS
- 차원별 평가
- correctness: Pass
- completeness: Pass
- test coverage: Pass
- API contract: Pass
- code quality: Pass
- plan deviation: Pass
- verification trust: Pass
- 발견된 문제
- Nit: `agent-ops/rules/project/domain/command/rules.md:50`의 command 하위 경로 일부가 `docker/`, `gradle/`처럼 축약되어 있어 리뷰 중 전체 `apps/runner/lib/oto/commands/...` 경로로 직접 보정했다. 기능/API 영향 없음.
- 리뷰 검증
- `rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain`: 남은 항목은 `apps/runner/...` 또는 명시된 legacy/external exception으로 확인.
- `rg --sort path -n '\`(lib|bin|assets|test|pubspec\.yaml|analysis_options\.yaml|go\.mod|proto)/|\`(pubspec\.yaml|analysis_options\.yaml)\`' agent-ops/rules/project/domain agent-ops/rules/project/rules.md`: stale root path 후보가 의도된 `lib/framework/`, root `proto/`, 일반 manifest 이름, `test/**` 설명, legacy sample 설명뿐임을 확인.
- 대표 domain mapping 경로 존재 여부 확인: `apps/runner/bin/main.dart`, runner lib/assets, package manifests, `services/core/go.mod`, `proto/` 모두 존재.
- `git diff --check`: 성공, 출력 없음.
- 다음 단계: PASS이므로 active plan/review를 `.log`로 아카이브하고 `complete.log` 작성 후 task directory를 archive로 이동한다.

42
agent-task/archive/2026/06/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log Normal file
View file

@ -0,0 +1,42 @@
# Complete - m-ops-rule-monorepo-alignment/01_domain_rules
## 완료 일시
2026-06-07T04:24:22+09:00
## 요약
Domain rule 경로와 책임 경계 문서를 모노레포 구조에 맞게 정리한 1회차 리뷰를 PASS로 종결했다.
## 루프 이력
| Plan | Review | Verdict | 메모 |
|------|--------|---------|------|
| `plan_local_G04_0.log` | `code_review_local_G04_0.log` | PASS | 계획된 domain/project rule 정합화가 완료되었고, 리뷰 중 command rule의 축약 경로 Nit를 직접 보정했다. |
## 구현/정리 내용
- `agent-ops/rules/project/domain/**/rules.md`의 runner 관련 root `lib/`, `bin/main.dart`, `assets/` 경로를 `apps/runner/...` 기준으로 정리했다.
- `framework` rule과 `agent-ops/rules/project/rules.md`가 runner/client/console/core service manifest, analyzer, Go module, proto 경계를 설명하도록 갱신했다.
- 리뷰 중 `agent-ops/rules/project/domain/command/rules.md`의 command 하위 축약 경로를 전체 `apps/runner/lib/oto/commands/...` 경로로 보정했다.
## 최종 검증
- `rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain` - PASS; 남은 항목은 `apps/runner/...` 또는 명시된 legacy/external exception.
- `rg --sort path -n '\`(lib|bin|assets|test|pubspec\.yaml|analysis_options\.yaml|go\.mod|proto)/|\`(pubspec\.yaml|analysis_options\.yaml)\`' agent-ops/rules/project/domain agent-ops/rules/project/rules.md` - PASS; stale root path 후보는 의도된 `lib/framework/`, root `proto/`, 일반 manifest 이름, `test/**` 설명, legacy sample 설명뿐임.
- `git diff --check` - PASS; 출력 없음.
## Roadmap Completion
- Milestone: `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- Completed task ids:
- `domain-paths`: PASS; evidence=`agent-task/archive/2026/06/m-ops-rule-monorepo-alignment/01_domain_rules/plan_local_G04_0.log`, `agent-task/archive/2026/06/m-ops-rule-monorepo-alignment/01_domain_rules/code_review_local_G04_0.log`; verification=`rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain`, `git diff --check`
- Not completed task ids: 없음
## 잔여 Nit
- 없음
## 후속 작업
- 없음

199
agent-task/archive/2026/06/m-ops-rule-monorepo-alignment/01_domain_rules/plan_local_G04_0.log Normal file
View file

@ -0,0 +1,199 @@
<!-- task=m-ops-rule-monorepo-alignment/01_domain_rules plan=0 tag=RULES -->
# Plan - RULES Domain Rule Monorepo Alignment
## 이 파일을 읽는 구현 에이전트에게
`CODE_REVIEW-local-G04.md`의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채우는 것이 필수다. 구현 후 검증을 실행하고 active 파일을 그대로 둔 채 리뷰 준비를 보고한다. 최종 판정, log rename, `complete.log`, archive 이동은 code-review skill 책임이다. 사용자만 결정할 수 있는 차단, 사용자 소유 외부 환경, 범위 충돌이 생기면 review stub의 `사용자 리뷰 요청` 섹션에 정확한 근거를 채우고 멈춘다. 구현 중 사용자에게 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다. 후속 에이전트가 명령 재실행이나 산출물 수집으로 해결할 수 있는 증거 공백은 사용자 리뷰 요청이 아니다.
## 배경
상위 프로젝트 규칙은 모노레포 구조로 일부 정리되었지만, domain rule 내부는 아직 root `lib/`, `bin/main.dart`, `assets/` 경로를 기준으로 설명한다. 이 상태에서는 코드 변경 전 읽어야 할 domain rule이 실제 파일 위치와 어긋난다. 이 plan은 domain rule의 경로와 책임 경계 설명을 현재 `apps/runner`, `apps/client`, `services/core`, `packages/flutter/oto_console` 구조에 맞춘다.
## 사용자 리뷰 요청 흐름
구현 중 차단은 active `CODE_REVIEW-local-G04.md`의 `사용자 리뷰 요청` 섹션에 기록한다. 직접 사용자 프롬프트는 금지하며, code-review가 요청 타당성을 검증하고 실제 `USER_REVIEW.md` 작성 여부를 결정한다.
## Roadmap Targets
- Milestone: `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- Task ids:
- `domain-paths`: domain rule의 파일 경로 예시와 책임 경계 설명이 현재 코드 위치와 맞는지 검토해 갱신한다.
- Completion mode: check-on-pass
## 분석 결과
### 읽은 파일
- `agent-ops/rules/common/philosophy.md`
- `agent-ops/rules/project/rules.md`
- `agent-roadmap/current.md`
- `agent-roadmap/phase/independent-control-plane/PHASE.md`
- `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- `agent-ops/rules/project/domain/agent/rules.md`
- `agent-ops/rules/project/domain/cli/rules.md`
- `agent-ops/rules/project/domain/command/rules.md`
- `agent-ops/rules/project/domain/core/rules.md`
- `agent-ops/rules/project/domain/framework/rules.md`
- `agent-ops/rules/project/domain/pipeline/rules.md`
- `agent-ops/rules/project/domain/sample/rules.md`
- `agent-ops/rules/project/domain/scheduler/rules.md`
- `Makefile`
- `apps/runner/pubspec.yaml`
- `apps/runner/analysis_options.yaml`
- `apps/client/pubspec.yaml`
- `apps/client/analysis_options.yaml`
- `packages/flutter/oto_console/pubspec.yaml`
- `services/core/go.mod`
### 테스트 환경 규칙
- test_env: `local`
- `agent-test/local/rules.md`는 존재하고 읽었다.
- 이 plan은 domain rule 문서 갱신이며 production 코드나 테스트 코드를 변경하지 않는다.
- matched profile: 없음. 변경 대상은 `agent-ops/rules/project/domain/**/rules.md` 문서다.
- fallback verification: deterministic `rg --sort path` 검색과 `git diff --check`.
### 테스트 커버리지 공백
- domain rule 문서 경로 갱신은 기존 unit test가 직접 검증하지 않는다.
- 검증은 stale path 검색, 현재 파일 존재 여부 대조, markdown diff whitespace 확인으로 수행한다.
### 심볼 참조
- none. 코드 symbol rename/remove가 아니다.
### 분할 판단
- split decision policy를 먼저 평가했다.
- shared task group: `m-ops-rule-monorepo-alignment`
- `01_domain_rules`: domain rule 내부의 경로와 책임 경계 정리. depends_on 없음.
- `02+01_test_rules`: local smoke 문서와 검증 명령 정리. `01_domain_rules` 완료 후 진행해야 한다.
- 이 plan은 `01_domain_rules`이므로 predecessor completion은 필요 없다.
### 범위 결정 근거
- `agent-test/local/*-smoke.md`는 이 plan에서 수정하지 않는다. domain 경로가 먼저 정리된 뒤 smoke 문서를 그 결과에 맞추는 것이 리뷰 가능하다.
- production code, `docs/`, archive 문서는 수정하지 않는다.
- dedicated domain rule이 없는 `apps/client/lib/**`, `packages/flutter/oto_console/lib/**`, `services/core/internal/**`은 기존 runner domain rule에 억지로 편입하지 않는다. 필요하면 별도 domain rule 생성 또는 후속 milestone으로 남긴다.
### 빌드 등급
- `local-G04`: 문서 전용 변경이지만 8개 domain rule의 경계와 path contract를 함께 맞추므로 중간 수준의 정합성 검토가 필요하다.
## 구현 체크리스트
- [ ] `agent-ops/rules/project/domain/**/rules.md`의 root `lib/`, `bin/main.dart`, root `assets/` 경로를 현재 `apps/runner/...` 경로로 갱신하고, legacy/external exception은 명시한다.
- [ ] `framework` rule이 runner/client/console/core service의 package/toolchain/proto 경계만 담당하도록 설명을 정리하고, dedicated domain rule이 없는 구현 경로를 기존 domain으로 단정하지 않는다.
- [ ] `rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain` 결과의 남은 항목이 모두 의도된 legacy/external exception인지 확인한다.
- [ ] `git diff --check`를 실행해 markdown whitespace 오류가 없는지 확인한다.
- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.
### [RULES-1] Runner domain path prefixes
`agent-ops/rules/project/domain/agent/rules.md:16`, `cli/rules.md:16`, `command/rules.md:16`, `core/rules.md:16`, `pipeline/rules.md:16`, `sample/rules.md:17`, `scheduler/rules.md:16` 등 다수 항목이 root `lib/`, `bin/main.dart`, `assets/`를 현재 위치로 안내한다.
#### 문제
상위 project rule은 `apps/runner` 구조를 가리키지만 domain rule 내부 포함/제외 경로와 주요 구성 요소는 root package 시절 경로를 유지한다.
#### 해결 방법
예시:
```markdown
Before:
- `lib/oto/pipeline/` — 파이프라인 실행 엔진 전체
After:
- `apps/runner/lib/oto/pipeline/` — 파이프라인 실행 엔진 전체
```
`agent`, `cli`, `command`, `core`, `pipeline`, `sample`, `scheduler` rule의 포함/제외 경로, 구성 요소 표, 유지 패턴의 파일 경로를 `apps/runner/...`로 정리한다.
#### 수정 파일 및 체크리스트
- [ ] `agent-ops/rules/project/domain/agent/rules.md`
- [ ] `agent-ops/rules/project/domain/cli/rules.md`
- [ ] `agent-ops/rules/project/domain/command/rules.md`
- [ ] `agent-ops/rules/project/domain/core/rules.md`
- [ ] `agent-ops/rules/project/domain/pipeline/rules.md`
- [ ] `agent-ops/rules/project/domain/sample/rules.md`
- [ ] `agent-ops/rules/project/domain/scheduler/rules.md`
#### 테스트 작성
문서 경로 정리이므로 unit test는 작성하지 않는다.
#### 중간 검증
```bash
rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain
```
예상: 남은 root 경로가 있으면 제거하거나 `lib/framework/` 제거 사실처럼 의도된 legacy/external exception으로 문장 안에서 명시한다.
### [RULES-2] Framework and non-runner boundary wording
#### 문제
`agent-ops/rules/project/domain/framework/rules.md:16`은 root `pubspec.yaml`과 `analysis_options.yaml`만 포함한다고 말하지만 실제 package/toolchain 파일은 `apps/runner`, `apps/client`, `packages/flutter/oto_console`, `services/core`에 있다.
#### 해결 방법
예시:
```markdown
Before:
- `pubspec.yaml` — `dart_framework` 외부 Git 의존성 선언
After:
- `apps/runner/pubspec.yaml` — runner Dart dependency와 `dart_framework` Git 의존성
- `apps/client/pubspec.yaml` — Flutter client dependency
- `packages/flutter/oto_console/pubspec.yaml` — embeddable console package dependency
- `services/core/go.mod` — Go core service dependency
```
framework rule은 package manifest, analyzer/lint, protobuf generation, 외부 dependency 경계만 담당한다고 못박는다. `apps/client/lib/**`, `packages/flutter/oto_console/lib/**`, `services/core/internal/**`의 behavior rule은 기존 runner domain rule로 단정하지 말고 dedicated domain rule 필요성을 남긴다.
#### 수정 파일 및 체크리스트
- [ ] `agent-ops/rules/project/domain/framework/rules.md`
- [ ] 필요 시 `agent-ops/rules/project/rules.md`의 dedicated domain 미정 문구와 충돌하지 않는지 확인
#### 테스트 작성
문서 경계 정리이므로 unit test는 작성하지 않는다.
#### 중간 검증
```bash
rg --sort path -n 'pubspec.yaml|analysis_options.yaml|go.mod|proto/' agent-ops/rules/project/domain/framework/rules.md agent-ops/rules/project/rules.md
```
예상: framework rule과 project rule의 package/toolchain 경계가 같은 의미를 가진다.
## 수정 파일 요약
| 파일 | 항목 |
|------|------|
| `agent-ops/rules/project/domain/agent/rules.md` | RULES-1 |
| `agent-ops/rules/project/domain/cli/rules.md` | RULES-1 |
| `agent-ops/rules/project/domain/command/rules.md` | RULES-1 |
| `agent-ops/rules/project/domain/core/rules.md` | RULES-1 |
| `agent-ops/rules/project/domain/pipeline/rules.md` | RULES-1 |
| `agent-ops/rules/project/domain/sample/rules.md` | RULES-1 |
| `agent-ops/rules/project/domain/scheduler/rules.md` | RULES-1 |
| `agent-ops/rules/project/domain/framework/rules.md` | RULES-2 |
| `agent-ops/rules/project/rules.md` | RULES-2 |
## 최종 검증
```bash
rg --sort path -n 'lib/|bin/main|assets/' agent-ops/rules/project/domain
git diff --check
```
남은 root 경로는 의도된 legacy/external exception이어야 하고, `git diff --check`는 출력 없이 성공해야 한다.
모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다.

140
agent-task/m-ops-rule-monorepo-alignment/02+01_test_rules/CODE_REVIEW-local-G04.md Normal file
View file

@ -0,0 +1,140 @@
<!-- task=m-ops-rule-monorepo-alignment/02+01_test_rules plan=0 tag=RULES -->
# Code Review Reference - RULES
> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
> The task is NOT complete until every implementation-owned section below is filled in.
> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
> Fill implementation-owned sections, then stop with active files in place and report ready for review.
> If implementation is blocked by a user-only decision, user-owned external environment prerequisite, or scope conflict, fill `사용자 리뷰 요청` with evidence and stop with active files in place; code-review decides whether to write `USER_REVIEW.md`. Evidence gaps that a follow-up agent can close by rerunning commands or collecting artifacts are normal follow-up issues, not user-review blockers by themselves.
> Do not ask the user directly, present choices in chat, or call `request_user_input` during implementation; record the needed decision in `사용자 리뷰 요청` and stop for code-review.
> Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, `코드리뷰 전용 체크리스트`) is review-agent-only, even after compaction/resume.
> Follow the ownership table at the bottom of this file for which sections you own.
## 개요
date=2026-06-07
task=m-ops-rule-monorepo-alignment/02+01_test_rules, plan=0, tag=RULES
## Roadmap Targets
- Milestone: `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- Task ids:
- `test-rules`: local test rule과 smoke 문서가 모노레포 target 이름과 일치하는지 확인한다.
- Completion mode: check-on-pass
## 이 파일을 읽는 리뷰 에이전트에게
> **[REVIEW AGENT ONLY]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.
각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.
1. 판정을 append한다.
2. `CODE_REVIEW-local-G04.md` -> `code_review_local_G04_N.log`, `PLAN-local-G04.md` -> `plan_local_G04_M.log`로 아카이브한다.
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/m-ops-rule-monorepo-alignment/02+01_test_rules/`로 이동한다. WARN/FAIL이면 user-review gate를 확인한 뒤 다음 active plan/review 파일 또는 `USER_REVIEW.md`를 작성한다. `USER_REVIEW.md`가 사용자 결정으로 완료/PASS 해소되면 code-review가 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log` 작성 후 archive 이동한다.
4. PASS이고 task group이 `m-<milestone-slug>`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.
---
## 구현 항목별 완료 여부
| 항목 | 완료 여부 |
|------|---------|
| [RULES-1] Local smoke read conditions and commands | [ ] |
| [RULES-2] Local routing and monorepo target consistency | [ ] |
## 구현 체크리스트
- [ ] predecessor `01_domain_rules`의 `complete.log`가 active 또는 archive 경로에 있는지 확인하고 없으면 구현을 시작하지 않고 review stub의 사용자 리뷰 요청이 아니라 dependency 미충족으로 기록한다.
- [ ] `agent-test/local/*-smoke.md`의 읽기 조건을 `apps/runner/...` 경로로 갱신하고, package-local 명령은 working directory 또는 `make` target 의미가 분명하게 보이도록 정리한다.
- [ ] `agent-test/local/rules.md`의 라우팅 설명이 runner/client/core package target과 충돌하지 않는지 확인한다.
- [ ] `rg --sort path -n 'lib/|bin/main|assets/' agent-test/local` 결과의 남은 항목이 모두 의도된 예외인지 확인한다.
- [ ] `git diff --check`를 실행해 markdown whitespace 오류가 없는지 확인한다.
- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.
## 코드리뷰 전용 체크리스트
> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.
- [ ] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
- [ ] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
- [ ] active `CODE_REVIEW-*-G??.md`를 `code_review_local_G04_N.log`로 아카이브한다.
- [ ] active `PLAN-*-G??.md`를 `plan_local_G04_M.log`로 아카이브한다.
- [ ] `.gitignore`의 Agent-Ops 관리 block이 `agent-task/**/*.md`와 `agent-task/**/*.log`를 unignore하고 `agent-roadmap/current.md`를 ignore하는지 확인한다.
- [ ] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
- [ ] PASS이면 active task 디렉터리 `agent-task/m-ops-rule-monorepo-alignment/02+01_test_rules/`를 `agent-task/archive/YYYY/MM/m-ops-rule-monorepo-alignment/02+01_test_rules/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
- [ ] PASS이고 task group이 `m-<milestone-slug>`이면 런타임이 읽을 완료 이벤트 메타데이터를 보고하고, roadmap 수정이나 `update-roadmap` 직접 호출을 하지 않는다.
- [ ] PASS split 작업이면 이동 후 빈 active parent `agent-task/m-ops-rule-monorepo-alignment/`를 제거하거나, 남은 sibling/file이 있어 유지했다고 확인한다.
- [ ] WARN/FAIL이고 user-review gate가 트리거되지 않았으면 다음 active `PLAN-local-G04.md`와 `CODE_REVIEW-local-G04.md`를 작성하고 `complete.log`를 작성하지 않는다.
- [ ] USER_REVIEW이면 `agent-ops/skills/common/code-review/templates/user-review-template.md` 기준으로 `USER_REVIEW.md`를 작성하고 active `PLAN-*.md`, `CODE_REVIEW-*.md`, `complete.log`를 남기지 않는다.
- [ ] USER_REVIEW가 사용자 결정으로 완료/PASS 해소되면 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log`를 작성한 뒤 task directory를 archive로 이동한다.
## 계획 대비 변경 사항
_구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께 기록한다._
## 주요 설계 결정
_구현 에이전트가 주요 설계 결정 사항을 기록한다._
## 사용자 리뷰 요청
_기본값은 `없음`이다. 구현 중 사용자 결정, 사용자 소유 외부 환경/secret/서비스 준비, 또는 계획 범위 변경 없이는 안전하게 진행할 수 없으면 아래 항목을 실제 내용으로 교체하고, 구현을 중단한 뒤 active 파일을 그대로 둔 채 리뷰를 요청한다. 구현 에이전트는 사용자에게 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다. 후속 에이전트가 명령 재실행이나 산출물 수집으로 해소할 수 있는 검증 증거 공백만으로는 사용자 리뷰 요청을 작성하지 않는다._
- 상태: 없음
- 사유 유형: 없음
- 결정 필요: 없음
- 차단 근거: 없음
- 실행한 검증/명령: 없음
- 자동 후속 불가 이유: 없음
- 재개 조건: 없음
## 리뷰어를 위한 체크포인트
- predecessor `01_domain_rules` 완료 근거 없이 구현이 시작되지 않았는지 확인한다.
- local smoke read condition이 domain rule 경로와 같은 모노레포 prefix를 쓰는지 확인한다.
- `Makefile` target과 smoke 문서의 명령 의미가 충돌하지 않는지 확인한다.
## 검증 결과
_구현 에이전트가 각 중간 검증 및 최종 검증 명령 실행 후 출력을 여기에 붙여 넣는다._
필수 규칙:
- 검증 명령은 고정된 계약이다. 임의로 대체하지 않는다.
- 대체가 필요하면 `계획 대비 변경 사항`에 이유와 대체 명령을 기록한다.
- `검증 결과`에는 실제 stdout/stderr를 붙여 넣는다.
- 사용자 리뷰 요청으로 명령을 끝까지 실행하지 못했다면 `사용자 리뷰 요청`에 실행한 명령, 실제 출력, 미실행 명령의 사유를 기록한다.
- mobile/UI hang, timeout, 또는 2분 무진행은 blind retry를 중단하고 focused rerun 명령과 screenshot/window/UI-tree evidence path를 남기며, 불가능하면 정확한 사유를 남긴다.
### RULES-1 중간 검증
```bash
$ rg --sort path -n 'lib/|bin/main|assets/' agent-test/local
(output)
```
### RULES-2 중간 검증
```bash
$ rg --sort path -n 'runner-analyze|runner-test|client-analyze|client-test|core-test|apps/runner|apps/client|services/core|packages/flutter/oto_console' agent-test/local Makefile
(output)
```
### 최종 검증
```bash
$ test -f agent-task/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log || find agent-task/archive -path '*/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log' -print -quit | grep -q .
(output)
$ rg --sort path -n 'lib/|bin/main|assets/' agent-test/local
(output)
$ rg --sort path -n 'runner-analyze|runner-test|client-analyze|client-test|core-test|apps/runner|apps/client|services/core|packages/flutter/oto_console' agent-test/local Makefile
(output)
$ git diff --check
(output)
```
---
> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
> If anything is blank, go back and fill it in before saving this file.
> Leave review-agent-only sections unchanged.

194
agent-task/m-ops-rule-monorepo-alignment/02+01_test_rules/PLAN-local-G04.md Normal file
View file

@ -0,0 +1,194 @@
<!-- task=m-ops-rule-monorepo-alignment/02+01_test_rules plan=0 tag=RULES -->
# Plan - RULES Local Test Rule Monorepo Alignment
## 이 파일을 읽는 구현 에이전트에게
`CODE_REVIEW-local-G04.md`의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채우는 것이 필수다. 구현 후 검증을 실행하고 active 파일을 그대로 둔 채 리뷰 준비를 보고한다. 최종 판정, log rename, `complete.log`, archive 이동은 code-review skill 책임이다. 사용자만 결정할 수 있는 차단, 사용자 소유 외부 환경, 범위 충돌이 생기면 review stub의 `사용자 리뷰 요청` 섹션에 정확한 근거를 채우고 멈춘다. 구현 중 사용자에게 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다. 후속 에이전트가 명령 재실행이나 산출물 수집으로 해결할 수 있는 증거 공백은 사용자 리뷰 요청이 아니다.
## 배경
local smoke 문서는 아직 root `lib/`, `bin/main.dart`, `assets/` 경로와 package-local 명령을 섞어 설명한다. 현재 workspace 검증은 `Makefile`의 `runner-*`, `client-*`, `core-test` target과 package별 working directory를 기준으로 실행된다. 이 plan은 domain rule 정리 완료 후 local test rule과 smoke profile의 읽기 조건 및 명령을 모노레포 target 이름과 맞춘다.
## 사용자 리뷰 요청 흐름
구현 중 차단은 active `CODE_REVIEW-local-G04.md`의 `사용자 리뷰 요청` 섹션에 기록한다. 직접 사용자 프롬프트는 금지하며, code-review가 요청 타당성을 검증하고 실제 `USER_REVIEW.md` 작성 여부를 결정한다.
## Roadmap Targets
- Milestone: `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- Task ids:
- `test-rules`: local test rule과 smoke 문서가 모노레포 target 이름과 일치하는지 확인한다.
- Completion mode: check-on-pass
## 분석 결과
### 읽은 파일
- `agent-ops/rules/common/philosophy.md`
- `agent-ops/rules/project/rules.md`
- `agent-roadmap/current.md`
- `agent-roadmap/phase/independent-control-plane/milestones/ops-rule-monorepo-alignment.md`
- `agent-test/local/rules.md`
- `agent-test/local/agent-smoke.md`
- `agent-test/local/cli-smoke.md`
- `agent-test/local/command-smoke.md`
- `agent-test/local/core-smoke.md`
- `agent-test/local/framework-smoke.md`
- `agent-test/local/pipeline-smoke.md`
- `agent-test/local/sample-smoke.md`
- `agent-test/local/scheduler-smoke.md`
- `Makefile`
- `apps/runner/pubspec.yaml`
- `apps/client/pubspec.yaml`
- `packages/flutter/oto_console/pubspec.yaml`
- `services/core/go.mod`
### 테스트 환경 규칙
- test_env: `local`
- `agent-test/local/rules.md`는 존재하고 읽었다.
- matched profiles: 모든 local smoke profile을 읽었다. 이 plan 자체가 smoke profile 정리 작업이다.
- fallback verification: `Makefile` target과 package manifest를 근거로 명령을 정리한다.
- `<확인 필요>` 값: 없음.
### 테스트 커버리지 공백
- test rule 문서 정리는 unit test가 직접 검증하지 않는다.
- 검증은 stale read condition 검색, `Makefile` target 이름과 smoke 문서 명령 대조, `git diff --check`로 수행한다.
### 심볼 참조
- none. 코드 symbol rename/remove가 아니다.
### 분할 판단
- split decision policy를 먼저 평가했다.
- shared task group: `m-ops-rule-monorepo-alignment`
- predecessor: `01_domain_rules`
- predecessor completion: 현재 active/archived `complete.log`가 없다. 이 plan은 작성해 두되 구현은 `agent-task/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log` 또는 archive의 matching `01_domain_rules/complete.log`가 생긴 뒤 시작한다.
- 이 dependency는 subtask directory name `02+01_test_rules`가 source of truth다.
### 범위 결정 근거
- domain rule 내부 경로 수정은 predecessor plan이 담당한다.
- production code, test code, `docs/`, archive 문서는 수정하지 않는다.
- 실제 검증 명령을 실행해 pass/fail을 바꾸는 작업이 아니라, 문서의 라우팅과 명령 계약을 현재 모노레포 target으로 맞추는 작업이다.
### 빌드 등급
- `local-G04`: 문서 전용 변경이지만 모든 local smoke profile을 함께 맞추고 predecessor 결과와 Makefile target을 대조해야 한다.
## 구현 체크리스트
- [ ] predecessor `01_domain_rules`의 `complete.log`가 active 또는 archive 경로에 있는지 확인하고 없으면 구현을 시작하지 않고 review stub의 사용자 리뷰 요청이 아니라 dependency 미충족으로 기록한다.
- [ ] `agent-test/local/*-smoke.md`의 읽기 조건을 `apps/runner/...` 경로로 갱신하고, package-local 명령은 working directory 또는 `make` target 의미가 분명하게 보이도록 정리한다.
- [ ] `agent-test/local/rules.md`의 라우팅 설명이 runner/client/core package target과 충돌하지 않는지 확인한다.
- [ ] `rg --sort path -n 'lib/|bin/main|assets/' agent-test/local` 결과의 남은 항목이 모두 의도된 예외인지 확인한다.
- [ ] `git diff --check`를 실행해 markdown whitespace 오류가 없는지 확인한다.
- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.
## 의존 관계 및 구현 순서
- `02+01_test_rules`는 같은 task group의 `01_domain_rules` 완료에 의존한다.
- 구현 전 확인 대상:
- active: `agent-task/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log`
- archive: `agent-task/archive/*/*/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log`
### [RULES-1] Local smoke read conditions and commands
#### 문제
`agent-test/local/agent-smoke.md:13`, `cli-smoke.md:13`, `command-smoke.md:13`, `core-smoke.md:13`, `pipeline-smoke.md:13`, `sample-smoke.md:13`, `scheduler-smoke.md:13`은 root `lib/`, `bin/main.dart`, `assets/` 경로를 읽기 조건으로 사용한다. `Makefile`은 package working directory 기반 `runner-analyze`, `runner-test`, `client-analyze`, `client-test`, `core-test` target을 제공한다.
#### 해결 방법
예시:
```markdown
Before:
- `lib/oto/agent/**`, `lib/cli/commands/command_agent.dart`, 또는 `assets/script/shell/oto_agent_bootstrap.sh` 변경 검증이 필요한 경우
After:
- `apps/runner/lib/oto/agent/**`, `apps/runner/lib/cli/commands/command_agent.dart`, 또는 `apps/runner/assets/script/shell/oto_agent_bootstrap.sh` 변경 검증이 필요한 경우
```
각 smoke profile의 read condition을 domain rule의 최종 경로와 맞추고, 명령은 package-local 실행인지 `make` target인지 헷갈리지 않게 쓴다.
#### 수정 파일 및 체크리스트
- [ ] `agent-test/local/agent-smoke.md`
- [ ] `agent-test/local/cli-smoke.md`
- [ ] `agent-test/local/command-smoke.md`
- [ ] `agent-test/local/core-smoke.md`
- [ ] `agent-test/local/framework-smoke.md`
- [ ] `agent-test/local/pipeline-smoke.md`
- [ ] `agent-test/local/sample-smoke.md`
- [ ] `agent-test/local/scheduler-smoke.md`
#### 테스트 작성
문서 라우팅 정리이므로 unit test는 작성하지 않는다.
#### 중간 검증
```bash
rg --sort path -n 'lib/|bin/main|assets/' agent-test/local
```
예상: 남은 root 경로가 있으면 제거하거나 의도된 예외로 명시한다.
### [RULES-2] Local routing and monorepo target consistency
#### 문제
`agent-test/local/rules.md`는 domain smoke profile만 나열하고, package별 target 이름과 현재 `Makefile`의 runner/client/core split이 어떻게 연결되는지 분명히 말하지 않는다. `framework-smoke.md:13`도 root manifest만 전제로 한다.
#### 해결 방법
`agent-test/local/rules.md`에 runner/client/core package target 기준을 짧게 추가하고, framework profile은 `apps/runner/pubspec.yaml`, `apps/client/pubspec.yaml`, `packages/flutter/oto_console/pubspec.yaml`, `services/core/go.mod`, `proto/**` 같은 manifest/proto 경계를 읽기 조건으로 둔다.
#### 수정 파일 및 체크리스트
- [ ] `agent-test/local/rules.md`
- [ ] `agent-test/local/framework-smoke.md`
- [ ] 필요 시 다른 smoke profile의 명령 설명
#### 테스트 작성
문서 라우팅 정리이므로 unit test는 작성하지 않는다.
#### 중간 검증
```bash
rg --sort path -n 'runner-analyze|runner-test|client-analyze|client-test|core-test|apps/runner|apps/client|services/core|packages/flutter/oto_console' agent-test/local Makefile
```
예상: smoke 문서와 `Makefile` target 이름이 같은 의미로 읽힌다.
## 수정 파일 요약
| 파일 | 항목 |
|------|------|
| `agent-test/local/rules.md` | RULES-2 |
| `agent-test/local/agent-smoke.md` | RULES-1 |
| `agent-test/local/cli-smoke.md` | RULES-1 |
| `agent-test/local/command-smoke.md` | RULES-1 |
| `agent-test/local/core-smoke.md` | RULES-1 |
| `agent-test/local/framework-smoke.md` | RULES-1, RULES-2 |
| `agent-test/local/pipeline-smoke.md` | RULES-1 |
| `agent-test/local/sample-smoke.md` | RULES-1 |
| `agent-test/local/scheduler-smoke.md` | RULES-1 |
## 최종 검증
```bash
test -f agent-task/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log || find agent-task/archive -path '*/m-ops-rule-monorepo-alignment/01_domain_rules/complete.log' -print -quit | grep -q .
rg --sort path -n 'lib/|bin/main|assets/' agent-test/local
rg --sort path -n 'runner-analyze|runner-test|client-analyze|client-test|core-test|apps/runner|apps/client|services/core|packages/flutter/oto_console' agent-test/local Makefile
git diff --check
```
첫 번째 명령은 predecessor `complete.log`가 active 또는 archive 경로에 있을 때만 성공해야 한다. 남은 root 경로는 의도된 예외여야 하고, `git diff --check`는 출력 없이 성공해야 한다.
모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다.