docs: enforce feature-branch team flow and mandatory runtime monitoring validation (#279)

docs/ouroboros/40_acceptance_and_test_plan.md

@@ -43,6 +43,11 @@ Updated: 2026-02-26
 - 기존 `tests/` 스위트 전량 실행
 - 신규 기능 플래그 ON/OFF 비교
 
+4. 구동/모니터링 검증 (필수)
+- 개발 완료 후 시스템을 실제 구동해 핵심 경로를 관찰
+- 필수 관찰 항목: 주문 차단 정책, Kill Switch 동작, 경보/예외 로그, 세션 전환 로그
+- Runtime Verifier 코멘트로 증적(실행 명령/요약 로그) 첨부
+
 ## 실행 명령
 
 ```bash
@@ -55,3 +60,4 @@ python3 scripts/validate_ouroboros_docs.py
 - 문서 검증 실패 시 구현 PR 병합 금지
 - `REQ-*` 변경 후 테스트 매핑 누락 시 병합 금지
 - 회귀 실패 시 원인 모듈 분리 후 재검증
+- 구동/모니터링 증적 누락 시 검증 승인 금지

docs/ouroboros/50_tpm_control_protocol.md

@@ -150,6 +150,10 @@ TPM 티켓 운영 규칙:
 - PR 본문에는 TPM이 지정한 우선순위와 범위가 그대로 반영되어야 한다.
 - 우선순위 변경은 TPM 제안 + Main Agent 승인으로만 가능하다.
 
+브랜치 운영 규칙:
+- TPM은 각 티켓에 대해 `ticket temp branch -> program feature branch` PR 경로를 지정한다.
+- 티켓 머지 대상은 항상 program feature branch이며, `main`은 최종 통합 단계에서만 사용한다.
+
 ## Runtime Verification Protocol
 
 - Runtime Verifier는 테스트 통과 이후 실제 동작(스테이징/실운영)을 모니터링한다.
@@ -159,6 +163,10 @@ TPM 티켓 운영 규칙:
 - 이슈 클로즈 규칙:
   - Dev 수정 완료 + Verifier 재검증 통과 + Runtime Verifier 재관측 정상
   - 최종 클로즈 승인자는 Main Agent
+- 개발 완료 필수 절차:
+  - 시스템 실제 구동(스테이징/로컬 실운영 모드) 실행
+  - 모니터링 체크리스트(핵심 경보/주문 경로/예외 로그) 수행
+  - 결과를 티켓/PR 코멘트에 증적으로 첨부하지 않으면 완료로 간주하지 않음
 
 ## Server Reflection Rule (No-Merge by Default)
 

docs/ouroboros/60_repo_enforcement_checklist.md

@@ -50,10 +50,12 @@ Updated: 2026-02-26
 - PR 본문에 `REQ-*`, `TASK-*`, `TEST-*` 매핑 표 존재
 - `src/core/risk_manager.py` 변경 없음
 - 주요 의사결정 체크포인트(DCP-01~04) 중 해당 단계 Main Agent 확인 기록 존재
+- 티켓 PR의 base가 `main`이 아닌 program feature branch인지 확인
 
 자동 점검:
 - 문서 검증 스크립트 통과
 - 테스트 통과
+- 개발 완료 시 시스템 구동/모니터링 증적 코멘트 존재
 
 ## 5) 감사 추적
 
@@ -92,3 +94,9 @@ Updated: 2026-02-26
 - 서버 반영은 `브랜치 푸시 + PR 코멘트(리뷰/논의/검증승인)`까지를 기본으로 한다.
 - 기본 규칙에서 `tea pulls merge` 실행은 금지한다.
 - 사용자 명시 승인 시에만 예외적으로 머지를 허용한다(예외 근거를 PR 코멘트에 기록).
+
+## 10) 최종 main 병합 조건
+
+- 모든 티켓이 program feature branch로 병합 완료
+- Runtime Verifier의 구동/모니터링 검증 완료
+- 사용자 최종 승인 코멘트 확인 후에만 `feature -> main` PR 머지 허용

docs/workflow.md

@@ -5,14 +5,23 @@
 **CRITICAL: All code changes MUST follow this workflow. Direct pushes to `main` are ABSOLUTELY PROHIBITED.**
 
 1. **Create Gitea Issue First** — All features, bug fixes, and policy changes require a Gitea issue before any code is written
-2. **Create Feature Branch** — Branch from `main` using format `feature/issue-{N}-{short-description}`
-   - After creating the branch, run `git pull origin main` and rebase to ensure the branch is up to date
-3. **Implement Changes** — Write code, tests, and documentation on the feature branch
-4. **Create Pull Request** — Submit PR to `main` branch referencing the issue number
-5. **Review & Merge** — After approval, merge via PR (squash or merge commit)
+2. **Create Program Feature Branch** — Branch from `main` for the whole development stream
+   - Format: `feature/{epic-or-stream-name}`
+3. **Create Ticket Temp Branch** — Branch from the program feature branch per ticket
+   - Format: `feature/issue-{N}-{short-description}`
+4. **Implement Per Ticket** — Write code, tests, and documentation on the ticket temp branch
+5. **Create Pull Request to Program Feature Branch** — `feature/issue-N-* -> feature/{stream}`
+6. **Review/Verify and Merge into Program Feature Branch**
+7. **Final Integration PR to main** — Only after all ticket stages complete and explicit user approval
 
 **Never commit directly to `main`.** This policy applies to all changes, no exceptions.
 
+## Branch Strategy (Mandatory)
+
+- Team operation default branch is the **program feature branch**, not `main`.
+- Ticket-level development happens only on **ticket temp branches** cut from the program feature branch.
+- Until final user sign-off, `main` merge is prohibited.
+
 ## Gitea CLI Formatting Troubleshooting
 
 Issue/PR 본문 작성 시 줄바꿈(`\n`)이 문자열 그대로 저장되는 문제가 반복될 수 있다. 원인은 `-d "...\n..."` 형태에서 쉘/CLI가 이스케이프를 실제 개행으로 해석하지 않기 때문이다.