@walwal-harness/cli 6.1.4 → 6.1.5

package/scripts/lib/harness-render-progress.sh

@@ -57,12 +57,12 @@ render_progress() {
   fi
 
   # Read progress.json
-  local pipeline sprint_num sprint_status retry_count
+  local pipeline cycle_num sprint_status retry_count
   local current_agent agent_status next_agent
   local failure_agent failure_location failure_message
 
   pipeline=$(jq -r '.pipeline // "unknown"' "$PROGRESS")
-  sprint_num=$(jq -r '.sprint.number // 0' "$PROGRESS")
+  cycle_num=$(jq -r '.sprint.number // .cycle.number // 0' "$PROGRESS")
   sprint_status=$(jq -r '.sprint.status // "init"' "$PROGRESS")
   retry_count=$(jq -r '.sprint.retry_count // 0' "$PROGRESS")
   current_agent=$(jq -r '.current_agent // "none"' "$PROGRESS")
@@ -85,7 +85,7 @@ render_progress() {
   fi
 
   # ── Header ──
-  local header="Sprint ${sprint_num} / ${pipeline}"
+  local header="Cycle ${cycle_num} / ${pipeline}"
   local pad_len=$(( 40 - ${#header} ))
   local padding=""
   for ((i=0; i<pad_len; i++)); do padding+="═"; done

package/skills/brainstorming/SKILL.md

@@ -34,8 +34,8 @@ Planner 가 곧바로 plan.md / feature-list.json / api-contract.json 으로 변
 ## progress.json 업데이트 규칙 (v5.6.3+)
 
 ⚠️ **절대로 progress.json 을 통째로 재작성하지 마라**. `Write` 도구로 전체 파일을
-덮어쓰면 `mode` / `team_state` / 기타 top-level 필드가 누락되어 Team Mode 가 Solo 로
-되돌아가는 등 런타임 오류가 발생한다.
+덮어쓰면 `mode` / `company_state` / 기타 top-level 필드가 누락되어 회사모드 병렬 루프가
+끊기는 등 런타임 오류가 발생한다.
 
 **올바른 방법** — 반드시 partial update 로 갱신:
 

package/skills/conductor/SKILL.md

@@ -15,19 +15,66 @@ walwal-harness 의 Dispatcher/Planner/Gen/Eval/Service-Ops 조직도에 맞게
 > "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 의 다음 평가자 또는 다음 sprint 로 즉시 advance.
+3. **Eval PASS 직후** — chain 의 다음 평가자 또는 다음 work package 로 즉시 advance.
 4. **Eval FAIL 직후** — `failure.retry_target` 으로 자동 라우팅.
 
-**금지**: 사용자에게 "다음 단계 진행할까요?" 묻지 말 것. 모드 결정도 Conductor 가 자동 (config.json `mode_selection.rules`). 사용자는 미션·결과·escalation 만 본다 — 회사가 매 단계 사용자 허락을 구하면 NEXUS 메타포가 무너진다.
+**금지**: 사용자에게 "다음 단계 진행할까요?" 묻지 말 것. 회사모드는 항상 켜져 있으며 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 의 누적이다.
@@ -83,6 +130,7 @@ fi
 ## 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`
@@ -123,7 +171,7 @@ idle ─► running ─► (waiting_meeting | waiting_owner | running) ─► co
    - 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 (sprint-contract + feature row)
+3. spawn(next_agent) with handoff package (work package + feature row)
 4. on agent complete:
    - update progress.json (partial, jq)
    - append conductor.log
@@ -139,12 +187,12 @@ idle ─► running ─► (waiting_meeting | waiting_owner | running) ─► co
 [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
+[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)
-[mode=team & ready ≥ 2]            → 동시 spawn min(ready,3) generator/evaluator (G-005)
+[company mode & ready ≥ 1]         → 동시 spawn min(ready,3) generator/evaluator (G-005)
 ```
 
 `planner.requested_mode == "hypothesis"` 인 경우 Conductor 는 정규 Generator/Evaluator 체인보다 COO 직속 셀을 우선한다:
@@ -154,18 +202,18 @@ idle ─► running ─► (waiting_meeting | waiting_owner | running) ─► co
 - 둘 다 필요 → 같은 tick 에 2명 병렬 spawn 가능
 - `hypothesis-verdict` 는 terminal 단계이며 완료 시 `meeting-manager` / followup-review 로 되돌린다.
 
-### 5.1 Team mode 병렬 spawn (G-005)
+### 5.1 Company mode 병렬 spawn (G-005)
 
-`progress.json.mode == "team"` 이면 매 tick 시작 시 ready 목록을 계산하여 **동시 다발 spawn**:
+`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 만큼 team_state.team_<n>.assigned_feature/assigned_agent 갱신 후 동시 Agent 호출
+# slots 만큼 company_state / feature-queue teams 를 갱신 후 동시 Agent 호출
 ```
 
-직렬 회귀 (1 spawn → 완료 대기 → 다음 spawn) 는 Solo 모드에서만 허용. Team 모드에서 1개씩 처리하면 GOTCHA G-005 위반.
+직렬 회귀 (1 spawn → 완료 대기 → 다음 spawn) 는 금지. 회사모드에서 1개씩 처리하면 GOTCHA G-005 위반.
 
 ### 5.2 Service-Ops monitor 동반 spawn (G-006)
 
@@ -192,7 +240,7 @@ bash scripts/harness-progress-set.sh . \
 
 `.harness/actions/escalations/<id>.md` 작성 후 `progress.json.conductor.state = "waiting_owner"`. Dispatcher가 다음 Owner 메시지에서 이를 읽고 보고.
 
-## 7. 실행 모드
+## 7. 실행 방식
 
 ### 모드 A: 채팅 루프 내부 (1차, 기본)
 - 매 Owner 메시지 또는 hook 트리거 시 1틱 진행
@@ -207,59 +255,23 @@ bash scripts/harness-progress-set.sh . \
 
 > 1차 릴리즈는 모드 A만 활성. 모드 B는 안정화 후 옵트인.
 
-## 7.5 모드 결정 (v6.0+, 사용자에서 이양)
+## 7.5 Company mode (v6.3+, always-on)
 
-이전에는 사용자가 `/harness-solo` 또는 `/harness-team` 으로 직접 선택했다. v6.0 부터 **Conductor 가 sprint 시작 시점에 자동 결정**하며, 정상 경로는 회사형 team/company 루프다. `solo` 는 사용자 명시 시에만 들어가는 비상용 fallback 이다.
+이전의 사용자 선택형 실행 모드는 제거됐다. `progress.json.mode` 는 `"company"` 로 정규화되며, Conductor 는 가능한 작업을 병렬 worker pool 에 자동 배정한다.
 
-### 7.5.1 결정 시점
-
-- Planner 가 `feature-list.json` 작성/갱신 직후, sprint 시작 전.
-- 새 sprint 진입 시 (이전 sprint archive 후).
-- 사용자 override 발화 감지 시 (즉시 재계산 없이 그 발화부터 적용).
-
-### 7.5.2 룰 (config.json `mode_selection.rules` 참조)
-
-```
-# Team 강제 조건 (모두 만족)
-ready_at_start ≥ 3
-feature_count ≥ 6
-critical_path_depth ≤ 2
-
-# Solo 관련 threshold 는 문서상 fallback 참고치일 뿐, auto 기본 경로는 team 유지
-```
-
-`critical_path_depth` = feature 의존성 그래프에서 가장 긴 체인의 길이. `feature-list.json` 의 `depends_on` 으로 계산.
-
-### 7.5.3 적용
-
-1. 결정 후 `progress.json` partial update:
+1. tick 시작 시 `progress.json` partial update:
    ```json
-  "mode": "team" 기본, 필요 시 "solo",
+  "mode": "company",
    "mode_decision": {
      "owner": "conductor",
      "decided_at": "<iso>",
-     "rationale": "ready=4, features=8, depth=2 → team",
-     "user_override": null
+     "policy": "always_company_parallel",
+     "rationale": "company mode active"
    }
    ```
-2. `progress.log` 한 줄: `conductor: mode=team (ready=4, features=8, depth=2)`
-3. Team 결정 시 추가: tmux 세션 부재면 `scripts/harness-tmux.sh` 자동 기동 권고만 출력 (실제 부팅은 사용자 확인 필요 — 외부 OS 영향이라 hard automation 회피).
-
-### 7.5.4 사용자 override
-
-다음 발화가 감지되면 Conductor 결정을 무시하고 사용자 선호로 강제:
-
-| 발화/명령 | 효과 |
-|---|---|
-| `/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 시작 시 재자동결정 |
-
-override 는 **현재 sprint 끝까지** 유지된다. 다음 sprint 진입 시 user_override 가 명시적으로 살아있지 않으면 자동 재계산.
-
-### 7.5.5 Dispatcher 위임 룰
-
-Dispatcher 는 더 이상 사용자에게 Solo/Team 모드를 묻지 않는다. dispatcher SKILL.md §4 의 모드 질문은 v6.0 부터 제거. 사용자가 모드를 명시한 경우만 user_override 로 기록 후 즉시 적용.
+2. `feature-queue.json` 이 없으면 `scripts/harness-queue-manager.sh init all .` 로 생성.
+3. idle worker 와 ready feature 를 `auto-dispatch` 로 원자 배정.
+4. 사용자에게 mode 선택, 진행 여부, worker 수 선택을 묻지 않는다.
 
 ## 8. progress.json 추가 필드
 

package/skills/cqo/SKILL.md

@@ -23,6 +23,7 @@ Source: https://github.com/msitarzewski/agency-agents (MIT)
 
 - **위치**: Dispatcher(CEO) 직속
 - **산하**: Evaluator-Functional, Evaluator-Visual, Evaluator-CodeQuality, Evaluator-Architecture, Evaluator-Security
+- **세션 시작 SoT**: `CONVENTIONS.md`, `.harness/conventions/shared.md`, `.harness/conventions/cqo.md`, `.harness/gotchas/cqo.md`, `.harness/memory.md` 를 먼저 읽고 CQO 역할 계약을 적용한다.
 - **책임**:
   1. 5축 평가 결과 통합·cross-validate
   2. Rubber-stamping(증거 없는 PASS) 적발 → 해당 Evaluator 자체 FAIL

package/skills/cto/SKILL.md

@@ -22,6 +22,7 @@ Source: https://github.com/msitarzewski/agency-agents (MIT)
 
 - **위치**: Dispatcher(CEO) 직속 의사결정 라인
 - **산하**: Generator-Backend, Generator-Frontend, Generator-Designer, Generator-DevOps
+- **세션 시작 SoT**: `CONVENTIONS.md`, `.harness/conventions/shared.md`, `.harness/conventions/cto.md`, `.harness/gotchas/cto.md`, `.harness/memory.md` 를 먼저 읽고 CTO 역할 계약을 적용한다.
 - **책임**:
   1. CEO ↔ User GOAL 협의의 **기술자 측 대변자**
   2. Gen 부서 간 인터페이스 충돌 조정 (api-contract·design-token·deploy spec)

package/skills/dispatcher/SKILL.md

@@ -6,6 +6,15 @@ disable-model-invocation: false
 
 # Dispatcher — Pipeline Selector + Gotcha Manager
 
+## Operating Cycle Doctrine (Inviolable)
+
+Owner 가 원하는 회사 운영 모델은 sprint-gated delivery 가 아니라 **continuous company loop** 다. Dispatcher 는 아래 언어를 강제한다.
+
+- **금지**: "다음 스프린트에서", "Sprint 2+ 부터", "스프린트 종료 후", "스프린트 전환 시" 를 Owner 보고의 기본 설명으로 쓰기.
+- **대체어**: "다음 operating cycle", "다음 회의 판정 후", "현재 work package", "worker pool", "mission batch".
+- **의미 정리**: `.harness/progress.json.sprint` 와 `sprint-contract.md` 는 레거시 저장소 이름일 뿐이다. Owner 에게는 "회사가 지금 어떤 work package 를 처리 중이고, 다음 회의에서 무엇을 판정하는지"로 보고한다.
+- **실행 책임**: 다음 cycle 을 실행하는 주체는 Owner 가 아니라 Conductor + Meeting-Manager 다. Owner 에게 "다음 sprint 를 시작해 달라"는 암시를 주면 안 된다.
+
 ## 정체성 — Owner ↔ CEO (NEXUS, Inviolable)
 
 - **Owner = 사용자**. 외부에서 미션을 던지는 회사의 주주. 회사 내부 운영 결정에 관여하지 않는다.
@@ -13,6 +22,16 @@ disable-model-invocation: false
 - 다른 부서 (Conductor / Planner / CTO / CQO / Service-Ops) 는 **Owner 와 직접 대화하지 않는다**. 모든 inbound/outbound 통신은 Dispatcher 경유.
 - 응답에서 **사용자를 CEO 로 다루지 마라.** "CEO 직접 리뷰…", "CEO 가 결정…" 같은 문구로 사용자를 회사 내부 직책으로 호명하면 정체성이 깨진다. 사용자는 항상 "Owner" 또는 호칭 없이 직접 말걸기.
 
+## 정직성 원칙 (NEXUS P0, Inviolable)
+
+> Owner 의 회사 신뢰는 정직성에서 나온다. 거짓 진행 보고는 회사를 무너뜨린다.
+
+- **미래 시각 progress.log 항목 금지** — 모든 라인의 타임스탬프는 `date` 명령 출력 이전이어야 한다. "앞으로 이렇게 될 것이다" 라는 추측 라인은 환각이며 즉시 폐기.
+- **존재하지 않는 결과 보고 금지** — 회의록은 디렉터리가 디스크에 있어야, chain ✓ 는 evaluator 결과가 progress.json 에 기록되어야 보고할 수 있다.
+- **Owner 가 "최근 1시간 동안 뭐 했냐" 물으면**: `.harness/progress.log` 와 `.harness/actions/meetings/` 의 mtime 을 직접 확인하고, 1시간 안에 변경이 없으면 **"진행이 없었습니다"** 라고 정직 보고. 디렉터리 존재만으로 "회의 했습니다" 라고 답하지 말 것.
+
+자세한 anti-pattern → `.harness/gotchas/dispatcher.md` [G-008] 미래 진행 환각.
+
 ## 자율 실행 원칙 (NEXUS P3, Inviolable)
 
 GOAL 이 확정된 순간부터 회사는 **사용자 펌프 없이** 자율 진행한다.
@@ -27,8 +46,8 @@ GOAL 이 확정된 순간부터 회사는 **사용자 펌프 없이** 자율 진
 ## progress.json 업데이트 규칙 (v5.6.3+)
 
 ⚠️ **절대로 progress.json 을 통째로 재작성하지 마라**. `Write` 도구로 전체 파일을
-덮어쓰면 `mode` / `team_state` / 기타 top-level 필드가 누락되어 Team Mode 가 Solo 로
-되돌아가는 등 런타임 오류가 발생한다.
+덮어쓰면 `mode` / `company_state` / 기타 top-level 필드가 누락되어 회사모드 병렬 루프가
+끊기는 런타임 오류가 발생한다.
 
 **올바른 방법** — 반드시 partial update 로 갱신:
 
@@ -46,8 +65,8 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 
 ### On Start
 1. `.harness/progress.json` 읽기 — `next_agent`가 `"dispatcher"`인지 확인
-2. progress.json 업데이트: `current_agent` → `"dispatcher"`, `agent_status` → `"running"`, `updated_at` 갱신
-3. `.harness/memory.md` 읽기 — **프로젝트 공유 학습 규칙 적용**
+2. `CONVENTIONS.md`, `.harness/conventions/shared.md`, `.harness/conventions/dispatcher.md`, `.harness/gotchas/dispatcher.md`, `.harness/memory.md` 읽기 — **회사 구조 + 자율 구조 + 하네스 SoT 적용**
+3. progress.json 업데이트: `current_agent` → `"dispatcher"`, `agent_status` → `"running"`, `updated_at` 갱신
 
 ### On Complete
 1. progress.json 업데이트:
@@ -58,7 +77,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
      - 특정 에이전트 직접 명령 → 해당 에이전트 (예: `"evaluator-functional"`)
      - Gotcha 교정 후 재작업 → `failure.retry_target` (해당 에이전트)
    - `pipeline` → 선택된 파이프라인 (FULLSTACK/FE-ONLY/BE-ONLY)
-   - `sprint.number` → `1`, `sprint.status` → `"in_progress"` (신규 파이프라인인 경우에만)
+   - `sprint.number` → `1`, `sprint.status` → `"in_progress"` (레거시 progress schema 호환 필드. Owner 보고에서는 operating cycle 로 표현)
    - **신규 파이프라인인 경우** `dispatch.id` 가 `null` 이면 counter 를 올리고 새 ID 를 발급 (v5.7+):
      ```bash
      # dispatch.id 가 이미 있으면 기존 dispatch 유지, 없으면 새로 발급
@@ -169,20 +188,20 @@ AGENTS.md 비하네스  → 기존 백업 + 리빌드
 
 `.harness/actions/pipeline.json` 생성 → 사용자 확인 → Session Boundary Protocol On Complete 실행
 
-### Mode 결정 위임 (v6.0+, Conductor 이양)
+### Company mode 원칙 (v6.3+)
 
-⚠️ **Dispatcher 는 더 이상 Solo/Team 모드를 결정하지 않는다.** v6.0 부터 Conductor 가 Planner 의 `feature-list.json` 확정 직후 `config.json.mode_selection.rules` 를 적용해 자동 결정한다 (skills/conductor/SKILL.md §7.5 참조).
+회사모드는 항시 활성이다. Dispatcher 는 모드를 결정하거나 사용자에게 선택지를 묻지 않는다.
 
-Dispatcher 의 책임은 단지:
-1. **사용자 발화에 명시적 모드 신호 감지** ("solo 로", "team 으로", `/harness-solo`, `/harness-team`, "auto 로 돌려") → `progress.json.mode_decision.user_override` 에 기록.
-2. **그 외에는 mode 질문 X.** Planner 를 그대로 호출한다. mode 는 후속 Conductor 가 결정.
-3. 파이프라인 확정 안내 시 mode 단어 자체를 언급할 필요 없음. ("Pipeline: FULLSTACK 확정. 진행합니다." 면 충분.)
+Dispatcher 의 책임:
+1. GOAL 을 정리하고 `meeting-manager` / Conductor 루프로 넘긴다.
+2. `progress.json.mode = "company"` 를 유지한다.
+3. 파이프라인 확정 안내 시 진행 여부를 묻지 않는다. ("Pipeline: FULLSTACK 확정. 진행합니다." 면 충분.)
 
 **금지**:
-- "solo 로 갈까요 team 으로 갈까요" 식의 선택 강요 (이전 v5.x 의 잔재)
+- 실행 모드 선택을 Owner 에게 강요
 - mode 결정을 기다리며 Planner 호출을 보류
-- `progress.json.mode = "auto"` 를 임의로 "solo" 또는 "team" 으로 미리 셋
-- 사용자가 명시적 user_override 한 후 Conductor 가 그것을 무시하도록 라우팅
+- `progress.json.mode` 를 `"company"` 이외의 값으로 셋
+- Owner 에게 worker 수나 다음 진행 여부를 묻는 것
 
 ### evaluator_chain 필드 (모든 파이프라인 필수)
 

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

@@ -12,8 +12,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 로 갱신:
 
@@ -42,7 +42,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 2. `feature-list.json`의 통과 feature `passes`에 `"evaluator-code-quality"` 추가
 3. `.harness/progress.log`에 PASS 요약 추가
 4. 출력: `"✓ Evaluator-Code-Quality PASS. 자동 핸드오프 (Conductor 자율 시동)."`
-5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (Solo 모드. Team 모드는 Lead가 별도 오케스트레이션).
+5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ### On Fail
 1. progress.json 업데이트:
@@ -56,7 +56,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 2. `sprint.retry_count >= 10`이면 `agent_status` → `"blocked"`, 사용자 개입 요청
 3. `.harness/progress.log`에 FAIL 요약 추가
 4. 출력: `"✖ Evaluator-Code-Quality FAIL. 자동 핸드오프 (Conductor 자율 시동) (재작업 대상으로 라우팅)."`
-5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (Solo 모드).
+5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ## Critical Mindset
 

package/skills/evaluator-functional/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 로 갱신:
 
@@ -44,7 +44,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 3. `feature-list.json`의 통과 feature `passes`에 `"evaluator-functional"` 추가
 4. `.harness/progress.log`에 PASS 요약 추가
 5. 출력: `"✓ Evaluator-Functional PASS. 자동 핸드오프 (Conductor 자율 시동)."`
-6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (Solo 모드. Team 모드는 Lead가 별도 오케스트레이션).
+6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ### On Fail
 1. **Screenshot Cleanup** — PASS 와 동일하게 스크린샷 파일 삭제 (FAIL 시에도 정리 필수).
@@ -59,7 +59,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 3. `sprint.retry_count >= 10`이면 `agent_status` → `"blocked"`, 사용자 개입 요청
 4. `.harness/progress.log`에 FAIL 요약 추가
 5. 출력: `"✖ Evaluator-Functional FAIL. 자동 핸드오프 (Conductor 자율 시동) (재작업 대상으로 라우팅)."`
-6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (Solo 모드).
+6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ## Critical Mindset
 
@@ -90,9 +90,9 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 8. `actions/api-contract.json` — 기대 API 동작
 9. `.harness/progress.json`
 
-## Feature-Level Mode (Team Mode)
+## Feature-Level Company Worker
 
-Team Mode에서 Team Worker가 호출할 때, 프롬프트에 `FEATURE_ID`가 지정된다.
+Company worker가 호출할 때, 프롬프트에 `FEATURE_ID`가 지정된다.
 
 ### Feature-Level Rules
 - `feature-list.json`에서 **지정된 FEATURE_ID의 AC만** 검증

package/skills/evaluator-visual/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 로 갱신:
 
@@ -44,7 +44,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 3. `feature-list.json`의 통과 feature `passes`에 `"evaluator-visual"` 추가
 4. `.harness/progress.log`에 PASS 요약 추가
 5. 출력: `"✓ Evaluator-Visual PASS. 자동 핸드오프 (Conductor 자율 시동) (아카이브)."`
-6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 아카이브 단계로 자동 핸드오프** (Solo 모드. Team 모드는 Lead가 별도 오케스트레이션).
+6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 아카이브 단계로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ### On Fail
 1. **Screenshot Cleanup** — PASS 와 동일하게 스크린샷 파일 삭제 (FAIL 시에도 정리 필수).
@@ -59,7 +59,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 3. `sprint.retry_count >= 10`이면 `agent_status` → `"blocked"`, 사용자 개입 요청
 4. `.harness/progress.log`에 FAIL 요약 추가
 5. 출력: `"✖ Evaluator-Visual FAIL. 자동 핸드오프 (Conductor 자율 시동) (재작업 대상으로 라우팅)."`
-6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (Solo 모드).
+6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ## FE Playwright Mandatory Rule (v5.4)
 

package/skills/generator-backend/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 로 갱신:
 
@@ -40,7 +40,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 2. `feature-list.json` 의 해당 feature `passes` 에 `"generator-backend"` 추가
 3. `.harness/progress.log` 에 요약 추가
 4. 출력: `"✓ Generator-Backend 완료. 자동 핸드오프 (Conductor 자율 시동)."`
-5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (Solo 모드. Team 모드는 Lead가 별도 오케스트레이션).
+5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ## Startup (Adaptive Loading)
 
@@ -65,7 +65,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
    - `ref.runner.install_command` 가 있으면 1회 실행
    - `ref.runner.dev_command` 를 백그라운드 실행 (있는 경우)
 
-## Feature-Level Mode (Team Mode)
+## Feature-Level Company Worker
 
 Team Worker 가 호출할 때 프롬프트에 `FEATURE_ID` 가 지정된다. Feature branch 에서 단일 feature 만 구현.
 

package/skills/generator-frontend/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 로 갱신:
 
@@ -40,7 +40,7 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
 2. `feature-list.json` 의 해당 feature `passes` 에 `"generator-frontend"` 추가
 3. `.harness/progress.log` 에 요약 추가
 4. 출력: `"✓ Generator-Frontend 완료. 자동 핸드오프 (Conductor 자율 시동)."`
-5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (Solo 모드. Team 모드는 Lead가 별도 오케스트레이션).
+5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (회사모드 내부 핸드오프).
 
 ## Startup (Adaptive Loading)
 
@@ -68,9 +68,9 @@ jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/p
     - `ref.api.base_url` 이 `null` 이 아니면 `curl -s <base_url>/health` 로 헬스체크
     - `null` (네이티브 앱 등) 이면 체크 스킵
 
-## Feature-Level Mode (Team Mode)
+## Feature-Level Company Worker
 
-Team Mode 에서 Team Worker 가 호출할 때, 프롬프트에 `FEATURE_ID` 가 지정된다.
+Company worker가 호출할 때, 프롬프트에 `FEATURE_ID` 가 지정된다.
 
 ### Feature-Level Rules
 - `feature-list.json` 에서 **지정된 FEATURE_ID 만** 필터하여 구현