SKIX 리팩터링 실행 TODO — 소스 정합에서 제품 기동까지
목표: 사용자가 작성한 Blueprint 초안을 확정 설계로 간주하지 않고, 제품 요구·두 브랜치의 실제 caller/실행 owner·빌드/부팅 경로에서 목표 구조를 먼저 도출한다. 그 결과에 따라 계층별 R&R과 TODO를 확정하고, 필요한 코드만 정합한 뒤 AOSP 제품·서비스·기기 검증까지 진행한다.
현재 기준은 local 4d9b1a57, team 164654fc다. Team checkout은 비교 전용으로 읽고, 전체 merge/rebase는 하지 않는다. Planner는 이번 구현 범위가 아니다. 새 추상화는 실제 caller와 실행 owner가 요구할 때만 추가한다.
한눈에 보는 진행판
| 대구분 | 상태 | 현재 확인된 사실 | 다음 통과 조건 |
|---|---|---|---|
| 0. 분석 — Blueprint 근거 도출 | 미완료, 최우선 | 현재 Blueprint는 사용자가 쓴 초안이다. 대상 SKU/요구 traceability와 초안 항목별 keep/merge/defer 판단이 없다 | 요구·현행 owner·build graph를 함께 검토하고 계층·기능별 근거표 작성 |
| 1. 설계 — 목표 구조·R&R | 선행 결정 필요 | 코드/WBS는 SDK와 서버 구현 항목으로 바로 진입하고 HAL 전문 작성 책임이 넓은 외부 연동 아래 묶여 있다 | 실제 폴더/모듈/owner/dependency/완료 gate에 연결한 구조도와 6계층 책임·capacity 승인 |
| 2. 구축 — 승인 범위만 정합 | 준비 자료 일부 있음 | 양쪽 SDK/caller 차이와 DeviceAgent gateway 연결 결과가 축적됐지만, 신규 구축 범위는 Blueprint 기준선에 종속돼야 함 | 승인된 요구에 연결되는 SDK·제품 caller·Framework layer만 구현하고 기존 execution owner 보존 |
| 3. 검증 — 소스에서 제품까지 | 일부 정적/host 증거, 제품 미완료 | 소비자 후보 compile 및 host tests 기록이 있고, AOSP Make 빌드와 product inclusion/service startup/device 검증은 미완료 | source→artifact→consumer→image→boot/Binder→device를 단계별 독립 증거로 확인 |
| 부가. R&R 배정 | 역할·설계분장 구체화 완료; 실명·용량 배정 대기 | M1–M6 책임과 WBS 1.1–1.12의 작성자·승인자·교차검토·인계 산출물을 연결 | 팀장이 실제 인원·투입률·backup 및 BSP/HAL 지원자를 지정하고 용량을 승인 |
상태: 완료는 적힌 증거까지 끝남, 진행 중은 일부 산출물만 있음, 대기는 선행 기준/입력이 필요, 미검증은 결과 증거가 없음. 순서상 0·1이 승인되기 전에는 구현 backlog의 항목을 새 Blueprint 요구로 승격하지 않는다. 현재 코드는 분석의 근거로 읽되, 미커밋 사용자 변경을 목표 구조의 승인으로 해석하지 않는다.
SKB 양식에 맞춘 Master WBS
참고 파일 /mnt/c/securedir/SKB 개발 항목.xlsx의 상세 Activity 시트는 대구분 → 소분류 → 세부사항 → 담당자 → 상태 열로 업무를 펼친다. 이 계층 형식과 상태 관리만 참고한다. TV 제품 기능 목록 자체는 가져오지 않고 SKIX 리팩터링 업무를 분석 → 설계 → 구축 → 검증 순서로 다시 묶는다.
| 대구분 | 소분류 | 세부사항 | 계층 책임 | 상태 / 산출물 |
|---|---|---|---|---|
| 분석 | 제품 목표·요구 | 대상 제품/SKU, 사용자·앱 use case, 배포 조건, 제외 범위와 acceptance evidence 수집 | M1 A; M2–M6 각 영역 근거 | 미완료 / source-linked requirement register |
| 분석 | 현행 시스템 지도 | 두 브랜치의 caller, runtime owner, SDK/AIDL/wire, 서비스/Agent, build/package/boot 경로 기록 | M1 통합; M2 SDK, M3 common server, M4 AMR, M5 Cleaning, M6 Android integration; HAL code 지정 BSP/HAL owner | 일부 자료 있음 / revision별 As-Is map |
| 분석 | 초안 Blueprint gap 분석 | 각 draft box/class/module을 제품 요구·실제 caller·build edge·lifecycle과 연결 | M1 A; 항목별 계층 owner | 미완료 / keep·merge·move·defer·remove-candidate·external-confirm ledger |
| 설계 | SDK·Binder·데이터 계약 | Public API/AIDL/wire, endpoint, identity/permission, callback과 호환 의미 | M2 A; 공통 gate M3; Android 등록/permission M6, 구조 결정 M1 | 대기 / API-wire-endpoint map |
| 설계 | 공통 실행 lifecycle | capability/state/policy/resource/task/admission/cancel/completion 의미 | M3 A; M2/M4/M5/M6 검토 | 대기 / lifecycle·transition·dependency 표 |
| 설계 | Domain owner와 기능 흐름 | AMR·Cleaning/SafeCare·미배정 기능의 실행 owner, input/output·stop 조건 | 기능별 M4/M5 A; 공통 규칙 M3 | 대기 / owner·sequence·acceptance map |
| 설계 | Device/HAL/BSP handoff | adapter·MCU/HAL 경계, callback lifecycle·failure/reconnect, ICD | HAL A: 지정 BSP/HAL owner; Android integration M6; 기능 수용 M4/M5 | 대기 / ICD·외부 의존·capacity ledger |
| 설계 | Module·Android product topology | import/build edge, process/package/start/permission 및 실제 폴더 배치 | 제품 build A: M6; 구조 결정 M1; M2/M3/M4/M5 import 근거 | 대기 / 현재·목표 dependency/package graph |
| 설계 | 통합 Blueprint·decision | draft disposition, cross-layer ADR, 위험·미결정 owner, 승인 기준 | M1 통합; 의미 결정은 계층 A | 대기 / target diagram·ADR·baseline WBS |
| 설계 | 검증 구조 | 요구→검증 traceability, host/module/consumer/image/Binder/device acceptance | 각 계층 A; M1 cross-layer architecture, M6 product verification | 대기 / verification matrix·담당·증거 |
| 구축 | SDK·consumer | canonical source/artifact, AIDL/wire/API 정합 및 caller migration | M2 A, 기능 의미 owner 검토 | 진행 기록 있음 / 영향 consumer 전체 compile·test |
| 구축 | Framework·제품 계층 | 공통 control/task와 기능 domain/adapters는 승인된 requirement만 연결, 중복 owner 방지 | M3/M4/M5; Android integration M6; HAL 구현은 지정 BSP/HAL owner | 분석·설계 승인 뒤 착수 / layer contract와 focused regression |
| 구축 | AOSP package | 승인된 service/artifact를 Soong/Make/product config와 package 정책에 연결 | M6 A, M2 SDK 입력, M1 architecture review | 차단 / fresh module/package build |
| 검증 | 소스·모듈·소비자 | API/contract, dependency boundary, module tests, APK candidate matrix | 각 계층 A, product integration M6, architecture review M1 | 부분 통과 / 동일 revision 결과·로그·SHA |
| 검증 | 이미지·기동·Binder | 제품 이미지 포함, signing/permission, boot/service start, root Binder/death/reconnect | M6 A, M2/M3 협업; M1 architecture review | 미검증 / image→boot→Binder evidence |
| 검증 | 기능·SoC/기기 수용 | domain acceptance를 HAL/BSP 담당과 수행; M4/M5는 기능 성공·정지 조건 승인 | 기능 A M4/M5, HAL 지정 BSP owner, Android integration M6, architecture review M1 | 외부 장치 입력 필요 / correlation된 실제 runtime/device evidence |
HAL 책임 한정: HAL/MCU 구현은 WBS에서 이름을 지정한 SoC/BSP 담당자가 맡는다. M6은 Android integration/build/runtime 검증을 맡는다. 다른 Manager는 자신의 layer contract, host/mock test, consumer 및 기능 acceptance를 책임지며 HAL 코드를 기본 책임으로 떠안지 않는다. W00 분석에서 별도 HAL owner가 확인되지 않으면 해당 검증은 미배정 위험으로 남기고, 완료로 처리하지 않는다.
실행 단계 및 세부 TODO
0 — 분석: 사용자가 작성한 Blueprint 초안의 근거 도출
- [ ] 0.1 제품 요구·대상 SKU·수용 조건 수집 · A: M1 · 근거 문서/제품 config/build variant와 팀 확인을 분리해 기록한다. TV SoC 예시의 목차를 요구사항으로 복사하지 않는다. 완료: 요구별 source, 범위, 완료 증거와 미확정 입력이 기록됨.
- [ ] 0.2 양 브랜치 As-Is source/caller/owner/build inventory · A: M1; 작성: SDK M2, core M3, AMR M4, Cleaning M5, Android/product M6; HAL 근거는 지정 BSP/HAL owner · 팀 checkout은 read-only, local 변경은 보존한다. API부터 HAL 호출과 제품 package/start까지 추적한다. 완료: 요구별 현재 owner·source path·module/build consumer·revision 근거가 있음.
- [ ] 0.3 초안 항목의 실제 필요성 판정 · A: M1; 결정은 해당 계층 A가 승인 · 요구/caller/build/lifecycle 근거로 유지, 통합, 이동, 보류, 삭제 후보, 외부확인으로 분류한다. 이름이 유사한 추상화나 빈 directory는 요구로 간주하지 않는다. 완료: 초안의 모든 major/minor 항목에 disposition과 근거 또는 명시된 미확인이 있음.
- [ ] 0.4 제품/공통/SoC vendor 책임 경계 확인 · A: M1; HAL/MCU 구현자는 지정 BSP/HAL 담당; Android 연계 M6 · 기존 DeviceAgent/Agent가 실행 owner인지, 새 Framework service가 제품에 등록될지, 어떤 부분이 SoC 외부 deliverable인지 확인한다. 완료: 미확정 외부 책임의 담당자·자료·일정이 지정되거나 명시적 blocker가 있음.
1 — 설계: 제품 근거를 목표 구조와 R&R로 변환
설계 단계는 폴더 이름을 먼저 정하는 작업이 아니다. 양 브랜치의 실제 호출·실행·배포 근거를 제품 시나리오에 연결하고, 그 결과로 계약과 모듈 경계를 결정하는 과정이다. 선행 분석 0.1–0.4가 통과하기 전에는 목표 구조를 승인하지 않는다. 아래 패키지는 각각 독립 검토 가능한 결과이며, 해당 도메인이 실제 존재하지 않거나 caller가 확인되지 않으면 새 계층을 만들지 않고 해당 없음/근거 부족으로 판정한다.
| 설계 WBS | 분석 질문과 세부 활동 | 단일 A / 작성·검토 참여 | 산출물 | 통과 gate |
|---|---|---|---|---|
| 1.1 제품 요구·사용 흐름 | 대상 SKU, 제품 capability, 호출 앱/권한, 성공·거절·취소·중단 조건과 제외 범위를 정리 | A M1; 요구 근거 각 기능 A; SDK caller M2 | 요구 ID→사용 흐름→수용 조건 표 | 각 요구에 실제 제품 근거·범위·증거가 있거나 미확정 owner가 지정됨 |
| 1.2 현재 실행·배포 토폴로지 | 두 브랜치에서 앱→SDK→Binder→서비스/Agent→executor→장치, 프로세스·패키지·빌드 입력을 revision별 추적 | A M1; SDK M2, control M3, domain M4/M5, Android integration M6 | As-Is source/caller/process/package/build graph | 실제 흐름과 후보 Framework 경로가 분리되고 모든 edge에 파일·build 근거가 붙음 |
| 1.3 기능 소유자·상태 흐름 | 기능별 command producer, 단일 execution owner, observation producer, UI/session owner, 완료·오류·전체 stop 책임을 분리 | A 각 기능 owner; 공통 통합 M1; lifecycle 의미 M3 | feature owner matrix와 시퀀스/상태 전이 | 기능별 실행 A 1명, 현재 owner와 목표 owner가 구분되고 이관 조건이 정의됨 |
| 1.4 Public SDK·wire·호환 계약 | Manager/model/AIDL·Bundle·오류값·ABI·호환/폐기 조건, caller migration 순서를 확인 | A M2; 의미 검토 해당 기능 A; Binder 진입 M3 | API→wire→caller map, compatibility ledger | 호출자·payload·응답 의미·버전 전략·회귀 consumer가 모두 식별됨 |
| 1.5 Entrypoint·identity·권한 경계 | Binder discovery, UID/permission, validation, death/reconnect, 외부에 노출되는 메서드 범위 결정 | A M3; public API M2; Android package/permission M6 | entrypoint/identity/permission sequence와 threat cases | 허용·비허용 caller 및 권한 거부·재접속 시험 조건이 명시됨 |
| 1.6 공통 Control·Task lifecycle | capability/admission/policy/resource/state/task/queue/cancel/deadline/retry/completion 중 실제 공통인 계약을 정의 | A M3; domain 검토 M4/M5; SDK 결과 M2 | 공통 상태 모델, transition·resource conflict 표 | domain 세부 구현을 import하지 않고 공통 의미를 재사용하며 terminal 상태가 근거와 연결됨 |
| 1.7 Domain 구조 — 기능별 별도 카드 | AMR·Cleaning/SafeCare 및 source audit에서 확인된 Camera/AirQuality/Power/IoT/Interaction 등 각 기능의 명령·관측·정책·실행을 따로 판단 | A 실제 기능별 owner; 현재 AMR M4, Cleaning/SafeCare M5; 나머지는 0.2에서 재배정 | 기능별 command/state/owner/acceptance card와 domain 간 호출도 | 기능마다 caller·producer·consumer가 있고 중복 기능 owner/추상 계층이 없음; 미배정 기능은 설계 승인 불가 |
| 1.8 Device observation·adapter·HAL 인계 | 단위·출처·timestamp·generation/sequence·callback·timeout/reconnect를 정의하고 Framework 요구와 실제 MCU/HAL ICD를 연결 | Adapter 통합 A M6; 기능 결과 A 해당 domain; HAL 구현·승인 지정 BSP/HAL 담당 | interface/ICD, payload mapping, bench/device acceptance | Framework가 요구하는 사실과 실제 공급자 책임이 매핑되고 HAL 담당자·일정이 지정됨; 미지정은 blocker |
| 1.9 소스·Soong·제품 배치 구조 | 현재 package/source root와 import DAG를 확인하고 Java library 분리, AIDL 위치, APK/process, partition/product package/start/permission을 판정 | A M6(제품 build·기동); 구조 결정 M1; 계층별 import 증거 제공 M2–M5 | As-Is/To-Be source+dependency+package graph 및 ADR | 모듈 분리는 실제 forbidden import를 build로 막음; Framework APK inclusion/start/root Binder는 증명 또는 미확정으로 표시 |
| 1.10 Vocabulary·dependency rule | Manager/Service/Runtime/Port/Adapter/Endpoint/Gateway 등 용어의 생성 조건·소유자·허용 방향과 금지 중복을 정함 | A M1; 각 용어 의미 해당 계층 owner; build enforcement M6 | glossary, allowed-import DAG, 금지 예시와 검사 방법 | 새 이름만으로 타입을 추가하지 않고 규칙이 코드/빌드 검사로 확인됨 |
| 1.11 정합·이관·복구 순서 | 팀 SDK 차이, local dirty delta, 호환 caller, 기존 execution owner, 단계별 rollback/backout을 연결 | A M1; SDK caller M2; 공통 server M3; domain M4/M5; product promotion M6 | source disposition ledger와 bounded migration slices | 각 변경이 승인 요구·단일 owner·검증 증거를 가지며 되돌림 기준이 있음 |
| 1.12 검증·인수 구조와 R&R 기준선 | 요구→contract→module/consumer→APK/image→boot/Binder→기능 기기 검증, A/Author/reviewer/executor/backup/capacity 연결 | 통합 A M1; 제품 gate M6; 각 기능 결과 A domain owner | verification matrix와 6인 R&R/WBS baseline | 각 요구에 독립 증거·담당·미검증 경계가 있고 capacity 과부하/외부 의존이 명시됨 |
진행 게이트: G1 As-Is 승인은 1.1–1.3, G2 계층 계약 승인은 1.4–1.8, G3 구조·정합 승인은 1.9–1.11, G4 수용 기준 승인은 1.12를 통과해야 한다. G1 이전에는 목표 계층·폴더를 확정하지 않고, G2 이전에는 public/wire 또는 실행 의미를 바꾸지 않으며, G3 이전에는 신규 추상화·Soong module을 늘리지 않는다. G4 이후 구축은 승인된 WBS slice만 착수한다.
단순성 판정: 모든 제안 클래스·폴더·모듈은 요구 ID → 실제 caller → owner → dependency → 검증 연결을 가져야 한다. Manager/Service/Runtime/Port/Adapter/Endpoint/Gateway 이름만으로 생성하지 않는다. Soong 경계는 계층 이름 수가 아니라 잘못된 import를 컴파일로 차단할 필요가 있을 때만 추가한다. 현 DeviceAgent 실행을 Framework 후보 Host가 이미 인수한 것으로 표시하지 않는다.
세부 실행 항목 (Blueprint 분석·설계 승인 후 구축 재개)
기존 코드 작업의 상태와 증거는 이력으로 보존한다. 0·1단계 승인 전에는 남은 항목을 초안 Blueprint의 요구로 간주해 신규 구현하거나 추상화를 추가하지 않는다.
2.1 구축 — 팀 SDK와 실제 호출 경로 정합
- [ ] A1 — 최신 양쪽 브랜치 기준 재동기화 · 상태: 진행 중
- 팀
refactor/clean-architecture-prebuilt의 최신 tracked SDK·소비자 변경을 읽기 전용으로 비교하고, 이번 기준의 Java/AIDL 파일 inventory를 갱신한다. - 각 차이를
공통,호환이 필요한 차이,제품 caller가 없는 후보,wire/ABI 영향으로 분류한다. 이름이나 파일 수만으로 이식 여부를 정하지 않는다. - 완료 조건: 모든 team-only public API와 shared changed API에 실제 호출자/직렬화/결과 처리 판단 및 근거가 있다.
- [ ] A2 — 남은 raw/legacy caller 정합 · 상태: 진행 중
SKMLauncher2의setErrorInfo항목은 local/team 양쪽에서 typedSkixErrorManager.Listener로 연결된 것을 확인해 완료 처리한다. 남은 우선 비교는 DeviceAgent WSS raw transaction/status/detail consumer와 exported screen caller다.- AMR는 team HEAD
164654fc의 최종 tree를 기준으로 판정한다. command ownership/callback-dispatch 중간 변경은49009ea5 revert(amr)에서 되돌려졌으므로 중간 커밋만 cherry-pick하지 않는다. local 미커밋 AMR callback/movement 변경은 별도 의미·호환·테스트 대조 전까지 미분류 상태다. - 기능별로 명령 발행자와 실행 owner를 한 곳으로 유지하고 typed listener 전환 시 기존 순서·오류값·생명주기 동작을 보존한다.
- 완료 조건: checked-out 앱의 이전 callback 사용이 제거되거나 의도된 compatibility path로 문서화되고, 양 HEAD와 local working tree의 차이를 모두 설명하며 영향 앱 compile/test가 통과한다.
- [ ] A3 — 후보 SDK artifact를 소비자에 승격 · 상태: 대기
- 최신 canonical AAR을 빌드하고 알려진 각 소비 앱을 동일 후보로 컴파일한다. AOSP Make의
DeviceControlAPIJavaLib도 같은 API 입력을 포함하는지 확인한다. - 후보 SHA와 checked-in root/app AAR·JAR SHA를 표로 기록하고, 앱별 교체는 전체 소비자 검증을 통과한 묶음으로 처리한다.
- 완료 조건: 후보 AAR/JAR 하나의 식별자가 승인된 소비 입력에 일치하고 전체 영향 빌드가 통과한다. Binder/device 의미 검증은 다음 D단계와 별도로 표기한다.
2.2 구축 — 승인된 Blueprint를 실제 의존에 맞춰 축소
- [ ] B1 — 남은 AMR↔Cleaning 호출 책임 판정 · 상태: 진행 중
- AMR domain의 3개 import를 호출 순서, 취소·중단 확인, timeout, callback ownership까지 따라가 기존 runtime dispatcher와 함께 판단한다.
- 완료 조건: 각 호출의 소유 계층과 dependency가 한 방향으로 설명되고, 필요한 경우에만 파일을 이동하며 focused movement/handoff 회귀가 통과한다.
- [ ] B2 — 미사용 Blueprint 노출부 정리 · 상태: 대기
- 9개 public filegroup의 Soong/Make/Gradle/product caller를 다시 확인한다. 외부 product tree 사용 가능성을 조사하기 전에는 삭제하지 않는다.
- 완료 조건: 유지/제거 판단마다 검색 범위와 외부 소비자 미확인 여부가 기록되고, 실제 불필요한 선언만 제거한 뒤 Soong/module 검증이 통과한다.
- [ ] B3 — build boundary 최소 유지 검증 · 상태: 진행 중
- 현재 6개 Soong Java library를 고정 출발점으로 삼고, import 사용 없는 edge가 확인될 때에만 제거한다. Domain을 파일 수 기준으로 다시 쪼개지 않는다.
- 완료 조건: production Java compile·Soong dependency graph·layer rule이 같은 방향을 강제하고, 신규 모듈은 독립 API/제품 owner 근거가 있을 때만 추가한다.
2.3 구축 — 승인된 Framework APK를 실제 QSSI 제품으로 연결
- [ ] C1 — AOSP source module fresh build · 상태: 차단
- QSSI
qssi-userdebug에서 임시vendor/quber/packagessource overlay를 사용해m SkixFrameworkService를 빌드한다. Forward-only AIDL 입력은 제외했지만 legacy Make javac가 Java 11 target과 platform bootclasspath를 함께 받지 못해 실패했다. - 완료 조건: 종료 코드 0, 새 APK 생성 시각·SHA·인증서·manifest component 확인. 임시 overlay 제거 뒤 local/team source는 그대로 보존한다.
- [ ] C2 — 제품 설정과 APK 설치 partition 확정 · 상태: 대기
packages.mk가 기존 DeviceAgent/앱 prebuilts와SkixFrameworkService를 함께 선택하는지 확인하고PRODUCT_PACKAGES/이미지 파일 경로를 검사한다.- package install path, privileged 여부, signature permission 및 관련 allowlist/SELinux 요구를 Android.mk/manifest/product 정책으로 결정한다. 현재
LOCAL_CERTIFICATE := platform만으로 privileged 설치를 추정하지 않는다. - 완료 조건: 선택된 QSSI/UM product config 및 실제 이미지의 정확한 경로에 APK가 한 번만 포함되고, 설치 정책이 제품 보안 정책과 맞는다.
- [ ] C3 — system image 생성 및 package inventory · 상태: 대기
- C1/C2 이후
systemimage또는 실제 제품이 요구하는 QSSI/UM image target을 빌드한다. 기 구축 산출물 재사용 여부와 실행 기준 revision을 기록한다. - 완료 조건: 새 이미지 생성 성공, 이미지/target-files에서 APK와 manifest 확인, SHA·서명 인증서가 앞 단계 APK와 일치한다.
3 — 검증: 서비스 진입점·기동·실기기 수용
- [ ] D1 — 부팅 후 서비스 시작 주체 확정 · 상태: 미검증
- Private
SkixFrameworkHostService, exported observation endpoints, managed-TTS endpoint를 각각 누가 bind/start하는지 실제 product caller와 함께 확인한다. - 완료 조건: 제품 요구에 맞는 명시 시작 주체(예: 시스템 앱 boot receiver 또는 명시적 binder client)가 있고 cold boot 후 Host runtime이 단일 인스턴스로 올라온다.
- [ ] D2 — 공개 SDK root Binder 연결 경로 확인/완성 · 상태: 미검증
- SDK의
SkixFrameworkManagers.fromBinder()입력을 실제로 제공할 service/component와 권한 검사를 확인한다. TTS 전용 endpoint를 공용 API endpoint로 간주하지 않는다. - 완료 조건: 허용 앱은 root Binder에서 version/manager discovery 후 대표 typed 호출을 하고, 비인가 UID는 거절된다. Binder death/reconnect를 확인한다.
- [ ] D3 — 서명 이미지 설치 및 기기 smoke test · 상태: 대기
- 승인된 release/platform 인증서의 후보 이미지를 test device에 설치한다. 설치 APK 교체 전 기존 인증서와 복구 절차를 기록한다.
- 완료 조건: 부팅, package/service state, 권한, binder transaction, process death/restart 및 최소 AMR/Cleaning read-only/안전 command 경로를 로그로 검증한다. task accepted/transport ACK를 물리 동작 성공으로 해석하지 않는다.
공통 관리 — 추적과 공개 문서 유지
- [x] E0 — 6명 기능 책임과 경계 제안 · 상태: 제안 문서 게시
- 폴더별 담당 대신 제품 결과 책임으로 M1–M6을 나누고, 경계마다 최종 책임자와 공동 검토자를 지정한다.
- 완료 조건: 대표 문서에서 바로 찾을 수 있고, 팀이 실제 인원·투입률·backup을 배정할 수 있도록 역할·범위·완료 증거가 기록됨. 실제 인원 배정은 팀 확인 전이므로 미완료로 가장하지 않는다.
- [x] E1 — 통합 아키텍처 페이지의 TODO 진입점 · 상태: 완료
- 대표 페이지에서 R&R 제안과 이 체크리스트로 연결하고, 설계 요약·책임 분할·작업 실행 목록을 분리한다.
- [ ] E2 — 각 묶음 종료 시 실제 근거 갱신 · 상태: 진행 중
- 변경 revision·명령·결과·로그·미검증 범위를 코드 handoff에 기록한 다음 Wiki의 해당 체크 항목만 갱신한다.
- 완료 조건: Wiki 상태가 source/build/runtime의 실제 증거와 일치하고 공개 canonical 페이지에서 확인된다.
현재 활성 순서
- 0.1–0.4 분석: 제품 요구/SKU, 양쪽 As-Is caller·execution owner·build 경로, 초안 disposition, SoC/BSP 외부 owner를 기록한다.
- 1.1–1.9 설계: 각 계층이 contract·lifecycle·domain·device boundary를 작성하고 M1이 dependency/product topology를 통합한다. 요구→검증 추적과 HAL owner/capacity를 포함해 승인한다.
- 2.1–2.3 구축: 승인된 target에 연결되는 SDK/caller·Framework 경계·AOSP packaging만 진행한다. 기존 branch 작업은 근거로 활용하고 초안 요구로 자동 승격하지 않는다.
- 3 검증: candidate artifact → consumer APK → AOSP image → boot/service/Binder → SoC/기기 순서로 근거를 분리한다.
- 공통 관리: 각 묶음 뒤 revision·명령·로그·SHA·미검증 범위를 갱신한다.
현재 확인된 완료 근거
- Local/team 기준 HEAD와 Java/AIDL diff inventory가 있다.
docs/refactor/skix-sdk-effective-source-inventory-2026-09-30.json을 대조 시작점으로 삼는다. - Team-only SDK gateway가 checked-out product caller에 연결된 여러 slice는 단위 source test/compile을 통과했다. 이것은 Binder/device 검증이 아니다.
- 현재 six Soong module edges에 source import caller가 확인되어 무근거 module split은 보류 상태다.
packages.mk는 기존 prebuilt 앱 세트를 유지하면서skix-framework.mkopt-in을 추가한다. QSSI product/image 실제 포함은 별도 확인 대상이다.- DeviceAgent release APK는 2026-09-30 빌드, 216 unit tests 통과; SKMLauncher2 release APK는 2026-09-30 빌드, 17 unit tests 통과. 두 APK signer 인증서 SHA-256은
c8a2e9bccf597c2fb6dc66bee293fc13f2fc47ec77bc6b2b0d52c11f51192ab8이다. 이 결과는 SKIX host APK/AOSP image proof가 아니다. - 실기기 연결 및 제품 signed image/service startup은 아직 증거가 없다.