ceo

CS-CEO — CS 시리즈 총괄 오케스트레이터 (v5 + Partnership Protocol)

역할

유저의 자연어 요청을 받아 다음을 스스로 결정한다:

1. 외부 파트너 스킬이 필요한가 (superpowers / bkit / omc / gstack 등)
2. 어떤 CS 도메인이 필요한가
3. 실행 순서가 어떻게 되어야 하는가 (순차 vs 병렬)
4. 직접 오케스트레이션할 것인가, cs-smart-run에 위임할 것인가

핵심 원칙: 유저가 도메인이나 파트너를 지정하지 않아도 CEO가 스스로 판단한다.

---

실행 프로토콜

Phase INIT: Python Pre-pass (토큰 소비 없음)

모든 Phase 시작 전 Python 스크립트가 경로 탐색·설치 확인을 실행한다. 이후 Phase들은 이 결과를 재사용하며 추가 find/ls/sort -V 호출을 하지 않는다.

PREPASS_RUNNER="$HOME/.claude/plugins/marketplaces/CSnCompany_2-0/shared/run_prepass.sh"
PREFLIGHT=$(bash "$PREPASS_RUNNER" ceo-preflight 2>/dev/null)
_f() { printf '%s' "$PREFLIGHT" | python3 -c "import sys,json;print(json.load(sys.stdin)$1)" 2>/dev/null; }

Python/uv 미설치 시 → run_prepass.sh가 uv 자동 설치를 유도하거나 오류 JSON을 반환한다. PREFLIGHT가 비어 있으면 각 Phase의 bash fallback으로 진행한다.

---

Phase G: Goal Gate (목표 추출 + 명확화) — v5.3

Phase INIT 직후, Phase -3 이전에 항상 실행한다. 유저 요청의 목표(WHAT)를 확정하는 것이 유일한 목적이다.

실행

LATEST_CEO=$(_f "['plugins']['experiencing']" 2>/dev/null || \
  ls -d "$HOME/.claude/plugins/marketplaces/CSnCompany_2-0/plugins/cs-ceo-v"* 2>/dev/null | sort -V | tail -1)
GOAL_SKILL="$LATEST_CEO/skills/goal/SKILL.md"

GOAL_SKILL 프로토콜(skills/goal/SKILL.md)을 읽고 아래 순서로 실행:

① 목표 신호 분석 (goal/SKILL.md STEP 1 기준)

명확 패턴	처리
URL + 동사, 도메인 + 기능, 구체적 작업, with 파트너 포함 요청	즉시 GOAL 확정 → Phase -3으로 진행

불명확 패턴	처리
동사만, 맥락 없는 키워드, 무한정 범위	→ ② 단계로 진행

② 불명확 시 AskUserQuestion 1회

AskUserQuestion(
  question: "어떤 목표를 달성하고 싶으신가요?\n현재 요청: '[원문]'",
  options: ["현재 요청 그대로 진행", "작업 취소"]
)

• Other(직접 입력) → 입력값을 goal_statement로 확정
• "현재 요청 그대로 진행" → 원문 그대로 사용
• "작업 취소" → 즉시 종료

③ GOAL 객체 확정 후 Phase -3으로 진행

GOAL_STATEMENT = "[한 문장 목표]"  # Phase 1~5 전체에서 기준점으로 사용

Phase 전체 영향

• Phase 1 공수 추정: GOAL_STATEMENT 기준으로 영향 범위·도메인 수 판단
• Phase 4 리포트: 첫 줄에 **목표**: [GOAL_STATEMENT] 항상 출력
• Phase 5-B 버전업: 목표가 불명확해서 중간에 방향 전환이 있었다면 → 버전업 트리거

---

Phase -3: 외부 지식 게이트 (External Knowledge Gate) — v5.2

모든 요청에서 가장 먼저 평가한다. "외부 도움이 필요할 것 같다"고 판단되면 지체 없이 /context7-auto-research를 호출한다.

트리거 조건 (다음 중 하나라도 해당되면 즉시 발동)

신호	예시
라이브러리/프레임워크 이름 포함	React, Next.js, Prisma, Stripe, Supabase, Tailwind, Drizzle, FastAPI 등
"최신 버전" / "latest" / "recent changes" / "breaking change"	"Next 15 app router 변경점"
모르는 API/스킬/도메인 용어가 등장	CEO 노하우/내장 지식으로 답이 안 나옴
기술적 의사결정 직전 ("어느 게 나아?", "대안")	라이브러리 비교, 패턴 비교
빌드/런타임 에러 + 외부 패키지 stack trace	node_modules/... 에서 발생
파트너 스킬이 내부 노하우만으로 부족	도메인 에이전트가 외부 문서 인용 필요
유저가 명시적으로 "공부해서", "조사해서", "찾아봐"	직접 의도 표현

실행 절차

① 트리거 평가 (위 표 + CEO 자율 판단)
② 설치 여부 확인 (Phase INIT 결과 사용 — 추가 find 불필요):
   CONTEXT7_INSTALLED=$(_f "['context7_installed']")
   CONTEXT7_SKILL=$(_f "['partners']['context7']")

③ 미설치 → 설치 유도 (블로킹 옵션):
   AskUserQuestion(
     question: "📚 외부 지식 게이트 발동 — context7-auto-research가 설치되지 않았습니다. 설치할까요?",
     options: [
       "Install (권장) — 'npx skills add -g BenedictKing/context7-auto-research' 실행 후 진행",
       "Skip this once — 이번엔 외부 학습 없이 진행 (정확도 하락 가능)",
       "Abort — 요청 중단"
     ]
   )

   - "Install" 선택 → Bash로 `npx skills add -g BenedictKing/context7-auto-research` 실행 → 재확인 후 진행
   - "Skip" 선택 → ⚠️ 알림: "외부 학습 생략됨. 결과 정확도가 떨어질 수 있습니다." 후 Phase -2로 진행
   - "Abort" 선택 → 즉시 종료

④ 설치됨 → 한 줄 알림:
   "📚 외부 지식 필요 감지: [주제] — context7-auto-research로 학습 후 진행합니다."
⑤ Skill 도구로 호출:
   Skill(skill="context7-auto-research", args="[주제 키워드]")
⑥ 반환된 문서를 읽고 핵심 발췌를 메모리에 보관
⑦ 이 학습 결과를 Phase -2 ~ Phase 4 전체 흐름에 INPUT으로 사용
⑧ 결과 리포트의 "파트너 기여" 줄에 "context7: [학습 요약]" 한 줄로 기록

설치 유도 메시지 템플릿 (미설치 시 표시)

📚 외부 지식 게이트가 발동했지만 context7-auto-research가 설치되지 않았습니다.

이 스킬은 React/Next.js/Prisma/Stripe 등 라이브러리의 최신 문서를 자동으로 가져와
도메인 에이전트가 잘못된 가정으로 작업하는 것을 방지합니다.

설치 명령:
  npx skills add -g BenedictKing/context7-auto-research

설치 후 `/cs-ceo`를 다시 실행하거나, 지금 자동 설치를 진행할 수도 있습니다.
저장소: https://github.com/BenedictKing/context7-auto-research

외부 지식 게이트 스킵 조건

• 이미 같은 세션에서 동일 주제 context7 결과가 메모리에 있다 (재호출 금지)
• 요청이 순수 인프라 진단/파일 검증 (외부 문서 불필요)
• 유저가 명시적으로 "조사 없이" / "그냥 진행" 지시

Phase 5-B 버전업 연동

게이트가 발동했고 그 결과가 판단/실행 품질에 영향을 줬다면 → 자동으로 버전업 트리거. Phase 5-B에서 "context7 학습 → 적용 결과" 한 줄을 노하우 후보로 보관해 다음 version-up 시 영구 학습화.

---

Phase -2: 파트너십 탐지 (Partnership Detection)

모든 요청을 처리하기 전에 먼저 실행한다.

① 명시적 파트너 파싱

요청에서 with [partner]: 또는 with [p1,p2,...]: 패턴을 추출한다. 파트너 이름은 어떤 스킬 이름이든 가능하다 — 사전 등록 불필요.

입력: "with superpowers: 이 기능 어떻게 접근할지 모르겠어"
파싱: partners=["superpowers"], task="이 기능 어떻게 접근할지 모르겠어"

입력: "with cs-clarify,deep-research: 요구사항 정리 후 리서치"
파싱: partners=["cs-clarify","deep-research"], task="요구사항 정리 후 리서치"

입력: "with tdd-workflow,gstack: TDD로 개발하고 결과 구글 시트에 저장"
파싱: partners=["tdd-workflow","gstack"], task="TDD로 개발하고 결과 구글 시트에 저장"

② 자동 감지 (명시 없는 경우 — 잘 알려진 패턴)

키워드/패턴	자동 파트너	타이밍
"어떻게 접근" / "잘 모르겠어" / "막막해"	superpowers:brainstorming	Pre
"구글 시트" / "드라이브" / "Gmail" / "캘린더" / "Google Docs"	gstack	Post
"버그" + 스택트레이스 / "근본 원인" / "깊이 파봐"	omc:deep-dive	Pre
"PDCA" / "전체 사이클로" / "품질 게이트"	bkit:pdca	Wraps
"요구사항 불명확" / "scope 정의" / "뭘 만들어야"	cs-clarify	Pre

자동 감지 시 한 줄 알림 후 진행:

🤝 파트너 자동 감지: [partner] — [이유 한 줄] 후 CS 도메인 실행합니다.

③ 파트너십 타이밍 결정

명시된 파트너의 경우, Partnership Registry에서 경로를 찾은 뒤 SKILL.md description 필드를 읽어 타이밍을 자동 추론한다.

description 키워드	추론 타이밍
분석 / 설계 / 계획 / research / plan / discover / clarify / interview	Pre
저장 / export / 문서화 / report / notify / publish / 시트 / 드라이브	Post
전체 / 사이클 / workflow / pipeline / PDCA / wraps	Wraps
(그 외 / 독립적 도구)	In (병렬 기본값)

타이밍 추론이 불명확한 경우 In으로 기본 설정한다.

• Pre (선행): 파트너 결과가 CEO 플랜의 INPUT → 파트너 먼저
• In (병렬): 파트너와 CS 도메인 독립 병렬 실행
• Post (후처리): CEO 실행 완료 후 파트너 추가 처리
• Wraps (포장): 파트너 방법론이 전체 실행을 감싸는 구조

파트너 없음 → 아무 출력 없이 Phase -1로 진행.

---

Partnership Registry (Universal — 모든 스킬 지원)

Phase 0에서 파트너 경로를 함께 검색한다. 알려진 파트너는 Fast-Path, 미등록 파트너는 Dynamic Resolve로 처리한다.

Fast-Path (알려진 파트너)

# Phase INIT 결과에서 일괄 추출 — find/sort/ls 불필요
SP_SKILLS=$(_f "['partners']['superpowers']['base']")
SP_BRAINSTORM=$(_f "['partners']['superpowers']['brainstorming']")
SP_WRITEPLAN=$(_f "['partners']['superpowers']['writing_plans']")
SP_EXECUTE=$(_f "['partners']['superpowers']['executing_plans']")
SP_DEBUG=$(_f "['partners']['superpowers']['systematic_debugging']")
SP_PARALLEL=$(_f "['partners']['superpowers']['dispatching_parallel']")

BKIT_PDCA=$(_f "['partners']['bkit']['pdca']")
BKIT_QA=$(_f "['partners']['bkit']['qa']")

OMC_SKILLS=$(_f "['partners']['omc']['base']")
OMC_DEEPDIVE=$(_f "['partners']['omc']['deep_dive']")
OMC_AUTORESEARCH=$(_f "['partners']['omc']['autoresearch']")
OMC_AUTOPILOT=$(_f "['partners']['omc']['autopilot']")
OMC_PLUGIN=$(_f "['partners']['omc']['plugin_name']")   # "oh-my-claudecode"
# OMC 에이전트 직접 호출용 (v5.5): Task(subagent_type="oh-my-claudecode:<agent>")
# 사용 가능 에이전트: analyst, architect, code-reviewer, debugger, executor, explore, designer, ...
# 예: Task(subagent_type="oh-my-claudecode:debugger") — 버그 심층 분석
#     Task(subagent_type="oh-my-claudecode:architect") — 아키텍처 설계
#     Task(subagent_type="oh-my-claudecode:executor") — 코드 실행 위임

GSTACK_SKILL=$(_f "['partners']['gstack']")
CLARIFY_SKILL=$(_f "['partners']['clarify']")
CONTEXT7_SKILL=$(_f "['partners']['context7']")

Dynamic Resolve v2 (미등록 파트너 — 타입 감지 포함) — v5.5

명시된 파트너가 Fast-Path에 없으면 prepass resolve-partner 명령으로 탐색한다. SKILL.md뿐 아니라 agents/ 파일도 탐색하며, 세 가지 타입 중 하나를 반환한다.

# resolve-partner 실행 — SKILL.md + agents/ 파일 + plugin.json 통합 탐색
_resolve() {
  local NAME="$1"
  bash "$PREPASS_RUNNER" resolve-partner "$NAME" 2>/dev/null || echo '{"found":false,"type":"UNKNOWN"}'
}

_ptype()  { printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('type','UNKNOWN'))" 2>/dev/null; }
_pinvoke(){ printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('invocation',''))"  2>/dev/null; }
_ppath()  { printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('path',''))"        2>/dev/null; }
_pfound() { printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('found',False))"   2>/dev/null; }
_pagents(){ printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(' '.join(d.get('agents',[])))" 2>/dev/null; }

파트너 타입 정의:

타입	조건	실행 방법
AGENT	agents/ 디렉토리 + plugin.json 존재	Task(subagent_type=invocation)
SKILL	plugin.json 있음, agents/ 없음	Skill(skill=invocation)
PROTOCOL	SKILL.md만 존재, plugin.json 없음	Read SKILL.md → CEO가 직접 프로토콜 따름

탐색 결과 처리:

✅ 파트너 해결됨: [NAME] (타입: AGENT/SKILL/PROTOCOL) → [invocation_or_path]
⚠️  파트너 미발견: [NAME] — 해당 스킬/에이전트를 설치하거나 이름을 확인하세요. 파트너 없이 계속합니다.

타이밍 자동 추론

파트너 경로가 확보되면 SKILL.md description 필드를 읽어 타이밍을 결정한다.

infer_timing() {
  local SKILL_PATH="$1"
  local DESC
  DESC=$(grep -A3 "^description:" "$SKILL_PATH" 2>/dev/null | tr '[:upper:]' '[:lower:]')

  # Wraps 패턴 (가장 먼저 체크)
  echo "$DESC" | grep -qE "사이클|전체|workflow|pipeline|pdca|wraps|lifecycle" && echo "Wraps" && return

  # Pre 패턴
  echo "$DESC" | grep -qE "분석|설계|계획|research|plan|discover|clarify|interview|brainstorm|조사|정의|탐색|gather" && echo "Pre" && return

  # Post 패턴
  echo "$DESC" | grep -qE "저장|export|문서화|report|notify|publish|시트|드라이브|slack|email|알림|공유|정리" && echo "Post" && return

  # 기본값
  echo "In"
}

범용 협업 실행 프로토콜 v2 — 타입별 분기

파트너가 Dynamic Resolve로 확보된 경우, 타입에 따라 다른 실행 방법을 사용한다.

PARTNER_INFO=$(_resolve "$PARTNER_NAME")
PARTNER_TYPE=$(_ptype "$PARTNER_INFO")
PARTNER_INVOKE=$(_pinvoke "$PARTNER_INFO")
PARTNER_PATH=$(_ppath "$PARTNER_INFO")
PARTNER_FOUND=$(_pfound "$PARTNER_INFO")

타입별 실행 방법

① AGENT 타입 — 다른 플러그인의 에이전트를 직접 호출

Task(
  subagent_type: "[PARTNER_INVOKE]",    # 예: "oh-my-claudecode:debugger"
  prompt: """
  [USER_TASK]
  
  실행 컨텍스트:
  - 요청 주체: CS-CEO
  - 타이밍: [Pre/In/Post]
  - 기대 OUTPUT: [Pre→분석/계획 결과 | In→독립 결과 | Post→CEO 결과 처리]
  
  [Pre 타이밍인 경우] 결과를 CEO가 다음 단계 INPUT으로 사용합니다.
  [Post 타이밍인 경우] CEO 실행 결과: [CEO_RESULT 요약]
  """
)

사용 예:

# with executor: 코드 구현 위임
Task(subagent_type="oh-my-claudecode:executor", prompt="...")

# with debugger: 버그 심층 분석
Task(subagent_type="oh-my-claudecode:debugger", prompt="...")

# with architect: 아키텍처 설계
Task(subagent_type="oh-my-claudecode:architect", prompt="...")

② SKILL 타입 — 스킬 직접 호출

Skill(skill="[PARTNER_INVOKE]", args="[USER_TASK]")
# 예: Skill(skill="superpowers:brainstorming", args="...")

③ PROTOCOL 타입 — SKILL.md 읽고 CEO가 프로토콜 직접 따름

Read(PARTNER_PATH)  # SKILL.md 전체 읽기
→ description / 주요 섹션 분석 (목적, INPUT, OUTPUT)
→ CEO가 프로토콜 직접 실행

또는 프로토콜이 복잡한 경우 Task로 위임:

Task(
  description: "[PARTNER_NAME] 프로토콜 실행",
  prompt: """
  아래는 [PARTNER_NAME] 스킬의 전체 프로토콜입니다:
  ---
  [SKILL.md 전체 내용]
  ---
  실행 컨텍스트:
  - 유저 요청: [USER_TASK]
  - 타이밍: [Pre/In/Post/Wraps]
  - 기대 OUTPUT: ...
  프로토콜에 따라 실행하고 결과를 반환하세요.
  """
)

파트너별 주요 스킬/에이전트 (Fast-Path 참고):

파트너 키	타입	핵심 스킬/에이전트	기본 타이밍
superpowers	SKILL	brainstorming, writing-plans, executing-plans	Pre
bkit	PROTOCOL	pdca, qa-phase	Wraps
omc / deep-dive	AGENT	oh-my-claudecode:debugger	Pre
omc / autoresearch	AGENT	oh-my-claudecode:analyst	Pre
omc / autopilot	AGENT	oh-my-claudecode:executor	Pre/In
executor	AGENT	oh-my-claudecode:executor	In
architect	AGENT	oh-my-claudecode:architect	Pre
debugger	AGENT	oh-my-claudecode:debugger	Pre
gstack	PROTOCOL	gstack (단일)	Post
cs-clarify	AGENT	cs-clarify:clarify-lead	Pre
(미등록)	자동 탐색	Dynamic Resolve v2 → 타입 자동 판정	자동 추론

---

Phase -1: 컨텍스트 상태 점검

도메인 에이전트를 스폰하기 전에 현재 세션 상태를 평가한다.

상황	신호	권장 조치
이전 cs-ceo 실행 결과가 컨텍스트에 쌓여 있음	도메인 리포트, 도구 출력 누적	/compact 권장 후 진행
완전히 다른 주제/프로젝트로 전환	이전 컨텍스트와 무관한 새 요청	/clear 권장
연속 작업 (이전 결과가 지금도 필요)	같은 코드베이스, 같은 목표	그냥 진행
Task()로 서브에이전트 위임 예정	모드 A/B/C/P 모두 해당	그냥 진행

컨텍스트가 무겁다고 판단되면 리포트 상단에 한 줄만 추가. 그 외 아무 출력 없이 Phase 0으로 진행.

cmux 환경 감지

if [ -n "$CMUX_SOCKET_PATH" ]; then
  cmux set-status "cs-ceo" "running" --icon "gear"
  cmux set-progress 0.0 --label "CEO 분석 중..."
  CMUX_ENV=true
fi

---

Phase 0: 도메인 경로 확인

# Phase INIT 결과에서 추출 — ls/sort -V 불필요
LATEST_TEST=$(_f "['plugins']['test']")
LATEST_PLAN=$(_f "['plugins']['plan']")
LATEST_REVIEW=$(_f "['plugins']['review']")
LATEST_DESIGN=$(_f "['plugins']['design']")
LATEST_SMARTRUN=$(_f "['plugins']['smartrun']")

파트너십이 감지된 경우, Partnership Registry의 Bash 블록도 이 Phase에서 함께 실행해 경로를 확보한다.

---

Phase 1: 공수 추정 (자율 판단)

① 영향 범위 — 파일/컴포넌트 수, 코드베이스 전체 vs 특정 기능
② 필요 도메인 수 — 1개(小) / 2~3개(中) / 3개 이상(大)
③ 단계 간 의존관계 — 병렬 가능 vs 순차 필요
④ 요청의 불확실성 — 목표 명확 vs 탐색적 vs 전략적 판단 필요
⑤ 노하우 섹션 참조 — 유사 케이스, 파트너십 효과 패턴

---

Phase 2: 실행 모드 결정

모드 A — 직접 단독 실행 (공수 小)

조건: 도메인 1개, 범위 명확, 목표 확실, 파트너 없음

해당 도메인 SKILL.md 읽기 → Task()로 도메인 lead 에이전트 스폰

모드 B — CEO 직접 오케스트레이션 (공수 中)

조건: 도메인 2~3개, 명확한 순서 또는 병렬 관계, 파트너 없음

각 도메인 SKILL.md 읽기 → 병렬 가능 시 단일 블록 Task() 동시 스폰
→ 순차 필요 시 이전 결과를 컨텍스트로 전달 → CEO 종합 리포트

모드 C — cs-smart-run 위임 (공수 大)

조건: 3개 이상 도메인 복잡하게 얽힘 / 모호한 전략 판단 / 복잡한 의존관계 / 노하우 기록

SMARTRUN_SKILL="$LATEST_SMARTRUN/skills/smart-run/SKILL.md"

모드 P-Pre — 파트너 선행 후 A/B/C

조건: 파트너 감지 + 파트너 결과가 CEO 플랜의 INPUT

파트너 SKILL.md 읽기 → Skill() 또는 Task()로 파트너 실행
→ 출력 결과 확보 → 공수 재추정 → 모드 A/B/C 결정 → 실행

예: superpowers:brainstorming → 설계 문서 → CEO-B (plan+test)

모드 P-In — 파트너와 병렬 실행

조건: 파트너 감지 + 파트너와 CS 도메인 독립 병렬 가능

단일 응답 블록에서 동시 스폰:
Task() → 파트너 / Task() → CS 도메인들
→ 결과 수집 → CEO 종합

예: gstack (시트 준비) ‖ CS-codebase-review 동시 실행

모드 P-Post — CEO 먼저, 파트너 후처리

조건: 파트너 감지 + 파트너가 CEO 결과를 처리

모드 A/B/C 실행 → CEO 리포트 산출 → Skill()로 파트너 호출

예: CS-test 완료 → gstack으로 결과 구글 드라이브 문서화

모드 P-Wraps — 파트너 방법론이 전체를 감싸는 구조

조건: bkit:pdca 또는 전체 PDCA 사이클 요청

bkit:pdca SKILL.md 읽기 → PDCA 방법론 안에서 CEO가 CS 도메인 오케스트레이션
Plan: CS-plan / Do: CEO 오케스트레이션 / Check: CS-test + CS-codebase-review / Report: CEO 종합

---

Phase 3: 실행

CS 도메인 라우팅 참고표:

요청 패턴	도메인	방식
URL / "테스트"	CS-test	모드 A
URL / "테스트" (cmux 환경)	CS-test (cmux browser 모드)	모드 A
"플랜" / "설계" / "기능 추가" (명확)	CS-plan	모드 A
"코드 리뷰" / "품질 체크"	CS-codebase-review	모드 A
"디자인 리뷰" / "UI 검토"	cs-design	모드 A
"전체 분석"	review → design → test	모드 B 순차
"뭐가 문제야" / "이상해"	review + test	모드 B 병렬
"기능 만들어줘" (범위 명확)	plan → design → test	모드 B 순차
아키텍처 개편 / 대규모 리팩터링 / 전략	cs-smart-run	모드 C

파트너십 라우팅 추가표:

요청 패턴	파트너	타이밍	CS 도메인 조합
"어떻게 접근" / "잘 모르겠어"	superpowers:brainstorming	Pre	브레인스토밍 → plan or B/C
"계획부터 짜줘" / "단계적으로"	superpowers:writing-plans	Pre	플랜 문서 → CEO 실행
"버그" + 복잡한 증상	omc:deep-dive	Pre	딥다이브 → review + test
"구글 시트에 정리" / "드라이브 저장"	gstack	Post	A or B → gstack 문서화
"Gmail" / "캘린더" / "Google Docs"	gstack	In	gstack ‖ 필요 CS 도메인
"전체 사이클" / "PDCA로"	bkit:pdca	Wraps	pdca가 CEO 감싸기
"요구사항 불명확" / "scope 먼저"	cs-clarify	Pre	clarify → 재추정 → A/B/C
"리서치 필요" / "조사해줘"	omc:autoresearch	Pre	리서치 → 관련 CS 도메인

---

Phase 4: CEO 종합 리포트

[ -n "$CMUX_SOCKET_PATH" ] && cmux set-progress 0.9 --label "CEO 리포트 생성 중..."

## CEO 실행 리포트

**목표**: [GOAL_STATEMENT]
**요청**: [유저 요청 원문]
**공수 판정**: 小/中/大
**선택 모드**: A / B / C / P-Pre / P-In / P-Post / P-Wraps
**실행 도메인**: [도메인 목록과 순서]
**판단 근거**: [①~⑤ 추정 결과 요약]

---
**파트너십**: [파트너 없음] 또는 [파트너명:스킬 → CEO-모드 → (후처리 파트너)]
**파트너 기여**: [파트너가 제공한 핵심 인사이트/결과 1-2줄]  ← 파트너 있을 때만
---

[각 도메인 결과 요약]

---

**CEO 종합 평가**: [전체 결과에 대한 CEO 판단]
**권장 다음 액션**: [우선순위 상위 3개]

if [ -n "$CMUX_SOCKET_PATH" ]; then
  cmux set-progress 1.0 --label "CEO 실행 완료"
  cmux notify --title "CS-CEO 완료" --body "[모드] — 다음: [권장 액션 1위]"
  cmux set-status "cs-ceo" "done" --icon "checkmark"
fi

---

Phase 5: 실행 후 컨텍스트 관리 + 버전업 결정

5-A: 컨텍스트 관리 권장

모드	권장
A	세션 유지. 다른 작업이면 /clear 제안
B	/compact 권장
C	/clear 권장
P-Pre	/compact 권장
P-In	/compact 권장
P-Post	A+Post면 유지, B+Post면 /compact
P-Wraps	/clear 권장

리포트 끝에 한 줄 출력 (B/C/P 모드만):

💡 컨텍스트 정리: `/compact focus on [도메인] 결과 + 다음 액션: [권장사항 1위]`
# 또는 C/P-Wraps:
💡 컨텍스트 정리: 대규모 작업 완료. `/clear` 후 핵심 결론만 가져가세요: "[결론 1줄]"

5-B: 버전업 결정

트리거	예시
공수 추정이 빗나갔다	小로 봤는데 실제론 中
새 요청 패턴 발견	라우팅 표에 없던 케이스
도메인/파트너 조합 효과가 예상과 달랐다	superpowers:brainstorming이 불필요했음
파트너 자동 감지가 틀렸다	gstack이 필요 없었는데 감지됨
파트너십 조합이 탁월했다	기록할 만한 효과적 패턴 발견
외부 지식 게이트 발동 (v5.2)	context7-auto-research로 학습한 라이브러리/패턴이 판단을 바꿨다
외부 지식 게이트 누락 (v5.2)	학습 없이 진행했다가 잘못된 가정으로 빗나갔음 — 트리거 표 보강 필요

트리거 있음 → 리포트 끝에:

💡 버전업 제안: `/cs-experiencing version-up all` 로 오늘 패턴을 노하우로 저장하세요.

---

CEO 노하우

버전업마다 이 섹션에 학습이 추가됩니다. CEO는 유사 상황에서 이 섹션을 참조해 판단 품질을 높입니다.

형식:

### [N]. [학습 제목] ([YYYY-MM-DD])
- **상황**: [어떤 요청]
- **판단**: [모드 선택, 도메인/파트너 조합]
- **결과**: [효과적이었는가]
- **교훈**: [다음 유사 상황에서의 판단 기준]

1. 인프라 진단 태스크는 도메인 에이전트 없이 직접 Bash 실행이 효율적 (2026-04-24)

• 상황: localhost:9000 점검 + GitHub sync + 폴더 선택 기능 에러 개선 확인 요청
• 판단: 도메인 에이전트 스폰 없이 직접 Bash 명령으로 진단 (git log, curl, lsof)
• 결과: git pull 1개 누락 커밋이 근본 원인임을 즉시 진단. 효율적이었음.
• 교훈: 서버 상태 확인, git sync, 파일 존재 여부 같은 인프라 진단은 CEO가 직접 Bash 실행. 도메인 에이전트는 심층 분석이 필요할 때만 스폰할 것.

2. 코드 변경 검증 요청은 Mode A + 직접 분석 (2026-04-24)

• 상황: 워크트리 UX 개선 코드 변경 후 6개 항목 검증 요청
• 판단: Mode A — 도메인 에이전트 없이 Bash+Read로 직접 코드 분석
• 결과: 6개 항목 모두 빠르게 검증 완료. 효율적이었음.
• 교훈: "implemented code verify" 패턴은 항상 Mode A. Bash grep + Read로 충분하며 도메인 에이전트 스폰이 오버헤드임.

3. 외부 지식 게이트 — context7-auto-research 자동 호출 (2026-04-25)

• 상황: CEO 내부 노하우만으로는 라이브러리/프레임워크 최신 동향, 새 API, 마이너 변경점을 정확히 답할 수 없음.
• 판단: Phase -3을 신설해 모든 요청 진입 직전에 "외부 지식 필요 여부"를 평가하고, 트리거 신호 1개라도 감지되면 즉시 context7-auto-research를 Skill 도구로 호출.
• 결과: 도메인 에이전트/파트너에게 정확한 최신 문서를 INPUT으로 전달 → 잘못된 가정 기반 실행이 줄고, 버전업 시 학습량이 누적됨.
• 교훈:
  1. "지체말고 호출" — 의심되면 호출이 기본값 (호출 비용 < 잘못된 실행 비용).
  2. 동일 세션 내 재호출 금지로 토큰 낭비 방지.
  3. 게이트 발동/누락 모두 Phase 5-B 버전업 트리거 → 다음 세션에 노하우로 영속화.
  4. 미설치 환경 대응: context7-auto-research가 없으면 무단으로 건너뛰지 말고 AskUserQuestion으로 Install/Skip/Abort 3지선다 제시. 설치 명령은 npx skills add -g BenedictKing/context7-auto-research. Skip 선택 시 정확도 하락 경고 1줄 후 진행.

12. HTTP-first 자동화 아키텍처: 서버리스 호환 fetch → Playwright 폴백 → AI 진단 게이트 (2026-04-26)

• 상황: Playwright 전용 파킹 자동화 앱을 Vercel 배포에서도 동작하도록 전환 요청
• 판단: Playwright는 서버리스 환경에서 Chromium 바이너리 실행 불가 → plain fetch로 HTTP 세션 자동화 먼저 시도. 실패 시 UI에 "Claude Code에 전달" 버튼으로 진단 프롬프트를 클립보드에 복사하는 UX 패턴 설계.
• 결과: fetch 구현은 AJPark 로그인 인코딩(Base64 ID) 문제로 추가 디버깅 필요했으나 아키텍처 방향은 유효. 진단 버튼 패턴은 비기술 사용자가 오류를 개발자(Claude Code)에게 전달하는 효과적인 채널이 됨.
• 교훈: Playwright 필수처럼 보이는 작업도 HTTP-first로 먼저 시도. 실패 경로에 "AI 진단 게이트(클립보드 복사 프롬프트)" 설계 → 사용자가 직접 Claude Code에 붙여넣으면 자동 디버깅 루프 완성.

13. Electron auto-paste 디버깅 — 3-레이어 격리 전략 (2026-04-27)

• 상황: Electron 앱에서 단축키 → 클립보드 → 붙여넣기 파이프라인이 동작하지 않아 root cause 특정이 어려움.
• 판단: 3-레이어 격리 방식 적용: ① pbpaste로 클립보드 직접 확인(Electron clipboard.writeText 정상 여부) ② osascript 단독 실행(AppleScript 문법 + 권한 여부) ③ Electron exec() 통합 테스트(자식 프로세스 sandbox 이슈 여부). Layer 2 성공 + Layer 3 실패 → Electron 자식 프로세스 권한 문제로 즉시 특정.
• 결과: keystroke "v" using command down은 Layer 2에서는 동작하지만 Layer 3(Electron exec)에서 silent fail → click menu item "Paste"로 교체 후 해결.
• 교훈: Electron 앱에서 osascript 오작동 시 반드시 3-레이어 격리부터. 특히 exit 0이지만 효과 없는 경우 sandbox/권한 문제 → AppleScript 메뉴 클릭 방식으로 우회.

14. 야간 위임 — 사용자 sleep 중 Phase별 자율 진행 + 아침 보고서 (2026-04-28)

• 상황: 사용자가 "난 자야하니까 잘 처리해 아침에 보자"로 위임. 5-phase 작업을 사용자 컨펌 없이 자율 진행해야 함.
• 판단: 안전한 작업(코드 변경, 빌드, git push)은 자율 진행. destructive 동작은 결과 검증 필수. Phase 단위로 commit/push 분리 → 아침에 사용자가 git log로 진행 트레이스 가능.
• 결과: 5-phase 모두 완료, 6커밋 푸시, 앱 설치 + 실행 검증, 아침 보고서에 시나리오별 검증 절차 명시.
• 교훈: 야간 위임 시 (1) Phase별 commit으로 트레이스 보장 (2) destructive는 검증까지 묶음 (3) 마지막 메시지에 시나리오 체크리스트 포함. ScheduleWakeup 270초 간격이 cache TTL 적정.

15. 빌드 시스템 크로스 디바이스 버그 — Mode B 인라인 분석으로 절대경로 즉시 진단 (2026-05-01)

• 상황: Tauri 앱 DMG 빌드가 iCloud ETIMEDOUT + E0601(main 미발견)로 반복 실패. 다른 Mac에서도 빌드 오류 보고됨.
• 판단: Mode B — CS-codebase-review 인라인 분석. .cargo/config.toml의 하드코딩 절대경로가 크로스 디바이스 실패의 근본 원인으로 즉시 특정.
• 결과: 크로스 디바이스 문제 해결. fix-dmg stale 파일 버그 + 로그 offset UTF-8 버그 동시 발견 및 수정. 8파일 커밋 + 푸시.
• 교훈: "다른 기기에서도 재현"은 환경 고유값 하드코딩(절대경로, username, 홈 디렉토리)을 1순위 의심. .cargo/config.toml, CMakeLists.txt, Makefile 절대경로를 코드 리뷰 체크리스트 필수 항목으로.

16. Tauri 앱 필드 사라짐 버그 — TypeScript ↔ Rust struct 필드 불일치 1순위 확인 (2026-05-01)

• 상황: 즐겨찾기(favorite) 추가 후 앱 재시작 시 사라지는 버그.
• 판단: Mode A 직접 분석. CEO 직접 Bash+Read로 3단계 원인 추적.
• 결과: 3중 원인 발견. 핵심 근본 원인 — Rust PortInfo 구조체에 favorite 필드 없어서 save_ports 호출 시 JSON 역직렬화 과정에서 필드 드롭.
• 교훈: Tauri 앱에서 특정 필드가 저장 안 될 때 → 1순위: src-tauri/src/lib.rs의 struct PortInfo 필드 목록과 TS interface PortInfo 비교. Rust 구조체 누락 필드는 serde 역직렬화 시 silently drop됨.

17. GUI 앱 PATH Desert — Tauri invoke()는 zsh -l -c로 실행해야 사용자 PATH 확보 (2026-05-14)

• 상황: Tauri 앱에서 claude --bg가 "claude not found in PATH" 오류. CLI/API 서버 경로에서는 정상 동작. Playwright 테스트도 통과했으나 앱에서만 계속 실패.
• 판단: Mode A 직접 분석. isTauri() 분기 발견 → Tauri invoke() 경로(lib.rs)와 HTTP 경로(api-server.ts)가 완전히 독립적. PATH enhancedPath로 부족, zsh -l -c 필요.
• 결과: open_claude_bg()를 Command::new("/bin/zsh").args(["-l", "-c", &shell_cmd])로 수정 → DMG v80 빌드 완료. 같은 파일의 suggest_names_batch()가 이미 동일 패턴 사용 중이었음.
• 교훈: Tauri(Finder 실행) = 최소 PATH(/usr/bin:/bin). CLI에서 작동 + Playwright 통과 + 앱에서만 실패 → isTauri() 분기 확인 → Rust invoke() 경로는 zsh -l -c 필수. Playwright는 HTTP 경로만 검증 — Rust invoke() 경로는 별도 테스트 필요.