#136 배포/종료 중 녹화 중단 시 partial 녹화 파일 정책

.claude/agents/chatforyou-external-expert.md

@@ -48,6 +48,9 @@ color: orange
 | **프로젝트 적합성** | 기존 CLAUDE.md 컨벤션, 패턴과의 일관성 |
 | **통합 리스크** | 백엔드-프론트-테스트가 실제로 연결되었을 때의 위험 요소 |
 
+> **[누락 위험 렌즈 — 동시성 코드 필수 체크]** 공유 상태(Redis 키, DB row, 파일 등)를 여러 replica/스레드가 만지는 로직을 검토할 때는 "재처리 안전성(idempotency: 같은 입력 두 번 처리해도 안전한가)"과 "레이스 안전성(TOCTOU: 스캔~처리 사이 값이 다른 것으로 바뀌면 안전한가)"을 **별개 질문으로 분리해서** 확인한다. 팀이 전자만 테스트하고 이를 "동시성 검증 완료"로 보고하는 경우가 있으므로, 후자(조건 없는 blind write/delete가 스캔 시점과 다른 최신 값을 덮어쓰거나 지우는 경로)가 실제로 존재하는지 코드에서 직접 추적한다.
+> 사례(2026-07 bug_136_recording_partial_cleanup): 백엔드/QA 모두 "동일 마커 2회 처리"만 검증하고 "스캔 이후 다른 마커로 교체된 채 삭제"는 아무도 테스트하지 않아 external-expert 최초 발견 P1(마커 TOCTOU blind delete)으로 이어짐.
+
 ### 3단계: Codex 교차검증 반복 루프 (cross-model review-rework loop — MANDATORY for L3)
 
 같은 모델 계열(Claude)끼리의 검증은 블라인드 스팟이 상관관계를 가진다. 진짜 무상관 검증을 위해 OpenAI Codex 를 호출한다.

.claude/agents/chatforyou-lead.md

@@ -203,6 +203,8 @@ commit 메시지는 vault 업데이트 완료 후 추천한다.
 ## 행동 규칙
 
 - **commit / push 절대 금지** — commit 메시지 추천만 허용
+  - 브랜치 생성/분리 작업 중에도 예외 없음. 새 브랜치에 "깨끗한 base"를 만들어주려고 기존에 쌓여있던 미커밋 변경사항을 임의로 커밋하거나 push하지 않는다 — 미커밋 상태 그대로 새 브랜치를 따거나, 정리가 필요하면 반드시 유저에게 먼저 확인한다.
 - PLAN 파일 없이 팀 작업 시작 금지
 - 역할 경계를 명확히 유지 — 백엔드 코드를 직접 작성하지 않음
 - 외부 전문가의 Critical 항목은 반드시 유저에게 전달하고, 해결 방안을 팀원에게 요청한다
+- **유저가 "중간 보고 없이 끝까지 진행"을 지시한 경우에도**, Phase(00~06)를 하나 완료할 때마다 해당 plan_docs 파일에 즉시 기록한다 (풀 리포트가 아니라 상태 체크포인트 목적). 세션 리밋 등으로 팀 리더가 중간에 응답불능이 되어도, 코디네이터가 이 문서만으로 마지막 완료 Phase를 파악해 새 팀 리더를 그 지점부터 재소집할 수 있어야 한다.

.claude/agents/chatforyou-qa-expert.md

@@ -61,6 +61,12 @@ color: red
 
 > Service 단위 테스트(`@ExtendWith(MockitoExtension)`)는 백엔드 전문가 담당
 
+**동시성 테스트 시 반드시 구분할 두 질문 (하나만 검증하고 "동시성 검증 완료"로 끝내지 말 것)**:
+1. **재처리 안전성(idempotency)** — 동일한 입력(같은 마커/같은 레코드)을 두 번 처리해도 안전한가?
+2. **레이스 안전성(TOCTOU)** — 스캔/조회 시점과 실제 처리(수정·삭제) 시점 사이에 그 데이터가 다른 값으로 바뀌면 안전한가? (예: 공유 키를 여러 write 경로가 조건 없이 overwrite/blind-delete 하는 경우)
+
+1번만 테스트하고 2번을 놓치면 "동시성 검증했다"는 착시가 생긴다 — 공유 상태(Redis 키, DB row 등)를 여러 replica/스레드가 만지는 로직에서는 반드시 2번 시나리오(스캔 이후 값이 교체된 채 처리)도 별도 테스트로 재현한다.
+
 ### 테스트 네이밍
 ```
 메서드명_조건_기대결과

.claude/skills/chatforyou-dev-team.md

@@ -285,7 +285,7 @@ FAIL / BLOCKED 시:
 
 ## 팀 공통 규칙
 
-- **commit / push 절대 금지** — 모든 팀원 공통
+- **commit / push 절대 금지** — 모든 팀원 공통. 브랜치 생성/분리 작업 중에도 예외 없음(새 브랜치의 "깨끗한 base"를 위해 기존 미커밋 변경사항을 임의로 커밋·push하지 않는다 — 정리가 필요하면 유저에게 먼저 확인).
 - **파일 소유권 엄수** — 배분되지 않은 파일 수정 금지
 - **PLAN 파일 없이 시작 금지**
 - **구현 시작 전 `AGENT_GUIDE.md`와 관련 `docs/*.md` 재확인 필수**
@@ -294,6 +294,17 @@ FAIL / BLOCKED 시:
 
 ---
 
+## 팀 리더 생존 모니터링 (코디네이터 필수 확인)
+
+"중간 보고 생략, 끝까지 진행" 같은 지시로 팀 리더를 장시간 논스톱 실행시킬 경우, 세션/토큰 리밋으로 팀 리더가 응답불능이 될 수 있다. 코디네이터(메인 세션)는 아래를 따른다:
+
+1. 팀 리더의 `idle_notification`이 실질 내용(신규 산출물·진행 언급) 없이 반복되면, `SendMessage`로 직접 상태를 재확인한다.
+2. `SendMessage`가 "agent... not reachable" 등으로 실패하면 팀 리더가 죽은 것으로 간주한다.
+3. 이 경우 코드/문서 손실 여부부터 확인한다 — `plan_docs/00~06/[기능명].md` 중 어디까지 존재하는지, `git status`로 워킹트리 변경사항이 그대로 있는지 확인(각 Phase는 완료 즉시 문서화되므로 대부분 안전하게 보존되어 있다).
+4. 유실이 없으면 새 `chatforyou-lead`를 재소집하되, **완료된 Phase는 재작업시키지 말고** 마지막 완료 Phase 다음 단계부터 이어서 진행하도록 명시적으로 지시한다.
+
+---
+
 ## AGENT_GUIDE Compliance Gate
 
 이 skill을 통해 시작하는 모든 작업에도 `AGENT_GUIDE.md`의 Pre-Implementation Compliance Gate가 동일하게 적용된다.

.codex/agents/chatforyou-external-expert.md

@@ -59,6 +59,10 @@ color: orange
 | **프로젝트 적합성** | 기존 AGENT_GUIDE.md 컨벤션, 패턴과의 일관성 |
 | **통합 리스크** | 백엔드-프론트-테스트가 실제로 연결되었을 때의 위험 요소 |
 
+> **[누락 위험 렌즈 — 동시성 코드 필수 체크]** idempotency(같은 입력 재처리 안전성)와 TOCTOU(스캔 후 처리 시점 상태 변경 안전성)를 별도 질문으로 분리해 검토한다. 한쪽만 검증된 경우 "동시성 검증 완료"로 인정하지 않는다.
+>
+> 사례(2026-07 `bug_136_recording_partial_cleanup`): 같은 partial marker를 2회 처리하는 idempotency 테스트는 있었지만, 마커 스캔 후 같은 Redis key가 새 `recordingId`로 교체된 뒤 blind delete 하는 TOCTOU 경로가 누락될 수 있었다. cleanup/batch/Redis marker/TTL/lock 관련 리뷰에서는 "현재 값이 아직 내가 스캔한 값인가?"를 반드시 확인한다.
+
 ### 3단계: Claude 교차검증 반복 루프 (cross-model review-rework loop — MANDATORY for L3)
 
 Codex host 의 외부 모델은 Claude다. 단발성 1회 검토가 아니라, **검토 → 분류 → 수정 → 재검토** 를 자동 반복하는 루프다.

.codex/agents/chatforyou-lead.md

@@ -208,6 +208,8 @@ commit 메시지는 vault 업데이트 완료 후 추천한다.
 ## 행동 규칙
 
 - **commit / push 절대 금지** — commit 메시지 추천만 허용
+  - 브랜치 생성/분리 작업 중에도 예외 없음. 새 브랜치에 "깨끗한 base"를 만들어주려고 기존에 쌓여있던 미커밋 변경사항을 임의로 커밋하거나 push하지 않는다 — 미커밋 상태 그대로 새 브랜치를 따거나, 정리가 필요하면 반드시 유저에게 먼저 확인한다.
 - PLAN 파일 없이 팀 작업 시작 금지
 - 역할 경계를 명확히 유지 — 백엔드 코드를 직접 작성하지 않음
 - 외부 전문가의 Critical 항목은 반드시 유저에게 전달하고, 해결 방안을 팀원에게 요청한다
+- **유저가 "중간 보고 없이 끝까지 진행"을 지시한 경우에도**, Phase(00~06)를 하나 완료할 때마다 해당 `plan_docs` 파일에 즉시 기록한다. 중간 대화 보고를 생략할 수는 있어도 문서 체크포인트는 생략하지 않는다.

.codex/agents/chatforyou-qa-expert.md

@@ -66,6 +66,12 @@ color: red
 
 > Service 단위 테스트(`@ExtendWith(MockitoExtension)`)는 백엔드 전문가 담당
 
+**동시성 테스트 시 반드시 구분할 두 질문 (하나만 검증하고 "동시성 검증 완료"로 끝내지 말 것)**:
+1. **재처리 안전성(idempotency)** — 같은 작업/마커/이벤트를 2번 처리해도 결과가 안전한가?
+2. **레이스 안전성(TOCTOU)** — 스캔한 상태와 실제 처리 시점의 현재 상태가 달라졌을 때도 안전한가? 특히 `scan -> file delete/log -> marker delete` 같은 흐름에서 현재 소유자/식별자가 바뀌었는지 재검증하는가?
+
+1번만 테스트하고 2번을 놓치면 "동일 입력 재처리"는 안전하지만 "중간에 새 값으로 교체된 상태"를 깨뜨릴 수 있다. cleanup/batch/Redis marker/lock/TTL 관련 코드는 두 질문을 별도 케이스로 확인한다.
+
 ### 테스트 네이밍
 ```
 메서드명_조건_기대결과

.codex/skills/chatforyou-dev-team/SKILL.md

@@ -302,7 +302,7 @@ STEP 3 QA로 넘어가기 전에 아래 항목이 모두 충족되어야 한다:
 
 ## 팀 공통 규칙
 
-- **commit / push 절대 금지** — 모든 팀원 공통
+- **commit / push 절대 금지** — 모든 팀원 공통. 브랜치 생성/분리 작업 중에도 예외 없음(새 브랜치의 "깨끗한 base"를 위해 기존 미커밋 변경사항을 임의로 커밋·push하지 않는다 — 정리가 필요하면 유저에게 먼저 확인).
 - **파일 소유권 엄수** — 배분되지 않은 파일 수정 금지
 - **PLAN 파일 없이 시작 금지**
 - **구현 시작 전 `AGENT_GUIDE.md`와 관련 `docs/*.md` 재확인 필수**
@@ -311,3 +311,14 @@ STEP 3 QA로 넘어가기 전에 아래 항목이 모두 충족되어야 한다:
 - TODO 체크박스는 대응 작업과 결정론 검증 evidence 가 실제로 완료된 뒤에만 `[x]` 로 표시
 - Phase 03 종료와 Phase 05 진입 전 `scripts/verify-changes.sh` 결과를 기록한다 (`docs/agent/verification-protocol.md`)
 - custom agent 위임 시 `.codex/config.toml` 등록 정보와 `.codex/agents/*.toml` 설정을 source of truth로 사용
+
+---
+
+## 팀 리더 생존 모니터링 (코디네이터 필수 확인)
+
+"중간 보고 생략, 끝까지 진행" 같은 지시로 팀 리더를 장시간 논스톱 실행시킬 경우, 세션/토큰 리밋으로 팀 리더가 응답불능이 될 수 있다. 코디네이터(메인 세션)는 아래를 따른다:
+
+1. 팀 리더의 `idle_notification`이 실질 내용(신규 산출물·진행 언급) 없이 반복되면, `SendMessage`로 직접 상태를 재확인한다.
+2. `SendMessage`가 "agent ... not reachable" 등으로 실패하면 팀 리더가 죽은 것으로 간주한다.
+3. 이 경우 코드/문서 손실 여부부터 확인한다 — `plan_docs/00~06/[기능명].md` 중 어디까지 존재하는지, `git status`로 워킹트리 변경사항이 그대로 있는지 확인한다. 각 Phase는 완료 즉시 문서화되어야 하므로 대부분 안전하게 보존되어 있어야 한다.
+4. 유실이 없으면 새 `chatforyou-lead`를 재소집하되, **완료된 Phase는 재작업시키지 말고** 마지막 완료 Phase 다음 단계부터 이어서 진행하도록 명시적으로 지시한다.

.github/workflows/GitAction-k8s-deploy.yml

@@ -2,7 +2,7 @@ name: CI/CD Pipeline with GitHub Actions for K8S
 
 on:
   push:
-    branches: [ "infra/cicd-test",  "chatforyou_v2"]
+    branches: [ "infra/cicd-test",  "chatforyou_v2", "bug/136"]
 #    branches: [ "master-webrtc-catchmind", "infra/cicd-test" ]
 #  pull_request:
 #    branches: [ "master" ]