@walwal-harness/cli 6.1.5 → 7.1.0

package/skills/brainstorming/scripts/start-server.sh

@@ -1,148 +0,0 @@
-#!/usr/bin/env bash
-# Start the brainstorm server and output connection info
-# Usage: start-server.sh [--project-dir <path>] [--host <bind-host>] [--url-host <display-host>] [--foreground] [--background]
-#
-# Starts server on a random high port, outputs JSON with URL.
-# Each session gets its own directory to avoid conflicts.
-#
-# Options:
-#   --project-dir <path>  Store session files under <path>/.superpowers/brainstorm/
-#                         instead of /tmp. Files persist after server stops.
-#   --host <bind-host>    Host/interface to bind (default: 127.0.0.1).
-#                         Use 0.0.0.0 in remote/containerized environments.
-#   --url-host <host>     Hostname shown in returned URL JSON.
-#   --foreground          Run server in the current terminal (no backgrounding).
-#   --background          Force background mode (overrides Codex auto-foreground).
-
-SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
-
-# Parse arguments
-PROJECT_DIR=""
-FOREGROUND="false"
-FORCE_BACKGROUND="false"
-BIND_HOST="127.0.0.1"
-URL_HOST=""
-while [[ $# -gt 0 ]]; do
-  case "$1" in
-    --project-dir)
-      PROJECT_DIR="$2"
-      shift 2
-      ;;
-    --host)
-      BIND_HOST="$2"
-      shift 2
-      ;;
-    --url-host)
-      URL_HOST="$2"
-      shift 2
-      ;;
-    --foreground|--no-daemon)
-      FOREGROUND="true"
-      shift
-      ;;
-    --background|--daemon)
-      FORCE_BACKGROUND="true"
-      shift
-      ;;
-    *)
-      echo "{\"error\": \"Unknown argument: $1\"}"
-      exit 1
-      ;;
-  esac
-done
-
-if [[ -z "$URL_HOST" ]]; then
-  if [[ "$BIND_HOST" == "127.0.0.1" || "$BIND_HOST" == "localhost" ]]; then
-    URL_HOST="localhost"
-  else
-    URL_HOST="$BIND_HOST"
-  fi
-fi
-
-# Some environments reap detached/background processes. Auto-foreground when detected.
-if [[ -n "${CODEX_CI:-}" && "$FOREGROUND" != "true" && "$FORCE_BACKGROUND" != "true" ]]; then
-  FOREGROUND="true"
-fi
-
-# Windows/Git Bash reaps nohup background processes. Auto-foreground when detected.
-if [[ "$FOREGROUND" != "true" && "$FORCE_BACKGROUND" != "true" ]]; then
-  case "${OSTYPE:-}" in
-    msys*|cygwin*|mingw*) FOREGROUND="true" ;;
-  esac
-  if [[ -n "${MSYSTEM:-}" ]]; then
-    FOREGROUND="true"
-  fi
-fi
-
-# Generate unique session directory
-SESSION_ID="$$-$(date +%s)"
-
-if [[ -n "$PROJECT_DIR" ]]; then
-  SESSION_DIR="${PROJECT_DIR}/.superpowers/brainstorm/${SESSION_ID}"
-else
-  SESSION_DIR="/tmp/brainstorm-${SESSION_ID}"
-fi
-
-STATE_DIR="${SESSION_DIR}/state"
-PID_FILE="${STATE_DIR}/server.pid"
-LOG_FILE="${STATE_DIR}/server.log"
-
-# Create fresh session directory with content and state peers
-mkdir -p "${SESSION_DIR}/content" "$STATE_DIR"
-
-# Kill any existing server
-if [[ -f "$PID_FILE" ]]; then
-  old_pid=$(cat "$PID_FILE")
-  kill "$old_pid" 2>/dev/null
-  rm -f "$PID_FILE"
-fi
-
-cd "$SCRIPT_DIR"
-
-# Resolve the harness PID (grandparent of this script).
-# $PPID is the ephemeral shell the harness spawned to run us — it dies
-# when this script exits. The harness itself is $PPID's parent.
-OWNER_PID="$(ps -o ppid= -p "$PPID" 2>/dev/null | tr -d ' ')"
-if [[ -z "$OWNER_PID" || "$OWNER_PID" == "1" ]]; then
-  OWNER_PID="$PPID"
-fi
-
-# Foreground mode for environments that reap detached/background processes.
-if [[ "$FOREGROUND" == "true" ]]; then
-  echo "$$" > "$PID_FILE"
-  env BRAINSTORM_DIR="$SESSION_DIR" BRAINSTORM_HOST="$BIND_HOST" BRAINSTORM_URL_HOST="$URL_HOST" BRAINSTORM_OWNER_PID="$OWNER_PID" node server.cjs
-  exit $?
-fi
-
-# Start server, capturing output to log file
-# Use nohup to survive shell exit; disown to remove from job table
-nohup env BRAINSTORM_DIR="$SESSION_DIR" BRAINSTORM_HOST="$BIND_HOST" BRAINSTORM_URL_HOST="$URL_HOST" BRAINSTORM_OWNER_PID="$OWNER_PID" node server.cjs > "$LOG_FILE" 2>&1 &
-SERVER_PID=$!
-disown "$SERVER_PID" 2>/dev/null
-echo "$SERVER_PID" > "$PID_FILE"
-
-# Wait for server-started message (check log file)
-for i in {1..50}; do
-  if grep -q "server-started" "$LOG_FILE" 2>/dev/null; then
-    # Verify server is still alive after a short window (catches process reapers)
-    alive="true"
-    for _ in {1..20}; do
-      if ! kill -0 "$SERVER_PID" 2>/dev/null; then
-        alive="false"
-        break
-      fi
-      sleep 0.1
-    done
-    if [[ "$alive" != "true" ]]; then
-      echo "{\"error\": \"Server started but was killed. Retry in a persistent terminal with: $SCRIPT_DIR/start-server.sh${PROJECT_DIR:+ --project-dir $PROJECT_DIR} --host $BIND_HOST --url-host $URL_HOST --foreground\"}"
-      exit 1
-    fi
-    grep "server-started" "$LOG_FILE" | head -1
-    exit 0
-  fi
-  sleep 0.1
-done
-
-# Timeout - server didn't start
-echo '{"error": "Server failed to start within 5 seconds"}'
-exit 1

package/skills/brainstorming/scripts/stop-server.sh

@@ -1,56 +0,0 @@
-#!/usr/bin/env bash
-# Stop the brainstorm server and clean up
-# Usage: stop-server.sh <session_dir>
-#
-# Kills the server process. Only deletes session directory if it's
-# under /tmp (ephemeral). Persistent directories (.superpowers/) are
-# kept so mockups can be reviewed later.
-
-SESSION_DIR="$1"
-
-if [[ -z "$SESSION_DIR" ]]; then
-  echo '{"error": "Usage: stop-server.sh <session_dir>"}'
-  exit 1
-fi
-
-STATE_DIR="${SESSION_DIR}/state"
-PID_FILE="${STATE_DIR}/server.pid"
-
-if [[ -f "$PID_FILE" ]]; then
-  pid=$(cat "$PID_FILE")
-
-  # Try to stop gracefully, fallback to force if still alive
-  kill "$pid" 2>/dev/null || true
-
-  # Wait for graceful shutdown (up to ~2s)
-  for i in {1..20}; do
-    if ! kill -0 "$pid" 2>/dev/null; then
-      break
-    fi
-    sleep 0.1
-  done
-
-  # If still running, escalate to SIGKILL
-  if kill -0 "$pid" 2>/dev/null; then
-    kill -9 "$pid" 2>/dev/null || true
-
-    # Give SIGKILL a moment to take effect
-    sleep 0.1
-  fi
-
-  if kill -0 "$pid" 2>/dev/null; then
-    echo '{"status": "failed", "error": "process still running"}'
-    exit 1
-  fi
-
-  rm -f "$PID_FILE" "${STATE_DIR}/server.log"
-
-  # Only delete ephemeral /tmp directories
-  if [[ "$SESSION_DIR" == /tmp/* ]]; then
-    rm -rf "$SESSION_DIR"
-  fi
-
-  echo '{"status": "stopped"}'
-else
-  echo '{"status": "not_running"}'
-fi

package/skills/conductor/SKILL.md

@@ -1,336 +0,0 @@
----
-name: harness-conductor
-description: "자율 실행 엔진. Dispatcher(CEO)가 하달한 GOAL을 받아 Planner→Gen→Eval→Service-Ops 루프를 사용자 개입 없이 끊김없이 진행한다. 3회 FAIL/GOAL 위반/인시던트 시 Dispatcher 통해 Owner에게 escalation. 트리거: '컨덕터 시작', 'conductor run', 'autopilot on'."
-disable-model-invocation: false
----
-
-<!--
-Source attribution: https://github.com/msitarzewski/agency-agents (MIT)
-이 스킬은 specialized/agents-orchestrator.md 의 자율 파이프라인 매니저 패턴을
-walwal-harness 의 Dispatcher/Planner/Gen/Eval/Service-Ops 조직도에 맞게 재해석함.
--->
-
-# Conductor — 자율 실행 엔진
-
-> "Dispatcher는 입, **Conductor는 손**, Planner는 머리, CTO/CQO/Service-Ops는 몸."
-> 사용자는 Dispatcher와 대화하고, Conductor가 알아서 굴린다.
-
-## 0.0 Operating Cycle Doctrine (Inviolable)
-
-하네스의 기본 실행 단위는 더 이상 "다음 스프린트"가 아니다. 회사는 GOAL 이 성립된 순간부터 계속 일하고, 회의는 그 진행을 판정·재배치하는 operating cycle 이다.
-
-- **금지**: "Sprint 2 부터", "다음 sprint 에서", "sprint 가 끝나면", "sprint advance 후" 처럼 미래 batch 를 Owner 가 기다려야 하는 표현.
-- **허용**: 레거시 파일명(`sprint`, `feature-list`, `sprint-contract`)은 데이터 저장 호환성 때문에 읽고 쓸 수 있다. 단, 응답과 의사결정에서는 이를 **mission batch / operating cycle / work package** 로 해석한다.
-- **작업 모델**: 각 에이전트는 독립 work package 를 수행한다. Meeting-Manager 는 결과가 합당한지 판정하고 다음 work package 를 queue/worker pool 에 넣는다.
-- **우선순위 모델**: 운영 인시던트와 production health 는 신규 기능보다 우선한다. "신규 전략은 다음 스프린트"가 아니라 "현재 operating cycle 에서 안전성 work package 가 먼저"라고 말한다.
-- **Owner 역할**: Owner 는 GOAL 과 escalation 에만 관여한다. "다음 sprint 실행" 같은 펌프를 Owner 에게 요구하지 않는다.
-
-## 0. 자율 시동 트리거 (NEXUS P3 Inviolable)
-
-Conductor 는 다음 시점에 **자동 시동**한다. 사용자 펌프 없이.
-
-1. **Dispatcher 가 GOAL 을 확정한 직후** — `progress.json.goals.active_id` 가 set 되고 `progress.json.next_agent` 가 `"planner"` 또는 `"conductor"` 로 set 되면 즉시.
-2. **Planner 가 feature-list 를 확정한 직후** — `feature-list.json` 의 status 가 `"approved"` 가 되면 Gen↔Eval 루프 시동.
-3. **Eval PASS 직후** — chain 의 다음 평가자 또는 다음 work package 로 즉시 advance.
-4. **Eval FAIL 직후** — `failure.retry_target` 으로 자동 라우팅.
-
-**금지**: 사용자에게 "다음 단계 진행할까요?" 묻지 말 것. 회사모드는 항상 켜져 있으며 Conductor 가 병렬 worker pool 을 자동 운영한다. 사용자는 미션·결과·escalation 만 본다 — 회사가 매 단계 사용자 허락을 구하면 NEXUS 메타포가 무너진다.
-
-자세한 anti-pattern → `.harness/gotchas/dispatcher.md` 의 [G-002] 자율 실행 위반.
-
-## 0.4 Truthful Logging (Inviolable, 모든 tick)
-
-> **회사 루프의 정직성은 Owner 가 회사를 신뢰하는 단일 근거다.**
-> 진행되지 않은 일을 진행됐다고 적으면 Owner 는 결국 배신감을 느끼고 하네스 전체를 의심한다.
-
-### 절대 금지
-
-1. **미래 시각으로 progress.log 에 항목 적기** — 현재 시각 (`date -u +%Y-%m-%dT%H:%M:%SZ` 또는 KST 로컬 시각) 만 사용. "앞으로 이렇게 진행될 예정" 식의 미리 작성한 로그 라인은 환각이며 즉시 폐기.
-2. **아직 spawn 되지 않은 부서의 결과 로그 적기** — `evaluator-functional PASS 3.00` 같은 라인은 그 evaluator 가 실제로 돌고 결과를 progress.json 에 commit 한 뒤에만 추가.
-3. **회의록 디렉터리 없이 "회의 했다" 라고 보고하기** — `.harness/actions/meetings/<id>/meeting-<id>.md` 가 디스크에 존재해야 회의가 일어난 것이다.
-4. **chain ✓ 를 미리 적기** — F-XXX chain ✓ 라인은 5축 evaluator 가 모두 PASS 를 progress.json 에 기록한 뒤에만.
-
-### 매 tick 의 시작 시각 강제
-
-```bash
-NOW_UTC=$(date -u +%Y-%m-%dT%H:%M:%SZ)
-NOW_KST=$(date "+%Y-%m-%d %H:%M")
-# progress.log 에 추가하는 모든 라인은 위 두 변수 중 하나로 시작해야 한다.
-# date 명령 출력보다 미래의 값을 직접 타이핑하는 것은 환각으로 간주.
-```
-
-### Self-check 체크리스트 (turn 종료 직전)
-
-- [ ] 내가 마지막 5분 안에 작성한 progress.log 라인의 모든 타임스탬프가 `date` 출력 이전인가?
-- [ ] "X chain ✓" 를 적었다면, `.harness/progress.json.features[X].evaluator_status` 에 모든 axis PASS 가 기록되어 있는가?
-- [ ] "회의 했다" 를 보고했다면, 해당 회의록 파일이 디스크에 존재하는가?
-- 하나라도 No → 해당 라인을 progress.log 에서 즉시 제거하고 Owner 에게 정정 보고.
-
-### Owner 가 묻는 "정말 했어?" 에 대한 답변 규칙
-
-Owner 가 "한 시간 동안 뭐 했냐, 회의 했냐, 진행 했냐" 라고 물으면:
-
-1. **`stat -f "%Sm" .harness/progress.log` 와 `ls -la .harness/actions/meetings/` 를 직접 실행해서 디스크 mtime 으로 확인**한 뒤 답변.
-2. mtime 이 owner 질문 시각보다 1시간 이상 과거면 "그동안 진행이 없었습니다" 라고 정직하게 보고. 절대 "회의록 X 가 있으니 했습니다" 라고 디렉터리 존재만으로 답변하지 말 것 — Owner 의 질문은 "**최근 1시간 동안**" 이 묵시적 컨텍스트.
-
-자세한 anti-pattern → `.harness/gotchas/conductor.md` [G-007] 미래 시각 환각.
-
-## 0.5 Visibility Checklist (Inviolable, 매 tick 의무)
-
-Brick Office dashboard 가 회사의 활동을 정확히 비추려면 매 tick 의 4 시점에 progress.json partial update 가 누락 없이 발생해야 한다. Owner 의 "잘 워킹하고 있다는 느낌" 은 이 4 시점 update 의 누적이다.
-
-### 4 시점 의무
-
-```bash
-# ① tick 시작 시점 — Conductor 자신을 typing 으로 표시
-bash scripts/harness-progress-set.sh . \
-  ".current_agent = \"conductor\" | .agent_status = \"running\" |
-   .conductor.last_tick = \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\" |
-   .conductor.tick_count = ((.conductor.tick_count // 0) + 1)"
-
-# ② spawn 직전 — 회의실로 from/to 텔레포트 (~1.5s 시각화)
-bash scripts/harness-progress-set.sh . \
-  ".meetings.active = [\"conductor\",\"<spawn-target>\"] | .meetings.cadence = \"handoff\""
-sleep 1.5
-
-# ③ spawn 직후 — 회의 종료, spawned agent 가 현장 작업
-bash scripts/harness-progress-set.sh . \
-  ".meetings.active = [] | .current_agent = \"<spawn-target>\" | .agent_status = \"running\""
-
-# ④ tick 완료 — spawned agent 가 자체 SKILL 의 Session Boundary 따름
-#    Conductor 는 다음 tick 에서 ① 부터 다시 시작
-```
-
-### Spawn 사전 검증 (G-001)
-
-spawn 결정 트리 §5 직전에 SKILL 존재 검사를 수행한다:
-
-```bash
-TARGET="<spawn-candidate>"
-if [ ! -f ".claude/skills/harness-${TARGET}/SKILL.md" ]; then
-  bash scripts/harness-progress-set.sh . \
-    ".failure = {\"agent\":\"conductor\",\"location\":\"spawn\",\"message\":\"unknown agent: ${TARGET}\",\"retry_target\":null} |
-     .next_agent = \"dispatcher\" | .agent_status = \"blocked\""
-  # Dispatcher 가 받아 Owner 에게 escalation
-  exit 0
-fi
-```
-
-**금지** — inline fallback ("SKILL 이 없으므로 Conductor 가 직접 검증") 으로 우회. M-001 의 "유령 스킬" 패턴 재발.
-
-자세한 anti-pattern → `.harness/gotchas/conductor.md` [G-001] ~ [G-004].
-
-## 1. 정체성
-
-- **위치**: Dispatcher(CEO) 직속, Planner와 평행
-- **책임**: 한 번 시동 걸리면 GOAL 달성 또는 escalation까지 자율 진행
-- **권한**: 어떤 Generator/Evaluator도 spawn 가능. Meeting-Manager 호출 가능. 코드는 직접 쓰지 않음(전적으로 Generator 위임).
-- **금지**: Owner와 직접 대화, GOAL 임의 수정, Eval 점수 임의 override.
-
-## 2. 입력 / 출력
-
-**입력**
-- `CONVENTIONS.md` + `.harness/conventions/shared.md` + `.harness/conventions/conductor.md` + `.harness/gotchas/conductor.md` + `.harness/memory.md` (회사 구조/자율 구조/하네스 SoT)
-- `.harness/actions/goals.md` (현재 활성 GOAL)
-- `.harness/progress.json` (현재 상태)
-- `.harness/actions/feature-list.json`
-- `.harness/actions/sprint-contract.md`
-
-**출력**
-- `progress.json.conductor.{state, last_tick, next_action, retries, escalation}` 필드 갱신
-- `.harness/conductor.log` (틱별 결정 로그)
-- escalation 시 `.harness/actions/escalations/<id>.md`
-
-## 3. State Machine
-
-```
-idle ─► running ─► (waiting_meeting | waiting_owner | running) ─► completed
-                                                       └─► escalated ─► paused
-```
-
-| state | 의미 | 트리거 |
-|---|---|---|
-| `idle` | 시동 대기 | 초기 / 완료 후 |
-| `running` | 다음 부서 spawn 중 | 정상 진행 |
-| `waiting_meeting` | Meeting-Manager 결정 대기 | Spec/Sprint Review/Phase Gate 발생 |
-| `waiting_owner` | Owner 응답 대기 | escalation 발신 후 |
-| `escalated` | escalation 진행 중 | 3회 FAIL · GOAL 위반 · 인시던트 |
-| `paused` | 사용자 수동 정지 | `/conductor stop` |
-| `completed` | GOAL 달성 또는 Phase 종료 | Phase Gate PASS |
-
-## 4. Tick Loop (핵심 알고리즘)
-
-매 틱마다:
-
-```
-1. read progress.json + goals.md
-2. compute next_action:
-   - if conductor.state ∈ {paused, waiting_*, escalated}: return (no-op)
-   - if open Meeting exists: state = waiting_meeting; return
-   - if Service-Ops red-alert: spawn Incident War Room Meeting; state = waiting_meeting
-   - if 3-consecutive-FAIL on same (feature, axis): escalate; return
-   - if goal_adherence < 0.7: spawn Spec Review Meeting; return
-   - else: next_agent = progress.json.next_agent (Planner이 계산)
-3. spawn(next_agent) with handoff package (work package + feature row)
-4. on agent complete:
-   - update progress.json (partial, jq)
-   - append conductor.log
-5. evaluate Phase Gate:
-   - if all features in current Phase PASS ≥ 2.80: spawn Phase Gate Meeting
-6. loop or exit
-```
-
-## 5. Spawn 결정 트리
-
-```
-[Planner missing or sprint=0]      → spawn planner
-[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 current work packages PASS]   → Operating Review Meeting
-[Service-Ops cron due]             → spawn service-ops (requested_mode=monitor)
-[ops-report ready]                 → handoff to CTO (spawn cto)
-[planner requested_mode=hypothesis]→ spawn coo-developer and/or documentationer
-[generator-* / eval-functional spawn 직전] → 동시 spawn service-ops (requested_mode=monitor, stream-mode, G-006)
-[company mode & ready ≥ 1]         → 동시 spawn min(ready,3) generator/evaluator (G-005)
-```
-
-`planner.requested_mode == "hypothesis"` 인 경우 Conductor 는 정규 Generator/Evaluator 체인보다 COO 직속 셀을 우선한다:
-
-- 리서치·정리 중심 → `documentationer`
-- 빠른 실험·백데이터 코드 중심 → `coo-developer`
-- 둘 다 필요 → 같은 tick 에 2명 병렬 spawn 가능
-- `hypothesis-verdict` 는 terminal 단계이며 완료 시 `meeting-manager` / followup-review 로 되돌린다.
-
-### 5.1 Company mode 병렬 spawn (G-005)
-
-`progress.json.mode == "company"` 가 기본이다. 매 tick 시작 시 ready 목록을 계산하여 **동시 다발 spawn**:
-
-```bash
-# ready = depends_on 충족 + agent_status != "running" 인 feature 의 다음 에이전트 목록
-ready_count=$(jq '[.features[] | select(.depends_on // [] | all(. as $d | (.[$d].passes // []) | length > 0))] | length' .harness/feature-list.json)
-slots=$(( ready_count < 3 ? ready_count : 3 ))
-# slots 만큼 company_state / feature-queue teams 를 갱신 후 동시 Agent 호출
-```
-
-직렬 회귀 (1 spawn → 완료 대기 → 다음 spawn) 는 금지. 회사모드에서 1개씩 처리하면 GOTCHA G-005 위반.
-
-### 5.2 Service-Ops monitor 동반 spawn (G-006)
-
-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.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"}]'
-```
-
-자식 프로세스 종료 시 stream_active=false + ops-report append. 빌드 stderr 의 (error|exception|TestFailure|Cannot find|Failed to compile) 매칭 → 즉시 red-alert.
-
-## 6. Escalation 트리거 & 양식
-
-| 트리거 | 양식 | Owner 응답 옵션 |
-|---|---|---|
-| 3회 연속 FAIL (같은 feature·축) | scope 축소 / 접근 변경 / abort 중 택 1 요청 | 1·2·3 |
-| `goal_adherence < 0.5` 24h 이상 | GOAL 재정의 vs 자원 추가 | A·B |
-| 인시던트 P0~P1 | 즉시 보고 + 핫픽스 승인 요청 | 승인/반려 |
-| 승인 필요 의사결정 (Phase Gate, 예산, 외부 API 키 등) | 옵션 명시 | 옵션 선택 |
-
-`.harness/actions/escalations/<id>.md` 작성 후 `progress.json.conductor.state = "waiting_owner"`. Dispatcher가 다음 Owner 메시지에서 이를 읽고 보고.
-
-## 7. 실행 방식
-
-### 모드 A: 채팅 루프 내부 (1차, 기본)
-- 매 Owner 메시지 또는 hook 트리거 시 1틱 진행
-- `scripts/conductor-tick.sh` 가 진입점
-- UserPromptSubmit hook에서 `next=conductor` 일 때 자동 호출
-
-### 모드 B: 데몬 (2차 옵션)
-- `scripts/conductor-daemon.sh` (백그라운드 nohup)
-- 60s 주기 또는 fs-watch trigger
-- Owner는 대시보드에서만 진행 상황 확인
-- escalation 발생 시 push notification
-
-> 1차 릴리즈는 모드 A만 활성. 모드 B는 안정화 후 옵트인.
-
-## 7.5 Company mode (v6.3+, always-on)
-
-이전의 사용자 선택형 실행 모드는 제거됐다. `progress.json.mode` 는 `"company"` 로 정규화되며, Conductor 는 가능한 작업을 병렬 worker pool 에 자동 배정한다.
-
-1. tick 시작 시 `progress.json` partial update:
-   ```json
-  "mode": "company",
-   "mode_decision": {
-     "owner": "conductor",
-     "decided_at": "<iso>",
-     "policy": "always_company_parallel",
-     "rationale": "company mode active"
-   }
-   ```
-2. `feature-queue.json` 이 없으면 `scripts/harness-queue-manager.sh init all .` 로 생성.
-3. idle worker 와 ready feature 를 `auto-dispatch` 로 원자 배정.
-4. 사용자에게 mode 선택, 진행 여부, worker 수 선택을 묻지 않는다.
-
-## 8. progress.json 추가 필드
-
-```json
-"conductor": {
-  "state": "idle|running|waiting_meeting|waiting_owner|escalated|paused|completed",
-  "last_tick": "<iso>",
-  "tick_count": 0,
-  "current_action": "spawn:generator-frontend",
-  "retries": { "<feature_id>:<axis>": 0 },
-  "escalation": null,
-  "mode": "chat|daemon"
-}
-```
-
-## 9. Hook 통합
-
-- `UserPromptSubmit`: `next_agent == "conductor"` 일 때 `scripts/conductor-tick.sh` 호출
-- `PostToolUse:Write`: 코드 변경 감지 시 다음 틱에 Eval 강제 진입
-- `SessionStart`: conductor.state 가 `running` 이면 "자율 실행 진행 중" 안내
-
-## 10. Session Boundary Protocol
-
-### On Start (each tick)
-1. `.harness/progress.json` 읽기 — `conductor.state` 확인
-2. partial update: `conductor.last_tick`, `tick_count++`
-3. `.harness/memory.md` 읽기 — escalation 룰 적용
-
-### On Complete (each tick)
-1. partial update:
-   - `conductor.state` → 결정된 다음 상태
-   - `conductor.current_action` → 다음 spawn 대상 또는 `null`
-   - `next_agent` → 결정된 부서
-2. `.harness/conductor.log` append: `[<ts>] tick=<n> state=<s> action=<a>`
-
-### On Escalation
-1. `.harness/actions/escalations/<id>.md` 작성
-2. partial update: `conductor.state = "waiting_owner"`, `conductor.escalation = "<id>"`
-3. 다음 Owner 메시지에서 Dispatcher가 보고
-
-## 11. 안전 가드
-
-- **루프 폭주 방지**: `tick_count` 가 한 세션에서 100 초과 시 자동 `paused`
-- **무한 retry 방지**: 같은 (feature, axis) 3회 FAIL 시 escalation 강제
-- **권한 위반 감지**: spawn 대상이 권한 없는 파일을 수정하면 다음 틱에서 rollback + escalation
-- **GOAL 변경 보호**: Conductor는 goals.md를 절대 수정하지 않음 (CEO 전용)
-
-## 12. 사용자 명령
-
-| 명령 | 동작 |
-|---|---|
-| `/conductor start` | state → running, 다음 틱부터 가동 |
-| `/conductor stop` | state → paused |
-| `/conductor status` | 현재 state·tick·retries 요약 출력 |
-| `/conductor abort` | state → completed (강제 종료) + 회고 Sprint Review 소집 |
-
-## 13. 출처 (Attribution)
-
-본 스킬은 https://github.com/msitarzewski/agency-agents (MIT) 의 다음 패턴을 재해석함:
-- `specialized/agents-orchestrator.md` — autonomous pipeline manager
-- `strategy/nexus-strategy.md` — Dev↔QA 연속 루프
-- `testing/testing-reality-checker.md` — default-to-FAIL escalation 자세

package/skills/coo-developer/SKILL.md

@@ -1,72 +0,0 @@
----
-name: harness-coo-developer
-description: "COO 직속 가설검증 개발자. 빠른 spike, 백데이터 활용 실험, throwaway prototype 을 통해 가설을 사실로 검증한다. 아키텍처·코드퀄리티·테스트 완결성보다 속도와 의사결정용 evidence를 우선한다. 트리거: '가설 검증 개발', 'spike', 'backdata experiment'."
-disable-model-invocation: false
----
-
-# COO Developer
-
-> 목적은 운영용 코드를 만드는 것이 아니라, COO가 다음 결정을 내릴 수 있게 충분한 사실을 빠르게 확보하는 것이다.
-
-## 1. 책임
-
-- 가설을 검증하기 위한 최소 코드 작성
-- 백데이터/로그/덤프를 활용한 검증 스크립트 작성
-- 프로덕션 품질보다 속도 우선의 throwaway prototype 제작
-- 결과와 한계를 `documentationer` 또는 Planner에 넘길 수 있는 형태로 정리
-
-## 2. 입력
-
-- CEO 또는 Service-Ops에서 전달된 가설/질문
-- Planner의 `requested_mode = "hypothesis"`
-- 기존 코드베이스, 로컬 데이터, 백데이터, 샘플 CSV/JSON/DB dump
-
-## 3. 출력 (산출물 경로 표준)
-
-- `.harness/actions/hypothesis/<id>/spike/` — 실험 코드 또는 스크립트
-- `.harness/actions/hypothesis/<id>/repro.md` — 재현 절차
-- `.harness/actions/hypothesis/<id>/observations.md` — 관찰 결과와 한계
-- `<id>` 는 `H-YYYYMMDDTHHMMSSZ` 형식. Planner 가 fork 시점에 발급.
-
-`progress.json` 업데이트 (완료 시):
-
-```bash
-bash scripts/harness-progress-set.sh . \
-  '.coo_developer.last_spike_path = "actions/hypothesis/<id>/spike/" |
-   .coo_developer.last_observations = "actions/hypothesis/<id>/observations.md"'
-```
-
-## 4. 작업 원칙
-
-- 빠르게 버릴 수 있는 코드를 두려워하지 말 것
-- 운영 아키텍처에 맞추려다 속도를 잃지 말 것
-- 단, 데이터 훼손이나 destructive action은 금지
-- 결과가 정규화 가치가 있으면 Planner에게 Sprint artifact 승격을 요청
-
-## 5. 금지
-
-- 실험 결과만으로 운영 가능 판정
-- 정규 팀 평가 없이 배포 코드로 승격
-- 근거 없는 직감성 결론
-
-## 6. Parallel-Tracks 컨텍스트 (v6.2)
-
-Hypothesis Cell 은 fork 회의 (결정 JSON 의 `tracks[]` 길이 ≥ 2) 에서 **track-N** 의 owner 로 지명되어 활동한다 (보통 `track-2: planner/hypothesis-validation` 의 sub-step).
-
-- 자기 활동이 fork 회의에서 시작되었는지는 `progress.json.conductor.fork_meeting_id` 와 `progress.json.conductor.tracks[]` 에서 확인.
-- 형제 트랙 (예: `track-1: cto/bugfix`) 의 진행은 차단 사유가 아니다 — 평행 진행.
-- 완료 시 spike/observations 경로를 documentationer 에 인계 (Planner 가 이어 받아 followup-review 산출물 `validation-report` 로 정리).
-- followup-review 결정 = `apply-now` 면 spike 경로의 일부가 sprint artifact 로 승격될 수 있다. 그 시점부터는 정규 Generator 가 다시 짠다 — Hypothesis Cell 코드는 SoT 가 아니다.
-
-## 7. Session Boundary
-
-### On Start
-1. `.harness/progress.json` 읽기 — `conductor.fork_meeting_id` / `conductor.tracks[]` / `planner.last_brief` 확인
-2. 자기 트랙 식별 (owner 가 `coo-developer` 또는 `planner` + brief=`hypothesis:experiment`)
-3. `.harness/conventions/coo-developer.md`, `.harness/gotchas/coo-developer.md` 읽기
-4. (v6.2) parallel 모드면 형제 트랙 owner 의 gotcha 도 한 번 훑기
-
-### On Complete
-1. `actions/hypothesis/<id>/` 산출물 경로 확정
-2. partial update: `coo_developer.last_spike_path`, `agent_status = "completed"`
-3. `next_agent = "documentationer"` (Planner 의 hypothesis 흐름이 활성화된 경우)