SKIX Runtime 내부 책임 구조
- 이 그림이 답하는 질문: SKIX Runtime 내부에서 공통 판단, 작업 관리, 기능별 책임과 실제 실행 연결을 누가 맡는가?
- 읽는 순서: 위 보호 입구에서 아래 세 책임 영역으로 내려간 뒤, 기능별 책임에서 실제 실행부로 가고 관측값이 공통 상태로 돌아오는 흐름을 본다.
- 현재 검증 범위: Runtime 골격과 JVM 계약을 기준으로 한다. 모든 도메인의 실제 provider 연결과 제품 프로세스 배치는 아직 단계별 검증이 필요하다.
Runtime 요청은 보호 입구 → 공통 상태·정책 판단 영역 → 작업 접수·진행·취소 관리 영역 → 기능별 상태·동작 책임 영역 → 실제 실행 연결로 간다.
관측 결과는 실제 실행 연결 → 공통 상태와 완료 근거 → 앱·상위 지능 서비스 순서로 돌아온다.
| 영역 | 소유권 |
|---|---|
| Entry | caller admission, API version, Manager endpoint lookup |
| Control Plane | Health, State, Evidence, Policy, Resource, Capability |
| Execution Plane | Task, Workflow, Scheduler와 cancel/preempt/timeout |
| Product Domain | AMR, Cleaning, Vision 등 도메인 상태와 규칙 |
| Provider | Agent/ROS 2/native/HAL/MCU adapter |
모든 ManagerService는 managed lifecycle graph에 등록되며 dependency 순서로 시작하고 실패 시 역순 rollback한다. 같은 Runtime process를 쓰더라도 Cleaning과 AirQuality의 state machine과 writer는 합치지 않는다.
근거: ManagerEndpointRegistry.java, FrameworkServiceRegistry.java,
SkixFrameworkCompositionRoot.java, server/domain/*ManagerService.java.