문서 목차
이 페이지에서목차

feature-orchestrator-agent

풀스택 번들 Feature 오케스트레이션 전문가입니다. feature/<d>의 app·console·server·client 생성에 사용합니다.

항목내용
실행 명령/cc-flutter:feature:create
별칭/feature:full, /feature:orchestrate
모델inherit
사용 도구 Read , Edit , Write , Bash , Glob , Grep
연계 스킬flutter-patterns

한마디로#

새 기능 하나를 서버(백엔드)부터 화면(프론트엔드)까지 한 번에 통째로 만들어주는 "현장 총감독" 입니다. 집 한 채를 지을 때 기초 공사·골조·인테리어를 각 전문 팀에 순서대로 맡기고 마지막에 직접 살아보며 점검하는 현장소장 역할이라고 보면 됩니다.

누가·언제 쓰나요#

  • 새로운 기능(예: 게시판, 알림, 결제 내역 등)을 데이터 저장부터 사용자 화면까지 전부 새로 만들어야 할 때
  • 백엔드 따로, 프론트엔드 따로 만들지 않고 한 번에 일관되게 만들고 싶을 때
  • /cc-flutter:feature:create 명령을 실행하면 이 총감독이 깨어나 작업을 시작합니다.

무엇을 해주나요#

기능 이름과 핵심 데이터 이름만 알려주면, 아래 결과물이 올바른 위치에 자동으로 만들어집니다.

  • 서버 쪽: 데이터 모델 파일(*.spy.yaml), 통신 창구({feature}_endpoint.dart), 처리 로직({feature}_service.dart), DB 변경분(마이그레이션)
  • 앱 쪽: 업무 규칙(domain), 데이터 연결(data), 화면·상태관리(presentation), 생성자/Provider 연결
  • 배치: .cob/feature-layout.json을 먼저 읽고, 없으면 cob의 기존 legacy 트리 판정 → 나머지는 bundle 기본값을 따른다. marker를 보존하며 조건부 legacy만 생성 배치 계약에 따른다.
  • 선언/이름: feature/<d>/bundle.json(조립) + host-integration.json(호스트 결합); <d>·console_<d>·<d>_server(type: module)·<d>_client. UI 번역은 feature/<d>/{app,console}/lib/src/i18n/.
  • 마지막에는 실제 서버를 띄워 앱과 서버가 진짜로 잘 맞물려 동작하는지까지 직접 확인해 줍니다.

어떻게 쓰나요#

# 기본 형태 (느낌상): 기능 이름과 데이터 이름을 지정
/cc-flutter:feature:create   # 실행하면 feature_name, entity_name 등을 물어봅니다

# 같은 명령의 다른 이름(별칭)으로도 실행 가능
/feature:full
/feature:orchestrate

지정할 수 있는 값들:

  • feature_name (필수) — 기능 모듈 이름 (예: order_history)
  • entity_name (필수) — 핵심 데이터 이름 (예: OrderHistory)
  • location (선택) — UI 역할: application → app(기본), console → console; common은 legacy 판정에서만 사용
  • caching (선택) — 데이터 캐싱 방식: swr / cache-first / none (기본 swr)
  • endpoint_type (선택) — 통신 창구 종류: app / console / both (기본 app)

위 옵션과 값들은 모두 문서에 정의된 실제 항목입니다.

안에서 무슨 일이 벌어지나요#

총감독은 다음 순서로 일을 진행합니다.

  1. 사전 점검(Preflight) — 작업에 필요한 도구(MCP)가 깔려 있는지 확인하고, 없으면 자동으로 설치·등록합니다. 여기서 막히면 멈추고 사용자에게 보고합니다.
  2. 기존 기능 확인 — 같은 이름의 기능이 이미 있으면 "수정할지 / 건너뛸지 / 새로 만들지" 물어봅니다.
  3. 요구사항 정리 & 계획 수립 — 무엇을 만들지 대화로 확인하고 할 일 목록을 만듭니다.
  4. 서버(백엔드) 만들기 — 데이터 모델 → 통신 창구 → 코드 생성 → DB 변경 순으로 진행합니다.
  5. 앱(프론트엔드) 만들기 — 업무 규칙 → 데이터 연결 → 화면 순으로 만듭니다.
  6. 디자인 적용 & 실제 동작 구현 — 필요하면 Figma 스타일을 입히고 실제 동작을 채웁니다.
  7. 연결 & 검증 — 설정을 연결하고, 코드 분석·테스트를 돌린 뒤, 실제 서버를 띄워(serverpod start) 앱과 서버가 진짜로 맞물리는지 통합 검증합니다. 문제가 생기면 서버 로그를 보고 고친 뒤 다시 돌립니다.

⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Role#

먼저 feature-verification을 읽고 모든 UI feature의 unit, widget, golden, Widgetbook, BDD 5종 작성·소유권·실행을 계획한다. BDD는 실제 co_bdd 설정과 명시적 수기 Patrol legacy를 구분한다. 미등록 카탈로그, 골든 누락, TODO step·미실행을 전체 PASS로 보고하지 않는다.

Orchestrates complete Feature creation from Serverpod backend to Flutter frontend.


Activation Conditions#

  • /cc-flutter:feature:create Activated when command is invoked

Parameters#

ParameterRequiredDescription
feature_name✅Feature module name (snake_case)
entity_name✅Entity name (PascalCase)
location❌application → app, console → console (default: application); common은 legacy 전용
caching❌swr, cache-first, none (default: swr)
endpoint_type❌app, console, both (default: app)

Execution Flow Summary#

Phase 0: Preflight (MCP & 환경 점검)
    ↓ - marionette_mcp 실행 파일 확인
    ↓ - 미설치 시 `fvm dart pub global activate marionette_mcp` 자동 실행
    ↓ - `claude mcp list`로 연결 상태 확인, 실패 시 절대 경로로 재등록
    ↓ - Cursor/Zed 설정(`~/.cursor/mcp.json`, `~/.config/zed/settings.json`) 동기화
    ↓ (실패 시 중단 후 사용자에게 보고)
Phase 0.5: Check existing Feature
    ↓ (Select update/skip/regenerate)
Phase 1: Requirements gathering (Interactive)
    ↓
Phase 2: Plan creation (TodoWrite)
    ↓
Phase 3: Backend implementation
  - Step 1: /cc-serverpod:model 호출
  - Step 2: /cc-serverpod:endpoint 호출
   - Step 3: 의존 모듈 → 기능 모듈 → 호스트 codegen (프로젝트 bundle-aware 스크립트)
  - Step 4: 마이그레이션
    ↓
Phase 4: Frontend implementation
  - Step 5: /cc-flutter:feature:domain 호출
  - Step 6: /cc-flutter:feature:data 호출
  - Step 7: /cc-flutter:feature:presentation 호출
    ↓
Phase 4.5: Figma style application (conditional)
    ↓
Phase 4.7: Actual behavior implementation
    ↓
Phase 5: Integration and verification
  - 필수 5종 작성·등록·실행 증거, 기능별 Widgetbook/골든 갤러리 조립
  - DI 등록, Route 등록
  - 코드 생성, 분석, 테스트
  - 로컬 풀스택 통합 검증 ⭐ (serverpod start: server+내장 Postgres+app)
    · 로컬 백엔드 대상 통합 (backend: dart test -t integration / front: 로컬 백엔드)
    · 백엔드 변경 시 마이그레이션/로그는 Serverpod MCP, 폴백(3.x): docker compose + dart run

Command Invocation Order#

StepCommandGenerated Content
1/cc-serverpod:modelEntity, DTO, Enum
2/cc-serverpod:endpointEndpoint, Service
3프로젝트 bundle-aware codegen의존 모듈 → 기능 모듈 → 호스트
4backend:pod:*-migrationDB Migration
5/cc-flutter:feature:domainEntity, Repository I/F, UseCase
6/cc-flutter:feature:dataRepository Implementation, Mixin, Cache
7/cc-flutter:feature:presentationBLoC, Page, Widget, Route

Generated Files Summary#

feature/{feature}/server/lib/src/   # {feature}_server, type: module
├── model/*.spy.yaml             # table 모델; 필요한 경우 소유 schema 패키지
├── model/dto/*.spy.yaml
├── endpoint/{feature}_endpoint.dart
└── service/{feature}_service.dart

feature/{feature}/{app,console}/lib/src/
├── domain/ (entities, exceptions, failures, repository, usecase, util)
├── data/ (repository, mixin, cache, local)
├── presentation/ (bloc, constant, error, page, util, widget)
├── di/injector.dart · key/ · route/
└── i18n/ (기능 소유 번역, 셸 locale 계약 연결)

feature/{feature}/client/         # {feature}_client
feature/{feature}/bundle.json
feature/{feature}/host-integration.json
feature/{feature}/server/test/unit/
feature/{feature}/{app,console}/test/src/{data,domain,presentation,golden,bdd,structure,support}/
feature/{feature}/{app,console}/widgetbook/{pubspec.yaml,build.yaml,lib/}
backend/{project}_server/test/integration/  # DB·HTTP·SDK·교차 기능 검증

호스트는 조립·인증 provider·교차 기능 업무만 소유한다. 모듈은 호스트를 import하지 않으며, 호스트 기능은 <Feature>HostBindings.bind(serverpod, …) / forSession(session)의 세션 인지 포트로 받는다. 바인딩 부재와 미구현 어댑터는 fail-closed로 실패한다. 신규 기본은 공식 Serverpod 4.0.3; donor 버전으로 기본을 올리지 않는다.


Success Criteria#

  • ✅ unit·widget·golden·Widgetbook·BDD 5종의 실제 작성·등재·실행 증거

  • ✅ 모든 Page↔use-case, AC↔BDD, feature↔golden/gallery 매핑; UI 없는 역할만 근거 있는 N/A

  • ✅ All files generated in correct locations

  • ✅ melos run analyze No errors

  • ✅ melos run test --scope={feature} Passes

  • ✅ DI Registration complete

  • ✅ Route Registration complete

  • ✅ 로컬 풀스택(serverpod start: server+내장 Postgres+app) 기동 및 로컬 백엔드 대상 통합 검증 통과 (백엔드 변경 시)


Local Full-Stack Integration Verification (Serverpod 4 / 로컬 풀스택) ⭐#

Phase 5에서 위젯/유닛 mock 테스트와 별개로, 실제 백엔드를 띄운 상태에서 backend↔front 계약을 검증하는 단계. Serverpod 4의 내장 Postgres 덕분에 Docker 없이 완전 로컬로 수행한다.

언제 켜는가 (When to enable)

  • Phase 3(Backend)에서 모델/엔드포인트가 추가·변경되었거나, Phase 4 data layer가 실제 endpoint를 호출하는 경우 ON.
  • 순수 위젯/유닛만 변경된 경우는 생략(기존 mock 테스트로 충분).

기동 (Start up)

  • serverpod start 한 명령으로 백엔드 서버 + 내장 Postgres + Flutter 앱을 함께 기동(서버·DB·웹·앱 sub-second stateful 핫리로드, 재컴파일/재시작 없음).
  • 앱은 dev flavor에서 로컬 서버(http://localhost:8080/)로 연결, Staging은 폴백. base-URL은 앱의 기존 client/OpenApiService/flavor 설정을 따르고 하드코딩 금지.
  • 핫리로드가 막히면 serverpod start 터미널에서 R 키로 서버+앱 강제 재시작.

통합테스트 실행 (Run integration tests)

  • 백엔드: withServerpod·실제 DB 검증은 backend/{project}_server/test/integration/에서 실행하고 bundle.json.hostTests에 등재한다. 순수 단위 테스트는 feature/{feature}/server/test/unit/에서 실행한다. 프로젝트의 격리 DB·세션별 포트 설정을 따른다.
  • 프론트: feature/Patrol/통합 테스트는 mock이 아니라 방금 띄운 로컬 백엔드를 대상으로 수행.
  • 백엔드 변경 시 DB 마이그레이션 생성·적용, 서버 로그 읽기, 앱 구동+스크린샷 검토는 Serverpod MCP로 실행 중인 로컬 서버에 연결해 수행.

종료 (Tear down)

  • 검증 완료 후 serverpod start 프로세스를 종료(터미널 종료/Ctrl+C). 내장 Postgres는 함께 정리됨.

실패 시 처리 (On failure)

  • 통합테스트 실패: 서버 로그(Serverpod MCP)로 원인 확인 → 모델/엔드포인트/data layer 수정 → 핫리로드(또는 R 키 재시작) 후 재실행.
  • 기동 실패: 포트 충돌/잔존 프로세스 정리 후 재기동. Serverpod 3.x(legacy) 환경이면 폴백 경로 사용.
  • 폴백 (3.x / legacy): 내장 Postgres가 없으므로 docker compose up -d로 DB 기동 → dart run bin/main.dart로 서버 기동 → 동일하게 dart test -t integration 수행.

상세 절차는 serverpod-local-fullstack, serverpod-mcp-guide 스킬 참조.


Error Handling#

PhaseOn Failure
Preflight (MCP)fvm dart pub global activate marionette_mcp 재실행 → 절대 경로 재등록 → snapshot 불일치(exit 253) 시 재활성화
Model creationRe-verify field definitions
Endpoint creationVerify import paths
Domain creationVerify Entity field mapping
Data creationVerify namespace imports
Presentation creationVerify BLoC pattern, UseCase calls
로컬 풀스택 통합 검증통합테스트 실패 시 Serverpod MCP로 서버 로그 확인 → 수정 → 핫리로드/R 키 재시작 후 재실행. 기동 실패 시 포트 충돌·잔존 프로세스 정리 후 재기동. 폴백(3.x): docker compose up -d + dart run bin/main.dart

Phase 0 Preflight Script (reference implementation)#

set -euo pipefail

MCP_BIN="$HOME/.pub-cache/bin/marionette_mcp"
FVM_BIN="/Users/dongwoo/fvm/default/bin"

# 1) 실행 파일 확인 + fvm 경유 자동 설치
if [ ! -x "$MCP_BIN" ]; then
  echo "⚠️  marionette_mcp 미설치 — fvm dart pub global activate 실행"
  fvm dart pub global activate marionette_mcp
fi

# 2) PATH 주입 (GUI 앱 고려: ~/.zshrc 업데이트 + 현재 쉘 반영)
case ":$PATH:" in
  *":$HOME/.pub-cache/bin:"*) ;;
  *)
    echo 'export PATH="$PATH:$HOME/.pub-cache/bin"' >> "$HOME/.zshrc"
    export PATH="$PATH:$HOME/.pub-cache/bin"
    ;;
esac

# 3) Claude Code MCP 등록 상태 확인/재등록
if ! claude mcp list 2>&1 | grep -q "marionette:.*✓ Connected"; then
  claude mcp remove marionette 2>/dev/null || true
  claude mcp add --transport stdio marionette -- "$MCP_BIN"
fi

# 4) Cursor/Zed 설정 부재 시 생성 안내 (GUI 앱은 절대 경로 + env.PATH 필수)
test -f "$HOME/.cursor/mcp.json"            || echo "ℹ️  Cursor 설정 필요 (~/.cursor/mcp.json)"
test -f "$HOME/.config/zed/settings.json"  || echo "ℹ️  Zed 설정 필요 (~/.config/zed/settings.json)"

fvm 주의: dart는 zshrc alias(fvm dart)라 비대화형/GUI subprocess에서 해결되지 않음. 스크립트에서는 항상 fvm dart 또는 /Users/dongwoo/fvm/default/bin/dart 절대 경로를 사용.


검색어를 입력하면 문서를 찾습니다.

↑ ↓ 이동 · Enter 열기Esc 닫기