← Docs hub

A2A Validation Guide

이 페이지는 현재 구조가 실제로 동작한다고 말하기 위해 필요한 검증 단계를 정리한다.

검증 레벨

현재 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를 찾는다.