company-haness/.claude/commands/run-wave.md

description

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은 '아이디어 없을 때 부르는' 예비가 아니라 방향·트레이드오프를 정하는 결정층이다.