@walwal-harness/cli 6.1.3 → 6.1.5

package/skills/meeting-manager/SKILL.md

@@ -16,12 +16,43 @@ walwal-harness 의 부서 구조에 맞게 재해석함.
 > Conductor가 "일을 굴리는 손"이라면, Meeting-Manager는 "일이 옆길로 새지 않게 잡는 서기".
 > Dispatcher(CEO) 직속, Conductor와 평행.
 
+## 0. Operating Cycle Doctrine (Inviolable)
+
+Meeting-Manager 는 회사를 sprint gate 로 멈추게 하지 않는다. 회의는 "다음 sprint 시작 승인"이 아니라 **현재 work package 결과 판정 + 다음 work package 자동 배정**이다.
+
+- **회의록 금지 표현**: "다음 sprint 에서 처리", "Sprint 2+ 부터", "Owner 가 다음 sprint 실행".
+- **회의록 표준 표현**: "backlog/queue 에 work package 등록", "Conductor 가 worker pool 에 자동 배정", "다음 cadence 에 followup-review".
+- **회의 결정**은 항상 `decision.owner`, `action_type`, `tracks[]`, `action_items[]` 중 하나로 실행 가능해야 한다. 단순한 "다음 sprint 계획"은 미완료 회의록으로 간주한다.
+- **정기 보고**는 `sprint-review` 대신 가능하면 `standup`, `followup-review`, `all-hands`, `incident-war-room` 의미로 작성한다. 레거시 enum 때문에 `sprint-review` 값을 읽더라도 Owner-facing 제목은 "Operating Review" 로 바꾼다.
+
 ## 1. 정체성
 
 - **위치**: Dispatcher 직속, Conductor 평행
 - **책임**: 회의 스케줄·소집·진행·기록·Action Item 디스패치
 - **권한**: 모든 부서에 prep 양식 발신, 회의록 작성·집계, queue enqueue (v5.9.6 재사용)
 - **금지**: 의사결정 직접 수행 (사회만 봄), Owner와 직접 대화 (escalation은 Dispatcher 경유)
+- **세션 시작 SoT**: `CONVENTIONS.md`, `.harness/conventions/shared.md`, `.harness/conventions/meeting-manager.md`, `.harness/gotchas/meeting-manager.md`, `.harness/memory.md` 를 먼저 읽고 회의 운영에 적용한다.
+
+## 1.5 Executive Role Contract (Inviolable)
+
+회의는 상태 리포트가 아니다. 회의록에는 반드시 각 임원이 자기 역할 관점에서 **입장(Position) · 근거(Evidence) · 다음 행동(Action)** 을 남겨야 한다.
+
+| Role | Identity | Must Decide | Must Not |
+|---|---|---|---|
+| Dispatcher/CEO | Owner와의 유일한 외부 창구, GOAL/사업 우선순위 책임자 | GOAL 흔들림 여부, Owner escalation 필요성 | 내부 해결 가능한 일을 Owner 대기로 끝내기 |
+| Planner/COO | GOAL을 work package/queue/가설로 바꾸는 운영 총괄 | planning_drift/goal_drift 여부, 다음 work package | "다음 sprint/Owner 결정 후" 같은 대기형 결론 |
+| CTO | 구현/아키텍처/runtime recovery 책임자 | implementation_drift, 복구/핫픽스/worker 배정 | 서버 down을 Service-Ops 알림으로만 방치 |
+| CQO | 품질/회귀/검증 기준 책임자 | evidence 충분성, PASS/FAIL, 추가 검증 | evidence 없는 낙관론 승인 |
+| Service-Ops | 운영 신호/KPI/incident/cadence 책임자 | ops_drift, incident-war-room 필요성, monitor cadence | 경고만 남기고 CTO/CQO action으로 연결하지 않기 |
+
+회의록이 아래 중 하나라도 빠뜨리면 "회의 완료"가 아니다.
+
+- `## Required Role Positions` 또는 `## Role Briefs` 에 CEO/COO/CTO/CQO/Service-Ops 전원의 발언이 있다.
+- `## Discussion` 에 역할 간 쟁점이 있다.
+- `## Decision JSON` 에 `decision.owner`, `action_type`, `rationale`, `evidence`, `drift_classification`, `source_path` 가 있다.
+- `## Action Items` 가 있고 Owner 대기 없이 다음 내부 owner로 이어진다.
+
+Owner-facing hourly 보고는 Service-Ops health table 이 아니라 **Executive Meeting Minutes 요약**이어야 한다. 서버 운용현황은 회의 evidence 중 하나일 뿐이다.
 
 ## 2. 회의 6종 (v6.2 — Followup Review 추가)
 
@@ -230,7 +261,7 @@ meeting:
 
 `scripts/conductor-tick.sh` 가 자동으로:
 1. fork 회의 직후 `progress.json.conductor.tracks` 에 트랙 상태 미러링.
-2. 첫 번째 트랙 owner 를 spawn (status=running). 그 owner 가 완료하면 트랙을 completed 처리하고 다음 pending 트랙 spawn.
+2. 모든 트랙 owner 를 같은 tick 에 running 으로 만들고 병렬 spawn 대상으로 노출한다. 첫 번째 트랙만 spawn 하고 나머지를 pending 으로 남기는 구현은 parallel fork 가 아니라 sequence 이므로 금지.
 3. 모든 트랙이 completed 되면 `meetings.requested_type=<rendezvous.type>` + `meetings.requested_reason=rendezvous` 로 followup-review 를 자동 소집.
 4. fork 회의 id 는 `progress.json.meetings.fork_meeting_id` 로 followup 회의에 전달된다.
 
@@ -244,7 +275,7 @@ Meeting-Manager 는 트랙 dispatch 자체에 관여하지 않는다. fork 회
 2. **결정자 지정**: 기본 결정자 = CTO (운영 적용 여부). 단 fork 회의가 `goal-intake` 또는 `goal-drift` 였으면 CEO(Dispatcher) 로 escalate.
 3. **세 가지 통합 결정 중 하나**:
    - `apply-now` — 두 산출물을 즉시 정규 sprint artifact 로 승격. 다음 owner = planner (sprint-contract 갱신).
-   - `backlog` — 백로그 등록 후 다음 sprint 에서 다룸. 다음 owner = planner (feature-list append).
+   - `backlog` — 백로그/queue 에 work package 등록. 다음 owner = planner (feature-list append) 이며 Conductor 가 가능한 시점에 자동 배정.
    - `more-validation` — 추가 검증 필요. 다시 parallel fork 또는 단일 spec-review.
 4. 결정은 **single mode** 로 작성한다 (followup 자체에서 또 fork 하지 말 것 — 무한 fork 방지).
 
@@ -308,30 +339,69 @@ bash scripts/queue-enqueue.sh   --owner generator-backend   --feature <feature-i
 
 ## 12. Session Boundary Protocol
 
+> **데이터 계약 (Inviolable):** `progress.json.meetings.active` 는 **현재 회의 중인 에이전트 ID 들의 평탄 배열** 이다 (예: `["dispatcher","planner","cto"]`). 대시보드 `state-mapping.ts` 가 이 배열을 `Array.includes(agentId)` 로 검사해 미니피규어를 회의실로 텔레포트시킨다 (`talking` 상태). 객체 배열을 넣으면 회의실에 아무도 모이지 않는다.
+>
+> 회의별 메타데이터(상태/참석자/타입)는 `meetings.tracking[]` 에 별도 보관한다.
+
 ### On Start (소집 1회)
-1. `.harness/progress.json` 읽기 → 현재 active meetings 확인 (중복 방지)
+1. `.harness/progress.json` 읽기 → 현재 `meetings.tracking[]` 확인 (중복 방지)
 2. meeting-id 발급 (`M-YYYY-MM-DD-NNNN`)
 3. `.harness/actions/meetings/<id>/notice.md` 작성
-4. partial update: `meetings.active[+].status = "notice"`
-
-### On Prep Collected
+4. partial update — 메타 등록만, active 는 아직 비움:
+   ```bash
+   bash scripts/harness-progress-set.sh . \
+     '.meetings.tracking = (.meetings.tracking // []) + [
+        {"id": "<meeting-id>", "type": "<type>", "participants": ["<id1>","<id2>",...], "status": "notice"}
+      ] |
+      .meetings.current_id = "<meeting-id>" |
+      .meetings.requested_type = "<type>"'
+   ```
+
+### On Prep Collected (회의 시작 — 미니피규어 회의실 모음)
 1. 모든 참석자 prep-*.md 존재 확인 (timeout: standup 5min, 그 외 30min)
 2. timeout 시 결석 처리 + 회의록에 명시
-3. partial update: `meetings.active[i].status = "convened"`
-
-### On Decided
+3. partial update — **참석자 ID 들을 `meetings.active` 평탄 배열에 그대로 넣는다**:
+   ```bash
+   bash scripts/harness-progress-set.sh . \
+     '.meetings.active = ["<id1>","<id2>","<id3>"] |
+      .meetings.cadence = "<cadence>" |
+      .meetings.tracking |= map(if .id == "<meeting-id>" then .status = "convened" else . end)'
+   ```
+4. 회의 본 진행 (의제·발언·결정) — 이 시간 동안 대시보드에서 미니피규어가 회의실에 모여 있는 상태로 보임.
+
+### On Decided (회의 종료 — 미니피규어 desk 복귀)
 1. 회의록 finalize → `meeting-<id>.md`
 2. Action Items → queue enqueue
-3. partial update: `status = "dispatched"`, `open_action_items += N`
+3. partial update — **`meetings.active` 를 빈 배열로 즉시 비운다** (미니피규어 desk 복귀):
+   ```bash
+   bash scripts/harness-progress-set.sh . \
+     '.meetings.active = [] |
+      .meetings.tracking |= map(if .id == "<meeting-id>" then .status = "dispatched" else . end) |
+      .meetings.open_action_items = ((.meetings.open_action_items // 0) + <N>) |
+      .meetings.last_type = "<type>" |
+      .meetings.last_reason = "<reason>" |
+      .meetings.last_decision = "<owner>:<action_type>"'
+   ```
 4. cadence 재계산 요청 (Service-Ops에 위임)
 5. 기본 handoff 규칙:
    - `goal-intake` / `goal-drift` / `spec-review` / `incident-followup` → `planner(COO)`
-   - `ops-batch` / `sprint-review` / `quality-fail` → `cto`
+   - `ops-batch` / `operating-review` / `quality-fail` → `cto`
    - `rendezvous` (followup-review 결정 시) → 결정자 = `cto` 기본, 단 fork 회의가 `goal-intake|goal-drift` 였으면 `dispatcher` 로 escalate
 
 ### On Archived
 1. `.harness/archive/meetings/<id>/` 로 이동
-2. partial update: active에서 제거
+2. partial update — `meetings.tracking` 에서 해당 항목 제거:
+   ```bash
+   bash scripts/harness-progress-set.sh . \
+     '.meetings.tracking |= map(select(.id != "<meeting-id>"))'
+   ```
+
+### 회의 가시성 자가검증 (turn 종료 직전)
+
+- [ ] 내가 "회의 했다" 라고 보고하려는 모든 회의에 대해 `.harness/actions/meetings/<id>/meeting-<id>.md` 가 디스크에 존재하는가?
+- [ ] convened 상태일 동안 `meetings.active` 에 모든 참석자 ID 가 들어 있었는가? (대시보드에서 회의실에 모이는 모습이 안 보였다면 이 단계가 누락된 것)
+- [ ] dispatched 직후 `meetings.active = []` 로 비웠는가? (안 비우면 미니피규어가 회의실에 영구 갇힘)
+- 하나라도 No → 이번 회의는 "보고만 했고 보여주지 못함" 이므로 자기 진행 보고에서 제외하고 정정.
 
 ## 13. 안전 가드
 

package/skills/planner/SKILL.md

@@ -9,8 +9,8 @@ disable-model-invocation: false
 ## progress.json 업데이트 규칙 (v5.6.3+)
 
 ⚠️ **절대로 progress.json 을 통째로 재작성하지 마라**. `Write` 도구로 전체 파일을
-덮어쓰면 `mode` / `team_state` / 기타 top-level 필드가 누락되어 Team Mode 가 Solo 로
-되돌아가는 등 런타임 오류가 발생한다.
+덮어쓰면 `mode` / `company_state` / 기타 top-level 필드가 누락되어 회사모드 병렬 루프가
+끊기는 등 런타임 오류가 발생한다.
 
 **올바른 방법** — 반드시 partial update 로 갱신:
 
@@ -190,7 +190,7 @@ planner (verdict 검토 · 완료 시 meeting-manager/followup-review 로 복귀
 
 ## Team 병렬 스케줄링 규칙 (필수)
 
-Team Mode의 `3`은 **회사 전체 에이전트 수 제한이 아니라 generator/evaluator worker pool 상한**이다. Planner는 feature-list.json 설계 시 control-plane(CEO/Meeting/CTO/CQO/Service-Ops)을 제외한 **worker plane** 이 끊기지 않게 다음 규칙을 반드시 준수한다.
+Company worker pool의 `3`은 **회사 전체 에이전트 수 제한이 아니라 generator/evaluator worker pool 상한**이다. Planner는 feature-list.json 설계 시 control-plane(CEO/Meeting/CTO/CQO/Service-Ops)을 제외한 **worker plane** 이 끊기지 않게 다음 규칙을 반드시 준수한다.
 
 ### 핵심 원칙: Sprint 시작 시 ready ≥ 3
 

package/skills/service-ops/SKILL.md

@@ -27,6 +27,7 @@ Source: https://github.com/msitarzewski/agency-agents (MIT)
 ## 1. 정체성
 
 - **위치**: Dispatcher 직속 (Conductor·Meeting-Manager·Planner와 평행)
+- **세션 시작 SoT**: `CONVENTIONS.md`, `.harness/conventions/shared.md`, `.harness/conventions/service-ops.md`, `.harness/gotchas/service-ops.md`, `.harness/memory.md` 를 먼저 읽고 Service-Ops 역할 계약을 적용한다.
 - **책임**:
   1. 배포 후 GOAL 적합도·헬스·메트릭 모니터링
   2. 사고 발생 시 즉시 대응 + War Room 소집 트리거
@@ -55,6 +56,30 @@ service-ops/
 - GOAL 적합도(`goal_adherence`) 계산
 - 임계 초과 시 event trigger 발신
 
+### 3.1.1 Live Visibility (Inviolable)
+
+> 대시보드의 Operations 미니피규어가 typing 으로 보이려면 monitor 가 active 인 동안 `progress.service_ops.monitor.stream_active = true` 가 유지되어야 한다 (`state-mapping.ts:103` 의 G-006 조건).
+
+**On Start (monitor 한 바퀴 시작 시)**
+```bash
+bash scripts/harness-progress-set.sh . \
+  '.service_ops.monitor.stream_active = true |
+   .service_ops.monitor.stream_started_at = (now | todate)'
+```
+
+**On Complete (monitor 종료 직후, 결과 commit 과 같은 partial update 안에서)**
+```bash
+bash scripts/harness-progress-set.sh . \
+  '.service_ops.monitor.stream_active = false |
+   .service_ops.monitor.last_check = (now | todate) |
+   .service_ops.monitor.cadence_decided = "<light|normal|heavy>" |
+   .service_ops.monitor.current_goal_adherence = <0..1> |
+   .service_ops.monitor.warns_this_sprint = ((.service_ops.monitor.warns_this_sprint // 0) + <Δwarn>) |
+   .service_ops.monitor.alerts_this_sprint = ((.service_ops.monitor.alerts_this_sprint // 0) + <Δalert>)'
+```
+
+stream_active 를 안 끄면 미니피규어가 영구 typing 으로 보여 Owner 가 "왜 항상 일하고 있냐" 의심 → 정직성 위반.
+
 ### 3.2 입력
 - `.harness/actions/goals.md` (KPI·success_metrics)
 - 운영 메트릭 소스: `.harness/ops/metrics.jsonl` (DevOps가 적재) 또는 외부 stack(Grafana·Sentry — 옵트인)

package/commands/harness-solo.md

@@ -1,103 +0,0 @@
----
-docmeta:
-  id: harness-solo
-  title: /harness-solo — 비상용 Single-Agent Fallback
-  type: input
-  createdAt: 2026-04-20T00:00:00Z
-  updatedAt: 2026-05-07T00:00:00Z
-  source:
-    producer: user
-    skillId: harness
-  inputs:
-    - documentId: skill-conductor
-      uri: ../skills/conductor/SKILL.md
-      relation: output-from
-      sections:
-        - sourceRange: { startLine: 115, endLine: 145 }   # §7.5 모드 결정 위임 룰 + user_override 채널
-          targetRange: { startLine: 17, endLine: 22 }     # 본 명령의 v6.0 override 안내 블록
-    - documentId: config-template
-      uri: ../assets/templates/config.json
-      relation: output-from
-      sections:
-        - sourceRange: { startLine: 345, endLine: 372 }   # mode_selection 룰 (force_solo_when 등)
-          targetRange: { startLine: 17, endLine: 22 }
-  tags: [harness, solo-mode, command, override, v6]
----
-
-# /harness-solo — 비상용 Single-Agent Fallback (v6.0+)
-
-> v6.0 의 정상 경로는 회사형 자동 루프입니다. 본 명령은 그 루프를 일시적으로 벗어나는 **비상용 override** 입니다.
->
-> **효과**: `progress.json.mode = "solo"` 강제 + `mode_decision.user_override = "solo"` 기록. 현재 sprint 끝까지 유지. 다음 sprint 진입 시 Conductor 가 재자동결정. **Auto 복귀**: 사용자 발화 "auto 로 돌려" 또는 "Conductor 결정으로".
-
-디버깅, 스크립트 장애, 수동 hotfix 같은 예외 상황에서만 사용합니다.
-회사 루프에서 전환 시, 진행 중이던 피처의 상태를 보존하고 단일 에이전트 fallback 으로 이어갑니다.
-
-## 실행 절차
-
-### Step 1: 현재 모드 확인 + 전환
-
-```bash
-# 현재 mode 읽기
-MODE=$(jq -r '.mode // "solo"' .harness/progress.json 2>/dev/null)
-echo "현재 모드: $MODE"
-```
-
-**team → solo 전환 시:**
-```bash
-# in_progress features를 ready로 복구
-bash scripts/harness-queue-manager.sh recover .
-
-# mode를 solo로 설정
-jq '.mode = "solo" | .mode_decision.user_override = "solo" | .team_state.active_teams = 0 | .team_state.paused_at = (now | todate)' .harness/progress.json > /tmp/progress_tmp.json && mv /tmp/progress_tmp.json .harness/progress.json
-```
-
-**paused → solo 전환 시:**
-```bash
-jq '.mode = "solo" | .mode_decision.user_override = "solo"' .harness/progress.json > /tmp/progress_tmp.json && mv /tmp/progress_tmp.json .harness/progress.json
-```
-
-### Step 2: 현재 진행 상태 표시
-
-```bash
-# progress.json 상태 확인
-cat .harness/progress.json | jq '{mode, sprint, current_agent, agent_status, next_agent}'
-
-# feature-queue.json이 있으면 남은 피처 표시
-if [ -f .harness/actions/feature-queue.json ]; then
-  echo "=== Feature Queue ==="
-  bash scripts/harness-queue-manager.sh status .
-fi
-```
-
-### Step 3: 다음 에이전트 안내
-
-progress.json의 `next_agent` 필드를 확인하여 다음 단계를 안내합니다:
-
-- **next_agent = "dispatcher"** → "프롬프트로 요구사항을 입력하면 자동으로 dispatcher가 분석합니다."
-- **next_agent = "planner"** → Planner 단계가 다음입니다. SessionStart / 내부 handoff가 연결돼 있으면 자동 진입, 아니면 해당 스킬을 수동 호출합니다.
-- **next_agent = "generator-backend"** → Backend generator 단계가 다음입니다.
-- **next_agent = "generator-frontend"** → Frontend generator 단계가 다음입니다.
-- **next_agent = "evaluator-functional"** → Functional evaluator 단계가 다음입니다.
-- **next_agent = "evaluator-visual"** → Visual evaluator 단계가 다음입니다.
-
-### Step 4: Solo 모드 진행
-
-각 에이전트는 완료 즉시 **내부 handoff(`harness-next.sh` 또는 SessionStart hook)** 로 다음 에이전트에 넘겨집니다. Owner가 `/harness-next` 를 직접 다룬다는 전제는 6.0 회사 모델과 맞지 않습니다.
-
-**예외 — 사용자 승인 게이트가 있는 단계:**
-- **Brainstorming**: brainstorm-spec.md 완성 후 사용자 승인 대기 → 승인 시 내부 handoff
-- **Planner**: plan.md / api-contract.json 완성 후 사용자 승인 대기 → 승인 시 내부 handoff
-
-흐름이 멈췄다면 원인은 보통 내부 handoff 스크립트/훅 미설치 또는 `next_agent` 불일치입니다. 이 경우 상태 파일과 hook 설치 상태를 먼저 점검합니다.
-
-feature-queue.json이 존재하는 경우:
-- 피처 완료(evaluator PASS) 시 `bash scripts/harness-queue-manager.sh pass {FEATURE_ID} .`를 호출하여 공유 상태 업데이트
-- Team 모드로 전환해도 이미 완료된 피처는 skip됨
-
-## 사용 권장 상황
-
-- 프롬프트로 각 에이전트 순차 실행
-- 내부 handoff 스크립트 장애 시 응급 복구
-- 아주 짧은 수동 hotfix / 상태 수선
-- 정상 회사 루프로 복귀: `/harness-team`

package/commands/harness-stop.md

@@ -1,53 +0,0 @@
-# /harness-stop — Team Mode 중단
-
-실행 중인 Team 모드를 안전하게 중단합니다.
-진행 중인 피처는 ready 상태로 복구되어, 이후 Solo 또는 Team 모드에서 이어갈 수 있습니다.
-
-## 실행 절차
-
-### Step 1: 현재 모드 확인
-
-```bash
-MODE=$(jq -r '.mode // "solo"' .harness/progress.json 2>/dev/null)
-echo "현재 모드: $MODE"
-```
-
-- **solo** → "이미 Solo 모드입니다. Team을 시작하려면 /harness-team 을 사용하세요." 안내 후 중단.
-- **team** → Step 2로 진행.
-
-### Step 2: Queue 상태 보존
-
-```bash
-# in_progress features를 ready로 복구
-bash scripts/harness-queue-manager.sh recover .
-
-# 현재 큐 상태 출력
-bash scripts/harness-queue-manager.sh status .
-```
-
-### Step 3: 모드 전환
-
-```bash
-# mode를 paused로 설정 (team에서 명시적으로 중단)
-jq '.mode = "paused" | .team_state.active_teams = 0 | .team_state.paused_at = (now | todate)' .harness/progress.json > /tmp/progress_tmp.json && mv /tmp/progress_tmp.json .harness/progress.json
-```
-
-### Step 4: tmux 세션 정리 (선택)
-
-```bash
-# harness-studio tmux 세션이 있으면 정리
-tmux kill-session -t harness-studio 2>/dev/null && echo "tmux 세션 정리 완료" || echo "활성 tmux 세션 없음"
-```
-
-### Step 5: 재개 안내
-
-다음 안내를 사용자에게 전달합니다:
-
-```
-Team 모드가 안전하게 중단되었습니다.
-진행 중이던 피처는 ready 상태로 복구되었습니다.
-
-재개 방법:
-  /harness-team    → Team 모드 재개 (남은 피처 자동 할당)
-  /harness-solo    → Solo 모드로 전환 (프롬프트 기반 순차 진행)
-```