@walwal-harness/cli 6.0.4 → 6.1.0

package/scripts/harness-session-start.sh

@@ -25,7 +25,8 @@ sprint_num=$(jq -r '.sprint.number // 0' "$PROGRESS" 2>/dev/null)
 current_agent=$(jq -r '.current_agent // "none"' "$PROGRESS" 2>/dev/null)
 next_agent=$(jq -r '.next_agent // "none"' "$PROGRESS" 2>/dev/null)
 agent_status=$(jq -r '.agent_status // "pending"' "$PROGRESS" 2>/dev/null)
-mode=$(jq -r '.mode // "solo"' "$PROGRESS" 2>/dev/null)
+mode=$(jq -r '.mode // "team"' "$PROGRESS" 2>/dev/null)
+conductor_state=$(jq -r '.conductor.state // "idle"' "$PROGRESS" 2>/dev/null)
 
 # ─────────────────────────────────────────
 # Auto-heal mode drift — Team 상태 유실 복구
@@ -65,8 +66,8 @@ if [ "$mode" = "team" ]; then
 
   echo "# Harness Team Mode active"
   echo "# Queue: ${passed}/${total} passed, ${in_prog} in progress, ${failed} failed"
-  echo "# Teams run autonomously (Gen-Eval loop, max 5 retries)."
-  echo "# Stop: /harness-stop | Switch to solo: /harness-solo"
+  echo "# Worker pool runs autonomously (Gen-Eval loop, max 5 retries). Control-plane Cxx agents are outside this limit."
+  echo "# Stop: /harness-stop | Emergency fallback: /harness-solo"
   exit 0
 fi
 
@@ -74,7 +75,7 @@ fi
 # Paused Mode — 중단 상태 안내
 # ─────────────────────────────────────────
 if [ "$mode" = "paused" ]; then
-  echo "# Harness paused — resume with /harness-team or /harness-solo"
+  echo "# Harness paused — resume with /harness-team"
   exit 0
 fi
 
@@ -83,7 +84,7 @@ fi
 # ─────────────────────────────────────────
 if [ "$sprint_status" = "init" ]; then
   echo "# Harness ready — say \"하네스 엔지니어링 시작\" or /harness-dispatcher"
-  echo "# 기본은 Solo 모드. 병렬 3팀 실행을 원하면 Planner 완료 후 /harness-team."
+  echo "# 기본 경로는 회사 루프입니다: dispatch -> CEO meeting -> COO/CTO 분배 -> gen/eval -> CQO -> service-ops -> batch meeting."
   exit 0
 fi
 
@@ -107,6 +108,16 @@ if [ "$agent_status" = "completed" ] || [ "$agent_status" = "failed" ]; then
   agent_status=$(jq -r '.agent_status // "pending"' "$PROGRESS" 2>/dev/null)
 fi
 
+# ─────────────────────────────────────────
+# Conductor running/queued → refresh routing once on session start
+# ─────────────────────────────────────────
+if [ "$conductor_state" = "running" ] || [ "$next_agent" = "conductor" ]; then
+  if [ -x "$SCRIPT_DIR/conductor-tick.sh" ]; then
+    bash "$SCRIPT_DIR/conductor-tick.sh" "$PROJECT_ROOT" >/dev/null 2>&1 || true
+    next_agent=$(jq -r '.next_agent // "none"' "$PROGRESS" 2>/dev/null)
+  fi
+fi
+
 # ─────────────────────────────────────────
 # 상태별 안내 출력
 # ─────────────────────────────────────────

package/scripts/harness-task-session.sh

@@ -0,0 +1,48 @@
+#!/bin/bash
+# harness-task-session.sh — create per-agent task session document
+set -euo pipefail
+
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
+source "$SCRIPT_DIR/lib/harness-render-progress.sh"
+
+PROJECT_ROOT="$(resolve_harness_root "${1:-.}")" || exit 1
+AGENT="${2:-}"
+SOURCE="${3:-}"
+
+[ -n "$AGENT" ] || exit 2
+command -v jq >/dev/null 2>&1 || exit 1
+
+PROGRESS="$PROJECT_ROOT/.harness/progress.json"
+TASK_ROOT="$PROJECT_ROOT/.harness/actions/task-sessions/$AGENT"
+mkdir -p "$TASK_ROOT"
+
+dispatch_id=$(jq -r '.dispatch.id // "D-000"' "$PROGRESS")
+sprint_num=$(jq -r '.sprint.number // 0' "$PROGRESS")
+ts=$(date -u +%Y%m%dT%H%M%SZ)
+session_id="${AGENT}-S$(printf '%03d' "$sprint_num")-${ts}"
+session_path="$TASK_ROOT/${session_id}.md"
+
+cat > "$session_path" <<EOF
+# Task Session — $session_id
+
+- agent: $AGENT
+- dispatch: $dispatch_id
+- sprint: $sprint_num
+- source: ${SOURCE:-none}
+- created_at: $(date -u +%Y-%m-%dT%H:%M:%SZ)
+
+## Allowed Inputs
+- .harness/handoff.json
+- .harness/progress.json
+- assigned evidence documents only
+
+## Rule
+- 이전 대화 기억이 아니라 문서와 evidence만 근거로 판단할 것
+- 사실과 추론을 분리해서 기록할 것
+EOF
+
+bash "$SCRIPT_DIR/harness-progress-set.sh" "$PROJECT_ROOT" \
+  ".task_sessions.current = {\"agent\":\"$AGENT\",\"id\":\"$session_id\",\"path\":\"${session_path#$PROJECT_ROOT/}\",\"source\":$(jq -Rn --arg v "${SOURCE:-}" '$v')} |
+   .task_sessions.history = ((.task_sessions.history // []) + [{\"agent\":\"$AGENT\",\"id\":\"$session_id\",\"path\":\"${session_path#$PROJECT_ROOT/}\",\"source\":$(jq -Rn --arg v "${SOURCE:-}" '$v')}])" >/dev/null
+
+echo "${session_path#$PROJECT_ROOT/}"

package/scripts/harness-user-prompt-submit.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 # harness-user-prompt-submit.sh — UserPromptSubmit hook (v5 unified)
-# 핵심 상태 + 라우팅 지시만 주입. Solo/Team 통합.
+# 핵심 상태 + 라우팅 지시만 주입. 회사 루프 기본, solo는 비상용 override.
 set -e
 
 INPUT=$(cat)
@@ -9,6 +9,7 @@ if [ -z "$CWD" ]; then CWD="$PWD"; fi
 
 # 조건 1: 하네스 초기화 확인
 if [ ! -f "$CWD/.harness/config.json" ]; then exit 0; fi
+SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
 
 # 조건 2: opt-out 플래그 확인
 AUTO_ROUTE="true"
@@ -28,6 +29,11 @@ PIPELINE="none"; CURRENT_AGENT="none"; NEXT_AGENT="none"
 SPRINT_NUM="0"; SPRINT_STATUS="init"; AGENT_STATUS="pending"
 
 if [ -f "$CWD/.harness/progress.json" ] && command -v jq >/dev/null 2>&1; then
+  conductor_state=$(jq -r '.conductor.state // "idle"' "$CWD/.harness/progress.json" 2>/dev/null || echo "idle")
+  pending_next=$(jq -r '.next_agent // "none"' "$CWD/.harness/progress.json" 2>/dev/null || echo "none")
+  if [ -x "$SCRIPT_DIR/conductor-tick.sh" ] && { [ "$conductor_state" = "running" ] || [ "$pending_next" = "conductor" ]; }; then
+    bash "$SCRIPT_DIR/conductor-tick.sh" "$CWD" >/dev/null 2>&1 || true
+  fi
   PIPELINE=$(jq -r '.pipeline // "none"' "$CWD/.harness/progress.json" 2>/dev/null || echo "none")
   CURRENT_AGENT=$(jq -r '.current_agent // "none"' "$CWD/.harness/progress.json" 2>/dev/null || echo "none")
   NEXT_AGENT=$(jq -r '.next_agent // "none"' "$CWD/.harness/progress.json" 2>/dev/null || echo "none")
@@ -52,22 +58,31 @@ fi
 # ── 컨텍스트 분리 가드레일 ──
 # 현재 에이전트가 활성인데 다른 에이전트 스킬을 호출하려는 경우 경고
 CONTEXT_WARNING=""
+CONTEXT_BLOCK=""
 if [ "$CURRENT_AGENT" != "none" ] && [ "$CURRENT_AGENT" != "null" ] && [ "$AGENT_STATUS" = "running" ]; then
   # 프롬프트에서 /harness-* 패턴 추출
   REQUESTED_SKILL=$(echo "$PROMPT" | grep -oE '/harness-[a-z-]+' | head -1 | sed 's|/harness-||')
   if [ -n "$REQUESTED_SKILL" ] && [ "$REQUESTED_SKILL" != "$CURRENT_AGENT" ]; then
-    CONTEXT_WARNING="
-## !! Context Isolation Warning !!
+    CONTEXT_BLOCK="
+## Context Isolation Block
 current_agent=${CURRENT_AGENT} (running) 인데 /harness-${REQUESTED_SKILL} 호출 감지.
-한 세션에서 다른 에이전트를 실행하면 컨텍스트가 오염됩니다.
+문서 기반 task session 분리를 강제하기 위해 이 호출은 차단됩니다.
 현재 에이전트를 먼저 완료(completed)하거나, 새 세션을 시작하세요."
   fi
 fi
 
+if [ -n "$CONTEXT_BLOCK" ]; then
+  cat <<EOF
+[harness] blocked | current=${CURRENT_AGENT} | requested=${REQUESTED_SKILL}
+${CONTEXT_BLOCK}
+EOF
+  exit 0
+fi
+
 # ── Mode 기반 분기 ──
-MODE="solo"
+MODE="team"
 if [ -f "$CWD/.harness/progress.json" ] && command -v jq >/dev/null 2>&1; then
-  MODE=$(jq -r '.mode // "solo"' "$CWD/.harness/progress.json" 2>/dev/null || echo "solo")
+  MODE=$(jq -r '.mode // "team"' "$CWD/.harness/progress.json" 2>/dev/null || echo "team")
 fi
 
 if [ "$MODE" = "team" ]; then
@@ -83,9 +98,10 @@ if [ "$MODE" = "team" ]; then
 [harness] team | ${T_PASSED}/${T_TOTAL} passed | ${T_FAILED} failed
 
 ## Team Mode Active
-- 3 Agent Teams이 자율적으로 Gen→Eval 루프 실행 중 (max 5 retries)
-- 역할: 모니터링, 실패 대응, 수동 개입
-- /harness-stop → 중단 | /harness-solo → Solo 전환
+- worker pool(기본 3)이 자율적으로 Gen→Eval 루프 실행 중 (max 5 retries)
+- CEO/Meeting/CTO/CQO/Service-Ops control-plane은 이 상한에 포함되지 않음
+- 역할: 모니터링, 실패 대응, Goal 점검
+- /harness-stop → 중단 | /harness-solo → 비상용 단일 에이전트 fallback
 - skip: "harness skip" 시 일반 대화
 EOF
   exit 0
@@ -97,6 +113,8 @@ cat <<EOF
 ${CONTEXT_WARNING}
 ## Route
 - pipeline=none/dispatcher 미실행 → harness-dispatcher 스킬 호출
+- 기본 경로는 conductor 중심 회사 루프다: dispatch -> CEO meeting -> planner(COO) -> cto -> gen/eval -> cqo -> service-ops -> batch meeting
+- conductor 는 Planner 직행 대신 meeting-manager / cto / cqo / service-ops 로 next_agent를 재작성할 수 있다
 - 기능 요청 → pipeline flow | 실수 지적 → gotcha flow | 메타 질문 → 짧게 응답 (skip)
 - 활성 pipeline → next_agent/current_agent 컨텍스트로 계속
 - skip: "harness skip", "just answer" 등 명시 시 단일 메시지 건너뜀

package/skills/brainstorming/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: harness-brainstorming
 description: "사용자의 러프한(바이브코딩) 요구사항을 대화형으로 구체화하여 Planner가 바로 쓸 수 있는 디자인/스펙 문서(.harness/actions/brainstorm-spec.md)로 만든다. Dispatcher가 사용자에게 '브레인스토밍 필요?' 라고 확인한 뒤에만 호출된다. 원본: obra/superpowers MIT."
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
 # Brainstormer — 요구사항 구체화 (obra/superpowers 파생)
@@ -52,9 +52,9 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 ## Session Boundary Protocol
 
 ### On Start
-1. `.harness/progress.json` 읽기 — `next_agent == "brainstormer"` 인지 확인
+1. `.harness/progress.json` 읽기 — `next_agent == "brainstorming"` 인지 확인
    - 아니면 즉시 STOP + "Dispatcher 를 먼저 실행하세요" 안내
-2. progress.json 업데이트: `current_agent` → `"brainstormer"`, `agent_status` → `"running"`, `updated_at` 갱신
+2. progress.json 업데이트: `current_agent` → `"brainstorming"`, `agent_status` → `"running"`, `updated_at` 갱신
 3. `.harness/memory.md` 읽기 — **프로젝트 공유 학습 규칙 적용**
 4. **Skip 조건 검사**: `.harness/actions/brainstorm-spec.md` 가 이미 존재하고
    사용자가 "새로 브레인스토밍" 을 명시하지 않았다면:
@@ -66,7 +66,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 1. `.harness/actions/brainstorm-spec.md` 가 존재하고 "User Review Gate" 를 통과했는지 확인
 2. progress.json 업데이트:
    - `agent_status` → `"completed"`
-   - `completed_agents` 에 `"brainstormer"` 추가
+   - `completed_agents` 에 `"brainstorming"` 추가
    - `next_agent` → `"planner"`
 3. `.harness/progress.log` 에 요약 추가: `Brainstormer → Planner (spec: <경로>)`
 4. 출력: `"✓ Brainstormer 완료. brainstorm-spec.md 검토 후 승인 신호를 주세요. 승인 시 자동 핸드오프 (Conductor 자율 시동) (Planner)."`

package/skills/conductor/SKILL.md

@@ -136,13 +136,13 @@ idle ─► running ─► (waiting_meeting | waiting_owner | running) ─► co
 
 ```
 [Planner missing or sprint=0]      → spawn planner
-[generator pending in feature row] → spawn generator-{be|fe|designer|devops}
-[generator done, eval pending]     → spawn evaluator-{func|visual|cq|arch|sec}
+[generator pending in feature row] → spawn generator-backend | generator-frontend | generator-designer | generator-devops
+[generator done, eval pending]     → spawn evaluator-code-quality | evaluator-functional | evaluator-visual | evaluator-architecture | evaluator-security
 [all eval PASS for feature]        → next feature
 [all features PASS]                → Phase Gate Meeting
-[Service-Ops cron due]             → spawn service-ops monitor
-[ops-report ready]                 → handoff to CTO (spawn cto-review)
-[generator-* / eval-functional spawn 직전] → 동시 spawn service-ops/monitor (stream-mode, G-006)
+[Service-Ops cron due]             → spawn service-ops (requested_mode=monitor)
+[ops-report ready]                 → handoff to CTO (spawn cto)
+[generator-* / eval-functional spawn 직전] → 동시 spawn service-ops (requested_mode=monitor, stream-mode, G-006)
 [mode=team & ready ≥ 2]            → 동시 spawn min(ready,3) generator/evaluator (G-005)
 ```
 
@@ -161,11 +161,12 @@ slots=$(( ready_count < 3 ? ready_count : 3 ))
 
 ### 5.2 Service-Ops monitor 동반 spawn (G-006)
 
-generator-{backend,frontend,frontend-flutter,devops} 또는 evaluator-functional* 을 spawn 하기 직전, **동일 tick 에서** service-ops/monitor 를 stream-mode 로 함께 spawn:
+generator-backend / generator-frontend / generator-devops 또는 evaluator-functional 을 spawn 하기 직전, **동일 tick 에서** `service-ops` 를 `requested_mode=monitor` 로 함께 spawn:
 
 ```bash
 bash scripts/harness-progress-set.sh . \
-  '.service_ops.monitor.stream_active = true |
+  '.service_ops.requested_mode = "monitor" |
+   .service_ops.monitor.stream_active = true |
    .service_ops.monitor.stream_target = "generator-frontend" |
    .agents += [{"id":"service-ops","room":"service-ops","minifigState":"watching"}]'
 ```
@@ -200,7 +201,7 @@ bash scripts/harness-progress-set.sh . \
 
 ## 7.5 모드 결정 (v6.0+, 사용자에서 이양)
 
-이전에는 사용자가 `/harness-solo` 또는 `/harness-team` 으로 직접 선택했다. v6.0 부터 **Conductor 가 sprint 시작 시점에 자동 결정**한다. 사용자 override 는 가능하지만 디폴트는 자동.
+이전에는 사용자가 `/harness-solo` 또는 `/harness-team` 으로 직접 선택했다. v6.0 부터 **Conductor 가 sprint 시작 시점에 자동 결정**하며, 정상 경로는 회사형 team/company 루프다. `solo` 는 사용자 명시 시에만 들어가는 비상용 fallback 이다.
 
 ### 7.5.1 결정 시점
 
@@ -216,12 +217,7 @@ ready_at_start ≥ 3
 feature_count ≥ 6
 critical_path_depth ≤ 2
 
-# Solo 강제 조건 (어느 하나라도)
-ready_at_start ≤ 2
-또는 feature_count ≤ 3
-또는 critical_path_depth ≥ 4
-
-# 동률 → solo (비용 안전)
+# Solo 관련 threshold 는 문서상 fallback 참고치일 뿐, auto 기본 경로는 team 유지
 ```
 
 `critical_path_depth` = feature 의존성 그래프에서 가장 긴 체인의 길이. `feature-list.json` 의 `depends_on` 으로 계산.
@@ -230,7 +226,7 @@ ready_at_start ≤ 2
 
 1. 결정 후 `progress.json` partial update:
    ```json
-   "mode": "solo" 또는 "team",
+  "mode": "team" 기본, 필요 시 "solo",
    "mode_decision": {
      "owner": "conductor",
      "decided_at": "<iso>",
@@ -247,7 +243,7 @@ ready_at_start ≤ 2
 
 | 발화/명령 | 효과 |
 |---|---|
-| `/harness-solo` 또는 "solo 로" | mode=solo 강제, mode_decision.user_override="solo" |
+| `/harness-solo` 또는 "solo 로" | mode=solo 강제, mode_decision.user_override="solo" (비상용 fallback) |
 | `/harness-team` 또는 "team 으로" | mode=team 강제, user_override="team" |
 | "auto 다시" / "Conductor 결정으로" | user_override=null, 다음 sprint 시작 시 재자동결정 |
 

package/skills/cqo/SKILL.md

@@ -90,6 +90,13 @@ CQO는 다음 짝의 평가가 일치하는지 확인:
 docmeta: { ... }
 cqo_audit:
   sprint: <n>
+  decision:
+    owner: cqo
+    action_type: re-evaluate | reject
+    rationale: <why CQO passed or rejected the build>
+    evidence:
+      - source: <artifact path>
+        kind: evaluation | regression | security | architecture
   per_axis_scores:
     functional: 2.85
     visual: 2.92

package/skills/cto/SKILL.md

@@ -93,6 +93,13 @@ CTO 판단 옵션:
 docmeta: { ... }
 cto_review:
   sprint: <n>
+  decision:
+    owner: cto
+    action_type: implement | replan
+    rationale: <fact-based conclusion>
+    evidence:
+      - source: <artifact path>
+        kind: ops-report | meeting-record | cqo-audit
   goal_feasibility: feasible | feasible-with-recruit | infeasible
   recommended_recruits: [generator-designer, eval-security]
   arch_risks: [...]

package/skills/dispatcher/SKILL.md

@@ -53,9 +53,8 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 1. progress.json 업데이트:
    - `agent_status` → `"completed"`
    - `completed_agents`에 `"dispatcher"` 추가
-   - `next_agent` → **브레인스토밍 결정 트리에 따라 결정** ([섹션 6](#6-brainstormer-routing-decision) 참조)
-     - 신규/재플래닝 + 사용자가 브레인스토밍 선택 → `"brainstorming"`
-     - 신규/재플래닝 + 사용자가 건너뛰기 선택 → `"planner"`
+   - `next_agent` → **기본은 `"meeting-manager"`**. CEO가 먼저 Cxx 회의를 소집하고, Conductor가 그 결과로 `planner(COO)` / `cto` / `cqo` / `service-ops` 를 분배한다.
+     - 신규/재플래닝/Goal 재정렬 → `"meeting-manager"`
      - 특정 에이전트 직접 명령 → 해당 에이전트 (예: `"evaluator-functional"`)
      - Gotcha 교정 후 재작업 → `failure.retry_target` (해당 에이전트)
    - `pipeline` → 선택된 파이프라인 (FULLSTACK/FE-ONLY/BE-ONLY)
@@ -74,7 +73,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
      아카이빙 후 `dispatch.id` 는 `null` 로 리셋되므로, 다음 dispatcher 실행 시 새 D-NNN 이 할당된다.
 2. `.harness/progress.log`에 요약 한 줄 추가
 3. 출력: `"✓ Dispatcher 완료. 자동 핸드오프 (Conductor 자율 시동)."`
-4. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (Solo 모드. Team 모드는 Lead가 별도 오케스트레이션). Brainstorming/Planner 단계가 아니면 사용자 승인 게이트 없음.
+4. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프**. 기본 경로는 `meeting-manager -> planner(COO) -> cto -> gen/eval -> cqo -> service-ops -> meeting-manager`.
 
 ## Auto-Routing (UserPromptSubmit Hook)
 
@@ -223,40 +222,30 @@ Dispatcher 는 사용자 요청을 분류한 뒤 아래 순서로 판단:
 ```
 1. Gotcha / 실수 지적인가?
    → YES: gotcha 기록 → next_agent = failure.retry_target (해당 에이전트)
-         (브레인스토밍 없음)
+         (회의 소집 없이 재작업)
 
 2. 특정 에이전트 직접 명령인가?
    ("evaluator 다시 돌려", "generator-frontend 재작업", "planner plan.md 고쳐" 등)
-   → YES: next_agent = <대상 에이전트> (브레인스토밍 없음)
+   → YES: next_agent = <대상 에이전트> (CEO 회의 우회)
 
-3. Planner 가 동작해야 하는 케이스인가?
-   (신규 파이프라인 / 신규 PRD / 기존 plan.md 대폭 수정 / 신규 feature 대규모 추가)
-   → YES: 사용자에게 확인 질문 → 6.2 "브레인스토밍 확인 플로우"
-   → NO:  다른 에이전트로 라우팅 (generator 이어서 등)
+3. 신규 GOAL / 재플래닝 / Goal drift / 운영 이슈인가?
+   → YES: next_agent = meeting-manager
+         (CEO가 COO/CTO/CQO/Service-Ops 회의를 먼저 소집)
 
-4. 그 외 (메타/인사/Claude 자체 질문) → Dispatcher skip
-```
-
-### 6.2 브레인스토밍 확인 플로우
-
-Planner 를 호출해야 한다고 판단되면, **사용자에게 단 하나의 질문을 출력한 뒤 대기한다:**
+4. Brainstorming 이 필요한가?
+   → YES: Brainstorming 은 기본 진입점이 아니라 COO/Planner 내부 판단 또는
+         명시적 요청일 때만 사용
 
+5. 그 외 (메타/인사/Claude 자체 질문) → Dispatcher skip
 ```
-이 요청은 Planner 가 처리할 신규/재플래닝 건으로 보입니다.
-러프한 요구사항을 먼저 구체화하는 Brainstormer 과정을 거칠까요?
 
-  (Y) 예 — Brainstormer 와 대화하며 요구사항을 fit 하게 만든 뒤 Planner
-  (N) 아니오 — 이미 PRD/OpenAPI 가 명확하므로 바로 Planner
+### 6.2 브레인스토밍 확인 플로우
 
-답변: Y / N
-```
+브레인스토밍은 더 이상 Dispatcher의 기본 확인 질문이 아니다.
 
-사용자 응답 처리:
-- **Y (긍정)** — "네", "y", "yes", "필요해", "해줘" 등
-  → `next_agent = "brainstorming"`
-- **N (부정)** — "아니오", "n", "no", "필요없어", "바로", "skip" 등
-  → `next_agent = "planner"`
-- **불명확 / 무응답** — 한 번 더 "Y 또는 N 으로 답해주세요" 요청
+- 기본값: `meeting-manager` 로 넘겨 CEO 회의 후 `planner(COO)` 가 브레인스토밍/웹리서치 필요 여부를 판단
+- 예외: Owner가 명시적으로 "`/harness-brainstorming`", "브레인스토밍부터"를 요청한 경우에만 직접 `brainstorming`
+- 금지: Planner 진입 전에 Brainstorming 여부를 사용자 승인 게이트로 되돌리는 것
 
 ### 6.3 Skip 케이스 정리
 

package/skills/evaluator-code-quality/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: harness-evaluator-code-quality
 description: "하네스 Code-Quality Evaluator. 브라우저 없이 코드 자체를 읽어 유지보수성·모범사례 준수·아키텍처 건전성을 검사한다. BE/FE/lib 전 영역 적용. C1-C5 축으로 적대적 채점. 기준 미달 = FAIL."
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
 # Evaluator-Code-Quality — Static Code Audit (No Browser)

package/skills/evaluator-functional/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: harness-evaluator-functional
 description: "하네스 Functional Evaluator. Playwright MCP(browser_*)로 실행 중인 앱을 실제 사용자처럼 조작하며 E2E 기능을 검증한다. Step 0 IA 구조 검증(Gate) → Step 1-7 기능 테스트. 기준 미달 = FAIL."
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
 # Evaluator-Functional — Playwright MCP

package/skills/evaluator-visual/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: harness-evaluator-visual
 description: "하네스 Visual Evaluator. Playwright MCP로 스크린샷, 반응형 검증, 접근성 트리 분석, AI슬롭 감지를 수행한다. Evaluator-Functional이 PASS한 후에만 실행. 기준 미달 = FAIL → Generator-Frontend 재작업."
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
 # Evaluator-Visual — Design & Accessibility

package/skills/generator-backend/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: harness-generator-backend
 description: "하네스 Backend Generator. 스택 독립(adaptive) — scan-result.json 의 be_stack / language 에 따라 .harness/ref/be-<stack>.md 를 로드해 runner/paths/api/validation 을 따른다. 모든 BE 스택(FastAPI / Django / Go / Rails / Phoenix / Spring / Express 등) 대응."
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
 # Generator-Backend — Adaptive (Stack-Agnostic)

package/skills/generator-frontend/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: harness-generator-frontend
 description: "하네스 Frontend Generator. 스택 독립(adaptive) — scan-result.json 의 fe_stack 에 따라 .harness/ref/fe-<stack>.md 를 로드해 해당 스택의 runner/paths/api/validation 을 따른다. 모든 FE 스택(Swift / Flutter / Vue / Svelte / Angular / 웹 SSR 등) 대응."
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
 # Generator-Frontend — Adaptive (Stack-Agnostic)

package/skills/meeting-manager/SKILL.md

@@ -97,6 +97,14 @@ meeting:
     - id: D-1
       text: <decision>
       vote: { agree: 0.71, override: false }
+  decision:
+    owner: planner | cto | cqo | service-ops | dispatcher
+    action_type: goal-alignment | replan | implement | re-evaluate | monitor | escalate-owner
+    rationale: <fact-based why this owner must act next>
+    evidence:
+      - source: <artifact path>
+        kind: ops-report | cqo-audit | cto-review | meeting-prep
+    drift_classification: implementation_drift | planning_drift | ops_drift | goal_drift
   action_items:
     - id: AI-1
       owner: generator-backend
@@ -119,17 +127,37 @@ meeting:
 ## 7. progress.json 추가
 
 ```json
-"meetings": {
+  "meetings": {
   "cadence": "light|normal|heavy",
   "last_standup": "<iso>",
   "next_scheduled": "<iso>",
   "active": [ { "id": "...", "type": "...", "status": "..." } ],
   "open_action_items": 0,
   "last_goal_adherence": 0.92,
+  "decision": {
+    "owner": "planner",
+    "action_type": "goal-alignment",
+    "rationale": "...",
+    "evidence": [],
+    "drift_classification": "planning_drift",
+    "source_path": ".harness/actions/meetings/M-.../meeting-M-....md"
+  },
   "manual_override": null
 }
 ```
 
+## 7.1 회의 진행 방식
+
+Meeting-Manager는 단순히 "토론해 주세요"라고 말하지 않는다. 각 참석자에게 역할별 prep를 요청한다.
+
+- `Dispatcher/CEO`: Goal 자체가 흔들렸는가, Owner escalation 이 필요한가
+- `Planner/COO`: 기획/가설/웹리서치/레퍼런스 재검토가 필요한가
+- `CTO`: 구현/아키텍처/기술선택 문제가 원인인가
+- `CQO`: 품질/회귀/검증 부족이 원인인가
+- `Service-Ops`: KPI/로그/incident 기준으로 어떤 drift 가 발생했는가
+
+회의 종료 시 `decision.owner`, `action_type`, `rationale`, `evidence`, `drift_classification` 이 비어 있으면 회의는 미완료로 본다.
+
 ## 8. Cron 통합 (Service-Ops 위임)
 
 Meeting-Manager 자체는 cron을 돌리지 않음. Service-Ops가 매 hourly 틱에서:
@@ -143,6 +171,7 @@ Meeting-Manager 자체는 cron을 돌리지 않음. Service-Ops가 매 hourly
 
 | Event 발신처 | 조건 | 소집 회의 |
 |---|---|---|
+| Dispatcher | 신규 GOAL / 재플래닝 시작 | All-Hands (`goal-intake`) |
 | Eval-* | `## Change Request` 첨부 | Spec Review |
 | Conductor | 3회 FAIL | Spec Review (scope 축소 검토) |
 | Service-Ops | red-alert (5xx 임계 / 헬스 실패) | Incident War Room |
@@ -185,6 +214,9 @@ bash scripts/queue-enqueue.sh   --owner generator-backend   --feature <feature-i
 2. Action Items → queue enqueue
 3. partial update: `status = "dispatched"`, `open_action_items += N`
 4. cadence 재계산 요청 (Service-Ops에 위임)
+5. 기본 handoff 규칙:
+   - `goal-intake` / `goal-drift` / `spec-review` / `incident-followup` → `planner(COO)`
+   - `ops-batch` / `sprint-review` / `quality-fail` → `cto`
 
 ### On Archived
 1. `.harness/archive/meetings/<id>/` 로 이동

package/skills/planner/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: harness-planner
 description: "하네스 Planner 에이전트. 사용자의 프로젝트 설명을 제품 사양(plan.md), 기능 목록(feature-list.json), API 계약서(api-contract.json), AGENTS.md로 확장. pipeline.json의 planner_mode(light/full)에 따라 동작."
-disable-model-invocation: true
+disable-model-invocation: false
 ---
 
-# Planner Agent
+# Planner Agent (COO + HR)
 
 ## progress.json 업데이트 규칙 (v5.6.3+)
 
@@ -34,11 +34,11 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 1. progress.json 업데이트:
    - `agent_status` → `"completed"`
    - `completed_agents`에 `"planner"` 추가
-   - `next_agent` → 파이프라인에 따라 결정 (FULLSTACK/BE-ONLY: `"generator-backend"`, FE-ONLY: `"generator-frontend"`)
+   - `next_agent` → `"cto"`
 2. `.harness/progress.log`에 요약 추가
-3. 출력: `"✓ Planner 완료. plan.md / api-contract.json 검토 후 승인 신호를 주세요. 승인 시 자동 핸드오프 (Conductor 자율 시동)."`
-4. **사용자 승인 게이트**: 사용자의 명시적 승인 ("승인", "ok", "다음", "진행", "go" 등) 을 기다린 후, **내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프**.
-5. 사용자가 피드백/수정 요청을 하면 plan.md / feature-list.json / api-contract.json 을 갱신하고 다시 승인 요청. 승인 없이는 `/harness-next` 호출 금지.
+3. 출력: `"✓ Planner 완료. COO 계획안을 CTO 실행 라인으로 자동 핸드오프합니다."`
+4. **사용자 승인 게이트 없음**: Planner는 CEO 회의에서 위임받은 COO 역할이다. 완료 즉시 **내부 핸드오프 (scripts/harness-next.sh)** 로 CTO에 넘긴다.
+5. 수정 루프가 필요하면 Meeting-Manager / CTO / CQO / Service-Ops가 다시 Planner를 호출한다. Owner 승인을 기본 대기점으로 두지 않는다.
 
 ## Startup
 
@@ -61,6 +61,20 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
    - 혼재/불명확 → 사용자에게 단 한 번 질문
    - 확정 후 `pipeline.json.fe_stack` 갱신 (없으면 생성)
 
+## 역할 재정의 (v6 Company Loop)
+
+Planner는 더 이상 초기 파이프라인의 단순 1회성 spec writer가 아니다.
+
+- **COO 역할**: Goal 정렬, 설계 허점 탐지, 브레인스토밍 필요 여부 판단
+- **HR 역할**: 필요한 스킬/부서가 비어 있으면 채용/온보딩 경로 준비
+- **입력 경로**:
+  - `meeting-manager` 의 CEO 회의 결과
+  - `cto` 의 hotfix / execution-plan 요청
+  - `service-ops` / `cqo` 로부터 올라온 재기획 요구
+- **출력 경로**:
+  - 신규/수정된 `plan.md`, `feature-list.json`, `api-contract.json`
+  - CTO가 바로 실행할 수 있는 작업 분할
+
 ## Outputs (4개)
 
 | 파일 | 설명 |
@@ -131,7 +145,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 
 ## Team 병렬 스케줄링 규칙 (필수)
 
-Team Mode는 **최대 3팀이 동시 작업**한다. Planner는 feature-list.json 설계 시 다음 규칙을 반드시 준수한다.
+Team Mode의 `3`은 **회사 전체 에이전트 수 제한이 아니라 generator/evaluator worker pool 상한**이다. Planner는 feature-list.json 설계 시 control-plane(CEO/Meeting/CTO/CQO/Service-Ops)을 제외한 **worker plane** 이 끊기지 않게 다음 규칙을 반드시 준수한다.
 
 ### 핵심 원칙: Sprint 시작 시 ready ≥ 3
 
@@ -180,5 +194,5 @@ ready가 3 미만인 Sprint가 있으면 **feature를 더 작게 분할하거나
 
 ## After Completion
 
-1. 사용자에게 plan.md + api-contract.json 리뷰 요청
-2. 승인 후 → Session Boundary Protocol On Complete 실행
+1. 산출물을 CTO가 즉시 실행 가능한 형태로 정리한다.
+2. Session Boundary Protocol On Complete 실행 → `next_agent = "cto"`