mattermost-push-plugin/agent-ops/roadmap/archive/phase/validation-foundation/milestones/project-operating-contract.md

3.3 KiB

Milestone: 프로젝트 운영 계약 정리

위치

  • Roadmap: agent-ops/roadmap/ROADMAP.md
  • Phase: agent-ops/roadmap/phase/validation-foundation/PHASE.md

목표

이 프로젝트가 여러 소비 프로젝트의 공통 알림 기반이 된다는 목적을 문서와 규칙으로 명확히 한다. 플러그인 repository와 소비 프로젝트 사이의 책임 경계를 고정하고, 이후 작업자가 같은 기준으로 판단할 수 있게 한다.

상태

[완료]

구현 잠금

  • 상태: 해제
  • 결정 필요: 없음

범위

  • 루트 README의 프로젝트 목적, 사용 방식, 검증 전략 정리
  • example/ 테스트 하네스 목적 문서화
  • build output, IDE 설정, generated 파일 제외 기준 정리
  • agent-ops 프로젝트 규칙과 로드맵의 책임 경계 정렬

필수 기능

Epic: [docs] 프로젝트 목적 문서화

공유 플러그인으로서의 목적과 소비 프로젝트의 책임 경계를 문서화한다.

  • [root-readme] 루트 README에 프로젝트 목표, host app 책임, Android 주의사항, 제한사항을 정리한다
  • [example-readme] example/README.md에 테스트 하네스 목적과 유지 규칙을 정리한다
  • [smoke-checklist] 수동 smoke checklist가 FCM, 알림, ACK, reply, dismiss 경로를 포함하게 한다

Epic: [repo-hygiene] Repository 운영 기준

반복 작업 중 생성물이 source control에 섞이지 않게 한다.

  • [gitignore] Flutter, Android, iOS/macOS, Firebase, local env 생성물을 .gitignore에 반영한다
  • [tracked-noise] 이미 추적 중인 파일과 새로 ignore되는 파일의 경계를 확인한다
  • [rules-align] 프로젝트 규칙과 README의 책임 경계가 충돌하지 않게 맞춘다

완료 기준

  • README에서 이 repository의 목적이 "공통 Mattermost 알림 플러그인"으로 읽힌다
  • 소비 프로젝트와 plugin repository의 책임 경계가 문서에 분리되어 있다
  • example/이 독립 테스트 하네스라는 점이 문서에 명시되어 있다
  • .gitignore가 Flutter plugin, Android, iOS/macOS, Firebase 로컬 설정을 포함한다
  • 새 문서가 기존 코드의 실제 API와 충돌하지 않는다

완료 리뷰

  • 상태: 승인됨
  • 요청일: 2026-05-25
  • 완료 근거: README.md에 프로젝트 목적, host app 책임, Android 주의사항, 테스트 전략, manual smoke checklist가 정리되어 있고, example/README.md에 독립 테스트 하네스 목적이 명시되어 있다. .gitignore는 Flutter/Android/iOS/macOS/Firebase/local env 생성물을 포함하며, 프로젝트 규칙과 문서의 책임 경계가 충돌하지 않는다.
  • 리뷰 필요:
    • 사용자가 완료 결과를 확인했다
    • archive 이동을 승인했다
  • 리뷰 코멘트: 2026-05-25 사용자 요청으로 완료 승인 및 archive 이동 처리.

범위 제외

  • 실제 Android runtime 동작 변경
  • CI workflow 추가
  • 소비 프로젝트별 통합 문서 작성
  • 배포 채널 결정

작업 컨텍스트

  • 관련 경로: README.md, example/README.md, .gitignore, agent-ops/rules/project/rules.md
  • 표준선(선택): Flutter plugin은 root package와 example/ host app 구조를 유지한다
  • 선행 작업: 없음
  • 후속 작업: 독립 테스트 하네스 정착, 품질 게이트 자동화
  • 확인 필요: 없음