@chrono-meta/fh-gate 2.0.0 → 2.1.0

package/CLAUDE.md

@@ -43,14 +43,14 @@ core invariants never melt). The nursery also **verifies what it births**: harne
 | **③ AI Collaboration Guide** | Accumulates and distributes best practices for token efficiency and dialogue methodology — "how to ask, delegate, and record". | `CHEATSHEET.md` · `knowledge/shared/dialogue/ai_dialogue_playbook.md` · `MEMORY.md` intent-based + associative recall (`knowledge/shared/dialogue/memory_intent_recall.md`) |
 | **Core Axis** | **Harness Engineering (How)** — the methodology and practice axis that realizes the three layers above. The 6-axis framework is the operating unit. **A harness is a means, not an end** — Field harness: "simpler over time" (complexity = warning signal). Meta-harness: *optimize*, not necessarily simplify — complexity earns its scope; red flags are orphaned, redundant, and decorative units, not complexity itself. | `harness_6axis_framework.md` · `hub_compounding_loop.md` · `claude_code_runtime_flow.md` · `plugins/*/agents/` (sub-agents) |
 
-> **3층 정본 — 공정 · 엔진 · 정체성**: FH 를 설명하는 뼈대는 세 층이고 셋의 관계가 정본으로 적혀 있다 — **3단 공정**(엔진을 벼리는 순서: 초기 영혼 → 중간 탈상관 가속화 → **마무리 4축 태우기**) → **4대 엔진**(영혼·품질게이트·질문하기·맥락유지) → **5대 정체성**(사람이 실제로 쓰는 기능). **Read `knowledge/shared/harness-core/fh_three_layer_canon.md`** before naming, re-scoping, or citing any of the three — it also defines the **4 verification axes** (ⓐ구현 · ⓑ재는 방식 · ⓒ주장 · ⓓ앵커) that the third stage actually consists of, and states why the three are *not* a clean stack. Grade table stays canonical in `ship_readiness_gate.md`; this pointer never carries grades.
+> **3층 정본 — 공정 · 엔진 · 정체성**: FH 를 설명하는 뼈대는 세 층이고 셋의 관계가 정본으로 적혀 있다 — **3단 공정**(엔진을 벼리는 순서: 초기 영혼 → 중간 탈상관 가속화 → **마무리 6축 태우기**) → **4대 엔진**(영혼·품질게이트·질문하기·맥락유지) → **5대 정체성**(사람이 실제로 쓰는 기능). 기억용 형태는 **3단 공정 · 4대 엔진 · 5대 정체성 · 6축 검증**이나 🟥 **6축은 네 번째 층이 아니다** — 3단 공정 ③단계가 무엇으로 이루어지는지다. **Read `knowledge/shared/harness-core/fh_three_layer_canon.md`** before naming, re-scoping, or citing any of the three — it also defines the **6 verification axes** (ⓐ계열 · ⓑ입장 · ⓒ격리 그라운딩 · ⓓ3자대면 · ⓔ첫실사용 · ⓕ되돌림; §1-a 가 최초 4축, §1-a-2 가 2026-08-16 확장) that the third stage actually consists of, and states why the three are *not* a clean stack. 🟥 **축은 «얼마나 적대적인가»가 아니라 «무엇을 받았는가»로 갈린다** — 받는 것이 같으면 리뷰어를 몇 명 붙여도 같은 사각이 남는다. 🟥 **명칭 충돌 — 이 파일 안에 「4축」이 두 개다.** §FH Improvement **4-Axis Auto-Gate** 의 4축(Axis 1 회귀 · 2 적대 · 3 팬텀 · 4 매니페스트)은 **커밋 게이트**이고, 여기 6축은 **검증 축**이다. 부분적으로만 겹치고(Axis 1·4 는 ⓐ~ⓕ 에 대응이 없다) **서로 대체하지 않는다**. 그래서 6축은 「6축 게이트」가 아니라 **「6축 검증」**으로 부른다. Grade table stays canonical in `ship_readiness_gate.md`; this pointer never carries grades.
 
 > **자기 대조는 상시 의무 — 트리거는 발화가 아니라 «지금 FH/PMH 자산을 건드리고 있다»**
 > (운영자 결정 2026-08-09; 이 저장소든 **다른 사용자의 install 이든** 동일). §FH Improvement
 > 4-Axis Auto-Gate 와 **같은 트리거**이므로 새 트리거도 새 파일도 만들지 않는다 — 기록 자리는
 > **4축 마커의 기존 필드**(`axis2-*` · `axis3-*` · `residual`)다.
 > **마커에 반드시 남는 3줄** ① **①영혼** — 설계 *전에* 쓴 «성공 정의 / 절대 안 함»(없으면 `없음`)
-> · ② **돌린 축과 안 돌린 축을 각각 이름으로**(ⓐ구현 · ⓑ재는 방식 · ⓒ주장 · ⓓ앵커)
+> · ② **돌린 축과 안 돌린 축을 각각 이름으로.** 마커 `axes-run` 은 **2026-08-17 부로 여섯 글자**를 요구한다 — **기호 키**(ⓐ계열 · ⓑ입장 · ⓒ격리 그라운딩 · ⓓ3자대면 · ⓔ첫실사용 · ⓕ되돌림). 그 전 날짜의 마커는 옛 **ASCII 네 글자**(a·b·c·d) 그대로다. 🟥 **두 배열은 같은 글자가 다른 축을 가리킨다** — 옛 `b`=첫실사용은 지금 **ⓔ**, 옛 `d`=되돌림은 지금 **ⓕ** 라서, 옛 줄을 그대로 옮기면 축 둘이 조용히 뒤바뀌고 아무 오류도 안 난다. **어느 배열인지는 마커 파일명의 날짜로 판별한다**(`< 2026-08-17` = 옛 4축). ⚠️ **표기법은 판별자가 아니다** — 초판이 «기호 키를 보면 6축인 줄 안다» 고 적었는데 **코퍼스 실측이 반증했다**: axes-run 보유 53건 중 기호 키가 4건인데 그중 **2건이 2026-08-10 자이면서 옛 4축 의미로 기호를 쓴다**(`ⓑ 첫실사용` · `ⓓ 되돌림` — 현 배열에선 각각 ⓔ·ⓕ), 혼용도 1건 있다. 훅은 그 셋을 안 읽으므로 커밋은 안 막지만 **감사자의 grep 은 거기서 틀린 답을 낸다**. ⓑ입장은 값을 여기 적지 않고 **`standpoint:` 자기 필드**를 가리킨다(`ⓑ=→standpoint`, 그 줄이 비면 죽은 포인터라 차단). 즉 산문 정본과 기계가 **축 개수로는 맞았고**, 남은 어긋남은 `standpoint:` 값을 **검증하는 코드가 아직 0줄**이라는 것 하나다(명시된 잔여). 형식 정본 = `.claude/rules/fh_4axis_gate.md §Marker axis fields`
 > · ③ **각 축의 컨트롤과 그 생사**. 축을 «돌렸다»의 **최소 증거 = 컨트롤이 살아 있는 실행 출력**
 > 이다 — 안 고른 이유만 적은 것은 준수가 아니다.
 > **비용 경계**: 넷을 매번 다 돌리지 않는다. 실패 모드에 맞춰 **고른다**.
@@ -122,6 +122,142 @@ onto their single hardest sub-mechanism, and a failure from a **non-harness** ru
 metric — each read a live-but-incomplete thing as zero, each caught by the operator, not self-caught.
 Detail: `[[feedback_reinvention_reflex_normalization_counterweight]]`.)
 
+## Mechanization Boundary — machinery at irreversible edges and channels, judgment left to evolution
+
+**Operator thesis (2026-08-16, verbatim)**: *"기계는 비가역 경계와 채널에만 두고, 판단은 진화에
+맡긴다. 「한 모델로도 도달하지만 진화에 기대어 100%를 뽑는다」는 그 형태에서만 성립한다 — 판단을
+내가 코드로 굳혀두면 그게 바로 진화를 막는 천장이 되니까."*
+
+This is the standing answer to *"should this become a check?"*, and it is **not** "mechanize less":
+
+| Build machinery | Leave to judgment |
+|---|---|
+| **Irreversible boundaries** — publish · delete · history-rewrite · anything a stranger can observe | Whether a given review was deep enough |
+| **Channels** — that a typed field carries a value, that a verdict is typed not grepped, that grounds are attributable | What the right value *is* |
+
+The discriminator: does the check assert a **property of the record** (present · typed · attributable ·
+non-vacuous), or does it assert a **conclusion**? The first is a channel and ages well. The second
+freezes today's judgment into tomorrow's ceiling — and this repo's own thesis is that the model layer
+converges upward while the harness persists, so a frozen conclusion is a harness that gets *worse*
+relative to what it wraps.
+
+**Corollary — tier-visible behavior is not automatically a defect.** Some FH capability only becomes
+reachable at a higher tier. `sonnet_floor_doctrine.md` is unchanged and remains a floor: **base ops
+must run 100% at Sonnet, and a tier-gated *base op* is still a defect.** What this corollary adds is
+the other side — where the gap is in *judgment quality* rather than in whether the capability fires,
+the answer is not always to encode the judgment. Discipline and channel-typing are how Sonnet reaches
+it; a frozen rule is how nobody ever exceeds it.
+
+⚠️ **Applied honestly to this file's own machinery, same day**: the `declined`-grounds lane added to
+`templates/.git-hooks/pre-commit` is a **channel** check (a claim must name attributable grounds) —
+it does not judge whether decorrelation was warranted. But its grounds test is a *vocabulary grep*,
+and a vocabulary list is a small frozen judgment: a legitimately-phrased `declined` in unforeseen
+wording over-blocks. Accepted because the failure is **loud and cheap** (author rephrases) rather
+than silent, and because it mirrors the existing degrade-branch form — named here rather than
+claimed pure.
+
+## Local Execution First — CI is a backstop, never the discovery mechanism
+
+**Operator, 2026-08-16**: *"이 실패가 CI 확인 단계에서야 발견되는 건 매우 늦다 … 로컬에서 그
+[대상 레포]를 통해서 실제로 구동시켜 봤다면 안 발생했을까"* and *"CI 확인도 중요하지만 사실 이는
+**깃헙의 기능에 기대는 것**이라고 봐야 하려나."*
+
+Both halves are load-bearing. **Late**: a red CI check is discovery at the slowest, most expensive
+point in the loop, after push, after the PR, in front of an audience. **Borrowed**: CI is a
+*platform* feature, so a harness that only finds its own defects there has not built a gate — it has
+outsourced one, and it silently inherits that platform's coverage boundaries as its own.
+
+**The order**: run the target's own suite locally, **to completion**, before pushing. Then let CI
+confirm. A green CI on a change whose suite was never run locally is not a second opinion — it is the
+*first* one.
+
+**Why "to completion" is the operative phrase** (measured 2026-08-16, pmh-dev): that repo's
+`validate.yml` was wired the same day, so CI's first run was the suite's first real execution ever —
+there was no "previously known-good" for it to confirm. A partial local run would have missed it too:
+the suite printed `SELFCHECK: FAIL` while **neither `FAIL` nor `❌` appeared anywhere in its output**
+(the failing lane used its own vocabulary, `INSTRUMENT ERROR`), so locating it needed `bash -x` to
+the actual failing line. Reading the tail, grepping for the expected token, or trusting an exit code
+you did not trace are all forms of not-running-it.
+
+**Relationship to the standpoint axis**: this is that axis's execution half, applied to your own
+change rather than to a peer harness — see `field_verdict_crossfamily_gate.md §7`
+«execution is the load-bearing half». Same principle, two surfaces.
+
+## Skeleton, Not Muscle — a wiring change is DONE when the floor tier executes it
+
+**Operator, 2026-08-16, verbatim**: *"배선에 대한 건 소넷이 실제로 돌아갈 수 있는지 봐야 잘 된
+거니까. **근육이 아니라 뼈대 기준으로 돌아야 하는 거야.**"* — and, on having had to ask for it:
+*"초기라서 내가 계속 이렇게 해봐라고 메뉴얼로 요청하고 있는데 **알아서 해야 할 거야.**"*
+
+**근육(muscle)** = a strong model's raw capability carrying a rule that is not actually wired.
+**뼈대(skeleton)** = the harness itself — the structure that makes the rule fire regardless of who
+is running. A rule that only works because the session was smart enough is not wired; it is being
+*carried*. It fails silently the moment a Sonnet session, a fresh install, or a compacted context
+picks it up — which is every install that is not the author's.
+
+**So the definition of done changes.** For any salience-dependent change (a rule, a trigger, an
+enum value, an onboarding path, a doctrine line), "done" is **not** «the text is correct and a
+reviewer agrees». It is: **a blind session at the floor tier, given a realistic situation and not
+told which rule is being tested, actually fires it.** This upgrades `fh_4axis_gate.md`'s target-tier
+sim gate from a near-mandatory step into the completion criterion itself.
+
+**And it is self-dispatched.** Do not wait to be asked to run it. The operator asking *"소넷이 실제로
+돌아갈지 확인은 하겠지?"* is the failure — the sim is part of authoring the change, like the
+known-pair is part of authoring an instrument.
+
+**Why «reads correctly» is not evidence.** A `tier1b` rung was added to the `standpoint:` enum
+precisely so a static review would stop being recorded as `tier2`. The text was correct; a reader
+would agree — and a reader agreeing is not a measurement, which is this paragraph's whole point.
+
+🟥 **RETRACTED (2026-08-17) — the numbers this paragraph used to cite are withdrawn, in BOTH
+directions.** It read: *"Two independent blind Sonnet sims then graded a pure cold-read as `tier2`,
+**0/2** … A static read of my own fix would have scored it PASS. Only running it found the hole."*
+That sim set was **8 runs at `tool_uses: 0`** — the agents never opened a file, so the instrument
+was dead and the grades measure nothing (`tracks/_meta/fh_completed_2026-08-16.md:690`, retracted
+the same day the doctrine was written and **before** this paragraph's own commit). The re-run with a
+live instrument then landed the **opposite** result — the rung was graded correctly — at **reps=1**,
+below this repo's own `reps>=3` bar. **So neither «it failed» nor «it worked» is established.** Do
+not restore either number, and do not read the retraction as proof of the inverse.
+
+**The claim that survives is narrower and does not need those numbers**: a static read cannot
+establish that a rule *fires*, because the thing being tested is whether a reader who is not the
+author lands on the right rung — and the author reading their own text is the one reader guaranteed
+to. That is an argument about what a read can measure, not a measurement. The general principle
+(`field_verdict_crossfamily_gate.md §7`'s execution-over-static asymmetry) rests on its own separate
+field evidence; **this paragraph is no longer one of its data points.**
+
+**Corollary — what a sim failure means.** It is a defect in the *wiring*, not in the floor model.
+The response is to make the rule fire (disambiguate, give it a mechanical discriminator, move it to
+where the actor reads it) — never to conclude the tier is too weak and move on. That conclusion is
+how a harness quietly becomes tier-gated, which `sonnet_floor_doctrine.md` calls a defect of the
+same severity class as a phantom reference.
+
+### Scope, and the target state it exists for (operator, 2026-08-16)
+
+**Scope — not FH-only**: *"FH뿐만이 아니라 **기계화 뼈대를 통해서 돌아가는 것들은 다** 이러한 과정을
+거쳐야 제대로 돌아가는지 아닌지 파악할 수 있을 거니까."* Anything whose behavior depends on a
+mechanized skeleton is in scope: field harnesses, propagated `templates/`, a mapped project's own
+gates, **and code contributed upstream to someone else's repo**. The question «does this actually
+fire for a reader who is not me, at the floor tier?» does not become optional because the artifact
+lives outside this repo.
+
+**Target state**: *"나머지는 정말 **저자(인간 저자)의 취향만** PR에서 첨삭할 수 있도록 하는 게
+목표야."* A PR should arrive with every **mechanical** question already settled — does it fire ·
+does it degrade in the safe direction · does the floor tier execute it · is the claim reproducible —
+so that the only thing left for the human reviewer is **taste**: naming, framing, whether this is
+the change they want. Review time spent re-deriving whether the thing works is review time
+*taken from* the judgment only a human can supply.
+
+**Existence proof, ours, this session**: *"우리가 최근에 클로드온데스크에 기여한 것처럼."*
+`rullerzhou-afk/clawd-on-desk` PR #888 was merged **exactly as submitted, with no changes
+requested** — the owner's words: *"focused, technically sound, and well-tested … we merged it
+exactly as submitted, with no changes needed."* That is the shape: the mechanical case was closed
+before submission (a fixture whose potency was reasoned about in-comment, a lane that re-executes
+the real consumer path rather than asserting a flag), so nothing was left to negotiate but whether
+they wanted it. **This is the bar to hold ourselves to on every outbound PR**, and it is why the
+survivor-lane technique from that same PR is worth absorbing rather than admiring
+(`tracks/_meta/fh_signal_2026-08-16_clawd-survivor-lane-air.md`).
+
 ## Instrument Calibration — before you trust a number, prove the instrument works *here*
 
 An instrument (a scan, a grep, a checker, a diagnostic row, a metric) is a claim about the world only
@@ -387,12 +523,27 @@ raises resolution *within* one standpoint (the author's own repo, the author's o
 target's rules); it does not decorrelate the review's ground-truth source. For a **shared-body /
 cross-harness-boundary** change — scoped by *effect* (alters another harness's behavior, gate
 outcome, or interaction contract), not merely by touching a synced file path — the marker
-additionally carries `standpoint:` — a closed enum (`tier1` content-only · `tier2(<harness>)`
-peer-simulated, ran the target's own repo · `tier2b(<harness>)` same operator, target's real
+additionally carries `standpoint:` — a closed enum (`tier1` content-only · **`tier1b(<harness>)`
+STATIC read of the target's own files, executed nothing** · `tier2(<harness>)`
+peer-simulated, **EXECUTED CODE in** the target's own repo — 🟥 the discriminator is mechanical:
+*name the command you ran and the output you saw*; cannot name one → `tier1b`, always. Reading the
+target's real files, however cold, is `tier1b` (🟥 the "two blind Sonnet sims graded a cold-read
+`tier2`" citation that stood here is **RETRACTED** — dead instrument, `tool_uses: 0`; the live re-run
+inverted it at reps=1, below bar. The **rule** stands on its own wording, not on that sim) ·
+`tier2b(<harness>)` same operator, target's real
 runtime (local wiring visible, not independent) · `tier3(<harness>)` a *different* operator of the
 target harness ran it · `not-applicable` · degrade triad `DEGRADED_NO_TARGET_ACCESS` could-not /
 `DEGRADED_NOT_RUN` did-not / `UNKNOWN` did-not-look — same shape as `crossfamily:`'s triad,
-**distinct literal values**, do not reuse crossfamily's tokens). Naming note: this collides in
+**distinct literal values**, do not reuse crossfamily's tokens).
+🟥 **The execution is the load-bearing half** (operator decision 2026-08-16): a static standpoint
+read competes with cross-family review for the same defect classes and mostly loses — *running the
+target harness locally, to completion*, is the part with no substitute. Measured on one delta the
+same day: static read found 1, running the target's own suite found 2 more, one of which printed
+neither `FAIL` nor `❌` and was unreachable by any read. So **`tier2`+ asserts something was RUN** —
+if the review only read, it is `tier1b`, and `tier1b` is deliberately the weak rung so that
+recording it honestly surfaces that the execution arm is still owed. (Broken on the day it was
+written — a static read was recorded as `tier2` because `tier1b` did not yet exist; a missing rung
+gets filled by the next one up rather than staying empty.) Naming note: this collides in
 English with FH's own persona/viewpoint sense of "standpoint" (`fh-meta:beginner`/`main-player`/
 `expert`) — a different axis (which persona reviews, not whose repo is ground truth); kept as-is,
 not renamed, but do not conflate the two. **Prose-only today** — unlike `crossfamily:`, no
@@ -615,6 +766,7 @@ Proposal format: `"I see [X]. Want me to run /[skill] to [one-line description]?
 | **"이 절 잘라도 되나", "상주에서 빼자", "cut this section", "is this section load-bearing", "ablate this"** — a proposal to REMOVE resident text (the decision `/context-doctor` and `/salience-splitter` reach, not the routing to them) | **Ablation procedure — do not decide by eye.** Canon = `scripts/probe_scope_check.sh` header (arms · isolation · `reps>=3` · pre-registration · the two leak channels); runner precondition = `bash scripts/ablation_calibrate.sh` exits 0; verdicts land in `.claude/regression/ablation_verdicts.md`. **A section is CUT only on a pre-registered question set an isolated arm B answers correctly** — "I read it and it looks redundant" is not a measurement, and arm B answering *confidently wrong* is a KEEP, not a pass |
 | "wrap up this week", "review", "audit", "weekly", "retrospective" | `/harvest-loop` |
 | "pull this into FH", "reverse-harvest", "worth keeping", "harvest pattern", "field pattern" | `/field-harvest` |
+| **you installed or invoked an EXTERNAL asset (a tool, framework, or repo not ours) and ran it against something this hub owns** — `pip install`/`npm i` of an outside framework, cloning a peer repo to run it, adopting an upstream utility. Fires on the ACT, not on a keyword: the trigger is *"I reached outside because ours did not cover this"* | **Sister Asset Protocol** (`knowledge/shared/rules/sister_asset_protocol.md` §Active adoption) — record the resolution difference, list **items to import** AND **items the hub can propagate** (bidirectionality is a prohibition, not a nicety), and where there is no write access write a `tracks/_audit/proposal_*.md` so the operator can decide whether to contribute it upstream. 🟥 Missed 2026-08-16 on exactly this shape: an external red-team framework was installed, run against a field harness, found a real bypass — and was filed as a `type: reference` **tool pointer** with no sister audit at all |
 | "용광로모드", "crucible mode", "absorb this whole corpus", "throw everything in", "re-forge FH identity", "melt this down" (total-immersion absorption, not cherry-pick — esp. a whole corpus on a core FH axis, or a frontier showcase risking FOMO) | `knowledge/shared/harness-core/crucible_mode.md` (read it, run the chain: total-ingest → steel-quench/phantom-quench melt → governor identity-bonding → sim/persona reforge → field-harvest rebirth; the core invariants stay unmeltable) |
 | "review this PR", "check diff", "code review" | code diff → built-in `/code-review`·`/review` · FH-asset coherence → `/hub-cc-pr-reviewer` (role split) |
 | "keep watching X", "poll this", "check every N minutes", recurring WATCH item | built-in `/loop` (interval runner) — pair with the WATCH list, don't hand-poll |
@@ -660,6 +812,40 @@ At session start, determine the last run time from history files and auto-propos
 
 > A cadence reminder the user has repeatedly declined is **muted** per the UAP (see the loop below) — don't re-nag.
 
+#### Expedition (원정) — measured first, cadence only if it earns one
+
+**Operator, agreed and recorded 2026-08-17** (it had been agreed verbally before and was **not in any
+file** — grepped, zero hits; that gap is why this paragraph exists): *"원정이 가치 있고 성공적이었다면
+**주기적으로 제안하는 것**으로 가기로 했었지."*
+
+An **expedition** is a deliberate, extended run that uses the harness cluster at full stretch against
+targets outside this hub — contributing to an external repo, declaring a peer's assets as cluster
+nodes, driving a foreign codebase through FH's own gates. Its operating conditions are unusual and
+must not be judged by another track's: **token cost is expected and pre-approved** (the `/goal-quench`
+budget gate still applies — approval removes the prompt, never the gate), **one session will not
+finish it**, and the success definition is not "expedition completed" but ⓐ **finding the pieces that
+move identities to 🟢 faster than internal work would** and ⓑ **hardening existing weak points by
+stressing them somewhere real**. An expedition that builds nothing and produces those two has succeeded.
+
+**Promotion path — and the interval is set AFTER the first one, not before** (operator, 2026-08-17:
+*"그 주기를 얼마나에 한 번씩 잡아야 할지도 그때 세우도록 할게 — 원정 한 차례 다 마치고 답습한 후에"*).
+Expeditions are **not** on a cadence today; they are proposed case-by-case.
+
+Sequence, in order, and do not skip to the end:
+1. **Run one, all the way through.** Not a slice — a complete expedition, however many sessions it
+   takes (the thread-continuation block on the session card is the carrier).
+2. **Absorb it** (답습) — what came back, what it cost, what it hardened, what it found that internal
+   work would not have.
+3. **Then set the interval**, informed by (2). An expedition's cadence has to be derived from what one
+   actually costs and yields — a number picked before the first run is a guess wearing a schedule.
+
+⚠️ **This deliberately does NOT use the `operations.md` `accepted ≥ 60%` promotion gate.** That gate
+measures how often a proposal class is *accepted*, which is the wrong quantity here: an expedition
+could be accepted every time and still not warrant a schedule, or be proposed once and clearly warrant
+one. The evidence that sets the interval is the **completed run itself**, not an acceptance rate.
+**No new gate, no new cadence table, no new registry** either — when the interval is set, it graduates
+into the existing §Cadence-Rules table like any other row.
+
 #### Event-bound proposals (context-entry, not time)
 
 Some proposals are not *time*-overdue — they fire **once when a specific work context is entered**. `persona-innovator` (ideation/naming + external-frontier absorption) is most valuable in exactly two contexts and friction-noise everywhere else, so it is proposed on context-entry rather than every session or every N days:
@@ -988,6 +1174,37 @@ Closing phrase detected ("wrap up", "done", "good work", "end session", etc.)
        across `package.json` + every `.claude-plugin/plugin.json` + `.claude-plugin/marketplace.json` (single-source =
        `package.json`) → Pre-Publish gate → `npm publish` → `git tag vX.Y.Z` at publish. **Propose, don't
        auto-publish.** (Why lockstep — Codex caches on plugin.json version — + drift-check + tag-drift caveat → §detail below.)
+
+       🟥 **WHICH DIGIT — operator decision 2026-08-17, and it is deliberately NOT strict semver.**
+       There was no policy before this line, which is why one session proposed three different bumps
+       for the same delta on three different (and each individually defensible) grounds. Decide by
+       **what the number tells a reader**, not by whether anything technically broke:
+
+       | Bump | Reserved for (operator's own wording, 2026-08-17) |
+       |---|---|
+       | **major** `+1.0.0` | **any one of three**: ⓐ **완전히 새로 지음** — rebuilt from scratch, not extended · ⓑ **정체성이 확립됨** — an identity of the five (+Ⓑ) actually standing 🟢, not progressing toward it · ⓒ **기능이 혁신적으로 변경되거나 늘어남** — a capability *class* appears or is replaced, not a capability instance. 🟥 **Never** for tightening a gate that already existed |
+       | **minor** `+0.1.0` | 미들급 — new assets, new gate lanes, doctrine that changes behavior; **including changes that break a consumer's gate acceptance**, which then carry a mandatory `BREAKING (gate):` line |
+       | **patch** `+0.0.1` | 트리비아급 — fixes, wiring, docs that change no behavior |
+
+       **The discriminator between major-ⓒ and minor**: *class* vs *instance*. A sixth Wave-1 attack
+       angle is an instance → minor. An attack-angle **registry** where none existed is a class → major.
+       Today's delta is instances and tightenings throughout, which is why it is 2.1.0 and not 3.0.0
+       even though it breaks a gate acceptance.
+
+       **Why gate-tightenings are minor here, stated so it is not mistaken for hiding a break**: what
+       breaks is the **record format of a gitignored local marker**, not an API or the consumer's code;
+       the hook prints exactly what to write instead; and the blast radius needs the consumer to have
+       installed the hook AND be making a load-bearing change AND have used the specific old form.
+       Against that, strict semver would burn a major on every gate we tighten — this repo took 2.0.0
+       for a publish-freshness gate one day and would have taken 3.0.0 for a commit gate the next.
+       **A major number that arrives monthly stops meaning anything**, and the milestone it should be
+       reserved for would have no word left.
+
+       ⚠️ **The condition that makes this honest, and it is not optional**: a minor that breaks gate
+       acceptance MUST carry `BREAKING (gate): <what now blocks> — <the one-line remedy>` in the
+       release description AND the CHANGELOG. Without it this policy is just burying breaks in minors.
+       **Applies from 2026-08-17 forward, not retroactively** (2.0.0 was the same class and is left
+       as-is rather than rewritten).
   → ④-c Handoff lifecycle (cross-machine continuity) — when a durable **result artifact lands** this
        session (mechanical hint: a new `*result*`/`*signal*`/`*_run_*` file in your companion store or
        `tracks/`), do two things: **(a) ④-c stamps** any `"run this/start here"` run-handoff whose
@@ -1050,6 +1267,25 @@ Card update is NOT a sub-step of harvest-loop — even if harvest-loop is skippe
 ① **Agent View pre-read** (see above) → ② Step 0-b cross-check generates removal list → ③ Remove completed items → ④ Add new priorities → ⑤ Fix stale paths/versions → ⑥ Overwrite → ⑦ Output "BEFORE N items → AFTER M items" diff.  
 "Delta update" not "snapshot" — completed items remaining in next session card is a bug.
 
+**Thread-continuation block (operator, 2026-08-16)**: *"특정 주제에 집중해서 진행한 세션이라면
+앞으로도 마감할 때 그 갈래로 이어갈 수 있게 알아서 정리해줘."* When a session ran predominantly on
+**one thread** (an incubation, one field harness, one doctrine arc) — as opposed to scattered
+maintenance — the card additionally carries a **named continuation block for that thread**, without
+being asked:
+
+```
+🧵 <thread name> — 이어가려면
+   지금 어디  : <state, with the artifact that proves it — a verdict line, a test count, a merged PR>
+   다음 한 걸음: <the single next action, concrete enough to start without re-deriving>
+   안 닫힌 것 : <what is open, stated as open — not omitted>
+   읽을 것    : <the 1-3 files that reconstitute context, in read order>
+```
+
+Not a second card and not a summary of the session — it is the **entry point for the next session
+that picks up this thread**, and it is written so that session does not have to re-derive where the
+thread stood. A scattered-maintenance session correctly writes none. Two or more threads → one block
+each, in priority order.
+
 ## Session Sync / Knowledge Push Protocol
 
 > Detailed procedure: `knowledge/shared/rules/sync_push_protocols.md`

package/README.ja.md

@@ -200,7 +200,7 @@ Project B  ──→  CLAUDE.md でハブを接続
 
 | | 正体 | 人が手にするもの |
 |---|---|---|
-| **①** | **マルチハーネスクラスター** | 1つの作業が複数のハーネスに乗り、ガバナンスはその*あいだ*で計算されます |
+| **①** | **ハーネスクラスター** | 1つの作業が複数のハーネスに乗り、ガバナンスはその*あいだ*で計算されます。その荷重を担う下位機構が **クロスハーネス** — 持っていない能力は**呼んで使い**(作らない)、作るべきものが見えたら**取り込む** |
 | **②** | **プロジェクトインキュベーター** | 新しいハーネスが空のスキャフォールドではなく、**生まれた場所で既に歩ける状態**で出てきます |
 | **③** | **ガバナンスゲート** | 出してはいけないものが、覚えて確認する代わりに**機械的に**止まります |
 | **④** | **フロンティア → 組織への伝播** | 外から届いたものが、組織の*内側*まで届ききります |
@@ -246,8 +246,13 @@ Project B  ──→  CLAUDE.md でハブを接続
 4大エンジン    それを可能にする能力              (能力 — できること)
    ↑ 生み出しているのは
 3段工程        そのエンジンを鍛える「順序」      (工程 — どう作られるか)
+   └ ③段階 = 6軸ゲート                          (下の §6つの検証軸)
 ```
 
+覚えやすい形にすると **3段工程 · 4大エンジン · 5つの正体 · 6軸ゲート** です。
+⚠️ ただし **6軸は4つめの層ではありません** — 3段工程の**③段階が何でできているか**です。
+4つを横並びの層として読むと、この節がそもそも直そうとしていた「層が入ってこない」問題が戻ってきます。
+
 **4大エンジン。** それぞれが上のいずれかの正体を足元で支えています。これらはこのページのために発明された
 ものではありません: 出荷準備ゲートが既に、すべての正体をこの同じ4つの能力に対して専用の列で採点して
 いました（[`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)）。ですから
@@ -286,29 +291,59 @@ Project B  ──→  CLAUDE.md でハブを接続
                           2度持つだけです。並列化それ自体には方向がなく、選ぶのは①の判断回路です。
                           これは「働き方」であって、③の最終検査ではありません。
 
-③ 最後に4つの軸で         下の4軸です。敵対的レビューはそのうちの1つであって、全部ではありません
-   焼き切る
+③ 最後に6つの軸で         下の6軸です。敵対的レビューはそのうちの1つであって、全部ではありません —
+   焼き切る               敵対性は**姿勢**であって軸ではありません。どの軸にも乗せられますが、
+                          乗せたところでその軸に見えないものはやはり見えません
 ```
 
-**4つの検証軸** — 「レビューしました」が実際には最初の1つだけを指していた、と判明しがちな場所です。
-真ん中の列を読んでどれを取るかを決め、右の列でそれが何を捕まえるかを確かめてください:
+**6つの検証軸** — 「レビューしました」が実際には最初の1つだけを指していた、と判明しがちな場所です。
+
+🟥 **軸は「どれだけ敵対的か」では分かれません。「何を受け取ったか」で分かれます。** 受け取るものが
+同じなら、レビュアーを何人足しても**同じ盲点が残ります**。ですから下の表でいちばん重要な列は
+*受け取るもの*です:
 
-| 軸 | こういうときに手を伸ばす | 何を捕まえるか | 典型的な計器 |
+| 軸 | **受け取るもの** | 何を捕まえるか | 典型的な計器 |
 |---|---|---|---|
-| **ⓐ 別ファミリー** | その変更が何かを決めるとき — PASS/FAIL、ゲート、安全ルール | **実装**が間違っている | 別のモデルファミリーからのレビュアー (`auto-decorrelation`) |
-| **ⓑ 初の実使用** | 数値 · カウント · スキャンの出力を信じようとしているとき | **測り方**が間違っている | 実際の対象1件に対して一度走らせ、結果を自分の目で見る |
-| **ⓒ 記録のグラウンディング** | 他人がそれを元に動く主張 · 数値 · 引用を書き留めたとき | **主張**が間違っている | 書いていない誰かが、書かれている内容を測り直す |
-| **ⓓ 戻して観察する** | テスト · ガード · 検査を足して、それが自分を守っていると思っているとき | **アンカー**が間違っている — その検査は装飾だ | 守っている対象を消して、*その特定の*検査が赤くなることを確かめる |
-
-**4つを毎回すべて回すわけではなく、それが設計です。** 1行の修正はどれも要求しません。verdict を返す
-変更は ⓐ を要求します。公表する数値は ⓑ と ⓒ を要求します。新しいガードは ⓓ を要求します。不可逆な
-表面 — publish, delete, 履歴の書き換え — は、その失敗モードがさらしている軸を要求し、迷ったときは
-もう1つ回すほうに倒します。レビュアーを増やすことは、軸を1つ足すことと同じではありません。
-
-これら4つの外側に、もう1つの軸があります。それは*何を*検査するかではなく、*誰の*グラウンドトゥルースに
-立つかを変えるからです: **standpoint（立ち位置）** — 変更が別のハーネスへまたがるとき、自分の読み方では
-なく、対象側自身のレポとルールから diff を走らせてください
-([`field_verdict_crossfamily_gate.md §7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md))。
+| **ⓐ 別ファミリー** | diff + 著者のフレーミング | **実装**が間違っている | 別のモデルファミリーからのレビュアー (`auto-decorrelation`) |
+| **ⓑ 立ち位置 (standpoint)** | diff + **対象ハーネス自身の正典** | **引用した規約が本当にそう言っているか** | そのハーネス自身のレポ · ルールの側で diff を走らせる ([`§7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md)) |
+| **ⓒ 隔離されたグラウンディング** | 著者が書いた文 + いまのツリー | **主張**が間違っている | 書いていない誰かが、書かれている内容を測り直す |
+| **ⓓ 第三者との対面** | 問題 + **他人のコードベース** | **これはもう解かれているのでは** · 自分の変更が他人のレポのどこに触るか | 無関係な第三のレポで同じ問題を見る |
+| **ⓔ 初の実使用** | 実物の対象1件 | **測り方**が間違っている — 計器の計器 | 実際の対象1件に対して一度走らせ、結果を自分の手で確かめる |
+| **ⓕ 戻して観察する** | 配線を消したツリー | **アンカー**が間違っている — その検査は装飾だ | 守っている対象を消して、*その特定の*検査が赤くなることを確かめる |
+
+**6つを毎回すべて回すわけではなく、それが設計です** — 掛け算せずに、**選んでください**:
+
+```
+1行の修正（typo · gitignore）      何も焼きません。①の回路すら不要 — 答えが1つなら、
+                                   植えること自体がオーバーヘッドです
+通常のコード変更（可逆）            ⓔ 初の実使用 + ⓕ 戻し
+verdict · ゲートのコード           + ⓐ 別ファミリー — verdict のロジックは、著者と同じ楽観を
+                                   共有するレビュアーが**構造的に**見落とします
+他人のハーネスに触れる変更          + ⓑ 立ち位置 — ファミリーを3つ足しても、全員が自分の
+                                   フレーミングを飲んでしまえば「その正典が本当にそう
+                                   言っているか」は誰も見ません
+超大型 · 不可逆                    + ⓒ 隔離 + ⓓ 第三者との対面。全部焼きます
+```
+
+⚠️ **ⓓ 第三者との対面はもっとも高くつき、固有の収穫がもっとも小さい軸です。** ところがその少数は
+すべて**境界をまたぐ種類**でした（他人がすでに廃止していたルール · 他人のレポが自分のファイルを
+import している）。小さく戻せる変更ではそうした項目は**そもそも発生せず**、大きく不可逆なときは
+まさにその2つが事故になります。コストが正当化されるのはそこです。
+
+**なぜこれが基盤モデルの進化で置き換わらないのか** — 軸は*レビュアーの能力*ではなく**入力**で
+定義されます。モデルが強くなっても、**「受け取っていない情報」は依然として見えません。** スキャフォー
+ルディングはモデルが良くなれば脱げますが、**入力境界の脱相関は脱げません**。そして単独の著者は定義上
+自分の入力の外へは出られません。🟥 正直な際どさ: エージェントが**ツールで自分から入力を取りに行く**と
+境界はぼやけます — 実際「ストア全件が使われていない」と「例外の握り潰し」は ⓐ · ⓒ でも捕まえられる、
+と外部の判定は見ました（自分で grep するからです）。逆に「他人のレポが過去に廃止したルール」は
+**ツールでも取りに行けません** — そのプロジェクトのレビュー履歴にアクセスする理由がそもそも
+ないからです。ⓓ が残るのはそこです。
+
+> 🟥 **引用する前に読むべき限界**: この6軸の表は **n=1**（1つの成果物 · 1セッション · 1人の著者）です。
+> 軸の「非重複」が構造的なのか、その日の偶然なのかは**未測定**です。さらに著者の自己採点を取り除く
+> ために、発見16件を**出典を消したまま**別ファミリーの分類器2つにブラインドで判定させたところ、
+> 著者が ⓓ に帰属させた**5件のうち3件が別の軸と判定されました** — その3件は「その軸が必要だったもの」
+> ではなく「別の軸が見落としたもの」でした。表の帰属はその分だけ割り引いて読んでください。
 
 > **正直な注記 — これはきれいな積み木ではなく、そこが要点です。** 段階①と段階③はエンジンと同じ素材で
 > できているので、下の層が上の層を使っています。この矛盾は*主語*で解けます: **エンジン**は FH が

package/README.ko.md

@@ -197,7 +197,7 @@ Project B  ──→  CLAUDE.md에서 허브 연결
 
 | | 정체성 | 사람이 얻는 것 |
 |---|---|---|
-| **①** | **멀티하네스 클러스터** | 하나의 작업이 여러 하네스를 타고, 거버넌스는 그 *사이에서* 계산됨 |
+| **①** | **하네스 클러스터** | 하나의 작업이 여러 하네스를 타고, 거버넌스는 그 *사이에서* 계산됨. 하위 기제 **크로스하네스** = 없는 능력을 **호출해 쓰고**(안 짓는다) 지어야 할 것이 보이면 **흡수한다** |
 | **②** | **프로젝트 인큐베이터** | 새 하네스가 빈 스캐폴드가 아니라 **태어난 자리에서 이미 걷는 상태로** 나옴 |
 | **③** | **거버넌스 게이트** | 나가면 안 되는 것이 점검을 기억해서가 아니라 **기계적으로** 막힘 |
 | **④** | **프런티어 → 조직 전파** | 밖에서 들어온 것이 조직 *안쪽까지* 내려앉음 |
@@ -242,8 +242,13 @@ Project B  ──→  CLAUDE.md에서 허브 연결
 네 엔진        그것을 가능하게 하는 능력          (능력 — 무엇을 할 수 있나)
       ↑ 만들어내는 것
 3단 공정       그 엔진들을 벼리는 순서            (공정 — 어떻게 만들어지나)
+      └ ③단계 = 6축 게이트                       (아래 §여섯 검증 축)
 ```
 
+기억하기 좋은 형태로는 **3단 공정 · 4대 엔진 · 5대 정체성 · 6축 게이트**입니다.
+⚠️ 다만 **6축은 네 번째 층이 아닙니다** — 3단 공정의 **③단계가 무엇으로 이루어지는지**입니다.
+넷을 나란한 층으로 읽으면 이 절이 애초에 고치려던 «층이 안 들린다» 문제가 되돌아옵니다.
+
 **네 엔진.** 각각은 위의 어떤 정체성이 딛고 서 있는 바닥입니다. 이 페이지를 위해 만들어낸 것이
 아닙니다: 레디니스 게이트가 이미 모든 정체성을 이 같은 네 능력에 대해 별도 열로 채점하고 있었고
 ([`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)), 이름을 붙인 것은
@@ -284,29 +289,90 @@ Project B  ──→  CLAUDE.md에서 허브 연결
                         병렬화 자체엔 방향이 없고, 고르는 것은 ①의 판단 회로.
                         이건 «일하는 방식»이지 ③의 마감 검사가 아님
 
-③ 끝에서 4축으로       아래 네 축. 적대검증은 그중 하나이지 전부가 아님
-   태우기
+③ 끝에서 6축으로       아래 여섯 축. 적대검증은 그중 하나이지 전부가 아님 —
+   태우기                 적대성은 **자세**지 축이 아닙니다. 아무 축에나 얹을 수 있고,
+                          얹어도 그 축이 못 보는 것은 여전히 못 봅니다
 ```
 
-**네 검증 축** — "리뷰했다"가 실제로는 이 중 첫 번째 하나만 뜻하는 경우가 대부분입니다. 가운데 열을
-보고 하나를 고르고, 오른쪽 열로 그것이 무엇을 잡는지 확인하세요:
+**여섯 검증 축** — "리뷰했다"가 실제로는 이 중 첫 번째 하나만 뜻하는 경우가 대부분입니다.
+
+🟥 **축은 «얼마나 적대적인가»로 갈리지 않습니다. «무엇을 받았는가»로 갈립니다.** 받는 것이 같으면
+리뷰어를 몇 명 붙여도 **같은 사각이 남습니다**. 그래서 아래 표에서 가장 중요한 열은 *받는 것*입니다:
 
-| 축 | 이럴 때 꺼내 쓴다 | 무엇을 잡나 | 대표 계기 |
+| 축 | **받는 것** | 무엇이 틀린 경우를 잡나 | 대표 계기 |
 |---|---|---|---|
-| **ⓐ 다른 패밀리** | 그 변경이 무언가를 결정할 때 — PASS/FAIL, 게이트, 안전 규칙 | **구현**이 틀림 | 다른 모델 패밀리의 리뷰어(`auto-decorrelation`) |
-| **ⓑ 첫 실사용** | 숫자·개수·스캔 출력을 믿으려 할 때 | **재는 방식**이 틀림 | 진짜 대상 하나에 한 번 돌리고 결과를 손으로 확인 |
-| **ⓒ 기록 그라운딩** | 남이 그것을 근거로 행동할 주장·수치·인용을 적었을 때 | **주장**이 틀림 | 그것을 쓰지 않은 사람이 적힌 내용을 다시 잼 |
-| **ⓓ 되돌려 관찰** | 테스트·가드·검사를 추가하고 그게 나를 지킨다고 믿을 때 | **앵커**가 틀림 — 검사가 장식임 | 그것이 지키는 대상을 지우고 *바로 그* 검사가 빨개지는지 확인 |
-
-**넷을 매번 다 돌리지 않으며, 그것이 설계입니다.** 한 줄짜리 수정은 어느 축도 벌지 못합니다.
-판정을 반환하는 변경은 ⓐ를 벌고, 공개되는 수치는 ⓑ와 ⓒ를, 새 가드는 ⓓ를 법니다. 비가역 표면 —
-공개 · 삭제 · 히스토리 재작성 — 은 자신이 노출된 실패 모드에 해당하는 축을 모두 벌며, 애매하면
-하나 더 돌리는 쪽에 이익을 줍니다. 리뷰어를 늘리는 것은 축을 더하는 것과 다릅니다.
-
-한 축이 이 넷의 바깥에 따로 있습니다. *무엇을* 검사하는지가 아니라 *누구의* ground truth 위에
-서는지를 바꾸기 때문입니다: **관점(standpoint)** — 변경이 다른 하네스로 넘어갈 때, 그 diff를 당신의
-해석이 아니라 대상 하네스 자신의 레포와 규칙에서 돌립니다
-([`field_verdict_crossfamily_gate.md §7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md)).
+| **ⓐ 다른 패밀리** | diff + 저자의 프레이밍 | **구현**이 틀림 | 다른 모델 패밀리의 리뷰어(`auto-decorrelation`) |
+| **ⓑ 입장** | diff + **대상 하네스의 정본** | **인용한 규약이 정말 그렇게 말하나** | 그 하네스 자신의 레포·규칙에서 diff를 돌림 ([`§7`](knowledge/shared/harness-core/field_verdict_crossfamily_gate.md)) |
+| **ⓒ 격리 그라운딩** | 저자가 쓴 문장 + 지금의 트리 | **주장**이 틀림 | 그것을 쓰지 않은 쪽이 적힌 내용을 다시 잼 |
+| **ⓓ 3자 대면** | 문제 + **남의 코드베이스** | **이미 풀린 문제 아닌가** · 내 변경이 남의 레포를 어디서 만지나 | 관련 없는 제3의 레포에서 같은 문제를 봄 |
+| **ⓔ 첫 실사용** | 실물 대상 한 건 | **재는 방식**이 틀림 — 계기의 계기 | 진짜 대상 하나에 돌리고 결과를 손으로 확인 |
+| **ⓕ 되돌려 관찰** | 배선을 지운 트리 | **앵커**가 틀림 — 검사가 장식임 | 지키는 대상을 지우고 *바로 그* 검사가 빨개지는지 확인 |
+
+**여섯을 매번 다 돌리지 않으며, 그것이 설계입니다** — 곱하지 말고 **고르세요**:
+
+```
+한 줄 수리(오타 · gitignore)   아무것도 안 태움. ①영혼도 불요 — 답이 하나면 심는 것이 오버헤드
+일반 코드 변경(가역)            ⓔ 첫 실사용 + ⓕ 되돌림
+판정 · 게이트 코드              + ⓐ 다른 패밀리 — 판정 로직은 저자와 같은 낙관을 공유하는
+                                리뷰어가 **구조적으로** 놓침
+남의 하네스에 닿는 변경         + ⓑ 입장 — 패밀리를 셋 붙여도 전부 내 프레이밍을 먹으면
+                                «그 정본이 그렇게 말하나»는 아무도 안 봄
+초대형 · 비가역                 + ⓒ 격리 + ⓓ 3자 대면. 전부 태움
+```
+
+⚠️ **ⓓ 3자 대면은 가장 비싸고 고유 수확이 가장 작습니다.** 그런데 그 소수가 전부 **경계를 넘는
+종류**였습니다(남이 이미 폐기한 규칙 · 남의 레포가 내 파일을 임포트). 작고 되돌릴 수 있는 변경에선
+그런 항목이 **생기지 않고**, 크고 비가역이면 정확히 그 둘이 사고가 됩니다. 비용이 정당해지는
+지점이 거기입니다.
+
+**왜 이것이 기반 모델 발전으로 대체되지 않나** — 축은 *리뷰어의 능력*이 아니라 **입력**으로
+정의됩니다. 모델이 세져도 **«받지 않은 정보»는 여전히 못 봅니다.** 스캐폴딩은 모델이 좋아지면
+벗겨지지만 **입력 경계 탈상관은 벗겨지지 않으며**, 단일 저자는 정의상 자기 입력을 벗어날 수 없습니다.
+🟥 정직한 가장자리: 에이전트가 **도구로 스스로 입력을 더 가져오면** 경계는 흐려집니다 — 실제로
+「저장소 전수 미사용」과 「예외 삼킴」은 ⓐ·ⓒ 도 잡을 수 있다고 외부 판정이 봤습니다(스스로 grep 하니까).
+반대로 「남의 레포가 과거에 폐기한 규칙」은 **도구로도 가져올 수 없습니다** — 그 프로젝트의 리뷰
+이력에 접근할 이유가 애초에 없기 때문입니다. 거기가 ⓓ가 남는 자리입니다.
+
+> 🟥 **인용 전에 읽어야 할 한계**: 이 6축 표는 **n=1**(한 산출물 · 한 세션 · 한 저자)입니다.
+> 축의 «비중복»이 구조적인지 그날 우연인지는 **미측정**입니다. 그리고 저자 자평을 걷어내려고
+> 발견 16건을 **출처를 지운 채** 다른 패밀리 분류자 둘에게 블라인드 판정시켰더니, 저자가 ⓓ에
+> 귀속시킨 **5건 중 3건이 다른 축으로 판정됐습니다** — 그 셋은 «축이 필요했던 것»이 아니라
+> «다른 축이 놓친 것»이었습니다. 표의 귀속은 그만큼 줄여 읽으세요.
+
+### 🟥 「4」가 두 개입니다 — 그리고 예전 이름까지 세면 셋이었습니다
+
+같은 저장소 안에서 「4」가 서로 다른 것을 가리킵니다. 인용하기 전에 어느 쪽인지 확인하세요:
+
+| 이름 | 무엇 | 어디에 붙나 |
+|---|---|---|
+| **4축 게이트** | Axis 1 회귀 · 2 적대 · 3 팬텀 · 4 매니페스트 | **커밋 경계** — 층이 아닙니다 |
+| **4대 엔진** | 영혼 · 품질게이트 · 질문하기 · 맥락유지 | **능력 층** |
+| ~~4축 검증~~ | → **6축 검증**으로 확장됨 | 3단 공정 ③단계의 내용물 |
+
+셋은 **부분적으로만 겹치고 서로 대체하지 않습니다** — Axis 2·3 이 ⓐ·ⓒ 와 가깝지만
+**Axis 1·4 는 검증 축에 대응이 아예 없습니다.** 그래서 6축은 «6축 게이트»가 아니라
+**«6축 검증»**으로 부릅니다.
+
+### 4축 게이트 — 층에 끼지 않고 커밋 경계에 직교로 붙습니다
+
+FH 자산이 바뀌면 **그 세션 첫 커밋 전에** 자동으로 도는 체인이고,
+`templates/.git-hooks/pre-commit` 이 하드 차단합니다. 위 세 층 어디에도 들어가지 않습니다:
+
+| 축 | 계기 | 무엇을 잡나 |
+|---|---|---|
+| **Axis 1 · 후방** | `templates/regression_guard.sh` | 절 소실 · 깨진 참조 · 문법 오류 · 줄 감소 |
+| **Axis 2 · 적대** | `steel-quench` | 트리거 충돌 · 설계 공격면 · 과설계 단계 |
+| **Axis 3 · 전방** | `phantom-quench` | 팬텀 참조 · 없는 경로 · 죽은 외부 링크 |
+| **Axis 4 · 기록** | `edit-manifest` | 예측 영향 기록 — 예측·검증 루프를 닫습니다 |
+
+> **더 알아보려면** — 층·축·계기가 한 장에 배치된 구조 참조와, 각 자리에 어떤 스킬·에이전트·
+> 스크립트가 붙는지의 매핑:
+> [`fh_three_layer_canon.md`](knowledge/shared/harness-core/fh_three_layer_canon.md)
+> (§1-a 최초 4축 · §1-a-2 6축 확장 · §2 엔진 · §3 정체성) ·
+> [`fh_4axis_gate.md`](.claude/rules/fh_4axis_gate.md)(커밋 게이트) ·
+> [`ship_readiness_gate.md`](knowledge/shared/harness-core/ship_readiness_gate.md)(정체성 등급).
+> ⚠️ 정본 표에서 온 배치와 라우팅 판단을 갈라 읽으세요 — 엔진↔정체성 매핑과 위 4축 표는
+> **정본 그대로**이고, 「어느 스킬이 어느 정체성에 붙나」는 **판단**입니다.
 
 > **정직한 주석 — 이것은 깔끔한 스택이 아니고, 그게 핵심입니다.** 1단계와 3단계는 엔진과 **같은
 > 재료**로 되어 있어서, 아래층이 위층을 씁니다. 모순은 *주어*에서 풀립니다: **엔진**은 FH가 당신의