collaboration-map:
  version: 1
  purpose: >
    설계→구현 handoff와 그룹 간 협업 엣지를 기계가 읽는 계약으로 인코딩한다.
    "머리 쓰는 일(결정·설계·분석)은 fan-out으로 각자 관점을 남기고, 코드는 collapse로 효율" 원칙의 실행 배선.
  source-of-topology: org-os/00-role-registry/team-topology-map.yaml
  source-of-collaboration-default: org-os/00-role-registry/capability-families.yaml
  cross-references:
    - "execution-policy.yaml (fan-out-collapse-policy, synthesis-rehydration)"
    - "context-package-spec.yaml (must-read 선행조건, report-return-contract)"
    - "state-transition-rules.yaml (설계 승인 전 구현 시작 금지)"

  # ── 캐스케이드: 발견(근거·옵션) → 결정 → 설계 → 세부 → 구현 ─────────────
  # 순서 교정(#7, 사용자 승인): GROUND(discovery, 발산)가 DECIDE(converge, 수렴) 앞에 온다.
  # anchoring 제거 — 하나의 안을 미리 정하지 않고 근거·선택지를 먼저 발산한 뒤 하나로 수렴한다.
  # workflow-stage = state-transition-rules.yaml/execution-plans.yaml 의 통합 stage(엔진이 강제).
  cascade-phases:
    - phase: GROUND
      workflow-stage: discovery
      collaboration: fan-out
      families: [FAM-STRATEGY, FAM-PRODUCT-MGMT, FAM-UX-RESEARCH, FAM-GTM-GROWTH, FAM-REVOPS, FAM-QA]
      each-produces: exact context-package/SHA와 결속된 grounding-contribution(고유 role/lens/run/report)
      synthesized-by: FAM-STRATEGY / STR-ANALYST — discovery synthesis lead
      synthesis-output: grounding-package(source-contributions + tier lens-coverage + option-set≥2) — 결정이 아니라 발산
      input-from: intake decision-brief (ceo-intake) — 결정 packet 이 아니다
      next-input-to: DECIDE
      rule: >
        결정 전에 문제·시장·사용자·경쟁·재무 근거를 먼저 접지하고 선택지(option-set)를 발산한다.
        하나의 안을 미리 정하지 않고 ≥2 옵션을 근거와 함께 남긴다. 수렴(결정)은 다음 DECIDE 가 한다.
        엔진 게이트: discovery→decide 는 grounding-evidence-present + option-set-present(≥2) +
        grounding-lens-coverage-satisfied를 요구한다. standard는 총 5개 렌즈 중 contrarian 1개가 필수이며,
        공개형/신규/대규모는 GTM-CI competitive-market-grounding을 추가로 exact 결속한다.
    - phase: DECIDE
      workflow-stage: decide
      collaboration: fan-out
      families: [FAM-CEO, FAM-CTO, FAM-CPO, FAM-CFO, FAM-COO, FAM-CPTO, FAM-VPENG]
      each-produces: 역할별 판단 보고서(.report.yaml)
      synthesized-by: FAM-CEO
      synthesis-output: ExecutiveDecisionPacket (합의/충돌/근거품질/권고)
      input-from: GROUND grounding-evidence + option-set (근거·선택지를 읽고 하나로 수렴)
      next-input-to: DESIGN
      rule: >
        C-Level 각자 GROUND 의 근거·option-set 을 읽고 렌즈별로 옵션을 평가(divergent) → CEO 가 원본
        전부 읽고 하나로 converge. 하위엔 개별 의견이 아니라 승인된 Packet 을 전달. 근거를 새로 만들지 않는다(그건 GROUND).
    - phase: DESIGN
      workflow-stage: design
      collaboration: fan-out
      families: [FAM-PRODUCT-MGMT, FAM-UX-RESEARCH, FAM-DESIGN, FAM-ARCHITECTURE-TECH, FAM-ARCHITECTURE-BIZ, FAM-DATA, FAM-SECURITY, FAM-STRATEGY]
      each-produces: 역할별 설계·분석 보고서(PRD, RFC/ADR, data-model, threat-model, 분석)
      synthesized-by: FAM-ARCHITECTURE-TECH (기술) / FAM-PRODUCT-MGMT (제품) — 도메인별 lead
      synthesis-output: 큰 설계 문서(overall-design) + 역할별 상세 링크
      next-input-to: DETAIL
      rule: 설계는 하나로 억지 병합하지 않는다. 조금씩 달라도 상위가 원본을 읽고 종합 설계로 수렴.
    - phase: DETAIL
      workflow-stage: spec
      collaboration: fan-out
      families: [FAM-PRODUCT-MGMT, FAM-ARCHITECTURE-TECH, FAM-DATA, FAM-SECURITY]
      each-produces: 컴포넌트별 세부 구현 문서(api-contract, 컴포넌트 스펙, 수용기준)
      synthesized-by: 담당 설계 lead
      next-input-to: BUILD
    - phase: BUILD
      workflow-stage: build
      collaboration: collapse
      families: [FAM-ENG-FRONTEND, FAM-ENG-BACKEND, FAM-ENG-SPECIAL, FAM-PLATFORM-INFRA, FAM-OPS-DELIVERY]
      each-produces: completion-record(구현 결과·검증·handoff)
      reviewed-by: FAM-VPENG / FAM-QA / FAM-SECURITY
      rule: 승인된 설계·세부문서를 must-read로 소비하고 구현. 설계 없이 코딩 시작 금지.

  # ── 설계→구현 계약: 어떤 설계 산출물이 어떤 구현 family의 선행조건인가 ──
  design-to-build-contract:
    rule: build family는 대응 설계 산출물이 Accepted 되기 전 구현을 시작하지 않는다(BlockedReport로 대기).
    # 항목3: /design-system이 산출하는 canonical ui-design은 Accepted만으로 must-read를 충족하지 않는다.
    # preview_ui 렌더 게이트 receipt(evidence-ledger, exit 0, --contrast-only 단독 아님)가 있어야
    # spec→build 의 must-read-designs-accepted 를 충족한다. state_engine._has_preview_receipt 가 강제.
    # 렌더된 적 없는 산문만으로 UI BUILD를 여는 docs-but-no-pixels 구멍을 봉인한다.
    design-system-gate:
      requires: preview_ui-render-receipt   # command=preview_ui.py · exit 0 · not(--contrast-only만)
      artifact-kind: ui-design
      enforced-by: state_engine._has_preview_receipt  # _must_read_unmet 에서 ui-design 특례
      applies-when: workload-profile.surfaces.ui=true
      release-binding:
        source: org-os/08-design/releases/index.yaml
        requires: [release-id, release-ref, release-sha256, component-ids, delta]
        adherence-check: .claude/hooks/lint_design_system_adherence.py
    experience-foundation-gate:
      requires: [competitive-experience-benchmark, experience-strategy, experience-technical-feasibility, experience-operational-feasibility, experience-blueprint, wireframe-set]
      enforced-by: state_engine._has_experience_foundation
      hard-if: "surfaces.ui && (surface-archetype in [public-website, interactive-learning] || experience-change in [new-product, major-redesign])"
      order: "benchmark → CPO strategy + CTO/CPTO technical + COO operational feasibility → IA blueprint → wireframes → design-direction"
      exact-binding: "부모 event가 child와 여섯 accepted artifact id+path+sha256를 모두 결속"
    # preview gate만으로는 /design-system을 거치지 않고 spec/build로 직행하는 우회를 막지 못한다.
    # ui-design은 workflow-contracts의 UI 조건부 bundle 자체에 포함되어 누락도 fail-closed된다.
    # direction-gate 는 그보다 상위(cascade 의 design→spec 전이 자체)에 건다 — UI-bearing
    # standard/heavy 이면 design-direction child 가 approved 되기 전까지 design→spec 자체가 막힌다
    # (state_engine.py 의 design-direction-gate-satisfied 조건, _has_direction_approval 로 검증).
    direction-gate:
      requires: design-direction-approved
      enforced-by: state_engine._has_direction_approval
      applies-to: [FAM-ENG-FRONTEND]
      hard-if: "ui-bearing && tier in [standard, heavy]"
      also-gates: "design->spec 전이(design-direction-gate-satisfied) — /design-system 우회 차단"
    # design-direction 자체 승인은 부모 링크와 `_has_direction_approval`에서 검사하고, 그 결과로 만든
    # approved-design-direction artifact는 UI design bundle의 일반 exact-review 규칙을 따른다.
    mappings:
      - build-family: FAM-ENG-FRONTEND
        must-read-designs: [prd, overall-design, approved-design-direction, ui-design, api-contract]
        design-owners: [FAM-PRODUCT-MGMT, FAM-DESIGN, FAM-ARCHITECTURE-TECH]
      - build-family: FAM-ENG-BACKEND
        must-read-designs: [prd, overall-design, api-contract, data-model, threat-model]
        design-owners: [FAM-PRODUCT-MGMT, FAM-ARCHITECTURE-TECH, FAM-DATA, FAM-SECURITY]
      - build-family: FAM-PLATFORM-INFRA
        must-read-designs: [overall-design, threat-model]
        design-owners: [FAM-ARCHITECTURE-TECH, FAM-SECURITY, FAM-CTO]
      - build-family: FAM-ENG-SPECIAL
        must-read-designs: [prd, overall-design, api-contract]
        design-owners: [FAM-PRODUCT-MGMT, FAM-ARCHITECTURE-TECH]

  # ── 그룹 간 양방향 협업 엣지(플로우차트) ───────────────────────────────
  cross-group-edges:
    rule: 각 엣지는 declared handoff 채널이다. 방향별 handoff-artifact를 명시하고, 미전달 시 해당 작업은 입력 부족으로 Blocked.
    edges:
      - id: demand-product
        a: FAM-GTM-GROWTH
        b: FAM-PRODUCT-MGMT
        a-to-b: "ICP·포지셔닝·캠페인 메시지"
        b-to-a: "제품 가치·로드맵·출시 맥락"
      - id: conversion-build
        a: FAM-REVOPS
        b: FAM-ENG-BACKEND
        a-to-b: "온보딩·PQL·전환 실험 요구"
        b-to-a: "제품 사용 이벤트·한도·계측"
      - id: expansion-product
        a: FAM-GTM-SALES
        b: FAM-PRODUCT-MGMT
        a-to-b: "이탈 위험·기능 채택·확장 신호"
        b-to-a: "개선 계획·릴리스 노트"
      - id: revintel-strategy
        a: FAM-REVOPS
        b: FAM-STRATEGY
        a-to-b: "Forecast·Lead Score·Pipeline Health"
        b-to-a: "시장·비용·사업 가정"
      - id: sales-product
        a: FAM-GTM-SALES
        b: FAM-PRODUCT-MGMT
        a-to-b: "고객 요구·딜 장애물·데모 피드백"
        b-to-a: "가치 제안·기능 범위·FAQ"
      - id: revrisk-sales
        a: FAM-LEGAL
        b: FAM-GTM-SALES
        a-to-b: "가격·계약·컴플라이언스 제약"
        b-to-a: "할인·MSA·보안 요구"

  # ── 리뷰/수용 게이트(플로우차트 하단) ─────────────────────────────────
  acceptance-gates:
    - gate: Pre-Implementation Gate
      checks: [output-contract, evidence, risk, blocker]
      applies-before: BUILD
    - gate: GTM Revenue Check
      when: revenue/GTM/lead-to-cash 영향
      checks: [PLG-PLS-SLG-motion, pipeline, NRR, pricing, compliance, handoff]
    - gate: Platform·SRE·Security Check
      when: golden-path/SLO/shift-left 영향
      checks: [golden-path, SLO, shift-left-security]
    - gate: Parent Review / Acceptance
      outcomes: [Accepted, Changes-Requested, Blocked, Escalated]
      on-accepted: 다음 역할 handoff 또는 ExecutiveDecisionPacket 반영
      on-escalated: FAM-CEO