feat: add notification preflight milestones for all platforms and update runtime validation docs
- Add iOS notification preflight milestone - Add macOS notification preflight milestone - Add Linux notification preflight milestone - Add Windows notification preflight milestone - Update notification test milestones for all platforms - Update phase documentation and current roadmap - Update runtime image validation docs - Update compose README
This commit is contained in:
parent
a3d395e7c3
commit
9f5e8c2343
12 changed files with 324 additions and 39 deletions
|
|
@ -7,18 +7,9 @@
|
|||
|
||||
## 활성 Milestone
|
||||
|
||||
- [계획] iOS 알림 테스트
|
||||
- [계획] iOS 알림 선행 정리
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/ios-notification-test.md`
|
||||
- [계획] macOS 알림 테스트
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/macos-notification-test.md`
|
||||
- [계획] Windows 알림 테스트
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/windows-notification-test.md`
|
||||
- [계획] Linux 알림 테스트
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/linux-notification-test.md`
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/ios-notification-preflight.md`
|
||||
|
||||
## 선택 규칙
|
||||
|
||||
|
|
|
|||
|
|
@ -22,18 +22,30 @@ Mattermost server/webapp/push-proxy는 upstream-followable runtime으로 두고,
|
|||
- [완료] 알림 파이프라인 고도화
|
||||
- 경로: `agent-roadmap/archive/phase/messaging-runtime/milestones/notification-pipeline.md`
|
||||
- 요약: FCM, ACK, inline reply, dismiss, open routing을 안정된 플러그인 책임으로 만든다.
|
||||
- [계획] iOS 알림 선행 정리
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/ios-notification-preflight.md`
|
||||
- 요약: Apple/Firebase/APNs 실자산 없이 iOS token 계약, native bridge 최소 범위, fixture, evidence 기준을 먼저 정리한다.
|
||||
- [계획] macOS 알림 선행 정리
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/macos-notification-preflight.md`
|
||||
- 요약: Apple signing/장비 없이 macOS native bridge 최소 범위, host placeholder, fixture, evidence 기준을 먼저 정리한다.
|
||||
- [계획] Windows 알림 선행 정리
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/windows-notification-preflight.md`
|
||||
- 요약: Windows 장비/packaging 결정 없이 plugin 등록, native API 후보, bridge 계약, fixture, evidence 기준을 먼저 정리한다.
|
||||
- [계획] Linux 알림 선행 정리
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/linux-notification-preflight.md`
|
||||
- 요약: Linux 배포판/desktop environment 결정 없이 plugin 등록, notification daemon 후보, bridge 계약, fixture, evidence 기준을 먼저 정리한다.
|
||||
- [계획] iOS 알림 테스트
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/ios-notification-test.md`
|
||||
- 요약: iOS/APNs 권한, token, open routing, ACK/dismiss 계약을 scaffold/stub gap과 smoke 기준으로 분리한다.
|
||||
- 요약: 선행 정리 후 iOS/APNs 권한, token, open routing, ACK/dismiss 계약을 실제 설정과 smoke 기준으로 검증한다.
|
||||
- [계획] macOS 알림 테스트
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/macos-notification-test.md`
|
||||
- 요약: macOS scaffold/stub 상태의 알림 기준과 구현 gap, smoke 경계를 확인한다.
|
||||
- 요약: 선행 정리 후 macOS scaffold/stub 상태의 알림 기준과 구현 gap, smoke 경계를 실제 OS 조건으로 확인한다.
|
||||
- [계획] Windows 알림 테스트
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/windows-notification-test.md`
|
||||
- 요약: Windows를 공통 플러그인의 지원 대상으로 두고 native API, packaging/test 조건을 정리한다.
|
||||
- 요약: 선행 정리 후 Windows를 공통 플러그인의 지원 대상으로 두고 native API, packaging/test 조건을 검증한다.
|
||||
- [계획] Linux 알림 테스트
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/linux-notification-test.md`
|
||||
- 요약: Linux를 공통 플러그인의 지원 대상으로 두고 배포판, desktop environment, notification daemon, packaging/test 조건을 정리한다.
|
||||
- 요약: 선행 정리 후 Linux를 공통 플러그인의 지원 대상으로 두고 배포판, desktop environment, notification daemon, packaging/test 조건을 검증한다.
|
||||
- [스케치] 멀티앱 채널 모델
|
||||
- 경로: `agent-roadmap/phase/messaging-runtime/milestones/multi-app-channel.md`
|
||||
- 요약: 추가 앱이 생길 때 사용 채널만 늘려 분기할 수 있는 서비스 모델을 검토한다.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,71 @@
|
|||
# Milestone: iOS 알림 선행 정리
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
Apple Developer 계정, APNs 인증 자산, Firebase iOS app, 실제 기기가 준비되기 전에도 iOS 알림 구현과 테스트를 막는 선행 계약을 정리한다.
|
||||
iOS token 계약, native bridge 최소 범위, placeholder, fixture, evidence 템플릿을 먼저 고정해 후속 `iOS 알림 테스트`가 외부 자산 검증에만 집중하게 만든다.
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- 없음
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 해제
|
||||
- 결정 필요:
|
||||
- 없음
|
||||
|
||||
## 범위
|
||||
|
||||
- iOS device token prefix와 APNs/FCM token 구분 기준
|
||||
- Dart가 기대하는 iOS EventChannel/MethodChannel 최소 bridge 계약
|
||||
- `apps/flutter-test/ios` host placeholder와 ignored credential 위치
|
||||
- APNs/FCM payload fixture와 local/simulator opened-routing injection 기준
|
||||
- 실제 APNs delivery 전후로 재사용할 smoke evidence 템플릿
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [preflight] iOS 선행 정리
|
||||
|
||||
Apple/Firebase/APNs 실자산이 없어도 먼저 확정할 수 있는 계약과 검증 표면을 분리한다.
|
||||
|
||||
- [ ] [token-contract] iOS device token prefix, FCM/APNs token 구분, nexo server 등록 호환 기준을 정리한다.
|
||||
- [ ] [bridge-scope] Dart가 기대하는 EventChannel/MethodChannel 이름, iOS 최소 구현 method, no-op/fallback 경계를 정리한다.
|
||||
- [ ] [host-placeholder] entitlements, `GoogleService-Info.example.plist`, ignored credential 위치, Xcode target resource 기준을 정리한다.
|
||||
- [ ] [fixtures] APNs/FCM payload fixture와 simulator/local injection으로 검증할 opened-routing 시나리오를 작성한다.
|
||||
- [ ] [evidence-template] permission, APNs/FCM token, foreground/background/open routing, ACK/dismiss gap evidence 템플릿을 작성한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 실제 Apple Developer Team, APNs key/certificate, provisioning profile, Firebase project/app 생성은 이 Milestone에서 결정하지 않는다.
|
||||
- 실제 iOS 기기 APNs/FCM delivery smoke는 `iOS 알림 테스트`에서 다룬다.
|
||||
- iOS native bridge 전체 구현은 선행 계약 정리 이후 별도 구현 계획으로 분리할 수 있다.
|
||||
- Android FCM 구현 변경은 이 Milestone에서 다루지 않는다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `packages/messaging_flutter/ios/`, `packages/messaging_flutter/lib/`, `apps/flutter-test/ios/`, `docs/ios-notification-test-guide.md`
|
||||
- 표준선(선택): 민감값 없이 placeholder, fixture, event 계약, evidence 양식을 먼저 고정한다
|
||||
- 민감값 기준: Apple/Firebase/APNs credential, Team ID, profile, token, private host 값은 tracked 문서에 쓰지 않는다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 후속 작업: iOS 알림 테스트
|
||||
- 확인 필요: 없음
|
||||
|
|
@ -42,7 +42,7 @@ Android 중심으로 정리된 nexo 알림 계약을 iOS/APNs 환경에서 어
|
|||
|
||||
iOS 알림이 Android와 같은 계약으로 검증되기 전에 필요한 platform baseline을 확인한다.
|
||||
|
||||
- [ ] [platform-state] `packages/messaging_flutter/ios`와 `apps/flutter-test/ios`의 scaffold, 등록 지점, no-op gap을 정리한다.
|
||||
- [ ] [platform-state] 선행 정리 결과를 바탕으로 `packages/messaging_flutter/ios`와 `apps/flutter-test/ios`의 scaffold, 등록 지점, 남은 no-op gap을 확인한다.
|
||||
- [ ] [permission-token] APNs entitlement, Firebase config, notification permission, APNs/FCM token 획득과 host handoff 조건을 정리한다.
|
||||
- [ ] [device-limits] simulator, physical device, CI/headless 환경에서 가능한 검증과 불가능한 검증을 구분한다.
|
||||
|
||||
|
|
@ -50,8 +50,8 @@ iOS 알림이 Android와 같은 계약으로 검증되기 전에 필요한 platf
|
|||
|
||||
iOS native event가 Dart API와 host routing callback으로 연결되기 위한 계약을 구체화한다.
|
||||
|
||||
- [ ] [native-bridge] permission, token refresh, notification opened event를 Flutter method/event channel로 넘기는 iOS bridge gap을 정리한다.
|
||||
- [ ] [payload-map] APNs payload에서 `server_url`, `server_id`, `channel_id`, `root_id`, `ack_id`를 `NotificationOpenedEvent`와 routing callback에 매핑하는 기준을 정리한다.
|
||||
- [ ] [native-bridge] 선행 정리한 bridge 계약 대비 permission, token refresh, notification opened event를 Flutter method/event channel로 넘기는 iOS 구현 gap을 확인한다.
|
||||
- [ ] [payload-map] 선행 fixture 계약을 실제 APNs/FCM payload의 `server_url`, `server_id`, `channel_id`, `root_id`, `ack_id` 매핑에 대조한다.
|
||||
- [ ] [ack-dismiss] iOS에서 ACK, dismiss, inline reply를 처리할 수 있는 native hook과 후속 구현이 필요한 gap을 분리한다.
|
||||
|
||||
### Epic: [smoke] iOS Smoke
|
||||
|
|
@ -84,6 +84,6 @@ iOS native event가 Dart API와 host routing callback으로 연결되기 위한
|
|||
- 관련 경로: `packages/messaging_flutter/ios/`, `packages/messaging_flutter/lib/`, `packages/messaging_flutter/README.md`, `apps/flutter-test/ios/`, `apps/flutter-test/README.md`
|
||||
- 표준선(선택): iOS scaffold/stub 상태를 먼저 명확히 하고, 가능한 smoke 기준과 후속 구현 gap을 분리한다
|
||||
- 민감값 기준: Apple/Firebase/APNs credential, team id, profile, token, private host 값은 tracked 문서에 쓰지 않고 책임 경계와 evidence 위치만 기록한다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 선행 작업: 알림 파이프라인 고도화, iOS 알림 선행 정리
|
||||
- 후속 작업: 멀티앱 채널 모델
|
||||
- 확인 필요: 프로비저닝, APNs 인증, Firebase iOS 설정, 실제 기기/CI smoke 환경 결정
|
||||
|
|
|
|||
|
|
@ -0,0 +1,70 @@
|
|||
# Milestone: Linux 알림 선행 정리
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
Linux 배포판, desktop environment, notification daemon, 테스트 장비 결정을 기다리지 않고 Linux 알림 지원에 필요한 선행 계약을 정리한다.
|
||||
Linux plugin 등록, notification daemon 연동 후보, bridge 계약, fixture, evidence 템플릿을 먼저 고정해 후속 `Linux 알림 테스트`가 실제 환경 smoke에 집중하게 만든다.
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- 없음
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 해제
|
||||
- 결정 필요:
|
||||
- 없음
|
||||
|
||||
## 범위
|
||||
|
||||
- Linux Flutter plugin 등록 방식과 host scaffold 필요 범위
|
||||
- Dart가 기대하는 Linux EventChannel/MethodChannel 최소 bridge 계약
|
||||
- D-Bus notification daemon, desktop portal, package/runtime dependency 후보 비교
|
||||
- local/debug notification payload fixture와 opened-routing injection 기준
|
||||
- 실제 Linux OS UI smoke 전후로 재사용할 evidence 템플릿
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [preflight] Linux 선행 정리
|
||||
|
||||
Linux 장비, 배포판, desktop environment 결정을 기다리지 않고 먼저 확정할 수 있는 계약과 검증 표면을 분리한다.
|
||||
|
||||
- [ ] [platform-contract] Linux plugin 등록 방식, Dart channel 이름, host scaffold 필요 범위를 정리한다.
|
||||
- [ ] [bridge-scope] Linux notification daemon click/open event를 `NotificationOpenedEvent`와 channel/thread callback에 연결하는 최소 bridge 계약을 정리한다.
|
||||
- [ ] [api-matrix] D-Bus notification daemon, desktop portal, package/runtime dependency 후보와 제약을 비교한다.
|
||||
- [ ] [fixtures] local/debug notification payload fixture와 opened-routing injection 시나리오를 작성한다.
|
||||
- [ ] [evidence-template] display, click/open routing, lifecycle, ACK/dismiss gap evidence 템플릿을 작성한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- Linux 배포판, desktop environment, notification daemon, 테스트 장비 책임 결정은 이 Milestone에서 하지 않는다.
|
||||
- 실제 Linux notification UI smoke와 package/runtime 검증은 `Linux 알림 테스트`에서 다룬다.
|
||||
- Linux native implementation 전체 완성은 선행 계약 정리 이후 별도 구현 계획으로 분리할 수 있다.
|
||||
- macOS/Windows 검증은 각 OS별 Milestone에서 다룬다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `packages/messaging_flutter/pubspec.yaml`, `packages/messaging_flutter/lib/`, `packages/messaging_flutter/README.md`, `apps/flutter-test/README.md`
|
||||
- 표준선(선택): 실제 Linux 장비 없이 platform 등록 후보, notification daemon 후보, event 계약, fixture, evidence 양식을 먼저 고정한다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 후속 작업: Linux 알림 테스트
|
||||
- 확인 필요: 없음
|
||||
|
|
@ -39,8 +39,8 @@ Linux 환경에서 nexo 알림 계약을 공통 플러그인의 지원 대상으
|
|||
|
||||
Linux 알림 지원에 필요한 platform baseline을 확인한다.
|
||||
|
||||
- [ ] [platform-state] Linux plugin platform 등록 여부와 host scaffold 필요 범위를 정리한다.
|
||||
- [ ] [native-api] Linux notification daemon/native 연동 후보와 package/runtime 제약을 정리한다.
|
||||
- [ ] [platform-state] 선행 정리 결과를 바탕으로 Linux plugin platform 등록 여부와 host scaffold 필요 범위를 확인한다.
|
||||
- [ ] [native-api] 선택한 Linux notification daemon/native 연동 방식과 package/runtime 제약을 smoke 기준으로 확인한다.
|
||||
- [ ] [test-env] 배포판, desktop environment, 테스트 장비, 수동/자동 smoke 가능 범위를 정리한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
|
@ -63,6 +63,6 @@ Linux 알림 지원에 필요한 platform baseline을 확인한다.
|
|||
|
||||
- 관련 경로: `packages/messaging_flutter/pubspec.yaml`, `packages/messaging_flutter/README.md`, `apps/flutter-test/README.md`
|
||||
- 표준선(선택): Linux는 공통 플러그인의 지원 대상이며, 먼저 배포판/desktop environment, notification daemon, packaging/test 조건을 정리한 뒤 구현 단위를 확정한다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 선행 작업: 알림 파이프라인 고도화, Linux 알림 선행 정리
|
||||
- 후속 작업: Linux native notification 구현 후보
|
||||
- 확인 필요: Linux 배포판/desktop environment, native 연동 방식, package/runtime dependency, 진행 우선순위
|
||||
|
|
|
|||
|
|
@ -0,0 +1,71 @@
|
|||
# Milestone: macOS 알림 선행 정리
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
Apple signing, macOS 테스트 장비, 실제 OS notification UI 검증 전에 macOS 알림 구현과 테스트를 막는 선행 계약을 정리한다.
|
||||
macOS native bridge 최소 범위, host placeholder, payload fixture, evidence 템플릿을 먼저 고정해 후속 `macOS 알림 테스트`가 장비와 OS UI smoke에 집중하게 만든다.
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- 없음
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 해제
|
||||
- 결정 필요:
|
||||
- 없음
|
||||
|
||||
## 범위
|
||||
|
||||
- Dart가 기대하는 macOS EventChannel/MethodChannel 최소 bridge 계약
|
||||
- `apps/flutter-test/macos` host placeholder와 entitlement/signing 기준
|
||||
- macOS notification userInfo와 `NotificationOpenedEvent` 매핑 기준
|
||||
- local notification payload fixture와 click/open routing injection 기준
|
||||
- 실제 macOS OS UI smoke 전후로 재사용할 evidence 템플릿
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [preflight] macOS 선행 정리
|
||||
|
||||
Apple signing, 장비, OS UI 수동 검증 전에 먼저 확정할 수 있는 계약과 검증 표면을 분리한다.
|
||||
|
||||
- [ ] [bridge-scope] Dart가 기대하는 EventChannel/MethodChannel 이름, macOS 최소 구현 method, no-op/fallback 경계를 정리한다.
|
||||
- [ ] [host-placeholder] entitlement, signing/notarization placeholder, ignored credential 위치, macOS target resource 기준을 정리한다.
|
||||
- [ ] [payload-map] macOS notification userInfo를 `NotificationOpenedEvent`와 channel/thread callback에 매핑하는 기준을 정리한다.
|
||||
- [ ] [fixtures] local notification payload fixture와 click/open routing injection 시나리오를 작성한다.
|
||||
- [ ] [evidence-template] permission, display, click/open routing, lifecycle, ACK/dismiss gap evidence 템플릿을 작성한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 실제 Apple Team, signing certificate, provisioning, notarization 책임 결정은 이 Milestone에서 하지 않는다.
|
||||
- 실제 macOS OS notification UI smoke는 `macOS 알림 테스트`에서 다룬다.
|
||||
- macOS native bridge 전체 구현은 선행 계약 정리 이후 별도 구현 계획으로 분리할 수 있다.
|
||||
- iOS/APNs, Windows, Linux 검증은 각 OS별 Milestone에서 다룬다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `packages/messaging_flutter/macos/`, `packages/messaging_flutter/lib/`, `apps/flutter-test/macos/`, `packages/messaging_flutter/README.md`
|
||||
- 표준선(선택): 민감값과 실제 장비 없이 placeholder, fixture, event 계약, evidence 양식을 먼저 고정한다
|
||||
- 민감값 기준: Apple credential, Team ID, profile, private host 값은 tracked 문서에 쓰지 않는다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 후속 작업: macOS 알림 테스트
|
||||
- 확인 필요: 없음
|
||||
|
|
@ -40,7 +40,7 @@ macOS 환경에서 nexo 알림 계약을 어느 수준까지 검증할 수 있
|
|||
|
||||
macOS 알림이 Android/iOS와 같은 계약으로 검증되기 전에 필요한 platform baseline을 확인한다.
|
||||
|
||||
- [ ] [platform-state] `packages/messaging_flutter/macos`와 `apps/flutter-test/macos`의 scaffold, 등록 지점, no-op gap을 정리한다.
|
||||
- [ ] [platform-state] 선행 정리 결과를 바탕으로 `packages/messaging_flutter/macos`와 `apps/flutter-test/macos`의 scaffold, 등록 지점, 남은 no-op gap을 확인한다.
|
||||
- [ ] [macos-host] app delegate, entitlement, permission/display 준비 조건을 확인한다.
|
||||
- [ ] [device-limits] macOS 버전, signing/notarization, headless 환경에서 가능한 검증과 불가능한 검증을 구분한다.
|
||||
|
||||
|
|
@ -48,8 +48,8 @@ macOS 알림이 Android/iOS와 같은 계약으로 검증되기 전에 필요한
|
|||
|
||||
macOS notification event가 Dart API와 host routing callback으로 연결되기 위한 계약을 구체화한다.
|
||||
|
||||
- [ ] [display-open] macOS notification display와 click/open routing을 `NotificationOpenedEvent`와 channel/thread callback에 연결하기 위한 event shape를 정리한다.
|
||||
- [ ] [lifecycle] foreground, background, minimized, terminated 상태에서 macOS notification 처리 기준과 제한을 정리한다.
|
||||
- [ ] [display-open] 선행 정리한 payload/event 계약 대비 macOS notification display와 click/open routing 연결 gap을 확인한다.
|
||||
- [ ] [lifecycle] foreground, background, minimized, terminated 상태에서 macOS notification 처리 기준과 제한을 실제 OS 조건에 대조한다.
|
||||
- [ ] [ack-dismiss] macOS에서 ACK, dismiss, inline reply를 처리할 수 있는 platform hook과 후속 구현 gap을 분리한다.
|
||||
|
||||
### Epic: [smoke] macOS Smoke
|
||||
|
|
@ -82,6 +82,6 @@ macOS notification event가 Dart API와 host routing callback으로 연결되기
|
|||
- 관련 경로: `packages/messaging_flutter/macos/`, `packages/messaging_flutter/pubspec.yaml`, `packages/messaging_flutter/README.md`, `apps/flutter-test/macos/`, `apps/flutter-test/README.md`
|
||||
- 표준선(선택): macOS scaffold/stub 상태를 먼저 검증하고, 가능한 smoke 기준과 후속 구현 gap을 분리한다
|
||||
- 민감값 기준: Apple credential, team id, profile, private host 값은 tracked 문서에 쓰지 않고 책임 경계와 evidence 위치만 기록한다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 선행 작업: 알림 파이프라인 고도화, macOS 알림 선행 정리
|
||||
- 후속 작업: Windows 알림 테스트, Linux 알림 테스트, 멀티앱 채널 모델
|
||||
- 확인 필요: macOS 버전/장비, signing/notarization 필요 여부, 수동/자동 smoke 경계 결정
|
||||
|
|
|
|||
|
|
@ -0,0 +1,70 @@
|
|||
# Milestone: Windows 알림 선행 정리
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-roadmap/ROADMAP.md`
|
||||
- Phase: `agent-roadmap/phase/messaging-runtime/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
Windows 테스트 장비, 계정/권한, packaging 결정을 기다리지 않고 Windows 알림 지원에 필요한 선행 계약을 정리한다.
|
||||
Windows plugin 등록, native notification API 후보, bridge 계약, fixture, evidence 템플릿을 먼저 고정해 후속 `Windows 알림 테스트`가 OS smoke와 packaging 검증에 집중하게 만든다.
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- 없음
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 해제
|
||||
- 결정 필요:
|
||||
- 없음
|
||||
|
||||
## 범위
|
||||
|
||||
- Windows Flutter plugin 등록 방식과 host scaffold 필요 범위
|
||||
- Dart가 기대하는 Windows EventChannel/MethodChannel 최소 bridge 계약
|
||||
- Windows notification API 후보와 MSIX/package 제약 비교
|
||||
- local/debug notification payload fixture와 opened-routing injection 기준
|
||||
- 실제 Windows OS UI smoke 전후로 재사용할 evidence 템플릿
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [preflight] Windows 선행 정리
|
||||
|
||||
Windows 장비, 계정, packaging 결정을 기다리지 않고 먼저 확정할 수 있는 계약과 검증 표면을 분리한다.
|
||||
|
||||
- [ ] [platform-contract] Windows plugin 등록 방식, Dart channel 이름, host scaffold 필요 범위를 정리한다.
|
||||
- [ ] [bridge-scope] Windows native notification open event를 `NotificationOpenedEvent`와 channel/thread callback에 연결하는 최소 bridge 계약을 정리한다.
|
||||
- [ ] [api-matrix] Windows notification API 후보와 app packaging/MSIX 여부에 따른 제약을 비교한다.
|
||||
- [ ] [fixtures] local/debug notification payload fixture와 opened-routing injection 시나리오를 작성한다.
|
||||
- [ ] [evidence-template] display, click/open routing, lifecycle, ACK/dismiss gap evidence 템플릿을 작성한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- Windows OS 버전, 테스트 장비, 계정/권한 책임 결정은 이 Milestone에서 하지 않는다.
|
||||
- 실제 Windows notification UI smoke와 packaging 검증은 `Windows 알림 테스트`에서 다룬다.
|
||||
- Windows native implementation 전체 완성은 선행 계약 정리 이후 별도 구현 계획으로 분리할 수 있다.
|
||||
- macOS/Linux 검증은 각 OS별 Milestone에서 다룬다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `packages/messaging_flutter/pubspec.yaml`, `packages/messaging_flutter/lib/`, `packages/messaging_flutter/README.md`, `apps/flutter-test/README.md`
|
||||
- 표준선(선택): 실제 Windows 장비 없이 platform 등록 후보, native API 후보, event 계약, fixture, evidence 양식을 먼저 고정한다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 후속 작업: Windows 알림 테스트
|
||||
- 확인 필요: 없음
|
||||
|
|
@ -39,8 +39,8 @@ Windows 환경에서 nexo 알림 계약을 공통 플러그인의 지원 대상
|
|||
|
||||
Windows 알림 지원에 필요한 platform baseline을 확인한다.
|
||||
|
||||
- [ ] [platform-state] Windows plugin platform 등록 여부와 host scaffold 필요 범위를 정리한다.
|
||||
- [ ] [native-api] Windows native notification API 후보와 packaging 제약을 정리한다.
|
||||
- [ ] [platform-state] 선행 정리 결과를 바탕으로 Windows plugin platform 등록 여부와 host scaffold 필요 범위를 확인한다.
|
||||
- [ ] [native-api] 선택한 Windows native notification API와 packaging 제약을 smoke 기준으로 확인한다.
|
||||
- [ ] [test-env] Windows 버전, 테스트 장비, 수동/자동 smoke 가능 범위를 정리한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
|
@ -63,6 +63,6 @@ Windows 알림 지원에 필요한 platform baseline을 확인한다.
|
|||
|
||||
- 관련 경로: `packages/messaging_flutter/pubspec.yaml`, `packages/messaging_flutter/README.md`, `apps/flutter-test/README.md`
|
||||
- 표준선(선택): Windows는 공통 플러그인의 지원 대상이며, 먼저 platform 등록, native API, packaging/test 조건을 정리한 뒤 구현 단위를 확정한다
|
||||
- 선행 작업: 알림 파이프라인 고도화
|
||||
- 선행 작업: 알림 파이프라인 고도화, Windows 알림 선행 정리
|
||||
- 후속 작업: Windows native notification 구현 후보
|
||||
- 확인 필요: Windows OS 버전/장비, native API, packaging/test 기준, 진행 우선순위
|
||||
|
|
|
|||
|
|
@ -55,18 +55,18 @@ $ sha256sum docker-compose.yml .env.example
|
|||
c46bc291e42b1e87ca5e6b49d118bb59c67b0b2b1412a2751c6089e49d492563 docker-compose.yml
|
||||
fa56a8dc7a8dddc7737d42ec048e4f29836252e277e2d270f0ad0e7cbb38d430 .env.example
|
||||
|
||||
$ ssh toki@toki-labs.com 'cd ~/docker/services/nexo/compose && sha256sum docker-compose.yml .env.example'
|
||||
$ ssh toki@toki-labs.com 'cd ~/docker/agent-service/nexo/compose && sha256sum docker-compose.yml .env.example'
|
||||
c46bc291e42b1e87ca5e6b49d118bb59c67b0b2b1412a2751c6089e49d492563 docker-compose.yml
|
||||
fa56a8dc7a8dddc7737d42ec048e4f29836252e277e2d270f0ad0e7cbb38d430 .env.example
|
||||
|
||||
# 2. Check remote Docker Compose configuration
|
||||
$ ssh toki@toki-labs.com 'cd ~/docker/services/nexo/compose && /usr/local/bin/docker compose --env-file .env.example config >/tmp/nexo-compose-config.yml && /usr/bin/grep -E "toki-labs.com:5050/nexo/(mattermost|push-proxy):latest|platform: linux/arm64" /tmp/nexo-compose-config.yml'
|
||||
$ ssh toki@toki-labs.com 'cd ~/docker/agent-service/nexo/compose && /usr/local/bin/docker compose --env-file .env.example config >/tmp/nexo-compose-config.yml && /usr/bin/grep -E "toki-labs.com:5050/nexo/(mattermost|push-proxy):latest|platform: linux/arm64" /tmp/nexo-compose-config.yml'
|
||||
image: toki-labs.com:5050/nexo/mattermost:latest
|
||||
platform: linux/arm64
|
||||
image: toki-labs.com:5050/nexo/push-proxy:latest
|
||||
|
||||
# 3. Pull and start services on the remote server
|
||||
$ ssh toki@toki-labs.com 'export PATH=$PATH:/Applications/Docker.app/Contents/Resources/bin && cd ~/docker/services/nexo/compose && /usr/local/bin/docker compose pull && /usr/local/bin/docker compose up -d'
|
||||
$ ssh toki@toki-labs.com 'export PATH=$PATH:/Applications/Docker.app/Contents/Resources/bin && cd ~/docker/agent-service/nexo/compose && /usr/local/bin/docker compose pull && /usr/local/bin/docker compose up -d'
|
||||
Container nexo-core-db Running
|
||||
Container nexo-core-push-proxy Recreated
|
||||
Container nexo-core Recreated
|
||||
|
|
@ -75,7 +75,7 @@ Container nexo-core-db Healthy
|
|||
Container nexo-core Started
|
||||
|
||||
# 4. Remote Runtime Smoke Checks
|
||||
$ ssh toki@toki-labs.com 'cd ~/docker/services/nexo/compose && curl -fsS "http://localhost:18065/api/v4/system/ping" && /usr/local/bin/docker compose exec -T db pg_isready -U mmuser -d mattermost && curl -fsSI "http://localhost:18065" && /usr/local/bin/docker compose ps push-proxy'
|
||||
$ ssh toki@toki-labs.com 'cd ~/docker/agent-service/nexo/compose && curl -fsS "http://localhost:18065/api/v4/system/ping" && /usr/local/bin/docker compose exec -T db pg_isready -U mmuser -d mattermost && curl -fsSI "http://localhost:18065" && /usr/local/bin/docker compose ps push-proxy'
|
||||
{"ActiveSearchBackend":"database","AndroidLatestVersion":"","AndroidMinVersion":"","IosLatestVersion":"","IosMinVersion":"","status":"OK"}
|
||||
/var/run/postgresql:5432 - accepting connections
|
||||
HTTP/1.1 200 OK
|
||||
|
|
@ -104,10 +104,10 @@ This section presents the verification matrix for nexo local/remote runtime comp
|
|||
| **Remote Runtime Smoke** | `ssh toki@toki-labs.com '...'` | Remote host (`toki-labs.com` Mac ARM64) | Active system ping returns `"status":"OK"`, docker compose services are healthy. | `{"status":"OK"}`, all containers (`core`, `db`, `push-proxy`) show Up and healthy on ports `18065`/`18066`. | **PASS** |
|
||||
| **Unit & Widget Tests** | `bin/test` | Local workspace container | All tests in `packages/messaging_flutter` and `apps/flutter-test` pass successfully. | `All tests passed!` output from both Flutter plugin package and test app. | **PASS** |
|
||||
| **Static Code Analysis** | `bin/lint` | Local workspace container | Both projects analyze cleanly with zero static issues or lint warnings. | `Analyzing messaging_flutter... No issues found!`, `Analyzing flutter-test... No issues found!`. | **PASS** |
|
||||
| **Android Build Unit Tests** | `ssh toki@toki-labs.com 'cd ~/works/nexo/apps/flutter-test/android && ./gradlew testDebugUnitTest'` | Remote host Android SDK (`emulator-5554`) | Gradle compiles and runs native unit tests for the Android host wrapper. | Remote Gradle test completed with `BUILD SUCCESSFUL in 22s`; `NexoMessagingPluginTest > onMethodCall_getPlatformVersion_returnsExpectedValue() PASSED`. | **PASS** |
|
||||
| **Flutter Integration Test** | `ssh toki@toki-labs.com 'cd ~/works/nexo/apps/flutter-test && flutter test && flutter test integration_test -d emulator-5554'` | Remote host Flutter + Android emulator (`emulator-5554`) | Integration test validates plugin debug event flow on connected device/emulator. | Widget tests passed (`4/4`), debug APK built/installed on `emulator-5554`, and integration suite completed with all `3` tests passing. | **PASS** |
|
||||
| **Original Mattermost App** | `ssh toki@toki-labs.com 'cd ~/works/nexo/apps/mattermost && npm run check-test'` | Remote host Node `22.22.3` / npm `10.9.8`, Ruby/watchman Mattermost workspace | ESLint + TypeScript check + Jest unit tests pass against the remote host baseline. | Korean `FormattedDate` snapshot baseline was updated from `AM` to remote `Intl.DateTimeFormat` output `오전`. Retry passed: `PASS app/components/formatted_date/index.test.tsx`; `Test Suites: 2 skipped, 612 passed, 612 of 614 total`; `Tests: 7 skipped, 8162 passed, 8169 total`; `Snapshots: 303 passed, 303 total`. | **PASS** |
|
||||
| **Detox E2E Testing** | `ssh toki@toki-labs.com 'cd ~/works/nexo/apps/mattermost && npm run e2e:android'` | Remote host Android emulator + Mattermost runtime | Detox builds and executes end-to-end user flows against the emulated app. | Firebase debug config was supplied as ignored local/remote `apps/mattermost/android/app/google-services.json` with matching `com.mattermost.rnbeta` client, and Gradle completed `assembleDebug assembleAndroidTest` with `BUILD SUCCESSFUL in 9m`. `.detoxrc.json` now defaults Android emulator runs to the remote host's `Pixel_6_Pro_API_34`. Detox auto-boot with `CI=true npm run e2e:android-test` starts qemu for `@Pixel_6_Pro_API_34`, but the auto-booted process did not attach to `adb devices` after about 5 minutes. Manual `Pixel_6_Pro_API_34` boot attaches as `emulator-5554`; with Metro and `adb reverse tcp:8081 tcp:8081`, a default-config smoke retry assigned `server_login.e2e.ts` to `emulator-5554 (Pixel_6_Pro_API_34)`, then failed in `beforeAll` app readiness with `Exceeded timeout of 180000 ms` and Detox multiple-interaction/app-disconnect errors. | **FAIL** — default AVD selection is fixed, but Android E2E still needs a stable boot/start procedure and app readiness/synchronization follow-up before login-flow PASS. |
|
||||
| **Android Build Unit Tests** | `ssh toki@toki-labs.com 'cd ~/agent-work/nexo/apps/flutter-test/android && ./gradlew testDebugUnitTest'` | Remote host Android SDK (`emulator-5554`) | Gradle compiles and runs native unit tests for the Android host wrapper. | Remote Gradle test completed with `BUILD SUCCESSFUL in 22s`; `NexoMessagingPluginTest > onMethodCall_getPlatformVersion_returnsExpectedValue() PASSED`. | **PASS** |
|
||||
| **Flutter Integration Test** | `ssh toki@toki-labs.com 'cd ~/agent-work/nexo/apps/flutter-test && flutter test && flutter test integration_test -d emulator-5554'` | Remote host Flutter + Android emulator (`emulator-5554`) | Integration test validates plugin debug event flow on connected device/emulator. | Widget tests passed (`4/4`), debug APK built/installed on `emulator-5554`, and integration suite completed with all `3` tests passing. | **PASS** |
|
||||
| **Original Mattermost App** | `ssh toki@toki-labs.com 'cd ~/agent-work/nexo/apps/mattermost && npm run check-test'` | Remote host Node `22.22.3` / npm `10.9.8`, Ruby/watchman Mattermost workspace | ESLint + TypeScript check + Jest unit tests pass against the remote host baseline. | Korean `FormattedDate` snapshot baseline was updated from `AM` to remote `Intl.DateTimeFormat` output `오전`. Retry passed: `PASS app/components/formatted_date/index.test.tsx`; `Test Suites: 2 skipped, 612 passed, 612 of 614 total`; `Tests: 7 skipped, 8162 passed, 8169 total`; `Snapshots: 303 passed, 303 total`. | **PASS** |
|
||||
| **Detox E2E Testing** | `ssh toki@toki-labs.com 'cd ~/agent-work/nexo/apps/mattermost && npm run e2e:android'` | Remote host Android emulator + Mattermost runtime | Detox builds and executes end-to-end user flows against the emulated app. | Firebase debug config was supplied as ignored local/remote `apps/mattermost/android/app/google-services.json` with matching `com.mattermost.rnbeta` client, and Gradle completed `assembleDebug assembleAndroidTest` with `BUILD SUCCESSFUL in 9m`. `.detoxrc.json` now defaults Android emulator runs to the remote host's `Pixel_6_Pro_API_34`. Detox auto-boot with `CI=true npm run e2e:android-test` starts qemu for `@Pixel_6_Pro_API_34`, but the auto-booted process did not attach to `adb devices` after about 5 minutes. Manual `Pixel_6_Pro_API_34` boot attaches as `emulator-5554`; with Metro and `adb reverse tcp:8081 tcp:8081`, a default-config smoke retry assigned `server_login.e2e.ts` to `emulator-5554 (Pixel_6_Pro_API_34)`, then failed in `beforeAll` app readiness with `Exceeded timeout of 180000 ms` and Detox multiple-interaction/app-disconnect errors. | **FAIL** — default AVD selection is fixed, but Android E2E still needs a stable boot/start procedure and app readiness/synchronization follow-up before login-flow PASS. |
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -97,14 +97,14 @@ belongs to consuming apps or a separate roadmap item.
|
|||
|
||||
## Remote Parity
|
||||
|
||||
The remote development copy lives under `~/docker/services/nexo/compose`. Local
|
||||
The remote development copy lives under `~/docker/agent-service/nexo/compose`. Local
|
||||
and remote compose inputs should match unless a work report explicitly records
|
||||
an intentional temporary drift.
|
||||
|
||||
```sh
|
||||
cd services/core/compose
|
||||
sha256sum docker-compose.yml .env.example
|
||||
ssh <host> 'cd ~/docker/services/nexo/compose && sha256sum docker-compose.yml .env.example'
|
||||
ssh <host> 'cd ~/docker/agent-service/nexo/compose && sha256sum docker-compose.yml .env.example'
|
||||
```
|
||||
|
||||
The two `sha256sum` outputs should match for both files before remote runtime
|
||||
|
|
|
|||
Loading…
Reference in a new issue