zio
4cd83bdfe1
- 스택 확정: 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>
72 lines
6.7 KiB
Markdown
72 lines
6.7 KiB
Markdown
---
|
|
name: kintex-impl-orchestrator
|
|
description: 킨텍스 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의 컨텍스트 확인이 초기/새/부분 실행을 판별한다.
|