.gitea/PULL_REQUEST_TEMPLATE.md

@@ -8,6 +8,11 @@
 - TASK: `TASK-...`
 - TEST: `TEST-...`
 
+## Ticket Stage
+
+- Current stage: `Implemented` / `Integrated` / `Observed` / `Accepted`
+- Previous stage evidence link:
+
 ## Main -> Verifier Directive Contract
 
 - Scope: 대상 요구사항/코드/로그 경로
@@ -36,3 +41,7 @@
 - 모니터링 로그 경로:
 - 이상 징후/이슈 링크:
 
+## Approval Gate
+
+- [ ] Static Verifier approval comment linked
+- [ ] Runtime Verifier approval comment linked

docs/ouroboros/50_tpm_control_protocol.md

@@ -121,6 +121,7 @@ Control checks:
 - Verifier가 `Coverage Matrix`(`REQ/TASK/TEST` x `PASS/FAIL/NOT_OBSERVED`) 첨부
 - `NOT_OBSERVED` 항목 수가 0인지 확인(0이 아니면 Gate 실패)
 - Runtime Verifier가 스테이징/실운영 모니터링 계획 승인
+- 정적 Verifier 승인 + Runtime Verifier 승인 2개 모두 확인
 - 산출물: 수용 승인 레코드
 
 ### Phase 5: Release and Post-Release Control
@@ -160,6 +161,15 @@ TPM 티켓 운영 규칙:
 - PM/TPM/Dev/Reviewer/Verifier/Runtime Verifier는 주요 의사결정 시점마다 PR 코멘트를 남겨 결정 근거를 추적 가능 상태로 유지한다.
 - PM/TPM/Dev/Reviewer/Verifier/Runtime Verifier는 이슈/PR/코멘트 조작 전에 `docs/commands.md`와 `docs/workflow.md`의 Gitea 트러블슈팅 섹션을 선참조해야 한다.
 - 저장소 협업에서 GitHub CLI(`gh`) 사용은 금지하며, Gitea 작업은 `tea`(필요 시 문서화된 API fallback)만 허용한다.
+- 재발 방지/운영 규칙 변경이 합의되면, 기능 구현 이전에 process 티켓을 먼저 생성/머지해야 한다.
+- process 티켓 미반영 상태에서 구현 티켓 진행 시 TPM이 즉시 `BLOCKED` 처리한다.
+
+티켓 성숙도 단계 (Mandatory):
+- `Implemented`: 코드/문서 변경 완료
+- `Integrated`: 호출 경로/파이프라인 연결 확인
+- `Observed`: 런타임/실행 증적 확보
+- `Accepted`: Verifier + Runtime Verifier 승인 완료
+- 단계는 순차 전진만 허용되며, 단계 점프는 허용되지 않는다.
 
 브랜치 운영 규칙:
 - TPM은 각 티켓에 대해 `ticket temp branch -> program feature branch` PR 경로를 지정한다.

docs/ouroboros/60_repo_enforcement_checklist.md

@@ -49,6 +49,7 @@ Updated: 2026-02-26
 - 이슈 연결(`Closes #N`) 존재
 - PR 본문에 `REQ-*`, `TASK-*`, `TEST-*` 매핑 표 존재
 - Main -> Verifier Directive Contract(범위/방법/합격/실패/미관측/증적 형식) 기재
+- process-change-first 대상이면 process 티켓 PR이 선머지됨
 - `src/core/risk_manager.py` 변경 없음
 - 주요 의사결정 체크포인트(DCP-01~04) 중 해당 단계 Main Agent 확인 기록 존재
 - 주요 의사결정(리뷰 지적/수정 합의/검증 승인)에 대한 에이전트 PR 코멘트 존재
@@ -62,6 +63,8 @@ Updated: 2026-02-26
 - `gh` CLI 미사용, `tea` 사용 증적 존재
 - Verifier `Coverage Matrix` 첨부(PASS/FAIL/NOT_OBSERVED)
 - `NOT_OBSERVED` 항목 0 확인(0이 아니면 머지 금지)
+- 티켓 단계 기록(`Implemented` -> `Integrated` -> `Observed` -> `Accepted`) 존재
+- 정적 Verifier 승인 + Runtime Verifier 승인 2개 확인
 
 ## 5) 감사 추적
 

docs/workflow.md

@@ -167,6 +167,28 @@ Use `run_in_background=True` for independent tasks that don't block subsequent w
 - `NOT_OBSERVED`는 운영상 `FAIL`과 동일하게 처리
 - `NOT_OBSERVED`가 하나라도 있으면 승인/머지 금지
 
+### Process-Change-First Rule (Mandatory)
+
+재발 방지/운영 규칙 변경이 결정되면, 기능 구현 티켓보다 먼저 서버(feature branch)에 반영해야 한다.
+
+- 순서: `process ticket merge` -> `implementation ticket start`
+- process ticket 미반영 상태에서 기능 티켓 코딩/머지 금지
+- 세션 전환 시에도 동일 규칙 유지
+
+### Ticket Maturity Stages (Mandatory)
+
+모든 티켓은 아래 4단계를 순서대로 통과해야 한다.
+
+1. `Implemented`: 코드/문서 변경 완료
+2. `Integrated`: 호출 경로/파이프라인 연결 완료
+3. `Observed`: 런타임/실행 증적 확보 완료
+4. `Accepted`: 정적 Verifier + Runtime Verifier 승인 완료
+
+강제 규칙:
+- 단계 점프 금지 (예: Implemented -> Accepted 금지)
+- `Observed` 전에는 완료 선언 금지
+- `Accepted` 전에는 머지 금지
+
 ## Code Review Checklist
 
 **CRITICAL: Every PR review MUST verify plan-implementation consistency.**
@@ -204,3 +226,6 @@ Before approving any PR, the reviewer (human or agent) must check ALL of the fol
 - [ ] `gh` 명령을 사용하지 않고 `tea`(또는 허용된 Gitea API fallback)만 사용했다
 - [ ] Main -> Verifier 지시가 Directive Contract 6개 항목을 모두 포함한다
 - [ ] Verifier 결과에 `Coverage Matrix`(PASS/FAIL/NOT_OBSERVED)가 있고, `NOT_OBSERVED=0`이다
+- [ ] Process-change-first 대상이면 해당 process PR이 먼저 머지되었다
+- [ ] 티켓 단계가 `Implemented -> Integrated -> Observed -> Accepted` 순서로 기록되었다
+- [ ] 정적 Verifier와 Runtime Verifier 승인 코멘트가 모두 존재한다