261 lines
20 KiB
Markdown
261 lines
20 KiB
Markdown
# Handoff: Chronos Standalone Agent Runtime과 Node Domain-Agent Gateway
|
||
|
||
> 2026-08-01 책임 경계 정정: Chronos scaffold와 후속 Roadmap 문서는 생성됐지만, 완료된 `iop-agent`의 선별 이전과 IOP standalone 의존성 제거는 Chronos 작업이 아니라 IOP가 먼저 수행할 작업이다. 현재 source of truth와 첫 진입점은 [IOP 선행 분리 Milestone](agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md)이며, [Chronos Roadmap](../chronos/agent-roadmap/ROADMAP.md)은 이 Milestone 완료 전까지 외부 잠금 상태다. 아래 최초 설계 narrative의 “새 저장소 미생성” 문구는 historical context로만 읽는다.
|
||
|
||
- 작성일: 2026-07-31
|
||
- 현재 타겟: IOP에서 Chronos-owned 자산을 선별 이전하고 standalone 의존성을 제거하는 선행 Milestone 검토
|
||
- 다음 세션 첫 진입점: [IOP 선행 분리 Milestone](agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md)과 [SDD User Review](agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/USER_REVIEW.md)
|
||
- 상태: Chronos scaffold·Agent-Ops·후속 Roadmap 생성 완료, IOP source 선별 이전·제거 미착수, Chronos Roadmap 외부 잠금
|
||
- 기록 위치: IOP 선행 분리의 원본은 IOP Roadmap/SDD에, 완료 뒤 제품 개발 원본은 Chronos Roadmap에 둔다.
|
||
|
||
## 사용자 확정 사항
|
||
|
||
1. `/config/workspace/iop-s0`에서 진행했던 `IOP Agent CLI Runtime` Milestone은 기존 범위대로 완료됐다. 완료 범위를 다시 열지 않고, 현재 `/config/workspace/iop`에 통합된 source와 계약을 선별 이전 기준선으로 사용한다.
|
||
2. `agentic-framework`는 문서·셸 중심의 가벼운 공통 agent-ops 프레임워크로 그대로 유지한다. 어디든 설치 가능한 현재 성격을 보존하고 application runtime을 추가하지 않는다.
|
||
3. 새 독립 프로젝트의 이름은 `Chronos`로 확정한다. 저장소·CLI·daemon의 기본 이름은 각각 `chronos`, `chronos`, `chronosd`로 사용한다.
|
||
4. 단계 2의 완료된 `iop-agent` 선별 이전과 IOP standalone 의존성 제거는 [IOP 선행 분리 Milestone](agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md)이 유일한 실행 source of truth다.
|
||
5. Chronos scaffold와 후속 Roadmap은 미리 둘 수 있지만, IOP 선행 Milestone이 완료되어 workspace 잠금이 해제되기 전에는 Chronos의 아키텍처 리뷰, 구현 plan 또는 product code 작업을 시작하지 않는다.
|
||
6. 선행 분리 완료 뒤 Chronos 제품 작업은 Chronos Roadmap에서 이어간다. 이후 IOP·OTO repository 코드를 바꾸는 기능은 해당 repository의 local Milestone과 Chronos Milestone을 명시적으로 연결해 실행 책임과 완료 evidence를 분리한다.
|
||
|
||
## 프로젝트 이름과 상징
|
||
|
||
프로젝트명은 **Chronos**로 확정한다.
|
||
|
||
사용자가 기존 skill/runtime에 일을 맡겨 실제로 얻은 가장 큰 가치는 자신의 시간이 크게 늘어난 것이다. Chronos는 단순 scheduler 명칭이 아니라 다음 경험을 상징한다.
|
||
|
||
> 일의 시간을 Chronos에게 맡기고, 내 시간을 되찾는다.
|
||
|
||
Chronos가 작업을 `Plan → Work → Review → Recovery` 순서로 계속 진행하는 동안 사용자는 작업을 상시 감시하지 않는다. 이름은 체계적으로 흐르는 작업 시간과 사용자에게 반환되는 시간을 함께 뜻한다.
|
||
|
||
- 영문 문구: `Chronos — Take your time back.`
|
||
- 한국어 문구: `일은 맡기고, 시간은 되찾다.`
|
||
- 저장소 기본명: `chronos`
|
||
- CLI 기본명: `chronos`
|
||
- daemon 기본명: `chronosd`
|
||
- runtime package/product family: `chronos-runtime`
|
||
- Node bridge kind 후보: `chronos-agent`
|
||
|
||
동명의 scheduler·workflow·AI 제품이 존재한다는 점은 인지하고 선택했다. 내부/초기 프로젝트명은 `Chronos`로 유지하고, 공개 배포 시점에만 조직 prefix, package namespace, domain·상표 충돌을 별도 검토한다. 다음 세션이 충돌만을 이유로 이름을 다시 열지 않는다.
|
||
|
||
## 최종 방향
|
||
|
||
현재 `/config/workspace/iop`에 통합된 완료 `iop-agent` 구현을 선행 source로 삼아 standalone daemon/runtime의 제품 소유권을 Chronos 프로젝트로 이전한다. `/config/workspace/iop-s0`는 완료 당시 snapshot 참고 경로로만 사용한다. Chronos는 Node에 내장하지 않는다. 로컬 사용에서 Node는 필수가 아니다. IOP 관리 환경에서만 Node가 선택적 `domain-agent gateway`가 되어 기존 outbound Edge 연결과 로컬 Chronos 연결을 중계한다.
|
||
|
||
```text
|
||
Local standalone
|
||
|
||
CLI / Skill / Flutter / Unity
|
||
↕ versioned local control
|
||
Chronos daemon (`chronosd`)
|
||
↕
|
||
workflow runtime과 durable state
|
||
|
||
IOP managed
|
||
|
||
Control Plane → Edge → 기존 Node outbound session
|
||
↕
|
||
Node agent_bridge gateway
|
||
↕ local typed connection
|
||
동일한 Chronos daemon
|
||
```
|
||
|
||
책임은 다음과 같이 고정한다.
|
||
|
||
| 소유자 | 책임 |
|
||
|---|---|
|
||
| `agentic-framework` | 어디든 설치 가능한 agent-ops 공통 규칙·skill·sync framework. Chronos runtime을 포함하지 않음 |
|
||
| `Chronos` | standalone runtime core, CLI/daemon, local control, workflow adapter, durable state/replay, scoped execution, Roadmap lifecycle 조합 |
|
||
| IOP Node | 로컬 agent discovery/registration, capability·health, admission, request correlation, bounded relay, timeout/backpressure, Edge 연결 중계 |
|
||
| IOP Edge/Control Plane | 원격 principal authorization, Node/agent routing, command/event summary, audit와 운영 표면 |
|
||
| OTO | pipeline/job/artifact/log 의미와 실행 상태의 원본 |
|
||
| Flutter/Unity | runtime client. CLI를 감싸지 않고 versioned local proto-socket 계열 계약을 직접 사용 |
|
||
|
||
Node는 workflow artifact, Plan/Review 해석, project state, OTO job state의 원본을 소유하지 않는다. Node 또는 Edge 연결이 끊겨도 이미 수락된 standalone 작업은 계속되어야 한다.
|
||
|
||
## Provider 경계
|
||
|
||
외부에서는 하나의 provider/resource 계열로 발견할 수 있지만, 기존 model/CLI provider와 같은 실행 의미로 합치지 않는다.
|
||
|
||
```text
|
||
agent_bridge provider framework
|
||
├─ kind: chronos-agent
|
||
└─ kind: oto-runner
|
||
```
|
||
|
||
공유 가능한 것은 다음 lifecycle뿐이다.
|
||
|
||
- versioned registration과 stable instance identity
|
||
- capability catalog와 availability/health
|
||
- command correlation과 idempotency
|
||
- ordered event, result, cancel/stop
|
||
- disconnect/reconnect와 snapshot/replay
|
||
- capacity, timeout, bounded queue와 audit metadata
|
||
|
||
Chronos의 Plan/Review/Milestone 상태와 OTO의 pipeline/job/artifact payload는 kind별 typed driver가 소유한다. 자유형 terminal output, model prompt/delta, HTTP `ProviderTunnel` body로 변환하지 않는다.
|
||
|
||
Node의 기존 terminal/CLI 기능은 설치·bootstrap·업데이트·비상 진단 후보일 뿐 정상 제어면이 아니다. `chronosd`를 terminal에서 실행하고 stdout을 파싱하는 구조는 singleton ownership, command correlation, cancel/resume, event ordering과 crash recovery를 중복 구현하게 하므로 폐기한다.
|
||
|
||
## 제품 사용 표면
|
||
|
||
같은 runtime을 다음 범위로 독립 사용 가능해야 한다.
|
||
|
||
- Plan/Review cycle만 실행
|
||
- 하나의 Milestone 범위만 실행
|
||
- 여러 Milestone을 포함한 전체 Roadmap lifecycle 실행
|
||
- 로컬 CLI에서 수동 시작·상태·중단·재개
|
||
- agent용 Skill이 CLI 또는 안정된 client interface를 통해 같은 기능 사용
|
||
- Flutter/Unity가 local control 계약으로 상태·event·control 사용
|
||
- IOP 관리 환경에서 Node gateway를 통한 선택적 원격 상태·제어
|
||
|
||
Plan/Review cycle의 상태 의미와 artifact 규칙은 공통 core가 소유한다. 실행 위치에 따라 adapter를 분리한다.
|
||
|
||
- 로컬 workflow: plan, work, review를 동일 사용자 장비의 standalone runtime이 수행한다.
|
||
- remote user-agent workflow: plan, work, review 요청과 결과가 모두 원격 사용자 agent를 통과한다. 공통 cycle을 사용하지만 transport, executor, retry, attention/승인 경로는 별도 adapter다.
|
||
|
||
따라서 실행 지점이 같다는 이유로 두 workflow를 하나의 pipeline 구현으로 강제하지 않는다. 공통 core는 cycle state와 transition을 제공하고, local/remote adapter가 각 수행 방식을 제공한다.
|
||
|
||
## OTO에서 흡수할 것과 버릴 것
|
||
|
||
OTO에서 제품화할 핵심은 `agent가 outbound 장기 session으로 등록 → capability 보고 → server push 수신 → heartbeat/report`하는 연결 패턴이다.
|
||
|
||
흡수한다.
|
||
|
||
- session abstraction
|
||
- protocol/capability version registration
|
||
- heartbeat와 disconnect 처리
|
||
- duplicate connection 교체
|
||
- server-push command와 typed report
|
||
- execution ownership 검사
|
||
|
||
그대로 가져오지 않는다.
|
||
|
||
- legacy OTO→IOP Edge direct registration code
|
||
- OTO domain proto를 Chronos에도 공통 적용
|
||
- 빈 값 여부만 확인하는 enrollment token
|
||
- TLS, reconnect/backoff, 실제 cancel 집행이 빠진 현재 한계
|
||
- Node가 OTO scheduler나 artifact/log store가 되는 구조
|
||
|
||
OTO와 Chronos는 같은 `agent_bridge` framework 아래 서로 다른 driver/instance로 둔다.
|
||
|
||
## 로컬 연결과 보안 경계
|
||
|
||
현재 iop-agent local control에서 검증 중인 Unix socket `0600`, owner-only state root `0700`, 동일 effective UID peer 경계를 Chronos 이전 후에도 보존한다. 이 경계를 원격 통합을 위해 느슨하게 만들지 않는다.
|
||
|
||
초기 후보는 두 단계다.
|
||
|
||
1. 같은 사용자 MVP: Node companion/connector가 Chronos의 owner-only local socket을 사용한다.
|
||
2. system Node 또는 다중 사용자 제품형: 사용자 agent가 Node가 소유한 local gateway로 outbound 등록하고 session을 유지한다. Unix domain socket/Windows named pipe가 목표이며, 공통 transport가 준비되지 않은 초기 구현은 `127.0.0.1` only + ephemeral port + short-lived credential을 사용할 수 있다.
|
||
|
||
어느 경우든 사용자 장비에 외부 inbound port를 추가하지 않는다. 원격 traffic은 기존 Node→Edge outbound session 하나로 multiplex한다.
|
||
|
||
production remote mutation 전 필수 gate:
|
||
|
||
- Edge–Node transport authentication/confidentiality
|
||
- remote principal → local owner/project/workspace scope authorization
|
||
- operation allowlist와 audit
|
||
- stable `command_id`를 이용한 duplicate convergence
|
||
- ordered event relay와 cursor replay
|
||
- replay 범위를 벗어나면 fresh snapshot으로 복구
|
||
- `node online`, `bridge connected`, `agent available`, `project running` 상태 구분
|
||
- 원격 UI start/focus와 임의 shell/path/protobuf forwarding 기본 금지
|
||
|
||
현재 Edge–Node transport에는 mTLS helper가 실제 transport에 연결되지 않았으므로, 이 gate 전에는 production `project.start/stop/resume`을 열지 않는다.
|
||
|
||
## 보류·분리 항목
|
||
|
||
- local LLM 감시/advisor는 현시점 over-spec으로 보류한다. 결정적 runtime monitoring에는 LLM을 넣지 않는다.
|
||
- remote terminal은 별도 기능이다. Node agent gateway와 합치지 않는다.
|
||
- Flutter/Unity는 CLI 제어가 아니라 proto-socket 계열 계약을 사용한다.
|
||
- remote coding 유지보수는 별도 Desktop Agent를 만들지 않고 향후 Chronos의 remote user-agent workflow adapter로 흡수한다.
|
||
- Node가 Chronos process, workflow, durable state를 기본 소유하거나 Edge reconnect 시 종료시키지 않는다.
|
||
- direct specialized agent→Edge protocol은 현재 기본 경로로 부활시키지 않는다.
|
||
- Node와 Chronos의 겹쳐 보이는 코드를 성급히 공통 package로 추출하지 않는다. shared contract/SDK만 먼저 고정하고 실제로 host-neutral한 구현 경계가 증명된 뒤 추출한다.
|
||
|
||
## 단계 기준
|
||
|
||
이전 대화에서 사용한 번호는 다음을 뜻한다.
|
||
|
||
1. 현재 IOP에 통합된 `IOP Agent CLI Runtime` 완료 기준선
|
||
2. `Agent Runtime Ownership Transition`
|
||
- `2A — IOP-owned selective transfer and decoupling`
|
||
- 완료된 standalone runtime에서 Chronos-owned source·contract fixture·behavior input만 독립 staging baseline으로 선별 이전
|
||
- versioned legacy-state export 또는 clean-start marker와 ambiguous-state blocker manifest 생성
|
||
- IOP의 standalone host·workflow·client lifecycle·전용 surface와 Chronos application dependency 제거
|
||
- IOP Node의 finite model/API/CLI provider 실행과 Edge wire 회귀, Chronos 잠금 해제용 transfer receipt 생성
|
||
- `2B — Chronos-owned baseline adoption`
|
||
- transfer receipt와 staging baseline acceptance, 최종 ownership architecture 확정
|
||
- Chronos-owned local control contract와 package·binary·state namespace 수립
|
||
- legacy-state export의 실제 import 또는 clean start, local/offline parity와 adoption receipt 검증
|
||
3. `Scoped Agent Task Execution Surface`
|
||
- Plan/Review, Milestone, Roadmap 범위별 독립 실행과 종료 경계
|
||
4. `Node External Agent Provider Foundation`
|
||
- `agent_bridge` registration, discovery, health, typed command/event/replay
|
||
5. `Edge Managed Agent Routing & Security`
|
||
- Edge–Node remote control wire, authorization, audit, reconnect
|
||
6. `Roadmap Lifecycle Orchestration`
|
||
- 3번 scope를 조합하되 작은 범위 사용성을 보존
|
||
7. `OTO Provider Adapter`
|
||
8. `Remote User-Agent Workflow Bridge`
|
||
|
||
2A는 IOP Roadmap에서 먼저 완료한다. workspace 잠금 해제 뒤 2B와 3번 이후 제품 Roadmap은 Chronos가 소유한다. 4, 5, 7번처럼 구현 파일이 IOP/OTO에 있는 작업은 `[계획]` 승격 전에 각 repository-local Milestone과 Chronos Milestone 사이의 명시적 잠금으로 연결한다.
|
||
|
||
3번과 6번의 local lifecycle 설계는 Node gateway와 독립적으로 진행할 수 있다. 원격 mutation만 5번 보안 gate를 선행한다.
|
||
|
||
## 다음 세션 실행 순서
|
||
|
||
1. [IOP 선행 분리 Milestone](agent-roadmap/phase/automation-runtime-bridge/milestones/iop-agent-chronos-extraction-decoupling.md), [SDD](agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/SDD.md)와 [SDD User Review](agent-roadmap/sdd/automation-runtime-bridge/iop-agent-chronos-extraction-decoupling/USER_REVIEW.md)를 먼저 읽는다.
|
||
2. 기존 project/config/state의 versioned export 범위에 대한 사용자 결정을 SDD에 반영하고 IOP Milestone을 `[계획]`으로 승격한다.
|
||
3. IOP task group에서 source revision과 disposition manifest를 고정하고, Chronos staging baseline·legacy-state export 전달 → destination 독립 검증 → IOP standalone 제거 → 잔류 Node/provider 회귀 순서로 실행한다.
|
||
4. transfer receipt와 양쪽 검증 evidence로 IOP Milestone 완료 검토를 통과시키고 `.agent-roadmap-sync/locks.yaml`의 Chronos 선행 조건을 동기화한다.
|
||
5. 잠금 해제 뒤에만 [Chronos 아키텍처 Milestone](../chronos/agent-roadmap/phase/runtime-ownership-transition/milestones/chronos-architecture-ownership-boundary.md)과 해당 managed connector 검토 항목으로 이동한다.
|
||
6. `agentic-framework`는 경량 공통 프레임워크로 유지하고 Chronos application runtime 또는 Roadmap을 추가하지 않는다.
|
||
|
||
## 필수 탐색 경로
|
||
|
||
### 유지할 `agentic-framework` 경계
|
||
|
||
- [`README.md`](README.md): 현재 저장소가 app runtime이 아닌 agent-ops 공통 원본이라고 명시한다. 저장소 역할 확장은 의식적인 결정이어야 한다.
|
||
- [`agent-ops/rules/common/philosophy.md`](agent-ops/rules/common/philosophy.md): runtime과 LLM 책임, Roadmap과 실행 상태 경계.
|
||
- [`agent-ops/bin/sync.sh`](agent-ops/bin/sync.sh): push 대상은 `agent-ops` 공통 영역으로 제한된다. Chronos는 이 sync payload가 아니라 별도 소비 프로젝트다.
|
||
|
||
### 현재 `iop-agent` 구현과 계약
|
||
|
||
- [`agent-contract/inner/iop-agent-cli-runtime.md`](agent-contract/inner/iop-agent-cli-runtime.md): 완료된 standalone runtime의 현재 구현 계약과 책임 경계. 원래 Milestone 문서는 active Roadmap에서 제거된 과거 근거다.
|
||
- [`../iop-s0/agent-contract/inner/iop-agent-cli-runtime.md`](../iop-s0/agent-contract/inner/iop-agent-cli-runtime.md): extraction source revision으로 고정했던 checkout의 standalone/local control 계약 snapshot.
|
||
- [`proto/iop/agent.proto`](proto/iop/agent.proto): typed envelope, `command_id`, snapshot, event sequence와 replay.
|
||
- [`apps/agent/internal/localcontrol/server.go`](apps/agent/internal/localcontrol/server.go): Unix socket, permission, same-UID peer credential 경계.
|
||
- [`apps/agent/internal/localcontrol/service.go`](apps/agent/internal/localcontrol/service.go): status와 project start/stop/resume port.
|
||
- [`apps/agent/internal/taskloop/workflow.go`](apps/agent/internal/taskloop/workflow.go): agent-ops Plan/Review/Milestone artifact 의존성이 집중된 workflow adapter.
|
||
- [`packages/go/agentruntime/types.go`](packages/go/agentruntime/types.go): 기존 유한 실행 Provider와 agent durable control의 의미 차이.
|
||
|
||
### IOP Node/Edge gateway 후보
|
||
|
||
- [`apps/node/README.md`](apps/node/README.md): 기존 Edge–Node transport, logical session, mTLS 미연결 상태.
|
||
- [`proto/iop/runtime.proto`](proto/iop/runtime.proto): `RunRequest`, `RunEvent`, `NodeCommand`, `ProviderTunnel`; 새 durable agent control을 억지로 넣지 않아야 하는 기존 wire.
|
||
- [`apps/node/internal/transport/session.go`](apps/node/internal/transport/session.go): 기존 단일 Edge–Node session의 message family multiplex.
|
||
- [`proto/iop/control.proto`](proto/iop/control.proto): `EdgeDomainAgentSummary`, `EdgeCommandRequest/Response/Event` scaffold.
|
||
- [`apps/edge/internal/service/status_provider.go`](apps/edge/internal/service/status_provider.go): `GetDomainAgents()`가 현재 비어 있는 integration point.
|
||
- [`apps/edge/internal/service/control_command.go`](apps/edge/internal/service/control_command.go): 현재 `agent.command`가 제한적 scaffold인 상태.
|
||
- [`agent-roadmap/phase/control-plane-portal-ops/milestones/multi-edge-operations.md`](agent-roadmap/phase/control-plane-portal-ops/milestones/multi-edge-operations.md): OTO/build-deploy를 Edge-owned domain-agent summary로 노출한다는 기존 결정.
|
||
- [`agent-roadmap/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md`](agent-roadmap/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md): remote terminal을 별도 기능으로 유지하는 경계.
|
||
|
||
### OTO 연결 패턴
|
||
|
||
- [`../oto/proto/oto/runner.proto`](../oto/proto/oto/runner.proto): registration, capability, heartbeat, push run/cancel, report 계약.
|
||
- [`../oto/apps/runner/lib/oto/agent/registration_client.dart`](../oto/apps/runner/lib/oto/agent/registration_client.dart): 현재 outbound session abstraction.
|
||
- [`../oto/apps/runner/lib/oto/agent/agent_runner.dart`](../oto/apps/runner/lib/oto/agent/agent_runner.dart): push job loop와 현재 cancel 한계.
|
||
- [`../oto/apps/runner/lib/oto/agent/edge_registration_client.dart`](../oto/apps/runner/lib/oto/agent/edge_registration_client.dart): legacy direct IOP Edge client임을 파일 자체가 명시한다.
|
||
- [`../oto/services/core/internal/runnersocket/server.go`](../oto/services/core/internal/runnersocket/server.go): runner registry, push, duplicate connection과 report ownership 패턴.
|
||
- [`../oto/services/core/internal/runnerregistry/registry.go`](../oto/services/core/internal/runnerregistry/registry.go): capability/version 검사와 현재 enrollment 검증 한계.
|
||
|
||
### 보조 컨텍스트
|
||
|
||
- 이전 Codex context ID: `019fb30f-08e6-7643-bc73-ef72a3199dcb`
|
||
- 위 context를 조회할 수 있으면 보조 근거로만 사용한다. 이 handoff의 사용자 확정 사항과 책임 경계를 우선한다.
|
||
|
||
## 작업 상태와 검증
|
||
|
||
- `/config/workspace/chronos`에는 최소 Go scaffold, Agent-Ops와 후속 Roadmap이 생성되어 있지만 application runtime 구현은 시작하지 않았다.
|
||
- `/config/workspace/iop`의 현재 완료된 `iop-agent` code와 [IOP Agent CLI Runtime 계약](agent-contract/inner/iop-agent-cli-runtime.md)을 선별 이전 source로 사용한다. `/config/workspace/iop-s0`는 과거 완료 snapshot 참고 경로일 뿐 이번 선행 Milestone의 실행 owner가 아니다.
|
||
- 이번 정정은 Roadmap·Milestone·SDD·handoff와 workspace lock만 갱신하며 code transfer와 삭제는 수행하지 않는다.
|
||
- 문서 작업이므로 code test는 실행하지 않고 링크·Roadmap 구조·workspace lock과 `git diff --check`를 검증한다.
|