28d3ba4836
- Move backend/frontend/messenger/ old paths to _archive/ - Reorganize scripts into scripts/deploy, check, push, setup, misc - Move docs (pptx, docx) to docs/ - Add .claude agents and skills for fullstack/folder-cleanup harness - workspace/ projects remain intact Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
133 lines
5.3 KiB
Markdown
133 lines
5.3 KiB
Markdown
---
|
|
name: guardia-fullstack-orchestrator
|
|
description: "GUARDiA 전체 시스템(ITSM·홈페이지·Manager·Messenger) 크로스 시스템 작업 오케스트레이터. 신기능 추가, 시스템 간 연동 수정, API 계약 변경, 통합 배포 등 여러 시스템에 걸친 작업을 조율한다. 다음 상황에서 반드시 사용: (1) '4개 시스템 분석', '전체 시스템'; (2) 여러 시스템에 걸친 기능 추가; (3) ITSM API 변경이 Manager·Messenger에 영향을 줄 때; (4) 크로스 시스템 테스트; (5) 다시 실행, 업데이트, 통합 배포."
|
|
---
|
|
|
|
# GUARDiA Fullstack Orchestrator
|
|
|
|
**실행 모드:** 하이브리드 (Phase 1: 분석=서브 에이전트 / Phase 2~3: 개발=에이전트 팀 / Phase 4: QA=서브 에이전트)
|
|
|
|
## Phase 0: 컨텍스트 확인
|
|
|
|
```
|
|
1. _workspace/ 존재 여부 확인
|
|
- 없음 → 초기 실행
|
|
- 있음 + 사용자가 "다시 실행/업데이트" → _workspace/를 _workspace_prev/로 이동 후 새 실행
|
|
- 있음 + 사용자가 특정 시스템만 수정 요청 → 해당 시스템 에이전트만 재호출 (부분 재실행)
|
|
|
|
2. 작업 유형 분류:
|
|
A. 단일 시스템 작업 → 해당 dev 에이전트만 직접 호출
|
|
B. 크로스 시스템 작업 → Phase 1~4 전체 실행
|
|
C. 분석 요청 → full-stack-analyst만 호출
|
|
```
|
|
|
|
## Phase 1: 영향 분석 (서브 에이전트)
|
|
|
|
`full-stack-analyst` 에이전트를 호출하여:
|
|
- 변경 요청의 영향 범위 파악 (어느 시스템의 어느 파일)
|
|
- API 계약 변경 시 의존 시스템 목록 추출
|
|
- 구현 순서 결정 (하위 의존 → 상위 의존)
|
|
|
|
산출물: `_workspace/01_analysis.md`
|
|
|
|
## Phase 2: 구현 (에이전트 팀)
|
|
|
|
영향 받는 시스템 수에 따라 팀 구성:
|
|
|
|
**단일 시스템**: 해당 에이전트만 호출
|
|
- ITSM 변경 → `itsm-dev`
|
|
- 홈페이지 변경 → `homepage-dev`
|
|
- Manager 변경 → `manager-dev`
|
|
- Messenger 변경 → `messenger-dev`
|
|
|
|
**크로스 시스템 (예: ITSM API 추가 + Manager/Messenger 클라이언트 추가)**:
|
|
```
|
|
에이전트 팀 구성:
|
|
1. itsm-dev — ITSM router/model 먼저 구현 (기반)
|
|
2. manager-dev — ITSM 구현 완료 후 Manager 클라이언트 구현
|
|
3. messenger-dev — Messenger 화면/훅 구현 (manager-dev와 병렬 가능)
|
|
```
|
|
|
|
**구현 순서 규칙**:
|
|
1. DB 모델 변경 (models.py) → 2. ITSM 라우터 → 3. Manager API 클라이언트 → 4. Messenger 화면
|
|
|
|
## Phase 3: 배포 준비 (선택)
|
|
|
|
`deploy-scripter` 에이전트를 통해:
|
|
- ITSM: `rsync workspace/guardia-itsm/ → /opt/guardia/app/`
|
|
- 홈페이지: `mvn clean package` + JAR 배포
|
|
- Manager: `npm run build` → `/var/www/manager/`
|
|
- Messenger: EAS 빌드 트리거
|
|
|
|
## Phase 4: 통합 QA (서브 에이전트)
|
|
|
|
`cross-system-qa` 에이전트를 호출하여:
|
|
- API 계약 일치 검증
|
|
- 보안 필드 노출 검사 (`ip_addr`, `ssh_user`, `os_pw_enc`)
|
|
- 인증 흐름 검증 (JWT 공유)
|
|
|
|
산출물: `_workspace/04_qa_report.md`
|
|
|
|
---
|
|
|
|
## 시스템별 빠른 참조
|
|
|
|
시스템 상세 정보가 필요하면 `references/system-landscape.md`를 읽어라.
|
|
|
|
### ITSM 신규 라우터 추가 체크리스트
|
|
|
|
- [ ] `workspace/guardia-itsm/routers/새파일.py` 생성
|
|
- [ ] `workspace/guardia-itsm/main.py`에 import + `app.include_router()` 추가
|
|
- [ ] `workspace/guardia-itsm/models.py`에 ORM 모델 + Pydantic 스키마 추가
|
|
- [ ] `ServerOut` 응답에서 `ip_addr`, `ssh_user`, `os_pw_enc` 제외 확인
|
|
|
|
### Manager 신규 기능 체크리스트
|
|
|
|
- [ ] `workspace/guardia-manager/frontend/src/pages/` 새 페이지 생성
|
|
- [ ] `workspace/guardia-manager/frontend/src/api/` API 클라이언트 메서드 추가
|
|
- [ ] ITSM JWT 토큰 `Authorization: Bearer {token}` 헤더 확인
|
|
|
|
### Messenger 신규 화면 체크리스트
|
|
|
|
- [ ] `workspace/guardia-messenger/app/(tabs)/새화면.tsx` 생성
|
|
- [ ] `workspace/guardia-messenger/app/(tabs)/_layout.tsx`에 탭 등록
|
|
- [ ] EAS 금지 패턴 4종 위반 여부 확인
|
|
|
|
---
|
|
|
|
## 에러 핸들링
|
|
|
|
| 상황 | 처리 |
|
|
|------|------|
|
|
| ITSM 라우터 import 실패 | models.py 스키마 누락 확인 → itsm-dev에 재요청 |
|
|
| Manager TypeScript 타입 오류 | ITSM Pydantic 스키마와 TS 인터페이스 비교 → manager-dev 수정 |
|
|
| Messenger EAS 빌드 실패 | 금지 패턴 4종 중 위반 항목 확인 → messenger-dev 수정 |
|
|
| 보안 필드 노출 감지 | 즉시 작업 중단 → itsm-dev에 스키마 수정 요청 후 재검증 |
|
|
|
|
---
|
|
|
|
## 테스트 시나리오
|
|
|
|
**정상 흐름**: "ITSM에 장비 모니터링 API 추가하고 Manager 대시보드와 Messenger에 연동해줘"
|
|
1. full-stack-analyst: 영향 범위 분석 → ITSM+Manager+Messenger 3개 시스템
|
|
2. itsm-dev: `routers/monitor.py` 생성 → main.py 등록
|
|
3. manager-dev: `/api/monitor` 호출 클라이언트 + 대시보드 위젯
|
|
4. messenger-dev: `(tabs)/monitor.tsx` 화면 추가
|
|
5. cross-system-qa: API shape 검증, 보안 필드 검사
|
|
|
|
**에러 흐름**: Manager에서 ITSM API 404 발생
|
|
1. cross-system-qa: ITSM 라우터 엔드포인트 vs Manager API 클라이언트 URL 대조
|
|
2. 불일치 발견 → manager-dev에 URL 수정 요청
|
|
3. 재검증
|
|
|
|
---
|
|
|
|
## 후속 작업 지원
|
|
|
|
이 스킬은 다음 상황에서도 트리거된다:
|
|
- "다시 실행", "업데이트", "수정", "보완"
|
|
- "ITSM과 Manager 연동 확인"
|
|
- "Messenger 화면 추가"
|
|
- "전체 시스템 배포"
|
|
- "API 계약 검증", "보안 스캔"
|