← Docs hub

Task Scheduling Runtime Readiness

TaskManager의 시간 실행 구조, 현재 구현, 테스트와 실기기 증거를 한 문서에서 관리한다. 제품의 반복 Schedule, Workflow 내부 지연, TaskManager의 단기 예약을 구분하고 구현됨, 자동 검증됨, 실기기 미검증, 미구현을 분리한다.

1. 2026-07-26 기준 결론

TaskManager scheduling은 단순 아이디어 단계가 아니다. 예약 저장, due admission, exact alarm opt-in, boot 이후 재등록, missed-run grace까지 소스에 들어와 있다.

단일 상대시간 예약의 등록, 재부팅 후 record 복원, 조회, 취소, request_id 멱등성은 실기기에서 확인했다. 이어서 수동 due admission으로 단일 DIRECT task가 한 번만 실행되는 것과 missed-run BLOCKED callback이 Cloud replan으로 이어지는 것도 확인했다. 하지만 다음 두 문장은 아직 증명되지 않았다.

1. exact alarm 또는 periodic worker가 실제 due 시점에 자동으로 한 번만 실행한다.
2. 단말 재부팅 후 exact alarm 재등록부터 due 실행까지 중복 없이 이어진다.

따라서 현재 상태는 다음과 같다.

API/저장/due admission/exact alarm source 구현
  -> JVM 회귀 테스트 통과
  -> Cloud schedule 계약 테스트 통과
  -> 실기기 등록/boot restore/query/cancel/idempotency 통과
  -> 수동 due DIRECT 실행과 scheduleId/taskId correlation 통과
  -> missed-run BLOCKED -> on-device -> Cloud replan 통과
  -> exact alarm/periodic worker 자동 due E2E는 미완료

2. 근거 소스

기준 경로:

/home/silogood/work/1.A1_SoC_new/SoC/a1-packages-mr6/apps/DeviceAgent
/home/silogood/work/1.A1_SoC_new/SoC/a1-packages-mr6/apps/TaskManagerClient

3. 구현·검증 매트릭스

source ready는 코드가 존재한다는 뜻이지 제품 release ready라는 뜻이 아니다.

시간 실행의 세 계층

세 계층은 같은 문장을 처리할 수 있어도 생명주기와 반복 정책이 다르다. due 시점에는 모두 fresh device context로 재검증한 뒤 기존 submitTask 또는 submitWorkflow runtime에 재진입한다.

4. 이번 턴의 fresh test evidence

2026-07-26에 아래 테스트를 새로 실행했다.

Cloud 테스트 범위:

test_schedule_session_state.py
test_schedule_workflow_router.py
test_schedule_workflow_orchestrator.py
test_schedule_multiturn_sequence_flow.py
test_task_orchestration_roundtrip.py

실기기 증거:

• 발화: 60분 뒤에 고정청정 시작해줘
• Cloud: relative_delay_seconds=3600
• On-device: relativeDelayMs=3600000, scheduleTask
• MR6: scheduleId=scheduled-4, state=SCHEDULED
• TTS: 60분 뒤에 고정 청정 시작하도록 예약했어요.
• 동일 request_id 재전송: deduplicated=true, 기존 scheduled-4 반환
• DeviceAgent 재부팅 후 API 조회: scheduled-4 복원
• API command envelope source와 record query source 충돌 수정 확인
• 검증 종료 후 scheduled-3, scheduled-4 취소, 활성 예약 0건
• 안전 조회 task getBatteryInfo 예약: scheduleId=scheduled-6
• 수동 due admission: admittedTaskId=getBatteryInfo-1
• event: STARTED 1회, COMPLETED 1회
• 동일 requestId 재전송: deduplicated=true, scheduled-6 유지, 추가 실행 event 없음
• missed-run 예약: scheduleId=scheduled-9, missedRunGraceMs=1000
• grace 초과 due: admittedCount=0, skippedCount=1, BLOCKED(reason=MISSED_RUN_EXPIRED), actuator 미실행
• ACK와 하위 blocked item 모두 requires_cloud_decision=true 보존
• DeviceAgent onTaskEvent -> on-device DeviceCommunicator -> local Cloud shim 전달
• Cloud 정규화: failure_type=schedule_missed, replan_action=ask_user
• 사용자 응답: 예약 시각이 지나 작업을 시작하지 못했어요. 새 시간을 정할까요?
• 예약 취소 시 CANCELLED task event 발행
• Worker가 terminal event를 반영해 검증용 BLOCKED 항목을 currentTasks에서 제거, 최종 active task 0건 확인

기존 추가 저장 증거:

• non-motion shadow r31: 60/60
• context-safe read-only live r32: 10/10

r31/r32는 전체 scheduling 실기기 증거가 아니다. route, 계약, read-only context 경로의 증거로만 사용한다. 2026-07-26 추가 증거는 수동 due와 missed-run replan을 포함하지만 exact alarm, periodic worker, 재부팅 후 자동 due 실행은 포함하지 않는다.

5. 실제 runtime 상태 전이

scheduleTask / scheduleWorkflow
  -> SCHEDULED
  -> durable snapshot
  -> periodic worker 또는 exact alarm
  -> runDueScheduledTasks
  -> fresh device context + policy admission
       |- 허용: submitTask / submitWorkflow -> ADMITTED
       `- 거절: BLOCKED + reason + requires_cloud_decision
  -> 기존 TaskManager runtime
  -> RUNNING / PAUSED / COMPLETED / FAILED / CANCELLED

예약 등록과 실행 runtime은 별도 엔진이 아니다. due 이후 기존 submitTask 또는 submitWorkflow로 재진입해야 queue, executor, callback, reason contract를 재사용한다.

6. 현재 opt-in 운영점

기본 비활성 또는 opt-in 항목은 단말 제품 정책과 배터리 영향 검토 없이 기본값을 바꾸지 않는다.

7. 남은 구현

7.1 계약 보강

• 모든 schedule record에 scheduleId, traceId, admittedTaskId, cloudWorkflowId 상관관계를 유지한다. 단일 DIRECT task는 확인했고 workflow correlation은 추가 검증한다.
• scheduled 상태 전이도 onTaskEvent와 같은 reason/event envelope로 노출한다.
• target room은 저장된 숫자 ID만 믿지 않고 실행 직전 room context로 resolve한다.
• requires_cloud_decision event에는 대체 가능한 capability와 blocker를 함께 제공한다.

7.2 Cloud 폐루프

• BLOCKED/FAILED/TIMEOUT만 Cloud replan 후보로 전달한다. missed-run BLOCKED는 실기기 폐루프까지 확인했다.
• 정상 due, admitted, progress는 monitor/UI 갱신으로 끝낸다.
• 동일 event 재전송은 workflow/state etag로 중복 제거한다.
• replan 결과는 기존 schedule을 갱신할지, 취소하고 새 schedule을 만들지 명시한다.

7.3 UI

• SCHEDULED, DUE, BLOCKED, ADMITTED, RUNNING을 서로 다른 상태로 보여준다.
• scheduleId에서 admitted taskId로 이어지는 correlation을 한 timeline에 표시한다.
• exact/periodic trigger, missed-run, boot restore 여부를 operator evidence로 남긴다.
• 사용자용 UI에는 내부 reason code 대신 행동 가능한 설명을 제공한다.

8. 다음 검증 순서

Gate A. Contract

1. 등록 payload schema
2. 조회/취소
3. scheduleId/taskId correlation
4. event/reason 필드

Gate B. Host/Unit

1. snapshot write/read
2. due boundary
3. missed-run grace
4. busy/context block
5. duplicate alarm

Gate C. Virtual/Shadow

1. 자연어 -> scheduleWorkflow
2. due event -> admission
3. blocked -> Cloud decision
4. user clarification
5. cancel/update

Gate D. Read-only live

1. property 확인
2. 등록 목록 조회
3. alarm registration dump 확인
4. TaskManager 상태와 monitor correlation

Gate E. State-changing live

1. 2~5분 뒤 단일 설정 task
2. due workflow 실행
3. 음성 세션 중 due -> pause/resume
4. busy block
5. cancel before due

Gate F. Reboot

1. 미래 schedule 등록
2. 단말 재부팅
3. LOCKED_BOOT_COMPLETED 수신
4. exact alarm 재등록
5. due admission
6. missed-run policy 판정

9. Release evidence bundle

각 실기기 시나리오는 아래를 한 묶음으로 보관한다.

test case id
schedule request JSON
getScheduledTasks before/after
alarm/worker registration evidence
TaskManager event timeline
scheduleId -> admittedTaskId correlation
DeviceAgent logcat slice
Cloud task_event / replan trace
monitor screenshot
final verdict

APK 교체가 필요한 검증은 platform cert를 먼저 확인한다. Android debug cert APK를 /system/priv-app에 push하지 않는다.

10. Exit criteria

TaskManager scheduling을 제품 검증 완료로 표기하려면 아래가 모두 필요하다.

1. exact alarm과 periodic worker 각각 1개 이상의 실기기 증거가 있다.
2. 재부팅 전후 같은 scheduleId가 복원되고 중복 실행되지 않는다.
3. missed-run grace 초과 시 actuator가 실행되지 않는다.
4. due 시점 busy/voice-active 상태에서 policy대로 block 또는 pause된다.
5. blocked event가 Cloud decision 또는 사용자 확인으로 이어진다.
6. monitor가 schedule -> admission -> runtime 전체 correlation을 보여준다.
7. 기존 즉시 task/workflow 회귀 성능과 성공률이 유지된다.

11. 이어서 볼 문서

• Core 예약 규범: TaskManager 기준 사양서
• 상위 목표와 성능 예산: Experience Supervisor
• 운영 상태와 trace: TaskManager Live Monitor