Vendor Open Questions
이 문서는 DeviceAgent/SoC 업체와 구현 전에 닫아야 할 질문과 결정 로그를 관리한다.
반드시 닫아야 하는 질문
| ID | 질문 | 왜 중요한가 | 현재 제안 | 상태 |
|---|---|---|---|---|
| VQ-01 | COMPLETED와 WORKFLOW_COMPLETED를 모두 올릴 것인가 |
Cloud가 task 단위 완료와 workflow 전체 완료를 구분해야 한다. | 둘 다 올린다. COMPLETED는 task, WORKFLOW_COMPLETED는 parent workflow 종료. |
미확정 |
| VQ-02 | event name 표준은 STARTED인가 RUNNING인가 |
Cloud 정상 event allow-list와 맞아야 한다. | DeviceAgent 내부는 STARTED 가능, Cloud 전달 alias로 RUNNING 호환 제공. |
미확정 |
| VQ-03 | snake_case와 camelCase를 모두 제공할 것인가 | Cloud/온디바이스/parser 호환성을 높인다. | trace와 reason 핵심 필드는 당분간 둘 다 제공. | 미확정 |
| VQ-04 | LOW_BATTERY, DEVICE_BUSY의 requires_cloud_decision 기본값은 무엇인가 |
Cloud replan 비용과 사용자 경험에 영향이 있다. | 자동 재시도/대기 가능하면 false, 사용자 선택 필요하면 true. | 미확정 |
| VQ-05 | getDevicePlanningContext snapshot freshness 허용 범위는 얼마인가 |
오래된 위치/배터리/queue 상태로 plan을 만들면 오동작 가능하다. | snapshot_ts 기준 3~5초 이내 또는 stale=true 명시. |
미확정 |
| VQ-06 | workflow 중간 실패 시 남은 subtask는 자동 취소되는가 | 안전성과 사용자 안내가 달라진다. | 기본은 fail-fast 후 remaining subtask cancel. | 미확정 |
| VQ-07 | parallelGroup을 초기 버전에서 지원할 것인가 | 복합명령 범위와 테스트 부담에 영향이 있다. | v1은 sequential 우선, parallel은 명시적으로 제한. | 미확정 |
| VQ-08 | task retry 정책은 어디에서 관리하는가 | Cloud가 재시도할지 DeviceAgent가 재시도할지 경계가 필요하다. | 물리 실행 retry는 DeviceAgent, 의미 재계획은 Cloud. | 미확정 |
| VQ-09 | reason_params에 room name 같은 사용자 정의 값을 어떻게 담는가 |
자연어 custom room은 표준 enum으로 표현하기 어렵다. | target_room_name, target_room_id, raw_target를 함께 제공. |
미확정 |
| VQ-10 | logcat artifact format은 누가 고정하는가 | QA 자동 검증과 vendor 제출물 대조에 필요하다. | Cloud 측 validator 필드 기준으로 DeviceAgent 로그 포맷 합의. | 미확정 |
| VQ-11 | WORKFLOW_STEP_STARTED/COMPLETED를 Cloud까지 올릴 것인가, 온디바이스 내부 상태로만 둘 것인가 |
Cloud audit trail과 토큰/네트워크 비용 사이의 경계가 필요하다. | v1은 온디바이스 audit에 보존하고, Cloud에는 step 완료/실패와 workflow 완료 중심으로 올린다. | 미확정 |
| VQ-12 | getDevicePlanningContext의 room list는 실제 room id/name을 제공할 수 있는가 |
Cloud가 room target plan을 만들 때 hallucination을 줄인다. | 가능한 경우 rooms=[{room_id, room_name, available}] 제공, 불가능하면 available=false와 reason 제공. |
미확정 |
| VQ-13 | DeviceAgent가 native set 명령의 내부 조건 판단 결과를 어떤 reason으로 매핑할 것인가 | 기존 조건 판단을 task화할 때 실패 사유가 안정적으로 올라와야 한다. | 조건별 error code를 TaskReasonContract에 매핑하고 unknown은 최소화한다. |
미확정 |
| VQ-14 | 19.comToMe의 실제 task method 이름을 comeToMe로 확정할 수 있는가 |
Cloud/On-device/DeviceAgent contract가 같은 method를 써야 한다. | v1 문서에서는 comeToMe를 기준명으로 둔다. |
미확정 |
| VQ-15 | ComeToMe를 공통 TaskManager executor로 구현할 것인가, 별도 ComeToMeTaskManager로 구현할 것인가 |
DoA/Vision/AMR/FollowMe lifecycle이 길어서 책임 경계가 필요하다. | 공통 TaskManager 아래 domain executor 또는 얇은 ComeToMeTaskManager를 둔다. |
미확정 |
| VQ-16 | ComeToMe stage gate 값 0-1, 0-2, 1, 2, 3을 DeviceAgent 설정으로 제공할 것인가 |
단계 밖 기능 실행을 막는 핵심 safety gate다. | DeviceAgent local config 또는 feature flag로 제공한다. | 미확정 |
| VQ-17 | Speaker profile과 room mapping store의 소유권은 누구에게 있는가 | stage 1 화자인식과 0-2 장소 이동이 이 저장소에 의존한다. | DeviceAgent/SoC가 store와 조회 API를 제공하고 Cloud에는 snapshot만 제공한다. | 미확정 |
| VQ-18 | DoA/Vision/AMR/FollowMe callback payload에 confidence, timestamp, pose, target continuity를 포함할 수 있는가 | ComeToMe 실패 분석과 FollowMe 전환 안정성 검증에 필요하다. | 최소 event payload schema를 19.comToMe DeviceAgent Contract에 맞춘다. | 미확정 |
결정 로그 양식
| 날짜 | 질문 ID | 결정 | 영향 문서 | 담당 |
|---|---|---|---|---|
회의 전 준비물
업체 회의 전에 아래 자료를 공유해야 한다.
- DeviceAgent Vendor Implementation Package
- 19.comToMe DeviceAgent Contract
- DeviceAgent TaskManager API Contract
- Vendor API Acceptance Checklist
- Vendor Test Evidence Template
- Requirements Traceability Matrix
합의 후 업데이트해야 하는 문서
질문이 닫히면 아래 문서에 반영해야 한다.
- API/event 필드 변경: DeviceAgent TaskManager API Contract
- 인수 기준 변경: Vendor API Acceptance Checklist
- 릴리스 블로커 변경: Requirements Traceability Matrix
- 검증 절차 변경: Validation Guide