company-haness/.claude/commands/ceo-intake.md

description

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:

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:

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면 거부).