kintex/.claude/skills/kintex-mobile-orchestrator/SKILL.md

6.8 KiB

name description
kintex-mobile-orchestrator 킨텍스 자동전시시스템 모바일 앱(mobile/, Expo SDK 51 + React Native + TypeScript) 트랙 오케스트레이터. 모바일 화면(SCR-M*) 구현·실데이터 API 배선·현장 체크리스트/검수·시각화 갤러리·승인 흐름·오프라인·푸시 알림·i18n·앱 아이콘/스플래시·EAS 빌드·APK·QR 배포를 kintex-mobile-dev + designer + kintex-backend-dev + kintex-qa + kintex-devops-dev 팀으로 조율한다. "모바일 앱", "앱 화면", "Expo", "앱 기능 추가", "앱 빌드", "APK", "QR 배포", "푸시 알림", "앱 오프라인", "앱 아이콘/스플래시", "EAS", "모바일 QA", "다시 실행/재실행/업데이트/보완", "특정 화면만" 요청 시 반드시 이 스킬을 사용하라. (웹 프론트·백엔드·도메인 모듈 구현은 kintex-impl-orchestrator, 기획=planner, 디자인=designer 경유.)

킨텍스 자동전시시스템 — 모바일 앱 트랙 오케스트레이터

mobile/(Expo) 트랙을 에이전트 팀으로 조율한다. 실행 모드: 에이전트 팀. 모든 Agent 호출은 model: "opus". 근거 문서: docs/design.md §4(모바일 화면)·mobile/README.md(스택·화면 표·남은 작업)·docs/PLANNING.md §2-1(역할별 웹/모바일 분리).

구현 레퍼런스 = WISE 모바일 C:\GUARDiA\workspace\guardia-messenger\app\uiws\(읽기 전용): uiwsApi.ts API 클라이언트 패턴(봉투 언랩·degraded 폴백)·(auth) 2FA 로그인·60+ 화면 컨벤션. 신규 화면은 대응 uiws 화면 구조를 먼저 차용한다. 디자인 = Stitch 경유: designer가 design.md SCR-M* 스펙+Stitch 프롬프트 작성 → Stitch 생성(mcp__stitch__* 도구 또는 기존 프로젝트 9385904003821333054) → mobile-dev가 React Native로 이식.

앱 타깃 2개 (소유자 확정 2026-07-11): 코드베이스는 mobile/ 하나, 배포 타깃은 ①운영 앱(B2B, 2FA 필수, 사내 QR/APK) ②관람객 앱(B2C, 스토어 공개, 간편가입·게스트, 2FA 미강제). eas 프로파일/역할 라우팅으로 분리. 관람객 1차 접점은 공개 웹(SCR-P7/P8), 앱은 리텐션 채널.

경계 (중복 회피)

  • 웹 프론트(src/frontend)·백엔드 모듈·도메인(M2~M18) 구현 = kintex-impl-orchestrator
  • 이 하네스 = mobile/ 앱 전용: 화면·API 배선·NFR·에셋·빌드/배포. 모바일이 요구하는 백엔드 API 확장은 kintex-backend-dev를 이 팀에 합류시켜 처리(계약 단일 출처 유지)

에이전트 로스터

에이전트 역할 비고
kintex-mobile-dev Expo 화면·API 배선·NFR·에셋·eas.json (핵심 구현) 신규 전담
designer design.md §4 모바일 화면 스펙(SCR-M*) 신설·갱신 화면 신설 시만 합류
kintex-backend-dev 모바일이 요구하는 API 확장(부스 목록·검수 제출 등 M6/C-4) 계약 공백 시만 합류
kintex-qa 경계면 교차 QA(shape·워터마크·시크릿·typecheck) 각 화면 완성 직후 점진
kintex-devops-dev EAS 실빌드·APK·QR 배포 파이프라인 Phase 3, G3 게이트 후
reviewer design.md↔구현 정합 교차 검증 트랙 마감 시

Phase 0: 컨텍스트 확인·게이트

  1. mobile/ 존재(스캐폴드 완료) + _workspace/ 확인 → 초기/부분 재실행/새 실행 판별:
    • 부분 수정 요청("검수 화면만") → 해당 화면만 kintex-mobile-dev 재호출 → qa
    • 새 기능 요청 → Phase 1부터. 기존 _workspace/_workspace_prev/로 이동
  2. mobile/README.md "남은 작업"과 docs/UNDEVELOPED_BACKLOG.md를 백로그 소스로 삼는다
  3. 게이트 G3(EAS 실빌드): EAS는 외부 클라우드 빌드 서비스 — 실빌드·스토어/QR 배포 전 소유자 승인 필요. 미승인 시 eas.json·에셋 준비까지만(코드/구조는 게이트와 무관하게 진행)

Phase 1: 디자인 (Stitch 경유, 조건부)

신규 화면이 design.md §4에 없으면: ① designer가 SCR-M* 스펙 + Stitch 프롬프트를 design.md에 추가(직접 수정 금지 — 반드시 designer 경유) → ② Stitch로 화면 생성(mcp__stitch__generate_screen_from_text/edit_screens, 기존 프로젝트 재사용) → ③ 생성 결과를 stitch_kintex_ai_system_architect/에 확보 → mobile-dev 이식 입력으로 연결. 기존 화면 수정이면 건너뜀.

Phase 2: 구현 (팀 병렬)

TeamCreate 후 spawn: kintex-mobile-dev(필수) + kintex-backend-dev(계약 공백 시). TaskCreate로 화면 단위 작업 생성, blockedBy로 API 계약→화면 배선 의존성 연결.

  • kintex-backend-dev: 모바일 필요 API 계약을 _workspace/{phase}_backend_contract.md에 먼저 산출 → mobile-dev가 소비
  • kintex-mobile-dev: 화면/기능 구현 + npm run typecheck 통과 → 완성 통지를 kintex-qa에 SendMessage

Phase 3: 점진 QA → 빌드·배포

  • kintex-qa: 화면 완성 직후 경계면 교차 비교(API shape↔lib/types.ts↔화면 소비), AiImage 워터마크 강제, 시크릿/자격증명 미노출, typecheck 회귀. 실패 시 mobile-dev에 반려(통과까지)
  • kintex-devops-dev(G3 승인 후): EAS 빌드 → APK → QR 배포 랜딩(GUARDiA ITSM 중앙 APK 저장소 패턴 참조 가능). 커밋·push는 mobile/node_modules 제외 경로 지정 add(리포 대용량 함정)
  • reviewer: 트랙 마감 시 design.md §4↔mobile/README.md 화면 표↔실구현 3자 정합 검증

데이터 전달 / 에러

태스크(조율) + 파일(_workspace/{phase}_{agent}_{artifact}) + 메시지(실시간). 1회 재시도 후 재실패는 누락 명시하고 진행, 상충 계약은 backend 계약 문서를 권위로. QA 실패는 통과까지 반려. 최종물 mobile/, 중간물 _workspace/ 보존.

보안 불변

AI 이미지 워터마크·고지 강제(AiImage 경유만). 시크릿·자격증명·서버 IP 코드/커밋 미기재(API 베이스는 env/app.json extra만). 비밀번호 저장 금지. RBAC 화면 가드. 외부 API 금지(예외: Claude·나노바나나 Gemini 기승인, EAS는 G3 승인 필요).

테스트 시나리오

  • 정상: "모바일 앱에 부스 목록 화면 추가" → Phase0(백로그 확인) → Phase1(designer SCR-M3 스펙) → Phase2(backend 계약→mobile-dev 구현·typecheck) → Phase3(qa 경계면 통과) → 커밋.
  • 부분 재실행: "검수 화면 반려 사유 입력만 보완" → Phase0 부분 판별 → kintex-mobile-dev 단독 수정 → qa 해당 화면만 재검.
  • 에러: G3 미승인 상태 "APK 빌드해서 QR 배포" → eas.json·에셋 준비까지 완료 + 승인 요청 에스컬레이션(빌드 실행 보류 명시).

후속 작업

description의 후속 키워드(다시 실행·업데이트·보완·특정 화면만)로 재트리거. Phase 0이 초기/새/부분을 판별하고, 각 에이전트는 이전 산출물이 있으면 개선점만 반영한다.