mutual-monitoring

name	mutual-monitoring
description	에이전트 팀의 Mutual Performance Monitoring(상호 성과 모니터링)과 Backup Behavior(백업 행동)를 수행하는 스킬. 팀원 산출물을 Shared Mental Model 기준으로 교차 검증하고, 경계면 불일치·목표 이탈을 감지하며, 정체·과부하·실패한 팀원을 백업한다. 'QA', '교차 검증', '경계면 점검', '정합성 확인', '팀원 백업', '재할당', '드리프트 감지' 작업에 반드시 트리거. Team Big Five 구성요소 2·3.

Mutual Performance Monitoring & Backup — 교차 검증과 백업

Team Big Five의 2번(상호 성과 모니터링)·3번(백업 행동) 구성요소. 팀원들이 서로의 작업을 관찰해 실수를 잡고, 막힌 팀원의 일을 대신 수행한다. performance-monitor 에이전트가 전담하되, 모든 contributor도 자기 인접 산출물을 부분적으로 모니터링한다.

왜 필요한가

혼자 일하는 에이전트는 자기 오류를 못 본다. 특히 경계면 — 팀원 A의 출력이 팀원 B의 입력이 되는 지점 — 에서 각자는 "내 쪽은 맞다"고 믿지만 둘이 안 맞는다. 상호 모니터링은 이 경계면을 교차로 비교해 숨은 버그를 드러낸다. 백업은 한 팀원의 정체가 팀 전체를 멈추지 않게 한다.

Part 0: 실행 검증 (코드 과제 — 텍스트 대조보다 먼저)

코드 과제에서 "두 산출물이 markdown 상으로 정합해 보임"은 "동작함"이 아니다. 경계면 텍스트 대조 전에 반드시 실행 검증을 먼저 한다:

• 해당 모듈/통합 트리의 빌드 · 타입체크 · 테스트 · 린트를 실제 실행하고 exit code를 기록한다.
• 하나라도 0이 아니면 즉시 BLOCKED/DRIFT — 텍스트 대조로 넘어가지 않는다.
• 보고서에 execution: {build, typecheck, test, lint} pass/fail + 출력 꼬리를 인용한다.
• 회귀 가드: Phase 1에서 잡은 baseline(기존 통과 테스트)이 깨지면 DRIFT. 통과하던 테스트는 절대 깨지면 안 된다.

산문 과제(리서치·문서·창작·마케팅)에는 실행할 스크립트가 없다 → Part 1의 정독 대조로 직행.

Part 1: Mutual Performance Monitoring (교차 검증)

핵심 원칙: "존재 확인"이 아니라 "경계면 교차 비교"

산출물이 생성되었는지 확인하는 것은 검증이 아니다. 의존 관계로 연결된 두 산출물을 함께 읽고, SMM의 해당 계약(스키마 또는 스타일/사실/연속성)을 기준으로 대조한다.

나쁨: "contributor-api가 users.json 만들었음 → OK"
좋음: "users.json의 필드 {id,name} ↔ contributor-ui가 기대하는 {id,name,email}
       → email 누락. SMM 인터페이스 위반. DRIFT 플래그."
나쁨(산문): "ch.4 초고 존재 → OK"
좋음(산문): "ch.1은 주인공을 외동으로, ch.4는 여동생 등장 → SMM canon 위반. DRIFT."

과제 유형별 모니터링 체크리스트

계약은 과제마다 다르므로 무엇을 대조하는지도 다르다:

코드/설계 : I/O shape, 타입, 계약 위반, 빌드/테스트(Part 0)
리서치/분석: 주장↔출처 정합(사실 원장), 인용 정확성, 분석 단위 일관, 무근거 주장
문서/보고서: 섹션 간 용어 일관, 중복·공백, 주장-근거 연결, 독자 적합
창작     : 보이스 드리프트, 타임라인/세계관 모순(canon 위반), 플롯 홀, POV·시제 일탈, 복선 회수
마케팅   : 핵심 메시지 일관, 브랜드 보이스, 채널별 톤, CTA·클레임 일관

또한 SMM §9의 명시된 위험 가정을 능동적으로 감시한다 — 그 가정이 깨질 조짐이 보이면 DRIFT 전이라도 리더에 알린다(사전 적응).

점진적 검증 (Incremental)

전체 완성 후 1회가 아니라, 각 모듈/Phase 완료 직후 즉시 검증한다. 늦게 잡은 경계면 버그는 그 위에 쌓인 작업까지 무효화한다.

판정 체계

판정	의미	후속
OK	SMM 기준 정합 (+ 코드면 실행 통과)	통과
DRIFT	산출물이 SMM/인접 산출물과 불일치, 또는 빌드/테스트 실패	해당 팀원에 폐쇄 루프 플래그 + 수정 요청
BLOCKED	산출물 누락/깨짐/의존 미충족	백업 행동 트리거 (Part 2)

소프트 제약(SMM §6에서 [soft])의 위반은 차단 DRIFT가 아니라 **권고(FYI)**로 — 드래프트 단계에서는 보이스·플롯 탐색을 막지 않는다. 차단 DRIFT는 [hard] 제약(계약·canon·사실·빌드)에만.

플래그 형식 (_workspace/monitor/round_{N}_report.md)

## {대상 팀원 / 경계면}
- 판정: OK | DRIFT | BLOCKED
- 실행(코드): build/typecheck/test/lint = pass/fail (+출력 꼬리)
- 근거: {어느 파일 어느 부분} ↔ {SMM 어느 기준 / 어느 인접 산출물}
- 권고: {구체적 수정 방향}

Mutual Trust 보정 (Calibrated, 이진 아님)

검증 강도는 경계면의 신뢰 등급(SMM §4)에 비례한다 — 결과 영향 큰 경계면은 매 라운드 재검증, 가벼운 건 한 번만. 검증 강도를 팀원 의심이 아니라 경계면 결과 비용으로 정한다. 검증은 계약 버전에 묶이므로, 의존 계약이 갱신되면 하위 "검증됨"은 무효 → 재검증. 모든 것을 매번 재검증하면 신뢰가 무너지고 비용이 폭발한다. 신뢰하되, 비싼 경계면은 본다.

Part 2: Backup Behavior (백업 행동)

정체 vs 정상 유휴 구분 (중요)

에이전트 팀에서 팀원은 매 턴 종료 후 정상적으로 idle이 된다. idle 자체는 실패가 아니다. **정체(stall)**는 다르게 정의한다:

정체 = 해당 task가 여전히 in_progress/미claim 상태이고, 리더의 점검 주기 N회(예: 2회)에 걸쳐 TaskUpdate 변화가 없음. (단순히 idle 알림이 온 것 ≠ 정체)

이 구분이 없으면 건강한 idle 팀원에게 백업을 발동해 중복 작업이 생기거나, 진짜 데드락을 놓친다.

트리거 신호

• 위 정의의 정체 (TaskList/TaskGet로 진행 없음 확인)
• 팀원 실패/중지 (작업 미완 + 복구 불가 보고)
• 한 팀원의 작업 큐가 과도하게 쌓임 (과부하)

백업 절차

1. monitor가 정체/과부하/실패를 감지 → 리더에게 폐쇄 루프로 보고
2. 리더가 판단:
   - 유휴 팀원 있음 → 그 팀원에게 작업 재할당 (TaskUpdate owner)
   - 작업이 크면 → 분할하여 여러 팀원에 분산
   - 대체 불가 → 부분 결과 보존 후 사용자에 보고
3. 백업 팀원은 SMM을 읽고 원 담당자의 진행분(부분 산출물)을 이어받는다
4. 원 담당자가 복귀하면 SMM 결정 로그로 인수인계 상태를 공유

백업의 한계

백업은 무한 재시도가 아니다. 같은 작업이 2회 실패하면 구조적 문제(SMM 결함, 작업 정의 오류)를 의심하고 리더가 재계획(Adaptability)을 검토한다.

Part 3: 팀 성과 스코어카드 (Team Scorecard)

Big Five의 전제는 팀 성과가 측정 가능하다는 것이다. monitor는 종료 전 _workspace/monitor/scorecard.md를 작성해 팀워크 품질을 계량한다:

## 팀 스코어카드
- DRIFT 건수 (경계면별):
- 재발 DRIFT (2회+):
- BLOCKED / 백업 발동 횟수:
- 적응 체크포인트 발동 횟수:
- OK까지 라운드 수:
- 완료 기준(rubric) 충족: {N}/{전체}
- 실행 게이트(코드): build/test/lint 최종 상태

이 스코어카드는 Phase 5 디브리핑(AAR)의 원자료가 되고, 하네스 진화의 학습 신호가 된다 — 좋은 실행과 나쁜 실행을 구분하는 유일한 근거다.

왜 이렇게 하는가 (원리)

• 경계면이 버그의 집 — 단일 산출물은 각자 맞아 보인다. 교차 비교만이 불일치를 드러낸다.
• 코드는 실행해야 검증 — markdown 정합 ≠ 컴파일·테스트 통과. Part 0가 없으면 "실행 안 된 그럴듯한 코드"에 만장일치 OK가 난다.
• 일찍 잡을수록 싸다 — 점진적 검증은 잘못된 토대 위 누적 작업을 막는다.
• idle ≠ 정체 — 정상 유휴를 실패로 오인하면 중복·thrash. 정체는 task 무변화로 정의.
• 백업은 팀 지향성의 행동적 표현 — "내 일 끝났으니 끝"이 아니라 팀 목표 완수까지가 일이다.
• 반복 실패는 적응 신호 — 백업으로 안 풀리면 모니터링 데이터가 리더의 재계획 근거가 된다.
• 측정 없이 진화 없다 — 스코어카드가 팀 성과를 계량해야 무엇을 고칠지 안다.