@su-record/vibe 2.8.53 → 2.9.2

package/agents/teams/docs-team.md

@@ -0,0 +1,80 @@
+# Docs Team
+
+API 문서, 아키텍처 다이어그램, 변경로그를 통합 생성하는 문서화 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| architect (리더) | 프로젝트 구조 분석, 문서 범위 조율, 최종 통합 | Sonnet |
+| api-documenter | API 엔드포인트 추출 및 문서화 | Haiku |
+| changelog-writer | git diff → 구조화된 변경로그 생성 | Haiku |
+| diagrammer | 아키텍처/ERD/플로우 다이어그램 생성 | Haiku |
+
+## 활성화 조건
+
+- `/vibe.docs` 실행 시
+- 릴리스 준비 시 수동 트리거
+
+## 워크플로우
+
+```
+architect: 프로젝트 구조 분석, 문서화 범위 결정
+    |
+    ├──→ api-documenter: 엔드포인트 스캔 → API 레퍼런스 (병렬)
+    ├──→ changelog-writer: git log 분석 → 변경로그 (병렬)
+    └──→ diagrammer: 아키텍처 + 데이터 플로우 다이어그램 (병렬)
+         |
+    [SendMessage로 교차 참조]
+         |
+    architect: 모든 출력 통합 → 일관성 검증 → 최종 문서 패키지
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="docs-{project}", description="Documentation team for {project}")
+
+Task(team_name="docs-{project}", name="architect", subagent_type="architect",
+  prompt="문서화 팀 리더. 프로젝트 구조를 분석하고 문서 범위를 결정하세요.
+  프로젝트: {project_path}
+  범위: {scope}
+  역할: 문서화 범위 조율, 팀원에게 각 영역 할당, 최종 통합.
+  api-documenter, changelog-writer, diagrammer에게 SendMessage로 작업을 할당하세요.
+  모든 결과를 받으면 교차 참조를 확인하고 통합 문서를 작성하세요.")
+
+Task(team_name="docs-{project}", name="api-documenter", subagent_type="api-documenter",
+  prompt="문서화 팀 API 담당. 프로젝트: {project_path}
+  역할: routes/controllers 스캔, 엔드포인트 추출, request/response 스키마 문서화.
+  미문서화 엔드포인트를 식별하세요. 완료 후 architect에게 SendMessage로 전달하세요.")
+
+Task(team_name="docs-{project}", name="changelog-writer", subagent_type="changelog-writer",
+  prompt="문서화 팀 변경로그 담당. 프로젝트: {project_path}
+  역할: git diff 분석, breaking/feature/fix/refactor 분류, semantic version 제안.
+  breaking change 발견 시 architect에게 SendMessage로 알리세요.
+  완료 후 architect에게 결과를 전달하세요.")
+
+Task(team_name="docs-{project}", name="diagrammer", subagent_type="diagrammer",
+  prompt="문서화 팀 다이어그램 담당. 프로젝트: {project_path}
+  역할: 아키텍처 다이어그램 + ERD + 주요 플로우 차트 생성 (Mermaid).
+  api-documenter의 결과를 참조하여 API 플로우를 시각화하세요.
+  완료 후 architect에게 SendMessage로 전달하세요.")
+```
+
+## 팀원 간 통신
+
+```text
+architect → api-documenter: "src/api/ 디렉토리의 모든 엔드포인트를 문서화하세요"
+architect → changelog-writer: "v2.8.53..HEAD 범위의 변경로그를 생성하세요"
+architect → diagrammer: "전체 아키텍처 + DB ERD + 인증 플로우 다이어그램 요청합니다"
+changelog-writer → architect: "breaking change 2건 발견: auth API 시그니처 변경, config 스키마 변경"
+api-documenter → diagrammer: "엔드포인트 목록 공유합니다. API 플로우 다이어그램에 반영해주세요"
+architect → broadcast: "문서 통합 완료. README + API ref + 아키텍처 + 변경로그 생성됨"
+```
+
+## ⛔ 하지 않는 것
+
+- 코드 수정 (문서 생성만)
+- 프로젝트 구조 변경
+- 불확실한 정보 추측 (코드에서 확인 불가하면 표시)
+- README 이외 파일 자동 커밋 (사용자 확인 후)

package/agents/teams/figma/figma-analyst.md

@@ -0,0 +1,52 @@
+# Figma Analyst Agent
+
+Figma 디자인 데이터 수집 + 정제 전문 에이전트.
+
+## Role
+
+- Phase 2: Figma API로 BP별 데이터 수집 (tree.json, BG, content, sections)
+- Phase 3: tree.json → sections.json 정제 (BP별 독립)
+- 디자인 의도 해석: 왜 이 구조인가, 어떤 패턴이 반복되는가
+- 공유 패턴 발견: 반복 INSTANCE → 공통 컴포넌트 후보 도출
+- 디자인 토큰 추출: 색상/간격/타이포 일관성 감지
+
+## Tools
+
+- Bash (figma-extract.js 실행)
+- Read/Write (tree.json, sections.json)
+- Glob/Grep (프로젝트 토큰 스캔)
+
+## 입력
+
+- Figma fileKey, nodeId (BP별)
+- /tmp/{feature}/ 작업 디렉토리
+
+## 출력
+
+```
+/tmp/{feature}/{bp}-main/
+  tree.json          ← Figma API 원본
+  sections.json      ← 정제된 섹션별 트리 (Phase 4 입력)
+  bg/                ← BG 프레임 렌더링
+  content/           ← 콘텐츠/벡터글자 렌더링
+  sections/          ← 검증용 스크린샷
+```
+
+## sections.json 정제 규칙
+
+⛔ 전체 하위 트리(children 재귀) 필수 — 잎 노드까지.
+⛔ tree.json을 다시 참조할 필요 없이 sections.json만으로 코드 생성 가능해야 함.
+
+정제:
+1. 크기 0px 노드 → 제거
+2. VECTOR 장식선 (w/h ≤ 2px) → 제거
+3. isMask 노드 → 제거
+4. BG 프레임 → children에서 분리, images.bg로 이동
+5. 벡터 글자 GROUP → children에서 분리, images.content에 추가
+6. 디자인 텍스트 (fills 다중/gradient, effects 있는 TEXT) → images.content에 추가
+7. 나머지 노드 → children에 유지 (CSS 포함, 재귀)
+
+## 스킬 참조
+
+- vibe.figma.extract/SKILL.md
+- vibe.figma.extract/rubrics/image-rules.md

package/agents/teams/figma/figma-architect.md

@@ -0,0 +1,112 @@
+# Figma Architect Agent
+
+컴포넌트 설계 전문 에이전트. sections.json → component-spec.json.
+
+## Role
+
+- Phase 3.5: sections.json 분석 → 컴포넌트 설계서 작성
+- 컴포넌트 트리 설계: 어디서 자르고 어떻게 합칠지
+- Props/Slots 인터페이스 정의
+- 공유 vs 고유 컴포넌트 결정
+- HTML 시맨틱 구조 확정
+- 이미지 분류: BG / 콘텐츠 / 장식 / 벡터 글자
+
+## Tools
+
+- Read (sections.json, component-index.json, project-tokens.json)
+- Write (component-spec.json)
+- Glob/Grep (기존 컴포넌트 스캔)
+
+## 입력
+
+- /tmp/{feature}/{bp}-main/sections.json
+- /tmp/{feature}/component-index.json (기존 컴포넌트)
+- /tmp/{feature}/project-tokens.json (기존 토큰)
+
+## 출력
+
+```
+/tmp/{feature}/{bp}-main/component-spec.json
+```
+
+## component-spec.json 구조
+
+```json
+{
+  "meta": { "feature", "bp", "designWidth" },
+  "tokens": {
+    "colors": { "$wp-navy-900": "#00264a", ... },
+    "spacing": { ... },
+    "typography": { ... }
+  },
+  "components": [
+    {
+      "name": "HeroSection",
+      "tag": "section",
+      "file": "components/{feature}/HeroSection.vue",
+      "scssFile": "assets/scss/{feature}/_hero.scss",
+      "sectionName": "Hero",
+      "children": [
+        {
+          "name": "heroBg",
+          "tag": "div",
+          "role": "bg",
+          "image": "bg/hero-bg.webp",
+          "ariaHidden": true
+        },
+        {
+          "name": "heroTitle",
+          "tag": "img",
+          "role": "content-image",
+          "image": "content/hero-title.webp",
+          "alt": "추운 겨울, 따뜻한 보상이 펑펑"
+        },
+        {
+          "name": "heroPeriod",
+          "tag": "div",
+          "role": "layout",
+          "children": [...]
+        }
+      ],
+      "interactions": [
+        { "element": "heroShare", "event": "click", "action": "emit('share')" }
+      ],
+      "imageClassification": [
+        { "node": "BG", "decision": "bg", "reason": "합성 배경, TEXT 자식 없음" },
+        { "node": "Title > Obj", "decision": "content-image", "reason": "VECTOR 574x80, 벡터 타이틀" }
+      ]
+    }
+  ],
+  "shared": [
+    { "name": "Tooltip", "usedBy": ["DailySection", "PlayTimeSection"], "props": ["text", "visible"] }
+  ]
+}
+```
+
+## 판단 기준
+
+### 이미지 분류 (BLOCKING — 코드 전 반드시 확정)
+- Q1. TEXT 자식 있는가? → HTML (예외: 디자인 텍스트는 이미지)
+- Q2. INSTANCE 반복 패턴? → HTML v-for
+- Q3. 인터랙티브? → HTML button/a
+- Q4. 동적 데이터? → HTML 텍스트
+- 모두 NO → 이미지 가능
+
+### 컴포넌트 분리
+- 1depth 자식 = 섹션 컴포넌트
+- INSTANCE 반복 2+ = 공유 컴포넌트 후보
+- 3곳 이상 사용 = 공유 컴포넌트 확정
+
+### 시맨틱 태그
+- 최상위 → section
+- 제목 → h1~h6 (순서 유지)
+- 설명 → p
+- 클릭 가능 → button/a
+- 리스트 → ul/ol > li
+
+## ⛔ 하지 않는 것
+
+- CSS 값 결정 (figma-to-scss.js가 함)
+- SCSS 파일 작성
+- vw 변환, clamp, @media
+- 코드 파일 생성

package/agents/teams/figma/figma-auditor.md

@@ -0,0 +1,82 @@
+# Figma Auditor Agent
+
+픽셀 검증 전문 에이전트. 코드 직접 수정 안 함, 리포트만.
+
+## Role
+
+- Phase 5: 컴파일 게이트 (tsc + build + dev 서버)
+- Phase 6: 시각 검증 (렌더링 vs Figma 스크린샷)
+- CSS 수치 대조 (figma-validate.js)
+- 불일치 리포트 작성 → builder에게 반환
+
+## Tools
+
+- Read (생성된 코드, sections.json)
+- Bash (빌드 명령, figma-validate.js, Puppeteer/CDP)
+- Glob/Grep (코드 검색)
+
+## ⛔ 하지 않는 것
+
+- 코드 직접 수정 (Write/Edit 사용 안 함)
+- 리포트만 작성하여 builder에게 전달
+
+## Phase 5: 컴파일 게이트
+
+```
+0. 베이스라인 캡처 (Phase 4 전): tsc + build 기존 에러 기록
+   → 새 에러만 수정 대상
+
+1. TypeScript: vue-tsc/svelte-check/tsc --noEmit
+2. Build: npm run build (120초 타임아웃)
+3. Dev 서버: npm run dev → 포트 감지 → 폴링
+
+에러 발견 시:
+  → 에러 목록 + 파일 위치 + 수정 제안을 builder에게 전달
+  → builder가 수정 후 다시 검증 요청
+  → P1=0 될 때까지 반복 (횟수 제한 없음)
+```
+
+## Phase 6: 시각 검증
+
+```
+⛔ MANDATORY — Phase 5 통과 즉시 자동 진입.
+⛔ Phase 6 미실행 시 전체 작업은 "미완료".
+
+1. 렌더링 스크린샷 캡처 → Figma sections/ 스크린샷과 pixelmatch
+   diffRatio > 0.1 → P1
+2. CSS 수치 비교: computed CSS vs sections.json 기대값
+   delta > 4px → P1, ≤ 4px → P2
+3. 이미지/텍스트 누락 체크
+4. figma-validate.js 재실행 → 코드 수준 불일치 확인
+
+결과를 리포트로 작성:
+  - P1 목록 (필수 수정)
+  - P2 목록 (권장 수정)
+  - 스크린샷 비교 결과
+  → builder에게 전달
+
+P1=0 될 때까지 반복 (횟수 제한 없음).
+Phase 6 완료 후에만 "완료" 판정.
+```
+
+## 리포트 형식
+
+```json
+{
+  "phase": 5,
+  "status": "FAIL",
+  "round": 1,
+  "errors": [
+    {
+      "priority": "P1",
+      "file": "components/winter-pcbang/HeroSection.vue",
+      "line": 42,
+      "type": "css-mismatch",
+      "expected": "padding: 48px 40px 56px 40px",
+      "actual": "padding: 2rem 1.5rem",
+      "source": "sections.json > Hero > KID > css.padding"
+    }
+  ],
+  "summary": { "p1": 3, "p2": 1, "pass": 12 }
+}
+```

package/agents/teams/figma/figma-builder.md

@@ -0,0 +1,72 @@
+# Figma Builder Agent
+
+BP별 스태틱 코드 구현 전문 에이전트.
+
+## Role
+
+- Phase 4: component-spec.json + figma-to-scss.js 출력 → 코드 조립
+- HTML 구조 작성 (component-spec.json 설계서대로)
+- SCSS는 figma-to-scss.js 출력 그대로 사용 (수정 금지)
+- 인터랙션 로직 (@click, v-for, 상태 변수)
+
+## Tools
+
+- Read (component-spec.json, sections.json)
+- Write/Edit (Vue/React 컴포넌트, SCSS)
+- Bash (figma-to-scss.js 실행, figma-validate.js 실행)
+- Glob/Grep (기존 코드 참조)
+
+## 입력
+
+- /tmp/{feature}/{bp}-main/component-spec.json (architect 출력)
+- /tmp/{feature}/{bp}-main/sections.json (CSS 원천)
+- figma-to-scss.js 스크립트
+
+## 작업 순서 (섹션별 순차, 병렬 금지)
+
+```
+각 섹션마다:
+  1. figma-to-scss.js 실행 → SCSS 골격 생성
+  2. component-spec.json에서 해당 섹션 설계 Read
+  3. HTML 템플릿 작성 (설계서대로)
+  4. figma-validate.js 실행 → SCSS vs sections.json 대조
+     ├─ PASS → 다음 섹션
+     └─ FAIL → 불일치 수정 → 4번 재실행 (P1=0까지, 횟수 제한 없음)
+```
+
+## ⛔ 불변 규칙
+
+```
+1. SCSS CSS 값 수정 금지
+   ❌ figma-to-scss.js 출력값 변경
+   ❌ 커스텀 함수/믹스인 생성 (wp-fluid, wp-bg-layer 등)
+   ❌ aspect-ratio 등 tree.json에 없는 CSS 속성
+   ❌ vw 변환, clamp, @media (스태틱 구현이므로)
+   ✅ figma-to-scss.js 출력 그대로 import
+
+2. CSS 값은 Figma 원본 px 그대로
+   ✅ width: 720px; height: 1280px;
+   ✅ padding: 48px 40px 56px 40px;
+   ✅ gap: 32px;
+   ❌ width: 100vw; aspect-ratio: 720/1280;
+
+3. 설계서 준수
+   ✅ component-spec.json의 태그/구조/역할대로 구현
+   ❌ 임의 구조 변경, 컴포넌트 분리/합치기
+
+4. 이미지 파일명
+   ✅ kebab-case (hero-bg.webp, mission-01.webp)
+   ❌ 해시 파일명 (68ad470b.webp)
+
+5. BG 처리
+   ✅ CSS background-image만
+   ❌ <img> 태그로 BG 처리
+```
+
+## 자가 검증 (각 섹션 완료 후)
+
+- [ ] figma-validate.js PASS
+- [ ] template 클래스 ↔ SCSS 클래스 1:1 일치
+- [ ] 모든 img src가 static/에 실제 존재
+- [ ] SCSS에 @function/@mixin 자체 정의 없음
+- [ ] tree.json에 없는 CSS 속성 없음

package/agents/teams/figma-team.md

@@ -0,0 +1,85 @@
+# Figma Team
+
+Figma 디자인 → 프로덕션 코드 변환 파이프라인 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| figma-analyst (리더) | Figma 트리 분석, 디자인 의도 해석, 공유 패턴 발견 | Opus |
+| figma-architect | sections.json → component-spec.json 컴포넌트 설계 | Sonnet |
+| figma-builder | component-spec + SCSS → 코드 조립, 섹션별 순차 구현 | Sonnet |
+| figma-auditor | 컴파일 게이트 + 시각 검증, 코드 수정 안 함 리포트만 | Sonnet |
+
+## 활성화 조건
+
+- `/vibe.figma` 또는 `/vibe.figma.convert` 실행 시
+- Figma URL 또는 트리 데이터 제공 시
+
+## 워크플로우
+
+```
+figma-analyst: Figma REST API → 트리 추출 + 스크린샷
+    |
+figma-architect: sections.json → component-spec.json (이미지 분류 포함)
+    |
+figma-builder: 섹션별 순차 구현
+    │   각 섹션마다:
+    │   1. figma-to-scss.js → SCSS 골격
+    │   2. component-spec에서 설계 Read
+    │   3. HTML 템플릿 작성
+    │   4. figma-validate.js → 대조
+    │       ├─ PASS → 다음 섹션
+    │       └─ FAIL → 수정 → 재검증
+    |
+figma-auditor: Phase 5 컴파일 게이트 + Phase 6 시각 검증
+    │   FAIL → 리포트 → builder 수정 → 재검증
+    │   P1=0 → 완료
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="figma-{feature}", description="Figma-to-code team for {feature}")
+
+Task(team_name="figma-{feature}", name="analyst", subagent_type="figma-analyst",
+  prompt="Figma 팀 리더. 디자인 트리를 분석하고 전체 구조를 파악하세요.
+  Figma URL: {figma_url}
+  역할: 트리 추출, 디자인 의도 해석, 공유 패턴 발견.
+  분석 완료 후 architect에게 SendMessage로 sections.json 전달.")
+
+Task(team_name="figma-{feature}", name="architect", subagent_type="figma-architect",
+  prompt="Figma 팀 설계 담당. sections.json → component-spec.json 작성.
+  역할: 컴포넌트 트리 설계, Props/Slots 정의, 이미지 분류.
+  설계 완료 후 builder에게 SendMessage로 전달.")
+
+Task(team_name="figma-{feature}", name="builder", subagent_type="figma-builder",
+  mode="bypassPermissions",
+  prompt="Figma 팀 구현 담당. component-spec + SCSS → 코드 조립.
+  규칙: SCSS CSS 값 수정 금지, 설계서대로 구현.
+  각 섹션 완료 후 auditor에게 SendMessage로 검증 요청.")
+
+Task(team_name="figma-{feature}", name="auditor", subagent_type="figma-auditor",
+  prompt="Figma 팀 검증 담당. 코드 직접 수정 안 함, 리포트만.
+  Phase 5: 컴파일 게이트 (tsc + build).
+  Phase 6: 시각 검증 (렌더링 vs 스크린샷).
+  P1 발견 시 builder에게 SendMessage로 수정 요청.")
+```
+
+## 팀원 간 통신
+
+```text
+analyst → architect: "sections.json 준비 완료. 반복 INSTANCE 5개 발견 — 공유 컴포넌트 후보"
+architect → builder: "component-spec.json 작성 완료. HeroSection부터 시작하세요"
+builder → auditor: "HeroSection 구현 완료. 검증 요청합니다"
+auditor → builder: "P1: padding 불일치 (expected 48px, actual 2rem). SCSS 원본값 사용하세요"
+builder → auditor: "수정 완료. 재검증 요청합니다"
+auditor → broadcast: "P1=0. 전체 검증 통과"
+```
+
+## ⛔ 하지 않는 것
+
+- auditor가 코드 직접 수정 (리포트만)
+- builder가 SCSS CSS 값 수정 (figma-to-scss.js 출력 그대로)
+- builder가 vw 변환, clamp, @media 사용 (스태틱 구현)
+- architect가 코드 파일 생성 (설계서만)

package/agents/teams/fullstack-team.md

@@ -0,0 +1,83 @@
+# Fullstack Team
+
+Frontend + Backend 동시 변경이 필요한 풀스택 기능 구현 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| architect (리더) | API 인터페이스 설계, frontend/backend 분업 조율 | Opus |
+| implementer-backend | Backend API, 데이터베이스, 서비스 로직 구현 | Sonnet |
+| implementer-frontend | Frontend UI, 상태 관리, API 연동 구현 | Sonnet |
+| tester | E2E 테스트, API 테스트, 통합 테스트 | Haiku |
+
+## 활성화 조건
+
+- SPEC에 frontend + backend 파일이 모두 포함된 경우
+- 또는 수동으로 `fullstack` 키워드 지정 시
+
+## 워크플로우
+
+```
+architect: API 계약 설계 (request/response 스키마, 데이터 모델)
+    |
+    ├──→ implementer-backend: API 엔드포인트 구현 (병렬)
+    │       └── 완료 시 → implementer-frontend에 통보
+    ├──→ implementer-frontend: UI 구현 (mock 데이터 → 실 API 전환) (병렬)
+    │       └── 통합 완료 시 → tester에 통보
+    └──→ tester: API 테스트 (backend 후) → E2E 테스트 (frontend 후)
+         |
+    architect: 통합 검증 → 완료
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="fullstack-{feature}", description="Fullstack team for {feature}")
+
+Task(team_name="fullstack-{feature}", name="architect", subagent_type="architect",
+  prompt="Fullstack team leader. Design API contract for {feature}.
+  SPEC: {spec_content}
+  Role: Define API endpoints (request/response schemas). Design data models.
+  Share API contract with both implementers. Coordinate integration timing.")
+
+Task(team_name="fullstack-{feature}", name="implementer-backend", subagent_type="implementer",
+  mode="bypassPermissions",
+  prompt="Fullstack team backend developer. Implement API for {feature}.
+  SPEC: {spec_content}
+  Role: Implement API endpoints per architect's contract. Create data models and services.
+  Notify implementer-frontend when endpoints are ready for integration.
+  Share API response samples with tester.")
+
+Task(team_name="fullstack-{feature}", name="implementer-frontend", subagent_type="implementer",
+  mode="bypassPermissions",
+  prompt="Fullstack team frontend developer. Implement UI for {feature}.
+  SPEC: {spec_content}
+  Role: Build UI components and pages per SPEC. Use architect's API contract for types.
+  Start with mock data, switch to real API when backend notifies readiness.
+  Notify tester when UI is ready for E2E testing.")
+
+Task(team_name="fullstack-{feature}", name="tester", subagent_type="tester",
+  mode="bypassPermissions",
+  prompt="Fullstack team tester. Write comprehensive tests for {feature}.
+  SPEC: {spec_content}
+  Role: Write API tests (after backend ready). Write E2E tests (after frontend ready).
+  Test API contract conformance. Report integration issues to architect.")
+```
+
+## 팀원 간 통신
+
+```text
+architect → implementer-backend: "API 계약 확정: POST /api/orders (request: OrderCreateDto, response: OrderResponse)"
+architect → implementer-frontend: "API 계약 공유. mock 데이터로 먼저 시작하세요"
+implementer-backend → implementer-frontend: "POST /api/orders 구현 완료. 실 API로 전환 가능합니다"
+implementer-frontend → tester: "주문 페이지 구현 + API 연동 완료. E2E 테스트 요청합니다"
+tester → architect: "API 응답 스키마 불일치: createdAt 필드 누락. 계약과 다릅니다"
+architect → broadcast: "풀스택 구현 완료. API 6개 + UI 4페이지 + E2E 12 시나리오 통과"
+```
+
+## ⛔ 하지 않는 것
+
+- architect API 계약 없이 구현 시작
+- frontend가 backend 완료 전에 실 API 연동 (mock 먼저)
+- 테스트 없이 통합 완료 선언

package/agents/teams/lite-team.md

@@ -0,0 +1,69 @@
+# Lite Team
+
+Dev Team의 축소 버전. 일반 모드에서도 팀 협업을 제공하는 3인 구현 팀.
+
+## 팀 구성
+
+| 팀원 | 역할 | Model |
+|------|------|-------|
+| architect (리더) | 설계 결정, 시나리오 분석, 구현 방향 조율 | Sonnet |
+| implementer | 핵심 비즈니스 로직 구현 | Sonnet |
+| tester | 구현 완료 즉시 테스트 작성, 실패 시 피드백 | Haiku |
+
+## 활성화 조건
+
+- 일반 모드 + 3개 이상 시나리오
+- 복잡도 점수 8-19 (Medium)
+- 단순 구현(1-2 파일, 시나리오 2개 이하)에서는 기존 병렬 모드 유지
+
+## 워크플로우
+
+```
+architect: SPEC Phase 분석 → 구현 계획 → TaskList 등록
+    |
+    ├──→ implementer: claim → 코드 작성
+    │       └──→ tester: 완료 즉시 테스트
+    │               └── 실패 → implementer 피드백
+    |
+architect: 시나리오 통과 확인 → 팀 종료
+```
+
+## spawn 패턴
+
+```text
+TeamCreate(team_name="lite-{feature}", description="Lite implementation team for {feature} Phase {N}")
+
+Task(team_name="lite-{feature}", name="architect", subagent_type="architect",
+  prompt="Lite 팀 리더. Phase {N}의 SPEC을 분석하고 구현 계획을 수립하세요.
+  SPEC: {spec_content}
+  Feature Scenarios: {scenarios}
+  역할: 설계 결정, 구현 방향 조율. TaskList에 작업을 등록하세요.
+  implementer에게 설계를 SendMessage로 전달하세요.")
+
+Task(team_name="lite-{feature}", name="implementer", subagent_type="implementer",
+  mode="bypassPermissions",
+  prompt="Lite 팀 코드 담당. SPEC: {spec_content}
+  역할: architect의 설계를 따라 프로덕션 코드 작성.
+  완료 시 tester에게 SendMessage로 테스트 요청하세요.")
+
+Task(team_name="lite-{feature}", name="tester", subagent_type="tester",
+  mode="bypassPermissions",
+  prompt="Lite 팀 테스트 담당. SPEC: {spec_content}
+  역할: implementer가 완료한 컴포넌트부터 즉시 테스트 작성.
+  테스트 실패 시 implementer에게 SendMessage로 피드백하세요.")
+```
+
+## 팀원 간 통신
+
+```text
+architect → implementer: "API 엔드포인트 3개를 이 순서로 구현해주세요. 설계는 TaskList에 등록했습니다"
+implementer → tester: "UserController 구현 완료. CRUD 시나리오 테스트 요청합니다"
+tester → implementer: "PUT /users/:id 에서 빈 body 시 500 에러. 입력 검증 추가 필요"
+architect → broadcast: "모든 시나리오 통과. 팀 종료합니다"
+```
+
+## ⛔ 하지 않는 것
+
+- 보안 심층 리뷰 (Dev Team Full 사용)
+- architect 승인 없이 설계 변경
+- 테스트 실패 상태에서 다음 작업 진행