A2A Validation Guide
이 페이지는 현재 구조가 실제로 동작한다고 말하기 위해 필요한 검증 단계를 정리한다.
검증 레벨
| 레벨 | 목적 | ADB 필요 |
|---|---|---|
| Unit | 함수/계약 단위 동작 확인 | 아니오 |
| Contract | Cloud/온디바이스/DeviceAgent payload 정합성 확인 | 아니오 |
| Dry-run | 실제 device request 생성 확인 | 아니오 |
| Integration | 온디바이스 runner와 DeviceAgent mock 연동 확인 | 아니오 또는 일부 |
| Real Device E2E | APK 설치, 발화, logcat, 실제 task 실행 확인 | 예 |
현재 ADB 없이 가능한 검증
pytest -q test/test_task_manager.py
pytest -q test/test_workflow_state.py
pytest -q test/test_task_event_contract_verifier.py
pytest -q test/test_task_orchestration_roundtrip.py
pytest -q test/test_device_task_dry_run_tool.py
목적:
- Planner output이 device request로 변환되는지 확인한다.
- 정상 event가 replan을 만들지 않는지 확인한다.
- 실패 event가 필요한 경우 replan 후보가 되는지 확인한다.
- trace field가 유지되는지 확인한다.
19.comToMe 검증
19.comToMe처럼 내부 lifecycle이 긴 device 기능은 19.comToMe A2A Workflow Example을 기준으로 검증한다.
구현 계약과 callback/reason 기준은 19.comToMe DeviceAgent Contract을 기준으로 본다.
ADB 없이 확인할 수 있는 것:
Cloud plan이 ComeToMe를 ODL device intent로 판단하는지
device_task_requests에 comeToMe task method와 commandType/roomName/rolloutStage가 포함되는지
submitTask 또는 submitWorkflow payload에 cloud trace field가 유지되는지
stage 0-1/0-2/1/2/3별 허용 기능 fixture가 있는지
cloud_step_id / cloud_output_key / cloud_workflow_id가 유지되는지
speaker/location/DoA/Vision/AMR/FollowMe 실패 fixture에서 reason_code / reason_params가 유지되는지
ADB/실기기에서 확인해야 하는 것:
ComeToMe TaskManager가 호출어/의도/stage/speaker/DoA/Vision/AMR/FollowMe lifecycle을 순서대로 관리하는지
0-1에서 "나에게와"만 수행되고 장소명 이동/화자인식이 실행되지 않는지
0-2에서 등록 장소명 좌표 기반 이동이 수행되는지
1단계 이상에서 speaker gate 실패 시 이동을 시작하지 않는지
DoA/Vision/AMR/FollowMe 실패가 FAILED/BLOCKED + reason contract로 올라오는지
실기기에서 확인해야 하는 것
- APK 설치 후 Cloud 복합명령 입력.
- Cloud 응답에
device_task_requests가 포함되는지. - 온디바이스가
device_intent_step을 수신하는지. CloudIntentWorkflowRunner가depends_on에 따라 step을 순차 unlock하는지.- DeviceAgent TaskManager가 실제
sk_100 -> sk_4계열 task를 순차 실행하는지. - 19.comToMe 예시에서는
wakeword -> intent -> stage gate -> speaker gate -> DoA/location -> AMR -> FollowMe순서가 지켜지는지. - logcat에
cloud_plan_id,cloud_step_id,cloud_output_key,WORKFLOW_COMPLETED가 남는지.
Log Evidence
정상 forwarding:
forwarded onTaskEvent to cloud
Cloud intent task event reported
WORKFLOW_COMPLETED
재판단 후보:
FAILED
BLOCKED
PAUSED
requires_cloud_decision=true
reason_code=...
reason_params=...
완료 판정
아래를 모두 만족해야 구조가 실제 단말까지 닫혔다고 볼 수 있다.
- Cloud planner가 기대한 multi-step을 만든다.
- Cloud runtime이
device_task_requests를 만든다. - 온디바이스가 request를 workflow로 실행한다.
- DeviceAgent TaskManager가 task를 queue에 등록하고 순차 실행한다.
- 정상 완료는 로컬에서 다음 step으로 진행한다.
- 실패/차단은 reason code와 함께 Cloud replan 후보로 올라간다.
- artifact validator가 trace field와 event evidence를 찾는다.