@walwal-harness/cli 6.1.2 → 6.1.3

package/scripts/harness-meeting-doc.sh

@@ -21,6 +21,13 @@ ops_report=$(jq -r '.service_ops.auto_retro.last_report // empty' "$PROGRESS")
 cqo_audit=$(jq -r '.cqo.audit_path // empty' "$PROGRESS")
 cto_review=$(jq -r '.cto.review_path // empty' "$PROGRESS")
 current_path=$(jq -r '.meetings.current_record_path // empty' "$PROGRESS")
+# v6.2 — parallel tracks hints (set by conductor before convene). length >= 2 = fork.
+requested_tracks=$(jq -c '.meetings.requested_tracks // []' "$PROGRESS")
+requested_rendezvous=$(jq -c '.meetings.requested_rendezvous // null' "$PROGRESS")
+fork_context=$(jq -c '.meetings.fork_context // null' "$PROGRESS")
+fallback_fork_meeting_id=$(jq -r '.meetings.fork_meeting_id // .conductor.fork_meeting_id // ""' "$PROGRESS")
+fallback_conductor_tracks=$(jq -c '.conductor.tracks // []' "$PROGRESS")
+fallback_decision_tracks=$(jq -c '.meetings.decision.tracks // []' "$PROGRESS")
 
 default_decision_json() {
   local owner="planner"
@@ -35,6 +42,33 @@ default_decision_json() {
     owner="planner"
     action_type="goal-alignment"
   fi
+
+  # v6.2 — Tracks 가 단일 진실: length >= 2 → fork-join, length == 1 → single.
+  # legacy {owner, action_type} 만 들어와도 1-element tracks[] 로 합성.
+  local tracks_json="[]"
+  local rendezvous_json="null"
+  if [ "$(jq 'length' <<<"$requested_tracks")" -gt 1 ]; then
+    tracks_json=$(jq -c '
+      [ to_entries[] | (.value + {
+          id: ((.value.id // null) // ("track-" + ((.key + 1) | tostring))),
+          deliverable: (.value.deliverable // "report"),
+          deliverable_path: (.value.deliverable_path // null),
+          status: (.value.status // "pending")
+        })
+      ]
+    ' <<<"$requested_tracks")
+    rendezvous_json=$(jq -c '. // {type:"followup-review", when:"next_cadence"}' <<<"$requested_rendezvous")
+    # primary owner = first track owner (편의 미러)
+    owner=$(jq -r '.[0].owner // "planner"' <<<"$tracks_json")
+    action_type=$(jq -r '.[0].action_type // "triage"' <<<"$tracks_json")
+  else
+    # single — derive a 1-element tracks[] (backward compat 도 동시에 처리)
+    tracks_json=$(jq -c -n \
+      --arg owner "$owner" \
+      --arg action_type "$action_type" \
+      '[ {id:"track-1", owner:$owner, action_type:$action_type, deliverable:"report", deliverable_path:null, status:"pending"} ]')
+  fi
+
   jq -n \
     --arg owner "$owner" \
     --arg action_type "$action_type" \
@@ -42,7 +76,9 @@ default_decision_json() {
     --arg drift_classification "$1" \
     --arg ops_report "$ops_report" \
     --arg cqo_audit "$cqo_audit" \
-    --arg cto_review "$cto_review" '
+    --arg cto_review "$cto_review" \
+    --argjson tracks "$tracks_json" \
+    --argjson rendezvous "$rendezvous_json" '
     {
       owner: $owner,
       action_type: $action_type,
@@ -54,26 +90,70 @@ default_decision_json() {
           (if $cto_review != "" then {source:$cto_review, kind:"cto-review"} else empty end)
         ]
       ),
-      drift_classification: $drift_classification
+      drift_classification: $drift_classification,
+      tracks: $tracks,
+      rendezvous: $rendezvous
     }'
 }
 
+resolve_followup_fork_context() {
+  local resolved="$fork_context"
+  if [ "$requested_type" != "followup-review" ]; then
+    echo "$resolved"
+    return
+  fi
+
+  if [ "$resolved" != "null" ] && [ -n "$resolved" ]; then
+    echo "$resolved"
+    return
+  fi
+
+  local fallback_tracks="$fallback_conductor_tracks"
+  if [ "$(jq 'length' <<<"$fallback_tracks")" -eq 0 ] && [ "$(jq 'length' <<<"$fallback_decision_tracks")" -gt 0 ]; then
+    fallback_tracks="$fallback_decision_tracks"
+  fi
+
+  if [ "$(jq 'length' <<<"$fallback_tracks")" -eq 0 ]; then
+    echo "null"
+    return
+  fi
+
+  jq -c -n \
+    --arg fork_meeting_id "$fallback_fork_meeting_id" \
+    --argjson prior_tracks "$fallback_tracks" \
+    '{fork_meeting_id:$fork_meeting_id, prior_tracks:$prior_tracks, sealed_at:(now | todate)}'
+}
+
 if [ "$MODE" = "prepare" ]; then
   meeting_id="M-$(date -u +%Y%m%dT%H%M%SZ)"
   meeting_dir="$MEETINGS_ROOT/$meeting_id"
   mkdir -p "$meeting_dir"
   record="$meeting_dir/meeting-$meeting_id.md"
 
+  # v6.2 — Notice surfaces tracks/rendezvous for visibility (length >= 2 = fork)
+  tracks_summary="(single owner)"
+  rendezvous_summary="-"
+  is_fork="false"
+  if [ "$(jq 'length' <<<"$requested_tracks")" -gt 1 ]; then
+    is_fork="true"
+    tracks_summary=$(jq -r '[.[] | "\(.id // "?"):\(.owner)/\(.action_type)→\(.deliverable // "report")"] | join(", ")' <<<"$requested_tracks")
+    rendezvous_summary=$(jq -r '"\(.type // "followup-review")@\(.when // "next_cadence")"' <<<"$requested_rendezvous")
+  fi
   cat > "$meeting_dir/notice.md" <<EOF
 # Notice — $meeting_id
 
 - type: $requested_type
 - reason: $requested_reason
 - goal_adherence: $goal_adherence
+- fork: $is_fork
+- tracks: $tracks_summary
+- rendezvous: $rendezvous_summary
 
 ## Request
 "$requested_reason" 요청이 접수되었습니다. 참석자들은 각자의 전문 시각에서 사실·증거를 제출하고,
 다음 owner와 action_type을 evidence 중심으로 결정하십시오.
+
+> **Parallel tracks (v6.2)**: \`tracks[]\` 의 길이 ≥ 2 면 fork-join. \`rendezvous\` 시점에 followup-review 로 합쳐집니다. 단일 트랙 회의는 기존과 동일하게 동작합니다.
 EOF
 
   cat > "$meeting_dir/prep-dispatcher.md" <<'EOF'
@@ -108,6 +188,26 @@ EOF
 EOF
 
   decision_json="$(default_decision_json "$drift")"
+
+  # v6.2 — followup-review: surface prior_tracks + fork_meeting_id from fork_context
+  resolved_fork_context="$(resolve_followup_fork_context)"
+
+  fork_section=""
+  if [ "$requested_type" = "followup-review" ] && [ "$resolved_fork_context" != "null" ] && [ -n "$resolved_fork_context" ]; then
+    fork_id=$(jq -r '.fork_meeting_id // ""' <<<"$resolved_fork_context")
+    fork_section="
+
+## Fork Context (v6.2)
+- fork_meeting_id: $fork_id
+- prior_tracks (rendezvous 입력):
+
+\`\`\`json
+$(jq '.prior_tracks' <<<"$resolved_fork_context")
+\`\`\`
+
+> 결정자(기본 CTO) 는 위 트랙별 deliverable 을 통합 검토 후 \`apply-now / backlog / more-validation\` 중 하나를 선택해 아래 Decision JSON 의 \`tracks\` 를 비우고 \`owner / action_type\` 만 채운다 (followup 에서 또 fork 금지)."
+  fi
+
   cat > "$record" <<EOF
 # Meeting Record — $meeting_id
 
@@ -115,6 +215,7 @@ EOF
 - type: $requested_type
 - reason: $requested_reason
 - goal_adherence: $goal_adherence
+$fork_section
 
 ## Decision JSON
 \`\`\`json
@@ -135,6 +236,10 @@ EOF
        jq -n --arg meeting_id "$meeting_id" --arg type "$requested_type" --arg reason "$requested_reason" --arg source_path "${record#$PROJECT_ROOT/}" --argjson decision "$decision_json" '{meeting_id:$meeting_id,type:$type,reason:$reason,decision:($decision + {source_path:$source_path})}'
      )"))" >/dev/null
 
+  if [ "$requested_type" = "followup-review" ] && [ "$resolved_fork_context" != "null" ] && [ -n "$resolved_fork_context" ]; then
+    bash "$SCRIPT_DIR/harness-progress-set.sh" "$PROJECT_ROOT" ".meetings.fork_context = $resolved_fork_context" >/dev/null
+  fi
+
   echo "${record#$PROJECT_ROOT/}"
   exit 0
 fi
@@ -150,4 +255,43 @@ if [ "$MODE" = "read-decision" ]; then
   exit 0
 fi
 
+# v6.2 — read-tracks: emit normalized tracks[] (length>=2 = fork, length==1 = single).
+# Legacy decisions without tracks → synthesize 1-element tracks[] from {owner, action_type}.
+if [ "$MODE" = "read-tracks" ]; then
+  jq -c '
+    if ((.meetings.decision.tracks // []) | length) > 0 then
+      .meetings.decision.tracks
+    elif ((.meetings.fork_context.prior_tracks // []) | length) > 0 then
+      .meetings.fork_context.prior_tracks
+    elif ((.conductor.tracks // []) | length) > 0 then
+      .conductor.tracks
+    else
+      [ {
+          id: "track-1",
+          owner: (.meetings.decision.owner // "planner"),
+          action_type: (.meetings.decision.action_type // "triage"),
+          deliverable: "report",
+          deliverable_path: null,
+          status: "pending"
+        }
+      ]
+    end
+  ' "$PROGRESS"
+  exit 0
+fi
+
+# v6.2 — read-rendezvous: emit rendezvous{} or null
+if [ "$MODE" = "read-rendezvous" ]; then
+  jq -c '.meetings.decision.rendezvous // .conductor.rendezvous // null' "$PROGRESS"
+  exit 0
+fi
+
+# v6.2 — read-fork: "true" if tracks.length >= 2, else "false"
+if [ "$MODE" = "read-fork" ]; then
+  decision="$(bash "$0" "$PROJECT_ROOT" read-decision 2>/dev/null || true)"
+  if [ -z "$decision" ]; then decision='{}'; fi
+  jq -r '((.tracks // []) | length) > 1' <<<"$decision"
+  exit 0
+fi
+
 exit 2

package/scripts/harness-session-start.sh

@@ -8,10 +8,12 @@
 SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
 LIB="$SCRIPT_DIR/lib/harness-render-progress.sh"
 AUDIT_LIB="$SCRIPT_DIR/lib/harness-audit.sh"
+MIGRATE_LIB="$SCRIPT_DIR/lib/harness-progress-migrate.sh"
 
 if [ ! -f "$LIB" ]; then exit 0; fi
 source "$LIB"
 [ -f "$AUDIT_LIB" ] && source "$AUDIT_LIB"
+[ -f "$MIGRATE_LIB" ] && source "$MIGRATE_LIB"
 command -v jq &>/dev/null || exit 0
 
 PROJECT_ROOT="$(resolve_harness_root "." 2>/dev/null)" || exit 0
@@ -20,6 +22,11 @@ CONFIG="$PROJECT_ROOT/.harness/config.json"
 HANDOFF="$PROJECT_ROOT/.harness/handoff.json"
 [ -f "$PROGRESS" ] || exit 0
 
+# v6.2 — idempotent schema migration (parallel tracks fields, etc.)
+if declare -f migrate_progress_schema >/dev/null 2>&1; then
+  migrate_progress_schema "$PROGRESS" || true
+fi
+
 sprint_status=$(jq -r '.sprint.status // "init"' "$PROGRESS" 2>/dev/null)
 sprint_num=$(jq -r '.sprint.number // 0' "$PROGRESS" 2>/dev/null)
 current_agent=$(jq -r '.current_agent // "none"' "$PROGRESS" 2>/dev/null)

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>/` 로 이동