@walwal-harness/cli 6.1.2 → 6.1.4

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

@@ -0,0 +1,58 @@
+#!/bin/bash
+# harness-progress-migrate.sh — Idempotent progress.json normalizer.
+#
+# 목적: 새 스키마 필드를 누락하지 않도록 SessionStart 마다 안전하게 채운다.
+# 항상 jq 의 alternative operator(`//`) 또는 `if has` 패턴으로 작성하여
+# 기존 값을 절대 덮어쓰지 않는다.
+#
+# Usage (sourced):
+#   source "$SCRIPT_DIR/lib/harness-progress-migrate.sh"
+#   migrate_progress_schema "$PROGRESS"
+#
+# Usage (standalone):
+#   bash scripts/lib/harness-progress-migrate.sh /path/to/.harness/progress.json
+
+migrate_progress_schema() {
+  local progress="$1"
+  [ -f "$progress" ] || return 0
+  command -v jq >/dev/null 2>&1 || return 0
+
+  # v6.2 — Parallel tracks (fork-join) fields. tracks.length >= 2 → fork.
+  # Note: there is intentionally NO `meetings.decision.mode` field — single/parallel is derived
+  # from tracks.length. Runtime progress.mode is preserved because it still governs solo/team/paused.
+  local filter='
+    .conductor.tracks           = (.conductor.tracks // [])
+    | .conductor.rendezvous       = (.conductor.rendezvous // null)
+    | .conductor.fork_meeting_id  = (.conductor.fork_meeting_id // null)
+
+    | .meetings                   = (.meetings // {})
+    | .meetings.requested_tracks  = (.meetings.requested_tracks // [])
+    | .meetings.requested_rendezvous = (.meetings.requested_rendezvous // null)
+    | .meetings.fork_meeting_id   = (.meetings.fork_meeting_id // null)
+
+    | .meetings.decision          = (.meetings.decision // {})
+    | .meetings.decision.tracks   = (.meetings.decision.tracks // [])
+    | .meetings.decision.rendezvous = (.meetings.decision.rendezvous // null)
+    | del(.meetings.decision.mode)
+    | del(.meetings.requested_mode)
+  '
+
+  local tmp
+  tmp="$(mktemp)" || return 1
+  if jq "$filter" "$progress" > "$tmp" 2>/dev/null; then
+    mv "$tmp" "$progress"
+  else
+    rm -f "$tmp"
+    return 1
+  fi
+}
+
+# Standalone invocation
+if [ "${BASH_SOURCE[0]}" = "$0" ]; then
+  target="${1:-}"
+  if [ -z "$target" ]; then
+    echo "usage: $0 <path/to/.harness/progress.json>" >&2
+    exit 2
+  fi
+  migrate_progress_schema "$target"
+fi

package/skills/conductor/SKILL.md

@@ -152,6 +152,7 @@ idle ─► running ─► (waiting_meeting | waiting_owner | running) ─► co
 - 리서치·정리 중심 → `documentationer`
 - 빠른 실험·백데이터 코드 중심 → `coo-developer`
 - 둘 다 필요 → 같은 tick 에 2명 병렬 spawn 가능
+- `hypothesis-verdict` 는 terminal 단계이며 완료 시 `meeting-manager` / followup-review 로 되돌린다.
 
 ### 5.1 Team mode 병렬 spawn (G-005)
 

package/skills/coo-developer/SKILL.md

@@ -21,12 +21,20 @@ disable-model-invocation: false
 - Planner의 `requested_mode = "hypothesis"`
 - 기존 코드베이스, 로컬 데이터, 백데이터, 샘플 CSV/JSON/DB dump
 
-## 3. 출력
+## 3. 출력 (산출물 경로 표준)
 
-- 실험 코드 또는 스크립트
-- 재현 절차
-- 관찰 결과와 한계
-- "가설 지지 / 반박 / 추가 데이터 필요" 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. 작업 원칙
 
@@ -40,3 +48,25 @@ disable-model-invocation: false
 - 실험 결과만으로 운영 가능 판정
 - 정규 팀 평가 없이 배포 코드로 승격
 - 근거 없는 직감성 결론
+
+## 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 흐름이 활성화된 경우)

package/skills/documentationer/SKILL.md

@@ -22,25 +22,71 @@ disable-model-invocation: false
 - `coo-developer`의 실험 결과
 - 필요 시 외부 리서치 소스
 
-## 3. 출력
+## 3. 출력 (산출물 경로 표준)
 
-- `hypothesis-brief`
-- `validation-report`
-- `evidence-summary`
-- 다음 액션 제안:
-  - 정규 Sprint로 승격
-  - 추가 실험 필요
-  - 폐기
+- `.harness/actions/hypothesis/<id>/brief.md` — `hypothesis-brief` (사전 리서치)
+- `.harness/actions/hypothesis/<id>/report.md` — `validation-report` (실험 후 통합)
+- `.harness/actions/hypothesis/<id>/evidence/` — 출처 스냅샷·캡처
+- `.harness/actions/hypothesis/<id>/verdict.json` — 기계 판독 판정
+
+`verdict.json` 스키마 (필수 필드):
+
+```json
+{
+  "id": "H-...",
+  "hypothesis": "한 줄 가설",
+  "verdict": "supported | refuted | inconclusive",
+  "confidence": 0.0,
+  "key_evidence": [
+    {"source": "actions/hypothesis/<id>/spike/run.log", "kind": "experiment"},
+    {"source": "https://...", "kind": "external-research"}
+  ],
+  "next_action": "promote-to-sprint | additional-experiment | discard",
+  "rationale": "왜 이 판정인가 — evidence 와 직접 연결",
+  "open_questions": ["..."],
+  "limitations": ["..."]
+}
+```
+
+`progress.json` 업데이트 (완료 시):
+
+```bash
+bash scripts/harness-progress-set.sh . \
+  '.documentationer.last_report = "actions/hypothesis/<id>/report.md" |
+   .documentationer.last_verdict = "actions/hypothesis/<id>/verdict.json"'
+```
 
 ## 4. 보고서 규칙
 
 - 결론 먼저, 근거 다음
-- 주장마다 evidence 출처 명시
+- 주장마다 evidence 출처 명시 (URI 또는 artifact path)
 - 운영팀/CTO/CQO가 바로 이어받을 수 있게 열린 질문을 분리
 - "왜 아직 확실하지 않은가"도 반드시 적을 것
+- `verdict` 는 supported / refuted / inconclusive 셋 중 하나로만 — 모호한 표현 금지
 
 ## 5. 금지
 
 - evidence 없는 유효 판정
 - CTO/CQO 검증을 대신했다고 표현
 - 실험 로그를 정제 없이 그대로 보고서로 제출
+
+## 6. Parallel-Tracks 컨텍스트 (v6.2)
+
+`validation-report` 는 followup-review 회의에서 **track deliverable** 로 사용된다.
+
+- followup-review 의 Meeting-Manager 는 `prior_tracks[].deliverable_path` 를 통해 이 보고서를 읽는다.
+- `verdict.json` 의 `next_action` 이 `promote-to-sprint` 면 followup 결정은 보통 `apply-now`, `additional-experiment` 면 `more-validation`, `discard` 면 `backlog` 또는 종결.
+- 형제 트랙 (예: `track-1: cto/bugfix`) 의 결과는 별도 deliverable. 둘을 함께 보고 결정자(CTO 또는 CEO) 가 통합한다 — Documentationer 가 직접 통합 결정을 내리지 않는다.
+
+## 7. Session Boundary
+
+### On Start
+1. `.harness/progress.json` 읽기 — `planner.last_brief` 확인 (`hypothesis:research` 또는 `hypothesis:report`)
+2. brief=research 면 `brief.md` 작성, brief=report 면 `coo-developer` 의 spike 결과를 `report.md` 로 통합
+3. `.harness/conventions/documentationer.md`, `.harness/gotchas/documentationer.md` 읽기
+4. (v6.2) parallel 모드면 형제 트랙 owner 의 gotcha 도 한 번 훑기
+
+### On Complete
+1. `report.md` + `verdict.json` 작성 완료
+2. partial update: `documentationer.last_report`, `documentationer.last_verdict`, `agent_status = "completed"`
+3. `next_agent = "planner"` (hypothesis-verdict 종합)

package/skills/meeting-manager/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: harness-meeting-manager
-description: "부서 간 동기화 엔진. Cron(Service-Ops)·Event(부서 발신)·Manual 트리거로 5종 회의(Standup/Sprint Review/Spec Review/Incident War Room/All-Hands)를 소집·집계·디스패치. 적응형 cadence(light 30m / normal 1h / heavy 4h). 트리거: '미팅 소집', 'meeting convene', 'standup'."
+description: "부서 간 동기화 엔진. Cron(Service-Ops)·Event(부서 발신)·Manual 트리거로 6종 회의(Standup/Sprint Review/Spec Review/Incident War Room/All-Hands/Followup Review)를 소집·집계·디스패치. parallel tracks fork-join 지원. 적응형 cadence(light 30m / normal 1h / heavy 4h). 트리거: '미팅 소집', 'meeting convene', 'standup', 'followup'."
 disable-model-invocation: false
 ---
 
@@ -23,7 +23,7 @@ walwal-harness 의 부서 구조에 맞게 재해석함.
 - **권한**: 모든 부서에 prep 양식 발신, 회의록 작성·집계, queue enqueue (v5.9.6 재사용)
 - **금지**: 의사결정 직접 수행 (사회만 봄), Owner와 직접 대화 (escalation은 Dispatcher 경유)
 
-## 2. 회의 5종
+## 2. 회의 6종 (v6.2 — Followup Review 추가)
 
 | 종류 | 트리거 | 참석자 | 결과물 | Owner 푸시? |
 |---|---|---|---|---|
@@ -32,6 +32,7 @@ walwal-harness 의 부서 구조에 맞게 재해석함.
 | **Spec Review** | Eval "Change Request" 발신 | COO·CTO·발신 Eval | feature-list 수정·api-contract 변경 | 변경 시 ✅ |
 | **Incident War Room** | Service-Ops red-alert | CEO·CTO·Incident-Responder·관련 Gen | 핫픽스·롤백·RCA 초안 | ✅ 즉시 |
 | **All-Hands (Phase Gate)** | Phase 0~6 전환 이벤트 | 전 부서 + CEO·COO | Phase 진입 승인·부서 편성 변경 | ✅ 요약본 |
+| **Followup Review** *(v6.2)* | parallel tracks 의 모든 deliverable 도착 또는 `rendezvous.when` 도달 | fork meeting 의 트랙 owner 들 + 결정자(CTO 또는 CEO) | 트랙 산출물 통합 결정 (즉시 적용 / 백로그 / 추가 검증) | 변경 시 ✅ |
 
 ## 3. 회의 라이프사이클 (5단계)
 
@@ -99,12 +100,27 @@ meeting:
       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
+    action_type: goal-alignment | replan | implement | re-evaluate | monitor | escalate-owner | hypothesis-validation | bugfix
     rationale: <fact-based why this owner must act next>
     evidence:
       - source: <artifact path>
-        kind: ops-report | cqo-audit | cto-review | meeting-prep
+        kind: ops-report | cqo-audit | cto-review | meeting-prep | track-deliverable
     drift_classification: implementation_drift | planning_drift | ops_drift | goal_drift
+    # v6.2 — Parallel tracks (fork-join). tracks.length >= 2 이면 fork, 없거나 1이면 single.
+    # 별도의 mode 플래그는 두지 않음 — 단일 진실은 tracks 자체.
+    tracks:
+      - id: track-1
+        owner: cto
+        action_type: bugfix
+        deliverable: hotfix-result | validation-report | spike-result | report
+        deliverable_path: <artifact path or null>
+        status: pending | running | completed | abandoned
+    rendezvous:               # tracks.length >= 2 일 때만 의미 있음
+      type: followup-review | sprint-review
+      when: next_cadence | <iso>
+    # Followup Review 전용 필드
+    fork_meeting_id: <원본 fork 회의 id, 있으면>
+    prior_tracks: [<완료된 tracks[] 스냅샷>]
   action_items:
     - id: AI-1
       owner: generator-backend
@@ -140,12 +156,104 @@ meeting:
     "rationale": "...",
     "evidence": [],
     "drift_classification": "planning_drift",
+    "tracks": [],
+    "rendezvous": null,
     "source_path": ".harness/actions/meetings/M-.../meeting-M-....md"
   },
+  "requested_tracks": [],
+  "requested_rendezvous": null,
+  "fork_meeting_id": null,
   "manual_override": null
 }
 ```
 
+> tracks.length ≥ 2 면 fork-join, 그 외(0 또는 1)는 single. 별도 mode 플래그는 없음.
+
+`progress.json.conductor` 에는 활성 fork 의 트랙 상태가 거울처럼 미러링 된다:
+
+```json
+"conductor": {
+  "tracks": [
+    { "id": "track-1", "owner": "cto", "action_type": "bugfix",
+      "deliverable": "hotfix-result", "deliverable_path": null,
+      "status": "running", "started_at": "<iso>" }
+  ],
+  "rendezvous": { "type": "followup-review", "when": "next_cadence" },
+  "fork_meeting_id": "M-..."
+}
+```
+
+## 7.05 Parallel Tracks (v6.2 — Fork-Join)
+
+회의 결론이 한 개의 owner 로 모이지 않고 둘 이상의 부서가 **독립 산출물**을 만든 뒤 **다음 회의에서 합치는** 패턴을 지원한다.
+
+### 7.05.1 언제 parallel 을 선택하는가
+
+다음을 **모두** 충족할 때만 parallel 로 결정한다.
+
+1. 결론이 둘 이상의 deliverable 로 자연 분해된다 (예: "버그 핫픽스" + "가설 보고서").
+2. 두 deliverable 사이에 직접 의존이 없다 (한쪽이 다른 쪽 결과를 기다리지 않는다).
+3. 결정자(CTO 또는 CEO) 가 두 결과를 **함께 보고** 다음 단계를 정해야 한다.
+
+위 셋 중 하나라도 어긋나면 single 로 가고, 후속 작업은 별도 회의에서 다룬다.
+
+### 7.05.2 Fork 회의 결정 작성법
+
+회의록 `## Decision JSON` 블록에 다음을 작성한다:
+
+```json
+{
+  "decision": {
+    "owner": "cto",
+    "action_type": "bugfix",
+    "rationale": "운영 버그 + 신규 가설 두 트랙 동시 진행 — 다음 followup-review 에서 통합 결정",
+    "evidence": [...],
+    "drift_classification": "implementation_drift",
+    "tracks": [
+      { "id": "track-1", "owner": "cto", "action_type": "bugfix", "deliverable": "hotfix-result" },
+      { "id": "track-2", "owner": "planner", "action_type": "hypothesis-validation", "deliverable": "validation-report" }
+    ],
+    "rendezvous": { "type": "followup-review", "when": "next_cadence" }
+  }
+}
+```
+
+> `tracks` 가 2개 이상 → 자동으로 fork-join. 1개 이하 → single (rendezvous 무시). 별도 mode 플래그 없음.
+
+규칙:
+- `tracks[0].owner` 와 `tracks[0].action_type` 는 backward-compat 으로 `decision.owner` / `decision.action_type` 와 동일해야 한다 (Conductor 의 1차 dispatch 대상).
+- `id` 는 `track-1`, `track-2` 형식으로 1-based 순번. 두 개를 권장. 셋 이상은 fork 가 너무 무거워지므로 회의를 분리해라.
+- `deliverable` 은 짧은 슬러그(`hotfix-result`, `validation-report`, `spike-result`, `report`).
+- `rendezvous.when` 은 `next_cadence` (다음 정기 회의에 합류) 또는 ISO 시각 (특정 시점에 강제 소집).
+
+### 7.05.3 Conductor 가 하는 일 (참고)
+
+`scripts/conductor-tick.sh` 가 자동으로:
+1. fork 회의 직후 `progress.json.conductor.tracks` 에 트랙 상태 미러링.
+2. 첫 번째 트랙 owner 를 spawn (status=running). 그 owner 가 완료하면 트랙을 completed 처리하고 다음 pending 트랙 spawn.
+3. 모든 트랙이 completed 되면 `meetings.requested_type=<rendezvous.type>` + `meetings.requested_reason=rendezvous` 로 followup-review 를 자동 소집.
+4. fork 회의 id 는 `progress.json.meetings.fork_meeting_id` 로 followup 회의에 전달된다.
+
+Meeting-Manager 는 트랙 dispatch 자체에 관여하지 않는다. fork 회의록의 decision JSON 만 정확히 작성하면 된다.
+
+### 7.05.4 Followup Review 진행 방식
+
+소집 직후 `notice.md` 에는 fork 회의 id 와 트랙 deliverable 경로 목록이 자동 채워진다. Meeting-Manager 는 다음 순서로 진행:
+
+1. **트랙 산출물 수집**: `prior_tracks[]` 의 각 `deliverable_path` 를 읽어 prep 양식에 요약을 넣는다 (`prep-cto.md` 에 hotfix-result, `prep-planner.md` 에 validation-report). `fork_context` 가 비어 있어도 `conductor.tracks` 또는 `meetings.decision.tracks` 로 복구한다.
+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).
+   - `more-validation` — 추가 검증 필요. 다시 parallel fork 또는 단일 spec-review.
+4. 결정은 **single mode** 로 작성한다 (followup 자체에서 또 fork 하지 말 것 — 무한 fork 방지).
+
+### 7.05.5 안전 가드
+
+- **Followup 무한 fork 금지**: followup-review 의 결정 JSON 은 `tracks.length ≤ 1` 만 허용 (또는 tracks 자체를 비움). 추가 분할이 필요하면 별도 spec-review 로 회부.
+- **Track abandon**: 트랙이 24h 이상 stuck 또는 owner 가 escalation 발신 → 해당 트랙 `status: abandoned`, 나머지 진행 + followup 에서 사유 명시.
+- **Fork 폭주 방지**: 한 sprint 내 parallel fork 가 ≥ 3회 발생하면 다음 fork 는 single 로 강제 (회의 분해 시그널).
+
 ## 7.1 회의 진행 방식
 
 Meeting-Manager는 단순히 "토론해 주세요"라고 말하지 않는다. 각 참석자에게 역할별 prep를 요청한다.
@@ -180,6 +288,7 @@ Meeting-Manager 자체는 cron을 돌리지 않음. Service-Ops가 매 hourly
 | Planner | Phase 전환 요청 | All-Hands (Phase Gate) |
 | Owner | `/meeting convene <type>` | 해당 타입 (manual) |
 | Service-Ops | `goal_adherence < 0.5` 24h | Spec Review (긴급) |
+| Conductor | parallel tracks 모두 완료 또는 `rendezvous.when` 도달 | **Followup Review** *(v6.2)* |
 
 ## 10. Action Item 디스패치
 
@@ -218,6 +327,7 @@ bash scripts/queue-enqueue.sh   --owner generator-backend   --feature <feature-i
 5. 기본 handoff 규칙:
    - `goal-intake` / `goal-drift` / `spec-review` / `incident-followup` → `planner(COO)`
    - `ops-batch` / `sprint-review` / `quality-fail` → `cto`
+   - `rendezvous` (followup-review 결정 시) → 결정자 = `cto` 기본, 단 fork 회의가 `goal-intake|goal-drift` 였으면 `dispatcher` 로 escalate
 
 ### On Archived
 1. `.harness/archive/meetings/<id>/` 로 이동

package/skills/planner/SKILL.md

@@ -67,13 +67,58 @@ Planner는 더 이상 초기 파이프라인의 단순 1회성 spec writer가
 
 - **COO 역할**: Goal 정렬, 설계 허점 탐지, 브레인스토밍 필요 여부 판단
 - **HR 역할**: 필요한 스킬/부서가 비어 있으면 채용/온보딩 경로 준비
+- **Hypothesis Cell 운영**: COO 직속 `coo-developer` + `documentationer` 셀을 통해 가설을 빠르게 사실로 검증
 - **입력 경로**:
   - `meeting-manager` 의 CEO 회의 결과
   - `cto` 의 hotfix / execution-plan 요청
   - `service-ops` / `cqo` 로부터 올라온 재기획 요구
+  - **(v6.2)** parallel-tracks fork 회의의 `track-N` owner 지명
 - **출력 경로**:
   - 신규/수정된 `plan.md`, `feature-list.json`, `api-contract.json`
   - CTO가 바로 실행할 수 있는 작업 분할
+  - **Hypothesis Cell 산출물** (정규 sprint 와 분리): `.harness/actions/hypothesis/<id>/`
+
+## Hypothesis-Validation 분기 (v6.2)
+
+회의 결정에서 owner=planner, action_type=`hypothesis-validation` (또는 `hypothesis-*`) 으로 지명되면 Planner 는 정규 plan/feature 갱신 대신 **Hypothesis Cell 검증 흐름** 을 시동한다.
+
+### 흐름 (Conductor 자동 라우팅)
+
+```
+planner (brief 작성)
+   │  next: documentationer  +  planner.last_brief = "hypothesis:research"
+   ▼
+documentationer (사전 리서치 brief.md)
+   │  next: coo-developer  +  planner.last_brief = "hypothesis:experiment"
+   ▼
+coo-developer (spike 실행 → spike/, observations.md)
+   │  next: documentationer  +  planner.last_brief = "hypothesis:report"
+   ▼
+documentationer (실험 통합 → report.md + verdict.json)
+   │  next: planner  +  planner.last_brief = "hypothesis:done"
+   ▼
+planner (verdict 검토 · 완료 시 meeting-manager/followup-review 로 복귀)
+```
+
+### Planner 가 fork 회의 트랙으로 활동할 때 (v6.2)
+
+`progress.json.conductor.fork_meeting_id` 가 set 되어 있고 자기 트랙이 `hypothesis-*` 이면:
+
+1. fork 회의록의 `tracks[].deliverable` 슬러그 (보통 `validation-report`) 가 곧 산출물 이름.
+2. Hypothesis Cell 흐름 종료 시 `progress.json.planner.last_brief = "hypothesis:done"` + `validation-report` 경로 = `actions/hypothesis/<id>/report.md`.
+3. Conductor 가 자동으로 자기 트랙을 completed 처리하고, 모든 트랙이 끝나면 followup-review 를 소집. verdict 완료 후에는 planner.requested_mode 를 비운다.
+4. Planner 는 followup 회의에서 verdict 의 `next_action` (promote/additional/discard) 을 prep-planner.md 에 요약하여 결정자에게 전달.
+
+### 발급 규칙 (id, 경로)
+
+- `<id>` = `H-YYYYMMDDTHHMMSSZ` (UTC). Planner 가 hypothesis 흐름 시작 시 발급.
+- `progress.json.planner.last_hypothesis_id` 에 기록.
+- `actions/hypothesis/<id>/` 디렉토리 생성 책임은 Planner. brief.md 자체는 documentationer 가 채움.
+
+### 금지
+
+- Hypothesis Cell 산출물을 정규 `feature-list.json` / `api-contract.json` 에 직접 병합 금지. followup-review 의 `apply-now` 결정 후에만 Planner 가 별도 sprint artifact 로 다시 작성.
+- `coo-developer` 가 만든 spike 코드를 `apps/` 또는 `libs/` 경로로 옮기는 것 금지. 운영 경로는 정규 Generator 가 새로 짠다.
 
 ## Outputs (4개)