@chrono-meta/fh-gate 2.0.0 → 2.1.0

package/knowledge/shared/harness-core/harness_incubator_doctrine.md

@@ -277,6 +277,88 @@ recommended path is *simulate inside the chamber first, then emit the initial mo
 build-immediately. (Wired as a recommendation branch in `CLAUDE.md §Onboarding / Acceleration
 Autopilot`; build-immediately remains correct for clear, small, low-failure-cost projects.)
 
+### 3-c. The EMIT bar — «walks on its own» (operator-forged, 2026-08-16)
+
+> **Relationship to §3's EMIT-worthiness criterion — two different questions, do not merge them.**
+> That one screens candidates *going in*: is this worth emitting at all (net-new · artifact-shaped ·
+> precision-adequate). This one judges a candidate *coming out*: is it ready to stand. A candidate can
+> clear the first and fail this one (worth building, not yet alive), or clear this one and fail the
+> first (alive, but a reinvention). Both are required; neither substitutes.
+
+Until now the chamber's EMIT threshold was **implicit**, and that is why its record (9 runs,
+8 KILL, 1 EMIT) could not be read: with no stated bar, "screened well" and "over-screened" are
+the same picture. An instrument whose output is almost always one value is indistinguishable
+from an instrument stuck on that value — the dead-control signature this repo keeps re-finding.
+The bar is therefore stated, and stated **low on purpose**:
+
+> **A candidate EMITs when it can stand on its own — not when it is good.**
+>
+> ① It **runs standalone**, with no defect severe enough to prevent execution.
+> ② Every necessary function **fires at least weakly**. Firing, not performing.
+> ③ It is in a state where it can **fill itself in through back-and-forth with a human**.
+> ④ **Weakness is not a KILL.** Only inability-to-run is.
+
+Newborn-foal semantics: it staggers, and it is standing. Shortcomings are expected and are the
+*point* — an emitted harness is raised, not delivered finished.
+
+**The mechanical discriminator, and it is already in hand.** ② is not a judgment call, because
+"fired weakly" and "did not fire" separate cleanly at the exit boundary:
+
+```
+dead   — dies before doing anything             e.g. a gate that aborts on its own version line (rc=1)
+alive  — ran and returned a TYPED verdict       e.g. the same gate returning HARNESS_ERROR (rc=10)
+```
+
+`HARNESS_ERROR` is a *bad* result and it satisfies ②: the unit ran and said why it could not
+finish. `rc=1`-before-anything is not a weak firing, it is absence. This is the same
+`not found ≠ 0` line the rest of this repo runs on, applied to birth.
+
+**Where the judgment must happen: outside the author's environment.** Measured 2026-08-16 — a
+gate suite read 31/31 green in the harness that wrote it and was structurally dead in the sibling
+that inherited it, because the author's repo happened to supply a file the code assumed. An EMIT
+verdict rendered inside the incubator's own environment cannot see that class at all. So the EMIT
+check is run the way a recipient would run it: a clean checkout, none of the author's local state,
+each declared function exercised once.
+
+**Calibration owed, not claimed.** This bar makes the chamber testable for the first time; it does
+not retroactively validate the existing ledger. The 8 KILLs were decided against an unstated bar,
+so whether each died on "cannot run" (correct) or on "weak" (over-screen) is **unknown from the
+record**. Known-pair to run before the ledger is cited as evidence of anything: a known-positive
+(a field harness the operator judges already stands on its own) must EMIT; a ledger KILL whose
+recorded reason is explicitly *cannot run* must KILL. If the known-positive is KILLed, the
+instrument over-screens and every prior KILL is weakened by that much.
+
+### 3-d. What separates incubating from boosting — the AUTHORITY, not the effort (operator, 2026-08-16)
+
+Operator, verbatim: *"부스팅보다 인큐베이터의 장점은 그 레포 전체(또는 출하하기 전 상태의 플젝)를
+FH가 감싸서 **모든 것을 만들어내고 재설계한다**에 있어. 그래서 모든 것을 빠삭히 알아야 하고,
+그러면서도 **모든 것을 조작할 수 있는 권한**이 있는 거야. 부스팅과는 다른 지점이 이것이기도 하다."*
+
+The two identities are not «small help» vs «big help». They differ in **scope of authority over the
+target**, and the two properties are a matched pair — neither is optional:
+
+| | Ⓑ Project Booster | ② Project Incubator |
+|---|---|---|
+| Touches | the point that was asked about | **the whole repo — including redesigning what already works** |
+| Must know | enough for that point | **the entire target, thoroughly** |
+| Reads the codebase | on demand, to answer | **as a precondition, before proposing anything** |
+
+**Why the pair is load-bearing**: total authority without total knowledge is vandalism, and total
+knowledge without authority is a booster that reads a lot. An incubation session that has not read
+the target's design canon, gate code, and existing verification surfaces has not *earned* the second
+column — and the correct move there is to read first, not to scope down to a booster-shaped change
+and call it incubation.
+
+**Where this bit, same day**: the-bible's ⓐ run scoped itself to «invariant-preserving» — correct as
+a *choice the operator made for that request*, and it was then mistaken for the identity's own reach.
+It is not. ⓐ/ⓑ is the operator setting the blast radius for one job; the incubator's standing
+authority is the full repo either way. A session that reads a per-request scope as the identity's
+ceiling will never propose the redesign that was the point of incubating.
+
+**Relationship to 3-a's «day one» bar**: 3-a says what the *born thing* must do. This says what the
+*nursery* is allowed to do to it while it is still inside. The first is an exit condition; the second
+is a working posture.
+
 ## 4. Compose ∪ disrupt — two operating modes over other harnesses
 
 | Mode | What | FH mechanism |
@@ -299,7 +381,7 @@ disruptive path *looks inferior early* — running it is a deliberate bet, named
 ### 4-b. Boundary crossing — what actually flows between harnesses
 
 Compose and disrupt say *what FH does to* other harnesses. They do not say **what moves across the
-boundary, or what must not**. That gap is where the value of a multi-harness cluster is won or lost, so
+boundary, or what must not**. That gap is where the value of the **harness cluster** (identity ①; renamed from "multi-harness cluster" 2026-08-16 — "multi" and "cluster" both meant plurality) is won or lost, so
 name it: a harness that only deepens its own well stays blind to what the neighbouring well knows —
 one harness sees runtime behaviour and not source structure, another sees source structure and never
 runtime. **The meta-harness's job is not to dig a deeper well; it is to make outputs flow across the

package/knowledge/shared/harness-core/harness_terminal_correlation_and_recommendations.md

@@ -0,0 +1,255 @@
+---
+name: harness-terminal-correlation-and-recommendations
+description: "Imported-and-reviewed report on how an AI agent harness relates to its terminal/orchestration environment (cmux vs Orca, both worktree-based orchestrators), human cognitive load bounds, risk-driven sandboxing, and execution-model recommendations. Authored by an external runtime 2026-08-15; corrected under the FH 4-axis gate 2026-08-16 — the original mis-cast Orca as a kernel sandbox."
+date: 2026-08-15
+tags: [harness, terminal, cmux, orca, architecture, ergonomics, governor-pattern, risk-driven-sandboxing, imported-reviewed]
+---
+
+# 하네스와 터미널 간 상관관계 및 사용 추천 (Correlation & Recommendation Report)
+
+## Executive Summary
+
+본 분석 보고서는 **AI 에이전트 하네스(Agent Harness)의 발달 수준과 터미널 환경(Multiplexer / Sandbox) 간의 상관관계 및 직교적 계층 구조**를 규명하고, 신뢰성 기반의 최적 운용 모델을 제안합니다.
+
+* **핵심 명제**: **"신뢰된 로컬 개발 환경에서는, 터미널 인프라에 의존하지 않는 얇은 하네스(Thin Harness)로 충분하다."** (전칭 «가장 뛰어난» 을 뺐다 — 비교 모집단을 잰 적이 없다)
+* **결론**: 에이전트 자체의 오케스트레이션 및 자가 검증(**4축 게이트** — Axis 1 `regression_guard.sh` · Axis 2 `steel-quench` · Axis 3 `phantom-quench` · Axis 4 `edit-manifest`, FH 자산 변경 시 커밋 경계에서 훅으로 강제 — ⚠️ **단 그 훅은 기본 활성이 아니다**: `core.hooksPath` 를 배선해야 발동하며, 갓 클론한 레포에서는 `templates/` 안의 템플릿일 뿐이다)이 성숙한 환경에서는 터미널 멀티플렉서(`cmux`)를 **가벼운 UI 껍데기**로 활용하고 **거버너(Governor) 에이전트 위임 모델**을 적용하는 것이 인지 부하를 최소화합니다. 단, 비신뢰 코드 실행 및 파괴적 부작용이 수반되는 과제는 **위험도 기반 샌드박싱(Risk-Driven Sandboxing)**에 따라 **실제 커널 경계를 가진 샌드박스**(Firecracker · Kata · gVisor · Docker Sandboxes 계열)를 하부에 계층화하여 방어합니다. 🟥 초판은 이 자리에 `Orca` 를 적었고 그것은 틀렸다(§4 최종추천 2 · §명명된 잔여 1).
+
+---
+
+## 1. 문제 제기 및 백그라운드
+
+과거 AI 에이전트 운용 초기에는 에이전트의 오탐, 환각, 호스트 파일시스템 오염을 막기 위해 **외부 인프라(터미널 멀티플렉서, 무거운 Docker/VM 샌드박스)**로 에이전트를 감싸고 통제했습니다.
+
+그러나 메타 하네스(`forge-harness`) 체계가 도입되면서, 에이전트 스스로 하위 작업을 생성·위임하고, 검증(4축 게이트)과 마감 피어 동기화(`knowledge/shared/rules/multi_session_close_protocol.md` **(FH 전용 자산 — 형제 하네스에는 없다. 동기화 시 dangling 참조가 된다)** — **마감 순서와 peer 델타 append 규율**이지, 메모리 색인 락이 아니다)를 소프트웨어적 통제 레이어에서 수행할 수 있게 되었습니다.
+
+이에 따라 **개발자 UX를 위한 UI 레이어(`cmux`)**, **거버넌스·오케스트레이션 레이어(`FH`)**, 그리고 **OS/커널 보안 레이어**의 역할 분담 및 선택 기준을 규정할 필요성이 제기되었습니다. 🟥 **초판은 세 번째 자리에 `Orca` 를 놓았으나 Orca 는 보안 레이어가 아니다** — Stably AI 의 멀티에이전트 오케스트레이터 데스크톱 앱이고 격리 기전이 **git worktree** 라, `cmux`·`FH` 와 **같은 층의 경쟁재**다.
+
+---
+
+## 2. 3계층 구조 대조 분석 (UI · 거버넌스 · 보안실행)
+
+터미널 및 하네스 수단은 선형 대체 관계가 아닌 **3계층 구조**입니다. 🟥 **단 «직교»는 과장이다** — 아래 표가 보여주듯 UI 층(cmux)과 프로토콜 층(FH)은 **worktree 격리에서 겹친다**. 초판은 «cmux 격리 = 없음»을 전제로 직교를 주장했고 그 전제가 틀렸다(임포트 심사에서 외부 1차 문서로 반증). 실제 구분선은 *격리를 제공하느냐*가 아니라 **검증 게이트를 강제하느냐**다:
+
+```
+┌─────────────────────────────────────────────────────────┐
+│ 1. Presentation / UI Layer (e.g. cmux)                  │ ──> 인간의 시각적 탭/세션 관리를 위한 껍데기
+├─────────────────────────────────────────────────────────┤
+│ 2. Protocol / Governance Layer (e.g. forge-harness)   │ ──> 지능적 오케스트레이션, 검증 게이트, 소스 앵커링
+├─────────────────────────────────────────────────────────┤
+│ 3. Execution / Security Sandbox Layer                    │ ──> OS/커널 레벨의 보안, 자원 쿼터, 파괴 방지
+│    (Firecracker · Kata · gVisor · Docker Sandboxes)      │     ⚠️ 이 층에 Orca·cmux 는 해당하지 않는다
+└─────────────────────────────────────────────────────────┘
+```
+
+| 비교 축 | Execution Sandbox (Firecracker · gVisor · Docker Sandboxes) | UI/오케스트레이터 (`cmux` · `Orca`) | Protocol-Native Harness (FH 거버너 위임) |
+|---|---|---|---|
+| **계층 역할** | OS/커널 레벨의 물리적 보안 및 자원 격리 | 시각적 탭/창 관리를 위한 UI 껍데기 | 지능적 오케스트레이션 및 소스 앵커링 |
+| **격리 범위** | 파일시스템, 네트워크 포트, 커널, CPU/RAM 쿼터 | 🟥 **«없음» 은 틀렸다. 다만 «worktree 격리 제공»도 과하다** — 벤더 페이지(<https://cmux.com/>, 2026-08-16 열람) 가 확인해 주는 것은 **SSH 원격 워크스페이스 · 탭별 브랜치/작업디렉터리 · 세션 복원**이고, 오히려 *"strict worktree isolation 을 강제하기보다 동시 작업을 정리하는 데 중점"* 이라고 읽힌다. «local/worktree/SSH 격리»는 **2차 출처발**이며 벤더 페이지에서 확인되지 않았다. ⚠️ 어느 쪽이든 **격리 강도는 미실측** | 서브에이전트 컨텍스트 격리 (별도 컨텍스트 윈도우·요약 반환). **worktree 는 FH 의 기본 격리 수단이 아니다** |
+| **주요 장점** | 비신뢰 코드 실행 시 호스트 시스템 보호(완전 격리는 아니다 — MicroVM 탈출 사례가 실존한다) | 낮은 인지 오버헤드, 빠른 로컬 파일 접근 | 편향 격리(저자 추론을 못 본 채 평가), 컨텍스트 보존, 검증 게이트 |
+| **주요 단점** | 기동 오버헤드, 피어 감지 및 볼륨 바인딩 마찰 | 자원 경합 및 직접적인 호스트 부작용 무방비 | 에이전트의 거버넌스 능력 필요. 🟥 **worktree 를 쓰면 게이트가 깨진다** (아래 §3.2 주의) |
+| **선택 기준** | **비신뢰 코드, 패키지 설치, 파괴적 셸 실행** | **신뢰된 로컬 환경 (1~3개 상위 세션)** | **모든 에이전트 오케스트레이션 및 검증** |
+
+---
+
+## 3. 구조적 상관관계 메커니즘
+
+### 3.1. 인간 활성 인지 한계 ($N_{human} \le 3$) vs 서브에이전트 비동기 병렬성 ($M_{subagent}$)
+보고서의 세션 제한 규율은 **인간의 동기식 의사결정 맥락**과 **서브에이전트 백그라운드 병렬성**으로 명확히 구별됩니다.
+
+1. **인간 활성 세션 ($N_{human} \le 3$)**:
+   * 개발자가 직접 개입하고 의사결정을 내리는 동기식 스트림을 **최대 3개**로 제한합니다. 🟥 **이 «3»은 운영자의 운용 규율이지 문헌값이 아니다** — 초판은 Miller's Law 에 귀속시켰으나 Miller(1956)의 수는 **7±2 chunks**(단기기억 span), 4±1 은 Cowan(2001)이고 **어느 쪽도 3을 주지 않는다.** 권위 이름을 뗀 채로 둔다(근거 = 운영 경험, 표본 미측정).
+     * **Stream 1**: 메인 도메인 기능 개발 (Feature Track)
+     * **Stream 2**: 시스템 리팩토링 및 테스트 (Refactoring Track)
+     * **Stream 3**: 실험적 R&D 및 스펙 검토 (Research Track)
+2. **서브에이전트 백그라운드 병렬성 ($M_{subagent}$)**:
+   * 거버너 에이전트 하위에서 백그라운드로 작동하는 비동기 서브에이전트는 인간 인지 부하를 **크게 늘리지 않으므로** $M > 3$ 병렬 실행이 가능하다고 **가정**합니다. ⚠️ **미측정 운용 가설이다** — «인지 부하 0» 도 «자원·rate limit 에 의해서**만** 제한» 도 잰 적이 없다(거버너의 통합·검토 부담은 M 에 따라 늘어난다). 재려면 M 을 바꿔가며 거버너 턴수·정정 횟수를 세야 한다.
+
+### 3.2. 거버너 + 위임 패턴 및 요약 페이로드 게이트 (Context Budgeting)
+`forge-harness`의 기본 독트린은 **거버너(Governor) 세션이 마감 권한과 소스 재검증 권한을 독점**하고, 하위 에이전트에게 **컨텍스트 격리**(별도 컨텍스트 윈도우, 저자 추론 미상속)를 위임하는 방식입니다.
+
+> 🟥 **worktree 로 위임하지 마라 — 이건 FH 가 실측으로 반대하는 경로다.** `CLAUDE.md §Agent Dispatch
+> Operation` 이 정본이다: ⓐ 문서가 설치를 지시하는 **상대경로 `core.hooksPath`** 형태에서는
+> worktree 안의 훅 사본을 고치면 그 worktree 의 게이트가 무력화된다(실측 `rc=0` — 마커 없는 FH 자산
+> 커밋이 통과). ⓑ 그와 무관하게 **게이트 증거가 gitignored 라 worktree 로 안 따라간다** — 다만
+> **어디까지 사라지는지는 레포마다 다르다.** 최소 공통은 **Axis 2–3 마커**이고, Axis 4 매니페스트는
+> 레포-국소다. 실측(2026-08-16): FH 는 `.gitignore` 가 `tracks/**` 전면이라 **매니페스트도 사라진다**
+> (`check-ignore` 히트, tracked 0). 형제 하네스 PMH 는 `tracks/*` + `!tracks/_meta/` 라
+> **매니페스트가 추적되고**, 마커만 사라진다. 결론(«worktree 에서 FH 자산을 커밋하지 마라»)은 양쪽
+> 모두에서 성립하지만, **그 이유를 «둘 다 부재»로 적으면 PMH 독자는 자기 레포에서 반증하고 마커
+> 경고까지 같이 버린다.** 각자 확인할 것: `git check-ignore -v tracks/_meta/edit_manifest.yaml`.
+> 🟥 **이 문단은 PMH 입장리뷰가 정정했다** — FH 안에서 읽으면 보편 명제로 보이고, 입장을 바꿔야
+> 국소성이 드러난다. 계열 다양성(codex)은 같은 레포 안에서 읽으므로 이 클래스를 못 잡았다.
+> ⇒ **FH 자산 커밋은 표준 세션에서 한다.** worktree 는 «자율 하위 격리»의 수단이 아니라 게이트 무결성
+> 위험이며, 이 문서의 초판은 그것을 강점으로 서술했다(임포트 심사에서 정정).
+
+단, 거버너 세션의 컨텍스트 윈도우 포화(Context Rot)를 방지하기 위해 서브에이전트는 대용량 원문 대신 **정제된 요약 페이로드(Summary Payload / Context Card)** 형태로 거버너에게 보고하며, 거버너는 앵커링 시에만 해당 디스크 아티팩트를 원문 대조합니다.
+
+```mermaid
+graph TD
+    Human["👤 작업자 (Human Director)"] -->|"상위 목표 전달 (N_human ≤ 3)"| Gov["👑 Governor Agent (Main Session)"]
+    Gov -->|컨텍스트 격리 위임| Sub1["🤖 Subagent A (기능 구현)"]
+    Gov -->|컨텍스트 격리 위임 · 블라인드| Sub2["🛡️ Subagent B (Axis 2 steel-quench 적대 심사)"]
+    Gov -->|컨텍스트 격리 위임| Sub3["🔍 Subagent C (Axis 3 phantom-quench 출처 역추적)"]
+    Sub1 -->|Summary Payload 요약 반환| Gov
+    Sub2 -->|Summary Payload 요약 반환| Gov
+    Sub3 -->|Summary Payload 요약 반환| Gov
+    Gov -->|디스크 아티팩트 소스 대조 & 앵커링| MainTree["📦 Main Working Directory & Knowledge"]
+```
+
+### 3.3. 세션 간 메모리 동기화 (Peer Dialog Protocol의 범위)
+병렬 세션 간 마감 충돌은 `multi_session_close_protocol.md` 의 **마감 순서 규율 + peer 델타 append(자기 소유 파일에만 쓴다)**로 다룹니다. 🟥 **다만 이것을 «메모리 색인 쓰기 충돌의 완화책»으로 읽으면 안 된다** — 그 프로토콜에는 메모리 색인 락도 트랜잭션 락도 **없다**. 그리고 그 문서 자신이 명시하는 한계가 이 문서의 cmux 권고를 직접 약화시킨다: **peer 판별이 cwd 매칭이라 다른 worktree 의 peer 를 못 잡는다.** 즉 세션을 늘릴수록 «살아있는 peer 에게 물어본다» 단계가 조용히 빈다. 동시 쓰기의 실제 방어선은 이 프로토콜이 아니라 **디렉터리/파일 소유 분리**이며, 락은 현재 존재하지 않는 미구축 항목이다.
+
+---
+
+## 4. 위험도 기반 샌드박싱 의사결정 트리 (Risk-Driven Decision Tree)
+
+🟥 **초판 트리에는 뿌리 분기가 «비신뢰 코드인가» 하나뿐이었고, 그건 개인 머신 입장에서만 충분하다.**
+residency 가 걸린 환경(조직 내부·규제·고객 데이터)에서는 **평범한 작업이 전부 그 분기에서 NO 로 떨어져**
+«얇은 하네스 + UI 층» 으로 직행한다 — 정작 그 환경의 구속조건은 코드 신뢰도가 아니라 **데이터 유출**
+인데도. 형제 하네스 입장리뷰가 지목했고, 뿌리 분기를 하나 앞에 세운다.
+
+```
+                       [ 새로운 작업 오더 ]
+                                │
+                 Is the data residency-bound?          ← 신설 (입장리뷰)
+                 (조직 내부·고객·규제 데이터가 관여하는가)
+                                │
+                   ┌────────────┴────────────┐
+                  YES                        NO
+                   │                         │
+   [ 환경 승인 도구만 · 도구의 telemetry·      │
+     상태파일 기록 표면을 먼저 실측 ]          │
+                                              │
+                 Is Execution Dangerous / Untrusted?
+                 (비신뢰 코드, 외부 패키지, 파괴적 셸)
+                                │
+                   ┌────────────┴────────────┐
+                  YES                        NO
+                   │                         │
+      [ 커널 샌드박스 ]             [ Meta-Harness (FH) / Thin Protocol + cmux ]
+      (OS/커널 물리 격리 적용)       (표준 세션 + 거버너 오케스트레이션)
+                                             │
+                                    Human Decision Streams?
+                                             │
+                                   ┌─────────┴─────────┐
+                             N_human <= 3        N_human > 3
+                                   │                   │
+                            [ cmux 1~3개 탭 ]  [ 인지 과부하 경고: ]
+                            (가벼운 UI 껍데기)   [ 과제 통합 및 조정 ]
+```
+
+### 최종 요약 추천
+1. **신뢰된 로컬 환경 (Trusted Local Setup)**: **`Meta-Harness (forge-harness) + cmux` (가벼운 UI 껍데기 1~3개 탭)**
+   * 메타 하네스가 자가 검증(4축 게이트)과 거버너 오케스트레이션, 서브에이전트 **컨텍스트 격리**를 수행하므로, 인프라 오버헤드가 없는 `cmux` 를 **잠정 권고**합니다(이 운영자 구성에서의 판단, n=1 · cmux 미실측). 여기서 "Thin Harness"는 인프라 샌드박스 대비 소프트웨어 프로토콜 중심이라는 최소 기준을 의미하며, `forge-harness`는 이 계층의 최상위 메타 하네스로 작동합니다.
+   * ⚠️ **범위 한정 ① OS**: 벤더 페이지 기준(2026-08-16) **배포되는 빌드는 Mac 이고 그 외 플랫폼은 waitlist** 다 — «macOS 전용 설계»가 아니라 «현재 Mac 만 출시»가 정확한 서술이다(초판·1차 정정 모두 이걸 «전용»으로 단정했다). 리눅스/윈도우 노드의 UI 층 선택은 다루지 않는다(미조사).
+   * ⚠️ **범위 한정 ② 런타임**: Claude Code 세션을 전제한다. 다른 런타임(OpenCode 등)에서의 적합성은 **판단 불가 — 조사한 적 없다.**
+   * 🟥 **범위 한정 ③ residency — 이 문서의 자기모순이었다.** 초판은 §5 에서 **이전 도구가 프롬프트 원문·툴콜을 로컬 상태파일에 기록하더라는 것을 residency 표면으로 지목해 놓고**, 바로 그 다음 절에서 새 UI 층을 **동일 점검 없이** 권고했다. UI 층은 **그 세션의 모든 프롬프트를 보는 구성요소**다. ⇒ **residency 가 걸린 노드에서는 도입 전에 telemetry·상태파일 기록 표면을 실측하고 승인받는다**(§5 와 같은 점검). «macOS 전용»은 맞는 단서지만 **틀린 축의 단서**였다 — 입장리뷰가 지목.
+2. **비신뢰 및 파괴적 과제 (Untrusted Execution)**: **실제 커널/하이퍼바이저 샌드박스** — Firecracker · Kata Containers · gVisor · Docker Sandboxes 계열
+   * 파괴적 셸 명령, 비신뢰 외부 코드 실행 시에는 커널 경계를 가진 샌드박스를 하부에 배치해 호스트 노출을 크게 줄입니다(«완벽»이 아니다 — 커널/하이퍼바이저 탈출은 실존하는 위협 클래스다).
+   * 🟥 **초판은 여기에 `Orca` 를 «물리 샌드박스»로 적었고 그건 틀렸다. 이 정정이 이 문서에서 가장
+     중요하다** — `stablyai/orca` 는 *"The AI Orchestrator for 100x builders"* 로, 격리 기전이
+     **git worktree** 다(*"each in its own isolated git worktree"*). 커널 격리도 MicroVM 도 컨테이너도
+     **없다.** 초판의 권고를 그대로 따르면 **비신뢰 코드를 커널 샌드박스로 착각한 채 호스트에서 그냥
+     실행하게 된다.** worktree 는 «어느 파일을 보느냐»의 분리이지 «무엇을 실행할 수 있느냐»의 경계가
+     아니다 — 같은 커널·같은 사용자 권한·같은 네트워크다.
+
+---
+
+## 5. FH 는 Orca 를 이미 써 보고 떠났다 (2026-07-12 기록)
+
+이 문서가 놓친 가장 큰 맥락은 **FH 가 Orca 를 실제로 운용해 본 이력이 있다**는 것이다.
+따라서 «Orca vs cmux» 는 가설 비교가 아니라 **이미 내려진 결정의 사후 서술**이다.
+
+> 🟥 **출처 도달성 — 이 절의 표는 리뷰어가 검증할 수 없다.** 근거는 운영자 memory
+> `reference_orca_app_config.md`(2026-07-12) · `feedback_no_ui_terminal_native_identity.md` 인데,
+> **둘 다 이 레포에 없다**(비공개 컴패니언 스토어의 gitignored 기록). 즉 아래 표는
+> `LOCAL-ONLY ATTESTATION — UNVERIFIED` 이며, 저자의 주장이지 리뷰어가 확인한 증거가 아니다.
+> 이것은 `fh_4axis_gate.md §Reviewer-visible evidence` 가 지적하는 «증거를 리뷰어가 닿을 수 없는
+> 곳에 둔» 바로 그 형태다 — 라벨은 갭을 정직하게 드러낼 뿐 닫지 않는다. **cross-family 심사가
+> 지목해서 추가된 문단이다**(내부 세션은 자기 memory 가 보이니 이 결손이 안 보였다).
+
+| 관찰(2026-07-12 실측) | 함의 |
+|---|---|
+| Orca 는 작업마다 `~/orca/workspaces/<레포>/<브랜치>/` 에 워크트리를 판다 | FH 자산 커밋 경로와 정면 충돌 — §3.2 의 게이트 무결성 문제를 **구조적으로 상시 유발** |
+| 그 결과 세 레포에 **방치 브랜치 다수** 발생, 스윕으로 정리 | 병렬성의 정리 비용이 사람에게 남는다 |
+| 에이전트별 기본 인자에 `--dangerously-skip-permissions` 가 박혀 있었다 | 승인 게이트를 기본값으로 우회 — FH 의 HITL 규율과 반대 방향 |
+| 상태 훅이 **프롬프트 원문·툴콜까지** 로컬 상태파일에 기록 (실측 확인 후 OFF) | 텔레메트리 표면. residency 관점에서 점검 대상 |
+
+**운영자 결론(그대로 인용)**: FH 는 *"사람=선형적 단일스레드로 거버넌스, AI=병렬 사이드카가
+흩어졌다 다시 모여 결과만 보고"* 하는 구조인데, Orca 는 반대로 *"병렬성을 사람이 보는 표면에
+그대로 노출"* 시켜 **통합 부담을 사람에게 떠넘긴다.**
+
+⇒ 이것이 cmux 로 옮긴 실제 이유이며, §3.1 의 $N_{human} \le 3$ 과 같은 축이다: **UI 층은 병렬성을
+보여주기만 해야 하고, 병렬성을 관리하는 주체는 거버너여야 한다.**
+
+⚠️ **단 이것은 도구의 속성이 아니라 «어떻게 쓰느냐»의 문제다** — cmux 도 팀/에이전트 오케스트레이션
+기능을 갖고 있다(공식 페이지). 여기서 «가벼운 UI 껍데기»는 **그 기능을 쓰지 않고 탭 관리로만 쓰는
+운용 구성**을 가리키며, 그렇게 쓰는 한 통합 부담이 거버너에 남는다. 같은 도구를 오케스트레이터로
+쓰기 시작하면 Orca 에서 떠난 이유가 **cmux 에서도 그대로 재발한다.** (초판 정정문은 이를 cmux 의
+속성인 것처럼 썼고, cross-family 심사가 그 과장을 지목했다.)
+
+---
+
+## 명명된 잔여 (Named Residuals)
+
+이 문서는 **다른 런타임(Antigravity/Gemini 계열)이 2026-08-15 에 작성한 것을 2026-08-16 에 FH 로
+임포트하면서 4축 게이트로 심사한 판본**이다. 초판의 주장 중 반증된 것은 위 본문에 🟥 로 표시했다.
+남은 잔여는 다음과 같다 — 닫힌 척하지 않는다.
+
+1. ✅ **`Orca` 오귀속 — 해소됨(운영자 지목 + 실물 확인). 이 문서 최대의 정정이다.**
+   초판은 Orca 를 «OS/커널 MicroVM 물리 샌드박스»로 세웠다. 실물은
+   [`stablyai/orca`](https://github.com/stablyai/orca) — *"The AI Orchestrator for 100x builders"*,
+   *"each in its own isolated **git worktree**"* 다. 커널 격리도 MicroVM 도 컨테이너도 **없다.**
+   ⇒ Orca 는 보안층이 아니라 **`cmux`·FH 와 같은 층의 오케스트레이터**다.
+   위험도는 분류 오류에 그치지 않는다: 초판을 그대로 따르면 **비신뢰 코드를 커널 샌드박스로 착각한
+   채 호스트 권한으로 실행하게 된다.**
+2. **cmux 는 로컬 미설치 — 벤더 1차 문서 대조까지만 했고 런타임 실측이 아니다.** 워크스페이스 격리
+   제공 사실은 공식 문서 기반이며, 그 격리의 *강도*는 재지 않았다.
+3. **`N_human ≤ 3` 은 표본 미측정 운용 규율**이다(§3.1). 문헌 근거 없음이 확인된 상태이지,
+   3이 옳다고 검증된 것이 아니다.
+4. **메모리 색인 동시쓰기 방어는 미구축**이다(§3.3). 하네스 층 파일 락은 존재하지 않으며,
+   현재 방어선은 파일 소유 분리라는 *규율*뿐이다.
+5. **부록의 심사 이력은 저자 런타임 자기신고**이며 재현 불가하다(아래 부록 자체 주석 참조).
+6. **표본 n=1** — 단일 운영자·단일 머신 구성에서의 판단이다.
+7. **형제 하네스가 아직 옛 입장을 들고 있다.** PMH 정본(`CLAUDE.md` 상주층)은 «에이전트뷰 기본
+   운용»을 선언하고 있어, 이 문서 §3.2 와 **정면으로 모순**된다. 이 문서를 동기화하면 그쪽에
+   상충하는 상주 지시가 둘 생기고 tiebreaker 가 없다. ⇒ **문서만 옮기지 말고 그쪽 정본의
+   carve-out 을 같은 변경에서 처리해야 한다.** 이 PR 범위 밖이며 미해결.
+8. **런타임 범위 미조사** — cmux × 비-Claude-Code 런타임 조합은 판단하지 않았다.
+9. **외부 1차 출처가 레포에 스냅샷되어 있지 않다.** Orca·cmux 인용은 열람일만 기록돼 있고
+   본문 스냅샷·커밋해시·아카이브 링크가 없다. 이 레포만 받은 사람은 **정정의 근거를 확인할 수
+   없다** — 초판이 틀렸다는 것도, 정정판이 맞다는 것도. (fresh-clone arm 지목)
+10. **게이트 강제는 배선 조건부다.** `core.hooksPath` 미배선 클론에서는 훅이 `templates/` 안
+   템플릿일 뿐이고 아무것도 막지 않는다. 초판 요약은 이를 무조건적 기계 사실로 적었다.
+11. **§5 는 이 레포 안에서 검증 불가다** — 4행 «2026-07-12 실측» 표와 인용된 운영자 결론의
+   출처가 전부 비공개 저장소에 있다. 라벨은 붙었으나 그건 갭을 드러낼 뿐 닫지 않는다.
+
+---
+
+## Appendix: `ko-tech-writer` & 글로벌 전문가 심사 이력 (Audit Log)
+
+| 파이프라인 단계 | 수행 항목 및 결과 | 비고 / check-class |
+|---|---|---|
+| **Step 0 레지스터** | 독자용 아키텍처 기술문서 (문어 존댓말/명료체) | mandatory-pass |
+| **Step 1 캘리브레이션** | FH Knowledge Core 정본 표본(`knowledge/shared/harness-core/fh_ecosystem_positioning.md`) 서식 및 톤 대조 완료 | mandatory-pass |
+| **Step 2 문체 규율** | 번역투·조각문 5종 스캔 «잔여 0건 (양성 컨트롤 동반)» 주장 | 🟥 `UNCALIBRATED` — 컨트롤이 무엇이었는지·재현 커맨드·출력이 **하나도 없다**. 재현 불가한 0은 0의 증거가 아니다 |
+| **Step 3 정직 수위** | 저자 내부 집계 규율 서술 제거 및 독자 의사결정 기반 정보 보존 | judged |
+| **Step 4 수치·주장 게이트** | 수치 전수 추출 + «전칭 단정 스캔 잔여 0건» 주장 | 🟥 `UNCALIBRATED — 자기반증`: 그 «0건» 시점에 본문에 전칭 단정이 **3건 살아 있었다**(«완벽 보호» ×2, «가장 뛰어난 하네스») — 임포트 심사가 손으로 잡아 정정했다. 계기는 초록인데 대상을 안 쟀다 |
+| **Step 5 지각 QA** | Mermaid 다이어그램 노드 레이블 및 Decision Tree ASCII 렌더링 시각 확인 완료 | judged |
+| **글로벌 인프라 심사** | 논리 격리 vs 보안 샌드박싱 분리, 자원 경합 및 Context Budgeting 피드백 반영 | 🟥 `LOCAL-ONLY ATTESTATION — UNVERIFIED`: 저자 런타임(Antigravity) 측 심사이고, 짝으로 적혀 있던 `research` 서브에이전트는 **이 레포에 존재하지 않는다**(등록 에이전트 8종 중 없음). FH 안에서 재현 불가 |
+| **적대적 공격 심사** | 직교적 3계층 모델 재정립, $N_{human}$ vs $M_{subagent}$ 인지 분리, 샌드박싱 조건 개고 | 🟥 `LOCAL-ONLY ATTESTATION — UNVERIFIED`: `challenger` 는 실재하는 FH 에이전트지만(`plugins/fh-meta/agents/challenger.md`), 이 행이 가리키는 실행의 마커·로그가 없다. **이름의 실재는 실행의 증거가 아니다** |
+
+> 🟥 **이 부록 전체의 지위**: 저자 런타임의 **자기신고**이며, 위 «잔여 0건»·«PASS» 는 아티팩트로
+> 뒷받침되지 않는다. FH 자기 규율상 이것은 증거가 아니라 저자의 주장이다
+> (`fh_4axis_gate.md §Reviewer-visible evidence` 의 degrade 라벨을 그대로 적용).
+> **이 문서에 대한 심사는 임포트 시점의 4축 게이트에서 이뤄졌다.** 🟥 **그런데 그 기록을 «커밋
+> 이력과 `tracks/_meta/edit_manifest.yaml` 에 있다»고 가리키는 것은, 이 레포를 받는 사람에게는
+> 죽은 포인터다** — `tracks/**` 가 gitignored 라 매니페스트도 마커도 **공개 레포에 애초에 실리지
+> 않는다.** fresh-clone 입장 arm 이 지목했다: 부록의 자기신고를 «증거 아님»으로 강등해 놓고, 그
+> 대체물로 **수령자에게 구조적으로 비어 있는 곳**을 가리켰다. 즉 **강등만 참이고 대체는 거짓**이었다.
+> ⇒ 리뷰어가 실제로 닿을 수 있는 것은 **PR 본문의 증거 캡슐**(PR #402)과 이 파일의 커밋 메시지뿐이며,
+> 마커·매니페스트는 저자 머신에만 존재한다. 이것은 `fh_4axis_gate.md §Reviewer-visible evidence`
+> 가 이미 명명한 구조적 갭이고, 여기서 닫히지 않는다.
+
+---
+*Authored by an Antigravity (Gemini-family) runtime, 2026-08-15; imported into the FH Knowledge Core and reviewed under the 4-axis gate on 2026-08-16.*

package/knowledge/shared/harness-core/harness_verification_core_extended.md

@@ -14,7 +14,7 @@ has two structurally different sources of lift:
 | Mode | What it is | Availability |
 |---|---|---|
 | **Core** | Verification questions FH/PMH can ask **natively, with no cluster member present** — methodology internalized as FH's own lens | Must hold stand-alone (cluster-independent) |
-| **Extended** | Verification **instruments** dispatched from the multi-harness cluster — a field QA harness's audit lens, a trace-boundary auditor, a process-fidelity/judge harness | Available when the cluster member and its consent lane are |
+| **Extended** | Verification **instruments** dispatched from the **harness cluster** (identity ①; renamed from "multi-harness cluster" 2026-08-16) — a field QA harness's audit lens, a trace-boundary auditor, a process-fidelity/judge harness | Available when the cluster member and its consent lane are |
 
 **First clause (the boundary)**: *harness-verification core = the FH-native triad-consistency lens;
 harness-verification extended = cluster instruments.* The operative test is **what discharges the