# Notes: insuniverse-docs-40-runtime-vendor-legal-m3

Plan: `.claude/plans/insuniverse-docs-40-runtime-vendor-legal-m3.plan.md`

이 파일은 `/mccp:prp-implement` 구현 창의 리뷰 기록이다. **계획서 본문에 쓰지 않는다** —
`mccp-plan-codex` receipt 가 `plan_hash` 로 계획서를 결박하고 있어 본문 편집은 그 receipt 를
stale 로 떨어뜨린다. 계획서 §NOT Building 도 착수 후 본문 편집을 명시적으로 금지한다.

## Codex Implementation Review

- 호출: `node C:/Users/madsc/.claude/plugins/cache/mccp/mccp/1.32.1/scripts/lib/codex-invoke.js adversarial-review` (fail-closed Bash wrapper, v0.2.2)
- 라운드 수: 0
- **Codex skipped per `MCCP_CODEX_DISABLED=1`** — env-level 정책이며 도구 실패가 아니다.
  근거는 실행 관측이다: 최소 프로브
  `adversarial-review --focus "Reply with the single word OK." --timeout-ms 180000 --json` 이
  `{"ok":true,"stdout":"","stderr":"","durationMs":1,"classification":"disabled","blocking":false,"advisory":false}`
  를 냈다. `durationMs=1` 이 short-circuit 경로임을 보인다 — 프로세스 spawn 이 없었다.
  설정 출처는 `C:/Users/madsc/.claude/settings.json` 4행의 `env.MCCP_CODEX_DISABLED = "1"` 이다.
- 게이트 기록값: `codex_verdict = skipped` · `meta.codex_disabled = true`.
  **`converged` 가 아니다** — cross-gate dedupe(`dedupe.js#evaluateForDedupe`)는 `converged`
  이외의 값에 fail-closed 이므로 이 receipt 는 하류 PR-Codex 를 건너뛰게 만들지 않는다.
- 합치 결론: 없음 — 리뷰가 돌지 않았으므로 합치도 없다. 아래 §2.5.2 목록이 **리뷰를 받지 못한
  결정 집합**이고 그것이 이 절이 남기는 유일한 실질이다.
- YAGNI Triage: 해당 없음 — findings 0건.
- Deferred to backlog: 0 (리뷰 산출 없음). 계획서 §Codex Adversarial Review 의 **잔여 4축**은
  Task 7 의 이월 대상이며 이 창에서 `codex-findings-backlog.md` 로 간다.
- Open Questions: 없음.
- Codex session 참조: 없음 (미호출).

### 이 창에서 새로 생기는 implement-time 결정 (2.5.2 — 리뷰를 못 받은 목록)

계획서가 pre-commit 하지 않은 것만 적는다. Codex 가 꺼져 있어 **아래 7건은 리뷰를 받지 못했다.**

1. `vendor-behaviors.yaml` 제한 리더의 수용 형태 — 계획서 Task 0 은 *"필요한 사실만 읽는 제한
   리더를 두고 모르는 형태는 관용하지 않고 죽는다"* 까지만 정했다. 어떤 키를 어떤 중첩 깊이까지
   받을지, 리스트 항목의 스칼라/맵 혼재를 어떻게 가를지는 미정이다.
2. 신호 소비 계수기의 토큰 매칭 방식 — §구별 신호 로케이터가 토큰 7종과 대상 트리·제외 글롭을
   못박았으나, 단어 경계 정규식인지 부분 문자열 포함인지는 미정이다. 이 선택이 Risks 표의
   *"신호 토큰이 다의어라 계수가 부풀려짐"* 행의 크기를 좌우한다.
3. 동결 3트리의 파일 열거 방식 — M2 하네스는 `git cat-file -p <sha>:<path>` 만 썼고 **트리 전체
   열거는 쓴 적이 없다.** `ls-tree -r` 로 열거한 뒤 `cat-file` 로 여는 2단 형태가 되는데, 그
   조합의 실패 모드(경로 부재 대 저장소 부재)를 M2 와 같은 어휘로 가르는지는 착수 시 결정한다.
4. `사각` 4어휘 재계산의 우선순위 — 관측 7 이 어휘를 정했으나 한 행이 두 조건을 동시에 만족할 때
   (예: codef `no_data` 가 `분류 부재` 이면서 화면에서도 안 갈림) 어느 쪽을 쓰는지는 미정이다.
5. `도달` 3어휘 재계산의 유도 규칙 — 계획서는 *"`#6c` 는 벤더 축 전용 토큰을 함께 본다"* 까지만
   적었다. 계수 임계값과 전용 토큰 목록의 정확한 결합 규칙은 미정이다.
6. 연혁 행 선정 — 계획서가 *"응답 의미가 바뀐 시점만 싣는다"* 로 판정을 저자에게 남겼고 게이트
   `#9` 는 앵커 경로 접촉까지만 본다. Acceptance 가 이미 `(미검증)` 으로 자백한 축이다.
7. `#13` 코드값 패턴 집합 — 계획서가 *"패턴은 표본이고 범위가 아니다"* 라고 사각을 자백했으나
   표본의 구성은 미정이다.

### Security Reviewer

해당 없음 — 이 창의 산출물은 `docs/**` 마크다운 1건과 `.claude/plans/**` 게이트 하네스 1건이다.
인증·암호·비밀값·입력 검증·주입·SSRF·경로 순회·권한 상승 어느 표면도 건드리지 않는다.
Phase 2.5.5 의 트리거 조건(*"security-sensitive areas"*)이 성립하지 않으므로 `security_skipped`
플래그를 세우지 않는다 — 이것은 폴백 은폐가 아니라 **트리거 미성립**이다. M2 receipt 도 같다
(`security_skipped: false`).

### Design Review

`impeccable-detect.js detect --mode implement --json` 실측:
`{"skill_available":true,"design_signal":false,"silent_skip":true,"silent_skip_reason":"no-signal"}`.
SKILL_AVAIL=1 · SIGNAL=0 · DESIGN_INTENT_ACTIVE=0 이므로 2.5.5b 결정표의 silent-skip 행이다 —
receipt 에 `--impeccable-silent-skip --impeccable-silent-skip-reason "no-signal"` 을 넘긴다.
렌더 표면이 없으므로 라우팅(2.5.5b) · 크리티크 루프 · 방향 캡처(2.5.5c) 는 돌지 않고,
그 결과 Phase 3.6 · 3.7 은 아티팩트 부재로 no-op 이다.

## 음성 케이스 관찰 (Task 0 · 계획서 §Validation 이 이 절로 보낸 기록)

계획서 §Validation 이 *"나머지는 하네스가 서는 Task 0 에서 한 번씩 실행하며 그 관찰은 계획서가
아니라 `.claude/notes/` 에 기록한다"* 로 이 절을 예약했다. 아래는 **실행해서 본 출력**이지
예상이 아니다.

### (가) 하네스가 선 시점 — 문서 부재로 12검사가 떨어진다

계획서 Task 0 이 *"이 시점에 `check1`~`check10` · `check12` · `check13` 은 문서 부재로 실패해야
한다"* 를 요구한다. `docs/06-vendors/02-failure-semantics.md` 가 없는 상태에서 `M3_GATES_CHECK0=ok`
로 12건을 돌린 결과 전건 rc=1:

```
check1  rc=1  #1 FAIL: 문서가 없다 — docs/06-vendors/02-failure-semantics.md
check2  rc=1  (#2a 는 인덱스만 보므로 통과한 뒤) #2b 에서 문서 부재로 죽는다
check3..check10 · check12  rc=1  FAIL: 문서가 없다 — …
check13 rc=1  FAIL: 파일이 없다 — …
```

`check2` 만 첫 줄이 `#2a ok` 인 것은 그 하위 검사가 인덱스 자기정합(25 = 24 + 1)만 보기 때문이다.
**하네스가 문서에 맞춰 휘지 않았다는 관찰이 이것이다** — 하네스는 문서보다 먼저 섰고 그 시점에
문서를 보는 모든 검사가 떨어졌다.

### (나) 검사별 음성 케이스 — 변이 → rc=1 → 복원

`docs/06-vendors/02-failure-semantics.md` 를 케이스마다 한 군데씩 깨뜨리고 해당 검사를 돌린 뒤
원본으로 복원했다. 마지막에 sha256 대조로 복원을 확인했다(`restore: ok (digest 일치)`).

| 검사 | 변이 | rc | 관찰된 실패 |
|---|---|---|---|
| `#1` | 정책 하나를 부록에서 본문으로 올린다 | 1 | `#1 FAIL: lint 가 exit 1` (규칙 `placement` 위반) |
| `#2` | 프론트매터에서 `vendor:codef:no_data` 를 뺀다 | 1 | `#2b FAIL: 인덱스에만 vendor:codef:no_data` |
| `#3` | pending 한 건의 status 를 `data-dependent-unknown` 으로 | 1 | `#3a FAIL: vendor:toss:success 기대 conditional-unknown 실제 data-dependent-unknown` |
| `#4` | non-treat 절 제목을 H3 로 낮춰 두 표를 한 절에 뭉친다 | 1 | `#4a FAIL: '## 응답 의미 대조 — treat 축' 절에 표가 2개 이상이다 (…:249)` |
| `#5` | codef 자료없음의 사각을 `없음` 으로 고쳐 적는다 | 1 | `#5 FAIL: … 사각 '없음' 인데 재계산은 '분류 부재' (basis=code-only no_data_discrimination=unmapped NO_DATA 도달=진단 표면만)` |
| `#6` | 소비 사슬에서 `NO_DATA` 행을 지운다 | 1 | `#6a FAIL: 로케이터에만 NO_DATA` |
| `#6` | `userMessage` 의 site 소비를 0 에서 3 으로 올려 적는다 | 1 | `#6b FAIL: userMessage site 소비 '3' 인데 재계수는 '0'` |
| `#7` | pending 사유에서 게이트 부재 문면을 지운다 | 1 | `#7b FAIL: vendor:aligo:no_data 의 unknown_reason 이 게이트 부재를 담지 않는다` |
| `#7` | pending 사유가 없는 정책 게이트를 주장한다 | 1 | `#7b FAIL: vendor:aligo:failure 는 policy_gates 가 빈 행인데 unknown_reason 이 정책 게이트 'TREAT_POOL' 를 주장한다` |
| `#8` | 앵커 행 번호를 파일 행수보다 크게 적는다 | 1 | `#8 FAIL: … 유도에만 …:3 · 문서에만 …:9999 · 앵커 … 행수 초과` |
| `#9` | 연혁 SHA 한 글자를 바꾼다 | 1 | `#9 FAIL: af16d982 를 commits.server.jsonl 에서 못 찾는다` |
| `#9` | 이 문서와 무관한 커밋을 연혁에 넣는다 | 1 | `#9 FAIL: 4d798f55 날짜 불일치 · 4d798f55 는 이 문서의 앵커 경로를 건드리지 않는다` |
| `#10` | 적용 범위 표에서 `기업회원` 열을 지운다 | 1 | `#10a FAIL: 헤더 누락 기업회원` |
| `#10` | 적용 범위 칸 하나를 비운다 | 1 | `#10b FAIL: 1건 — 빈 칸 — vendor:aligo:failure / 일반회원` |
| `#12` | 격자 한 칸(`vendor:smartro:no_data`)을 표에서 뺀다 | 1 | `#12a FAIL: 유도에만 vendor:smartro:no_data` |
| `#13` | 부록에 허용 목록 밖 코드값을 한 번 쓴다 | 1 | `#13 FAIL: 목록 밖 코드값 1건 — 02-failure-semantics.md:453 CF-00016 (패턴 CF-nnnnn)` |

**`#4` 의 관찰이 계획서 예상 문면과 다르다.** 계획서는 `#4a FAIL: 대조표가 1개다 (기대 2)` 를
예상했는데 실제로는 `표가 2개 이상이다` 가 먼저 떨어졌다. 원인은 변이 방식이다 — 절 제목을
지우지 않고 H3 로 낮췄더니 두 표가 앞 절 범위 안에 함께 들어가 절 안 복수 표 검사가 먼저
잡았다. **두 경로 모두 뭉침을 rc=1 로 잡으며 이 검사가 겨냥한 층위는 동일하다.** 절 제목을
아예 지우면 계획서가 예상한 분기로 떨어진다(`sectionRange` 가 `null` 을 내는 경로).

### (다) `#0` 두 팔 — 회귀와 워킹트리 불변이 다른 사유로 떨어진다

| 변이 | rc | 관찰 |
|---|---|---|
| M1 문서 배치표에서 `schedule:fax-status` 행 1개 삭제 | 1 | `#0 FAIL: M1 하네스 rc=1` (M1 자신은 `all FAIL: 14/15 (실패: check1)` — `id-crossref` 위반) |
| M1 문서에 개행 1개만 추가하고 고치지 않음 | 1 | `#0 FAIL: docs/05-schedules/04-runtime-topology.md 가 워킹트리에서 변했다 — M …` |

두 팔이 **다른 사유로** 떨어진다는 것이 관찰의 요점이다. 계획서가 요구한 대로 회귀 실패와
워킹트리 오염이 같은 실패로 접히지 않는다. 두 경우 모두 `git checkout --` 로 복원했고
`git status --porcelain` 이 0행임을 확인했다.

### (라) `#11` 양성 프로브의 필요성

없는 경로로 `--help` 를 부르면 `node` 가 rc=1 을 낸다:

```
$ node .claude/plans/nosuch-gates.mjs --help   →  rc=1 · Cannot find module
$ node <실 하네스> nosuchcheck                  →  rc=1 · 알 수 없는 서브커맨드: nosuchcheck — 지원: …
```

**두 rc 가 같다.** 그래서 `#11` 은 음성 rc 만 보지 않고 `--help` 성공(rc=0 + 서브커맨드 목록
출력)을 먼저 확인한다. 그 양성 프로브가 없으면 *하네스 부재* 와 *하네스가 unknown 을 올바로
거부* 가 구별되지 않는다.

## 구현 로그

### 계획서와 실측이 갈린 자리 (관측 10 · 한 칸)

계획서 관측 10 은 동결 admin `fb001e1d` 의 `src/**` 에서 `NO_DATA` 가 **0건**이라고 적었다.
구현 창 실측은 **1건**이다:

```
$ git -C ../../insuniverse-admin grep -n -w -F -e NO_DATA fb001e1d… -- src
…/TreatMonitor/TreatMonitorPage.tsx:80:  return "neutral"; // NO_DATA, DUPLICATE 등
```

**판정은 바뀌지 않는다.** 그 한 건은 주석이고 분기가 아니며, 계획서가 이미 계수를 도달의
*상한* 으로 규정하고 게이트 재계수를 오라클로 세워 두었다(`#6b`). 문서는 게이트가 다시 센
1 을 적고 게이트가 그 1 을 승인한다 — 계획서 산문이 아니라 재계수가 정본이라는 계약이 여기서
실제로 작동했다.

드러난 것은 **계수기의 사각 하나**다: 토큰 단어 일치는 코드와 주석을 구별하지 못한다. 그래서
`#6b` 가 그 사각을 매 실행 출력에 찍도록 했고(`admin 의 NO_DATA 1건은 주석행이다`), `도달`
판정은 계수가 아니라 벤더 축 전용 토큰과의 파일 교집합이 정하도록 좁혔다. 이월 원장에도
올렸다(`id=40m3-obs10-admin-nodata-count`). **계획서 본문은 `plan_hash` 앵커라 고치지 않는다.**

### 연혁 행 재선정 (`#9` 가 3행을 반려)

첫 저작에서 연혁 7행 중 3행(`3a80536f` · `0afb594e` · `4d798f55`)이 `#9` 에 걸렸다 —
`… 는 이 문서의 앵커 경로를 건드리지 않는다`. 앞의 둘은 예외 필터 파일을, 셋째는 기준점
커밋이라 무관한 파일을 건드린다. **게이트가 옳다** — 계획서가 연혁 행을 *이 문서의 정책 앵커
경로를 건드린 커밋 집합* 안으로 제한했다.

앵커 경로 9종을 건드린 커밋은 인덱스 기준 65건이고, 그중 응답 의미가 바뀐 시점 9건을 골라
다시 적었다. 분류·재시도성이 응답에 실린 시점(2026-06-08 `0afb594e`)은 **행으로 만들 수 없는
행**이므로 연혁 절 머리 산문에 그 사실과 사유를 적었다 — 계획서 Task 5 가 요구한 처리다.

### 게이트 최종

```
$ node .claude/plans/insuniverse-docs-40-runtime-vendor-legal-m3.gates.mjs all
all ok 14/14 통과
```

## 코드리뷰 라운드 (`/mccp:code-review` Local Review Mode · 2026-08-26)

게이트가 `all ok 14/14` 로 통과한 트리를 대상으로 돌렸다. **7건 전건 흡수**했고 기각 0건이다.
층위는 `CLAUDE.md` §2 체크리스트 번호.

| 라운드 | 지적 | 층위 | 흡수 | 반사실 |
|---|---|---|---|---|
| CR1 | `#6c` admin 축 판별이 주석 한 줄에 통째로 걸려 있다 | 8 | 축 판별·신호 교집합 양쪽을 **코드행 등장만** 보도록 좁히고 `VENDOR_ERROR` 를 축 토큰에 더했다 | CF6'·CF7 |
| CR1 | 그 결과 `NO_DATA` 행의 `도달` 이 오판이었다 | 1 | `진단 표면만` → `미도달`. 관리자 모니터의 색 분기가 그 값을 따로 다루지 않고 기본 낙하로 접는다 | CF4·CF6' |
| CR2 | 소비 사슬 `소비 표면` 열의 수치가 재유도되지 않는다 (`사용자 인증 화면 여섯` — 실측 2) | 2 | 그 열에 수치를 담지 못하게 `#6a` 에 검사를 넣고 세 행의 문면에서 수를 뺐다 | CF1 |
| CR3 | `#8` 앵커 3건의 기대값이 하네스 리터럴이라 저자와 저자를 대조한다 | 7 | 출력을 `인덱스 N건 / 하네스 리터럴 M건` 으로 갈라 찍고 사각 줄을 붙였다 | (출력 대조) |
| CR4 | `#10b` 가 200칸의 비어있지 않음만 보고 값과 유도 규칙을 안 본다 | 2 | `#10c` 신설 — 2어휘 대조 + 문서 산문이 선언한 유도 규칙 재유도. `#6c` 도달에 결박했다 | CF2·CF3 |
| CR5 | 죽은 코드 2건 (`sortJoin` · `semantics_unknown`) | 1 | 제거. `semantics` 키는 주사 층위라 계수만 남겼다 | (`node --check`) |
| CR6 | `die()` 가 먼저 걸려 0 외 값이 인쇄될 수 없는 계수기 5건 | 7 | 출력에서 제거. 검사가 아니라 장식이었다 | (출력 대조) |
| CR7 | `#11` normAnchor 자기검증 4건이 전부 양성 | 8 | 음성 4건 추가 — 잘린 범위 · 다중 범위 · 파일명 하이픈 · 행 없음 | CF5' |

### CR1 이 왜 층위 8 인가

`#6b` 사각 줄이 `admin 의 NO_DATA 1건은 주석행이다` 로 그 히트를 **스스로 오탐이라고 지명**한
뒤, `#6c` 가 같은 히트를 오탐을 거르는 오라클로 썼다. 좁힘이 자기가 이름 붙인 거짓 위에 서
있었다 — 검사가 자기 사각지대를 출력에 적었는데 그 사각이 바로 그 검사의 하중이었다.

실측: 동결 admin `fb001e1d` 의 `src/**` 에서 계획서가 지명한 축 토큰 둘(`NO_DATA` ·
`isRetryableTreatError`)의 **코드행 등장이 0**이다. 축 집합을 세우던 유일한 근거가
`TreatMonitorPage.tsx:80` 의 `return "neutral"; // NO_DATA, DUPLICATE 등` 하나였다.

`VENDOR_ERROR` 는 같은 파일 `catGroup` 의 코드행에서 잡히고 site 축에는 0건이다. CF7 이
그 토큰을 빼면 `category` · `userMessage` 가 거짓 `미도달` 로 떨어짐을 보였다 — 하중이지 장식이
아니다. **계획서 Risks 행이 축 토큰 둘을 지명한 것과 편차가 생기지만 계획서 본문은
`plan_hash` 앵커라 고치지 않고** 이월 원장으로 낸다(`id=40m3-axis-token-widened`).

### 반사실 검증 (수정 전/후로 결과가 뒤집히는가)

| 프로브 | 변이 | 관찰 |
|---|---|---|
| CF1 | `소비 표면` 에 `1곳` 삽입 | `#6a FAIL: PROVIDER_FAULT_CODES 소비 표면에 수치가 있다` rc=1 |
| CF2 | `vendor:codef:failure` 의 `site` 칸을 `적용` → `—` | `#10c FAIL: … site 이 '—' 인데 유도는 '적용' (treat=true 도달=true)` rc=1 |
| CF3 | `vendor:toss:success` 의 `server` 칸을 `적용됨` | `#10c FAIL: … 값 '적용됨' 는 어휘 밖이다` rc=1 |
| CF4 | `NO_DATA` 행 `도달` 을 `진단 표면만` 으로 되돌림 | `#6c FAIL: … 재계산은 '미도달' (축 교집합 site 0 · admin 0)` rc=1 |
| CF5' | `normAnchor` 를 `:(\d+)-.*$` 로 탐욕 파손 | `#11 FAIL: normAnchor('…:9-') 가 '…:9' 다` rc=1 — 음성 케이스가 잡았다 |
| CF6' | 신호 쪽 교집합을 `codeGrepFiles` → `gitGrepFiles` | `#6c FAIL: NO_DATA 도달 '미도달' 인데 재계산은 '진단 표면만' (축 교집합 admin 1)` rc=1 |
| CF7 | 축 토큰에서 `VENDOR_ERROR` 제거 | `#6c FAIL: category · userMessage 도달 '진단 표면만' 인데 재계산은 '미도달'` rc=1 |

`CF5` · `CF6` 의 첫 시도는 레버를 잘못 짚었다 — `sed` 의 정규식 이스케이프가 먹지 않아 파일이
안 바뀌었고(그런데 `#11` 은 `ok` 를 찍었다), `CF6` 은 축 쪽만 되돌려 신호 쪽 좁힘이 그대로
남았다. **둘 다 "프로브가 통과했다" 가 아니라 "프로브가 대상을 안 건드렸다" 였다** — 변이
스크립트가 대상 문자열 부재를 `PROBE-SETUP-FAIL` 로 먼저 신고하도록 바꾼 뒤 다시 걸었다.

### 남은 사각 (게이트가 잡지 못한다)

- 코드/주석 판별은 행 안 마커 위치로만 갈린다. 문자열 리터럴 안의 `//` 오인은 도달을 **과소**평가하고(fail-safe), 접두 마커 없는 블록 주석 속행은 코드로 세어 **과대**평가한다(fail-open). 뒤쪽이 잔여 위험이며 `#6b` 출력이 방향까지 적는다
- `#6a` 의 수치 금지는 아라비아 숫자만 본다 — 한글 수사는 못 본다. 이번 지적의 원인이 정확히 그 형태(`여섯`)였다
- `#8` 의 리터럴 앵커 3건은 좌표 **선택**이 검사되지 않는다. 해석 가능성만 검사된다

### 게이트 최종 (코드리뷰 흡수 후)

```
$ node .claude/plans/insuniverse-docs-40-runtime-vendor-legal-m3.gates.mjs all
all ok 14/14 통과
#6c ok 도달 재계산 7건 일치 (사용자 경로 1 · 진단 표면만 2 · 미도달 4)
#10c ok 적용 범위 200칸 값 재유도 일치 (적용 55 · — 145) · site 도달 true · admin 도달 true
#8 ok 앵커 29건 해석 · 행 내용 대조 29건 · 기대 집합 출처 인덱스 26건 / 하네스 리터럴 3건
```

## main 병합 관측 (2026-08-26 · `41a0d6e`)

`origin/main` 이 `df8b403` → `dfee66f` 로 41커밋 전진해 병합했다(rebase 아님 — receipt 3종이
`head_sha` 결박이다). 들여온 형제 창 산출은 `20-foundation-access` M2 · `30-contracts-limits` M1 ·
`50-domain` M2·M3 · `60-history-deprecated` M2 다.

**충돌 1건 · `.claude/plans/codex-findings-backlog.md`.** 양쪽이 같은 표 끝에 행을 덧붙였다 —
이쪽은 40-m3 지적 11행, `origin/main` 쪽은 형제 창 지적 36행. 어느 쪽도 상대 행을 고치지
않으므로 **양측 전건을 보존**했다. 계수 대조로 소실 0 을 확인한다.

| 축 | 값 |
|---|---|
| 병합 전 이쪽 (`21213a6`) | 표 행 31 (그중 40-m3 11행) |
| 병합 전 `origin/main` (`dfee66f`) | 표 행 56 |
| 병합 후 | 표 행 67 = 56 + 11 · 소실 0 |
| 머리행 `\| Date \| Severity \| Source plan \| Finding \|` | 255행에 유지 |

배치는 `origin/main` 블록을 앞, 이쪽 11행을 뒤로 뒀다. main 이 이미 가진 순서를 그대로 두고
이쪽 델타만 꼬리에 붙이는 형태라 다음 병합에서 같은 자리만 다시 충돌한다.

**병합 후 게이트 실측 — 재지정 없이 전건 통과.**

| 축 | 결과 |
|---|---|
| `m3.gates.mjs all` | `all ok 14/14 통과` · rc 0 |
| 그중 `#0` 회귀 | M1 `all 15/15` · M2 `all 13/13` · `05-schedules` 4문서 워킹트리 변경 0 |
| `#1` doc-kit lint `--strict-refs` | 5개 파일 · 위반 0 · rc 0 |
| `lint-plan.mjs <m3 계획서>` | rc 0 |

이 하네스가 병합에 흔들리지 않은 이유는 검사 기준선이 **리비전 고정이 아니기** 때문이다 —
`#0`~`#13` 은 전부 워킹트리의 문서·인덱스·동결 서브모듈 트리를 서로 대조하며, `origin/main..HEAD`
변경 범위를 분모로 쓰는 검사가 없다. 형제 창 파일이 병합으로 들어와도 어느 검사의 분모도
움직이지 않는다. (backlog `기준선 리터럴은 병합에서 깨진다` 행이 관측한 형태의 취약점이 이
하네스에는 없다.)

**ship receipt 는 아직 발행 전이다.** 병합을 PR 발행보다 **먼저** 둔 것은 backlog `60m2` 행이
관측한 post-PR stale-head(재앵커 불가)를 애초에 만들지 않기 위해서다.