# 베타 운영 계획 (차수 19)

> 본 문서는 **계획/프로세스**다. 실제 서버 구성·인원 모집·버그 수정 실행은 별도(외부 실행).

## 1. 베타 테스트 서버 선정/구성 (#283)
- **대상**: 소규모 활성 커뮤니티 1곳(인원 ~20–50, 관리자 협조 가능).
- **구성 체크리스트**:
  - [ ] 별도 Discord 서버(또는 채널) — 운영 서버와 분리.
  - [ ] central-server 베타 인스턴스(`CENTRAL_DEV_ENABLED=false`, Postgres, 헬스 UP).
  - [ ] 봇 초대 + **길드 등록**(빠른 명령 반영, OPERATIONS §명령 등록 전략).
  - [ ] 프로바이더 2–3인 에이전트 연결(`/provider-join` → 승인 → 토큰 → 실행).
  - [ ] 모니터링: Prometheus/Grafana + 알림 웹훅(`central.alert.discord-webhook`).
- **종료 기준(Exit)**: 핵심 시나리오(아래 §4 검증) 무중단 통과 + 치명 버그 0.

## 2. 피드백 수집 채널/폼 (#286)
- **채널**: 베타 서버 `#피드백` 채널 + 봇 `/help` 안내에 링크.
- **폼 템플릿**(Google Form/Discord 게시 양식):
  ```
  - 역할: 유저 / 프로바이더 / 관리자
  - 무엇을 하려 했나:
  - 기대 동작:
  - 실제 동작(+에러 메시지/시각, 가능하면 X-Request-Id):
  - 심각도: 낮음 / 보통 / 높음 / 치명
  - 재현 빈도: 항상 / 가끔 / 1회
  ```
- request-id(#218)를 응답/로그에서 수집하면 트리아지 추적이 쉬움.

## 3. 이슈 트리아지 프로세스 (#287)
1. **수집** → GitHub Issue 로 등록(라벨: `beta`).
2. **분류**: 심각도 라벨 `sev:critical|high|medium|low` + 영역 `area:central|agent|discord|docs`.
3. **우선순위**: critical(즉시) → high(이번 베타 내) → medium(차기) → low(백로그).
4. **SLA(베타 내부)**: critical 24h 내 착수, high 3일 내.
5. **수정 흐름**: 브랜치 → 테스트 추가(회귀 방지) → PR(CODEOWNERS 리뷰) → 머지 → 베타 재배포.
6. **종결**: 보고자에게 확인 요청 후 close.

## 4. 베타 검증 시나리오(재검증용, #294 연계)
- 유저: `/ask` 왕복 성공(풀 라우팅 → 에이전트 PC → 응답).
- 프로바이더: join/approve/pause/resume/leave, `/provider-schedule` 자동 on/off.
- 관리자: 정책(채널/역할)·차단·공정성 리포트.
- 장애: 프로바이더 강제 종료 시 fallback·오프라인 알림.

## 5. 미해결(외부 실행 필요)
- 실제 서버 구성/인원 모집/버그 수정 1차(#284/#285/#288), 데모 영상(#290), 정식 배포(#297~299).