요청이 실제 완료 근거로 돌아오는 구조
- 이 그림이 답하는 질문: 앱 요청이 어떤 확인과 실행을 거쳐 실제 완료 근거로 돌아오는가?
- 읽는 순서: 위쪽 1번부터 6번까지 요청을 따라가고, 아래 초록 점선의 진행 결과→Evidence→계획 수정 순서로 돌아온다.
- 현재 검증 범위: 요청·Task·상태·근거 계약을 표현한다. provider의 물리 완료와 실기기 관측 연결은 별도 검증 대상이다.
정상 흐름
- App/상위 지능 서비스가 typed Manager로 request/trace ID와 명령을 제출한다.
- Root Binder가 호출자와 권한 확인을 수행하고 도메인 Binder를 반환한다.
- Task/Workflow가 장기 작업 접수를 수행하고 Task ID를 만든다.
- Policy/Resource가 현재 State에 대해 정책 판단과 자원 중재를 수행한다.
- Domain ManagerService가 단일 command owner로 실행 요청 전달을 수행한다.
- Agent/ROS 2/HAL이 feedback·observation·completion의 진행 결과 반환을 수행한다.
- State/Evidence가 결과를 공통 상태로 반영하고 상위 지능 서비스/subscriber가 필요하면 계획 수정을 수행한다.
accepted != physically completed다. denial은 안정된 reason code를 반환하며, timeout/caller death/provider
death는 Task를 방치하지 않고 cancel/recovery 경로로 보낸다.
근거: ISkixFrameworkService.aidl, FrameworkAdmissionController.java, TaskManagerService.java,
PolicyManagerService.java, StateManagerService.java.