init: company-haness 설계

2026-07-23 17:49:00 +09:00
parent 57d1bab894
commit f668d6a158
962 changed files with 98989 additions and 1 deletions
@@ -0,0 +1,527 @@
+# P1 — Company / Venture Bootstrap (설계)
+
+- 날짜: 2026-07-12
+- 상태: 설계 확정 대기 → (승인 후) 구현 계획(writing-plans)
+- 범위: 리뷰 반영 로드맵의 **P1**. 리뷰 핵심결함 #1(회사를 정의하기 전에 회사 문맥을 요구하는 순환의존) 해소.
+- 관련: 리뷰 로드맵의 P0(실행 무결성, 대부분 완료·재검증)·P2(디자인 방향)·P3(프롬프트/스킬 분리)·P4(벤치마크)는 **별도 사이클**. 본 스펙은 P1만 다룬다.
+
+---
+
+## 1. 문제 (순환의존)
+
+현재 cascade는 `intake → discovery → decide → design → spec → build → …`이며, `/ground`·`/decide`·`/design`은 이미 회사 방향·제품 제약(`company-context.yaml`)을 전제한다. 그런데 `company-context.yaml`은 `status: demo`(빈 템플릿)이고 `projects: []`다. 즉:
+
+```
+아이디어를 고르려면 회사의 전략·제약이 필요함
+                ↑
+회사 전략을 정하려면 아이디어를 먼저 골라야 함
+```
+
+지금은 이 공백을 매 intake 문장과 임시 가정으로 메우므로 아이디어 검토 결과가 일관되지 않는다.
+
+**해소 원리:** `founder-context`(회사 정의 이전에도 사람이 채울 수 있는 유일한 입력)를 **입력**으로 하는 별도 `venture-bootstrap` plan을 두고, 그 plan의 **terminal 산출물**로 `company-context.yaml (status: provisional)`을 **생산**한다. 이후 제품 cascade는 그 산출물을 **입력으로 소비**만 한다. bootstrap 내부에서는 company-context를 요구하지 않으므로 순환이 끊긴다.
+
+## 2. 목표 / 비목표
+
+**목표**
+- 회사 lifecycle(1회성 수립)과 제품 lifecycle(반복)을 **별도 plan**으로 분리한다.
+- `founder-context.yaml`(사람 입력) → 기회탐색 → 벤처검증 → 벤처결정 → company-context commit의 강제된 stage 그래프를 만든다.
+- `company-context.yaml`을 **항목별 provenance**를 갖는 facts / strategic-decisions / hypotheses 구조로 재편하고, 공식 SoT 상태 어휘를 `template|provisional|operating`(3-상태)로 교체한다(작성 중은 공식 status가 아니라 candidate-status/workflow stage로 표현 — §7.3).
+- 회사 문맥 인용 상한을 **항목 단위**로 정밀화하되(전체 보고서 강등 금지), 신뢰경계(worker는 전이 불가)와 원자적 commit을 지킨다.
+- 제품 cascade가 bootstrap 결과를 정확히 참조할 **진입 계약**을 정의한다(단, product-definition stage 자체는 P1에서 만들지 않는다).
+
+**비목표(YAGNI / 이후 사이클)**
+- `product-definition` stage 신설 — 제품 lifecycle 소관. seam(진입 계약)만 정의.
+- 보고서별 **완전 citation-provenance 추적**(모든 보고서에서 인용 출처를 파싱해 항목별 ceiling) — 최소 형태(회사 문맥을 evidence로 포함한 보고서에만, hypothesis 인용은 Med 상한)만 구현.
+- 자연어 **의미 기반** hypothesis-as-fact 오분류 판정 — Hard Fail이 아니라 Warning.
+- DES-VISUAL/DES-DIRECTOR·디자인 단계(P2), skill 분리(P3), 벤치마크(P4).
+
+---
+
+## 3. 아키텍처 개요 — 두 lifecycle과 seam
+
+```
+Company lifecycle (1회성, plan=venture-bootstrap)
+  founder-context.yaml (사람)
+    → opportunity-discovery
+    → venture-validation
+    → venture-decision (+ HUMAN acceptance receipt)
+    → company-context-commit (candidate → atomic replace)
+    → bootstrap-complete   ⇒ 공식 company-context.yaml (status: provisional)
+
+        │  seam = company-context-ready 진입 계약
+        ▼
+
+Product lifecycle (반복, plan=cascade)
+  selected venture → (product-definition) → design → spec → build → …
+  ↑ company-context.yaml + venture-decision-id + company-decision-ids 를 입력으로 참조
+```
+
+핵심: 공식 `company-context.yaml`(SoT)은 bootstrap **도중에는 바뀌지 않는다**. candidate 파일에 작성·검증한 뒤, 마지막에 **한 번, 원자적으로** 교체한다(§9.3).
+
+---
+
+## 4. 신규/변경 아티팩트 인벤토리
+
+| 파일 | 위치 | 성격 | 변경 |
+|---|---|---|---|
+| `founder-context.yaml` | `org-os/01-company/` | 사람 입력 | 신규 |
+| `venture-option-spec.yaml` | `org-os/06-agent-work/` | 데이터 스키마 계약 | 신규 |
+| `venture-validation-map.yaml` | `org-os/06-agent-work/` | 역할·게이트 매핑 계약 | 신규 |
+| `company-context.yaml` | `org-os/01-company/` | 회사 SoT | **재구조화** |
+| `state-transition-rules.yaml` | `org-os/00-role-registry/` | 전이 SSOT | venture-bootstrap 전이·조건 추가 |
+| `execution-plans.yaml` | `org-os/06-agent-work/` | plan 프리셋 | `venture-bootstrap` plan 추가 |
+| `ceo-intake.md` | `.claude/commands/` | 커맨드 | `--plan` 선택·founder-context 유도 |
+| `venture-validate.md` | `.claude/commands/` | 커맨드 | 신규 |
+| `company-bootstrap.md` | `.claude/commands/` | 커맨드 | 신규 |
+| `state_engine.py` | `.claude/hooks/` | 전이 강제기 | 신규 predicate 6종 |
+| `validate_report.py` | `.claude/hooks/` | 보고 검증 | status 어휘 + 항목 ceiling |
+| `lint_company_context.py` | `.claude/hooks/` | 파일 린터 | 신규(Hard Fail + Warning) |
+| `commit_company_context.py` | `.claude/hooks/` | trusted commit CLI | 신규(atomic replace) |
+| `acceptance_log.py` / `acceptance-event.schema.json` | `.claude/hooks/`·`schemas/` | 수락 원장 | 선택 `report-sha256` 바인딩 추가 |
+| `guard_tools.py` | `.claude/hooks/` | 권한 경계 | 공식 company-context.yaml 직접쓰기 보호 |
+| `doctor.py` | `.claude/hooks/` | preflight | 신규 아티팩트·plan 배선 점검 |
+| 테스트 | `.claude/tests/` | 단위테스트 | `test_venture_bootstrap.py`(신규) 외 |
+
+---
+
+## 5. `founder-context.yaml` (사람 입력)
+
+회사 정의 이전에도 사람이 채울 수 있는 유일 입력. **여러 venture validation에서 재사용**되며, 누락되면 founder-fit 판단 전체가 무효 → 독립 stage(`founder-setup`)의 게이팅 아티팩트.
+
+```yaml
+schema-version: 1
+status: template            # template | filled
+founder:
+  strengths: [backend, database, infrastructure]
+  available-time: ""        # 예: "solo, 주 50h"
+  available-capital: ""
+  desired-business-size: ""  # 예: "$1-5M ARR, solo-operable"
+  preferred-market: ""
+  distribution-capability: ""  # self-serve? community? outbound?
+  sales-tolerance: ""        # low|med|high
+  operation-tolerance: ""
+  risk-tolerance: ""
+  hard-constraints:
+    - solo-operable
+    - self-serve-distribution
+    - no-enterprise-sales-dependency
+  strategic-preferences:
+    - recurring-revenue
+    - technical-moat
+    - global-developer-market
+```
+
+- 위치: `org-os/01-company/founder-context.yaml`(회사 SoT 옆).
+- `status: filled`이어야 `founder-setup → opportunity-discovery` 통과.
+- 비밀/키는 두지 않는다(company-context와 동일 정책).
+
+---
+
+## 6. 벤처 계약 — 두 파일로 분리 (리뷰 #8)
+
+스키마(산출물 구조)와 역할 매핑(협업 방식)은 변경 이유가 달라 분리한다.
+
+### 6.1 `venture-option-spec.yaml` (데이터 스키마)
+
+```yaml
+venture-option-spec:
+  version: 1
+  opportunity-cluster:      # opportunity-discovery 산출(제품명 이전, 문제 클러스터)
+    required: [id, problem-domain, target-user, triggering-event,
+               current-alternative, why-now, founder-fit]
+  venture-option:           # venture-validation 산출(옵션별)
+    required: [id, customer, painful-job, current-alternative, wedge,
+               monetization, expected-price, reachable-customers,
+               rough-revenue-ceiling, acquisition-channel, build-cost,
+               operation-cost, founder-fit, defensibility, kill-criteria,
+               unresolved-assumptions]
+    notes:
+      - "unknown 은 허용값이다(모른다고 적을 수 있어야 한다) — 단 unresolved-assumptions 에 명시."
+      - "kill-criteria 는 필수(없으면 venture-validation→venture-decision 차단)."
+  validation-result:        # 게이트별 판정 스냅샷
+    required: [option-id, gate, verdict, evidence, dissent]
+    verdict-enum: [pass, fail, unknown]
+```
+
+### 6.2 `venture-validation-map.yaml` (역할·게이트 매핑) — 리뷰 역할 보강 반영
+
+9-게이트를 **CFO 1인이 대신할 수 없으므로**(가격/WTP/유통/획득/기술해자/운영) 역할을 보강한다. 각 게이트는 primary(작성) + contrarian/auditor(반증) + synthesis-owner를 가진다. 렌즈 다양성·이해상충 방지(작성자≠감사자).
+
+| Gate | Primary | Contrarian/Auditor |
+|---|---|---|
+| 문제 강도·빈도 | UX-RESEARCHER | PROD-PM |
+| 경쟁·대체재 | GTM-CI | STR-ANALYST |
+| 지불 의사(WTP) | GTM-PRICING | CFO |
+| 매출모델·단위경제 | CFO · GTM-REVOPS | GTM-PRICING |
+| 기술 가능성·해자 | (CTO) ARCH-TECH | CFO |
+| 운영 가능성 | (COO) CONSULT-OPS | ARCH-TECH |
+| 유통 가능성 | GTM-GROWTHPM · GTM-SALES | CFO |
+| 창업자 적합성 | EXEC-CEO | ARCH-TECH |
+| 실패·중단 기준 | CFO | EXEC-CEO |
+
+```yaml
+venture-validation-map:
+  version: 1
+  synthesis-owner: EXEC-CEO      # 종합(수렴)은 CEO, 최종 선택은 사람
+  gates:
+    - { gate: problem-intensity, primary: [UX-RESEARCHER], auditor: [PROD-PM] }
+    - { gate: competition-alternatives, primary: [GTM-CI], auditor: [STR-ANALYST] }
+    - { gate: willingness-to-pay, primary: [GTM-PRICING], auditor: [CFO] }
+    - { gate: revenue-unit-economics, primary: [CFO, GTM-REVOPS], auditor: [GTM-PRICING] }
+    - { gate: tech-feasibility-moat, primary: [ARCH-TECH], auditor: [CFO] }
+    - { gate: operability, primary: [CONSULT-OPS], auditor: [ARCH-TECH] }
+    - { gate: distribution, primary: [GTM-GROWTHPM, GTM-SALES], auditor: [CFO] }
+    - { gate: founder-fit, primary: [EXEC-CEO], auditor: [ARCH-TECH] }
+    - { gate: kill-criteria, primary: [CFO], auditor: [EXEC-CEO] }
+  opportunity-discovery-roles:   # 기회탐색(발산) 참여 역할
+    diverge: [EXEC-CEO, FAM-CPO, STR-ANALYST, PROD-PM, UX-RESEARCHER, GTM-PMM]
+    contrarian: [CFO]            # 왜 실패하는가 — 초기 아이디어의 경제구조 반증
+```
+
+> **CFO의 위치(리뷰 강조):** CFO는 "마지막에 돈이 되는지 확인"이 아니라 **초기 아이디어의 경제구조를 반증**하는 역할로 opportunity-discovery부터 contrarian으로 참여한다.
+
+> 파일을 늘리기 싫으면 한 파일 두 섹션으로 둘 수 있으나, 본 스펙은 변경축 분리를 위해 2파일을 채택한다.
+
+---
+
+## 7. `company-context.yaml` 재구조화 — 항목별 provenance (리뷰 #1)
+
+### 7.1 왜 블록 단위 evidence-cap을 제거하는가
+
+`fact/decision/hypothesis`는 **정보의 종류**이고 `E1~E5`는 **증거의 강도**다. 둘은 독립이다. 창업자 자가입력 사실은 fact지만 E1~E2일 수 있고, 코드 실행으로 확인한 스택은 fact이며 E4~E5일 수 있다. 전략 결정은 "E3 증거"가 아니라 **HUMAN 권한**으로 유효해진다. 따라서 블록 cap을 제거하고 **항목별 provenance**를 둔다.
+
+### 7.2 구조
+
+```yaml
+schema-version: 2
+status: provisional          # 공식 SoT는 3-상태만: template | provisional | operating  (bootstrap 아님)
+company:
+  facts:
+    - id: FACT-001
+      statement: "창업자는 백엔드·인프라 개발 역량을 보유한다."
+      category: founder-capability
+      provenance:
+        - { source-uri: org-os/01-company/founder-context.yaml, grade: E2 }
+      verified-at: "2026-07-12"
+      status: active          # active | retired
+  strategic-decisions:
+    - id: DEC-001
+      statement: "초기 고객은 소규모 백엔드·DB 운영팀으로 한정한다."
+      decision-type: target-market
+      accepted-by: HUMAN-001
+      accepted-at: "2026-07-12"
+      source-decision-id: VD-001          # venture-decision report 계보
+      supporting-evidence:
+        - { source-uri: completion-records/<wf>/exec-packet-*.report.yaml, grade: E2 }
+      status: active
+  hypotheses:
+    - id: HYP-001
+      statement: "대상 고객은 월 $79 이상 지불 의사가 있다."
+      hypothesis-type: willingness-to-pay
+      confidence: Med
+      validation-status: untested         # untested | validated | refuted
+      evidence:
+        - { source-uri: completion-records/<wf>/pricing-*.report.yaml, grade: E2 }
+      promotion-criteria: ["유료 사전판매 5+"]
+      falsification-criteria: ["2주 랜딩 유료전환 < 1%"]
+  validation-state:
+    stage: pre-traction
+    validated: []
+    open: [HYP-001]
+    refuted: []
+projects: []                 # 기존 유지(제품 lifecycle 소관)
+```
+
+- 단일 `decision-provenance` 객체 **제거** — 결정은 여러 개 누적되므로 **각 decision이 자기 provenance**(accepted-by/accepted-at/source-decision-id/supporting-evidence)를 갖는다.
+- `schema-version: 1 → 2`. 기존 `company:` 블록(자유서술)은 마이그레이션 시 facts/decisions로 이전하거나 보존(§12).
+
+### 7.3 상태 어휘 — 공식 SoT는 3-상태만
+
+**공식 `company-context.yaml`의 `status`는 다음 3개만 가진다.** `bootstrap`은 공식 SoT 상태가 **아니다**(중간·모호 상태 방지 — 리뷰 2차 반영).
+
+```
+공식 SoT status:
+  template    : 초기(빈) — 회사 미정의
+  provisional : bootstrap 산출. 결정은 유효, 시장 가설은 검증 상태에 종속
+  operating   : 실검증·실운영 데이터로 승격(operating 승격 acceptance event 필요)
+
+공식 SoT 상태 전이(§9.3):
+  template  ──(atomic commit)──▶  provisional  ──(human-approved promotion)──▶  operating
+```
+
+"작성 중인 bootstrap"은 **공식 status로 표현하지 않는다**. 두 가지로만 표현한다:
+- **candidate 파일**의 별도 필드 `candidate-status: bootstrap`(공식 `status` 필드와 분리 — §9.3), 그리고
+- **workflow stage** `company-context-commit`(진행 중).
+
+이로써 "공식 status=bootstrap인데 candidate인가? commit 중인가? cascade가 읽어도 되나?" 같은 애매한 상태가 원천 차단된다. 제품 cascade는 공식 status가 `provisional|operating`일 때만 읽는다(§11).
+
+`demo/populated`(구 어휘)는 **읽기 호환 + deprecation warning + 일회성 migration**으로 처리(영구 별칭 아님, §12: demo→template, populated→operating).
+
+---
+
+## 8. 상태머신 — `venture-bootstrap` plan (리뷰 #4, #5)
+
+### 8.1 stage 그래프 (terminal 이전에 commit·lint 전이 존재)
+
+`company-bootstrap`에 "진입하는 순간 terminal 도달" 문제를 피하기 위해 commit과 완료를 분리한다.
+
+```yaml
+# execution-plans.yaml
+plans:
+  venture-bootstrap:
+    description: >
+      회사 수립(1회성). founder-context 를 입력으로 기회탐색→벤처검증→벤처결정→
+      company-context commit 을 거쳐 company-context.yaml(provisional) 을 산출한다.
+      제품 cascade 의 선행이며 별도 lifecycle 이다.
+    stages: [intake, founder-setup, opportunity-discovery, venture-validation,
+             venture-decision, company-context-commit, bootstrap-complete]
+    terminal-stage: bootstrap-complete
+    default-tier: standard
+    outputs: "org-os/01-company/company-context.yaml (status: provisional)"
+```
+
+### 8.2 전이·조건 (state-transition-rules.yaml `workflow-stage-transitions`에 추가)
+
+전이 **집행 주체는 OPS-ORCH(trusted) 단독**. C-Level·전문역할은 intake·결정·추천 **보고서만** 생산하고 상태 원장을 직접 전이하지 않는다(리뷰 #5·2차 반영, 기존 신뢰경계와 정합). `-role-agent` placeholder와 `EXEC-CEO`를 allowed-by에서 **전부 제거**해 worker/C-Level-authored 전이 경로를 원천 차단한다 — venture-bootstrap의 **모든** 전이는 `allowed-by: [OPS-ORCH]`로 통일한다.
+
+| 전이 | allowed-by | required-conditions(신규 predicate) |
+|---|---|---|
+| intake → founder-setup | `[OPS-ORCH]` | `decision-brief-present` |
+| founder-setup → opportunity-discovery | `[OPS-ORCH]` | `founder-context-present` |
+| opportunity-discovery → venture-validation | `[OPS-ORCH]` | `opportunity-clusters-present`(≥2) |
+| venture-validation → venture-decision | `[OPS-ORCH]` | `venture-options-validated` |
+| venture-decision → company-context-commit | `[OPS-ORCH]` | `venture-decision-accepted` + `human-acceptance-receipt-present` |
+| company-context-commit → bootstrap-complete | `[OPS-ORCH]` | `company-context-provisional-committed` + `company-context-lint-passed` + `company-context-artifact-recorded` |
+
+> `EXEC-CEO`는 intake 보고서(decision-brief)·venture-decision 종합을 **생산**할 수 있지만, 그 산출물을 근거로 stage를 전이하는 것은 OPS-ORCH다. (기존 cascade 일부 전이는 `[OPS-ORCH, discovery-role-agent]`처럼 placeholder를 병기하지만 — 실제 집행자는 항상 OPS-ORCH이고 엔진이 `EXEC-CEO` actor를 거부함 — venture-bootstrap은 그 잠재 경로마저 없애기 위해 OPS-ORCH 단독으로 못박는다.)
+
+이 분리 덕에 "결정은 승인됐지만 company-context 쓰기·검증은 실패" 상태를 정확히 표현·재개할 수 있다.
+
+### 8.3 신규 condition-catalog (state_engine.py가 원장 사실로 평가)
+
+```yaml
+condition-catalog:
+  founder-context-present: "org-os/01-company/founder-context.yaml status=filled"
+  opportunity-clusters-present: "opportunity-cluster 산출 ≥ 2 (ledger.artifacts/보고서)"
+  venture-options-validated: "각 venture-option 이 venture-option-spec required 필드 충족 + kill-criteria 존재 + 9-gate 결과 present"
+  venture-decision-accepted: "venture-decision 보고서 존재 + validate_report 통과 + acceptance_log accepted 이벤트(=report-id·workflow-id 바인딩)"
+  human-acceptance-receipt-present: "HUMAN-001 acceptance 이벤트가 그 venture-decision report-id/hash/workflow-id 에 바인딩(§9.4)"
+  company-context-provisional-committed: "공식 company-context.yaml status=provisional 로 원자적 교체 완료(commit_company_context receipt)"
+  company-context-lint-passed: "lint_company_context Hard Fail 0 (candidate 및 최종)"
+  company-context-artifact-recorded: "commit receipt 가 evidence-ledger/통합원장에 기록됨"
+```
+
+### 8.4 human-gate는 boolean이 아니라 바인딩된 receipt (리뷰 #5)
+
+`human_gate_approved: true` 단일 boolean 금지. `venture-decision-accepted`+`human-acceptance-receipt-present`는 다음을 모두 요구:
+1. venture-decision report 존재, 2. `validate_report` 통과, 3. `HUMAN-001` acceptance 이벤트 존재, 4. 이벤트가 **동일 report-id + report-sha256 + workflow-id**에 바인딩. (report-sha256 바인딩은 acceptance-event에 추가하는 신규 필드 — §9.4.)
+
+---
+
+## 9. 강제기 (hook / validator)
+
+### 9.1 `validate_report` — 항목 단위 상한 (리뷰 #2, 자기수정 포함)
+
+**정정:** 기존 코드는 이미 **항목 단위**로 동작한다. [validate_report.py:474-480](.claude/hooks/validate_report.py#L474-L480)의 `_is_unpopulated_company_ref(source-uri)`는 **개별 evidence 항목의 source-uri가 회사 네임스페이스를 가리키고 status != populated일 때 그 항목만** E2로 상한한다(외부·코드·테스트 증거는 원래 등급 유지). 전체 보고서 강등이 아니다. 따라서 리뷰 #2의 우려(전역 강등)는 **기존 구현엔 없으며**, 변경은 아래 두 가지로 한정한다:
+
+1. **상태 어휘 확장:** `_company_context_populated()` → 공식 status가 `operating`일 때만 상한 해제. `template/provisional`(및 구 `demo`)은 회사 네임스페이스 인용을 계속 E2/Med 상한. 구 `populated`는 `operating`으로 읽기 호환. (공식 SoT에 `bootstrap`은 존재하지 않으므로 처리 대상 아님 — §7.3.)
+2. **hypothesis 항목 ceiling(신규 최소구현):** 회사 문맥 인용의 `source-uri`가 특정 항목(`company-context.yaml#HYP-001` 형태 anchor)을 가리키면:
+   - `hypotheses` 항목 → 회사별 결론 **confidence ≤ Med**, grade ≤ E2 (검증 상태 무관하게 가설 기반).
+   - `facts`/`strategic-decisions` 항목(provenance 有) → 항목 provenance grade까지 허용(단 status=operating 또는 결정은 결정으로서 유효).
+   - anchor 미지정(파일 전체 인용) → 기존 네임스페이스 상한(coarse).
+3. **불변:** 외부 E3/E4/E5(코드 실행·테스트·외부 조사)는 회사 status와 **독립**으로 원등급 유지.
+
+### 9.2 `lint_company_context.py` — 구조는 Hard Fail, 의미는 Warning (리뷰 #3)
+
+자연어 의미로 "이건 가설인데 fact로 위장"을 정적 판정하는 것은 오탐·누락이 크다 → **Warning**. 구조·참조·권한·상태 정합만 **Hard Fail**.
+
+**Hard Fail**
+- 항목 ID 누락 / 중복 ID
+- 공식 파일의 `status`가 `template|provisional|operating`(3-상태) 밖 — 특히 공식 파일에 `status: bootstrap`이면 Hard Fail(§7.3)
+- 항목 `status`가 허용값 밖
+- candidate 파일이 아닌데 `candidate-status` 필드가 존재(또는 공식 파일에 `candidate-status: bootstrap`이 남아있음)
+- `fact`의 provenance 누락
+- `decision`의 `accepted-by`/`accepted-at`/`source-decision-id` 누락
+- `hypothesis`의 `validation-status`/`confidence`/`falsification-criteria` 누락
+- hypothesis ID를 fact reference 자리에 사용
+- 존재하지 않는 evidence 경로(source-uri)
+- `provisional`인데 human 승인 decision이 하나도 없음
+- `operating`인데 operating 승격 acceptance event 부재
+
+**Warning**
+- fact 문장이 추정 표현("~일 것", "예상") 포함
+- hypothesis와 fact 내용이 의미상 중복 의심
+- 시장 규모·WTP가 fact에 들어간 것으로 의심
+- 장기 미검증 hypothesis(오래된 verified/updated 없음)
+- provenance는 있으나 근거 내용이 주장과 약하게 연결
+
+- candidate 파일(§9.3)과 최종 파일 **둘 다** 검증 가능해야 한다.
+- `run_all.py`·`doctor.py`에 배선. 구 `demo/populated`는 읽기 호환하되 **deprecation warning** 발생.
+
+### 9.3 `commit_company_context.py` — candidate → 원자적 교체 (리뷰 #6)
+
+bootstrap 도중 공식 SoT를 수정하면 중간 상태를 제품 cascade가 소비할 위험이 있다. 따라서:
+
+```
+공식 company-context.yaml (status: template)   ← bootstrap 동안 불변, 공식 status에 bootstrap 없음
+        │
+candidate 생성:
+  <workspace>/completion-records/<workflow-id>/company-context.candidate.yaml
+    · status: provisional          # 최종 목표 상태(공식 3-상태 중 하나)
+    · candidate-status: bootstrap   # candidate임을 표시하는 별도 필드(공식 파일엔 없음)
+        ↓ schema validation
+        ↓ lint_company_context (Hard Fail 0; candidate-status:bootstrap 허용은 candidate에 한함)
+        ↓ venture-decision + human acceptance receipt 검증(바인딩)
+        ↓ trusted commit: candidate-status 필드 제거 → 임시파일 write → os.replace() 원자 교체
+공식 company-context.yaml (status: provisional)   ← candidate-status 없음
+```
+
+- `commit_company_context.py`는 **trusted CLI**(OPS-ORCH가 실행). 위 게이트를 모두 통과할 때만 `candidate-status`를 벗겨 `os.replace()`로 교체. 실패 시 기존 파일 **무변경**.
+- 공식 SoT는 `template → provisional → operating` 3-상태만 실질 사용(§7.3). "작성 중"은 공식 status가 아니라 **candidate 파일의 `candidate-status: bootstrap`** 및 **workflow stage `company-context-commit`**으로만 표현한다.
+- commit은 `evidence-ledger`/통합원장에 receipt를 남긴다(`company-context-artifact-recorded`).
+
+### 9.4 `acceptance_log` / `acceptance-event.schema.json` — 해시 바인딩 추가 (리뷰 #5, tests #3/#4)
+
+현재 이벤트는 report-id + workflow-id + 실존(`_resolve_report_path`, ghost-acceptance 차단)만 바인딩하고 **content hash는 없다**. venture-decision human-gate의 위조·재사용을 막기 위해 **선택적 `report-sha256`** 필드를 추가(스키마 `additionalProperties: true`라 additive):
+
+- `acceptance_log.py append ... --report-sha256 <hash>` 지원.
+- `human-acceptance-receipt-present` predicate는 acceptance 이벤트의 `report-sha256`가 **현재 venture-decision 파일의 해시와 일치**하고 `workflow-id`가 같을 때만 통과. 불일치(결정 변경/타 workflow 재사용) → 거부.
+
+### 9.5 `guard_tools.py` — 공식 SoT 직접쓰기 보호
+
+공식 `org-os/01-company/company-context.yaml`은 fan-out worker/일반 Edit·Write로 **직접 수정 금지**. `commit_company_context.py`(trusted) 경로로만 교체. `founder-context.yaml`은 사람 입력이므로 별도(사람이 편집; worker 쓰기는 금지).
+
+---
+
+## 10. 커맨드 (리뷰 #7, #9)
+
+기존 fan-out(divergent)·converge 인프라 위 **얇은 드라이버**. `/decide` **명령**을 호출하지 않고 공통 **converge contract**(collaboration-modes.yaml)를 재사용한다.
+
+### 10.1 `/ceo-intake` (보강)
+- `--plan venture-bootstrap` 명시로만 회사 부트스트랩 선택(자동 선택 금지 — 기존 제품 cascade와 충돌 방지).
+- founder-context가 `template`이면 사람에게 채우도록 유도(또는 `/venture-validate` 진입 시 상태 확인해 founder-setup으로 유도).
+
+### 10.2 `/venture-validate` (신규)
+- **opportunity-discovery(발산):** `venture-validation-map.opportunity-discovery-roles`로 fan-out → opportunity-cluster ≥2(중복·완전성 검사). 제품명 이전, 문제 클러스터부터.
+- **venture-validation:** option별 9-gate fan-out(primary/auditor, dissent 보존). `unknown` 허용, `kill-criteria` 필수. 산출 = validation-result + venture-option 보고서.
+- 진입 시 `state_engine guard`, 종료 시 OPS-ORCH가 `transition`(worker 아님).
+
+### 10.3 `/company-bootstrap` (신규)
+- **venture-decision(수렴):** 공통 converge contract로 C-Level 독립 평가(CPO·CFO·CTO·COO·CPTO) → CEO synthesis(dissent 보존) → **ExecutiveDecisionPacket** 산출.
+- **HUMAN acceptance:** 사람이 하나를 선택 → `acceptance_log append`(report-id + report-sha256 + workflow-id 바인딩).
+- **company-context-commit:** candidate 생성 → schema/lint/acceptance 검증 → `commit_company_context.py`로 원자적 교체(§9.3).
+- 모든 stage 전이는 OPS-ORCH가 집행.
+
+### 10.4 공통 converge contract의 위치
+재사용 단위는 slash command가 아니라 다음 중 하나로 둔다(구현 계획에서 택1):
+- `collaboration-modes.yaml`의 `converge` 계약(이미 존재: synthesis + report-header) + `context_package`(mode=divergent 평가 → converge 종합) 조합을 커맨드 문서가 **참조**.
+- 필요 시 얇은 orchestrator helper/command fragment로 절차를 공유(중복 서술 금지).
+
+---
+
+## 11. 제품 cascade 진입 계약 (seam, 리뷰 #9)
+
+product-definition stage는 P1에서 만들지 않되, **후속 cascade가 bootstrap 결과를 정확히 참조**할 계약만 정의한다.
+
+```yaml
+# 제품 cascade 진입 조건(신규 predicate: company-context-ready)
+company-context-ready:
+  all:
+    - "company-context.status in [provisional, operating]"
+    - "selected-venture-decision-id exists (company.strategic-decisions[].source-decision-id 또는 별도 pointer)"
+    - "selected venture accepted by HUMAN (acceptance event 바인딩)"
+    - "no unresolved bootstrap blocker"
+```
+
+제품 intake(decision-brief)에는 다음 참조를 포함한다:
+
+```yaml
+company-context-ref: org-os/01-company/company-context.yaml
+venture-decision-id: VD-001
+company-decision-ids: [DEC-001, DEC-002]
+```
+
+- `template` 상태(또는 company-context-commit 미완)에서 제품 cascade 진입은 **advisory 체크**로 가드된다 — 오케스트레이터가 진입 시 `python3 .claude/hooks/state_engine.py check-company-context-ready --workflow <wf>`(exit 2 = NOT READY)를 실행·확인하되, **기존 cascade 전이의 하드 선행조건으로는 넣지 않는다**(부트스트랩되지 않은 회사에서 도는 데모/샌드박스 cascade 회귀 방지 — 구현상 의도적 advisory, Task 12). `provisional/operating`은 READY. **후속 과제**: 이 advisory 체크를 `/ground`·`/decide` 커맨드 프롬프트의 진입 스텝으로 명시 배선(하드 게이트 승격은 데모 cascade 회귀와 상충하므로 신중)."
+- 이 계약은 state_engine의 cascade 진입 guard에 predicate로 추가(제품 stage 자체는 불변).
+
+---
+
+## 12. 마이그레이션 (`demo/populated` → 신 어휘)
+
+영구 별칭이 아니라 **읽기 호환 + deprecation warning + 일회성 migration**:
+1. **읽기 호환:** validate_report·lint은 `demo`를 `template`으로, `populated`를 `operating`으로 **해석**하되 **deprecation warning** 출력.
+2. **일회성 migration:** `lint_company_context.py --migrate`(또는 별도 스니펫)로 현재 `company-context.yaml`을 schema-version 2 구조로 1회 변환(자유서술 `company:` → facts/decisions 이전, 나머지는 hypotheses/보존). 변환 후 status를 명시 어휘로 교체.
+3. 변환 뒤에는 구 어휘 사용 시 Hard Fail로 승격(후속 사이클).
+
+---
+
+## 13. 데이터 흐름 (확정)
+
+```
+/ceo-intake --plan venture-bootstrap
+  → intake (decision-brief-present)
+  → founder-setup            (founder-context.yaml status=filled)
+/venture-validate
+  → opportunity-discovery     (독립 fan-out, cluster ≥2, 중복·완전성)
+  → venture-validation        (option별 9-gate, unknown 허용, kill-criteria 필수, dissent 보존)
+/company-bootstrap
+  → venture-decision          (C-Level 독립평가 → CEO synthesis → HUMAN acceptance receipt[hash 바인딩])
+  → company-context-commit    (candidate → schema → lint → atomic os.replace)
+  → bootstrap-complete        (company-context.status=provisional, artifact receipt 기록)
+        │ seam: company-context-ready
+        ▼
+[product cascade] /ground /decide /design …  (company-context + venture/decision ids 를 입력으로)
+```
+
+전이는 전부 OPS-ORCH가 집행. 각 stage 산출물은 불변 보고서. 공식 SoT는 마지막 1회 원자 교체.
+
+---
+
+## 14. 테스트 (TDD, RED→GREEN, run_all 유지)
+
+기존 제안(신규 predicate 게이팅, lint, status 어휘 캡)에 더해 **반드시 포함**:
+
+1. worker agent가 state transition을 요청하면 거부(allowed-by=OPS-ORCH만).
+2. human boolean만 있고 acceptance receipt 없으면 거부.
+3. 다른 workflow의 decision report를 재사용하면 거부(workflow-id 불일치).
+4. decision hash ≠ acceptance hash면 거부(report-sha256 바인딩).
+5. candidate lint 실패 시 공식 company-context **무변경**.
+6. commit 중 실패해도 기존 파일 유지(atomic).
+7. `template` 상태(또는 company-context-commit 미완)에서 제품 cascade 진입 거부.
+8. `provisional` 상태에서 제품 cascade 진입 허용.
+9. 외부 E4 증거가 provisional 때문에 E2로 강등되지 **않음**.
+10. hypothesis를 참조한 회사별 주장은 Med ceiling 적용.
+11. `demo/populated` 읽기 호환은 되지만 deprecation warning 발생.
+12. 재실행 시 이미 완료된 fan-out을 중복 실행하지 않음(idempotent stage).
+13. 동일 candidate commit 재실행 idempotent.
+14. decision 변경 시 이전 candidate commit 거부.
+
+추가 커버리지: lint Hard Fail 항목별(ID 누락/중복/provenance 누락/hypothesis 필드 누락/hypothesis-id-as-fact/nonexistent evidence path), founder-context 미충족 게이팅, opportunity-cluster <2 차단, kill-criteria 누락 차단.
+
+---
+
+## 15. 열린 사항 / 리스크
+
+- **converge contract 재사용 형태**(collaboration-modes 참조 vs helper vs fragment)는 구현 계획에서 확정. 어느 쪽이든 `/decide` 명령 직접 호출 금지 원칙은 불변.
+- **hypothesis 항목 ceiling**의 anchor 규약(`company-context.yaml#HYP-001`) — 인용 표기 컨벤션을 context-package/보고 스키마 문서에 명시해야 실효.
+- **역할 보강**(GTM-PRICING·GTM-GROWTHPM·ARCH-TECH·CONSULT-OPS 등)이 venture-validation-map에서 실제 agent-card로 존재하는지 gen_agents 대조(doctor 체크 후보).
+- **company-context는 repo-level SoT**(회사 사실 + projects[]). bootstrap은 회사 수립이므로 repo SoT를 교체하는 것이 맞다. candidate는 workspace completion-records에 두고 최종만 repo로 원자 교체.
+
+---
+
+## 16. 확정 체크리스트(리뷰 9개 반영)
+
+1. ✅ 블록 단위 evidence-cap 제거, 항목별 provenance(§7)
+2. ✅ company status가 보고서 전체 evidence를 강등하지 않도록 항목 단위로 한정(§9.1, 기존 구현이 이미 항목 단위임을 확인·확장)
+3. ✅ semantic hypothesis-as-fact는 Warning, 구조·참조·권한만 Hard Fail(§9.2)
+4. ✅ `company-context-commit → bootstrap-complete` 전이 추가(§8.1–8.2)
+5. ✅ 상태 전이는 worker 아니라 OPS-ORCH/trusted hook만 + acceptance receipt hash 바인딩(§8.2–8.4, §9.4)
+6. ✅ candidate 작성 후 공식 SoT 원자적 commit(§9.3)
+7. ✅ `/decide` 명령이 아니라 공통 converge contract 재사용(§10)
+8. ✅ GTM-PRICING·GTM-GROWTHPM·ARCH-TECH·CONSULT-OPS 등 역할 보강(§6.2)
+9. ✅ product cascade 진입 계약만 P1에서 정의(product-definition stage 미신설)(§11)
+
+**2차 반영(구현 직전):**
+10. ✅ 상태 전이 권한 완전 통일 — venture-bootstrap 모든 전이 `allowed-by: [OPS-ORCH]` 단독(intake 행의 `EXEC-CEO` 제거). C-Level은 보고서 생산만(§8.2).
+11. ✅ 공식 `company-context.yaml` status는 3-상태(`template|provisional|operating`)만 — `bootstrap` 제거. "작성 중"은 candidate 파일의 `candidate-status: bootstrap` + workflow stage `company-context-commit`로만 표현(§7.3, §9.2–9.3).