← Docs hub

DeviceAgent Executor Closure Matrix

이 문서는 MR6 DeviceAgent의 60개 TaskManager executor를 “호출할 수 있는가” 가 아니라 Planner가 계획하고, 기기가 실행하고, callback으로 완료를 증명할 수 있는가 기준으로 분류한다.

1. 쉽게 읽는 법

사용자 목표
  -> Planner가 의미 capability와 단계를 만든다
  -> On-device가 taskMethod 계약을 전달한다
  -> TaskManager가 순서·취소·timeout을 관리한다
  -> DeviceAgent domain이 실제 기능을 수행한다
  -> callback이 완료·실패·취소를 증명한다
  -> 필요하면 Planner가 다음 단계를 바꾼다

2. 현재 결과

60개가 모두 사용자용 기능인 것은 아니다. 특히 내부 lifecycle method를 Planner capability로 그대로 공개하면 안전 경계와 계약이 무너진다.

3. Domain별 폐쇄성

Framework

Main API

Movement

Cleaning

LLM / TTS

IoT / Settings

Routine / LED

Product Schedule / Interaction

Firmware Update

4. 현재 가장 중요한 구조 차이

4.1 Cloud method와 MR6 executor가 완전히 같지 않다

Cloud compiler는 setLanguage, setPuiWaitingScreenTheme를 생성할 수 있지만 두 method는 MR6 전용 executor 60개에 포함되지 않는다. 현재 동작한다면 TaskManager의 legacy command factory fallback에 의존하는 것이다. strict managed-only 경로로 전환하기 전에 전용 executor 또는 setConfig 정규화 계약을 선택해야 한다.

4.2 On-device 범용 전달은 병목이 아니다

On-device ManagedDeviceTask는 청정 위치·상태를 보정하는 경우 외에는 Cloud의 taskMethod와 workflow metadata를 그대로 DeviceAgent에 전달한다. 따라서 다음 기능을 추가할 때마다 새로운 발화 문자열 adapter를 만드는 방식은 필요하지 않다.

4.3 다음 우선순위는 Interaction이다

interSchedule은 welcome, wake-up, relax 흐름과 다음 완료 evidence를 이미 가지고 있다.

• interaction.started
• interaction.arrived
• interaction.actionStarted
• interaction.actionEnded
• interaction.returning
• interaction.completed

하지만 Cloud capability registry와 typed action compiler가 연결되지 않아 Planner가 이 lifecycle을 복합 workflow에 안전하게 배치할 수 없다. 다음 보강은 사용자 문장 keyword가 아니라 다음 구조화 계약이어야 한다.

{
  "capability_id": "interaction_experience",
  "operation": "start",
  "arguments": {
    "experience_type": "welcome",
    "schedule_id": "..."
  },
  "completion_target": "interaction.completed"
}

5. 변경 설명 원칙

이후 구현 설명은 파일 목록보다 아래 흐름을 먼저 사용한다.

무엇을 하려는가
-> 어떤 상태를 확인하는가
-> Planner가 어떤 단계로 나눴는가
-> TaskManager가 무엇을 관리하는가
-> 어떤 callback을 성공 증거로 썼는가
-> 실패하면 무엇을 다시 계획하는가

이 기준으로 “소스에 함수가 있다”, “TaskManager에 등록됐다”, “Cloud에서 계획된다”, “실기기에서 완료까지 검증됐다”를 서로 다른 상태로 기록한다.