← Docs hub

SKIX Robotics Framework — System 6인 Manager R&R 및 전체 TODO

목적: 초안 Blueprint를 그대로 구현 명세로 취급하지 않고 제품 요구와 현재 소스에서 목표 구조를 먼저 도출한다. 그 구조의 각 계층에 결과 책임을 배정하고, HAL 전문 구현 책임이 모든 담당자에게 퍼지지 않도록 경계를 정한다.

현재 문서 상태: 아래 M1–M6은 제안된 책임 슬롯이다. 실제 담당자 이름·투입률·대체 담당은 팀이 배정해야 한다. 이 문서는 특정 개인에게 이미 일이 배정됐다는 뜻이 아니다.

빠른 읽기

책임 배치 한눈에 보기

계층 책임 담당

M1 — System Architecture & Blueprint Owner

책임 결과: 실제 제품 요구와 두 브랜치 근거를 통해 승인 가능한 Blueprint, 계층 경계, R&R과 단계별 구축 범위를 만든다.

• 맡는 일: 요구 traceability와 As-Is/To-Be 구조 통합, 계층 간 dependency와 실행 owner 충돌 조정, 용어·module 추가 gate, architecture decision record(ADR), 구조·범위 승인안.
• 맡지 않는 일: SDK wire 세부 구현(M2), Task/Policy 내부 의미(M3), AMR/Cleaning 기능 정책(M4/M5), Soong/product build와 서비스 기동의 실무 실행(M6), HAL/MCU 구현.
• 설계 작성 방식: 요구·현재 owner·API·control lifecycle·각 domain·장치 계약·build/product topology를 각 담당자가 작성한다. M1은 근거 누락과 경계 충돌을 해결하고 통합 Blueprint를 편집한다.
• 주 협업: M2–M6 각 owner, 지정 BSP/HAL 담당자, 제품 책임자.
• 주요 증거: 요구→caller→owner→source/build→검증 trace, ADR, 승인된 dependency graph, 미결정/외부 의존 register.
• 경로: skix-framework/base 구조, SDK와 service 계층 간 계약, docs/refactor 및 제품 build 결정 기록.

M2 — SDK Contract & App Consumers

책임 결과: 모든 앱과 Framework가 같은 Java/AIDL 의미, artifact 버전, 호환 규칙을 사용한다.

• 맡는 일: public Manager/model/AIDL, 오류·accepted/delivered 의미, compatibility/deprecation, canonical AAR/JAR, 알려진 앱의 typed API 이관과 consumer build matrix.
• 맡지 않는 일: Binder 응답을 물리 동작 완료로 간주하거나 각 앱의 기능 실행 owner를 대체하는 일.
• 주 협업: M4–M6(기능별 contract), M1(AOSP SDK 소비), 실제 앱 owner(UI/lifecycle 승인).
• 주요 증거: local/team API diff ledger, caller/wire 판정, artifact SHA, 모든 영향 앱의 compile/test.
• 경로: skix-framework/base/core, base/compatibility, apps/AirbotSdkProject/skix-framework-sdk, apps/DeviceControlAPI 및 SDK 소비 앱.

M3 — Common Control, Task & Safety

책임 결과: 모든 domain에서 caller 확인, admission, 공통 policy/resource 판단, task/operation 추적과 terminal 상태 의미가 일관된다.

• 맡는 일: identity/authorization, capability, 공통 state freshness, policy/resource arbitration, queue/task/claim/cancel/deadline/completion, Framework health와 공통 lifecycle. Alert/maintenance/self-test와 managed TTS의 Framework-side command/lifecycle 의미도 M3가 맡는다.
• 맡지 않는 일: Android process start/product packaging(M6), AMR/Cleaning 내부 실행 알고리즘(M4/M5), HAL/MCU driver 구현(지정 BSP/HAL owner).
• 주 협업: 각 domain Manager(기능 의미·안전 조건), M2(public contract), M6(service packaging/start), M1(cross-layer decision).
• 주요 증거: decision/state-transition 표, 경쟁·timeout·cancel 회귀, dependency graph/layer checks, 물리 결과와 command ACK 분리. TTS의 Android audio focus/route는 M6과 함께 검증한다.
• 경로: skix-framework/base/services/core/java/.../{control,execution,entrypoint} 및 공통 security/state/resource/task.

제품 기능 담당

M4 — AMR Mobility

책임 결과: 이동·위치·station 작업을 요청부터 상관관계가 있는 AMR 결과와 중단 근거까지 추적한다.

• 맡는 일: AMR API/model, map/position/station 의미, AMR domain policy/state, 기존 DeviceAgent 이동 실행 owner 연결, requestId와 callback correlation, pause/resume/stop.
• 맡지 않는 일: 공통 Task/resource arbiter 재구현, Cleaning 완료 선언, transport 재연결 기반(M6).
• 주 협업: M3(admission/resource), M2(API/caller), M6(Android/runtime integration), 지정 BSP/HAL owner(AMR transport), M1(architecture decision).
• 주요 증거: typed request/result 회귀, 기존 실행 owner 유지, correlated runtime/기기 완료·stop 로그.
• 현재 owner 경로: apps/DeviceAgent/.../device/item/amr/AMRService와 Robot movement controller; 이동 완료 확인 전까지 이 owner를 기준으로 한다.

M5 — Cleaning & SafeCare Operations

책임 결과: 청소·예약·리포트와 SafeCare 운영 흐름의 기능 의미가 유지되고, 중단은 전체 실행이 멈춘 증거로 확인된다.

• 맡는 일: cleaning mode/fan/schedule/report contract, DeviceAgent cleaning executor 연결, SafeCare 기능 흐름과 화면/session caller 간 합의, 하위 동작 stop ACK·전체 stop·timeout·자원 반환 구분.
• 맡지 않는 일: SafeCare 권한 결정(M3), EventAssetAgent 화면/세션의 실제 소유권을 인수했다고 간주하는 일, AMR 이동 실행(M4).
• 주 협업: M3(authority/admission), M2(API와 앱 이관), 현재 DeviceAgent/EventAssetAgent owner, M1(기기 검증).
• 주요 증거: cleaning lifecycle/stop 회귀, schedule/report consumer compile, SafeCare session correlation, 기기 전체 중단 로그.
• 현재 owner 경로: apps/DeviceAgent cleaning managers; SafeCare screen/session은 EventAssetAgent가 소유하고 WSS transport는 현 DeviceAgent owner를 대조한다.

M6 — Android Platform Integration & Verification

책임 결과: 승인된 Framework/SDK 산출물이 Android 제품 빌드와 서비스 실행 경로에 실제로 연결되고, 단계별 검증 증거가 만들어진다.

• 맡는 일: Soong/Gradle/Make 연결, Java/AIDL module compile 경계, APK·package·partition·permission·SELinux 입력, product inclusion, process/service start·restart·Binder discovery, 이미지와 설치·롤백·boot 검증, 검증 matrix와 로그/SHA 보관.
• 맡지 않는 일: Blueprint 최종 cross-layer 구조 결정(M1), SDK 계약(M2), common policy/task semantics(M3), domain 성공·중단 판정(M4/M5), MCU/HAL/BSP driver 구현. HAL 시험은 지정 전문 담당자와 수행한다.
• 주 협업: M1(구조/승인), M2(API artifact/consumer), M3(Binder/runtime lifecycle), M4/M5(기능 acceptance), 지정 BSP/HAL owner(실장치와 ICD).
• 주요 증거: fresh module/APK/image build, artifact SHA와 인증서, package 포함 경로, boot 이후 process/service/Binder 로그, 독립 단계별 미검증 목록.
• HAL 인계 규칙: adapter/framework 쪽은 실제 기능 owner와 M6이 계약·연결을 확인한다. HAL/MCU 코드를 작성할 사람은 WBS에서 이름·역량·일정을 명시한다. 지정자가 없으면 기능은 제품 검증 완료가 아니라 외부 의존 blocker로 남긴다.
• 경로: skix-framework/base/Android.bp, SkixFrameworkService, skix-framework.mk, DeviceAgent/Agent service manifest와 대상 product config. 실제 product config 연결 여부는 별도 증거로 확인한다.

기능별 owner 및 인계표

담당 Manager는 제품 결과에 대한 단일 책임자다. 현재 실행 owner는 현재 command 또는 데이터를 실제 수행·보유하는 코드다. 인계 완료 조건이 충족되기 전까지 기존 owner가 유지된다.

Alert/maintenance/self-test, TTS, SystemUI/display는 서로 다른 결과이므로 한 줄에서 묶지 않는다. 상세 source owner가 불분명한 기능은 W00에서 caller와 producer를 확인하고 기능 책임자를 배정한다. 장치별 행에서 M6은 Android-side integration 책임을 뜻하고, HAL/MCU 구현 책임은 지정 BSP/HAL owner에게 있다. M6은 domain 결과의 A를 자동으로 맡지 않는다.

계층별 산출물과 인계 규칙

HAL 분담: 여섯 명 중 M6을 HAL 코더로 고정하지 않는다. HAL/MCU 드라이버는 WBS에서 이름·역량·일정을 지정한 SoC/BSP 담당자가 구현한다. M6은 Android 쪽 adapter 접점, 제품 build/package/start, 검증 조율을 책임지고, M4/M5와 추가 기능 A는 기능 의미와 안전·중단 수용 조건을 승인한다. 지정 전문가가 없거나 지원 일정이 확인되지 않으면 HAL-dependent 항목은 외부 의존으로 추적하며 완료 처리하지 않는다.

아키텍처 설계 R&R과 결정권

설계 상세 WBS 1.1–1.12와 선행 산출물/gate는 실행 TODO의 설계 단계에 한 번만 관리한다. 이 표는 책임 배치만 보여준다. 작성자(Author)는 근거와 설계 초안을 만들고, Accountable은 해당 결과를 승인한다.

설계 산출물은 아래 다섯 묶음으로 검토한다. 기존 1.1–1.12 번호는 세부 카드 추적용이며, 각 묶음의 산출물이 gate를 통과하기 전에는 다음 단계로 넘어가지 않는다.

작성 원칙: M1은 각 영역의 상세 설계를 대신 쓰지 않는다. M1의 산출물은 통합 요구 지도, 교차경계 ADR, 승인된 target graph와 미결정 register다. M2–M6은 자기 코드/제품 영역의 근거와 계약을 직접 제시한다. 다섯 설계 묶음의 도식은 브랜치 정합 대표 문서의 작업 지도와 설계 구조 SVG를 함께 본다.

책임 공백 처리: 아직 실제 A가 배정되지 않은 Camera, AirQuality, Power, IoT, Interaction, OTA/Provisioning 등의 기능을 M3 또는 M5의 포괄 책임으로 간주하지 않는다. W00에서 현재 caller와 실행 owner를 확인하고 실제 인원/역량/capacity로 기능 A를 지정하기 전까지는 기존 제품 owner 유지 / 신규 설계 승인 보류로 둔다. SDK/API 형식 정합(M2), 공통 control 의미(M3), Android 연결(M6)은 진행할 수 있지만 기능 결과 승인과 실행 owner 이전은 포함하지 않는다.

이 표에서 Author는 문서와 근거를 직접 만든 사람, A는 그 결과의 의미와 완료를 승인하는 한 사람이다. M1은 모든 설계를 대신 작성하지 않는다. 각 계층 A가 자신의 contract와 현재 소스 근거를 만들고, M1은 요구 trace와 계층 간 모순·용어·범위를 통합한다. 제품 빌드·배치 결정은 M6, public/wire 의미는 M2, 공통 lifecycle은 M3, 도메인 동작은 해당 기능 A가 최종 승인한다.

결정권: M1은 교차 계층 구조·용어·범위 충돌을 ADR로 해결한다. M1은 M2–M5가 소유한 의미를 임의로 대신 결정하지 않는다. 제품 build/package/start 결정과 검증 실행은 M6이 맡고, domain 결과를 승인하는 권한은 M4/M5에 남는다. HAL/MCU의 실제 구현 책임은 명시된 BSP/HAL 담당자에게만 부여한다. 상세 설계에서 Camera, AirQuality, Power, IoT, Interaction 등 추가 domain이 확인되면 실제 caller와 current owner 근거로 feature A를 WBS에 따로 등록한다. M5에 자동 합산하거나 “기타 domain” 한 칸에 숨기지 않는다.

협업·결정 규칙

1. 모든 작업 카드에 Accountable 1명, 실제 작성자, 검토자, 현재 execution owner, 완료 증거를 쓴다. 폴더 경로만 보고 담당을 정하지 않는다.
2. API/wire 변경은 M2, 공통 admission/task/resource/state는 M3, 제품 build/package/boot는 M6, cross-layer architecture는 M1, 도메인 결과는 M4/M5 또는 WBS에 지정된 추가 기능 A가 승인한다. 한 변경에 여러 검토자는 있어도 기능 결과 A는 하나다.
3. 팀 SDK branch의 소스나 DeviceAgent의 파일을 가져와도 실행 owner 변경은 별도 설계·테스트·기기 증거가 있기 전까지 선언하지 않는다.
4. 테스트, APK 생성, 이미지 포함, 서비스 기동, Binder 성공, 실제 AMR/Cleaning 동작은 다른 완료 단계다. 상위 단계 증거 없이 완료로 표시하지 않는다.
5. 실제 인원 배정 시 업무량이 같다고 가정하지 않는다. 1~2주 capacity, 운영·긴급 대응 비중, 대체자, 교차 리뷰 가능성을 함께 적고 M6/플랫폼 병목을 재평가한다.

전체 WBS / TODO

아래 목록은 현재 SKIX Framework 작업 범위를 코드 기준으로 나눈 WBS다. TV SoC 예시의 보드 주변기기·인증·Factory 전체를 포함하는 제품 전체 계획은 아니다. 각 번호는 기능 결과를 기준으로 묶었고, 하위 항목은 실제 구현·통합·검증할 작업이다. 상태는 2026-09-30 확인 근거 기준이며, 완료율은 근거 없이 추정하지 않는다.

W00 — 요구·현행 근거에서 Blueprint 도출

• [ ] W00.1 제품 목표·대상 SKU·지원 시나리오 확정 · A: M1, 승인: System 책임자 · 선행: 없음. 제품/SoC 요구, 지원 앱·Agent, 배포 이미지와 비목표를 기존 제품 문서·실행 설정·담당자 확인으로 모은다. 완료: 각 요구의 근거·제품 범위·수용 기준·미확정 입력이 추적표에 기록됨.
• [ ] W00.2 As-Is 코드·실행 owner·빌드 경로 지도 · 통합 A: M1; 작성: SDK M2, core M3, AMR M4, Cleaning M5, Android/product M6; HAL 근거는 지정 BSP/HAL owner · 선행: W00.1 초안 작성과 병행. 각 owner가 자기 caller/runtime owner/AIDL-wire/build-package 경로를 조사하고 M1이 교차 경계를 잇는다. 완료: 요구별 구현 상태와 source path·consumer·revision 근거가 기록됨.
• [ ] W00.3 요구에서 계층·기능 경계 도출 · 통합 A: M1; 의미 결정 A: 해당 M2–M6 · 선행: W00.1–W00.2. M2는 SDK/IPC, M3는 공통 제어/lifecycle, M4/M5는 domain 결과, M6은 Android integration, 지정 BSP/HAL owner는 장치 제약을 작성한다. 완료: 요구별 단일 outcome owner, interface, 협업자, 검증 증거가 정해짐.
• [ ] W00.4 초안 Blueprint disposition 결정 · 기록 통합: M1; 각 계층 판단/승인: 해당 M2–M6 A · 선행: W00.3. 각 draft box/folder/module/class에 keep/merge/move/defer/remove-candidate/external-confirm을 부여하고 caller·build·lifecycle 근거와 반대 근거를 남긴다. 완료: 모든 항목의 결정자와 보류 해제조건이 명시됨.
• [ ] W00.5 Target Blueprint·dependency·product topology 통합 · 통합 A: M1; 계층 승인: 관련 A · 선행: W00.4 및 상세 설계 산출물. 실제 folder와 Soong/Gradle/Make edge, runtime owner, Binder/device boundary, package/start 경로를 한 구조로 묶는다. 완료: target diagram, ADR, traceability와 검증 gate가 같은 요구 집합을 가리킴.
• [ ] W00.6 6인 이름·capacity·backup 배정 · A: 팀장 · 선행: W00.3 workload 산정. M1–M6 역할을 실제 인원에 배정하고 운영 비중, 교차 리뷰, HAL/BSP 외부 지원, 백업 및 병목을 합의한다. 완료: 실제 owner와 일정이 기록되고 HAL/BSP 외부 의존에 지원 계획이 있음.
• [ ] W00.7 책임 변경 승인 규칙 · A: M1 · 선행: W00.5–W00.6. 기능 A, 작성자, 검토자, 현재 execution owner, layer owner, 완료 증거를 모든 작업 카드에 기록한다. 완료: 코드 위치 이동과 실행 책임 이동이 구분되고 새 카드 형식에 필수 필드가 있음.

W01 — Framework SDK, AIDL, 호환 및 소비 앱

• [ ] W01.1 SDK 정본·브랜치 차이 고정 · A: M2 · 선행: W00.2. local/team Java·AIDL·artifact 차이를 API 의미, wire/ABI, 실제 caller 기준으로 분류한다. 완료: 모든 public/team-only 차이에 채택·호환·보류 판단과 caller 근거가 있음.
• [ ] W01.2 typed API 및 callback 잔여 이관 · A: M2, 기능 동작은 M4/M5/M6 · 선행: W01.1. WSS/raw event/error callback/명령 결과 등 남은 legacy 소비를 앱별로 옮기고 payload·순서·오류 의미를 보존한다. 대상 소비자는 DeviceAgent, EventAssetAgent, ICT, IotAgent, PairingAgent, SKMLauncher, SKMLauncher2다. 완료: 각 consumer build/test 통과, 남은 raw 경로는 호환 사유와 제거 조건이 기록됨.
• [ ] W01.3 AAR/JAR 후보 승격 · A: M2 · 선행: W01.1–W01.2. SDK 후보 하나를 고정하고 알려진 앱과 AOSP Make 입력을 같은 후보로 컴파일한다. 완료: candidate SHA와 각 검증 소비자 SHA/빌드 기록이 맞고 checked-in artifact를 승인 없이 덮지 않음.
• [ ] W01.4 API lifecycle·호환 종료 조건 · A: M2 · 선행: W01.3. deprecated API, compatibility bridge, wire 변화를 제거하는 조건과 지원 조합을 정의한다. 완료: SDK 릴리스마다 API/consumer compatibility 표가 갱신됨.

W02 — Host, Runtime, Health, State

• [ ] W02.1 Host composition 및 단일 인스턴스 · A: M3, Android process는 M6 · 선행: W11. Android host에 공통 services/endpoints/domain owner를 조립하고 중복 start/bind 시 인스턴스 수명을 확인한다. 완료: JVM composition 회귀 및 제품 process start/restart 증거.
• [ ] W02.2 Framework health/lifecycle API · A: M3 · 선행: W02.1, W03. Health snapshot, readiness, unavailable/stale 상태를 실제 manager/caller가 소비하도록 연결한다. 완료: producer 상태 변경부터 consumer 판단까지 추적되는 결과.
• [ ] W02.3 canonical State freshness/ordering · A: M3, 원본 callback은 M6 · 선행: W03. sequence/generation/time 검증과 stale·duplicate 차단을 적용한다. 완료: 오래된 callback/reconnect가 최신 State를 덮지 않는 회귀 + 기기 source timestamp 증거.

W03 — Device Observation, Callback, Reconnect

• [ ] W03.1 IoT/MQTT event source · A: M6 · 선행: W01, W02. 기존 IotAgent/DeviceAgent callback을 typed ingress로 연결하고 generation, 재연결, 등록 해제를 확인한다. 완료: reconnect 뒤 새 event만 현재 세대 State로 전달됨.
• [ ] W03.2 AirQuality·Power source · A: M6 · 선행: W02. MCU/Android producer, 단위, validity, freshness, fallback을 contract로 전달한다. 정책·상태 의미 A는 M3다. 완료: 실제 payload/시각부터 canonical State까지 trace가 남음.
• [ ] W03.3 AMR/Cleaning observations · A: 각각 M4/M5, callback transport는 M6 · 선행: W04. command ACK와 물리 상태 callback의 request/attempt/epoch/sequence 귀속을 구분한다. 완료: 명령과 해당 실행의 관측·stop/completion event가 상관관계로 연결됨.
• [ ] W03.4 Camera/device callbacks · A: M6, authority/resource는 M3 · 선행: W09. session generation, error, callback 해제와 client 재연결을 확인한다. 완료: old session callback이 새 session 상태를 변경하지 않음.

W04 — AMR 및 Cleaning 명령 경로

• [ ] W04.1 AMR 요청부터 결과까지 · A: M4 · 선행: W01, W05. SDK request → admission → 기존 DeviceAgent movement owner → 결과 callback 경로와 requestId를 잇는다. 완료: 단일 실행 owner와 correlated success/failure/stop 증거.
• [ ] W04.2 Cleaning 요청·예약·리포트 실행 · A: M5 · 선행: W01, W05, W08. 기존 BaseCleaningManager/BasicCleaningManager/MovingCleaningManager 의미와 기능별 결과를 보존한다. 완료: typed SDK와 기존 executor 사이에 중복 실행 없이 outcome이 전달됨.
• [ ] W04.3 stop/cancel/timeout 인계 · A: M4 또는 M5, 공통 Task 규칙 M3 · 선행: W04.1–W04.2, W06. 요청 접수, 하위 stop ACK, 전체 멈춤 확인, timeout, resource release를 분리한다. 완료: timeout이나 ACK 하나만으로 물리 stop을 승인하지 않는 회귀·기기 증거.

W05 — Capability, Policy, Resource, Admission

• [ ] W05.1 Capability readiness와 admission · A: M3 · 선행: W02–W03. 실제 provider/source readiness와 권한·상태 freshness에 따라 요청 가능 여부를 정한다. 완료: unready/stale provider는 실행이 거절되고 이유가 호출자에게 전달됨.
• [ ] W05.2 Resource claim/release/recovery · A: M3 · 선행: W04, W06. 이동·청소·카메라 등 경쟁 자원의 owner와 lease 회복 규칙을 정한다. 완료: 정상/실패/cancel/death 경로에서 이중 점유 또는 조기 해제가 없음.
• [ ] W05.3 SafeCare/보안 권한 결정 · A: M3, Android signature/permission은 M1 · 선행: W01, W11. authorization, permit, expiry/revocation과 실제 operation session을 분리한다. 완료: allow/deny 사유와 revocation 이후 stop 정책이 테스트됨.
• [ ] W05.4 Blueprint module/import rule · A: M3, AOSP classpath는 M1 · 선행: W02–W05. 현재 Soong module DAG/import 검사로 실제 compile boundary를 강제하고 미사용 public filegroup은 외부 consumer 확인 뒤 판단한다. 완료: 허용/금지 dependency 검사 통과 및 근거가 있는 export 목록.

W06 — Task, Queue, Claim, Completion

• [ ] W06.1 Task admission/queue/claim 단일 owner · A: M3 · 선행: W05. 요청별 task identity, claim/permit, queue, duplicate 정책을 정의한다. 완료: 한 task의 실제 executor가 한 번만 claim하고 identity가 끝까지 보존됨.
• [ ] W06.2 domain execution과 terminal evidence 연결 · A: M3, domain 결과는 M4/M5/M6 · 선행: W04. 각 task의 accepted/dispatched/physical-running/completed/failed/cancelled 의미를 연결한다. 완료: terminal result에 source evidence와 원인이 귀속됨.
• [ ] W06.3 cancel/deadline/retry 의미 · A: M3 · 선행: W06.1–W06.2. MR6의 timeout/retry/cancel 계약과 실제 provider 취소·completion을 대조한다. 완료: 재시도 시 새 attempt가 구분되고 이전 callback이 새 결과를 완료시키지 않음.

W07 — 영속 기록과 재시작 복구

• [ ] W07.1 Task journal 장애·보존·용량 · A: M3 · 선행: W06. 원자 기록, checksum/version, single writer, 용량 상한과 정리를 검증한다. 완료: crash/손상/full disk에서 안전한 복구·실패 동작.
• [ ] W07.2 재인증 및 미확인 실행 재조정 · A: M3, 실제 상태 확인은 domain owner · 선행: W03, W05–W07. 기록된 task를 그대로 running으로 복원하지 말고 provider의 현 상태를 다시 확인한다. 완료: 재인증 전 명령 재개·resource FREE 오판이 없음.
• [ ] W07.3 재개 정책 · A: M3 · 선행: W07.2. 재시작 후 재개/실패/사용자 확인 대상과 새 request/attempt correlation을 확정한다. 완료: 각 상태에 명시적 정책·테스트·감사 기록이 있음.

W08 — Workflow 및 Schedule

• [ ] W08.1 workflow/parallel execution contract · A: M3 · 선행: W06. 여러 task의 parent/child·부분 실패·cancel 의미를 정한다. 완료: MR6 workflow semantics 비교와 실행 추적 회귀.
• [ ] W08.2 durable schedule·alarm·reboot · A: M3, 청소 기능 값·화면 수용은 M5 · 선행: W07. 저장·AlarmReceiver·재부팅 복구·중복 억제를 구현한다. 완료: 재부팅 이후 한 예약이 한 번만 실행되고 결과 이력이 연결됨.
• [ ] W08.3 Cleaning 예약 및 리포트 consumer · A: M5 · 선행: W01, W08.2. Launcher/Launcher2 화면과 SDK schedule/report 모델을 연결한다. 완료: 소비자 compile과 예약 실행·취소·결과 표시가 같은 기록을 가리킴.

W09 — 기능별 추가 domain 및 제품 consumer

• [ ] W09.1 Camera/Vision · A: M6, 권한·resource M3, API M2 · 선행: W01, W05. DeviceAgent camera owner, Framework session lease, 실제 client·error callback을 연결한다. 완료: session lifecycle와 consumer build/device evidence.
• [ ] W09.2 SystemUI/display · A: M6 (cross-layer scope M1), 공개 API M2 · 선행: W11. Android component/export/permission 및 기존 UI product owner를 확인한다. 완료: component start/permission과 실제 callback 소비 증거.
• [ ] W09.3 MCU·Pairing·Bluetooth/device connection · A: M6, PairingAgent API 소비는 M2 · 선행: W01, W03. interactive UI owner와 transport owner를 나누고 callback 등록 해제를 검증한다. 완료: 연결/해제/rebind와 사용자 흐름 회귀.
• [ ] W09.4 OTA/Update/Provisioning · A: feature owner를 W00에서 지정, Android product integration M6 · 선행: W01, W11. product version, full/partial/recovery owner와 기존 setup flow를 목록화한다. 완료: 제품 policy·persistent state·reboot/recovery 검증이 정의됨.
• [ ] W09.5 SafeCare/EventAsset screen-session integration · A: M5, authority M3, API M2 · 선행: W05, W08. 화면/session 실제 owner와 Launcher caller를 연결한다. 완료: screen owner를 중복 생성하지 않고 session start/stop/expiry가 추적됨.
• [ ] W09.6 Alert/Maintenance/Self-test · 기능 의미 A: M3; Android execution hook: M6 · 선행: W02, W05. 현재 product producer, task vs query 성격, 오류·복구 contract를 각 기능별로 분류한다. 완료: 기능마다 caller·owner·acceptance scenario가 별도로 지정됨.
• [ ] W09.7 각 consumer 앱 migration · A: M2, 기능 acceptance는 해당 M4/M5/M6 · 선행: 해당 W01/W04/W09 API. DeviceAgent, EventAssetAgent, ICT, IotAgent, PairingAgent, SKMLauncher/2를 후보 artifact 기준으로 검증한다. 완료: 앱별 compile/test와 artifact SHA 기록; Binder/device 단계는 별도 표시.

W10 — Managed TTS 기존 경로 유지·검증

• [ ] W10.1 Managed TTS existing path 유지·검증 · A: M3, Android audio focus/route M6, API M2 · 선행: W02, W11. 요청 소유권, cancellation, endpoint lifecycle, audio routing 확인만 한다. 완료: 기존 TTS 경로의 owner·error·stop 의미가 보존됨.

W11 — SDK 소비 입력, AOSP APK, 제품 이미지, 서비스 기동

• [ ] W11.1 Make/Soong source module build · A: M6; 구조 결정 M1, SDK source 정합 M2 · 선행: W01. 현재 QSSI 시도는 forward-only AIDL 입력 처리 뒤 --boot-class-path not allowed with target 11에서 실패했다. Make 또는 Soong 컴파일 경로와 Java target 조합을 검증한 뒤 재실행한다. 완료: 종료 코드 0, fresh APK 시각/SHA/certificate/manifest 확인.
• [ ] W11.2 product package·partition·signing·permission · A: M6 · 선행: W11.1. QSSI/UM product가 framework opt-in을 포함하는지와 privileged/signature permission·allowlist·SELinux 요구를 대조한다. 완료: 정확한 image 경로에서 package 한 번 포함, 정책 근거와 cert 확인.
• [ ] W11.3 image generation 및 install inventory · A: M6 · 선행: W11.1–W11.2. 실제 QSSI/UM image 또는 target-files에서 APK identity를 대조한다. 완료: image의 APK SHA/cert가 fresh module 산출물과 일치.
• [ ] W11.4 Host·endpoint boot/start/restart owner · A: M6, service lifecycle semantics M3 · 선행: W11.2. Private Host, observation service, managed TTS endpoint의 각각의 start/bind caller를 찾는다. 완료: cold boot·process death 후 의도한 endpoint가 중복 없이 올라오고 복구됨.

W12 — Binder·기기·제품 인수

• [ ] W12.1 Public root Binder discovery와 UID gate · A: M3, SDK contract M2, Android permission M6 · 선행: W11.4. fromBinder()를 연결할 service/component와 권한을 확인한다. 완료: 허용/거절 UID, version/manager discovery, 대표 typed call, death/reconnect 왕복.
• [ ] W12.2 기기 observation acceptance · A: M6, State 의미 M3 · 선행: W03, W11.3. IoT·AirQuality·Power·Camera 중 대표 source를 실제 장치에서 확인한다. 완료: 원본 source, 시각/sequence, Framework State, consumer까지 상관관계 로그.
• [ ] W12.3 AMR acceptance · A: M4, 제품 image M6 · 선행: W04, W06, W11.3. 안전한 이동/조회/중단 대표 흐름을 확인한다. 완료: command ACK와 physical completion/stop evidence가 분리된 기기 기록.
• [ ] W12.4 Cleaning/SafeCare acceptance · A: M5, authority M3, 제품 image M6 · 선행: W04/W05/W08/W11.3. 청소 시작·부분 중단·전체 중단·예약 또는 session 흐름을 확인한다. 완료: 하위 stop ACK 전부와 전체 정지, schedule/session 결과가 같은 execution에 귀속.
• [ ] W12.5 resource/performance/restart soak · A: M6, architecture review M1, Task/resource M3, feature owner · 선행: W12.1–W12.4. 재연결/반복 lifecycle과 process memory/thread/handle 변화를 수집한다. 완료: 사전 합의된 제품 기준, 원시 로그, 반복 횟수와 실패 조건.

W13 — 검증 기록과 Wiki 유지

• [ ] W13.1 변경 묶음 증거 기록 · A: 작업 작성자, 품질 승인은 해당 Manager · 매 묶음 종료 때 revision + 명령 + 결과 + log + 미검증 범위를 한 기록 위치에 쓴다. 완료: 현재 코드와 주장이 같은 revision을 가리킴.
• [ ] W13.2 공개 현황 갱신 · A: M1 + 문서 편집자 · 검증된 상태만 진행판·WBS·검색 인덱스에 반영하고 build/lint/sensitive scan 및 canonical URL을 확인한다. 완료: public canonical 내용이 local staged hash와 일치.

다음 작업 착수 순서

1. W00.1–W00.4: 제품 요구와 양 브랜치 현행 경로를 대조해 초안 Blueprint 항목별 disposition을 만든다.
2. W00.5–W00.7: 소스/module/runtime 그림, 계층 책임·HAL 지원계획, acceptance와 실제 인원 capacity를 확정한다.
3. W01–W10: 승인된 target에 근거가 있는 SDK·caller·Framework 기능만 정합한다. 현재 코드 결과는 evidence로 보존하되 자동으로 target architecture로 승인하지 않는다.
4. W11: AOSP Java target/Make 문제를 해결하고 fresh APK→제품 image→boot 순서로 통과시킨다.
5. W12: Binder와 기능별 기기 검증을 분리해 수행한다. HAL 시험은 지정 SoC/BSP owner와 진행하고 domain 담당자가 acceptance를 승인한다.
6. W13: 묶음마다 revision·검증·미검증 근거를 갱신한다.

연결 문서

• 실행 TODO — 세부 카드와 현재 검증 근거
• 브랜치 정합 대표 문서 — 현재 코드 차이와 구조 판정
• 진행 현황 — 전체 작업 지도와 실제 구현 이력
• SKIX Robotics Product Framework Blueprint