@chrono-meta/fh-gate 2.2.0 → 2.4.0

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

@@ -224,6 +224,37 @@ pass):
 **🟥 DECIDE IN THIS ORDER — first match wins. Do not pick by matching a description.**
 
 ```
+Q0. WHICH TARGETS? — settle the target CLASS(es) before reaching for a tier.
+    🟥 NOT first-match. Q0 can return MORE THAN ONE target, and each one owes its own tier.
+    A release that also alters a named peer's contract owes both arms; recording only the
+    first shadows the second (caught by cross-family review, 2026-08-17).
+
+      ⓐ Does a NAMED PEER HARNESS carry this surface?
+         Mechanical test, in this order — do not decide from memory or from a name list:
+           · a local repo of a cluster peer carries the file this delta changes
+             (`for d in ~/projects/*; do test -f "$d/<changed-path>"; done`), OR
+           · the peer is declared in `.claude/capabilities` / the cluster registry, OR
+             the change edits an adapter under `scripts/adapters/` naming it
+         YES → target = that repo (one per peer)              → run Q1 for each
+      ⓑ Does this delta change CONSUMER-VISIBLE BEHAVIOR — what a consumer's gate blocks or
+         passes, what a consumer's session is instructed to do, what an install receives?
+         YES → target = a CLEAN INSTALL of the packed artifact → run Q1
+               🟥 This binds NOW, at the change, pre-push (§Sequencing) — NOT deferred to
+               the eventual release. Deferral was the first draft's hole: "not a release
+               yet" would have let a behavior change ship unexamined and left the releaser
+               holding a delta they did not write.
+      ⓒ Neither ⓐ nor ⓑ → `not-applicable`   STOP.
+
+    🟥 A consumer install IS another harness — settled, not open. What Q0 scopes is not WHO
+    RECEIVES the change but WHERE IT HAS TO BE EXECUTED, and 🟥 **not «is this file shipped»**:
+    almost everything here is shipped, so shipped-ness cannot be the discriminator (see
+    «Target class» below). The discriminator is ⓑ's *behavior* clause — the same effect-based
+    trigger this section already uses, applied to the consumer as a target rather than as an
+    audience.
+    Reading Q1/Q2 when the target is an install tree rather than a repo: Q1's "executed in the
+    target's repo" = "executed inside the extracted/installed tree"; Q2's local-wiring question
+    is answered NO for a bare extraction (`tier2`), YES only if a real consumer node's own
+    settings/state were in play (`tier2b`).
 Q1. Did anything EXECUTE in the target's repo — a command, a script, a suite?
       NO, I only read files          → tier1b(<harness>)   STOP.
       NO, I did not touch its repo   → tier1               STOP.
@@ -269,6 +300,24 @@ tier1b(<target-harness>)     STATIC standpoint read — the reviewer read the TA
                               nearer value existed. A missing rung does not stay empty — it gets
                               filled by the next one up. Real but weak: see «execution is the
                               load-bearing half» below before crediting it.
+                              🟥 «FROM THE TARGET'S REPO» IS LOAD-BEARING, and a field case the
+                              day this rung shipped shows why. A session changed FH code that would
+                              make two peer harnesses' capability declarations start being REJECTED
+                              — genuinely applicable — and reached for `tier1b` because it had
+                              *read files*. The files it read were FH-local records ABOUT those
+                              peers (`tracks/_meta/relay/*.cap`), not the peers' own files. Reading
+                              your own repo's description of a peer is NOT a standpoint read; the
+                              whole point of the axis is whose ground truth the review was checked
+                              against, and that was still your own. The honest value there is
+                              `DEGRADED_NOT_RUN(<peers>)` — applicable, target reachable, nothing
+                              done at the target. Note the direction of the risk has INVERTED since
+                              this rung was added: tier1b was created because a real static read had
+                              no home and got recorded one rung too high; the new failure mode is
+                              local reading being recorded as tier1b because "I read something"
+                              feels the same. 🟥 Two different questions get merged here and must
+                              not be: *does a target exist and is it affected* is **Q0**; *what did
+                              you actually do at that target* is the **tier**. "The impact is real"
+                              answers the first and says nothing about the second.
 tier2(<target-harness>)      peer-simulated — the reviewer EXECUTED CODE in the TARGET's own repo
                               (a local clone, real content) and observed the result.
                               🟥 DISCRIMINATOR — «reading the target's real files is NOT this rung».
@@ -305,8 +354,18 @@ tier2b(<target-harness>)     same operator, target's real runtime — the SAME h
 tier3(<target-harness>)      actual peer — a DIFFERENT human operator of the target harness ran
                               the change in their real runtime. The only tier with both local
                               wiring AND reviewer independence from the author.
-not-applicable                the change has no target-harness standpoint to borrow (no
-                              shared-body surface, no cross-repo consumer contract) — distinct
+not-applicable                the change has no target-harness standpoint to borrow — Q0 found
+                              neither a named peer harness NOR a release/publish surface, so there
+                              is no repo and no install to run this from. 🟥 Read the second half
+                              literally: «no cross-repo consumer contract» does NOT mean «this file
+                              is never shipped». Almost everything here is shipped (measured
+                              2026-08-17: 192/200 recent commits touch an npm-shipped path, and that
+                              96% is a LOWER bound — `package.json` is packed without appearing in
+                              `files[]`). Reading shipped-ness as the trigger makes this value
+                              reachable in under 4% of commits, i.e. effectively unreachable, and an
+                              unreachable value teaches authors to delete what they are counting
+                              (`[[feedback_unreachable_done_when_trains_evasion]]`). The trigger is
+                              the RELEASE, not the path — distinct
                               from a degrade value; this is a scoping fact, not a miss. Carries the
                               same substantive-grounds-on-the-same-line discipline as a degrade
                               value below — asserting non-applicability without naming what was
@@ -382,11 +441,22 @@ data point.
 **Mechanization status — `standpoint:` is prose-only today, and this must not be read as more than
 that.** `crossfamily:`'s degrade triad is hard-blocked at commit (`templates/.git-hooks/pre-commit`,
 `scripts/test_marker_crossfamily_lanes.sh` — grep-verified: ~20 crossfamily references in the hook,
-validated fixtures). `standpoint:` has **zero** matches in that hook and no fixture suite — nothing
-stops an author from writing `not-applicable` with a thin justification, or omitting the field
-entirely, and no marker-shape check catches it. §Marker required fields in
-`.claude/rules/fh_4axis_gate.md` does not yet list `standpoint:` either (add it there when this
-mechanizes). This is the honest current state, not a placeholder apology: the field exists so a
+validated fixtures). `standpoint:` has **no value-enum validation and no fixture suite** — nothing stops an author from
+writing `not-applicable` with a thin justification, and no marker-shape check catches a wrong value.
+
+🟥 **Two sentences that stood here were STALE and are corrected (2026-08-17, re-measured — a
+cross-family reviewer flagged the second, the first fell out of checking it).** They read
+*"`standpoint:` has **zero** matches in that hook"* and *"§Marker required fields in
+`.claude/rules/fh_4axis_gate.md` does not yet list `standpoint:` either"*. Both are false as of this
+date: `grep -c standpoint templates/.git-hooks/pre-commit` → **15**, and the hook *does* enforce one
+property (when `axes-run` carries `ⓑ=→standpoint`, the `standpoint:` line must exist and be non-empty
+— `pre-commit:780-782`); `.claude/rules/fh_4axis_gate.md` lists the field at **§133 and §192**.
+**What is still true is the narrower claim**: the *value* is unvalidated — «the line exists» is
+enforced, «the value is right» is deliberately reserved (§Mechanization Boundary). Do not read the
+corrected sentence as "now mechanized"; read it as "the channel is checked, the judgment is not".
+The distinction this stale text destroyed is exactly the one that matters here, and it destroyed it
+in the *pessimistic* direction — under-claiming coverage is not a safe error either, because it
+invites someone to rebuild a lane that already exists. This is the honest current state, not a placeholder apology: the field exists so a
 human reader can ask for it and so the *next* occurrence of a false `not-applicable` has something
 concrete to point at — mechanize on that first recorded false value
 (`[[feedback_mechanize_at_repetition_prose_before]]`), not before. **Ownership**: this field lives
@@ -449,6 +519,160 @@ proposal (pmh-dev issue #68, verified verbatim in that thread: *"대상 후보
 behavioral reading after that same review found the file-class reading false for at least one real
 pair.
 
+**Target class — «누가 받나» is not the question; «어디서 돌려야 하나» is (operator decision,
+2026-08-17).** The trigger above says *effect, not file-class*, and that was still not enough: three
+independent marker-audit legs, run the same day against three different markers, all failed at the
+same place — each reasoned *"it ships, therefore there are consumers, therefore a cross-repo consumer
+contract exists, therefore applicable"*. That reading is not obviously wrong; the enum's own words
+(*"no cross-repo consumer contract"*) invite it. What kills it is the size: **192 of the last 200
+commits touch an npm-shipped path (96%, a lower bound — `package.json` ships without being listed in
+`files[]`, so at least one of the 8 remaining is a false negative too)**. A value reachable in under
+4% of commits is not a scoping value — it prices the axis at a rate this section's own **Trigger**
+paragraph already rejects as over-triggering (*"almost every commit would qualify, which is the
+over-pricing this trigger is trying to avoid, not invoke"*). That is the argument, and it was
+already in this document.
+
+⚠️ **A citation is withdrawn here.** The first draft justified this with
+`[[feedback_unreachable_done_when_trains_evasion]]` — *"an unreachable condition teaches people to
+delete what they are counting"*. An adversarial round showed the direction is **inverted**: that
+memory is about an unreachable **pass condition** a person must reach, whereas `not-applicable` is an
+**exemption**. An unreachable exemption does not make anyone delete anything; it makes the obligation
+fire almost always, and the failure mode is over-pricing and formality, not evasion. Same discomfort,
+different mechanism — do not re-import the citation.
+
+🟥 **State precisely what that 96% does and does not establish — it is narrower than it looks, and a
+cross-family reviewer caught the first draft overreaching on exactly this.** It is a *file-class*
+count, which this very section rejects as a trigger. It is admissible for **one** claim: the legs'
+argument *was* the file-class argument (*"it ships, therefore consumers, therefore applicable"*), so
+the number measures **that argument's reach**, and shows that adopting it collapses `not-applicable`
+to under 4%. It does **NOT** establish how often the *behavioral* trigger (Q0-ⓑ) actually fires —
+that number is **unmeasured**, and the step from "touched a shipped path" to "a consumer standpoint
+obligation arose" is precisely the step Q0-ⓑ exists to make someone take by hand. Anyone citing 96%
+as the applicability rate is citing it wrong.
+
+**Corrected figure, and the instrument defect behind it — surfaced only because an adversarial round
+demanded the hand-check.** The first pass reported **192/200 (96%)** with 8 non-touching commits. Two
+faults, in opposite directions:
+- **Instrument**: the scan ran `--first-parent` *including merge commits*, and `--name-only` emits no
+  file list for a merge — so merges were silently scored *non-touching*. Re-run with `--no-merges`:
+  the ratio held at 192/200, but the non-touching set collapsed to **6 real cases** (2 commits
+  legitimately carry no files).
+- **Hand-check of all 6** (this repo's own publish-a-number rule; N=6 made it trivially cheap):
+  **2 are `package.json`-only**, which npm packs regardless of `files[]` — they *are* shipped. The
+  other 4 are genuinely unshipped (`.gitignore` · `knowledge/shared/learnings/…` · two `scripts/`
+  paths absent from `files[]`).
+
+⇒ **Measured: 194/200 = 97%, every exception hand-verified.** ⚠️ One direction stays unexamined: the
+scan applies **today's** `files[]` to **past** commits, and that manifest has only grown, so older
+commits are over-counted as shipped. That FP direction is **unmeasured** — read 97% as *"under the
+current manifest"*, never as a historical claim.
+
+🟥 **And read the reachability argument in BOTH directions, which the first draft did not.** It
+measured only what the *rejected* reading does to `not-applicable` (collapses it to <4%). It never
+measured what the *adopted* reading does — Q0-ⓑ is a judged behavioral test, so no scan settles it,
+and the honest statement is that **the new rate is unknown in both tails**: the value could stay rare
+(if most shipped-path commits do change consumer-visible behavior) or become near-universal (if most
+do not), and a near-universal exemption is a rubber stamp, which is its own failure — not the one
+this edit was fixing. Watch the next 20 markers rather than assuming this landed in the middle.
+⚠️ **The «unreachable ⇒ trap» premise is also weaker here than the first draft implied**: `tier1` is
+explicitly *"NOT itself a failure"*, so even under the rejected reading an author had a cheap honest
+value to write and was not cornered into deleting anything.
+
+⚠️ **Two different denominators, both of which happen to be 200 — do not merge them.** The 192/200 is
+over the **last 200 commits**. The 177/200 below is over the **200 markers in
+`tracks/_meta/.axes_23_passed_*.marker`**. Commits and markers are different populations (a marker
+covers a delta, not a commit; unmarked commits exist), and their coincident size is an accident of
+this corpus. No ratio may be carried from one to the other.
+
+So the split is by **execution site**:
+
+| Q0 target class | What discharges the standpoint arm | Binds at |
+|---|---|---|
+| named peer harness (qasp · pmh · mate · gstack · sibling hub) | the enum as written — `tier1b`/`tier2`/`tier2b`/`tier3` against that repo | the change, pre-push |
+| generic consumer install | run the **packed artifact in a clean install** — see the split below; the *presence* half already runs at ship time, the *execution* half does not exist yet | the **release/publish** delta |
+| neither | `not-applicable` | — |
+
+**🟥 What that arm is actually covered by today — corrected in the same session that wrote it, by
+reading the lanes instead of naming them.** The first draft of this table said the consumer-install
+arm was *"already mechanized"* by `publish_freshness_check.sh` · `package_coverage_check.sh
+--vs-tarball` · `test_capability_entrypoint_shipping.sh`. Reading those three shows they answer a
+narrower question than the arm asks:
+
+```
+covered, AT PUBLISH   `prepublishOnly` = prepublish_scope_note · publish_freshness_check ·
+                      version_lockstep_check · package_coverage_check --vs-tarball ·
+                      public_surface_scan_files          ← read from package.json, not recalled
+covered, BUT IN CI    test_capability_entrypoint_shipping.sh is NOT in that chain — it runs under
+                      the selfcheck anchor loop (`npm test`/CI). Naming it as a ship-time lane was
+                      wrong; a green CI is not a publish gate (§Local Execution First).
+NOT covered (exec)    extract the tarball into a clean directory, run the gate as a consumer would,
+                      observe it behaves as intended. Measured 2026-08-17: of the lanes that invoke
+                      `npm pack`, ZERO extract or execute the result — `--vs-tarball` compares a
+                      FILE LIST (`npm pack --dry-run --json`), it never unpacks.
+```
+
+This matters because it is the same asymmetry this section already argues for: *"execution is the
+load-bearing half"*. An arm discharged by presence checks alone is a `tier1b`-shaped arm wearing a
+`tier2` label — the exact substitution the `tier1b` rung was added to stop. **So: the presence half
+is mechanized and free; the execution half is a named residual, discharged by hand
+(`npm pack` → extract to a clean dir → run the gate → record the command and the output, per the
+`tier2` discriminator) until a lane exists.** Do not cite this arm as fully mechanized. The
+decision's «no new machinery» framing was correct about the *presence* half and overstated about
+the whole — recorded here rather than quietly narrowed, because a reader reaching for this table
+mid-release is exactly the reader who would otherwise skip the half that has no lane.
+
+**What this decision costs, stated rather than hidden.** Of the three legs, **leg B was right and
+the other two were wrong to generalize it**: the `release_2.3.0` marker's `not-applicable` IS a
+defect under this closure (a release delta whose own grounds line concede *"소비자 install 의 게이트
+수용은 바뀐다 (BREAKING 2건)"* — that is the trigger being met, written out in the field that denies
+it), while an ordinary commit touching a shipped script correctly stays `not-applicable`. Row 1
+(PR #368) needs no reclassification: its target was a sibling hub with its own repo, a named peer.
+⚠️ Those three legs were **not decorrelated** — same family, same prompt shape, same canon — so their
+3/3 agreement is closer to one observation than three; it is cited here as *the pattern that exposed
+the definitional hole*, never as three confirmations
+(`[[feedback_decorrelation_axis_is_what_you_send]]`).
+
+**Measured after this edit shipped, and it REFUTES the residual this paragraph first carried.** The
+original text read: *"177 of the 200 corpus markers carry no `standpoint:` line at all … that pool is
+larger than the one measured and remains unexamined."* It has now been examined, and the pool is not
+larger — it barely exists:
+
+```
+201 markers · 24 carry `standpoint:` · 177 do not
+  172   predate the field itself (born 2026-08-14, PR #370 landed 14:13) — structural, not a miss
+    2   written the same day but BEFORE 14:13 (12:29 · 12:39) — also structural
+    3   written after the field existed (16:41 · 19:10 · 21:06)   ← the entire real pool
+    0   absences dated 2026-08-15 or later — adoption is 100% from day two onward
+```
+
+🟥 **The first step was decomposition, not adjudication.** Counting "no field" as "not recorded"
+folds *the field did not exist yet* into *the author skipped it* — the same `not-found ≠ 0` collapse
+this session hit three separate times (`[[feedback_not_found_is_not_zero_family]]`). Splitting by the
+field's own birth timestamp is what turned 177 into 3.
+
+**Hand-check of all 3, judged from the real diffs** (their markers use the pre-2026-08-17 four-letter
+`axes-run` notation, where `b` means first-real-use and NOT standpoint — reading the marker's own
+self-description instead of the diff would have inverted two axes):
+
+| commit | delta | verdict under Q0 |
+|---|---|---|
+| #375 `cedd8ac` | `version_lockstep_check.sh` +11 lines, **all comment** | `not-applicable` would have been correct — a **missing line**, not a wrong judgment |
+| #374 `0690ba7` | 7 files, +409 — shipped gate scripts plus `templates/degrade_direction_scan.sh` | 🟥 **genuinely under-recorded** (Q0-ⓑ, and `templates/` propagates to field harnesses) |
+| #373 `549a4bc` | `ko-tech-writer/SKILL.md` +63/−12 (shipped plugin) | 🟥 **genuinely under-recorded** (Q0-ⓑ) |
+
+**The direction matches §6's earlier finding: over-claiming 0, under-recording only.** A gate that
+tightens *"were you really tier2?"* cannot catch this direction by construction.
+
+⚠️ **Retroactive-application caveat**: Q0 was written 2026-08-17 and these three are 2026-08-14, so
+their authors could not have applied it. What survives the caveat is narrower and still real — the
+**field existed** by then, so the absent line is a gap independent of Q0.
+
+**Consequence for sequencing**: the argument for postponing mechanization was *"absence is the
+dominant reality, so validating values would only tighten a recording minority."* That premise is
+**dead** — recording is 100% from 2026-08-15 onward. ⚠️ The refutation does **not** travel to peers:
+pmh-dev's 42 markers carry the field 0 times, and whether that is late arrival or non-adoption is
+**unmeasured** there. `thirdparty:` likewise stands at 2 corpus instances — unmeasured, not clean.
+
 **Relationship to `harness_verification_core_extended.md`'s core/extended axis**: tier2 and tier3
 are both "extended" in that document's sense (they require a cluster member's engine or repo to
 discharge) — this field does not compete with that doctrine, it subdivides one corner of it.

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

@@ -110,6 +110,11 @@ this chamber's field emit terminus); an **FH-internal utility** (a skill/script/
 field harness) instead routes through the **New-Skill Pre-Commit gate + `asset-placement-gate`** (the
 same gate every FH asset passes). KILL emits nothing — the workspace stays as the evidence record.
 
+> 🟥 **2026-08-17 이후 이 문단은 단독으로 읽으면 틀린다.** 아래 «clears **all four**» 중
+> **(1) net-new 는 더 이상 KILL 사유가 아니다**(→ `CURATED` 라우팅) — §3-SCREEN-2026-08-17 로
+> 대체됐고, (2) 는 `NOT-APPLICABLE` 라우팅이다. **(3)·(4) 는 KILL 로 그대로 유효하다.**
+> 아래 본문은 그 정정 이전의 원문이며 이력으로 보존한다.
+
 **EMIT-worthiness — the measured screening criterion (runs #5–#6, 2026-07-14)**: six chamber runs, EMIT
 0/6, all KILL. A candidate is emit-worthy only if it clears **all four** of — (1) **net-new** (not a
 reinvention of an existing FH/official asset, nor a cosmetic re-wrap of code that already ships — runs
@@ -132,6 +137,90 @@ standalone graduations — not yet *birthing*. **Graduation order** (run #6's po
 hub-state-dependent capability graduates hub-internal → proven in use → THEN extracted portable, never
 speculated standalone-first — the only path every successfully-portable FH asset actually took.
 
+---
+
+### 🟢 §3-SCREEN-2026-08-17 — **(1) net-new 는 더 이상 KILL 사유가 아니다** (운영자 결정)
+
+> *"사람들이 자신이 구상한 하네스를 인큐베이팅으로 해서 출하하려는데, 그럴 때마다 항상
+> **«이미 있는 기능이야»라고 리젝시키면 쓰고 싶은 생각이 들까?** 그것보다는 «이미 이러한
+> 레퍼런스가 있는데 **너만의 방법으로 커스터마이징하고 싶다면 여기서 출발해보자**»가 되어야 할
+> 것 같아. **인큐베이팅이 필요없다면 큐레이팅으로 가면 되는 거고.**"*
+> · *"**그 사람이 만들려는 걸 인큐베이터가 막을 필요가 있을까. 그냥 만들게 두면 되지.**"*
+> · *"인큐베이터는 **훈수를 놓게 하기 위한 장치가 아니라**, 원하는 프로젝트나 하네스를
+> **출하 전부터 미리 굴려보고 사용해보게 하는 에뮬레이션**과 그로 인해 자신만의 것을
+> **성숙하게 출하시키기 위한 장치**"*
+
+**바뀌는 것 — 기준은 남고, 그 기준의 «판정 결과»가 바뀐다:**
+```
+전       net-new 미달  →  KILL          (후보가 회수된다. 사용자는 빈손으로 돌아간다)
+후       net-new 미달  →  **CURATED**    (선행 목록 + 가장 가까운 것 + 그것이 안 덮는 델타를 준다)
+                          → 사용자가 «그거 쓸게» 면 거기서 끝(큐레이팅 종료)
+                          → 사용자가 «내 걸 만들래» 면 **인큐베이터로 들어간다**
+```
+🟥 **전환점은 판정이 아니라 의사다.** 인큐베이터는 「이게 새로운가」를 묻지 않고 「너 만들 거냐」를
+묻는다. 그리고 선행 목록은 **회수 통보가 아니라 재료 목록**이다 — 아래 §3-SCREEN-b.
+
+🟥 **초판이 여기서 게이트를 무력화했고, 적대검증이 커밋 전에 잡았다. 그 정정을 남긴다.**
+초판은 «진짜 KILL» 을 셋으로 줄이며 **(3) 을 「precision 을 만들 수 없음(원리적 불가)」으로
+바꾸고 (4) 를 「형태 라우팅」으로 격하**했다. 둘 다 틀렸다:
+- **(3) 의 원문은 «원리적 불가» 가 아니라 «실측 미달» 이다** — *"run #5's rule scored **5/5
+  false-positive** on 111 real files; run #6's heuristic scored **14/22 false-fire**"*.
+  초판 문장대로면 **런 #5·#6 이 KILL 이 아니게 된다**(둘 다 precision 을 *만들 수는* 있었다).
+- **합산이 진짜 문제였다**: 이 절이 챔버의 실증된 값어치를 셋으로 적는데
+  (*"preventing **reinventions** · **low-precision births** · **premature standalone
+  graduations**"*), 초판이 재발명→CURATE · (3)→원리적불가 · (4)→형태라우팅 으로
+  **셋 다 뺐다.** 남는 entry 스크린이 「사용자가 만들겠다고 하나」 하나뿐이 됐다.
+
+**그래서 이렇게 정리한다 — entry 와 exit 를 섞지 않는다** (§3-c 가 *"two different questions,
+**do not merge them**"* 이라고 명시한 그 분리):
+
+```
+── ENTRY (들어갈 때, 이 절) ──────────────────────────────────────────────
+ (1) net-new 미달        → **CURATED**  라우팅. KILL 아님 (§3-SCREEN-2026-08-17)
+ (2) artifact-shaped 미달 → **NOT-APPLICABLE**. 판단-방법은 이 인큐베이터의 산출 형태가 아니다
+ (3) precision **실측 미달** → **KILL 유지** 🟥 «못 만든다» 가 아니라 «돌려봤더니 나빴다» 다
+ (4) hub-state 의존       → **KILL 유지** 🟥 premature standalone graduation 방지가 이 축의 일이고,
+                            §3 말미의 Graduation order(hub-internal → proven → extract)가 그 처방이다
+ ★ 사용자가 «안 만들래»    → **종료**(큐레이팅으로 끝. KILL 원장에 세지 않는다)
+
+── EXIT (나올 때, §3-c) ──────────────────────────────────────────────────
+ «설 수 없다»(inability-to-run) → **KILL**.  약함은 KILL 아님(§3-c ④)
+```
+🟥 **원리적으로 precision 을 만들 수 없는 대상**(판별 쌍을 구성할 수 없는 것)은 KILL 이 아니라
+**`NOT-APPLICABLE`** 이다 — 후보의 실패가 아니라 **이 인큐베이터의 바가 안 맞는 것**이다.
+
+⚠️ **§3-c 의 한 문장이 이 정정으로 갱신된다**: *"clear this one and fail the first
+(**alive, but a reinvention**)"* — 그 분기는 이제 KILL 이 아니라 **CURATED 로 라우팅**된다.
+
+**⚠️ 경계가 사라지는 것은 아니다.** 재발명이라는 *사실*은 여전히 측정하고 기록한다. 바뀐 것은
+그 사실을 **누구에게 무엇으로 주느냐**다: 게이트의 판정 근거 → 제작자의 출발점.
+
+### §3-SCREEN-b — **선행은 재료다** (인큐베이팅 가속화, 운영자)
+
+> *"앞서 찾았거나 정말 새로운 거라면 검색한 레포 중에서 **배워올 만한 것들을 일부만 빌려와서
+> 개발해 나가는 것**이 곧 인큐베이팅 **가속화**의 방법이 되기도 하겠지. 제로부터 자신만의
+> 아이디어만으로 하는 게 아니라 **프런티어에서 배워옴으로서 시작점부터 프런티어급 가능성을
+> 품은 채 태어나게 하는 것.** 개발자들이 코드를 다 새로 짜는 게 아니라 **구글링하는 전통**이
+> 있던 것처럼."*
+
+🟥 **가장 날카로운 형태**: **재발명 위험이 높다는 것은, 그만큼 빌려올 선행이 많다는 뜻이다.**
+옛 taxonomy 는 이것을 **거꾸로** 읽었다 — 재료가 풍부할수록 죽였다.
+```
+전    레퍼런스 발견 → KILL 근거   → 배출 확률 0 · 사용자는 빈손
+후    레퍼런스 발견 → 빌드 재료   → 시작점부터 프런티어급 · 사용자는 목록을 들고 간다
+```
+**같은 정보, 소비처만 바꾸면 정반대로 작동한다.** 그리고 이건 §3-c 의 EMIT 바(«설 수 있나»)를
+**더 쉽게 넘게 만든다** — 즉 큐레이팅은 인큐베이팅의 **관문이 아니라 성공률을 올리는 장치**다.
+
+**실물 대조(챔버 런 #13 `n-eff-probe`, 2026-08-17)**: K1(재발명)으로 KILL 됐고, 그 근거였던
+선행 5건(capture-recapture · double-fault measure · Snyk VulnBench · BenchGuard · SAST overlap)은
+새 taxonomy 에서 **부품 목록**이다 — 통계량은 기성품을 쓰고 새로 만들 것이 「크로스-노드 배선 +
+픽스처」 하나로 줄어든다. **판정을 소급해 무르지는 않는다**(사전등록 원칙). 바뀐 것은
+**다음 후보가 같은 자리에서 어떻게 처리되는가**다.
+
+> **정본**: `tracks/_meta/fh_signal_2026-08-17_incubator-is-not-a-gate.md`
+> — 흐름 전체 · 큐레이팅의 자리(⑤ 증폭자) · 진입로 B(축적 기반 제안) · 원장 과소계상 실측.
+
 **Chamber scope — what belongs in the chamber at all (run #7, 2026-07-14)**: run #7 tested a hub-internal
 reactivation of the cluster-wizard signal and KILLed it — decisively on its own merits (its "narrow
 net-new" claim collapsed against the real shipped registry and an already-existing synergy skill), but
@@ -218,7 +307,89 @@ meta harness    easy to birth (a declaration starts one) │ needs endless tendi
 
 A meta-harness cannot clear a bar that reads *"walks on day one"* — not because it is worse, but
 because unbounded growth is its point. FH itself is the standing evidence: it is tended continuously,
-by design. **Therefore a meta-harness candidate is not a chamber candidate.**
+by design. ~~**Therefore a meta-harness candidate is not a chamber candidate.**~~
+
+### 🟥 §3-a-1-2026-08-17 — 위 결론 문장은 **폐기한다. 범위가 과했다** (운영자 결정)
+
+**폐기 사유 ① — 아래쪽 범위는 이미 넓혀져 있었고, 이 파일이 그 확장을 반영하지 않았다.**
+`ship_readiness_gate.md §Ⓑ-layering`(2026-08-16, 운영자 발화 기반)이 ② 의 범위를 이렇게 적는다:
+> *"② 프로젝트 인큐베이터 | **유닛을 낳는다 — 하네스만이 아니다.** … 범위가 **하네스 · 스킬 ·
+> 에이전트** · 하네스 형태가 아닌 일반 레포까지다"*
+
+🟥 **초판은 이걸 «8일 전에 뒤집혔는데 안 고쳐졌다 = half-fix 전파 결함» 이라고 적었다. 틀렸고,
+적대검증이 잡았다** — 그 줄이 넓힌 것은 사다리의 **아래쪽**(스킬·에이전트·일반 레포)이고,
+폐기 대상 문장은 **위쪽**(meta-**harness**)에 대한 진술이라 **둘은 논리적으로 양립한다**
+(하위를 포함한다고 상위가 포함되지 않는다). 게다가 그 줄에 **「md 규율」은 없다** — 그건
+2026-08-17 운영자 발화에서만 나온다. **결함 귀속을 철회하고 사유를 약화한다**: 뒤집힌 게
+아니라 **범위 확장이 이 파일에 반영되지 않은 것**이다. (그리고 폐기 자체는 사유 ③ 으로 선다.)
+
+**폐기 사유 ② — 논거가 실제로 덮는 범위는 «하네스 급» 뿐이다.**
+위 논거는 *"unbounded growth 가 본질이라 day-one walk 를 못 넘는다"* 인데, 그건 **meta-harness**
+에 대한 진술이다. 스킬 · 에이전트 · md 규율은 **day-one walk 가 가능하다 — 🟥 단 미검증이다.**
+
+⚠️ **초판은 «실제로 넘고 있다» 고 적었는데 근거가 없었고, 반례가 같은 레포에 있다.**
+day-one walk 의 정의는 *"on the first run, with the user adding nothing, the thing produces
+something useful"* 이고 반대말이 `built-but-not-wired`, 그리고 *"**wiring is part of the birth**"*
+다. **md 규율은 구조적으로 호출부가 없다**(살리언스). 실제 반례:
+`.claude/rules/fh_4axis_gate.md` 의 `standpoint:` 필드 — *"Still validated by nothing — zero hook
+lines, no fixture suite"* 였고, `tier1b` 등급이 **없어서 정적 리뷰가 tier2 로 기록**됐다.
+`axes-run` 기호 키도 53건 중 2건이 옛 의미로 쓰였다. **태어났고 안 걸은 md 규율들**이다.
+
+⇒ **유닛 클래스별 day-one walk 판정자를 따로 건다**:
+```
+스킬 · 에이전트   첫 런에서 사용자가 아무것도 안 더하고 쓸 만한 산출이 나오는가
+md 규율          🟥 **블라인드 floor-tier sim 이 실제로 그 규율을 발화하는가**
+                 (CLAUDE.md §Skeleton, Not Muscle — "done 은 블라인드 세션이 실제로 발화하는 것")
+```
+
+**폐기 사유 ③ — 그 셋이 이 인큐베이터의 최대 산출이다** (운영자, 2026-08-17):
+> *"**FH 의 스킬 상당수는 후자식(축적 기반)으로 만들어졌고** 전자도 거기에 해당하지.
+> FH 스킬은 **내 아이디어로 발명**한 거니까."* ·
+> *"인큐베이터의 **최대 레버는 하네스**이지만 그 **하위의 것들은 다 포함**된다.
+> 스킬 · 에이전트 · **md 규율** 등…"* ·
+> *"인큐베이션 대상은 마감시점 정리 시 **FH 자체가 될 수도 있다.**"*
+
+### 🟥 그러면 경계가 필요하다 — 판별 기준 (운영자)
+
+경계 없이 폐기만 하면 인큐베이터 정의가 **«FH 가 한 모든 것»**이 되어 계상이 무한대가 되고,
+그건 1건만 세는 것과 똑같이 못 쓴다. 기준은 이것이다:
+
+> *"**스킬 없이도 FH 는 동작하지만, 그걸 단축시킬 유닛을 낳은 것까지는 인큐베이팅으로 봐야
+> 한다.**"*
+
+```
+❌ 「FH 가 그 일을 했나」          — 이러면 전부가 인큐베이팅이라 측정 불능
+⭕ 조건 1  「그 일을 **단축시키는 유닛을 낳았나**」
+⭕ 조건 2  「그 유닛이 **자기 소비처를 새로 갖는가**」 ← 🟥 **크기 축. 둘 다 필요하다**
+           (별도 레포 · 플러그인 엔트리 · 독립 호출면 — «호출부가 새로 생겼나»)
+
+범위   하네스 ← 최대 레버
+         ⊃ 스킬 · 에이전트 · **md 규율**
+         ⊃ 하네스 형태가 아닌 일반 레포
+```
+🟥 **조건 1 만으로는 계상이 무한대가 된다 — 적대검증이 반례를 냈다.**
+> `templates/.git-hooks/pre-commit` 에 필드 검사 한 줄 추가 → ⓐ md 규율이고 ⓑ 그 일을 단축시키고
+> ⓒ 「유닛」으로 셀 수 있다 = **세 조건 충족.** 그런데 그건 평범한 Mode D 자기개발이고
+> **4축 게이트가 이미 관할한다.** 여기에 «대상이 FH 자체일 수 있다» 가 붙으면
+> **모든 FH 세션의 대부분 커밋이 인큐베이팅**이 된다.
+
+**조건 2 가 그걸 자른다**: 기존 훅에 줄을 더하는 것은 **소비처가 이미 있던 것**이라 탈락하고,
+`dashboard-dev`·`ko-tech-writer`(플러그인 엔트리 신설)·`the-bible`(별도 레포)은 통과한다.
+**「일을 했다」와 「유닛이 태어났다」를 가르는 것이 조건 1, 「유닛」과 「기존 것의 확장」을
+가르는 것이 조건 2** 다.
+
+⚠️ **그래도 남는 잔여**: 조건 2 는 「소비처가 새로 생겼나」라는 **사후 관측**이라, 만드는 중에는
+판정이 유보된다. 사전 판정이 필요하면 «이것이 태어나면 어디서 불리는가» 를 INTENT 에 적게 하는
+것이 대응이지만 **미구축**이다.
+
+### 위 ⚠️ 회고 관찰은 어떻게 되나 — **재분류하되 폐기하지 않는다**
+
+아래 회고 관찰(«KILL 된 것 중 chamber-internal metering · hub-internal orchestration ·
+cluster wizardry · org relay 는 meta-shaped 였다»)은 **여전히 유효한 관찰**이다. 다만 그
+처분이 바뀐다: **「스코프 밖이라 KILL」이 아니라 「meta-*harness* 급이라 day-one walk 바를
+다르게 받아야 한다」**이다. `NOT-APPLICABLE` 분리(아래 문단)는 그대로 필요하고, 오히려
+이 정정으로 **더 필요해진다** — 이제 통이 셋이다: `KILL`(못 선다) · `CURATED`(선행이 있다,
+§3-SCREEN-2026-08-17) · `NOT-APPLICABLE`(meta-harness 급이라 이 바가 안 맞는다).
 
 ⚠️ **Retrospective observation, not a finding.** Re-reading the run ledger along this axis: of the
 KILLed candidates, those aimed at chamber-internal metering, hub-internal orchestration, cluster
@@ -387,6 +558,49 @@ one harness sees runtime behaviour and not source structure, another sees source
 runtime. **The meta-harness's job is not to dig a deeper well; it is to make outputs flow across the
 boundary between wells.**
 
+### 4-c. The return leg, and why the cluster exists at all (operator, 2026-08-17)
+
+§4-b says outputs **flow across** the boundary. It does not say what happens to what flows *in*,
+nor why FH pays for the crossing. Both were load-bearing and neither was written down. Operator's
+formulation, in three parts — and the third is the one that makes the first two a strategy rather
+than a nice habit:
+
+```
+1  BORROW-EXECUTE (standing)   FH does not endlessly BUILD the capability it lacks.
+                               It reaches into a cluster harness and RUNS theirs.
+2  INTERNALIZE (selective)     Of the insight that comes back, only what is genuinely worth
+                               adopting is PROPOSED and absorbed. Never automatic.
+3  THE POINT IS TIME           Not capability breadth. What FH buys by not-building is time to
+                               sharpen its OWN edge — and that is what lets it keep pace with a
+                               fast-moving model layer instead of being outrun by it.
+```
+
+🟥 **Without (3), (1) inverts on reading.** "We borrow instead of building" reads as *"FH need not
+have capabilities"* — which turns the cluster into dependency. The operator's claim is the opposite:
+**borrowing is how FH protects its own sharpness.** State (3) whenever (1) is cited.
+
+**The asymmetry in (2) is the whole filter.** Borrowing is constant; absorbing is rare and gated by
+a proposal. Automatic absorption produces a collage of other harnesses' capabilities wearing FH's
+name — the exact opposite of (3), because a collage has no edge to sharpen.
+
+**First recorded run of the full loop (2026-08-17, gstack → qasp, FH as governor).** FH did not
+build a DX/product lens; it stood up the gstack persona (`/plan-devex-review`, `/qa-only`) against a
+qasp change and observed. The review returned three findings FH's and qasp's lenses structurally do
+not ask (guide-promises-vs-delivered-bundle · the shipped document's readability · release-doc
+drift). Then the filter ran, and **it rejected more than it accepted**:
+
+| finding | disposition |
+|---|---|
+| anchor should be *discovery-based*, not a hand-kept list | **rejected** — measured against FH and the transfer did not hold; a control showed the suites believed unwired do run by another path |
+| guide promises ≠ delivered bundle | **rejected** — `package_coverage_check.sh` already covers it |
+| release docs did not follow | **rejected** — §④-b entry-point drift covers half; not enough delta |
+| **a shipped document is never read as a reader before it ships** | **accepted** — and NOT because gstack said so: FH reached the same place independently the same day from a different axis, recording that *"readability is measured only by rendering it or by a person; a static scan catches what is ABSENT, never what is UNREADABLE"* with 12 findings and **0** caught by static scanners. **Two independent arrivals is the internalization signal.** One source alone leaves it a candidate. |
+
+⚠️ **Honest scope**: one run, one target, one third harness. This is an existence proof that the
+loop closes, not a rate. And the filter rejecting 3 of 4 is the expected shape — if it accepted
+everything it would not be a filter, it would be a funnel.
+
+
 Three rules, in falling order of how easily they are broken:
 
 1. **Crossing must not overwrite the receiving harness's identity.** If harness B is deliberately