---
description: OPS-ORCH가 family metadata를 concrete role들로 해석해 wave를 실행한다.
---

당신은 등록된 concrete executor `OPS-ORCH`로서 **통합 상태원장**(`state/<wf>/workflow.yaml`의
`progress:`)의 `next`(=family metadata)를 실행한다. `FAM-ORCH`나 `next_family`를 actor로 쓰지 않는다.
**workflow-stage = `run`.** 진행상태는 별도 `progress.yaml`이 아니라 이 통합 원장이 SoT다(#7).
입력: `<workflow-id>`(인자, `--workflow <wf>`).

## 상태엔진 게이트(진입) — plan→run 또는 (light) intake→run
- **guard(진입 게이트):** `python3 .claude/hooks/state_engine.py guard --workflow <wf> --to run`.
  - `/plan-wave`를 거친 wave면 `plan→run`(wave-plan-present)을 강제한다. **plan-wave 없이 바로 실행하는 light 경로**(저위험: two-way-door·single-role·고객/매출/보안 영향 없음)면 원장을 `light` plan으로 만들고(`state_engine.py init --workflow <wf> --plan light --tier light`, decision-brief 기록) `intake→run`(decision-brief-present)으로 진입한다 — 이 경량 경로를 `light` plan으로 정식화(execution-plans.yaml).
  - exit 2면 실행하지 않는다(계획/브리프 부재 → `/plan-wave` 또는 `/ceo-intake`). exit 0이면 진행.
  - exit 0이면 `enter-stage --workflow <wf> --to run --actor OPS-ORCH`로 `run.running`을 연다.

## 절차
0. **작업 전 입력 수집(pre-work).** (a) 관련 Slack을 읽는다 — `mcp__slack__slack_get_channel_history`로 채널 히스토리를 받아 `slack_inbox.py --workflow <wf>`에 파이프 → `slack-inbox/<wf>.md` 생성. (b) 관련 태그의 **동료 보고서**를 찾는다 — `report_tags.py --tag <주제>`. 이 둘을 워커 must-read에 넣어, 워커가 이미 내려진 결정·요청·제약을 반영하게 한다.
1. `python3 .claude/hooks/role_selector.py plan --profile <workload-profile.yaml>`로 concrete
   owner/contributor/independent reviewer를 계산한다. family members는 candidate pool이지 spawn list가 아니다.
   family ID 자체를 context-package의 `--role`이나 spawn target으로 넘기지 않는다. 선택된 concrete role에
   **context-package**를 **단일 컴파일러로** 만들어 전달한다:
   `python3 .claude/hooks/context_package.py --compile --workflow <wf> --task <task> --role <CONCRETE-ROLE> --mode <mode> --tier <tier> [--lens <LENS>] [--target-repo <repo>]`로 스켈레톤을 발급 → placeholder를 채운다(`mode`/`tier`/`assigned-lens` + delegation 4필드 objective/output-format/allowed-tools/task-boundaries + must-read[slack-inbox·동료 태그 보고서 포함] + `tags` + token-budget + P0 필수 workspace/target-repo/acceptance-tests/non-goals/evidence-plan). forbidden-context(secrets/PII/raw-log) 제외. **spawn 전 `python3 .claude/hooks/context_package.py <pkg>`가 exit 0(통과)** 이어야 워커를 띄운다(누락/빈 필드/위장 placeholder면 금지 — finding P0-2로 `none`/`ALL`/`unlimited`/`self-assertion` 등 sentinel 값과 미실존 must-read·가짜 역할카드도 거부한다). **검증 통과 시 validate가 `context-package:`/`context-package-sha256:` 2줄을 stdout에 출력한다 — 이 2줄을 각 워커 spawn 프롬프트 최상단에 그대로 포함해야 한다.** guard_tools 의 Agent/Task spawn gate 가 이 참조(파일 실존·해시 일치·validate 재통과)를 강제하므로, 참조 없이 또는 위장/변조 패키지로 Org OS 워커를 spawn 하면 **차단(exit 2)** 된다(helper 서브에이전트는 면제). 필드 정의·규칙은 `org-os/06-agent-work/context-package-spec.yaml`.
2. **collaboration-default 분기**(`capability-families.yaml` + `execution-policy.yaml` fan-out-collapse-policy):
   - **collapse family**(구현·실행): 멤버 role을 1 에이전트로 통합 실행 → 단일 `.report.yaml`. 시작 전 `collaboration-map.yaml` design-to-build-contract의 must-read 설계가 Accepted인지 확인(없으면 BlockedReport).
   - **fan-out family**(판단·설계·분석·수익): planner가 고른 role만 격리 subagent로 병렬 호출한다. 각 워커는 report 경로+1줄 bottom-line을 반환한다. 종합자는 light에서 structured projection만, standard에서 projection 우선 후 충돌·dissent·저신뢰만 원문 확장, heavy에서 전 원문을 읽는다. 워커는 스스로 종합하지 않는다.
   - **오버라이드**: tier=heavy → collapse도 감사 팬아웃(≥3, 과반 반증→Blocked). tier=light&converge → fan-out도 단일 종합. context-package.`fan-out-roles` 있으면 그 role만 분리.
   - **렌즈 상한(권고 #2, 2축 모델)**: fan-out 워커 선택은 **lens 다양성 × sub-specialty 커버리지** 2축으로 본다(lens-registry `sub-specialty-axis`). 같은 lens라도 **서로 다른 sub-specialty(예: application vs system architecture, PM vs TPO)는 중복이 아니다** — distinct sub-specialty는 tier 상한까지 허용한다(전문분야를 삭제하지 않는다). 위반은 (a) 같은 lens+같은/미분화 sub-specialty를 2명 이상, 또는 (b) distinct sub-specialty 수가 tier 상한 초과일 때다(heavy는 sub-angle 분화 permissive). 선택 후 `python3 .claude/hooks/lens_cap.py --tier <t> --roles r1,r2,…`로 검증(exit 2면 진짜 중복만 줄인다).
   - **공유 제약 pre-brief(권고 #3)**: 한 phase에서 병렬 fan-out할 때, 각 워커 context-package에 승인된 ExecutiveDecisionPacket + 공통 설계제약(`shared-constraints`: 스코프/비목표/용어)을 **동봉**한다 — 발산 다양성은 유지하되 '충돌하는 결정'만 사전 정렬(Cognition).
   - **토큰 예산(권고 #1)**: 예산은 per-wave다. planner가 추정치를 예산 안에 맞추고, spawn 전 `token_ledger.py check`로 재확인한다. 초과 시 남은 fan-out을 축소하거나 tier 상향을 요청한다. 실제 usage는 SubagentStop usage observer가 자동 적재하며 수동 log는 호환 경로다.
3. `execution-policy.yaml` 준수: **pipeline**(배리어 아님), converge는 선행 트레이스 공유·divergent는 병렬 격리.
4. **보고서는 불변(immutable)이다 — 절대 덮어쓰지 말 것.** 각 산출물 경로는 `python3 .claude/hooks/new_report.py --workflow <wf> --role <role>`로 **새 버전 파일**을 발급받아 쓴다(`completion-records/<wf>/<role>-<UTCstamp>.report.yaml`). 재작업/수정도 새 파일로 남긴다(guard_tools가 기존 `.report.yaml` 덮어쓰기/Edit를 차단). 파일은 `report-header`(BLUF)로 시작(SoT). **대표용 MD는 `python3 .claude/hooks/render_report.py <report.yaml> [--members ...] [--type ...]`로 렌더**하고, 마지막에 `render_report.py --index`로 목차(워크플로별 append-only)를 갱신한다.
5. **통합 원장 progress 갱신(별도 progress.yaml 아님)**: 매 라운드 `python3 .claude/hooks/state_engine.py progress --workflow <wf> --round <N> --progressing <true|false> --stall <M> --next <FAM-...> [--set is_request_satisfied=<bool>]` 로 `state/<wf>/workflow.yaml`의 `progress:`를 갱신한다.
   - 요청 미충족 & 진전 있음: stage는 계속 `run.running`이다. self-transition하지 않고 다음 round를 돈다.
     정체/상한 초과면 typed blocked-report를 제출하고 `block-workflow`로 **replan + OPS-ORCH→CEO escalate**한다.
   - 요청 충족: completion-record를 제출한 뒤 `complete-stage --workflow <wf> --actor OPS-ORCH
     --evidence <completion-record>`로 `run.completed`를 기록한다. `/review-output`이 verification을 연다.
6. wave 종료 시 `python3 .claude/hooks/token_ledger.py dashboard`로 토큰 대시보드(`reports/TOKENS.md`)를 갱신한다(대표가 tokens/wave·cost-per-decision을 눈으로 확인).
7. **결과 보고(Slack) — 스레드 규약(기본).** fan-out wave는 **부모=종합 결정** 1건(`notify_slack.py report <synthesis.report.yaml>`)을 승인 채널에 올리고, **각 워커의 개별 agent-report(템플릿 3)를 그 부모 메시지의 스레드 답글**(`mcp__slack__slack_reply_to_thread`)로 붙인다 — 누가 어떤 판단을 했는지 다 보이되 채널 스팸은 없다. 각 답글은 `직무·렌즈·토큰` 헤더 + BLUF + 근거/산출물 + 결정필요(승인자) + 리스크 + `cc #태그`. collapse wave는 부모 1건만.

## 규칙
- report-header 없는 산출·evidence 없는 confidence:High는 수용 금지(stop_validate/validate_report가 강제 차단).
- fan-out 종합 시 raw-chat-log/tool-trace/secrets/PII는 여전히 배제(`.report.yaml`만 재적재).
- external side-effect(slack/PR/deploy/secret/db-write)는 기본 금지(guard_tools 강제).
- 다음 단계 라우팅은 통합 원장 `progress.next`(=next_family)로만(별도 progress.yaml 폐지 — 하나의 wf-id·하나의 원장).
- **역할 선택은 `role-selection-scorecard.yaml` 기반으로 한다 — Orchestrator 임의 선발 금지.** 선택 근거(candidate-family·rubric·tie-break)를 남긴다.
- **cascade 건너뛰기 금지(`collaboration-map.yaml`).** tier=heavy 전략 결정(신규 제품/수익/방향)은 **DECIDE phase(C-Level 심의 → CEO 종합 ExecutiveDecisionPacket)를 DESIGN 워커보다 먼저** 실행한다. 승인된 Packet을 DESIGN 워커 must-read로 내려보낸다. C-Level은 '아이디어 없을 때 부르는' 예비가 아니라 **방향·트레이드오프를 정하는 결정층**이다.