@walwal-harness/cli 6.1.5 → 7.1.0

package/skills/generator-frontend/references/_web-react-legacy/component-patterns.md

@@ -1,52 +0,0 @@
-# Component Patterns
-
-## 프로젝트 구조
-
-```
-apps/web/src/
-├── api/
-│   ├── client.ts           # fetch 인스턴스 (base: localhost:3000)
-│   ├── types.ts            # api-contract.json → TypeScript 1:1
-│   └── [domain].ts         # 도메인별 API 함수
-├── components/
-│   ├── ui/                 # Button, Input, Modal, Card
-│   └── [domain]/           # 도메인별 컴포넌트
-├── pages/ (또는 app/)
-├── hooks/
-│   └── use[Domain].ts
-├── stores/                 # Zustand (클라이언트 상태만)
-└── styles/
-    └── globals.css         # Tailwind directives
-```
-
-## API 타입 변환
-
-```typescript
-// api-contract.json의 response_200을 그대로 반영
-interface ItemResponse {
-  id: number;
-  name: string;
-  created_at: string;
-}
-```
-
-## 상태관리
-
-- 서버 상태: TanStack Query (캐시, 리페치, 낙관적 업데이트)
-- 클라이언트 상태: Zustand (최소한, 서버 상태와 중복 금지)
-
-## 3가지 상태 필수 처리
-
-```tsx
-if (isLoading) return <Skeleton />;
-if (error) return <ErrorMessage error={error} />;
-if (data.length === 0) return <EmptyState />;
-return <ItemList items={data} />;
-```
-
-## 접근성
-
-- `<button>`, `<nav>`, `<main>`, `<form>` 시맨틱 태그
-- `aria-label` 필요 시 추가
-- Tab 순서 논리적, Enter/Escape 동작
-- 색상 대비 4.5:1 이상

package/skills/generator-frontend/references/_web-react-legacy/design-system-rules.md

@@ -1,139 +0,0 @@
-# Design System Rules
-
-> 출처: taste-skill (Leonxlnx), supanova-design-skill (uxjoseph)
-> React/Next.js 앱 컨텍스트에 맞게 적응
-
-## 디자인 변수 (Baseline)
-
-```
-DESIGN_VARIANCE: 8   (1=대칭, 10=비대칭)
-MOTION_INTENSITY: 6  (1=정적, 10=시네마틱)
-VISUAL_DENSITY: 4    (1=갤러리, 10=콕핏)
-```
-
-사용자 요청에 따라 동적 조정. Planner의 plan.md에 명시된 톤에 맞춤.
-
-## 1. Typography
-
-### 한국어
-- **Primary**: Pretendard (CDN 또는 next/font)
-- Headlines: `text-4xl md:text-5xl lg:text-6xl tracking-tight leading-tight font-bold`
-- Body: `text-base md:text-lg text-gray-600 leading-relaxed max-w-[65ch]`
-- **`break-keep-all`** 필수 (한국어 단어 중간 줄바꿈 방지)
-- **`leading-tight` ~ `leading-snug`** (한국어는 Latin보다 수직 여백 필요)
-
-### 영문 Display
-- `Geist`, `Outfit`, `Cabinet Grotesk`, `Satoshi` 중 택 1
-- Headlines: `tracking-tighter leading-none`
-- Dashboard/Software UI: Serif 폰트 **금지** → Sans-Serif만 (`Geist` + `Geist Mono`)
-
-### 금지 폰트
-Inter, Noto Sans KR, Roboto, Arial, Open Sans, Helvetica, Malgun Gothic
-
-## 2. Color
-
-- **Accent 1개만.** Saturation < 80%
-- **THE LILA BAN**: AI 보라색/파란색 그라디언트 **금지**
-- Neutral base: Zinc/Slate 계열
-- Accent: Emerald, Electric Blue, Warm Amber, Deep Rose 중 택 1
-- 페이지 전체 warm/cool gray **혼용 금지**
-- **NO Pure Black**: `#000000` 금지 → `#0a0a0a`, Zinc-950, Slate-950
-
-### 다크모드
-- 랜딩페이지: 다크 기본 권장 (`bg-zinc-950`)
-- 앱/대시보드: 라이트 기본, 다크 옵션 (`dark:` prefix)
-
-## 3. Layout
-
-- **ANTI-CENTER BIAS**: DESIGN_VARIANCE > 4 일 때 센터 정렬 Hero **금지**
-  - Split Screen (50/50), 좌측 정렬/우측 에셋, 비대칭 여백 사용
-- **NO 3-Column Equal Cards**: Bento Grid, Zig-Zag, 비대칭 그리드 사용
-- **Grid over Flex-Math**: `grid grid-cols-1 md:grid-cols-3 gap-6` (flexbox calc 금지)
-- **컨테이너**: `max-w-7xl mx-auto px-4 sm:px-6 lg:px-8`
-- **섹션 간격**: `py-24 md:py-32 lg:py-40` (디자인이 숨쉬도록)
-- **모바일 오버라이드**: `< 768px`에서 `w-full px-4 py-8` 단일 컬럼 강제
-
-### Bento Grid 패턴
-```
-grid grid-cols-12
-- col-span-8 row-span-2 (큰 카드)
-- col-span-4 (작은 카드 2개 스택)
-```
-
-## 4. Components
-
-### Card Architecture (Double-Bezel)
-```
-Outer: bg-white/5 ring-1 ring-white/10 p-1.5 rounded-[2rem]
-Inner: bg-distinct shadow-[inset_0_1px_1px_rgba(255,255,255,0.15)] rounded-[calc(2rem-0.375rem)]
-```
-- Card는 elevation이 hierarchy를 전달할 때만 사용
-- VISUAL_DENSITY > 7: card 대신 `border-t`, `divide-y`, negative space
-
-### CTA Button
-```
-rounded-full px-8 py-4 text-lg
-hover:scale-[1.02] active:scale-[0.98]
-transition: all 0.5s cubic-bezier(0.16, 1, 0.3, 1)
-```
-- 화살표 아이콘: 원형 래퍼 안에 배치 (`w-8 h-8 rounded-full bg-black/5`)
-- 모바일 최소 48px 높이
-
-### Eyebrow Tag
-```
-rounded-full px-3 py-1 text-[11px] uppercase tracking-[0.15em] font-medium bg-accent/10 text-accent
-```
-
-## 5. Motion
-
-### 전역 트랜지션 기본값
-```css
-transition: all 0.5s cubic-bezier(0.16, 1, 0.3, 1);
-```
-`linear`, `ease-in-out` **금지**. 모든 인터랙티브 요소에 이 curve 적용.
-
-### 스크롤 진입
-```css
-@keyframes fadeInUp {
-  from { opacity: 0; transform: translateY(2rem); filter: blur(4px); }
-  to   { opacity: 1; transform: translateY(0);    filter: blur(0);   }
-}
-```
-- `IntersectionObserver`로 트리거 (`window.addEventListener('scroll')` 금지)
-- 형제 요소 stagger: `animation-delay: calc(var(--index) * 80ms)`
-
-### Framer Motion (MOTION_INTENSITY > 5)
-- Spring physics: `type: "spring", stiffness: 100, damping: 20`
-- `layout` / `layoutId`로 레이아웃 전환
-- `useMotionValue` + `useTransform` (연속 애니메이션에 useState 금지)
-- Perpetual motion은 `React.memo`로 격리된 Client Component에서만
-- `<AnimatePresence>` 필수
-
-### 성능
-- **GPU만**: `transform`, `opacity`만 애니메이션. `top/left/width/height` 금지
-- **Blur 제한**: `backdrop-blur`는 fixed/sticky 요소에만
-- **Z-index**: sticky nav(`z-40`), overlay(`z-50`)에만. 임의 z-50 남발 금지
-- **Grain/Noise**: `position: fixed; pointer-events: none; z-[60]`에서만
-
-## 6. Viewport & Responsiveness
-
-- **`min-h-[100dvh]`** 사용 (`h-screen` **금지** — iOS Safari 깨짐)
-- Breakpoints: `sm:640` `md:768` `lg:1024` `xl:1280`
-- 모바일 터치 타겟: 최소 44px
-- 텍스트 가독성: 모바일 최소 14px
-
-## 7. 한국어 콘텐츠 기준
-
-- **자연스러운 한국어**: 번역체 금지
-- 존댓말 일관성: 합니다/하세요 통일
-- CTA: "무료로 시작하기", "3분만에 만들어보기", "지금 바로 체험하기"
-- **금지 표현**: "혁신적인", "획기적인", "차세대", "원활한", "게임 체인저"
-- 이름: 하윤서, 박도현, 이서진, 김하늘 (김철수/John Doe 금지)
-- 숫자: `47,200+`, `4.87/5.0` (50,000+, 5.0 같은 깨끗한 숫자 금지)
-
-## 8. Icons
-
-- **Phosphor Icons** (`@phosphor-icons/react`) 또는 **Radix Icons** (`@radix-ui/react-icons`)
-- strokeWidth 전역 통일 (1.5 또는 2.0 중 택 1)
-- **이모지 금지**: 코드, 마크업, 텍스트 어디에서든
-- FontAwesome, Material Icons 금지 (두꺼운 선)

package/skills/generator-frontend/references/_web-react-legacy/vercel-best-practices.md

@@ -1,54 +0,0 @@
-# Vercel / Next.js Best Practices
-
-> 출처: Vercel Engineering, Next.js App Router 공식 문서
-
-## Framework 기본값
-
-- **Next.js App Router** + **Server Components** 기본
-- `'use client'`는 인터랙션이 필요한 곳에만 추가
-- `proxy.ts` (Next.js 16+) 또는 `middleware.ts`로 인터셉션, 인증 게이트, 리다이렉트
-- Cache Components, `next/image`, `next/font` 우선 사용
-
-## RSC (React Server Components) 규칙
-
-- **RSC 안전**: 전역 상태는 Client Components에서만 동작
-- Next.js에서 Provider는 별도 `'use client'` 컴포넌트로 래핑
-- **인터랙티비티 격리**: 모션/인터랙션이 있는 UI는 독립 leaf 컴포넌트로 추출 + `'use client'`
-- Server Components는 정적 레이아웃만 렌더링
-
-## 렌더링 전략
-
-- **SSG (Static)**: 변하지 않는 페이지
-- **ISR (Incremental)**: 주기적 갱신이 필요한 페이지
-- **SSR (Dynamic)**: 요청마다 달라지는 페이지
-- **PPR (Partial Prerendering)**: 정적 쉘 + 동적 홀 조합
-
-## 성능 최적화
-
-- `next/image`: 자동 최적화, `loading="lazy"`, `sizes` 속성 필수
-- `next/font`: 빌드 타임 폰트 최적화, 레이아웃 시프트 방지
-- **번들 사이즈**: `'use client'` 경계에서 트리쉐이킹 확인
-- **Core Web Vitals**: LCP < 2.5s, FID < 100ms, CLS < 0.1 목표
-
-## 상태관리 전략
-
-- **서버 상태**: TanStack Query (캐시, 리페치, 낙관적 업데이트)
-- **클라이언트 상태**: Zustand (최소한, 서버 상태와 중복 금지)
-- `useState`/`useReducer`: 격리된 UI 로직에만
-- 전역 상태: deep prop-drilling 회피 목적으로만
-
-## 의존성 검증 [필수]
-
-3rd party 라이브러리 import 전 반드시 `package.json` 확인.
-없으면 설치 명령 먼저 출력. **존재를 가정하지 않는다.**
-
-## Tailwind CSS 버전 관리
-
-- `package.json`에서 v3/v4 확인 후 해당 문법 사용
-- v4: `postcss.config.js`에 `tailwindcss` 플러그인 사용 금지 → `@tailwindcss/postcss` 또는 Vite 플러그인
-- v3 프로젝트에 v4 문법 혼용 금지
-
-## shadcn/ui 사용 시
-
-- 기본 상태 그대로 사용 **금지**
-- radius, colors, shadows를 프로젝트 디자인 시스템에 맞게 커스터마이즈 필수

package/skills/meeting-manager/SKILL.md

@@ -1,419 +0,0 @@
----
-name: harness-meeting-manager
-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
----
-
-<!--
-Source attribution: https://github.com/msitarzewski/agency-agents (MIT)
-이 스킬은 strategy/coordination/handoff-templates.md 의 Standup/Sprint/Phase-Gate
-양식과 strategy/runbooks/scenario-incident-response.md 의 War Room 패턴을
-walwal-harness 의 부서 구조에 맞게 재해석함.
--->
-
-# Meeting-Manager — 회의 소집·집계·디스패치
-
-> 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 추가)
-
-| 종류 | 트리거 | 참석자 | 결과물 | Owner 푸시? |
-|---|---|---|---|---|
-| **Standup** | Cron (적응형) | CTO·CQO·Service-Ops | GOAL 적합도·블로커·다음 24h 계획 | ❌ (대시보드만) |
-| **Sprint Review** | Sprint 종료 이벤트 | CEO·COO·CTO·CQO | PASS/FAIL 통합·다음 Sprint 결정 | ✅ 요약본 |
-| **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단계)
-
-```
-Notice → Prep → Convene → Decide → Minutes
-```
-
-| 단계 | 책임 | 산출물 |
-|---|---|---|
-| Notice | Meeting-Manager | `.harness/actions/meetings/<id>/notice.md` (의제·참석자·deadline) |
-| Prep | 각 참석자 | `.harness/actions/meetings/<id>/prep-<role>.md` |
-| Convene | Meeting-Manager | prep 통합 → `meeting-<id>.md` 초안 |
-| Decide | rubric → CEO override | `decisions:` 섹션 작성 |
-| Minutes | Meeting-Manager | Action Items를 queue enqueue + archive |
-
-## 4. 적응형 Cadence (Standup)
-
-| 모드 | 주기 | 진입 조건 |
-|---|---|---|
-| `light` | 30m | 활성 Sprint AND Service-Ops 이벤트율 < 1/h AND goal_adherence ≥ 0.9 |
-| `normal` | 1h | 기본값 / 다른 모드 미충족 |
-| `heavy` | 4h | (idle OR 배포 후 안정기) AND 직전 3회 standup 무특이사항 |
-
-전환 결정자: Service-Ops가 매 Standup 종료 시 직전 3회 메트릭으로 재계산 → `progress.json.meetings.cadence` 갱신.
-수동 override: Owner가 `/meeting-cadence light|normal|heavy` (Conductor가 1회 적용 후 자동 조정 재개).
-
-## 5. 의사결정 규칙
-
-```
-1. rubric 기반 합의 시도
-   - 각 참석자 의견 + 가중치 (담당 영역 가중)
-   - 가중 동의율 ≥ 0.66 → 가결
-2. 가결 못 함 → CEO override 요청
-   - Dispatcher 통해 Owner에게 옵션 제시
-   - Owner 응답 = 최종
-3. 인시던트는 시간 압박 → CEO 즉시 override 가능
-```
-
-## 6. Artifact 스키마
-
-`.harness/actions/meetings/<meeting-id>.md`:
-
-```yaml
----
-docmeta: { id, type: output, ... }
-meeting:
-  id: M-2026-05-07-0001
-  type: standup | sprint-review | spec-review | incident | all-hands
-  trigger: cron | event:<source> | manual
-  scheduled_at: <iso>
-  convened_at: <iso>
-  attendees: [cto, cqo, service-ops]
-  status: notice | prep | convened | decided | dispatched | archived
-  prep_links:
-    - role: cto
-      uri: meetings/M-.../prep-cto.md
-  agenda:
-    - <item>
-  reports:
-    - role: <role>
-      summary: <one-line>
-  decisions:
-    - id: D-1
-      text: <decision>
-      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 | 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 | 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
-      description: <task>
-      due: <iso>
-      queue_entry_id: <queue-id>
-  goal_adherence_delta: -0.05
-  escalation_to_owner: false
----
-
-# Meeting <id> — <type> @ <ts>
-
-## 1. Agenda
-## 2. Reports (per role)
-## 3. Decisions
-## 4. Action Items
-## 5. Next Meeting
-```
-
-## 7. progress.json 추가
-
-```json
-  "meetings": {
-  "cadence": "light|normal|heavy",
-  "last_standup": "<iso>",
-  "next_scheduled": "<iso>",
-  "active": [ { "id": "...", "type": "...", "status": "..." } ],
-  "open_action_items": 0,
-  "last_goal_adherence": 0.92,
-  "decision": {
-    "owner": "planner",
-    "action_type": "goal-alignment",
-    "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 를 같은 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 회의에 전달된다.
-
-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` — 백로그/queue 에 work package 등록. 다음 owner = planner (feature-list append) 이며 Conductor 가 가능한 시점에 자동 배정.
-   - `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를 요청한다.
-
-- `Dispatcher/CEO`: Goal 자체가 흔들렸는가, Owner escalation 이 필요한가
-- `Planner/COO`: 기획/가설/웹리서치/레퍼런스 재검토가 필요한가
-- `COO Hypothesis Cell`: 실험으로 바로 검증 가능한가, 어떤 백데이터/리서치가 필요한가
-- `CTO`: 구현/아키텍처/기술선택 문제가 원인인가
-- `CQO`: 품질/회귀/검증 부족이 원인인가
-- `Service-Ops`: KPI/로그/incident 기준으로 어떤 drift 가 발생했는가
-
-회의 종료 시 `decision.owner`, `action_type`, `rationale`, `evidence`, `drift_classification` 이 비어 있으면 회의는 미완료로 본다.
-
-## 8. Cron 통합 (Service-Ops 위임)
-
-Meeting-Manager 자체는 cron을 돌리지 않음. Service-Ops가 매 hourly 틱에서:
-1. cadence 모드에 따라 다음 스케줄 시각 계산
-2. 도달 시 Meeting-Manager에 `convene(type=standup)` 요청
-3. Meeting-Manager가 라이프사이클 실행
-
-이로써 cron 책임이 Service-Ops에 일원화되고, Meeting-Manager는 순수 회의 도메인에 집중.
-
-## 9. Event 트리거 카탈로그
-
-| Event 발신처 | 조건 | 소집 회의 |
-|---|---|---|
-| Dispatcher | 신규 GOAL / 재플래닝 시작 | All-Hands (`goal-intake`) |
-| Eval-* | `## Change Request` 첨부 | Spec Review |
-| Conductor | 3회 FAIL | Spec Review (scope 축소 검토) |
-| Service-Ops | red-alert (5xx 임계 / 헬스 실패) | Incident War Room |
-| Conductor | Sprint 종료 (모든 feature PASS) | Sprint Review |
-| 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 디스패치
-
-회의 종료 시 모든 Action Item은 기존 queue enqueue (v5.9.6) 재사용:
-
-```bash
-bash scripts/queue-enqueue.sh   --owner generator-backend   --feature <feature-id>   --description "<text>"   --due "<iso>"   --source-meeting <meeting-id>
-```
-
-큐에 들어간 항목은 Conductor가 다음 틱에서 자연스럽게 spawn.
-
-## 11. Owner 가시성 정책
-
-- **기본**: 회의록은 대시보드(`apps/harness-dashboard`) 회의실 룸에 핀, Owner가 클릭해서 조회
-- **푸시 발생**: Sprint Review / Phase Gate / Incident War Room → Dispatcher가 다음 Owner 메시지에서 1줄 요약 보고
-- **요청 시**: Owner가 "오늘 회의 요약" / `/meetings today` → 최근 N건 헤더 + 미해결 Action Item 출력
-
-## 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` 읽기 → 현재 `meetings.tracking[]` 확인 (중복 방지)
-2. meeting-id 발급 (`M-YYYY-MM-DD-NNNN`)
-3. `.harness/actions/meetings/<id>/notice.md` 작성
-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 — **참석자 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 — **`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` / `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 — `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. 안전 가드
-
-- **회의 중복 방지**: 같은 type이 active이면 새 소집 무시 (incident만 예외)
-- **prep 누락**: 5분(standup) / 30분(그 외) timeout, 결석자 표시 후 진행
-- **무한 회의 방지**: 한 Sprint 내 같은 type 회의 ≥ 5회면 escalation
-- **CEO override 남용 방지**: Owner override 카운트를 회의록에 기록, Sprint Review에서 회고
-
-## 14. 출처 (Attribution)
-
-본 스킬은 https://github.com/msitarzewski/agency-agents (MIT) 의 다음을 재해석함:
-- `strategy/coordination/handoff-templates.md` — Standup·Sprint·Phase Gate 양식
-- `strategy/runbooks/scenario-incident-response.md` — War Room 패턴
-- `specialized/specialized-chief-of-staff.md` — 회의 사회·문서 의존성 그래프 관리
-- `support/support-executive-summary-generator.md` — 회의록 요약 출력