← Docs hub

SKIX 리팩터링 변경 이력

과거 기록 보관 페이지. 아래의 ‘현재’, ‘다음’, 테스트 수치는 각 기록 작성 당시의 판단이다. 지금의 완료·미완 상태는 전체 구조 기반 진행 현황을 우선한다. 기존 날짜·커밋·검증 근거와 큰 구조도는 삭제하지 않고 이 페이지로 옮겼다.

Connections

• 현재 구현 현황과 상태 구조도
• 목표 구조 Blueprint

2026-09-14 — Task 우선 통합 현황과 Android Parcel 테스트 준비

• MR7 2bb0eec: 내부 부품과 제품 연결을 분리한 현황을 작성했다. Task는 공통 execution/task/, 도메인 동작은 domain/*/execution/, Android 진입점은 services/runtime/에 둔다. 실제 호스트는 여전히 onBind()=null이며 제품 Task 공개는 미완이다.
• MR6 task_manager의 d1d8dfbc4c807a32990f4350cf09c49f159f5848를 읽기 전용으로 대조했다. 원본 TaskManager의 요청·모드 분기(:333–402), 대기/우선순위 실행(:2044–2145), Workflow(:404–575), 예약(:765–810), 취소(:2527–2561)를 MR7 책임 영역에 대응했다. 공통 Workflow/Scheduler는 package-info 골격이고 retryCount는 실행 재시도를 증명하지 않는다. MR6를 이미 모두 이식했다는 판정을 하지 않았다.
• services/tests/instrumentation/…/TaskBinderParcelTest.java에 테스트 8개를 추가했다. 실제 generated Proxy·Android Parcel·Task Stub과 내부 endpoint를 연결하되 같은 프로세스에서 호출자 증거를 주입한다. 조회·목록·취소 값, 호출별 재검증, 소유자 숨김, 권한·세대 거부, 전송 실패와 취소 반영 후 응답 유실 시 자동 재시도 금지를 검사하도록 작성했다.
• 앱에는 androidTest sourceSet과 test 의존성만 연결했다. 제품 Manifest·권한·호스트 공개는 변경하지 않았다. 연결 검사 RED 후 관련 정적 검사 7개 통과, 레이어·폴더·API 경계 검사 통과.
• 검토된 55f3872 스냅샷 + 테스트 변경 기준 서버 JVM 697개, SDK 62개, 실패·오류·건너뜀 0. 기존 미완 LLM/Vision 변경은 제외했다. debug APK와 androidTest APK를 오프라인으로 재빌드했고 Gradle 84개 작업을 모두 실행했다. Android 테스트 8개는 실행하지 않았다. 연결 기기·AVD가 없으며 실제 UID·서명·권한·프로세스 간 IPC·물리 동작의 검증이 아니다.
• 대상 debug APK SHA-256: d03b4fbda045a16deb6562a8501c683306d4d0f3a02c15c0de70579670591815. androidTest APK SHA-256: fd97c21974a2e7360a7a639d2e80df12f9964b6ce517a0667a4c1053e67bd1e1. 두 빌드 산출물의 인증서는 일치하지만 설치된 제품 인증서와의 호환 증거는 아니다. 기기에 설치하지 않았다.
• 선행 7fafa03은 공통 실행 계층의 도메인 import를 차단했고, 55f3872는 AMR 신호와 공통 완료 키의 상수 소유권을 분리했다. 폴더와 의존성의 책임 경계를 함께 유지한다.
• 다음 우선순위는 대표 이동의 요청→실행→완료·취소 연결이다. 보안 주체 결정 없이 공유 UID 거부를 완화하지 않는다. 기존 큰 구조도와 과거 이력을 삭제하거나 간소화하지 않았다.
• 저장소 상세 근거: docs/refactor/skix-taskmanager-integration-status-2026-09-14.md.

2026-09-14 — 제품 Binder 연결과 공유 UID 선행 조건 재대조

• MR7 2af2086의 Android 호스트는 endpoint 없는 생성자와 onBind()=null을 유지한다. Task Stub 생성·공개, SystemServer Root 등록, 실제 bind/death/rebind는 미연결이다. RuntimeConnectionSupervisor는 설계 문서의 이름이며 Java 구현이 아니다.
• DeviceAgent·IotAgent·SKMLauncher의 system shared UID 선언과 현재 resolver의 다중 package 거부 계약을 대조했다. QSSI PackageManager.getPackagesForUid 및 ComputerEngine의 설치·사용자·가시성 필터를 확인했다. 소스 선언은 실제 설치 목록이나 실기기 거부 증거가 아니다.
• 기존 identity 관련 JVM 테스트 13개(resolver 4, trust 4, scope matrix 5)를 재실행해 실패·오류·건너뜀 0을 확인했다. 이는 현재 거부 계약의 테스트이며 새로운 제품 통합 검증이 아니다.
• Runtime 내부 registry와 SystemServer의 discovery registry는 프로세스 경계에서 동일 객체가 될 수 없음을 명시했다. 동일 TaskManager 연결과 프로세스 간 준비·세대·죽음 처리가 후속이다.
• production identity·grant·Manifest는 변경하지 않았다. 권한 완화나 기존 sharedUserId 삭제를 임의 적용하지 않았다. 새 조립 설계는 승인 전이며, 큰 SVG와 과거 구현 이력은 보존했다.
• 저장소 근거: docs/refactor/skix-shared-uid-binder-integration-audit-2026-09-14.md, docs/refactor/skix-runtime-host-wiring-audit-2026-09-09.md.

2026-09-14 — Runtime endpoint 공개·종료 수명 연결

• 기존 FrameworkRuntimeHost에 registry/snapshot 조합을 추가했다. 서비스 준비 후 일괄 공개, 종료 callback 전 자기 세대 무효화, 공개 실패 rollback을 기존 상태 기계에 연결했다.
• registry의 조건부 무효화는 원자적으로 세대를 비교한다. 이전 호스트의 늦은 종료, 시작 전 종료와 공개 실패가 다른 세대를 지우지 않도록 했다.
• 신규 8개 테스트, 기존 Task endpoint 10개 테스트를 실제 호스트/registry 조합으로 검증했다. 미구현 API 확인 후 동작 RED 5/30 → GREEN 30/30, 최종 서버 697개·SDK 62개 모두 통과. Runtime release 빌드 98개 작업 전부 재실행, 독립 리뷰에서 지적 사항 없음.
• 검증은 2996724 + 해당 변경 snapshot 기준이며 기존 미완 LLM/TTS 등의 변경은 제외했다. Android 호스트는 기존 비공개 생성자·onBind()=null을 유지한다. 외부 IPC·제품 설치· 실기기 검증은 아직 없다. 진행 현황의 큰 SVG는 그대로 보존했다.

2026-09-14 — IoT 관측 연결의 서비스 수명 이관

후속: 기존 요청의 실제 소유자를 system에서 IoT로 분리

• DeviceAgent IotCommandHandler를 만들고 AWS 조회·갱신, 시작 알림, 프로비저닝 전달 네 요청을 이관했다. MainApi 등록과 기존 system 처리기의 소유 선언 제거를 함께 반영했다.
• 31f9caf의 네 분기 본문과 비교해 내용 동일함을 확인했다. 문자열 status, serial 추가, provisioning 속성 설정 후 원본 Bundle 전달 순서와 기존 Utils 캐시는 유지한다.
• 소유권 검사 RED(6개 assertion) → GREEN(3개 unittest), 전체 273개 명령 중복 없음, Bundle 검사 11개 대상 통과. DeviceAgent 테스트 22개·debug APK 빌드, 37개 작업 모두 재실행.
• IotAgent의 실제 SDK 호출을 확인했으나 별도 Framework Runtime으로의 상태 보고 IPC는 아직 없다. DeviceAgent 안에 중복 Runtime을 생성하지 않았다. 실기기 미검증.

내부 관측 연결 수명 구현

• 기본 Runtime에 IoT를 실제 등록해 공통 7개 + IoT, 총 8개 서비스가 시작·종료된다.
• IotManagerService가 관측 연결을 발급·교체·폐기한다. 이전 연결의 보고·지연 close, 장애·복구 전 연결의 재사용을 차단한다. 마지막 관측 기록은 진단용으로 보존한다.
• AwsIotConnectivityObservationAdapter는 값 변환만 한다. 공통 publishFrom은 소유 서비스의 READY·세대 확인과 저장을 원자적으로 처리한다. 외부 clock은 서비스 잠금 밖에서 실행한다.
• 신규 수명 검사 10개·공통 검사 5개. RED 확인 후 GREEN, 독립 리뷰 APPROVE. 2c3b917 + 이번 변경 스냅샷 기준 서버 689개·SDK 62개, 실패·오류·건너뜀 0, 98개 Gradle 작업 모두 재실행 및 Runtime release APK 생성.
• 기존 미완 LLM/TTS 등은 검증에서 제외·보존. 기존 AWS 문자열 캐시와 실제 생산자는 미연결이다. 일반 publish가 남으므로 전역 key 발행권 ACL로 간주하지 않는다.
• 실기기·AOSP 제품 부팅·공개 Binder·Task 성공·자원 FREE는 이번 검증 범위가 아니다.

2026-09-14 — 기존 공기질 등급 판정을 도메인 정책으로 이관

후속: AirQuality·IoT·Power 상태 계약과 관측 연결부의 폴더 분리

• 운영 클래스 10개를 각 도메인의 state/, observation/로 분리하고 테스트 3개도 이동했다. ManagerService와 공기질 policy 경계는 유지했다.
• 폴더 검사 RED(20개 하위 assertion 실패) 후 GREEN, 계층·폴더·API 검사 통과.
• 191ada8 정본과 이 폴더 변경의 스냅샷에서 서버 674개·SDK 62개, Runtime release 빌드 통과. 98개 Gradle 작업을 모두 재실행했다.
• 실제 생산자 구독·서비스 세대 검증은 미연결이며, 상태 소유권 전체 이관으로 표시하지 않는다.

후속: 보고서 기반 청소 후보 우선순위와 전체 회귀

• 기존 AirQualityPriorityResolver의 보고서 최소 10회·나쁜 등급 판정·PM/가스 집계·후보 정렬을 domain/airquality/policy/AirQualityReportPolicy로 이관했다. DB·Bundle·지도 접근은 기존 연결부에 둔다.
• 동률일 때만 PM10을 읽는 기존 순서와 예외 의미를 유지한다. 신규 정책 14개·등급 정책 5개 검사 통과.
• DeviceAgent 22개 검사·debug APK·컴파일 소스 경계 검사 통과, 38개 작업 모두 재실행. 바이트코드의 정본 정책 호출 4개 확인.
• 검토된 c268aa0 정본 소스에 이번 정책·테스트를 추가한 스냅샷 기준 서버 674개·SDK 62개 검사 통과, 98개 작업 전부 실행 및 Runtime release APK 생성. 미완 LLM 등 dirty 수정은 이 전체 검사에서 제외·보존했다.
• Runtime APK SHA-256: b49e87fefd94516665c8605a6088446fb4166ac0fff9744f139d39cf1e6ccaa6.
• 개별 서비스 상태·센서 생산자·제품 부팅 이관과 실기기 검증은 남아 있다.

최초: 센서 등급 판정

• 실제 AirQualityManager.evaluateAirQuality가 domain/airquality/policy/LegacyAirQualityGradingPolicy에 위임한다.
• PM 경계, TVOC·NOx의 저장 문자열 사용, HCHO·CO₂ 이분 판정, 비정상 문자열 예외와 가변 경계표 의미 보존.
• 정책 JUnit 5개와 DeviceAgent 기존 22개 테스트 통과. debug APK 생성, 빌드 작업 38개 모두 재실행.
• 평가된 컴파일 소스에서 공기질 정책 하위 폴더만 추가됨을 확인하고, 바이트코드에서 정본 정책 호출 확인.
• 계층·정본 폴더·API 경계 검사 통과. 상태 소유권 이관·서버 전체 회귀·제품 부팅·실기기 검증을 의미하지 않는다.
• 폴더 책임·보존 규칙·검증 상세.

2026-09-12 — 공통 Task 계층 의존 검사와 폴더 지도 정정

• 공통 server.execution.*에서 구체적인 server.domain.* import를 금지했다. 도메인에서 공통 Task 계약을 사용하는 방향은 허용한다.
• 기존 검사에서 AMR 서비스 의존을 놓치는 실패를 재현한 뒤 일반·static·wildcard import 회귀 검사를 통과시켰다.
• 실제 트리 계층 검사와 폴더 검사 4개 통과. 이 항목은 정적 경계 보강이며 Java 동작 변경·APK 빌드·실기기 검증을 포함하지 않는다.
• 폴더 지도에서 core/java의 Manager·모델과 core/aidl 통신 계약을 구분하고, services/systemserver의 구체적인 시작 서비스가 미구현임을 명시했다.
• 존재하지 않는 SVG 참조를 기존 상세 폴더·전체 상태 그림으로 연결했다. 큰 구조도는 유지한다.
• 초안의 “완전 검증”, “AOSP core runtime 완료/안정”, “소유권 교차가 없다”는 표현을 검증 범위에 맞춰 정정했다.

2026-09-11 — Vision 내부 카메라 세션 수명

• 코드 85d4984: domain/vision/session/CameraSessionService와 Vision 시작·종료 연결, 대응 테스트 2종 추가.
• 소유자·발급 서비스·READY 순번·활성 핸들 검증, 단일 반환, 종료·복구 무효화, STREAM 공유와 EXCLUSIVE 참조 의미 보존.
• API 미존재 RED와 12개 동작 RED를 구분하고 GREEN을 확인한 뒤 상태·경합·등록소 검사를 보강했다. 신규 세션 16개·등록소 3개, 총 19개 통과.
• 정본 스냅샷 전체 재실행: 서버 655개·SDK 62개, 실패·오류·건너뜀 0. 빌드 작업 98개 모두 실행, release APK 생성 성공.
• 기존 DeviceAgent 22개 테스트·debug APK 생성 성공, 38개 작업 모두 재실행. 미완 LLM/TTS는 격리·보존.
• 전체 현황 SVG의 378개 요소 구조·좌표를 유지하고 Vision 문구 3곳만 변경했다. 상태는 ‘일부 구현’으로 유지한다.
• 기존 static 카메라 경로와 새 내부 서비스는 별개다. 브로커·공통 CAMERA 자원·공개 IPC·제품 부팅·실기기 미연결/미검증.
• 폴더·세션·기존 앱 경계 상세.

2026-09-11 — 현황판 분리와 Cleaning 인계 내부 검증

후속 검증 정정 — DeviceAgent AMR 소스 경계

a2897c1에서 기존 DeviceAgent를 컴파일하자 TaskManager·관측·수명 의존성 누락으로 100개 오류가 발생했다. 아래 폴더 이동의 서버·SDK 검증은 기존 앱 빌드를 포함하지 않았다. AMR 실행 폴더로 관리형 코드가 옮겨졌는데 앱이 폴더 전체를 가져오던 것이 원인이다.

• DeviceAgent에는 AmrOperations.java, AmrMoveTarget.java만 포함하도록 정본 경로에 한정한 제외 조건을 적용했다.
• 공통 execution/task/와 도메인 amr/execution/ 위치는 유지한다. 공통 Runtime을 앱에 추가하지 않는다.
• 실제 컴파일 소스 검사에서 수정 전 관리형 코드 유입으로 실패, 수정 후 통과를 확인했다.
• --offline --rerun-tasks: 빌드 작업 38개 모두 실행. DeviceAgent 테스트 22개, 실패·오류·건너뜀 0 및 debug APK 생성 성공.
• 경계 검사 4종·폴더 검사 4개 통과. 별도 코드 리뷰 차단 이슈 없음.
• DeviceAgent debug APK SHA-256: 94aae654a8a58db7cf2b1d6a6c2d57538872ba4eba4a33fb443badac9d757c5f.
• 기기 설치·서명 변경·제품 부팅·물리 동작 검증은 하지 않았다. Vision static 접근 상태의 서비스 이관은 여전히 후속 작업이다.

폴더·패키지 명확화 — 공통 TaskManager와 도메인 실행

domain/amr/task/는 domain/amr/execution/으로, domain/cleaning/task/CleaningTransitionPort는 domain/cleaning/execution/으로, CleaningMovementHandoff 계열은 domain/cleaning/handoff/으로 옮겼다. 공통 execution/task/TaskManagerService는 유지한다. 동작 변경 없음: 도메인별 TaskManager를 추가하거나 공통 TaskManager로 장치 실행기를 몰아넣는 변경이 아니다. 현재 문서·SVG·MMD는 새 경로로 맞추고, 아래 과거 검증 기록의 경로는 당시 기준으로 읽는다.

• 코드 22b671d: 13개 도메인 Java 파일과 대응 테스트·참조 이동, 세 폴더의 책임 설명 및 경로 회귀 검사 추가.
• 경로 검사 4개, 격리 정본 서버 636개·SDK 62개 테스트 통과. release APK와 경계 검사 4종 통과.
• 이동 후 APK SHA-256: ec12b1de288d92d9f0dd0b7888ca5db99e159d0f1a210b7d7de2c60389e947e9.
• 제품 활성화·실기기 검증을 의미하지 않는다. 아래는 이동 전 인계 구현의 기록이다.

앞선 현황판·Cleaning 인계 검증 기록

• 현재 진행 현황을 전체 계층·15개 도메인 상태 지도와 남은 작업 중심으로 재구성했다. 날짜별 기록과 기존 큰 SVG는 이 페이지로 보존했다.
• Cleaning 인계 코드: 44f83f8 → 6240b4c → b73e99c → bb001f2. 정책 변경과 claim 잠금 경합, 조회 중 제3자 점유 보존을 회귀 테스트로 고정했다.
• 최종 정본 스냅샷 전체 재실행: 서버 636개, SDK 62개, failures/errors/skipped 0. release APK, 경계 검사 4종 통과. 명세·품질 리뷰 차단 이슈 없음.
• APK SHA-256: 92a8595f095c93bfc7afd45ae7ef892cda1ca284148ac9d176c93cd59c708c7f.
• 제품 공급자 연결·AOSP 이미지 설치·물리 동작 검증은 미완이다. 미완 LLM/TTS 작업은 제외·보존했다.
• 청소 → 이동 인계 상세 · 현재 상태 지도.

이전 진행 페이지 보존 기록

아래는 분리 이전 진행 페이지의 본문이다. 목표 구조·설계 기준은 Blueprint에, 과거 구현 커밋·검증 결과·당시 미완 항목은 아래에 남긴다. 외부 로봇 SDK별 호환성 검토는 별도 작업이며 아래 구현 실적에 합산하지 않는다.

현재 우선순위 — 개별 기능 이식으로 전환

현재 연결 작업 — Cleaning → AMR 구동 자원 인계: 청소가 실제로 점유한 MOVEMENT_BASE를 원래 Cleaning 서비스가 정지·반환하고, 별도 최신 구동부 idle 관측과 자원 버전 재확인 후 AMR이 새로 획득하는 선택형 경로를 구현·검증 중이다. 전체 위치·폴더별 책임·단계별 자원 상태 SVG에서 청소 정지, 팬 정지, 구동부 정지, Task 완료가 각각 다른 이유를 설명한다. 아래 5d6280c 수치는 이전 완료 단계의 기록이며 이번 연결의 검증 수치가 아니다.

2026-09-11 AMR 취소 관측의 서비스 수명 연결: AmrManagerService가 선택형 AmrAbortObservationService를 시작·종료한다. MovementTaskSession.executeWithAbortObservation은 실행 종료 뒤에도 원래 등록·시도·관측 수신기를 유지해 유효한 ABORTED만 공통 Task 취소 완료로 전달한다. 용량·시간 초과·세대 변경·중복 전달·이전 소유자 변경을 차단하고 종료 사유는 CloseReason으로 정의했다. 같은 시도를 가리키더라도 다른 수신기의 수락 결과는 인계 전에 거부한다. 서버 604개·SDK 62개, 실패·오류·건너뜀 0 및 release APK 빌드 통과(기존 미완 LLM/TTS 제외). 자원 FREE·제품 활성화·실기기 검증은 포함하지 않는다. 전체 위치·폴더·수명 흐름 SVG.

전체 정리: 소스 README에 SDK → Binder → Android 호스트 → Runtime → 공통 서비스 → 도메인 → 제품 어댑터의 역할과 실제 연결 상태를 정리했다. Blueprint의 빠진 상세 문서 연결을 복구하고 기존 전체 구조도를 유지했다. 다음 연결 공백은 Cleaning 소유자의 정지 협력 → 자원 반환·재확인 → AMR 획득이며 MR6 task_manager 소스와 대조했다. 팬 정지를 전체 청소·구동부 정지로 취급하지 않는다.

구현 커밋: 5d6280c, 브랜치 refactor/blueprint-foundation 유지. 최종 서버·SDK 빌드 작업 98개를 모두 재실행했다. 설계 준수·품질 리뷰의 소유권/수락 결과 출처 지적을 회귀 테스트로 수정했다. SKIX 문서 검사 111개, Wiki lint 오류 0개 (기존 오래된 문서 경고 8개), 정적 사이트 빌드 통과. Blueprint의 큰 SVG 11개를 유지한다. 문서 검사는 로봇 기능의 실기기 검증 수치에 합산하지 않는다.

이전 단계 — 2026-09-11 AMR 수락 관측의 일회 인수: AmrObservationIngress.takeAccepted에서 원래 수신기의 최신 수락 결과만 한 번 인수하도록 구현했다. 다른 수신기의 결과·중복 인수·만료·공급자 재시작을 검사하고 원본 순번·ID·이유를 유지한다. 당시 신규 12개 포함 서버 576개·SDK 62개 테스트, 실패·오류·건너뜀 0, 전체 재실행·release APK·경계 검사 통과(기존 미완 LLM/TTS 제외). 당시 미완이었던 서비스 소유권 인계·만료 정리는 위 단계에서 연결했다. 제품 연결은 후속이다. 필요한 이유와 남은 연결.

2026-09-11 AMR 사전 등록·완료 전달: 내부 선택형 executeWithCompletion에서 명령 전 등록 → 실제 시도 결합 → 현재 실행권·원본 근거 재검사 → 공통 Task 완료 접수를 연결했다. 등록 실패와 다른 TaskManager 오배선은 명령 전에 거부한다. 원본 ID 누락·변형, 위치 기반 추정은 성공으로 바꾸지 않는다. 승인된 Task는 SUCCEEDED로 전이하지만 자원은 UNVERIFIED로 유지한다. 신규 10개 포함 서버 564개·SDK 62개, 실패·오류·건너뜀 0, 전체 재실행·release APK·경계 검사 통과. 공통 소유권 검증을 포함하고 미완 LLM/TTS 구현은 제외한 검증이다. 기존 API는 유지하며 제품 경로 활성화·지속 중단 관측·실기기 검증은 후속이다. 폴더·실행 흐름·보류 사유.

이전 단계 — 2026-09-11 AMR 원본 이벤트 ID 보존: AmrObservationEnvelope.eventId()와 4인자 생성자로 원본 식별자를 수정 없이 보존한다. 기존 3인자 생성자와 관측 순번 검사는 유지한다. 당시 후속이었던 사전 등록·시도 결합·Task 완료 전달은 위 단계에서 연결했다. 제품 공급자 연결은 후속이며 제품 이벤트 ID가 실제로 공급된다는 뜻은 아니다. 역할과 남은 연결 상세.

2026-09-10 AMR 완료 인계 준비: 관측 원본 봉투와 실제 세션 실행권을 결과에 보존하고, assessCompletion으로 반환 이후 취소·서비스/공급자 재시작·관측 만료를 구분하도록 구현했다. 위치 안정·이미 충전소인 결과를 완료 이벤트로 합성하지 않는다. 신규 10개 포함 서버 551개·SDK 62개 JVM 테스트 실패·오류·건너뜀 0, 전체 98개 빌드 작업 재실행·release APK 생성·경계 검사 통과(미완 LLM/TTS 제외). Task 성공 전환·자원 FREE·제품 경로 활성화는 범위 밖이며 원본 eventId와 공통 완료 실행 등록은 후속이다. 폴더별 책임과 판정값 상세.

2026-09-10 AMR 실행 종료 근거 구분: MovementExecutionResult로 도착 응답·위치 안정·충전 응답·이미 충전소인 경우를 구분했다. 기존 void API와 이동 동작을 유지하며, 이 결과를 Task 완료나 자원 안전 증거로 승격하지 않는다. 신규 6개 및 기존 회귀 검사 보강을 포함한 서버 541개·SDK 62개 JVM 테스트 실패 0, 캐시 없는 전체 재실행·release APK 빌드·설계 준수 리뷰 통과. 기존 미완 LLM/TTS 변경은 검증에서 제외했다. 제품 콜백·Task 완료 연결·실기기 검증은 남아 있다. 결과별 의미와 API 책임.

2026-09-10 AMR 관측 검증기와 이동 세션 연결: CorrelatedMovementRuntime으로 원본 관측 계약을 명시하고, MovementTaskSession에서 수신 검증·소비 전 권한 재검사·종료 시 수신 폐기를 연결했다. 신규 12개 포함 서버 535개·SDK 62개 JVM 테스트 실패 0, release APK 빌드와 설계·품질 리뷰 통과. 제품 콜백·Task 완료 연결은 이번 범위가 아니다. 기존 위치 안정성 경로도 최종 완료 증거로 승격하지 않는다. 연결 구조와 검증 범위.

이전 단계 — 2026-09-10 AMR 관측 수신 검증기: 원본 관측의 실행 시도·세대·대상·순번·시각을 검증하는 domain/amr/observation/를 구현했다. 이전 작업 이벤트·중복·만료 관측을 거부하고, 거부 이유는 도메인 enum으로 구분한다. 신규 23개 포함 서버 523개·SDK 62개 JVM 테스트와 release APK 빌드 통과. 당시에는 제품 콜백·이동 실행기에 연결하지 않은 내부 검증기였다. 현재 이동 세션 연결 상태는 위 항목에서 관리하며 하드웨어 출처 인증이나 Task 완료 처리와 구별한다. 수신 경계와 남은 제품 연결. 기존 전체 구조도 11개는 유지한다.

2026-09-10 AMR 작업 상태 연결: 이동 세션의 Task 실행권을 AMR 작업 토큰에 연결했다. 최신 IDLE 없이 실행을 시작하지 않으며 정지 요청·오류·토큰 교체 이후 후속 검사에서 실행을 거부한다. 이동 명령 이후 취소도 실제 물리 정지나 Task 완료로 바꾸지 않는다. 이번 11개 추가 검사 포함 서버 500개·SDK 62개 JVM 테스트 및 release APK 빌드 통과. 내부 실행 경로 구현이며 제품 경로 활성화는 아니다. 제품 콜백·완료 증거 전달·기기 검증은 남아 있다. 상태·명령·완료를 나눈 연결 상세.

이전 단계 — 2026-09-10 이동 경로 내부 통합 검증: 실제 RuntimeHost·공통 서비스·AMR·Cleaning 서비스를 조립해 접수→실행권→자원→이동 실행을 신규 10개 시나리오로 검증했다. 당시 전체 서버 489개·SDK 62개 JVM 테스트 및 release APK 빌드 통과. 두 호출자의 자원 경합, 청소 정지 직후 취소, 서비스 장애·호스트 종료, 이전 세대 관측을 확인했다. 당시 남아 있던 AMR 상태 정본 연결은 위 단계에서 구현했다. 이전 검증과 제품 연결 경계. Blueprint의 전체 구조도 11개와 기존 SVG는 그대로 유지한다.

2026-09-10 이동 실행 준비 연결: 발급된 Task 실행권에서 구동 자원 확보와 MovementTaskSession 생성까지 연결했다. 자원 미확인 시 실행권을 유지하고, 중복 실행 준비·실행 전 정책 변경·청소 정지 후 정책 변경을 거부한다. 서버 479개·SDK 62개 JVM 테스트와 release 빌드 통과(미완 LLM/TTS 변경 제외). 스케줄러·제품 관측·Task 종료·실기기는 미완이다. 구조·검증·남은 연결.

Blueprint 큰 구조도 복원: AOSP–SKIX 전체 배치, 서비스 계층, 요청·결과 흐름, 서비스·Task 생명주기 등 기존 SVG 7개를 Blueprint 본문의 관련 절에 다시 배치했다. 기존 상세도는 단순화하지 않았으며 초기 설계와 현재 목표의 차이를 설명으로 구분했다. 핵심 구조도는 보존본 링크로만 대체하지 않는다.

AMR 소유자 기반 Task 접수 (8e2d7c6, 2026-09-10): AmrTaskEndpoint → MovementTaskAdmission → TaskManagerService를 연결했다. 이동·복귀 입력과 검증된 호출자 소유권을 함께 저장하고, 필수 도메인 정책 검사 전후로 권한·서비스 준비 상태·세대를 확인한다. 신규 14개, 서버 전체 461개·SDK 62개 JVM 테스트와 release 빌드를 통과했다(기존 미완 LLM/TTS 변경 제외). 접수 경계 구현이며 실제 제품 정책·실행 배정·구동부·공개 Binder 연결 완료는 아니다. 폴더·접수 흐름·남은 실행 연결.

2026-09-10 설계 문서 재구성: Blueprint를 목적 → 전체 구동 구조 → 폴더 → 공통·15개 도메인 책임 → 실행 흐름 → 상태·자원 → 정책·계약 → 이관 계획 순서로 정리했다. 초기 DeviceAgent 내부 집중 배치와 범용 Task 제출 예시는 현재 목표와 분리하고 기존 상세 설명·SVG 보존본으로 옮겼다. 문서 정리이며 코드 구현률 증가나 제품 연결 완료를 뜻하지 않는다.

Task typed Binder·SDK 연결 (dba443e): SkixTaskManager → ITaskManager → TaskManagerBinderService → 기존 소유권 endpoint의 조회·목록·취소 경로를 구현했다. 서버 447개·SDK 62개 JVM 테스트와 release APK 빌드를 통과했다. Stub·SDK 구현 완료와 공개 Binder 활성화는 다르다. 현재 호스트는 외부 Binder를 공개하지 않으며 Root 등록·앱 간 실제 통신·제품 부팅은 미검증이다. 폴더·오류 계약·검증 상세.

취소 요청 수락은 CANCELLING이며 물리 정지나 자원 반환 완료를 뜻하지 않는다. 오류 전달에는 일반 Android SDK에서 사용할 수 없는 숨김 API 대신 typed 결과를 사용한다. 통신 실패 시 취소를 자동 재전송하지 않으며 결과가 불명확할 수 있음을 알린다. 실제 통신 실패 경로의 Android 실행 검증은 후속이다.

Task 소유자별 조회·취소 (dab4e73, 보강 2d35b09): Task 소유권과 실제 서비스 연결. 접수 시 UID·사용자·패키지 소유권을 Task 기록에 함께 저장하고, 매 조회·취소에서 권한·런타임 세대와 소유권을 검사한다. 서버 447개·SDK 46개 테스트 및 release APK 빌드를 통과했다. 공개 Binder·제품 경로 활성화·실기기 검증은 미완이며 취소 수락은 물리 정지 완료가 아니다. 기존 전체 구조도는 유지한다.

Cleaning 팬 관측 후속 (bacc1e5): 팬 관측·정지 근거의 서비스 소유권. 요청 전 RPM 0을 새 정지 근거로 재사용하지 않는 내부 계약을 구현하고 사양·품질 검토를 통과했다. 커밋 서버 409개·SDK 46개 테스트 결과와 서버 release Java 컴파일을 확인했다. 팬 정지와 AMR 정지·Task 완료·자원 반환은 별도이며 MCU 제품 연결은 미완이다.

프레임워크로 실제 구동되는가: 비공개 Android 시작 서비스와 내부 런타임 연결을 추가했다. SkixFrameworkHostService가 FrameworkRuntimeHost를 통해 공통 서비스 7개를 시작하고 역순 종료한다. 이는 코드 연결이며 제품 자동 부팅·외부 Manager 공개·전체 도메인 활성화·실기기 동작 완료가 아니다. 세부 검증 상태는 연결 상세 페이지에서 확인한다. 시작·권한·통신·도메인 실행·실제 관측·완료 근거까지 확인하는 것이 제품 연결의 후속 완료 기준이다.

AMR 상태 소유권 후속 (c624e6e, 보강 e30b4fa): 요청·관측 분리와 서비스 상태 전이 상세. 정지 요청을 실제 IDLE로 취급하지 않도록 내부 계약을 구현했다. 제품 콜백·실행 세션 연결은 후속이며, 다른 도메인까지 완료한 것은 아니다.

후속 이식 상세: 이동 작업 실행 — 청소 정지부터 도착·구동부 정지까지. 상태·자원·동시 접근의 도메인별 소유권 지도를 추가했다. 상태 enum 정의와 실제 전이 강제·제품 연결의 차이를 구분한다.

MR6의 완료 대기 절차를 AMR 내부 실행기와 Cleaning 협력 포트로 분리했다(4715e62, 시간 판정 보강 60ca9d1). 후속 3a7aa902에서 Task 단일 실행 권한·자원 예약 식별·서비스 세대 검사를 MovementTaskSession에 연결했다. 후속 e30b4fa 검증(2026-09-10)은 커밋된 서버 397개·SDK 46개 테스트와 서버 release Java 컴파일을 통과했다. AMR 상태·기존 서비스·세션 집중 검사는 29개다. 이전 3a7aa902의 권한·자원·세션 집중 40개는 별도 검증 이력이며 합산 수치가 아니다. 기존 제품 경로에 연결된 즉시 명령 이관과, 아직 제품 어댑터가 필요한 관리형 실행기 이식을 구분해서 본다.

LLM/TTS 공통 기반의 추가 확장은 보류하고, 다른 도메인의 실제 실행 책임 이관을 우선한다. ManagerService 클래스가 생긴 것과 기존 기능이 그 서비스에서 실행되는 것은 다르다. AMR·Cleaning·Vision의 기존 handler가 정본 실행·정책 코드를 호출하도록 이관했다. AMR 서비스에는 준비 상태를 검사하는 실행 진입점도 추가했지만, 현재 제품 요청은 기존 DeviceAgent Binder를 사용한다. 새 Runtime·Task 경로 이식 완료와 구분한다.

이번 코드 이관의 폴더·호출 경로: AMR·Cleaning·Vision 실제 연결 상세도. 전체 구조 Atlas와 기존 모듈 지도는 유지하고, 새 상세도에서 이번에 바뀐 부분만 확대한다.

5fd2370 검증: 커밋된 서버만 분리한 JVM 339개, SDK 46개, DeviceAgent 22개 통과. 서버 release Java 컴파일과 DeviceAgent release APK 빌드도 성공했다. 실패·오류·건너뜀은 0이다. 세 도메인의 사양·품질 검토와 통합 검토를 마쳤으며 실기기 검증 및 새 Runtime 통합은 미완료다. 보류 TTS 수정은 이 커밋에 포함하지 않았다. 아래 날짜별 수치는 별도의 과거 검증 이력이다.

LLM/TTS의 새 Dispatcher 작업은 진행 중 체크포인트다. 독립 검토·제품 연결 완료로 표시하지 않는다. 기존 AI Agent의 합성·재생 책임은 유지하며, 이 작업을 모든 도메인 이관의 선행 조건으로 삼지 않는다. 위 표는 작업 우선순위이고, 제품 배포 전에 필요한 Android 호스트·권한 검증을 생략한다는 뜻이 아니다. 실행기별 원본과 목표 소유자는 MR6 실행기 이관 표를 함께 본다.

현재 위치 — 전체 구조에서 무엇이 바뀌었나

전체 위치는 구조 Atlas, 실행 사례는 AI Agent·LLM·Task 역할 해설에서 본다. 아래 날짜별 기록은 누적 이력이며, 예전 테스트 수치를 오늘의 전체 검증 결과로 읽지 않는다.

다른 로봇 제어 SDK와의 연동 경계

프레임워크가 특정 기기나 로봇 SDK에 종속되지 않도록 공통 기능 계약과 실제 실행 어댑터를 분리한다. 앱은 SKIX Manager로 기능을 요청하고, 도메인 서비스는 Task·State·Evidence의 공통 의미를 사용한다. 다른 로봇 제어 SDK를 연결할 때 바뀌는 부분은 해당 SDK를 호출하고 결과를 변환하는 어댑터다. 같은 소스나 바이너리를 모든 로봇에서 그대로 실행한다는 뜻은 아니다.

이것은 호환성을 확보하기 위한 설계 경계이며 다른 로봇 SDK와의 연동 완료 표시가 아니다. 특정 제품의 함수명·통신 토픽·설치 방식은 공개 Manager API에 그대로 넣지 않는다. 개별 로봇 연결 사례의 상세 내용은 별도 SDK 연동 설계에서 관리한다.

2026-09-09 후속 구현 반영: 상태 판정은 c960924로 커밋됐고 실제 DeviceAgent 경로에는 아직 연결하지 않았다. 세 판정은 잠금 중 수신 허용·기존 재개용 처리 상태·IoT 활성이다. 0bd43fe에서 실제 콜백 순서·예외·재진입을 테스트했고 b2b45fa에서 송신 계약 정의를 공용 폴더로 모았다. 역할 해설의 폴더 절에서 상태 9와 외부 TTS의 의미가 왜 다른지 설명한다.

각 행은 당시 코드 검증 기록이며 합산한 새 전체 테스트 결과가 아니다. 실패·오류·건너뜀은 모두 0이었다. 기존 Android Log stub stderr 및 빌드 경고는 남아 있다. 독립 리뷰는 에이전트 수 제한으로 미수행이다. 이번 Wiki 배포에서는 문서 검사·빌드·공개 페이지를 검증하며 Android 검증을 새로 했다고 주장하지 않는다.

후속 순서는 70bf49c 감사에서 선행 조건을 보완했다. Task 전용 Binder → Android Runtime 호스트 → SystemServer·제품 연결 → 기존 실행을 유지한 LLM 비교 → Cleaning·AMR 등 소유 도메인으로 책임 이관 → 종단 검증이다. Manifest에 Service 선언이 아직 없으므로 Java 객체 조립을 제품 실행으로 취급하지 않는다. TTS 합성·재생 엔진 자체는 AI Agent에 유지한다.

2026-09-09 추가 확인 · 무엇이 구현이고 무엇이 미연결인가

261f689의 검사기 회귀 6개는 당시 통과했으며 Java 전체 구문 분석이나 실기기 통신 검증은 아니다. 기존 9개 handler 기록은 당시 범위로 남기며 현재 기본 검사 범위는 10개 소스다. 70bf49c는 설계 오류와 누락 경로를 밝힌 문서 커밋이며 Android 호스트 구현 커밋이 아니다. 전체 구조와 폴더별 실행 단계, AI Agent·TTS 역할 해설에서 같은 기준으로 읽을 수 있다.

2026-09-09 · LLM 통신 계약과 DeviceAgent 폴더 경계 반영

850d2f2에서 LlmCommandHandler의 통신 상수를 실제 소유 도메인으로 연결했고, aeaa175에서 DeviceAgent가 SDK 전용 어댑터까지 컴파일하던 설정을 계약 폴더로 제한했다. 검사 대상은 DeviceAgent 9개 handler, 명령 소유권은 273개다. 제품 정책 변경이나 TTS 엔진 이관은 하지 않았다.

변경한 폴더·역할·검증·남은 작업에서 실제 소스 경계와 아직 기존 코드에 남아 있는 책임을 함께 확인할 수 있다.

2026-09-09 · LLM 내부 연결 관리와 문서 읽기 순서 정리

이번 구현은 TTS 엔진 이관이 아니라, AI Agent와 연동할 프레임워크 내부 관리 책임을 연결한 것이다. domain/llm/completion/TtsManagedHost.java가 연결을 소유하고 기존 관측 큐에 위임한다. LlmManagerService는 이 객체를 선택적으로 받아 서비스 종료 때 닫는다. 연결 폐기는 control/capability/의 closeProviderConnection()을 사용하며, Task 상태와 Resource 점유는 기존 소유 서비스에 남긴다.

기본 런타임은 기존 7개 서비스를 유지한다. 테스트용 LLM 조립과 제품 기본 구성을 혼동하지 않는다.

구현 커밋 34c08bd에서 전체 강제 재실행: 서버 JVM 39개 클래스 / 290개, SDK JVM 11개 클래스 / 37개, 실패·오류·건너뜀 0. 새 호스트 17개는 서버 합계에 포함된다. release Java 컴파일, 폴더·레이어 검사와 각 검사기 회귀, Resource snapshot 정적 회귀도 통과했다. APK 설치·AOSP 제품 부팅·AI Agent 실제 재생은 미검증이다.

문서는 전체 Atlas → 폴더별 역할·상태 책임 → 실행·결과 흐름 해설 순서로 읽도록 연결했다. 기존 상세 구조도를 삭제하지 않았고, 역할 해설의 내부 위임만 실선으로 갱신했다. 실제 생산자 연결은 점선으로 남긴다.

2026-09-09 · AI Agent와 프레임워크 역할 해설

역할 해설·확대 구조도를 추가했다. AI Agent의 실제 TTS 실행, 프레임워크의 연결·관측 전달, TaskManager의 작업 상태를 분리해서 설명한다. Blueprint·전체 Atlas·구성요소 상세 지도·기존 TTS 전달 문서에서 연결하며 기존 전체 SVG는 유지한다.

초기 설계 기록: 당시 MR7 f161ec3은 관리 객체 설계 문서 커밋이었다. TtsManagedHost는 설계 단계였으며, 실제 생산자 실행 키 전달·호스트 구현·Android 종단 연결은 완료하지 않은 상태였다. 후속 내부 구현은 위 항목을 따른다. 이번 정리는 문서·SVG 변경이며 아래 9월 8일 테스트 수치를 새 실행 결과로 재사용하지 않는다.

2026-09-08 · 전체 구성요소 상세 지도

최신 구현: 제공자 재연결 보호와 TTS 관측의 순서 보존

같은 서비스 세대 안에서 재연결해도 이전 연결의 READY·해제를 차단한다. LLM 도메인의 전달 큐는 실행 키가 있는 관측만 받아 제한된 FIFO로 전달하며, BUSY·예외 재시도와 전달 중 close가 서로 섞이지 않도록 세션을 보호한다. 기본 Runtime 7개 및 Resource 소유권은 변경하지 않았다. Android 생산자 자동 결선은 아직 별도다.

전체 강제 재실행: 서버 JVM 38개 클래스 / 265개, SDK JVM 11개 클래스 / 37개, 실패·오류·건너뜀 0. release Java 컴파일과 폴더·레이어 및 각 회귀 검사도 통과했다. 기존 전체 구조도는 유지하고 연결·전달·Task 소유권 확대 SVG/Mermaid 1개를 추가했다. 최종 독립 사양·품질 검토와 Wiki 검사 65개도 통과했다.

제공자 연결 세대·TTS 관측 전달 상세 · 전체 폴더와 모듈 지도

앞선 구현: 자원 소유권·기능 조회·Task를 실제 기본 Runtime에 연결

control/resource/는 주행부·카메라 등 6개 공유 자원의 소유권을, control/capability/는 기능 명세와 제공자의 현재 준비 상태를 관리한다. Task는 기존 작업 접수·상태 관리 책임을 유지한다. 기본 Runtime은 Runtime → State → Evidence → Policy → Resource → Capability → Task의 실제 7개 객체를 조립한다. 모두 같은 생명주기 감독자를 사용하며, Capability가 조회하는 Resource도 Runtime의 동일 객체다.

자원은 미확인 상태로 시작하고 반환 후에도 물리 정지 확인 전에는 사용 가능으로 바뀌지 않는다. 기능 조회는 정책 승인이나 자원 확보가 아니며, 기본 기능 목록은 비어 있다. MR6 제품별 충돌 규칙은 공통 Resource가 아닌 execution/task/admission/에 이관했다. 장치 실행기·LLM/TTS 자동 결선·Android 부팅 호스트는 이번 완료 범위에 포함하지 않는다.

이 단계의 전체 재실행 기준 서버 JVM 36개 클래스 / 236개 검사, SDK JVM 11개 클래스 / 37개 검사가 실패·오류·건너뜀 없이 통과했다. release Java 컴파일과 폴더·레이어 검사 및 회귀 검사도 통과했다. 기존 Policy 테스트의 4개 서비스 기대값은 현재 7개로 갱신했으며 시작 전·중지 후 거부 검사는 보존했다. Wiki 전용 검사는 64개 통과, lint는 오류 0개와 기존 최신성 경고 8개다. 전체 구조 SVG 6개를 현재 Runtime에 맞게 갱신하고 자원·기능·작업 확대 SVG 1개를 추가했다.

자원·기능·작업 상세와 확대 SVG · 전체 폴더와 모듈 지도

이전 구현: TTS 완료 처리를 LLM 도메인과 Task 계층으로 분리

base/services/core/.../server/domain/llm/completion/이 재생 완료 조건을 해석하고, execution/task/completion/이 작업·시도·서비스 세대와 결과를 연결하도록 구현했다. TaskManagerService만 작업 상태를 변경하며, Evidence 기록 성공 여부는 별도로 반환한다. 이전 실행의 콜백·중복·역순·종료 경쟁·근거 기록 재진입을 검사하고, 처리 중 겹치는 콜백에는 명시적 재시도 응답을 준다.

서버 JVM 193개, SDK JVM 37개, release Java 컴파일 및 폴더·레이어 회귀 검사가 통과했다. 기존 전체 SVG를 보존하고 TTS 폴더별 책임·호출 흐름 확대 SVG를 추가했다. TTS 단계 당시에는 Resource·Capability와 기본 Task 결선이 후속 작업이었다. 현재 내부 7개 서비스 구성은 최신 상세 문서로 갱신하며, 장치 콜백·LLM/TTS 기본 결선은 여전히 후속 작업이다.

TTS 구현·상세 SVG·검증 범위 · 전체 폴더와 모듈 지도

MR6 이관 전 기준선: 원본 Task JVM 250개 통과

task_manager 커밋 d1d8dfbc의 DeviceAgent를 임시 경로에 추출해 원본 테스트를 실행했다. 완료 감시·TTS·주행·청정·앱 세션·보안·작업·관측 등을 포함한 28개 클래스 / 250개 검사가 실패·오류·건너뜀 없이 통과했다. MR6 사용 중인 체크아웃은 유지했다. 이 결과는 원본 이관 기준선이며 MR7 기능 이관이나 실제 장치 동작 완료를 의미하지 않는다.

원본 테스트 결과·도메인별 이관 폴더·검증 한계

폴더 소유권 검사 보완: AIDL 계약

새 프레임워크 AIDL의 패키지·폴더 불일치와 SDK 앱 아래 복제본을 구조 검사에서 거부하도록 수정했다. 두 누락 사례의 실패를 먼저 재현한 뒤 수정했으며, 정상 구조와 기존 IPC 계약은 계속 허용한다. 폴더·레이어 검사 및 각각의 회귀 검사가 통과했다. Android 실행 코드·빌드 설정은 변경하지 않았고, 이번 검사 보완으로 AOSP 이미지·실기기 통합 완료를 주장하지 않는다.

폴더 SVG·역할·검사 범위 설명

후속 분석: 완료 감시를 공통 서비스에 복사하면 안 되는 이유

MR6 완료 표적 24개를 생산자·도메인별로 추적했다. 주행의 도착 후 IDLE 확인, 청정의 시작·단계·보고 완료 구분, TTS의 시작 관측 후 IDLE 조건은 각각 도메인 사양이다. 원본 테스트에는 성공·중단 관측이 함께 있으면 성공을 우선하는 계약도 존재한다. 전역 key와 폴링을 그대로 복사하거나 중단 우선으로 일괄 변경하지 않고, 도메인의 완료 해석과 Task별 관측 연결을 나누는 설계를 작성했다.

MR6 완료 판정 분석·24개 표적·폴더 배치·신규 계약 검토안

최초 항목은 정적 분석 및 설계였다. 이후 MR6 원본 JVM 250개를 실행했으며 결과는 위에 추가했다. 이후 TTS용 Coordinator 내부 경로는 구현·검증했다. 위 최신 항목을 기준으로 보며, 장치 연결·실기기 검증은 여전히 미완료다.

최신 추가: 관측 근거를 독립 Evidence 서비스로 이관

MR6 task_manager의 실제 관측 저장 구현을 base/services/core/.../execution/evidence/EvidenceManagerService.java로 이식했다. 전역 싱글턴을 제거하고 서비스별 준비·장애·중지 상태를 적용했다. 현재 기본 구성은 Runtime + State + Evidence + Policy + Resource + Capability + Task다. 자원·기능·작업 Runtime 상세에서 실제 구현 범위를 확인한다. 아래 단계의 더 작은 구성과 테스트 수는 각각 당시 기록이다.

원본의 bounded 보관·중복 제거·불변 관측·구독 계약을 보존하고, 로케일에 따라 금지 필드 검사가 누락되는 경우를 보완했다. 서버 JVM 167개, SDK JVM 37개, release Java 컴파일과 폴더·레이어 검사 모두 통과했다. 이는 관측 저장 책임 이관이며 Task 물리 완료·Android 콜백·실기기 통합 완료가 아니다.

원본 대응·서비스 상태·남은 연결 상세 · 폴더 구조로 읽는 설명

추가 구현: 정책 판정 서비스의 실제 런타임 등록

기본 구성은 이제 Runtime → State → Policy 순서로 시작한다. services/core/.../control/policy/PolicyManagerService.java가 같은 생명주기 감독자를 사용하는 관리 서비스로 등록되며, runtime/SkixFrameworkCompositionRoot.java가 실제 객체를 조립한다. 앱이나 도메인 폴더로 정책 판정 책임을 옮기지 않았다.

Policy가 READY가 아니면 판정 요청은 ServiceLifecycleException의 not_ready 코드로 거부한다. 이는 정책 충돌(CONFLICT)이나 요구사항 없음(NO_REQUIREMENT)과 다르며 실행 허가를 뜻하지 않는다. State 장애 시 Policy도 DEGRADED가 되고, State 복구 뒤에도 Policy의 명시적인 복구·READY 전이가 필요하다. 기존 안전·제품 사양·사용자 의도 우선순위와 틸팅 교차 도메인 판정 결과는 유지했다.

이 변경은 진입 시 준비 상태 검사와 기본 서비스 조립이다. 자동 상태 수집, 판정 중 상태의 원자성, 연속 정책 강제, Task 실행기·물리 장치 연결을 완성한 것은 아니다. 아래 앞선 작업 기록의 Runtime + State 구성은 해당 시점 기준이며, 현재 구성은 Runtime + State + Policy다.

검증: 서버 JVM 148개, SDK JVM 37개가 실패 없이 통과했고 release Java 컴파일도 통과했다. 폴더·레이어 경계 검사와 검사기 회귀 테스트, 독립 코드 리뷰를 통과했다. Wiki 관련 테스트 61개 통과, 빌드 성공, lint 오류 0개(기존 문서 노후 경고 8개). 실기기 설치·AOSP 이미지 빌드·물리 동작 검증은 미수행이다.

추가 구현: Task 서비스 생명주기와 작업 상태 분리

services/core/.../server/execution/task/TaskManagerService.java를 FrameworkManagedService에 연결했다. 모든 생성자는 같은 Runtime의 ServiceLifecycleSupervisor를 명시적으로 받고, 다른 감독자에 등록하려는 구성은 lifecycle_mismatch로 거부한다.

작업 제출·다음 작업 인출·개별 조회·목록 조회·상태 전이·취소 요청의 6개 진입점은 서비스가 READY일 때만 처리하고, 그 외에는 공개 TaskErrorCode.NOT_READY를 반환한다. 의존 서비스 장애로 DEGRADED가 된 경우도 차단하며, 의존 서비스만 복구됐다고 자동 재개하지 않는다. Task 서비스 자체가 명시적으로 READY가 되어야 재개한다.

기존 큐·우선순위·취소 후 실행자 확인·완료 이력 알고리즘은 유지한다. 이는 메서드 진입 시 준비 상태 검사다. 서비스 중지를 물리 정지·작업 완료로 바꾸지 않으며, 진행 중 호출의 배출, 실행자 정지 확인, 프로세스 재시작 후 작업 복원은 후속 통합 대상이다. 테스트의 의존 서비스는 생명주기 대역이고 제품 기본 조립은 여전히 Runtime + State다.

검증: 서버 JVM 142개·SDK JVM 37개 통과, release Java 컴파일 통과. 폴더·레이어 검사와 검사기 자체 회귀 테스트도 통과했다. 독립 코드 리뷰에서 수정 필요 사항은 없었다. 실기기 설치·AOSP 이미지 빌드·물리 동작 검증은 이번 단계에 포함하지 않았다.

문서 보강: 폴더 구조·모듈 역할·상위 서비스 명칭

폴더 → 포함 모듈 → 담당 역할 SVG를 추가했다. base/core, services/core의 내부 패키지, Android 진입부, AOSP 시작 연결, 호환·실행 어댑터, 설정·API·테스트와 apps/ 빌드 호스트를 함께 보여준다. 모듈 역할 사전은 공통 기반 10개(Runtime 포함)와 제품 도메인 15개를 담당 업무·협력 대상·실제 소스·구현 범위로 연결한다.

외부 추론·계획 주체의 예시 명칭은 framework-sdk 본문·SVG·Mermaid 전체에서 상위 지능 서비스라는 역할명으로 통일했다. 특정 프로토콜이나 제품을 필수 구성으로 두지 않는다. 기존 상세 구조도는 보존했으며, 이번 변경은 문서·그림 보강이지 Android 기능 추가나 실기기 검증이 아니다.

추가 구현: 15개 도메인의 Runtime 등록 계약 연결

BaseDomainManagerService에 FrameworkManagedService 계약을 연결했다. 이제 15개 도메인을 FrameworkServiceRegistry에 등록할 수 있고, 다른 생명주기 감독자를 사용하는 잘못된 구성은 등록 전에 거부한다. 테스트는 모든 도메인의 CREATED → READY → STOPPED와 실패 후 재등록을 확인한다. 의존 서비스는 테스트용 대역이며, 실제 기본 구성은 여전히 Runtime + State다. 전체 제품 구동 완료가 아니다.

전체 모듈 역할 지도와 AMR 소유권 정리

Atlas 첫 화면에 공통 모듈 9개와 제품 도메인 15개를 한 장으로 배치했다. 각 상자에는 역할·입력·결과·현재 구현 상태가 들어간다. AMR 상태·정책은 domain/mobility에서 domain/amr로 모았고, 정책 ID와 상태 값은 유지했다. 분리된 옛 canonical 폴더의 Java 소스 재생성을 검사로 차단한다. 실제 기기 구동 완료는 아니다.

추가 구현: 도메인 상태는 해당 도메인 폴더가 소유

IoT 연결 상태 IotConnectionState를 server/integration/agent에서 server/domain/iot로 옮겼다. 연결 상태 값과 관측 동작은 유지하며, 도메인이 하위 integration/legacy 구현을 import하면 경계 검사가 실패하도록 보강했다. 공통 연결 영역이 도메인 상태 계약을 소유하던 역방향 의존성 두 곳을 제거했다. 이는 폴더·책임 분리 작업이며 실제 IoT Agent 결선 완료를 의미하지 않는다.

상세 구조도 3장을 추가했다. 전체 계층과 왕복 경로, 15개 독립 도메인의 책임·목표 provider, canonical 소스와 AOSP 구동 위치를 각각 펼친다. 기본 구성은 Runtime + State뿐이며 Android 시작 Service와 전체 도메인 결선은 미완료라는 사실도 표시했다. 폴더 검사에는 Power 소유권, runtime/compatibility 빌드 입력, canonical Java 상대 경로 중복 방지를 보강했다.

처음 읽는 사람: SKIX 리팩터링 한눈에 보기에서 세 계층과 현재 단계부터 확인한 뒤 이 페이지의 세부 진행표를 읽는다.

현재 단계 요약

같은 날 SDK legacy IPC 구현도 호환 계층으로 이관했다. LegacyDeviceAgentAdapter, LegacyIotAgentAdapter, DeviceControlService의 소유 폴더는 base/compatibility/java이며 패키지와 동작은 유지한다. SDK base/core/java의 DeviceControl/IoT AIDL 직접 import는 0개이고, 재유입을 거부하는 경계 검사를 추가했다. Soong도 Bundle 상수와 legacy transport 입력을 분리한다. SDK 37개, Runtime 134개 테스트 강제 재실행 및 release Java 컴파일 통과. 호환 facade 의존과 기능 이식 과제는 legacy 목록에 계속 남는다.

2026-09-08에는 Android 전송 어댑터 3개를 실제 폴더 기준으로 분리했다. AndroidBinderCallerSources, AndroidCallerTrustSources, SkixFrameworkBinderService는 skix-framework/base/services/runtime/java가 소유한다. services/core/java에는 전송 독립적인 admission, caller 계약, endpoint registry와 ManagerService가 남는다. 패키지/API/동작은 유지하며 Gradle과 Soong의 입력도 별도로 연결했다.

코어의 Android import와 Android host 역참조를 차단하는 경계 검증을 추가했다. Runtime 단위 테스트 134개 강제 재실행 통과, release Java 컴파일 및 실제 계층 검사 통과. SystemServer 공개·제품 image·실기기 검증은 후속 단계다.

이 페이지의 역할

이 페이지는 SKIX 리팩터링 프레임워크 설계안을 목표 기준선으로 삼아 실제 코드 리팩터링의 진행 상태, 검증 결과와 다음 작업을 누적한다. 현재 구현과 목표 구조의 차이는 MR7 정합성 감사 및 교정안에서 설명하고, 여기서는 현재 작업 브랜치에서 실제로 반영됐는지만 관리한다.

설계 완료, 소스 반영, JVM 검증, 실기기 검증을 서로 다른 상태로 기록한다. 빌드가 성공해도 센서·모터·Binder 호출자·물리 완료가 확인되지 않으면 실기기 미검증이다.

작업 기준선

SKIX는 얇은 SkixFrameworkSystemService + 격리된 system_ext Runtime의 하이브리드로 간다. system_server는 부팅 phase, root Binder, 외곽 권한 검사와 Runtime 죽음 감시만 담당한다. 무거운 Task·Workflow·Policy·State·Evidence·Domain ManagerService는 독립 Runtime process에 격리하고, 기존 Agent는 physical provider, DeviceAgent는 legacy compatibility gateway로 축소한다.

영역별 진행 문서

이 페이지는 전체 상태를 요약하는 허브다. 상세 구조와 검증 근거는 책임별 페이지에서 관리한다.

전체 레이어뿐 아니라 boot, 요청 처리, Task/Policy/State, provider/Evidence 환류와 migration을 먼저 보려면 SKIX 로보틱스 프레임워크 전체 구조 Atlas를 연다.

전체가 어렵게 느껴지면 먼저 SKIX 전체 구조 — 처음 보는 안내서를 연다. 요청→Android 보호→Runtime 판단→도메인 서비스→실제 실행→State/Evidence 환류를 청소 예시로 설명하고, 24개 Manager/ManagerService와 기술 상세도는 그 아래에서 단계적으로 연결한다.

구조 다이어그램

아래 그림은 현재 코드가 모두 목표 구조로 이관됐다는 완료 선언이 아니다. 목표 파일 배치, 현재 생성한 Stage 0 경계, Task Core 구현과 후속 이식 순서를 각각 분리해 표현한다. 구현 상태와 검증 Gate는 그림 아래 진행표를 기준으로 판정한다.

Root Binder admission 구현과 후속 경계

구현·검증 상세 · 원본 SVG 열기

Runtime composition 구현 상세

구현·검증 상세 · 원본 SVG 열기

StateManager 읽기 전용 투영

구현·MR6 이식 경계 상세 · 원본 SVG 열기

하이브리드 source / process / partition

상세 설계 · 원본 SVG 열기

Android boot phase와 readiness

원본 SVG 열기

Runtime death와 안전 복구

원본 SVG 열기

전체 Manager / ManagerService / Agent 맵

아래 전체 맵은 Control 5개, Execution 4개, Product Domain 15개와 독립 Agent 8개를 축약 없이 표현한다.

전체 맵 설명 · 원본 SVG 열기

영역별 상세 SVG

• Control Services 상세
• Task / Execution 상세
• Product Domain Services 상세
• Agent / Legacy 상세
• 도메인 정책 사양과 충돌 조정
• 서비스 라이프사이클과 도메인 상태 감사
• 도메인별 Bundle 계약 상수화

도메인별 Bundle wire 계약

상세 현황 · 원본 SVG 열기

AOSP 기준 Manager / ManagerService 배치

원본 SVG 열기

큰 Domain Manager / ManagerService / Agent 분리

원본 SVG 열기

Stage 0 SDK / DeviceAgent 패키지 경계

원본 SVG 열기

MR6 TaskManager 단계적 이식 경로

원본 SVG 열기

Stage 0 · Layer foundation

Manager / ManagerService 파일 배치 원칙

skix-framework/base/
├── core/
│  ├── java/com/sk/airbot/framework/
│  │  ├── core/                   # SDK 진입과 연결 수명
│  │  ├── state/                  # Skix*Manager와 client-visible 상태 계약
│  │  ├── capability/             # capability Manager API와 descriptor
│  │  ├── policy/                 # policy Manager API와 decision
│  │  ├── resource/               # resource Manager API와 계약
│  │  ├── task/                   # Task Manager API와 공개 계약
│  │  ├── event/                  # 실행 event 공개 계약
│  │  ├── health/                 # framework health API
│  │  ├── ui/                     # UI session API
│  │  ├── domain/                 # typed 제품 domain Manager
│  │  └── internal/               # Binder, legacy wire, compatibility adapter
│  └── tests/src/                      # public test package mirror
├── services/core/java/com/sk/airbot/frameworkservice/server/
│  ├── entrypoint/                     # canonical Binder ingress
│  ├── control/                        # State/Policy/Resource/Capability ManagerService
│  ├── execution/                      # Task/Workflow/Scheduler/Evidence ManagerService
│  ├── domain/                         # AMR/IoT/LLM/Vision 등 Domain ManagerService
│  ├── integration/                    # 기존 Agent와 연결하는 typed provider port
│  └── legacy/                         # DeviceAgent compatibility adapter
├── services/tests/src/                   # ManagerService test package mirror
├── services/systemserver/                # thin AOSP SystemService boundary
├── services/runtime/                     # isolated Android Service boundary
├── adapters/                             # Agent·ROS 2·MCU·HAL ports
├── compatibility/                        # legacy forwarding
├── data/etc/                             # permission·overlay·service contexts
└── api/                                  # reviewed API signature

DeviceAgent/
└── legacy IDeviceControl gateway # slice 이관에 따라 지속 축소

AMRAgent / IotAgent / LLMAgent / VisionAgent / MCUAgent /
UpdateAgent / PairingAgent / EventAssetAgent
└── 독립 process·권한·장애 수명을 가진 physical provider

SDK-facing authority는 Skix*Manager.java, runtime 권위 구현은 *ManagerService.java로 명명한다. RequestContext, StateRecord, TaskState처럼 자체 의미를 가진 계약·모델은 억지로 Service 이름을 붙이지 않는다. 테스트는 생산 패키지와 클래스 이름을 그대로 미러링한다.

큰 도메인은 각각 Manager ↔ ManagerService ↔ Agent provider 경계를 가진다. AMR, IoT, LLM, MCU, Vision, Update, Pairing과 EventAsset은 기존 독립 Agent와 IPC/권한/장애 수명이 있으므로 합치지 않는다. 반대로 AMR+Map, LCD+Toast, non-power Manage+Setting+Wifi처럼 같은 상태와 lifecycle을 공유하는 작은 API는 각각 AMR, UI, System Domain ManagerService로 묶는다. Battery·charging·power sleep은 독립 상태와 정책 수명을 가지므로 PowerManagerService로 분리한다. SDK Manager 개수와 Android process 개수를 1:1로 만들지 않는다.

이 표의 ManagerService는 각각 별도 APK를 만든다는 뜻이 아니다. 모두 신규 SkixFrameworkService.apk 안의 책임 단위로 시작하고, 독립 장애·권한·하드웨어·부팅·배포 수명이 실제로 필요한 도메인만 별도 process인 기존 Agent provider 경계를 유지한다.

현재 진행표

Stage 0 source-integration Gate

2026-09-05 typed observation / Power 증분 Gate

DeviceAgent release 빌드는 성공했지만 기존 R8 duplicate-library 및 missing-annotation 경고가 남아 있다. 이 Gate는 로컬 소스 구조와 빌드 통합만 증명한다. AOSP prebuilt 교체 전 인증서 일치, OTA, Binder 실제 호출자, 센서·모터의 물리 완료와 중복 실행 여부는 실기기 미검증이다.

TaskManager 통합 원칙

MR6 task_manager 브랜치는 폐기하거나 처음부터 다시 만드는 대상이 아니다. 다음 순서로 통합한다.

1. 완료 — MR6 계약을 감사해 공개 Task 상태·요청·handle·snapshot을 SDK에 이식했다.
2. 완료 — lifecycle과 queue 권위를 신규 SkixFrameworkService의 TaskManagerService로 배치했다.
3. 완료 — deterministic priority/FIFO queue, queued cancel, terminal reason, bounded terminal history를 JVM 테스트로 고정했다.
4. 다음 — WorkflowManagerService, EvidenceManagerService, TaskSchedulerManagerService를 순차 이식한다.
5. 다음 — SDK SkixTaskManager와 Binder facade, legacy forwarding adapter를 연결한다.
6. 다음 — 기존 command owner를 domain executor로 연결하고 AMR vertical slice와 실기기 evidence를 검증한다.

단순 브랜치 merge나 디렉터리 복사는 완료로 판정하지 않는다. 현재 코드의 패키지, Binder 계약과 실행 owner에 맞춰 이식한 뒤 회귀 시험을 통과해야 통합 완료로 표시한다.

변경 기록

관련 문서

• SKIX Runtime Composition 구현 현황
• SKIX StateManager 읽기 전용 투영 구현
• SKIX 하이브리드 SystemService와 Runtime 구조
• SKIX 리팩터링 프레임워크 설계안
• SKIX Blueprint 기준 MR7 리팩터링 정합성 감사 및 교정안
• 도메인 정책 사양 카탈로그
• 서비스 라이프사이클과 도메인 상태 감사
• 도메인별 Bundle 계약 상수화
• 프레임워크와 SDK 문서 모음