chore: readme 수정

README.md

@@ -1,15 +1,13 @@
 # Org OS 하네스 — Claude Code용 에이전트 운영체계
 
-Org OS 하네스는 제품·개발·운영·GTM 업무를 여러 AI 역할에 배분하고, 단계별 산출물과 사람 승인을 파일 계약으로 연결하는 Claude Code 프로젝트 하네스입니다. <!-- claim-id: C-IDENTITY -->
+Org OS 하네스는 제품·개발·운영·GTM 업무를 여러 AI 역할에 배분하는 Claude Code 프로젝트 하네스입니다. 단계별 산출물과 사람 승인은 파일 계약으로 연결합니다. <!-- claim-id: C-IDENTITY -->
 
-이 저장소의 핵심은 역할 프롬프트의 개수가 아니라 **누가 무엇을 만들고, 어떤 근거로 검토하며, 어느 조건에서 다음 단계로 갈 수 있는지**를 명시하는 데 있습니다. 워크플로 그래프, 역할·권한, typed artifact, 실행 증거를 각각 정본 파일과 hook으로 연결합니다. <!-- claim-id: C-VALUE -->
+이 저장소는 누가 무엇을 만들고 어떤 근거로 검토하며 어느 조건에서 다음 단계로 갈 수 있는지를 명시합니다. 역할 프롬프트의 개수는 핵심이 아닙니다. 워크플로 그래프, 역할·권한, typed artifact, 실행 증거를 각각 정본 파일과 hook으로 연결합니다. <!-- claim-id: C-VALUE -->
 
 <!-- section-id: overview -->
 ## 무엇을 제공하나요?
 
-일반적인 새 작업은 `/ceo-intake`에서 의도와 작업 규모를 구조화한 뒤, 선택된 plan에 따라 discovery·decision·design·build·verification·acceptance로 진행됩니다. 짧은 작업은 light 경로로 줄이고, 회사 수립이나 디자인 방향처럼 별도 수명주기가 필요한 일은 전용 workflow로 분리합니다. <!-- claim-id: C-ENTRY-MODEL -->
+일반적인 새 작업은 `/ceo-intake`에서 의도와 작업 규모를 구조화한 뒤 선택된 plan에 따라 discovery·decision·design·build·verification·acceptance로 진행됩니다. 짧은 작업은 light 경로로 줄이고 회사 수립이나 디자인 방향처럼 별도 수명주기가 필요한 일은 전용 workflow로 분리합니다. <!-- claim-id: C-ENTRY-MODEL -->
-
-이 하네스가 연결하는 범위는 다음과 같습니다.
 
 - 역할과 family를 이용한 작업 라우팅
 - 단계별 입력·출력 artifact와 검토 권한
@@ -20,10 +18,10 @@ Org OS 하네스는 제품·개발·운영·GTM 업무를 여러 AI 역할에
 <!-- section-id: operating-model -->
 ## 핵심 운영 모델
 
-1. **계약이 실행보다 먼저입니다.** `workflow-contracts.yaml`이 stage, command, artifact bundle, reviewer capability, exit gate를 정의하고 `state_engine.py`가 그 그래프를 읽습니다. <!-- claim-id: C-CONTRACT-MODEL -->
+1. **계약이 실행보다 먼저** — `workflow-contracts.yaml`이 stage, command, artifact bundle, reviewer capability, exit gate를 정의하고 `state_engine.py`가 그 그래프를 읽습니다. <!-- claim-id: C-CONTRACT-MODEL -->
-2. **판단과 구현의 협업 방식이 다릅니다.** 현재 family 정책은 판단·설계·분석을 멤버별로 격리하는 fan-out과 코드·실행을 한 concrete worker로 모으는 collapse를 구분합니다. <!-- claim-id: C-COLLAB-MODEL -->
+2. **판단과 구현의 협업 방식이 다릅니다.** 현재 family 정책은 fan-out과 collapse를 구분합니다. fan-out은 판단·설계·분석을 멤버별로 격리하고 collapse는 코드·실행을 한 concrete worker로 모읍니다. <!-- claim-id: C-COLLAB-MODEL -->
 3. **중요 결정은 자동 완주하지 않습니다.** 전체 cascade는 방향 수용과 release 승인 같은 사람 결정 지점에서 멈추도록 정의되어 있습니다. <!-- claim-id: C-HUMAN-BOUNDARY -->
-4. **결과보다 provenance를 함께 남깁니다.** workflow와 artifact는 append-only event 및 id+SHA-256 snapshot으로 연결되고, report는 새 시도마다 새 파일로 발급됩니다. <!-- claim-id: C-PROVENANCE-MODEL -->
+4. **결과보다 provenance를 함께 남깁니다.** workflow와 artifact는 append-only event 및 id+SHA-256 snapshot으로 연결되고 report는 새 시도마다 새 파일로 발급됩니다. <!-- claim-id: C-PROVENANCE-MODEL -->
 
 Claude Code가 이 프로젝트의 `.claude/settings.json`을 로드하면 PreToolUse, PostToolUse, SubagentStart, SubagentStop, Stop 이벤트가 각각 도구 경계·증거 원장·subagent 등록·종료 검증에 연결됩니다. <!-- claim-id: C-HOOK-MODEL -->
 
@@ -43,7 +41,7 @@ pip install -r requirements.txt
 
 ### 2. 워크스페이스 지정
 
-산출물 경로는 `ORGOS_WORKSPACE` 환경변수를 먼저 사용하고, 없으면 `.orgos-workspace`의 첫 유효 줄을 사용합니다. 둘 다 없으면 strict 운영 hook은 exit 2로 중단합니다. <!-- claim-id: C-WORKSPACE-RESOLUTION -->
+산출물 경로는 `ORGOS_WORKSPACE` 환경변수를 먼저 사용하고 없으면 `.orgos-workspace`의 첫 유효 줄을 사용합니다. 둘 다 없으면 strict 운영 hook은 exit 2로 중단합니다. <!-- claim-id: C-WORKSPACE-RESOLUTION -->
 
 저장소 자체를 점검할 때는 테스트용 `_sandbox`를 명시할 수 있습니다. 실제 작업에서는 별도의 프로젝트 디렉터리를 지정하십시오.
 
@@ -69,9 +67,9 @@ Claude Code에서 일반적인 새 제품·개발·운영 요청은 `/ceo-intake
 | **light** | 저위험·two-way-door·single-role이며 고객·매출·보안 영향이 없는 작업 | `/ceo-intake` → `/run-wave` → `/review-output` → `acceptance` <!-- claim-id: C-WORKFLOW-LIGHT --> |
 | **venture-bootstrap** | company context가 아직 template인 새 회사·제품의 수립 | founder context를 채운 뒤 `/ceo-intake --plan venture-bootstrap` → `/venture-validate` → `/company-bootstrap` → `bootstrap-complete` <!-- claim-id: C-WORKFLOW-VENTURE --> |
 
-`/run-cascade`는 cascade의 현재 stage와 다음 command를 계산하는 상위 드라이버입니다. `/design-direction`은 제품 cascade에 종속된 방향 탐색 child workflow이고, `/design-system`과 `/consult`는 각각 코드 UI 검증과 독립 자문 산출물에 초점을 둡니다. <!-- claim-id: C-SPECIALIZED-WORKFLOWS -->
+`/run-cascade`는 상위 드라이버입니다. cascade의 현재 stage와 다음 command를 계산합니다. `/design-direction`은 제품 cascade에 종속된 방향 탐색 child workflow이고 `/design-system`과 `/consult`는 각각 코드 UI 검증과 독립 자문 산출물에 초점을 둡니다. <!-- claim-id: C-SPECIALIZED-WORKFLOWS -->
 
-다음 흐름은 `workflow-contracts.yaml`에 정의된 cascade stage와 사람 결정 경계를 요약합니다. <!-- claim-id: C-CASCADE-VISUAL -->
+`workflow-contracts.yaml`에 정의된 cascade stage와 사람 결정 경계를 요약한 흐름입니다. <!-- claim-id: C-CASCADE-VISUAL -->
 
 ```mermaid
 flowchart LR
@@ -92,7 +90,7 @@ flowchart LR
 <!-- section-id: architecture -->
 ## 저장소 구조와 책임
 
-실행 그래프의 정본은 `org-os/06-agent-work/workflow-contracts.yaml`입니다. 역할·권한 정책은 `org-os/00-role-registry/`에 있고, Claude Code용 command·agent·skill·hook은 `.claude/` 아래에서 이 계약을 소비하거나 검증합니다. <!-- claim-id: C-ARCH-SOURCE -->
+실행 그래프의 정본은 `org-os/06-agent-work/workflow-contracts.yaml`입니다. 역할·권한 정책은 `org-os/00-role-registry/`에 있고 Claude Code용 command·agent·skill·hook은 `.claude/` 아래에서 이 계약을 소비하거나 검증합니다. <!-- claim-id: C-ARCH-SOURCE -->
 
 | 경로 | 책임 |
 |---|---|
@@ -118,7 +116,7 @@ flowchart LR
 <!-- section-id: artifacts -->
 ## 워크스페이스와 산출물
 
-`ORGOS_WORKSPACE`가 상대 경로이면 저장소 루트 아래 프로젝트 디렉터리로 해석되고, 절대 경로이면 그대로 사용됩니다. workspace 아래에는 실행 결과와 상태가 다음처럼 분리됩니다. <!-- claim-id: C-WORKSPACE-LAYOUT -->
+`ORGOS_WORKSPACE`가 상대 경로이면 저장소 루트 아래 프로젝트 디렉터리로 해석되고 절대 경로이면 그대로 사용됩니다. workspace 아래에서 실행 결과와 상태는 이렇게 분리됩니다. <!-- claim-id: C-WORKSPACE-LAYOUT -->
 
 ```text
 <workspace>/
@@ -130,12 +128,12 @@ flowchart LR
 └── design-system/                  # 해당 프로젝트에 UI 산출물이 있을 때
 ```
 
-report는 `<workspace>/completion-records/<workflow>/<role>-<UTC timestamp>.report.yaml` 형식으로 새로 발급됩니다. 실행 command와 exit code, 작성 파일 경로와 SHA-256은 evidence ledger의 receipt로 남길 수 있지만, workspace를 해석하지 못한 계측 hook은 기록을 생략할 수 있습니다. <!-- claim-id: C-REPORT-RECEIPTS -->
+report는 `<workspace>/completion-records/<workflow>/<role>-<UTC timestamp>.report.yaml` 형식으로 새로 발급됩니다. 실행 command와 exit code, 작성 파일 경로와 SHA-256은 evidence ledger의 receipt로 남길 수 있지만 workspace를 해석하지 못한 계측 hook은 기록을 생략할 수 있습니다. <!-- claim-id: C-REPORT-RECEIPTS -->
 
 <!-- section-id: verification -->
 ## 검증 방법과 증거 수준
 
-다음 표는 명령별 확인 수준을 구분합니다. 2026-07-20 현재 이 작업트리에서 doctor와 전체 test suite를 실제 실행했으며, 실행하지 않은 항목은 정적 확인으로만 표시합니다.
+다음 표는 명령별 확인 수준을 구분합니다. 2026-07-20 현재 이 작업트리에서 doctor와 전체 test suite를 실제 실행했으며 실행하지 않은 항목은 정적 확인으로만 표시합니다.
 
 | 목적 | 명령 | 성공 신호와 현재 확인 수준 |
 |---|---|---|
@@ -154,10 +152,10 @@ GitHub Actions는 Python 3.12와 Node 20, `_sandbox` workspace에서 의존성
 <!-- section-id: limitations -->
 ## 현재 상태와 한계
 
-- `company-context.yaml`은 Hyeonworks 확정 전략을 담은 `provisional`, `founder-context.yaml`은 `filled` 상태입니다. 다만 창업자의 실제 주당 시간·자본/런웨이·목표 사업 규모·보유 유통채널·운영/리스크 내성은 확인 전 `unknown`으로 유지하므로, 자원·GTM 결정을 내리기 전 실제 값을 추가해야 합니다. <!-- claim-id: C-LIMIT-CONTEXT -->
+- `company-context.yaml`은 Hyeonworks 확정 전략을 담은 `provisional`, `founder-context.yaml`은 `filled` 상태입니다. 다만 창업자의 실제 주당 시간·자본/런웨이·목표 사업 규모·보유 유통채널·운영/리스크 내성은 확인 전 `unknown`으로 유지합니다. 자원·GTM 결정을 내리기 전 실제 값을 추가해야 합니다. <!-- claim-id: C-LIMIT-CONTEXT -->
 - 강제 hook은 Claude Code가 이 저장소의 `.claude/settings.json`을 로드한 세션 경계 안에서 동작합니다. 다른 실행 환경에서 같은 강제를 자동으로 보장하지 않습니다. <!-- claim-id: C-LIMIT-HOOKS -->
 - UI preview는 DOM mount, bundle, 대비, focus, 반응형 screenshot 같은 render health를 검사하지만 시각적 차별성·타이포그래피·비례·spacing의 미학 품질을 판정하지 않습니다. <!-- claim-id: C-LIMIT-UI -->
-- Node 18 이상과 D2 0.6 이상은 관련 기능의 권장 도구이고, Marp 3 이상은 선택 사항입니다. 전체 UI render에는 Chrome 또는 Chromium 계열 실행 파일도 필요합니다. <!-- claim-id: C-LIMIT-TOOLS -->
+- Node 18 이상과 D2 0.6 이상은 관련 기능의 권장 도구이고 Marp 3 이상은 선택 사항입니다. 전체 UI render에는 Chrome 또는 Chromium 계열 실행 파일도 필요합니다. <!-- claim-id: C-LIMIT-TOOLS -->
 - plain 대 harness의 현재 실행 표본은 저난도 bugfix 두 과제뿐이며 결과는 동률입니다. 설계·문서·의사결정 과제에 대한 품질 향상은 아직 실증되지 않았습니다. <!-- claim-id: C-LIMIT-EVIDENCE -->
 
 <!-- section-id: reference -->