update roadmap: phase updates, independent-service deletion, upstream-runtime addition
This commit is contained in:
parent
54121f5b80
commit
0e7b7d4918
16 changed files with 275 additions and 241 deletions
|
|
@ -2,10 +2,11 @@
|
|||
|
||||
## 전체 목표
|
||||
|
||||
`nexo`는 메시지 전체와 알림을 포괄하는 독립 메시징/알림 서비스로 정리한다.
|
||||
현재 서버/푸시 런타임은 검증 가능한 단위로 유지하되, 제품 표면과 개발 경계는 nexo가 소유한다.
|
||||
최종 형태는 서버 코어, Flutter 클라이언트, Flutter 플러그인이 한 세트로 움직이며,
|
||||
여러 앱이 표준화된 메시징 채널과 알림 파이프라인을 사용할 수 있는 서비스다.
|
||||
`nexo`는 Mattermost server, webapp, push-proxy를 upstream-followable 메시징 런타임으로 계승하고,
|
||||
Flutter 플러그인을 nexo-owned embedded messaging/notification SDK로 제공한다.
|
||||
서버, 기본 웹 메시지 앱, push-proxy는 보안/버그/기능 업데이트를 계속 따라가기 쉬운 구조로 유지하고,
|
||||
nexo의 제품 표면은 SDK, compose, 운영 계약, 얇은 branding/compatibility layer에 둔다.
|
||||
최종 형태는 upstream update를 CI/CD와 runbook으로 흡수하면서 여러 앱이 표준화된 메시징 채널과 알림 파이프라인을 사용할 수 있는 서비스다.
|
||||
|
||||
## Phase 흐름
|
||||
|
||||
|
|
@ -16,13 +17,13 @@
|
|||
|
||||
- [진행중] 제품 기반 정리
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/PHASE.md`
|
||||
- 요약: nexo의 독립 제품 정체성, 모노레포 구조, 검증 가능한 런타임 기준선을 고정한다.
|
||||
- 요약: nexo의 제품 경계, 모노레포 구조, upstream-followable 런타임 기준선을 고정한다.
|
||||
- [계획] 업스트림 런타임 운영화
|
||||
- 경로: `agent-ops/roadmap/phase/upstream-runtime/PHASE.md`
|
||||
- 요약: Mattermost server/webapp/push-proxy 업데이트를 계속 따라가기 위한 기준, CI/CD, 장애 대응 루프를 만든다.
|
||||
- [계획] 메시징 런타임 표준화
|
||||
- 경로: `agent-ops/roadmap/phase/messaging-runtime/PHASE.md`
|
||||
- 요약: 플러그인과 서버가 공유할 메시징/알림 계약, 테스트, 앱별 사용 채널 모델을 정리한다.
|
||||
- [스케치] 독립 서비스화
|
||||
- 경로: `agent-ops/roadmap/phase/independent-service/PHASE.md`
|
||||
- 요약: 서버 코어의 제품 표면, 운영 방식, 불필요 기능을 nexo 목적에 맞게 분리한다.
|
||||
- 요약: nexo-owned Flutter SDK와 upstream runtime이 공유할 메시징/알림 계약, 테스트, 앱별 사용 채널 모델을 정리한다.
|
||||
|
||||
## 로딩 정책
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@
|
|||
|
||||
## 상태
|
||||
|
||||
[진행중]
|
||||
[완료]
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
|
|
@ -39,27 +39,30 @@
|
|||
|
||||
nexo가 제공하려는 서비스의 방향과 기존 기술을 대하는 방식을 문서와 네이밍 기준선으로 만든다.
|
||||
|
||||
- [ ] [product-story] nexo를 메시지 전체와 알림을 포괄하는 독립 메시징/알림 서비스로 설명하는 문서 표현을 README, roadmap, domain rule에서 일관되게 유지한다. 검증: 관련 문서에서 제품 목표와 모듈 경계가 충돌하지 않는다.
|
||||
- [ ] [tech-boundary] 기존 upstream/vendor 명칭을 public product identity에서 제거하고, project-owned 문서/설정/코드 naming의 nexo 전환 기준을 정리한다.
|
||||
- [ ] [nexo-rename] package/import/native package 등 project-owned code identifier를 nexo 계열 이름으로 전환할 범위와 실행 순서를 정리한다. 검증: repo scan에서 기존 upstream/vendor 명칭이 허용된 compatibility context에만 남는다.
|
||||
- [ ] [module-shape] 최상위 구조를 `apps/client`, `packages/messaging_flutter`, `services/core` 중심으로 유지하고 과한 scaffold를 만들지 않는 원칙을 문서화한다.
|
||||
- [x] [product-story] nexo를 메시지 전체와 알림을 포괄하는 독립 메시징/알림 서비스로 설명하는 문서 표현을 README, roadmap, domain rule에서 일관되게 유지한다. 검증: 관련 문서에서 제품 목표와 모듈 경계가 충돌하지 않는다.
|
||||
- [x] [tech-boundary] 기존 upstream/vendor 명칭을 public product identity에서 제거하고, project-owned 문서/설정/코드 naming의 nexo 전환 기준을 정리한다.
|
||||
- [x] [nexo-rename] package/import/native package 등 project-owned code identifier를 nexo 계열 이름으로 전환할 범위와 실행 순서를 정리한다. 검증: repo scan에서 기존 upstream/vendor 명칭이 허용된 compatibility context에만 남는다.
|
||||
- [x] [module-shape] 최상위 구조를 `apps/client`, `packages/messaging_flutter`, `services/core` 중심으로 유지하고 과한 scaffold를 만들지 않는 원칙을 문서화한다.
|
||||
|
||||
### Epic: [agent-entry] 작업 진입점
|
||||
|
||||
AI 에이전트와 사람이 같은 규칙으로 프로젝트에 들어오도록 작업 진입점을 고정한다.
|
||||
|
||||
- [ ] [rules-entry] `AGENTS.md`, `agent-ops/rules/project/rules.md`, domain rules, roadmap current의 역할을 충돌 없이 연결한다.
|
||||
- [ ] [readme-entry] 루트 README가 제품 소개와 작업 진입점 역할을 함께 수행하도록 유지한다. 검증: README의 명령과 참조 경로가 실제 파일을 가리킨다.
|
||||
- [x] [rules-entry] `AGENTS.md`, `agent-ops/rules/project/rules.md`, domain rules, roadmap current의 역할을 충돌 없이 연결한다.
|
||||
- [x] [readme-entry] 루트 README가 제품 소개와 작업 진입점 역할을 함께 수행하도록 유지한다. 검증: README의 명령과 참조 경로가 실제 파일을 가리킨다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 상태: 승인됨
|
||||
- 요청일: 2026-05-27
|
||||
- 완료 근거:
|
||||
- `README.md`, `agent-ops/rules/project/rules.md`, domain rules, roadmap 문서가 nexo를 메시징/알림 서비스로 설명하고 `apps/client`, `packages/messaging_flutter`, `services/core` 경계를 같은 기준으로 유지한다.
|
||||
- `packages/messaging_flutter`와 `apps/client`의 public package/import/native identifier가 `nexo_messaging`, `NexoMessagingPlugin`, `com.tokilabs.nexo.messaging`, `com.tokilabs.nexo_client` 계열로 정리되어 있다.
|
||||
- 기존 upstream/vendor 명칭은 `services/core` upstream 영역과 compose image/db/user/path, push-proxy config 같은 compatibility context에 남아 있다.
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
- [x] 사용자가 완료 결과를 확인했다
|
||||
- [x] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 2026-05-27 사용자 승인으로 완료 처리하고 archive로 이동한다.
|
||||
|
||||
## 범위 제외
|
||||
|
||||
|
|
@ -4,20 +4,25 @@
|
|||
|
||||
- [진행중] 제품 기반 정리
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/PHASE.md`
|
||||
- [계획] 업스트림 런타임 운영화
|
||||
- 경로: `agent-ops/roadmap/phase/upstream-runtime/PHASE.md`
|
||||
- [계획] 메시징 런타임 표준화
|
||||
- 경로: `agent-ops/roadmap/phase/messaging-runtime/PHASE.md`
|
||||
|
||||
## 활성 Milestone
|
||||
|
||||
- [진행중] 정체성 기준선
|
||||
- Phase: `agent-ops/roadmap/phase/product-foundation/PHASE.md`
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/milestones/identity-baseline.md`
|
||||
- [계획] 운영 기준선
|
||||
- Phase: `agent-ops/roadmap/phase/product-foundation/PHASE.md`
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/milestones/runtime-baseline.md`
|
||||
- [계획] 클라이언트 검증 기준선
|
||||
- Phase: `agent-ops/roadmap/phase/product-foundation/PHASE.md`
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/milestones/client-validation.md`
|
||||
- [계획] 업스트림 팔로잉 기준선
|
||||
- Phase: `agent-ops/roadmap/phase/upstream-runtime/PHASE.md`
|
||||
- 경로: `agent-ops/roadmap/phase/upstream-runtime/milestones/upstream-following.md`
|
||||
- [계획] CI/CD와 운영 업데이트 루프
|
||||
- Phase: `agent-ops/roadmap/phase/upstream-runtime/PHASE.md`
|
||||
- 경로: `agent-ops/roadmap/phase/upstream-runtime/milestones/cicd-operations.md`
|
||||
- [계획] 메시징 계약 표준화
|
||||
- Phase: `agent-ops/roadmap/phase/messaging-runtime/PHASE.md`
|
||||
- 경로: `agent-ops/roadmap/phase/messaging-runtime/milestones/messaging-contract.md`
|
||||
|
|
|
|||
|
|
@ -1,29 +0,0 @@
|
|||
# Phase: 독립 서비스화
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 목표
|
||||
|
||||
nexo가 사용자에게 제공하는 독립 메시징/알림 서비스라는 제품 표면을 서버 구현 세부와 분리한다.
|
||||
장기적으로는 필요한 메시징 코어만 유지하고 불필요한 UI, 운영 기능, 이름, 문서 표면을 nexo 목적에 맞게 줄인다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
스케치 Milestone은 아직 구현 가능한 계획이 아니므로 계획 Milestone보다 아래에 둔다.
|
||||
|
||||
- [스케치] 서버 코어 독립화 경계
|
||||
- 경로: `agent-ops/roadmap/phase/independent-service/milestones/core-independence.md`
|
||||
- 요약: 서버 core에서 유지할 기능과 제거/숨김/대체할 기능의 경계를 정한다.
|
||||
- [스케치] 제품화와 운영 모델
|
||||
- 경로: `agent-ops/roadmap/phase/independent-service/milestones/product-operations.md`
|
||||
- 요약: nexo를 별도 서비스로 배포, 운영, 확장하기 위한 제품/운영 단위를 검토한다.
|
||||
|
||||
## Phase 경계
|
||||
|
||||
- 이 Phase는 아직 구현 계획이 아니라 장기 방향성 정리 단계다.
|
||||
- upstream과의 비교 가능성을 잃는 대규모 변경은 경계 결정 전 진행하지 않는다.
|
||||
- 사용자가 보는 제품 표면을 우선 분리하고, 내부 compatibility layer는 필요한 만큼 유지한다.
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
# Milestone: 서버 코어 독립화 경계
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-ops/roadmap/ROADMAP.md`
|
||||
- Phase: `agent-ops/roadmap/phase/independent-service/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
nexo 서버 core에서 유지할 메시징 기능과 제거, 숨김, 대체할 기능의 경계를 정한다.
|
||||
이 결정은 서버 fork 비용과 upstream 추적 가능성에 직접 영향을 주므로 먼저 스케치로 유지한다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] nexo가 반드시 유지해야 할 core 기능 목록을 정한다.
|
||||
- [ ] 제거하거나 숨길 서버 기능 목록을 정한다.
|
||||
- [ ] upstream merge 가능성을 유지할지, 독립 fork로 갈지 기준을 정한다.
|
||||
- [ ] 서버 이미지 빌드 방식을 official image 사용, source build, custom image 중 하나로 결정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요:
|
||||
- [ ] upstream 추적 가능성을 어느 정도까지 유지할지 결정한다.
|
||||
- [ ] 웹앱을 유지할지, admin/debug 표면으로만 둘지, 제거할지 결정한다.
|
||||
- [ ] nexo 서버 이미지를 언제 자체 빌드로 전환할지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- `services/core` upstream baseline과 fork 전략
|
||||
- server API, webapp, plugin, push-proxy의 유지/숨김/제거 후보
|
||||
- Docker image build와 배포 전략 후보
|
||||
- 불필요 기능 제거에 따른 테스트/운영 위험
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [inheritance] 계승 경계
|
||||
|
||||
nexo가 서버 core에서 계속 가져갈 기능을 정의한다.
|
||||
|
||||
- [ ] [keep-list] 메시징, channel, user/session, push 관련 유지 기능 목록을 정리한다.
|
||||
- [ ] [remove-list] nexo 목적과 맞지 않는 기능의 제거/숨김/보류 후보를 정리한다.
|
||||
- [ ] [upstream-policy] upstream 추적 방식과 conflict 비용을 판단할 기준을 정리한다.
|
||||
|
||||
### Epic: [build] 서버 빌드
|
||||
|
||||
official image에서 custom image로 넘어갈 조건을 정리한다.
|
||||
|
||||
- [ ] [image-policy] official image, source build, custom image의 장단점과 전환 조건을 정리한다.
|
||||
- [ ] [test-impact] server 변경 시 필요한 smoke, Go test, API test 범위를 정리한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 실제 core 코드 제거와 대규모 rename은 승격 전까지 진행하지 않는다.
|
||||
- upstream baseline 변경은 이 Milestone의 결정 없이 하지 않는다.
|
||||
- full reimplementation은 기본 후보가 아니다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `services/core/`, `services/core/UPSTREAM.md`, `services/core/compose/`
|
||||
- 표준선(선택): 검증된 서버 core를 유지하면서 nexo 제품 표면부터 분리한다
|
||||
- 선행 작업: 메시징 런타임 표준화
|
||||
- 후속 작업: 제품화와 운영 모델
|
||||
- 확인 필요: upstream 추적 정책, webapp 처리, server image 전환 시점
|
||||
|
|
@ -1,79 +0,0 @@
|
|||
# Milestone: 제품화와 운영 모델
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-ops/roadmap/ROADMAP.md`
|
||||
- Phase: `agent-ops/roadmap/phase/independent-service/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
nexo를 단순 개발 레포가 아니라 반복 배포 가능한 서비스로 운영하기 위한 모델을 검토한다.
|
||||
첫 운영 단위, 도메인/프록시, 환경 분리, 배포 검증, 앱 onboarding 문서를 정리할 준비를 한다.
|
||||
|
||||
## 상태
|
||||
|
||||
[스케치]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- [ ] 첫 production-like 환경의 범위를 정한다.
|
||||
- [ ] 도메인, TLS, reverse proxy, 백업, 로그 보존의 최소 운영 기준을 정한다.
|
||||
- [ ] 앱 onboarding 문서와 운영 runbook의 책임 경계를 정한다.
|
||||
- [ ] release/versioning 기준을 정한다.
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요:
|
||||
- [ ] nexo를 먼저 private service로 운영할지, 여러 앱이 쓰는 internal platform으로 볼지 결정한다.
|
||||
- [ ] release/versioning을 server, plugin, client 각각 따로 할지 monorepo tag로 묶을지 결정한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- deployment topology 후보
|
||||
- domain/proxy/TLS 후보
|
||||
- backup/log/monitoring 최소 기준
|
||||
- release/versioning 후보
|
||||
- 앱 onboarding과 운영 runbook 후보
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [deploy] 배포 모델
|
||||
|
||||
서비스로 운영할 최소 배포 단위를 정리한다.
|
||||
|
||||
- [ ] [topology] 단일 compose, remote docker, reverse proxy 연결 후보를 정리한다.
|
||||
- [ ] [environment] dev/test/production-like 환경 분리 기준을 정리한다.
|
||||
- [ ] [release] server/plugin/client 버전과 배포 순서를 정리한다.
|
||||
|
||||
### Epic: [ops] 운영 기준
|
||||
|
||||
서비스 운영에 필요한 최소 runbook 후보를 만든다.
|
||||
|
||||
- [ ] [health] core, db, push-proxy health check와 장애 확인 절차 후보를 정리한다.
|
||||
- [ ] [backup] db와 runtime data 백업/복원 책임 후보를 정리한다.
|
||||
- [ ] [onboarding] 새 앱이 nexo를 붙일 때 필요한 설정, credential, smoke 절차 후보를 정리한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- production hardening 구현은 승격 전까지 진행하지 않는다.
|
||||
- 외부 공개용 landing page나 marketing site는 포함하지 않는다.
|
||||
- billing, admin console, organization management는 별도 제품 결정 전까지 포함하지 않는다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `services/core/compose/`, `docs/`, `packages/messaging_flutter/README.md`, `apps/client/README.md`
|
||||
- 표준선(선택): 먼저 private/internal service 운영 기준을 잡고 확장 비용이 확인될 때 platform 형태를 검토한다
|
||||
- 선행 작업: 서버 코어 독립화 경계, 멀티앱 채널 모델
|
||||
- 후속 작업: 없음
|
||||
- 확인 필요: 운영 제품 형태와 versioning 방식
|
||||
|
|
@ -7,7 +7,8 @@
|
|||
## 목표
|
||||
|
||||
알림만 떼어낸 기능이 아니라, 여러 앱이 사용할 수 있는 메시징/알림 런타임 계약을 정리한다.
|
||||
서버 core와 Flutter 플러그인의 역할을 명확히 나누고, 앱별 채널 분기와 호환 API를 제품 기능으로 다룰 수 있게 만든다.
|
||||
Mattermost server/webapp/push-proxy는 upstream-followable runtime으로 두고, Flutter 플러그인은 nexo-owned embedded SDK로 역할을 명확히 나눈다.
|
||||
앱별 채널 분기와 호환 API를 제품 기능으로 다룰 수 있게 만든다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
|
|
@ -28,5 +29,7 @@
|
|||
## Phase 경계
|
||||
|
||||
- 계약이 중복되기 전까지 별도 `contract` 패키지를 만들지 않고, server API와 plugin public API 문서로 관리한다.
|
||||
- `packages/messaging_flutter`는 앱별 알림 구현을 대체하는 공통 플러그인 책임을 가진다.
|
||||
- `services/core`는 메시징 서버와 push-proxy 연동 책임을 가지며, client UI 책임을 갖지 않는다.
|
||||
- `packages/messaging_flutter`는 앱별 알림 구현을 대체하는 nexo-owned embedded SDK 책임을 가진다.
|
||||
- `packages/messaging_flutter/android`는 Mattermost mobile code를 계속 merge하는 대상이 아니라, server/push 계약과 Android/FCM platform 변화를 추적한다.
|
||||
- `services/core`는 upstream-followable server/webapp/push-proxy runtime 책임을 가진다.
|
||||
- `services/core/webapp`은 기본 메시지 앱/reference front로 유지할 수 있지만, Flutter SDK 소비 앱 책임과 섞지 않는다.
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@
|
|||
|
||||
## 목표
|
||||
|
||||
서버 core와 Flutter 플러그인이 주고받는 메시지, 알림, device token, ACK, navigation event 계약을 정리한다.
|
||||
초기에는 기존 서버/플러그인 계약을 유지하되, nexo가 소유할 API와 compatibility layer를 구분한다.
|
||||
upstream-followable server/push runtime과 nexo-owned Flutter SDK가 주고받는 메시지, 알림, device token, ACK, navigation event 계약을 정리한다.
|
||||
서버/webapp/push-proxy compatibility는 유지하되, 앱이 의존할 nexo SDK API와 compatibility layer를 구분한다.
|
||||
|
||||
## 상태
|
||||
|
||||
|
|
@ -22,14 +22,16 @@
|
|||
|
||||
- 상태: 잠금
|
||||
- 결정 필요:
|
||||
- [ ] nexo public API를 기존 호환 형태로 유지할지, nexo wrapper API를 먼저 만들지 결정한다.
|
||||
- [ ] 메시징 전체 기능 중 Flutter 앱에 우선 노출할 범위를 결정한다.
|
||||
- 결정 완료:
|
||||
- [x] 2026-05-27: Flutter public API는 nexo-owned SDK wrapper로 유지하고, server/push runtime compatibility와 분리한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- Flutter plugin public Dart API
|
||||
- Android native plugin event와 storage contract
|
||||
- server core push payload, ACK, channel/thread routing contract
|
||||
- Mattermost webapp/reference front와 Flutter SDK가 공유하거나 분리해야 할 계약 경계
|
||||
- 계약 문서 위치와 테스트 anchor
|
||||
|
||||
## 기능
|
||||
|
|
@ -41,6 +43,7 @@
|
|||
- [ ] [dart-api] Dart public API에서 유지할 이름, deprecated 후보, nexo wrapper 후보를 분리한다.
|
||||
- [ ] [event-shape] notification event, opened event, token event의 payload shape와 backward compatibility 기준을 문서화한다.
|
||||
- [ ] [token-flow] device token 저장, auth token 저장, signing key 저장 책임과 호출 순서를 정리한다.
|
||||
- [ ] [sdk-runtime-boundary] Flutter SDK가 server/push contract를 추적하되 Mattermost mobile implementation을 팔로잉하지 않는 경계를 문서화한다.
|
||||
|
||||
### Epic: [server-contract] Server contract
|
||||
|
||||
|
|
@ -49,6 +52,7 @@
|
|||
- [ ] [push-payload] push payload 필드와 검증 기준을 서버/플러그인 양쪽 문서에서 연결한다.
|
||||
- [ ] [ack-contract] ACK 요청 형식과 실패 처리 기준을 정리한다.
|
||||
- [ ] [routing-contract] channel/thread navigation event가 client router로 전달되는 기준을 정리한다.
|
||||
- [ ] [front-compat] Mattermost webapp/reference front에서 동작하는 기본 메시징 기능과 Flutter SDK embedded 흐름이 충돌하지 않는 기준을 정리한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
|
|
@ -69,7 +73,7 @@
|
|||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `packages/messaging_flutter/lib/`, `packages/messaging_flutter/android/`, `services/core/server/`, `apps/client/`
|
||||
- 표준선(선택): compatibility를 깨는 rename보다 wrapper와 migration path를 우선 검토한다
|
||||
- 표준선(선택): SDK public API는 nexo-owned wrapper로 유지하고, server/webapp/push-proxy compatibility는 얇은 layer로 흡수한다
|
||||
- 선행 작업: 정체성 기준선, 클라이언트 검증 기준선
|
||||
- 후속 작업: 알림 파이프라인 고도화, 멀티앱 채널 모델
|
||||
- 확인 필요: public API 방향과 Flutter 앱 우선 노출 범위
|
||||
- 확인 필요: Flutter 앱 우선 노출 범위
|
||||
|
|
|
|||
|
|
@ -8,7 +8,8 @@
|
|||
## 목표
|
||||
|
||||
여러 앱이 nexo를 사용할 때 서비스 전체를 복제하지 않고 앱별 사용 채널과 알림 라우팅만 늘릴 수 있는 모델을 검토한다.
|
||||
이 Milestone은 아직 컨셉 단계이며, 앱 식별, 채널 분기, 권한, push credential 분리 기준을 먼저 정한다.
|
||||
이 Milestone은 아직 컨셉 단계이며, 앱 식별, channel/team/tenant 분기, 권한, push credential 분리 기준을 먼저 정한다.
|
||||
server/webapp/push-proxy는 upstream-followable runtime으로 두고, 앱별 내장은 Flutter SDK 설정으로 확장한다.
|
||||
|
||||
## 상태
|
||||
|
||||
|
|
@ -33,6 +34,7 @@
|
|||
- 앱별 channel/tenant/server 분기 후보
|
||||
- plugin configuration model 후보
|
||||
- server core 설정과 push-proxy credential 분리 후보
|
||||
- Mattermost webapp/reference front와 embedded SDK가 함께 사용할 수 있는 channel/team 모델 후보
|
||||
- 첫 번째 소비 앱 onboarding 흐름
|
||||
|
||||
## 기능
|
||||
|
|
@ -73,5 +75,5 @@
|
|||
- 관련 경로: `services/core/`, `packages/messaging_flutter/`, `apps/client/`
|
||||
- 표준선(선택): 먼저 channel 기반 최소 모델을 검토하고, 운영 비용이 커질 때 tenant/server 분리를 검토한다
|
||||
- 선행 작업: 메시징 계약 표준화, 알림 파이프라인 고도화
|
||||
- 후속 작업: 독립 서비스화 Phase의 운영 모델
|
||||
- 후속 작업: 업스트림 런타임 운영화 Phase의 CI/CD와 운영 업데이트 루프
|
||||
- 확인 필요: 앱별 분기 단위와 credential 분리 기준
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@
|
|||
|
||||
FCM 수신부터 signing-key 검증, 로컬 저장, notification display, ACK, inline reply, dismiss, open routing까지 이어지는 알림 파이프라인을 플러그인 책임으로 안정화한다.
|
||||
host app은 라우팅과 로그인 상태 연결만 담당하도록 경계를 유지한다.
|
||||
Android 구현은 Mattermost mobile code 팔로잉 대상이 아니라 nexo-owned SDK 구현으로 관리한다.
|
||||
|
||||
## 상태
|
||||
|
||||
|
|
@ -31,6 +32,7 @@ host app은 라우팅과 로그인 상태 연결만 담당하도록 경계를
|
|||
- signing key, auth token, device token storage
|
||||
- ACK delivery, inline reply, dismiss action
|
||||
- client notification-open callback
|
||||
- server/push-proxy payload와 Android/FCM platform 변화 추적
|
||||
- 수동 smoke와 자동 테스트의 분리
|
||||
|
||||
## 기능
|
||||
|
|
@ -43,6 +45,7 @@ Android-first 알림 파이프라인을 안정된 제품 책임으로 만든다.
|
|||
- [ ] [display-notification] message/thread notification display 기준을 정리하고 회귀 테스트 후보를 만든다.
|
||||
- [ ] [ack-delivery] ACK request 성공/실패 처리와 retry 후보를 정리한다.
|
||||
- [ ] [reply-dismiss] inline reply와 dismiss action의 storage/network 경계를 정리한다.
|
||||
- [ ] [platform-follow] Mattermost mobile implementation merge 대신 server/push contract, FCM, Android notification platform 변경을 추적하는 기준을 정리한다.
|
||||
|
||||
### Epic: [host-routing] Host routing
|
||||
|
||||
|
|
@ -70,7 +73,7 @@ host app이 받아야 할 최소 이벤트만 노출한다.
|
|||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `packages/messaging_flutter/android/`, `packages/messaging_flutter/lib/`, `apps/client/integration_test/`
|
||||
- 표준선(선택): Android-first로 자동화 가능한 테스트를 늘리고, FCM delivery는 수동 smoke로 분리한다
|
||||
- 표준선(선택): Android-first nexo SDK로 자동화 가능한 테스트를 늘리고, FCM delivery는 수동 smoke로 분리한다
|
||||
- 선행 작업: 메시징 계약 표준화
|
||||
- 후속 작업: 멀티앱 채널 모델, iOS/APNS 후보
|
||||
- 확인 필요: iOS 우선순위와 ACK 실패 책임 범위
|
||||
|
|
|
|||
|
|
@ -6,8 +6,8 @@
|
|||
|
||||
## 목표
|
||||
|
||||
nexo를 메시지 전체와 알림을 포괄하는 독립적인 메시징/알림 서비스로 정의한다.
|
||||
모노레포 구조, core compose, client 검증 흐름, agent-ops 진입 규칙을 정리해 이후 기능 작업이 같은 기준선 위에서 진행되도록 만든다.
|
||||
nexo를 Mattermost 기반 서버/front/push-proxy 런타임과 nexo-owned Flutter SDK가 함께 움직이는 메시징/알림 서비스로 정의한다.
|
||||
모노레포 구조, upstream-followable runtime, client 검증 흐름, agent-ops 진입 규칙을 정리해 이후 기능 작업이 같은 기준선 위에서 진행되도록 만든다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
|
|
@ -15,12 +15,12 @@ nexo를 메시지 전체와 알림을 포괄하는 독립적인 메시징/알림
|
|||
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
스케치 Milestone은 아직 구현 가능한 계획이 아니므로 계획 Milestone보다 아래에 둔다.
|
||||
|
||||
- [진행중] 정체성 기준선
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/milestones/identity-baseline.md`
|
||||
- 요약: 제품 이름, 메시징/알림 서비스 범위, project-owned naming의 nexo 전환 기준을 문서화한다.
|
||||
- [완료] 정체성 기준선
|
||||
- 경로: `agent-ops/roadmap/archive/phase/product-foundation/milestones/identity-baseline.md`
|
||||
- 요약: 제품 이름, 메시징/알림 서비스 범위, project-owned naming의 nexo 전환 기준을 문서화했다.
|
||||
- [계획] 운영 기준선
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/milestones/runtime-baseline.md`
|
||||
- 요약: core compose, 원격 Docker 세팅, 환경 변수, 최소 health check를 안정된 기준선으로 만든다.
|
||||
- 요약: Mattermost server/webapp/push-proxy compose, 원격 Docker 세팅, 환경 변수, 최소 health check를 안정된 기준선으로 만든다.
|
||||
- [계획] 클라이언트 검증 기준선
|
||||
- 경로: `agent-ops/roadmap/phase/product-foundation/milestones/client-validation.md`
|
||||
- 요약: `apps/client`가 플러그인 소비 앱이자 테스트 호스트로 반복 검증을 제공하도록 고정한다.
|
||||
|
|
@ -30,4 +30,6 @@ nexo를 메시지 전체와 알림을 포괄하는 독립적인 메시징/알림
|
|||
- 모노레포의 기본 골격은 `apps/client`, `packages/messaging_flutter`, `services/core`로 유지한다.
|
||||
- `contract`, `infra`, `sandbox` 같은 별도 최상위 모듈은 중복 필요가 명확해지기 전까지 만들지 않는다.
|
||||
- Docker compose와 runtime 설정은 `services/core/compose/` 안에 둔다.
|
||||
- `services/core/`의 upstream baseline 변경은 이 Phase의 기본 범위가 아니다.
|
||||
- `services/core/server`, `services/core/webapp`, push-proxy 연동은 upstream-followable 상태를 우선한다.
|
||||
- upstream-owned 코드의 대량 rename이나 deep fork는 이 Phase의 기본 범위가 아니다.
|
||||
- nexo-owned naming은 SDK, compose, 운영 문서, 얇은 compatibility layer에 우선 적용한다.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
|
||||
## 목표
|
||||
|
||||
`apps/client`를 테스트용 앱이자 실제 소비 앱 형태의 얇은 클라이언트로 유지한다.
|
||||
`apps/client`를 테스트용 앱이자 nexo-owned Flutter SDK를 소비하는 얇은 클라이언트로 유지한다.
|
||||
플러그인 등록, method channel, event channel, notification-open routing, Android native unit test를 반복 검증할 수 있게 한다.
|
||||
|
||||
## 상태
|
||||
|
|
@ -27,6 +27,7 @@
|
|||
|
||||
- `apps/client`의 Flutter 테스트와 통합 테스트
|
||||
- `packages/messaging_flutter`의 Dart 테스트와 Android native unit test
|
||||
- Flutter SDK Android 구현이 Mattermost mobile upstream-following 코드가 아니라 nexo-owned embedded SDK임을 확인하는 문서/테스트 경계
|
||||
- Android SDK 또는 원격 Android 테스트 환경 사용 절차
|
||||
- FCM/ACK 수동 smoke와 자동화 가능한 테스트의 경계
|
||||
|
||||
|
|
@ -39,6 +40,7 @@ client 앱을 플러그인 통합 검증에 필요한 만큼만 유지한다.
|
|||
- [ ] [thin-client] `apps/client`가 제품 UI가 아니라 plugin integration host 역할을 유지하도록 README와 테스트가 같은 기준을 따른다.
|
||||
- [ ] [integration-path] plugin method channel, event channel, opened-routing 통합 테스트 경로를 유지한다. 검증: `cd apps/client && flutter test integration_test`가 지원 환경에서 성공한다.
|
||||
- [ ] [native-test] Android native unit test 실행 절차를 유지한다. 검증: `cd apps/client/android && ./gradlew testDebugUnitTest`가 Android SDK 환경에서 성공한다.
|
||||
- [ ] [sdk-boundary] Flutter SDK Android 구현은 Mattermost mobile code를 팔로잉하지 않고 server/push contract와 Android/FCM platform 변화만 추적한다는 기준을 문서화한다.
|
||||
|
||||
### Epic: [manual-smoke] 외부 인프라 smoke
|
||||
|
||||
|
|
@ -66,7 +68,7 @@ client 앱을 플러그인 통합 검증에 필요한 만큼만 유지한다.
|
|||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `apps/client/`, `packages/messaging_flutter/`, `packages/messaging_flutter/docs/android-test-environment.md`
|
||||
- 표준선(선택): client는 실제 소비 앱 모양의 검증 호스트이며 별도 `/example`이나 `/sandbox`를 두지 않는다
|
||||
- 표준선(선택): client는 실제 소비 앱 모양의 검증 호스트이며 별도 `/example`이나 `/sandbox`를 두지 않는다. Flutter SDK는 nexo-owned embedded SDK로 유지한다
|
||||
- 선행 작업: client migration과 1차 테스트
|
||||
- 후속 작업: 메시징 계약 표준화, 알림 파이프라인 고도화
|
||||
- 확인 필요: 없음
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@
|
|||
|
||||
## 목표
|
||||
|
||||
core compose와 원격 Docker 세팅을 nexo의 반복 가능한 테스트 런타임으로 고정한다.
|
||||
nexo용 포트, 환경 변수, 데이터 경로, push-proxy 설정을 명확히 분리한다.
|
||||
Mattermost server, webapp, push-proxy compose와 원격 Docker 세팅을 nexo의 반복 가능한 테스트 런타임으로 고정한다.
|
||||
nexo용 포트, 환경 변수, 데이터 경로, push-proxy 설정을 분리하되 upstream update를 따라가기 쉬운 runtime shape를 유지한다.
|
||||
|
||||
## 상태
|
||||
|
||||
|
|
@ -24,29 +24,34 @@ nexo용 포트, 환경 변수, 데이터 경로, push-proxy 설정을 명확히
|
|||
- 결정 필요:
|
||||
- [ ] 원격 환경에서 nexo를 별도 포트 테스트 서비스로 유지할지, 도메인/프록시까지 연결할지 결정한다.
|
||||
- [ ] push-proxy의 FCM 자격 증명과 테스트/운영 credential 분리 기준을 결정한다.
|
||||
- 결정 완료:
|
||||
- [x] 2026-05-27: Mattermost server/webapp/push-proxy는 nexo가 deep fork하지 않고 upstream-followable runtime으로 유지한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- `services/core/compose/`의 compose와 `.env.example`
|
||||
- `services/core/server/`, `services/core/webapp/`의 upstream-followable runtime 경계
|
||||
- push-proxy image/source tracking과 credential/config 경계
|
||||
- 원격 `~/docker/services/nexo/` 배치와 로컬 compose의 동등성
|
||||
- core, Postgres, push-proxy 최소 health check
|
||||
- core, webapp, Postgres, push-proxy 최소 health check
|
||||
- runtime data와 secret이 git에 들어가지 않도록 유지하는 규칙
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [compose] Core compose
|
||||
|
||||
local과 원격 Docker에서 같은 shape로 서버 런타임을 올릴 수 있게 한다.
|
||||
local과 원격 Docker에서 같은 shape로 server/webapp/push-proxy 런타임을 올릴 수 있게 한다.
|
||||
|
||||
- [ ] [local-compose] `services/core/compose`에서 core, db, push-proxy가 함께 실행되는 기준을 유지한다. 검증: `cd services/core/compose && docker compose up -d` 후 core ping이 성공한다.
|
||||
- [ ] [local-compose] `services/core/compose`에서 core, webapp, db, push-proxy가 함께 실행되는 기준을 유지한다. 검증: `cd services/core/compose && docker compose up -d` 후 core ping과 webapp 접근이 성공한다.
|
||||
- [ ] [remote-parity] 원격 `~/docker/services/nexo/compose`와 repo의 compose 파일이 의도적으로 동기화되는 절차를 문서화한다. 검증: local/remote compose와 `.env.example` hash 비교가 일치한다.
|
||||
- [ ] [secret-boundary] `.env`, data, push-proxy credential이 git 추적 밖에 머무는 기준을 유지한다.
|
||||
- [ ] [upstream-runtime] server/webapp/push-proxy runtime은 official image/source baseline을 추적하고, nexo 변경은 compose/env/docs/thin patch로 제한하는 기준을 문서화한다.
|
||||
|
||||
### Epic: [smoke] Runtime smoke
|
||||
|
||||
서버 런타임 변경 후 최소 확인 절차를 작게 유지한다.
|
||||
|
||||
- [ ] [health-check] core `/api/v4/system/ping` health check를 로컬과 원격에서 확인하는 절차를 문서화한다.
|
||||
- [ ] [health-check] core `/api/v4/system/ping`, webapp 접근, db readiness를 로컬과 원격에서 확인하는 절차를 문서화한다.
|
||||
- [ ] [push-proxy-check] push-proxy가 core에서 참조 가능한 위치에 뜨는지 확인하는 smoke 기준을 정한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
|
@ -62,13 +67,13 @@ local과 원격 Docker에서 같은 shape로 서버 런타임을 올릴 수 있
|
|||
## 범위 제외
|
||||
|
||||
- nginx/domain 연결, TLS, production hardening은 이 Milestone의 필수 범위가 아니다.
|
||||
- 서버 이미지를 nexo 자체 빌드 이미지로 바꾸는 작업은 별도 결정 후 진행한다.
|
||||
- 서버/front/push-proxy를 nexo 자체 deep fork 이미지로 바꾸는 작업은 별도 결정 후 진행한다.
|
||||
- 기존 운영 중인 다른 compose 서비스와의 병합은 이 Milestone에서 자동으로 하지 않는다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `services/core/compose/`, `services/core/UPSTREAM.md`
|
||||
- 표준선(선택): compose는 core service 내부에 두고, 별도 `infra/` 모듈을 만들지 않는다
|
||||
- 관련 경로: `services/core/compose/`, `services/core/UPSTREAM.md`, `services/core/server/`, `services/core/webapp/`
|
||||
- 표준선(선택): compose는 core service 내부에 두고, server/webapp/push-proxy는 upstream-followable runtime으로 유지하며 별도 `infra/` 모듈은 만들지 않는다
|
||||
- 선행 작업: core compose 원격 테스트 배치
|
||||
- 후속 작업: 서버 커스터마이징 경계, 운영 모델
|
||||
- 후속 작업: 업스트림 팔로잉 기준선, CI/CD와 운영 업데이트 루프
|
||||
- 확인 필요: 원격 노출 방식과 push credential 분리 방식
|
||||
|
|
|
|||
31
agent-ops/roadmap/phase/upstream-runtime/PHASE.md
Normal file
31
agent-ops/roadmap/phase/upstream-runtime/PHASE.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# Phase: 업스트림 런타임 운영화
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 목표
|
||||
|
||||
Mattermost server, webapp, push-proxy를 nexo의 upstream-followable 메시징 런타임으로 유지한다.
|
||||
보안/버그/기능 업데이트를 계속 흡수할 수 있도록 baseline 기록, patch 경계, CI/CD, 배포 검증, 이슈 대응 루프를 만든다.
|
||||
|
||||
## Milestone 흐름
|
||||
|
||||
완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 `milestones/` 경로를 가리킨다.
|
||||
완료, 검토중, 진행중, 계획, 스케치 순서로 두어 아래로 갈수록 미래 작업에 가까워지게 정렬한다.
|
||||
스케치 Milestone은 아직 구현 가능한 계획이 아니므로 계획 Milestone보다 아래에 둔다.
|
||||
|
||||
- [계획] 업스트림 팔로잉 기준선
|
||||
- 경로: `agent-ops/roadmap/phase/upstream-runtime/milestones/upstream-following.md`
|
||||
- 요약: server/webapp/push-proxy의 upstream baseline, patch 경계, update 판단 기준을 정한다.
|
||||
- [계획] CI/CD와 운영 업데이트 루프
|
||||
- 경로: `agent-ops/roadmap/phase/upstream-runtime/milestones/cicd-operations.md`
|
||||
- 요약: upstream update, compose 배포, 검증 실패 이슈화를 반복 가능한 파이프라인으로 만든다.
|
||||
|
||||
## Phase 경계
|
||||
|
||||
- `services/core/server`, `services/core/webapp`, push-proxy 연동은 upstream-owned runtime으로 취급한다.
|
||||
- upstream 코드의 대량 rename, deep fork, 제품 UI 재작성은 별도 결정 전 진행하지 않는다.
|
||||
- `services/core/webapp`은 기본 메시지 앱 또는 reference front로 유지하되, nexo embedded SDK와 책임을 섞지 않는다.
|
||||
- `packages/messaging_flutter`는 nexo-owned embedded SDK이며 Mattermost mobile code를 팔로잉하는 대상이 아니다.
|
||||
- nexo 변경은 compose, docs, CI/CD, patch inventory, 얇은 branding/compatibility layer에 우선 둔다.
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
# Milestone: CI/CD와 운영 업데이트 루프
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-ops/roadmap/ROADMAP.md`
|
||||
- Phase: `agent-ops/roadmap/phase/upstream-runtime/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
Mattermost server/webapp/push-proxy update와 nexo Flutter SDK 검증을 반복 가능한 CI/CD와 운영 runbook으로 연결한다.
|
||||
upstream 업데이트에 따른 이슈를 빠르게 분류하고, 수정/보류/rollback 결정을 남길 수 있는 흐름을 만든다.
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- 없음
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 잠금
|
||||
- 결정 필요:
|
||||
- [ ] CI/CD 실행 위치를 GitHub Actions, 자체 runner, 원격 테스트 서버 중 어디에 둘지 결정한다.
|
||||
- [ ] production-like 배포 대상과 secret 보관 방식을 결정한다.
|
||||
- 결정 완료:
|
||||
- [x] 2026-05-27: upstream update를 쉽게 따라가기 위한 CI/CD와 이슈 대응 루프를 프로젝트 방향성에 포함한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- workspace `bin/test`, `bin/lint`, `bin/build` 기반 기본 검증
|
||||
- optional Go test/vet/build와 webapp/npm 검증
|
||||
- compose smoke, server ping, webapp 접근, push-proxy smoke
|
||||
- Flutter SDK Dart/integration/Android native test
|
||||
- upstream update 실패 이슈화, rollback, release note 흐름
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [ci] Continuous verification
|
||||
|
||||
upstream-followable runtime과 nexo SDK를 같은 변경 흐름에서 검증한다.
|
||||
|
||||
- [ ] [workspace-checks] CI에서 `bin/test`, `bin/lint`, `bin/build`를 실행하고 skip된 도구를 보고하는 기준을 만든다.
|
||||
- [ ] [core-checks] optional Go test/vet/build와 webapp 검증을 upstream update 또는 core 변경 시 실행하는 기준을 만든다.
|
||||
- [ ] [compose-smoke] compose로 core, webapp, db, push-proxy를 올리고 최소 smoke를 확인하는 CI 또는 원격 검증 흐름을 만든다.
|
||||
- [ ] [sdk-checks] Flutter SDK Dart test, client integration test, Android native unit test를 환경별로 나누어 실행하는 기준을 만든다.
|
||||
|
||||
### Epic: [cd] Deployment loop
|
||||
|
||||
업데이트와 배포 실패가 추적 가능한 이슈로 남도록 운영 루프를 만든다.
|
||||
|
||||
- [ ] [update-branch] Mattermost server/webapp/push-proxy baseline update용 branch, diff, patch inventory 절차를 정리한다.
|
||||
- [ ] [deploy-pipeline] dev/test/production-like compose 배포, secret 주입, rollback 절차를 정리한다.
|
||||
- [ ] [issue-loop] upstream update 실패를 server, webapp, push-proxy, SDK contract, infra 중 하나로 분류하고 후속 이슈로 남기는 절차를 만든다.
|
||||
- [ ] [release-note] server/front/push-proxy baseline과 Flutter SDK compatibility를 한 번에 볼 수 있는 release note 기준을 만든다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- production hardening 전체 구현은 배포 대상과 secret 정책 결정 전까지 진행하지 않는다.
|
||||
- 외부 공개용 landing page나 marketing site는 포함하지 않는다.
|
||||
- billing, organization management, 별도 admin console은 포함하지 않는다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `.github/`, `bin/`, `services/core/`, `services/core/compose/`, `packages/messaging_flutter/`, `apps/client/`, `docs/`
|
||||
- 표준선(선택): 먼저 private/internal deployment loop를 만들고, runner와 secret 정책이 확정되면 production-like CD로 확장한다
|
||||
- 선행 작업: 업스트림 팔로잉 기준선
|
||||
- 후속 작업: 운영 runbook, release/versioning 고도화
|
||||
- 확인 필요: CI/CD 실행 위치와 production-like 배포 대상
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
# Milestone: 업스트림 팔로잉 기준선
|
||||
|
||||
## 위치
|
||||
|
||||
- Roadmap: `agent-ops/roadmap/ROADMAP.md`
|
||||
- Phase: `agent-ops/roadmap/phase/upstream-runtime/PHASE.md`
|
||||
|
||||
## 목표
|
||||
|
||||
Mattermost server, webapp, push-proxy를 nexo runtime으로 계승하면서도 upstream update를 계속 따라가기 쉬운 기준을 만든다.
|
||||
서버/front/push-proxy는 deep fork보다 baseline 추적과 얇은 patch를 우선하고, Flutter SDK는 별도 nexo-owned surface로 분리한다.
|
||||
|
||||
## 상태
|
||||
|
||||
[계획]
|
||||
|
||||
## 승격 조건
|
||||
|
||||
- 없음
|
||||
|
||||
## 구현 잠금
|
||||
|
||||
- 상태: 해제
|
||||
- 결정 필요:
|
||||
- 없음
|
||||
- 결정 완료:
|
||||
- [x] 2026-05-27: Mattermost server, webapp, push-proxy는 upstream-followable runtime으로 유지한다.
|
||||
- [x] 2026-05-27: Flutter SDK Android 구현은 Mattermost mobile code를 팔로잉하지 않고 nexo-owned embedded SDK로 관리한다.
|
||||
- [x] 2026-05-27: 기본 메시지 앱은 Mattermost webapp/reference front를 활용할 수 있게 유지한다.
|
||||
|
||||
## 범위
|
||||
|
||||
- `services/core/UPSTREAM.md`의 baseline 기록 방식
|
||||
- `services/core/server/`, `services/core/webapp/` update 추적 기준
|
||||
- push-proxy image/source tracking 기준
|
||||
- nexo patch, branding, compatibility layer 허용 범위
|
||||
- upstream release note, security patch, breaking change 판단 기준
|
||||
|
||||
## 기능
|
||||
|
||||
### Epic: [baseline] Baseline tracking
|
||||
|
||||
server/webapp/push-proxy가 어떤 upstream 버전을 기준으로 움직이는지 추적 가능하게 만든다.
|
||||
|
||||
- [ ] [source-baseline] server와 webapp의 upstream tag/commit, 적용 patch, nexo-local 변경 범위를 기록하는 기준을 정리한다.
|
||||
- [ ] [push-proxy-baseline] push-proxy를 image-only로 추적할지 source mirror/fork를 둘지 판단 기준과 현재 선택을 문서화한다.
|
||||
- [ ] [release-watch] Mattermost monthly/ESR release, security patch, push-proxy update를 확인하는 주기와 담당 문서를 정리한다.
|
||||
|
||||
### Epic: [patch-policy] Patch boundary
|
||||
|
||||
nexo 변경이 upstream merge를 어렵게 만들지 않도록 허용 경계를 만든다.
|
||||
|
||||
- [ ] [thin-branding] webapp은 기본 메시지 앱/reference front로 유지하고, branding과 기능 숨김은 얇은 patch로 제한하는 기준을 정리한다.
|
||||
- [ ] [no-deep-rename] server/webapp/push-proxy upstream-owned 코드의 대량 rename과 deep fork를 금지하고 예외 조건을 문서화한다.
|
||||
- [ ] [feature-triage] upstream 새 기능을 keep/hide/defer/remove 후보로 분류하는 기준을 정리한다.
|
||||
|
||||
## 완료 리뷰
|
||||
|
||||
- 상태: 없음
|
||||
- 요청일: 없음
|
||||
- 완료 근거: 없음
|
||||
- 리뷰 필요:
|
||||
- [ ] 사용자가 완료 결과를 확인했다
|
||||
- [ ] archive 이동을 승인했다
|
||||
- 리뷰 코멘트: 없음
|
||||
|
||||
## 범위 제외
|
||||
|
||||
- 실제 server/webapp/push-proxy 코드 병합이나 대규모 fork 변경은 이 Milestone에서 수행하지 않는다.
|
||||
- nexo 전용 full web client 구현은 포함하지 않는다.
|
||||
- Flutter SDK API 구현 변경은 메시징 런타임 표준화 Phase에서 다룬다.
|
||||
|
||||
## 작업 컨텍스트
|
||||
|
||||
- 관련 경로: `services/core/`, `services/core/UPSTREAM.md`, `services/core/compose/`, `packages/messaging_flutter/`
|
||||
- 표준선(선택): server/webapp/push-proxy는 upstream-followable runtime, Flutter SDK는 nexo-owned embedded SDK
|
||||
- 선행 작업: 정체성 기준선
|
||||
- 후속 작업: CI/CD와 운영 업데이트 루프, 메시징 계약 표준화
|
||||
- 확인 필요: 없음
|
||||
Loading…
Reference in a new issue