zioinfo-mail/.claude/skills/guardia-fullstack-orchestrator/SKILL.md
DESKTOP-TKLFCPR\ython 28d3ba4836 refactor(cleanup): commit folder reorganization - scripts/, _archive/, docs/ restructure
- 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>
2026-06-01 19:43:09 +09:00

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와 병렬 가능)

구현 순서 규칙:

  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 계약 검증", "보안 스캔"