# QC 프로세스 전면 개편: "실제로 되는지" 검증 시스템 구축

## 배경
현재 QC 프로세스의 근본적 문제:
- 코드 짜는 팀이 테스트도 짜고, QC도 같은 세션에서 실행 → 자기 편향
- "10/10 PASS"인데 실제 동작에서 버그 반복 발생
- 대시보드: stale task 22건 방치, 팀원 상태 불일치, 옛날 버전 복구 등 모두 QC 통과했지만 실제 문제
- QC가 "코드가 맞나"만 보고, "실제로 되나"를 안 봄

## 제이회장님 지시
- 에이전트 미팅 3회 이상 소집하여 심도 있는 논의
- 최대한 자세히 검토
- 우리 철학(아누 가이드, 모듈화 원칙, 3문서 시스템 등)에서 벗어나지 않는 선에서
- **"실제로 되는건지"를 볼 수 있어야 함** ← 핵심
- Phase로 나눠서 터지지 않게 구현
- 전체 Phase 한번에 진행 (한정적 핵미사일 발사 승인)

## 미팅 논의 주제 (최소 3회)

### 미팅 1: 현재 QC 프로세스 진단 + 실패 사례 분석
- 현재 QC 프로세스 전수 분석 (team_prompts.py의 셀프 QC 5항목, 마아트 서브에이전트)
- 실패 사례 수집: 어떤 버그들이 QC를 통과했는지 구체적으로 분석
  - task-188.1: 대시보드 인증 문제 → QC 미감지
  - task-189.1: 대시보드 버전 문제 → stash에서 복구 필요
  - task-191.1: stale task 22건 → 시스템 상태 검증 부재
  - task-194.1: 팀 진행 vs 팀원 유휴 불일치 → 데이터 일관성 검증 부재
- 근본 원인 분류: 테스트 커버리지 부족? 통합 검증 부재? QC 독립성 부족?

### 미팅 2: 해결 방안 설계
- "실제로 되는지" 검증 방법론:
  - API 응답 실동작 검증 (curl/httpie)
  - 데이터 소스 간 일관성 체크 (JSON 간 교차 검증)
  - UI 변경 시 API→렌더링 데이터 흐름 검증
  - 시스템 상태 검증 (프로세스, 포트, 파일 존재)
- 코딩팀 ≠ 검증팀 분리 방안:
  - 1팀 코딩 → 2팀 검증? 비용 대비 효과?
  - 자동 스크립트로 대체 가능한 범위?
  - 아누 개입 최소화 (제이회장님과 대화 블로킹 방지)
- 비용 최적화: Haiku로 가능한 검증 vs Sonnet 필요한 검증

### 미팅 3: 구현 계획 확정 + Phase 분리
- 최종 QC 프로세스 아키텍처 확정
- Phase별 구현 계획 수립 (터지지 않게 순차 진행)
- 기존 팀 프롬프트(team_prompts.py) 수정 범위 결정
- post-task 자동 검증 스크립트 설계
- 통합 검증 체크리스트 표준 정의

## 참고 파일
- 아누 가이드: `/home/jay/workspace/memory/specs/anu-guide.md`
- 현재 QC 프롬프트: `/home/jay/workspace/prompts/team_prompts.py` (_build_verification_section 함수)
- 조직 구조: `/home/jay/workspace/memory/organization-structure.json`
- 대시보드 관련 보고서들: `/home/jay/workspace/memory/reports/task-{188,189,191,194}.1.md`
- 모듈화 철학: `/home/jay/.openclaw/workspace/memory/MODULARIZATION-PHILOSOPHY.md`

## 우리 철학 (벗어나지 말 것)
- 아누 가이드: 자동 품질검사 시스템 (4대 시스템 중 하나)
- 모듈화 원칙: DRY, SOLID, 200줄 이하, 독립 실행 가능
- 목차→요약→상세: 프롬프트 폭발 방지
- 아누는 코딩 금지, 위임만 → QC도 아누가 직접 하면 안 됨
- 비용 의식: 불필요한 Opus 소모 최소화

## 한정적 핵미사일 발사 승인
- 미팅 3회 → Phase 확정 → Phase 1부터 끝까지 자율 체이닝
- 각 Phase 완료 시 간결 중간보고 (3줄 이내)
- 마지막 Phase 완료 시 전체 통합 보고
- 파일 충돌 위험 Phase 간 반드시 순차 진행