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

chore: update agent-ops rules

Browse source
This commit is contained in:
toki 2026-05-19 10:27:16 +09:00
parent 21037225e3
commit 26186097ee
8 changed files with 160 additions and 39 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -2,38 +2,51 @@
## 목적 / 책임
사용자로부터 CLI 인자를 받아 파싱하고, `Application`을 통해 파이프라인을 시작하거나 스케줄러 데몬을 관리하는 진입 계층이다.
사용자로부터 CLI 인자를 받아 파싱하고, `Application`을 통해 파이프라인 실행을 시작하는 진입 계층이다.
백그라운드 스케줄러의 상세 실행/등록 관리는 `scheduler` 도메인에서 담당한다.
## 포함 경로
- `lib/cli/` — CLI 레이어 전체 (명령 파싱, 스케줄러 관리)
- `lib/cli/cli.dart` — CLI 루트 객체, 출력/스타일 처리
- `lib/cli/commands/command_base.dart` — CLI 커맨드 공통 베이스
- `lib/cli/commands/command_manager.dart` — CLI 커맨드 라우팅
- `lib/cli/commands/command_exe.dart` — `exe` 명령과 `Application.build()` 진입
- `lib/cli/commands/command_template.dart` — 템플릿 출력
- `lib/cli/commands/command_start.dart` — 시작 커맨드
- `lib/cli/commands/command_install.dart` — 설치 명령
- `lib/cli/commands/install/` — PATH 등록 등 설치 보조 로직
## 제외 경로
- `lib/oto/` — 비즈니스 로직·파이프라인 엔진 (cli는 진입만 담당)
- `lib/cli/commands/scheduler/` — 스케줄러 실행/등록/OS별 백그라운드 처리 (`scheduler` 도메인)
## 주요 구성 요소
- `Cli` (`cli.dart`) — CLI 루트 객체
- `CLI` (`cli.dart`) — CLI 루트 객체, 출력 유틸, `CLIConfig`
- `Printer` (`cli.dart`) — OS별 콘솔 출력 처리
- `CommandExe` — `-j`(Jenkins), `-t`(test), `-f`(file) 플래그 파싱 → `Application.build()` 호출
- `CommandInstall` — PATH 등록 (`install/regist_path.dart`)
- `CommandScheduler` — 스케줄러 데몬 시작
- `CommandStart` — 시작 커맨드
- `CommandTemplate` — 템플릿 출력
- `CommandManager` — CLI 커맨드 등록 관리
- `SchedulerManager` — 스케줄러 실행 조정 (interval, isolate, OS별 구현)
## 유지할 패턴
- CLI 커맨드는 `CommandBase` 상속
- OS별 스케줄러는 `scheduler_linux.dart` / `scheduler_osx.dart` / `scheduler_windows.dart` 분리 유지
- CLI는 인자 파싱과 진입점 역할만 수행하고, 파이프라인 실행은 `Application.build()`에 위임
- `CommandExe`는 `BuildType` 선택과 YAML 파일 읽기까지만 담당
- 콘솔 출력은 `CLI.print*` 또는 `CommandBase` 출력 헬퍼를 사용
- CLI 변경 후 `dart analyze`를 실행하고, CLI 진입 변경이면 최소 `dart run bin/main.dart` 수준의 스모크 실행 가능 여부를 확인
## 다른 도메인과의 경계
- **pipeline/command**: cli는 `Application.build()`만 호출. 파이프라인·커맨드 내부를 직접 참조하지 않는다
- **core**: DataComposer 호출은 Application 내부에서 이루어지며 cli는 관여하지 않는다
- **scheduler**: `CommandScheduler`와 `lib/cli/commands/scheduler/**`는 scheduler 도메인이다. 일반 CLI 변경에서 scheduler 내부 동작을 함께 수정하지 않는다
## 금지 사항
- cli 레이어에서 Pipeline 또는 Command를 직접 인스턴스화하지 않는다
- 비즈니스 로직을 cli 커맨드 핸들러에 넣지 않는다
- 일반 CLI 변경에 scheduler 등록 파일, 로그 파일, OS 시작 프로그램 로직을 섞지 않는다

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

@ -3,6 +3,7 @@
## 목적 / 책임
외부 시스템(Git, Jenkins, FTP, Slack, iOS 빌드 등)과의 실제 연동을 구현하는 커맨드 계층과, 커맨드 파라미터 데이터 모델을 담당한다.
파이프라인은 커맨드를 호출만 하며, 실제 I/O·프로세스 실행·외부 API 호출은 이 도메인에 둔다.
## 포함 경로
@ -21,29 +22,42 @@
- `DataParam` (`base_data.dart`) — 모든 커맨드 파라미터의 베이스
- `DataCommand` (`command_data.dart`) — 모든 커맨드에 전달되는 통합 컨테이너
커맨드 카테고리:
- `build/` — iOS/Flutter/Dart/MSBuild/.NET 빌드
- `file/` — 파일 복사·삭제·이름 변경·압축
- `git/` — Git, GitHub 연동
- `ftp/` — FTP 업로드·다운로드
- `notification/` — Slack, Mattermost 알림
- `jenkins/` — Jenkins API 연동
- `aws/`, `docker/`, `gradle/`, `proto/`, `jira/`, `infra/`, `shell/`, `web/`, `process/`, `util/`
커맨드 카테고리와 우선 참조 파일:
| 범주 | 구현 경로 | 데이터 모델 |
|------|-----------|-------------|
| 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` |
## 유지할 패턴
- 새 커맨드는 반드시 `Command` 상속 후 `CommandRegistry`에 등록
- 파라미터 모델은 `DataParam` 상속 + `@JsonSerializable`
- `*.g.dart`는 `dart run build_runner build`로 생성 (필요 시 직접 수정 가능)
- `*.g.dart`는 `dart run build_runner build`로 생성한다. 생성 파일 직접 수정은 생성 불가한 긴급 상황에서만 한다
- `getWorkspace()`: workspace 필드 → `property['workspace']` → `commonData.workspace` 순으로 resolve
- 커맨드 파라미터는 `getParam(command)`를 통해 태그 치환과 workspace resolve를 거친 뒤 `Data*` 모델로 파싱한다
- 결과 저장은 `<@property.key>` 형태의 쓰기 태그와 `setProperty()` / `complete()`의 `setResult`, `setExitCode` 흐름을 우선 사용한다
- 외부 프로세스 실행은 기존 패턴인 `ProcessExecutor.start()` 또는 `ProcessExecutor.run()`을 우선 사용한다
- 커맨드 추가/파라미터 변경 시 관련 `assets/yaml/sample/**`와 README 커맨드 목록 갱신 필요 여부를 확인한다
- 데이터 모델 변경 후 `dart run build_runner build`와 `dart analyze`를 실행한다
## 다른 도메인과의 경계
- **pipeline**: `Command.execute(DataCommand)`를 호출하는 시점이 경계. 커맨드는 흐름을 모른다
- **core**: 태그 치환은 core가 완료한 후 DataCommand가 커맨드에 전달됨
- **sample**: YAML 사용 예시는 sample 도메인이 담당한다. 커맨드 파라미터 변경 시 sample 도메인과 동기화한다
- **framework**: `dart_framework`의 `ProcessExecutor`, path/system 유틸은 외부 런타임 의존성으로 사용한다. OTO 비즈니스 로직을 framework 의존성 쪽으로 옮기지 않는다
## 금지 사항
- 커맨드에서 다른 커맨드를 직접 인스턴스화하거나 호출하지 않는다
- 흐름 제어(if/loop) 로직을 커맨드 내부에 넣지 않는다
- `CommandRegistry` 외 장소에서 CommandType 매핑을 추가하지 않는다
- 커맨드 구현 중 `Application.instance.dataCommandMap`을 직접 순회하거나 파이프라인 구조를 해석하지 않는다
- 샘플 YAML에 실제 토큰, 비밀번호, API 키를 넣지 않는다

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

@ -3,6 +3,7 @@
## 목적 / 책임
파이프라인 실행 전 단계에서 YAML 파싱, Jenkins 환경 변수 합성, 태그 치환을 담당하는 공통 인프라 레이어다. `Application` 싱글턴이 전체 빌드 흐름을 오케스트레이션한다.
런타임 property, command state, build data 생성처럼 pipeline/command가 공유하는 실행 컨텍스트도 이 도메인에서 시작된다.
## 포함 경로
@ -21,18 +22,27 @@
- `DataComposer` (`data_composer.dart`) — YAML + Jenkins env → `DataCommand` 리스트 변환
- `DefinedData` (`defined_data.dart`) — 내장 YAML 템플릿 (빌트인 정의)
- `MattermostSender` / `MattermostData` (`utils/mattermost/`) — 공통 알림 헬퍼
- `Application` (`application.dart`) — build type 분기, command 등록, property 초기화, pipeline 실행
## 유지할 패턴
- 태그 치환은 반드시 `TagSystem`을 통해 처리
- 태그 전체 문자열이면 원본 타입 유지, 부분 삽입이면 `toString()` 변환 원칙 유지
- YAML 문자열 → Map 변환은 `Application.getMapFromYamlA()` 흐름을 유지
- 커맨드 등록은 `registerAllCommands()` 호출 이후 pipeline validate를 수행
- property 기본값에 `workspace`가 없으면 `Application.current`를 채우는 흐름을 유지
- core 변경 후 `dart analyze`를 실행하고, 태그/파싱 변경이면 관련 단위 테스트 또는 최소 샘플 YAML 파싱 검증을 추가/확인한다
## 다른 도메인과의 경계
- **pipeline**: DataComposer가 DataCommand 리스트 생성을 완료한 후 Pipeline이 실행 시작
- **command**: 커맨드 실행 중 쓰기 태그(`<@...>`) 처리는 TagSystem에 위임
- **cli/scheduler**: build type, YAML content, scheduler build data는 cli/scheduler에서 넘기지만 실제 build 흐름은 Application이 담당
- **sample**: 태그 문법이나 YAML 구조가 변경되면 sample 도메인의 YAML 예시를 함께 점검
## 금지 사항
- core에서 외부 시스템(Git, Jenkins API 등)을 직접 호출하지 않는다
- 커맨드별 파싱 로직을 DataComposer에 넣지 않는다
- pipeline 흐름 제어(if/foreach/switch 등)를 core에 넣지 않는다
- command별 실행 결과 처리 로직을 `Application`에 추가하지 않는다

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

@ -2,47 +2,42 @@
## 목적 / 책임
oto 전체에서 공유하는 런타임 인프라를 제공한다: 프로세스 실행, Isolate 관리, 로깅, 플랫폼 추상화, 공통 유틸리티.
현재 프로젝트에는 `lib/framework/` 모듈이 없다.
이 도메인은 외부 Git 의존성인 `dart_framework` 사용 규칙과 의존성 경계를 기록한다.
## 포함 경로
- `lib/framework/core/` — Application 베이스, AppDataManager (앱 메타데이터)
- `lib/framework/data/` — Isolate 메시지 데이터 타입
- `lib/framework/log/` — 로깅 시스템 (Log, LogItem, LogType)
- `lib/framework/model/` — AppData 모델 및 JSON 직렬화
- `lib/framework/platform/` — 플랫폼 추상화, IsolateManager, ProcessExecutor
- `lib/framework/utils/` — 공통 유틸 (system_util, path, string_util, os_startup, Slack 헬퍼)
- `pubspec.yaml` — `dart_framework` 외부 Git 의존성 선언
## 제외 경로
- `lib/framework/` — 제거된 로컬 모듈. 새로 만들지 않는다
- `lib/oto/` — OTO 비즈니스 로직 (framework 위에서 동작)
- `lib/cli/` — CLI 레이어 (framework를 소비)
## 주요 구성 요소
- `Application` (`core/application.dart`) — `runZonedGuarded` 기반 앱 진입점 베이스
- `AppDataManager` (`core/app_data_manager.dart`) — 버전, Git hash, 빌드 일자 생성 및 `app_data.json` 저장
- `IsolateManager` / `IsolateBase` / `IsolateHandler` (`platform/isolate_manager.dart`) — Dart Isolate 라이프사이클 관리
- `ProcessExecutor` / `ProcessData` (`platform/process.dart`) — 셸 스크립트·외부 프로세스 실행 (macOS: zsh, Linux: bash, Windows: PowerShell)
- `Log` / `LogItem` (`log/log.dart`) — 로그 수집 및 파일 기록
- `AppData` (`model/app_data.dart`) — 앱 메타 모델 (`app_data.json`)
- `system_util.dart` — 환경 초기화, CLI 인자 파싱, YAML/JSON 파싱 헬퍼
- `SlackSender` / `SlackData` (`utils/slack/`) — Slack 메시지 전송 헬퍼
- `dart_framework/core/application.dart` — `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()`의 로그 타입에 사용
## 유지할 패턴
- 프로세스 실행은 `ProcessExecutor.start()` (스트리밍, stdout/stderr 실시간 수신) 또는 `ProcessExecutor.run()` (블로킹, 결과만 필요) 중 목적에 맞게 선택
- 로그 출력은 `log()` / `logWarning()` / `logError()` 함수를 통해서만 기록
- OS 분기가 필요한 코드는 `Platform.isMacOS / isLinux / isWindows` 조건으로 분기하고, 플랫폼별 구현은 `platform_*` 파일로 분리
- `dart_framework` API 사용 시 기존 import 패턴을 따른다
- 외부 의존성 ref 변경은 `pubspec.yaml`에서만 수행하고, 변경 후 `dart pub get` 및 `dart analyze`를 확인한다
- 로컬에 `lib/framework/`를 되살리는 대신 필요한 OTO 로직은 `lib/oto/` 또는 `lib/cli/`의 해당 도메인에 둔다
## 다른 도메인과의 경계
- **core**: `lib/oto/application.dart`(OTO 오케스트레이터)는 framework의 `Application`을 상속하지 않고 독립 singleton. framework는 하위 인프라만 제공
- **cli**: `scheduler_isolate.dart`는 `IsolateBase`를 상속. framework가 API를 제공하고 cli가 소비
- **command**: 커맨드들이 `ProcessExecutor`를 직접 사용하여 셸 스크립트 실행
- **core**: `lib/oto/application.dart`는 OTO 오케스트레이터이며 외부 framework의 Application과 별개다
- **cli/scheduler**: isolate, process, OS startup 유틸을 소비하지만 스케줄러 정책은 scheduler 도메인에 둔다
- **command**: 커맨드들은 `ProcessExecutor`를 소비하지만 커맨드별 비즈니스 로직은 command 도메인에 둔다
## 금지 사항
- framework 내부에서 `lib/oto/` 또는 `lib/cli/`를 import하지 않는다 (단방향 의존성 유지)
- OTO 비즈니스 로직(파이프라인, 커맨드 등록 등)을 framework에 넣지 않는다
- `ProcessExecutor`를 우회하여 `dart:io Process`를 직접 호출하지 않는다
- `lib/framework/` 디렉터리를 새로 만들지 않는다
- 외부 `dart_framework` 내부 코드를 이 저장소의 도메인 rule 기준으로 직접 수정한다고 가정하지 않는다
- OTO 비즈니스 로직(파이프라인, 커맨드 등록 등)을 framework 의존성 변경으로 해결하려 하지 않는다

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

@ -3,6 +3,7 @@
## 목적 / 책임
YAML에서 파싱된 `DataCommand` 리스트를 순차 실행하고, 조건 분기·반복·대기 등 파이프라인 흐름 제어를 담당한다.
외부 시스템 작업은 실행하지 않고, command ID를 찾아 커맨드 도메인으로 위임한다.
## 포함 경로
@ -28,13 +29,20 @@ YAML에서 파싱된 `DataCommand` 리스트를 순차 실행하고, 조건 분
- 파이프라인 노드는 단일 책임: 흐름 제어만 한다, I/O는 커맨드에 위임
- 새 흐름 제어 유형은 `Pipeline*` 네이밍으로 추가
- 새 흐름 제어 유형은 `Pipeline.exeMap`에 등록하고, 필요한 데이터 모델은 `lib/oto/data/pipeline_data.dart`에 둔다
- 파이프라인 validate 단계에서 command ID 존재 여부와 하위 task 구조를 가능한 한 먼저 확인한다
- 조건식은 `PipelineCondition`의 type caster와 `Command.replaceTagValue()` 흐름을 유지한다
- pipeline 변경 후 `dart analyze`를 실행하고, if/foreach/while/switch/wait-until 중 영향을 받는 샘플 YAML 파싱 또는 실행 테스트를 확인한다
## 다른 도메인과의 경계
- **command**: `Pipeline`이 `Command.byType()`을 호출하는 시점이 경계. 커맨드 내부 로직은 pipeline이 모른다
- **core**: `DataComposer`가 YAML → `DataCommand` 변환을 마친 후 pipeline이 실행 시작
- **sample**: workflow 문법 변경 시 `assets/yaml/sample/02_*`~`05_*`와 README 흐름 제어 예시를 함께 점검
## 금지 사항
- pipeline 코드에서 외부 시스템(Git, Jenkins 등)을 직접 호출하지 않는다
- 커맨드별 비즈니스 로직을 pipeline에 넣지 않는다
- pipeline에서 파일 시스템, 네트워크, shell 실행을 직접 수행하지 않는다
- command param의 세부 필드를 pipeline에서 해석하지 않는다

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

@ -4,6 +4,7 @@
YAML 작성 요청 시 코드 분석 없이 빠르게 참조할 수 있는 샘플 파일 모음을 담당한다.
샘플만 읽으면 파라미터 이름·태그 문법·파이프라인 패턴을 바로 파악할 수 있어 토큰을 절약한다.
AI가 파이프라인 YAML을 작성하거나 검토할 때 가장 먼저 읽는 도메인이다.
## 포함 경로
@ -13,6 +14,7 @@ YAML 작성 요청 시 코드 분석 없이 빠르게 참조할 수 있는 샘
- `assets/yaml/example/` — 기존 실험용 파일 (샘플 도메인 아님)
- `assets/templates/` — 알림 템플릿 (샘플 도메인 아님)
- `lib/oto/data/` — 실제 파라미터 모델은 command 도메인
## 주요 구성 요소
@ -60,11 +62,16 @@ YAML 작성 요청 시 코드 분석 없이 빠르게 참조할 수 있는 샘
- 각 파일 상단에 `# [샘플] 제목` 주석으로 목적 명시
- 실제 작동 가능한 파라미터 구조를 유지한다 (추측 값 사용 금지)
- 새 커맨드가 추가되면 관련 샘플 파일도 함께 갱신한다
- 샘플은 placeholder 값을 사용하고 실제 토큰·비밀번호·API 키를 넣지 않는다
- YAML 작성 요청에서는 먼저 이 rule의 키워드 표로 읽을 샘플을 고르고, 필요한 샘플만 읽는다
- 샘플 변경 후 `dart analyze` 영향은 보통 없지만, 가능하면 해당 YAML이 `Application.getMapFromYamlA()`와 `DataBuild.fromJson()`으로 파싱 가능한지 확인한다
## 다른 도메인과의 경계
- **command**: 커맨드 파라미터가 변경되면 샘플도 동기화 필요. 샘플은 command 도메인을 참조하지 않는다
- **core**: 태그 문법(`<!...>` / `<@...>`)이 변경되면 모든 샘플 파일 업데이트 필요
- **pipeline**: workflow 문법이 변경되면 pipeline 샘플(`02`~`05`)을 함께 갱신한다
- **scheduler**: scheduler YAML 구조는 `12_scheduler.yaml`에서 관리한다
## 금지 사항

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

@ -0,0 +1,51 @@
# scheduler
## 목적 / 책임
등록된 YAML 파이프라인을 백그라운드에서 cron 또는 interval 방식으로 실행하는 스케줄러 도메인이다.
CLI의 `scheduler` 명령, OS별 실행 경로, isolate 기반 실행, 등록 파일/로그 파일 관리를 담당한다.
## 포함 경로
- `lib/cli/commands/command_scheduler.dart` — `scheduler` CLI 명령 파싱과 진입점
- `lib/cli/commands/scheduler/` — 스케줄러 등록/해제/실행/OS별 구현
- `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` 도메인)
## 주요 구성 요소
- `CommandScheduler` — `-l`, `-r`, `-u`, `-e`, 숨김 `-s`, `-t` 플래그 처리
- `SchedulerManager` — 스케줄러 등록 파일, settings.json, 로그, 프로세스 시작/종료 관리
- `SchedulerLinux` / `SchedulerOsx` / `SchedulerWindows` — OS별 실행 파일 경로 결정
- `IsolateScheduler` — 스케줄러 YAML 변경 감지, cron/interval 실행, 로그 전송
- `SchedulerInterval` — interval 기반 반복 실행 제어
- `SchedulerListData` / `SchedulerData` — 로컬 scheduler settings JSON 모델
## 유지할 패턴
- OS별 차이는 `scheduler_linux.dart`, `scheduler_osx.dart`, `scheduler_windows.dart`에 분리한다
- YAML 파싱은 `Application.getMapFromYamlA()`와 `DataBuild.fromJson()` 흐름을 사용한다
- 실제 파이프라인 실행은 `CommandExe.executeScheduler()`에 위임하고, scheduler가 command/pipeline 내부를 직접 해석하지 않는다
- 스케줄러 등록 데이터는 `dataPath/scheduler` 하위의 YAML과 `settings.json` 구조를 유지한다
- 로그 파일명에는 alias, pid, 날짜/시간을 포함하는 기존 패턴을 유지한다
- scheduler 데이터 모델 변경 시 `dart run build_runner build`와 `dart analyze`를 실행한다
## 다른 도메인과의 경계
- **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`에서 관리한다
## 금지 사항
- scheduler 내부에서 `Command.byType()` 또는 `Pipeline.pipelineInitialize()`를 직접 호출하지 않는다
- OS별 실행 경로 보정 로직을 공통 `SchedulerManager`에 섞지 않는다
- 등록/해제 작업에서 사용자가 지정한 YAML 외 임의의 프로젝트 파일을 수정하지 않는다
- scheduler 샘플에 실제 토큰, 비밀번호, API 키를 넣지 않는다

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

@ -33,6 +33,7 @@ lib/
```
> **참고**: `lib/framework/` 모듈이 제거되었습니다. 기존 기능은 `lib/oto/` 내부로 통합되었습니다.
> 현재 `dart_framework`는 외부 Git 의존성으로만 사용합니다.
## 기술 스택
@ -69,13 +70,28 @@ lib/
2. `lib/oto/commands/command.dart`의 `CommandType` enum에 값 추가
3. `Command` 상속하여 커맨드 클래스 구현
4. `lib/oto/commands/command_registry.dart`에 등록
5. `@JsonSerializable` 클래스 추가 시 `dart run build_runner build` 실행
5. 관련 `assets/yaml/sample/**` 샘플 갱신 필요 여부 확인
6. `@JsonSerializable` 클래스 추가/변경 시 `dart run build_runner build` 실행
## 에러 처리
- `Application.build()`는 `catch (e, stacktrace)` (Exception이 아닌 Error 포함 캐치)
- 에러 시 `exit(10)` 호출로 부모 프로세스에 실패 신호 전달
## 스킬 기반 작업 흐름
- 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/**`를 우선 참조한다.
- 코드 변경 요청은 먼저 아래 도메인 매핑에서 해당 rule을 읽고, 변경 후 도메인 rule의 검증 기준을 따른다.
## 도메인 룰 로딩
- 아래 도메인 매핑에 해당하는 작업에서 해당 domain 최초 진입 시 domain rule을 1회 읽는다.
- 더 구체적인 경로 패턴이 있으면 그 rule을 우선 적용한다.
- 이미 읽은 domain rule은 같은 세션에서 반복해서 읽지 않는다.
## 도메인 매핑
| 경로 패턴 | 도메인 | rules.md |
@ -83,14 +99,21 @@ lib/
| `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/**` | command | `agent-ops/rules/project/domain/command/rules.md` |
| `lib/cli/commands/scheduler/**` | scheduler | `agent-ops/rules/project/domain/scheduler/rules.md` |
| `lib/cli/**` | cli | `agent-ops/rules/project/domain/cli/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/yaml/sample/**` | sample | `agent-ops/rules/project/domain/sample/rules.md` |
| `pubspec.yaml` | framework | `agent-ops/rules/project/domain/framework/rules.md` |
## 스킬 라우팅
| 요청 키워드 | 수행 방법 |
|------------|---------|
| yaml 짜줘, 파이프라인 만들어줘, 자동화 작성, 빌드 yaml | `agent-ops/rules/project/domain/sample/rules.md` 읽고 해당 샘플 참조 |
| 도메인 업데이트, domain rule 갱신, 도메인 검토, domain 스캔 | `agent-ops/skills/common/update-domain-rule/SKILL.md` 수행 |
| domain rule 만들어줘, rules.md 생성, 새 도메인 규칙 | `agent-ops/skills/common/create-domain-rule/SKILL.md` 수행 |
| skill 만들어줘, SKILL.md 생성, 새 스킬 추가 | `agent-ops/skills/common/create-skill/SKILL.md` 수행 |
| 코드 리뷰해줘, code review | `agent-ops/skills/common/code-review/SKILL.md` 수행 |
| 커밋해줘, 푸시해줘, commit, push, 반영해줘 | `agent-ops/skills/common/commit-push/SKILL.md` 수행 |