@walwal-harness/cli 6.0.5 → 6.1.0

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"`

package/skills/service-ops/SKILL.md

@@ -90,6 +90,17 @@ Standup 종료 직후 호출됨. 직전 3회 standup의:
 - `goal_adherence < 0.5` 24h 이상 → Spec Review (긴급) 소집
 - warn 누적 ≥ 5건/Sprint → 다음 Standup에서 보고
 
+### 3.7 Drift Classification
+
+Service-Ops는 `goal_adherence` 하락을 감지했을 때 원인 분류 없이 Planner로 넘기면 안 된다. 먼저 아래 분류를 시도한다.
+
+- `implementation_drift`: CQO FAIL / regression / 품질 축 미달이 직접 원인
+- `planning_drift`: 구현/품질은 통과했지만 Goal 달성 가설이 어긋남
+- `ops_drift`: 운영 환경, 배포, 로그, incident, KPI 이상이 원인
+- `goal_drift`: Goal/KPI 정의 자체가 흔들리거나 Owner intent와 괴리
+
+이 분류는 `progress.json.service_ops.drift_classification` 과 ops-report evidence에 기록되어야 한다.
+
 ---
 
 ## 4. Incident 모듈
@@ -176,6 +187,10 @@ CTO가 수신 → Hotfix/Backlog Feature로 변환 → Planner 등록.
 
 ```json
 "service_ops": {
+  "drift_classification": "planning_drift",
+  "evidence": [
+    { "source": ".harness/actions/ops-report-3.md", "kind": "ops-report" }
+  ],
   "monitor": {
     "last_check": "<iso>",
     "cadence_decided": "normal",
@@ -221,15 +236,15 @@ CTO가 수신 → Hotfix/Backlog Feature로 변환 → Planner 등록.
 ## 9. Conductor와의 인터페이스
 
 - Conductor 틱에서:
-  - cron 도달 → spawn `service-ops/monitor`
-  - red-alert 이벤트 → spawn `service-ops/incident`
-  - Sprint 종료 → spawn `service-ops/auto-retro`
+  - cron 도달 → spawn `service-ops` + `service_ops.requested_mode="monitor"`
+  - red-alert 이벤트 → spawn `service-ops` + `service_ops.requested_mode="incident"`
+  - Sprint 종료 → spawn `service-ops` + `service_ops.requested_mode="auto-retro"`
 - 모든 Service-Ops 산출물은 CTO 경유로만 코드 변경에 도달
 
 ## 10. Session Boundary Protocol
 
 ### On Start
-1. `.harness/progress.json` 읽기 → 어느 모듈 호출인지 확인 (`mode = monitor|incident|auto-retro`)
+1. `.harness/progress.json` 읽기 → 어느 모듈 호출인지 확인 (`service_ops.requested_mode = monitor|incident|auto-retro`)
 2. partial update: `current_agent = "service-ops"`, `service_ops.<mode>.running = true`
 
 ### On Complete