---
name: guardia-orchestrator
description: "GUARDiA ITSM 통합 오케스트레이터. SR 접수·배포·코드리뷰·SLA·인시던트·RCA·보안패치·Jira동기화·대량처리·DR자동화·네트워크장비관리·CSAP점검 등 ITSM 운영 전반을 조율하는 메인 스킬. 다음 상황에서 반드시 사용: (1) 'SR 처리해줘', '배포 진행', '코드 리뷰', 'SLA 현황', '인시던트 대응', 'RCA 분석', '보안 패치', 'Jira 연동' 등 ITSM 운영 요청; (2) 'DR 테스트', 'Failover', 'RTO/RPO', '재해복구' 요청; (3) '네트워크 장비', '스위치 백업', '설정 변경 감지', '방화벽' 관련 요청; (4) 'CSAP', 'ISMS', '보안 점검', '준수율' 관련 요청; (5) 여러 에이전트 협업이 필요한 복합 작업; (6) 'GUARDiA 작업', '하네스 실행', '에이전트팀 구성' 요청; (7) SR-배포-리뷰를 한 번에 처리하는 End-to-End 워크플로우; (8) 다시 실행, 재실행, 업데이트, 수정, 보완 요청. 단순 질문(API 경로, 모델 설명 등)은 직접 응답 가능."
---

# GUARDiA ITSM 오케스트레이터

GUARDiA ITSM의 전문 에이전트를 조율하는 통합 워크플로우.
**실행 모드: 에이전트 팀 (기본)** — 복합 작업은 TeamCreate로 팀 구성, 단순 작업은 서브 에이전트.

## 에이전트 팀 구성

| 에이전트 | 역할 | 파일 |
|---------|------|------|
| sr-manager | SR 생명주기 + 대량처리 + AI분류 | `.claude/agents/sr-manager.md` |
| code-reviewer | 코드 리뷰 (B-3) | `.claude/agents/code-reviewer.md` |
| deploy-engineer | 배포 파이프라인 + 영향분석 | `.claude/agents/deploy-engineer.md` |
| sla-guardian | SLA 모니터링 + 다중승인 | `.claude/agents/sla-guardian.md` |
| incident-responder | 인시던트 대응 + 자동RCA | `.claude/agents/incident-responder.md` |
| dr-coordinator | DR 자동화 + Failover + RTO/RPO | `.claude/agents/dr-coordinator.md` |
| network-guardian | 네트워크 장비 관리 + 설정백업 | `.claude/agents/network-guardian.md` |
| csap-auditor | CSAP/ISMS 자동 점검 + 보고서 | `.claude/agents/csap-auditor.md` |

## Phase -1: 라이선스 검증

모든 오케스트레이션 시작 전 라이선스 상태를 확인한다.

```
GET /api/license/status
→ valid: true           → 정상 진행
→ expiry_warning: true  → "⚠️ 라이선스 만료 N일 전입니다." 경고 후 진행
→ expired: true         → "❌ 라이선스가 만료되었습니다." 고지 후 제한 모드로 진행
→ activated: false      → Community 제한 모드 고지 후 진행
```

에디션별 사용 가능 기능:
| 에디션 | 사용 가능 기능 |
|--------|-------------|
| COMMUNITY | MFA만 |
| STANDARD | MFA, LDAP, PAM, AI_AGENTS |
| ENTERPRISE | 전체 (VULN_SCAN, CICD, ANALYTICS, FINOPS 포함) |

라이선스 상태는 `/api/license/status` 응답의 `limits.features` 배열로 확인한다.

## Phase 0: 컨텍스트 확인

```
_workspace/ 존재 + 부분 수정 요청 → 부분 재실행 (해당 에이전트만)
_workspace/ 존재 + 새 입력       → 새 실행 (_workspace를 _workspace_prev/로 이동)
_workspace/ 미존재               → 초기 실행
```

## Phase 1: 작업 분류 및 팀 구성

요청 유형을 파악하여 필요한 에이전트만 포함한 팀을 구성한다.

**단순 작업 (서브 에이전트 1개):**
- SR 단건 조회/상태 변경 → sr-manager만
- 빠른 보안 스캔 → code-reviewer만
- 온콜 현황 조회 → orchestrator 직접 처리

**복합 작업 (에이전트 팀):**
- SR 접수 → 코드 리뷰 → 배포: sr-manager + code-reviewer + deploy-engineer
- SLA 위반 대응: sla-guardian + sr-manager + incident-responder
- 인시던트 처리: incident-responder + sr-manager + sla-guardian

## Phase 1.5: G-1~G-12 확장 기능 워크플로우

**G-2 SR 대량처리 (sr-manager):**
```
POST /api/tasks/bulk
{ sr_ids: [...], action: "STATUS_CHANGE|ASSIGN|CLOSE|PRIORITY_CHANGE", params: {...} }
→ 100건 이내, 결과별 성공/실패 반환
```

**G-5 자동 RCA (incident-responder):**
```
POST /api/incidents/{id}/auto-rca
POST /api/problem/{prb_id}/auto-rca
→ Ollama LLM이 root_cause, prevention, confidence 생성
→ 실패 시 규칙 기반 폴백 (Fail-Safe)
```

**G-6 배포 영향 분석 (deploy-engineer):**
```
POST /api/vibe/{session_id}/impact-analysis
→ CMDB BFS 탐색 → 영향 CI·기관 목록 + 리스크 레벨 반환
→ PRD 배포 전 필수 실행
```

**G-7 AI 티켓 자동 분류 (sr-manager):**
```
SR 생성 직후 백그라운드 자동 실행
GET /api/tasks/{sr_id}/ai-suggestion → priority, category, team 제안
```

**G-9 Jira 연동 (gateway):**
```
POST /api/gateway/jira/sync/{sr_id} → Jira 이슈 생성
GET  /api/gateway/jira/status/{key} → Jira 상태 조회
POST /api/gateway/confluence/publish → KB → Confluence 발행
```

**G-11 다중승인 (sla-guardian):**
```
POST /api/approvals/{id}/delegate     → 결재 위임
POST /api/approvals/{id}/sign         → 전자서명
GET  /api/approvals/pending/overdue   → 기한초과 목록
POST /api/approvals/{id}/extend-deadline → 마감 연장
```

## Phase 2: End-to-End SR → 배포 워크플로우

```
1. sr-manager: SR 생성/조회, 우선순위 확인
   └─ 파일: _workspace/01_sr-manager_sr_info.md

2. code-reviewer: 연관 프로젝트 코드 리뷰 (병렬 실행 가능)
   └─ 빠른 스캔: POST /api/code-review/quick-scan
   └─ 심층 리뷰: POST /api/code-review (비동기, 폴링)
   └─ 파일: _workspace/02_code-reviewer_findings.json
   └─ CRITICAL 발견 시 → deploy-engineer에게 차단 신호

3. deploy-engineer: 리뷰 통과(score ≥ 60)이면 배포 진행
   └─ PRD이면 승인 요청
   └─ 파일: _workspace/03_deploy-engineer_result.md

4. sla-guardian: 배포 완료 후 SR SLA 상태 갱신
5. sr-manager: SR 상태를 COMPLETED로 변경
```

## Phase 3: 인시던트 대응 워크플로우

```
1. incident-responder: 인시던트 감지/생성, 심각도 분류
2. sla-guardian: 영향받는 SR SLA 일시 중지
3. sr-manager: 인시던트 SR 생성
4. incident-responder: 온콜 호출, 타임라인 기록, 복구 조율
5. 복구 완료 → sr-manager SR 종료, sla-guardian SLA 재개
```

## 데이터 전달 프로토콜

| 방법 | 용도 |
|------|------|
| 파일 기반 (`_workspace/`) | 대용량 결과, SR 정보, 발견 항목 |
| 메시지 기반 (SendMessage) | 실시간 상태, 차단 신호, 알림 |
| 태스크 기반 (TaskCreate) | 작업 진행상황 추적 |

파일 컨벤션: `{phase:02d}_{agent}_{artifact}.{ext}`

## 에러 핸들링

| 상황 | 처리 |
|------|------|
| code-reviewer Ollama 연결 실패 | 빠른 스캔으로 폴백, 경고와 함께 계속 |
| deploy-engineer 빌드 실패 | 재시도 1회, 실패 시 sr-manager에 보고 |
| sla-guardian API 오류 | 오류 로그 후 계속 진행 (SLA는 비차단) |
| 에이전트 응답 없음 | 30초 대기 후 재시도, 재실패 시 human escalation |

## 테스트 시나리오

### 정상 흐름: SR → 코드 리뷰 → 배포
```
입력: "SR-0042 처리하고 testcase-java-api 코드 리뷰 후 배포해줘"
예상:
  1. sr-manager가 SR-0042 조회
  2. code-reviewer가 testcase-java-api 빠른 스캔 → 심층 리뷰
  3. score ≥ 60이면 deploy-engineer 배포 진행
  4. 완료 후 SR 상태 COMPLETED
```

### 에러 흐름: 코드 리뷰 CRITICAL 발견
```
입력: "testcase-php-legacy 배포해줘"
예상:
  1. code-reviewer가 quick-scan 수행
  2. SQL 인젝션, XSS 등 CRITICAL 발견
  3. deploy-engineer에게 차단 신호
  4. 사용자에게 "CRITICAL 3건 수정 후 재요청" 안내
```