PUI and Voice Task Design Hub
PUI, Voice, IoT와 Cloud가 같은 기기 기능을 호출할 때, 입력 방식은 달라도 실행 계약은 하나로 수렴해야 한다. 이 문서는 무엇을 Task로 만들고, 어떤 capability를 어떤 정책으로 실행할지 압축해서 정의한다.
1. 공통 변환 모델
source input
-> canonical capability
-> action and resolved slots
-> taskMethod or workflow
-> queue and policy
-> progress, terminal event and reason
기능명과 발화는 public language이고 taskMethod와 payload는 execution language다. 고정 청정, 화면 버튼과 음성 표현이 달라도 최종 실행은 동일한 canonical method를 사용한다.
2. Task 경계
| 유형 | 처리 |
|---|---|
| 장시간 물리 동작 | Task: 이동, 청정, 복귀, 따라오기 |
| 사용자 종료가 필요한 앱·모드 | 장기 Task: 바이탈, 보안, Welcome |
| 짧지만 상태 변경이 있는 기능 | 정책에 따라 Task 또는 direct setting |
| 단순 조회 | direct query, 필요하면 planning context에 반영 |
| 모호한 실행 요청 | slot을 완성하기 전에는 Task 제출 금지 |
| 여러 동작의 순서 | Workflow와 dependency로 표현 |
Task 후보는 최소한 실행 method, 입력 schema, queue, completion evidence, cancel·timeout, reason mapping을 가져야 한다. 이 항목 중 하나라도 정의되지 않으면 capability catalog에는 노출할 수 있어도 live 실행에는 허용하지 않는다.
3. Source별 정책
| source | 기본 특성 | 실행 정책 |
|---|---|---|
| PUI | 사용자가 화면에서 대상과 옵션을 직접 선택 | slot이 완성되면 빠르게 실행, 현재 화면·모드와 충돌 확인 |
| Voice | STT 오류와 대상 생략 가능 | capability와 slot confidence가 낮으면 확인 후 실행 |
| IoT·관제 | 구조화 payload와 원격 요청 | caller 인증, idempotency와 device policy 우선 |
| 내부 이벤트·예약 | 사용자 발화 없이 자동 발생 | due 시점 context 재검증, 사용자 방해와 안전 정책 적용 |
| Cloud Planner | 동적 단계와 의존관계 | catalog에 있는 capability만 사용, bounded replanning |
source별 차이는 admission policy에 둔다. executor와 completion evidence를 별도로 복제하지 않는다.
4. Capability catalog 최소 필드
| 필드 | 설명 |
|---|---|
capability_id |
Planner와 제품 시나리오가 사용하는 안정된 기능 ID |
task_method |
DeviceAgent canonical method |
actions |
start, stop, pause, resume, query 등 허용 동작 |
required_slots |
실행 전에 반드시 확정할 값 |
queue, priority |
자원과 실행 순서 정책 |
execution_mode |
direct, queued wait, async |
completion_target |
실제 완료를 증명하는 상태 또는 callback |
cancel_method |
사용자 취소와 보상 동작 |
timeout_ms |
무한 대기를 막는 상한 |
constraints |
battery, privacy, voice session, busy 등 실행 조건 |
live_tier |
shadow, read-only, state-changing 등 허용 단계 |
전체 capability와 실제 executor closure는 Capability Composition Catalog을 기준으로 한다.
5. Workflow 패턴
순차 실행
이동 완료 후 청정처럼 이전 단계의 physical completion을 기다린다.
병렬 실행
서로 다른 자원을 사용하고 안전 정책이 허용하는 단계만 parallelGroup으로 묶는다. 같은 movement나 cleaning 자원을 공유하면 직렬화한다.
조건부 실행
Planner는 조건을 구조화하고, TaskManager는 due 또는 선행 단계 완료 시점의 fresh context로 판정한다. 조건이 불확실하면 임의로 실행하지 않는다.
취소와 선점
사용자 취소는 현재 Task를 중단하고 dependent step을 막는다. 긴급 복귀 같은 선점은 허용된 policy에서만 실행하고 기존 Task의 terminal reason을 남긴다.
실패 후 처리
deterministic retry가 허용되면 정해진 상한 안에서 로컬 재시도한다. capability 대체, 목표 변경 또는 사용자 확인이 필요하면 구조화된 reason과 현재 상태를 상위에 전달한다.
6. 도메인 기본 분류
| domain | queue | 대표 기능 | 완료 기준 예 |
|---|---|---|---|
| Movement | movement |
이동, 복귀, 회전, 따라오기 | 도착, 도킹, 정지 |
| Cleaning | cleaning |
청정 시작·중지, 선택 청정 | 청정 종료 callback |
| Workflow | workflow |
이동·청정·복귀 조합 | 모든 필수 단계 terminal |
| Settings | settings / state |
밝기, 음량, 모드 | 상태 반영 또는 ACK |
| Interaction | ai / sound |
TTS, 화면, 앱 세션 | 재생 종료, 화면 전환, 세션 종료 |
| Schedule | schedule |
예약 등록·수정·삭제 | 등록 결과와 due 실행 분리 |
| Safety | state |
privacy, security, lock | 안전 mode 상태 변화 |
| Query | direct | 배터리, 공기질, 필터, 위치 | queue Task가 아닌 조회 결과 |
7. 구현 순서
- 공개 기능과 기존 DeviceAgent method를 조사한다.
- capability ID, action과 slot을 정의한다.
- validator와 source policy를 등록한다.
- executor가 기존 기능 API에 위임하도록 연결한다.
- completion, cancel, timeout과 reason을 연결한다.
- 단일 Task를 host test와 실기기에서 검증한다.
- 검증된 Task만 Workflow 조합과 Planner catalog에 노출한다.
- Console·Monitor에서 plan, dispatch, event와 device response를 확인한다.
8. 완료 기준
- 같은 capability가 PUI·Voice·IoT에서 같은 canonical method로 수렴한다.
- 모호한 Voice 요청은 slot 확정 전 실행되지 않는다.
- long-running 기능의 취소, timeout과 terminal event가 관측된다.
- Workflow가 순서, 반복 occurrence와 completion dependency를 보존한다.
- unsupported capability를 비슷한 기능으로 임의 치환하지 않는다.
- live 실행은 source 존재가 아니라 executor와 physical evidence까지 검증된 기능만 허용한다.