kintex/.claude/skills/kintex-impl-orchestrator/SKILL.md
zio 4cd83bdfe1 feat(harness): 구현 하네스 전체 구성 + 스택 확정(React/Spring/MyBatis/PostgreSQL)
- 스택 확정: PLANNING v1.2 §8(FastAPI/Next.js→Spring Boot+MyBatis/React), CLAUDE.md 기술스택 섹션
- 구현 에이전트 5종: kintex-backend-dev·frontend-dev·db-engineer·qa·devops-dev
- kintex-impl-orchestrator 스킬 + docs/IMPLEMENTATION_BACKLOG.md(Phase0~5)
- designer에 Stitch 학습·정합 트랙, developer 스택 갱신
- Stitch export 텍스트 참조(code.html·DESIGN.md 3종·proposal.md) 추가, 스크린샷 PNG는 gitignore

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 16:58:31 +09:00

6.7 KiB

name description
kintex-impl-orchestrator 킨텍스 AI 전시관리 시스템 구현 오케스트레이터. React(Vite)+Spring Boot 3.x(Java17)+MyBatis+PostgreSQL(PostGIS)+Redis+나노바나나 Python 워커로 PLANNING v1.2의 M1~M9 모듈을 P0(M2 플로어플랜·M3 부스설계·M4 유틸리티배선·M5 시각화)부터 구현하도록 전문 에이전트 팀(kintex-backend-dev·kintex-frontend-dev·kintex-db-engineer·visualizer·kintex-qa·kintex-devops-dev + designer·planner·reviewer)을 조율한다. "킨텍스 구현", "kintex 개발", "부스 배치/설계/배선/시각화 구현", "백엔드/프론트/스키마 구현", "Stitch 화면 이식", "src 구현", "구현 백로그", "배포", "다시 실행", "재실행", "업데이트", "수정", "보완", "특정 모듈만(M2~M9)" 요청 시 반드시 이 스킬을 사용하라. (기획 문서 수정은 planner, 디자인 문서는 designer 경유 — 이 오케스트레이터는 구현 조율 트랙.)

킨텍스 AI 전시관리 시스템 — 구현 오케스트레이터

docs/PLANNING.md(v1.2)·docs/design.md·docs/IMPLEMENTATION_BACKLOG.md를 근거로 실제 구현(src/)을 에이전트 팀으로 조율한다. 실행 모드: 에이전트 팀(기본). 모든 Agent 호출은 model: "opus".

확정 스택 (불변)

React 18/19(Vite·TS) · Spring Boot 3.x(Java 17)+MyBatis · PostgreSQL(PostGIS) · Redis 큐 · 나노바나나 Python 워커(tools/nanobanana, google-genai gemini-3.1-flash-image-preview). 상세 아키텍처는 PLANNING §8.

에이전트 로스터

에이전트 역할 타입
designer Stitch 산출물 학습·design.md 정합·SCR 매핑·범위 게이트 designer
kintex-db-engineer PostGIS 스키마·마이그레이션·MyBatis 매퍼·마스터 시드 kintex-db-engineer
kintex-backend-dev Spring Boot+MyBatis M1~M9 API·룰/배치/배선 엔진·RenderJob 발행 kintex-backend-dev
kintex-frontend-dev React 이식(Stitch→컴포넌트)·캔버스·배선뷰·Before/After kintex-frontend-dev
visualizer 나노바나나 Python 워커 구현(RenderJob 소비·생성·오버레이 래스터) visualizer
kintex-qa 경계면 교차 QA(점진)·보안 불변·공간 로직 정합 kintex-qa (general-purpose)
kintex-devops-dev 빌드·CI/CD·배포 구성(승인 게이트) kintex-devops-dev
planner / reviewer 기획 갱신 / 산출물 교차 검증 planner / reviewer

Phase 0: 컨텍스트 확인 (필수 선행)

  1. _workspace/ 존재 여부·src/ 현황·docs/IMPLEMENTATION_BACKLOG.md를 확인해 실행 모드 판별:
    • _workspace/ 미존재 → 초기 실행(Phase 1부터)
    • _workspace/ 존재 + 사용자가 부분 수정 요청 → 부분 재실행(해당 에이전트/모듈만)
    • _workspace/ 존재 + 새 입력 → 새 실행(기존 _workspace/_workspace_prev/로 이동)
  2. 선행 게이트 2종을 사용자에게 확인(미확정이면 해당 트랙 보류):
    • G1 나노바나나(Gemini) 외부 호출 승인(PLANNING R12) — M5 실호출·배포 전 필수. 미승인 시 M5는 코드/구조만 작성하고 실 API 호출·배포 보류.
    • G2 배포 대상 서버·포트(kintex는 GUARDiA 관제 인프라와 별개 도메인) — Phase 5 배포 전 확인.

Phase 1: 설계 정합 (파이프라인, 팀)

TeamCreate 후 아래를 TaskCreate로 배분(의존성 blockedBy):

  1. designer — Stitch 산출물(stitch_kintex_ai_system_architect/) 학습 → docs/design.md 정합(디자인 시스템 단일 출처 수렴) + SCR 매핑표 + 범위 게이트(범위 밖 Stitch 화면 P2 표기). ★design.md 수정은 designer만.
  2. kintex-db-engineer — PLANNING §7 ERD → PostGIS 스키마 v1·마이그레이션·마스터 시드(홀·요율·규정 룰셋)·MyBatis 매퍼 골격. 스키마 계약 _workspace/01_db_schema.md.
  3. kintex-backend-dev — P0 API 계약(OpenAPI 수준) 초안 _workspace/01_backend_contracts.md(스키마 계약 참조). → 종료 시 reviewer가 기획-디자인-스키마-계약 정합 교차 검증.

Phase 2: P0 구현 (파이프라인 + 점진 QA)

IMPLEMENTATION_BACKLOG의 P0 에픽(M2·M3·M4·M5) 단위로 파이프라인. 각 모듈:

  • db → backend → frontend/visualizer → qa 순으로 흐르되 모듈 간 독립 병렬(배리어 최소화).
  • M2 플로어플랜: db(booth polygon·trench)→backend(배치 저장·규정 검증 PostGIS)→frontend(SCR-03 캔버스 이식)→qa
  • M3 부스 설계: backend(초안·규정 사전검증)→frontend(SCR-06)→qa
  • M4 유틸리티 배선: db(wiring LineString)→backend(배선 산출·견적·위치표시도)→frontend(SCR-07/08)→qa
  • M5 시각화: backend(RenderJob 발행/상태)→visualizer(나노바나나 워커 소비·생성·S6 래스터)→frontend(SCR-12 갤러리·Before/After)→qa (★G1 미승인 시 실호출 제외, 목/폴백으로)
  • 각 모듈 완성 직후 kintex-qa 점진 검증 — 경계면 shape·보안 불변·공간 로직·워터마크 강제. 실패 시 해당 에이전트에 SendMessage 반려.

Phase 3: P1 구현

M1(홀 배정·요율 룰 엔진)·M6(마일스톤·서식)·M7(등록업체 매칭)·M9(정산·결제). Phase 2 패턴 반복.

Phase 4: P2 구현

M8(물류 슬롯) + designer가 P2로 승격 판정한 Stitch 화면(BI·hall ops 등)은 planner 기획 반영 후에만.

Phase 5: 빌드·배포 (G2 게이트)

kintex-devops-dev — Spring jar + React 번들(+나노바나나 워커 서비스) 빌드, Gitea zio/kintex CI/CD·webhook·systemd. G2(서버·포트)·G1(Gemini 승인) 확정 후 실배포; 미확정 시 파이프라인 파일만 준비.

데이터 전달

태스크 기반(조율) + 파일 기반(_workspace/{phase}_{agent}_{artifact}) + 메시지 기반(실시간). 최종 산출물은 src/·docs/, 중간물은 _workspace/ 보존.

에러 핸들링

1회 재시도 후 재실패 시 해당 결과 없이 진행하고 _workspace/ 리포트에 누락 명시. 상충 데이터는 삭제 않고 출처 병기. 빌드/QA 실패는 통과까지 반려.

테스트 시나리오

  • 정상: "킨텍스 M2 구현" → Phase0 컨텍스트 확인 → Phase1 설계정합 → Phase2 M2(db→backend→frontend→qa) → QA 통과 → 보고.
  • 부분 재실행: "SCR-07 배선 뷰만 다시" → Phase0에서 부분 재실행 판정 → kintex-frontend-dev(+backend 계약 확인)만 재호출 → qa 재검증.
  • 에러: G1(Gemini) 미승인 상태로 "M5 구현" → M5 실호출 제외·구조만 작성, 사용자에게 승인 요청 에스컬레이션.

후속 작업

description의 후속 키워드로 재실행/부분수정/업데이트를 트리거한다. Phase 0의 컨텍스트 확인이 초기/새/부분 실행을 판별한다.