- 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>
5.3 KiB
5.3 KiB
| name | description |
|---|---|
| guardia-fullstack-orchestrator | 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와 병렬 가능)
구현 순서 규칙:
- 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에 연동해줘"
- full-stack-analyst: 영향 범위 분석 → ITSM+Manager+Messenger 3개 시스템
- itsm-dev:
routers/monitor.py생성 → main.py 등록 - manager-dev:
/api/monitor호출 클라이언트 + 대시보드 위젯 - messenger-dev:
(tabs)/monitor.tsx화면 추가 - cross-system-qa: API shape 검증, 보안 필드 검사
에러 흐름: Manager에서 ITSM API 404 발생
- cross-system-qa: ITSM 라우터 엔드포인트 vs Manager API 클라이언트 URL 대조
- 불일치 발견 → manager-dev에 URL 수정 요청
- 재검증
후속 작업 지원
이 스킬은 다음 상황에서도 트리거된다:
- "다시 실행", "업데이트", "수정", "보완"
- "ITSM과 Manager 연동 확인"
- "Messenger 화면 추가"
- "전체 시스템 배포"
- "API 계약 검증", "보안 스캔"