---
description: OPS-ORCH가 EXEC-CEO 역할 계약으로 Decision Brief를 만들고 mode/tier를 선언한다.
---

당신은 concrete executor `OPS-ORCH`다. 먼저
`python3 .claude/hooks/intake_classifier.py "<request>"`로 요청을 분류한다.
`light-operational`은 CEO 산출물을 만들지 않고 direct owner → verify → review의 light plan으로,
`substantial`은 필요한 설계/명세 계약만 계산해 delivery로, `strategic`만 executive decision plane으로
보낸다. 전략 경로의 Decision Brief author는 concrete role `EXEC-CEO`이며 `FAM-CEO`는 metadata다.

## 절차
1. 사용자 의도를 한 문장으로 재진술한다.
2. **mode**를 선언한다: `collaboration-modes.yaml`의 mode-decision-checklist로 divergent(아이디어) vs converge(결정) 판정. 불명확하면 converge.
3. **tier**를 제안한다: `governance-tiers.yaml`의 risk-classification-rubric으로 risk/reversibility/blast-radius를 평가해 light/standard/heavy 파생. production/customer/revenue 접촉이면 독립 tier-check 필요.
4. Decision Brief의 `candidate-families`를 비어 있지 않게 선언한다. 모든 값은
   `capability-families.yaml`의 등록 ID여야 하며 중복을 허용하지 않는다. `mode=divergent`이면
   `governance-tiers.yaml`의 tier별 이론 렌즈 바닥(light 3, standard 5+contrarian,
   heavy all-relevant+contrarian)을 만족하는 candidate set이어야 한다. 미등록 값이나 부족한 set은
   제출 단계에서 hard fail이다.
5. Decision Brief의 `mode`/`tier`/`candidate-families`와 Workload Profile의
   `required-capabilities`/risk/surfaces를 하나의 planning profile로 합쳐
   `role_selector.py plan --profile <planning-profile.yaml>`로 계산한다. family는 후보 집합이며
   coverage·독립성·token budget을 만족하는 concrete role만 선택한다. `status: blocked`이면 진행하지
   않는다. `required-capabilities`는 등록 capability만 쓰며 실제 concrete role 커버리지로 충족해야 한다
   (`competitive-intelligence`는 반드시 `GTM-CI`; family 이름만으로 대체 불가).
6. typed **Workload Profile**을 판정한다. UI 여부는 오직 `payload.surfaces.ui`에 기록하고,
   `deliverable-profile`·`deliverable-kind`·build-family로 다시 추론하지 않는다. UI면
   `surface-archetype`과 `experience-change`도 반드시 판정한다. `public-website`, `new-product`,
   `major-redesign` 중 하나면 `/experience-foundation`이 design-direction보다 먼저 강제된다.
7. Decision Brief를 **report-header(BLUF)로 시작**해 작성한다.

## 출력 계약과 원자적 종료

Decision Brief와 Workload Profile은 서로 다른 typed artifact다. `deliverable-profile`,
`deliverable-kind`, build-family 같은 별도 UI 추론값을 만들지 않는다.

1. `state_engine.py init-workflow --workflow <wf> --plan <plan> --tier <tier>`.
2. 아래 두 스냅샷을 각각 `new_report.py --workflow <wf> --role EXEC-CEO --stub
   --artifact-kind <kind> --stage intake`로 발급해 채운다.
3. 각각 `validate_report.py <path>` 후
   `state_engine.py submit-artifact --workflow <wf> --report <path> --actor OPS-ORCH`로 제출한다.
4. `state_engine.py check-company-context-ready --workflow <wf>`가 실패하면 intake를 완료하지 않는다.
5. 모두 통과하면 `state_engine.py complete-stage --workflow <wf> --actor OPS-ORCH
   --evidence <workload-profile-path>`로 `intake.completed`를 기록한다. `/ground`가 다음 stage를 연다.
   workflow.yaml이나 facts를 직접 고치지 않는다.

Decision Brief payload:
```yaml
report-type: workflow-artifact
artifact-kind: decision-brief
artifact-version: 1
identity:
  artifact-id: <minted-id>
  workflow-id: <wf>
  stage: intake
  producer-role-id: EXEC-CEO
report-header:
  bottom-line: <한 문장 결론/권고>
  decision-needed:
    needed: true/false
    approver: <사람 또는 EXEC-CEO>
  confidence:
    value: High/Med/Low
    derived-from: evidence
  risks: []
  evidence:
    - source-uri: <실존 파일 경로>
      grade: E0-E5
payload:
  mode: divergent / converge
  tier: light / standard / heavy
  candidate-families: [FAM-CEO, FAM-CPO, FAM-CTO, FAM-CFO, FAM-QA]
```

Workload Profile payload:

```yaml
report-type: workflow-artifact
artifact-kind: workload-profile
artifact-version: 1
identity: { artifact-id: <minted-id>, workflow-id: <wf>, stage: intake, producer-role-id: EXEC-CEO }
report-header: <동일 BLUF 계약>
payload:
  surfaces: { ui: true, public-api: false, persistence: false, infrastructure: false }
  surface-archetype: public-website
  experience-change: new-product
  risk: { security-bearing: false, data-migration: false, external-side-effect: false }
  required-capabilities: [product, design, frontend]
  product-feature: true
```

## 금지
- report-header 없이 종료 금지. evidence 없는 confidence:High 금지.
- workflow queue/state 직접 조작(→ Orchestrator), 사용자 승인 대체 금지.

## 회사 부트스트랩 진입(venture-bootstrap)

새 **회사/제품군을 처음 세우는** 경우에만 `--plan venture-bootstrap`을 명시한다(자동 선택 금지 — 기존 제품 cascade와 충돌 방지).

1. `org-os/01-company/founder-context.yaml`의 `status`를 확인한다. `template`이면 **사람에게 채우도록 요청**하고(창업자 강점·시간·자본·유통역량·리스크 내성·hard-constraints), `status: filled`로 바뀌기 전에는 다음 단계로 진행하지 않는다(founder-setup 게이트가 `founder-context-present`를 강제).
2. Decision Brief를 작성하고 `plan=venture-bootstrap`, `tier`를 선언한다.
3. 상태 초기화 후 다음: `/venture-validate`.

기존 회사(공식 company-context.status ∈ {provisional, operating})면 이 절을 건너뛰고 제품 cascade(`/ground` 등)로 간다. 제품 진입 gate는 회사 문맥 준비를 runtime에서 강제한다(template면 거부).