fix: 대형 파일 자동 접힘을 파일 길이가 아니라 변경량으로 판정한다

[say8425]

뷰어가 첫 등장한 대형 파일을 접어서 마운트하는데(main.ts의 isLargeFile), 그 판정에 넘기던 changedLines가 변경량이 아니라 파일 전량이었다. 정책은 "changes가 너무 길면 접는다"인데 실제로는 "파일이 길면 접는다"로 동작했다.

근본 원인

const changedLines = fileDiff.additionLines.length + fileDiff.deletionLines.length;

FileDiffMetadata의 additionLines/deletionLines는 이름과 달리 string[]이고, 뷰어처럼 파일 전량으로 diff를 만들면(isPartial === false — parseDiffFromFile이 항상 그렇다) 각각 새 파일과 옛 파일의 전체 내용이다. packages/diffs/src/types.ts:235-256이 그렇게 문서화한다.

즉 실효 판정식이 파일 길이 × 2 > 1500, 사실상 파일 길이 750줄 초과였다.

실측(headerlab 워킹트리) — 1,166줄 CLAUDE.md의 +28/−2 = 30줄 변경이 2,306으로 읽혔다. 같은 트리에서 이렇게 잘못 접힌 파일이 5개였다:

파일	실제 변경	옛 로직이 읽은 값	접힘
CLAUDE.md	30	2,306	✗ → ✓
tests/e2e/header-modification.spec.ts	388	4,114	✗ → ✓
tests/unit/ScopeRail.test.tsx	158	2,342	✗ → ✓
components/ScopeRail.tsx	164	2,188	✗ → ✓
tests/unit/App.test.tsx	117	2,675	✗ → ✓

수정

실제 +/- 줄 수는 Hunk 쪽 동명 number 필드에만 있다. 파일 헤더의 -M +N 배지도 정확히 그걸 세므로(createFileHeaderElement), 이제 화면 배지와 접힘 판정이 같은 값을 본다.

• browser/largeFile.ts — countChangedLines(hunks) 추가
• browser/main.ts — 호출부 교체

임계값 1500과 lockfile 이름 규칙은 그대로다.

Screenshots

Before — CLAUDE.md(-2 +28)가 접혀 있다. 158줄만 바뀐 tests/unit/ScopeRail.test.tsx(-103 +55)도 함께 접혔다.

After — 같은 파일이 펼쳐진 채 뜬다.

회귀망

이 종류의 버그는 유닛이 원리적으로 못 잡는다. isLargeFile 자체는 옳았고 호출부가 틀린 값을 넘겼을 뿐이라, 그 함수의 기존 테스트 5개가 전부 통과한 채로 버그가 살아 있었다. 같은 이유로 main.ts는 커버리지 게이트 밖이고 배선은 e2e가 맡는다.

large-file-collapse.e2e.ts가 세 방향을 한 파일에서 지킨다:

#	시나리오	기대
①	2,000줄 파일에 3줄 변경	안 접힘
②	800줄 전량 재작성 (1,600줄 변경)	접힘
③	1,000줄 lockfile (변경량 196줄 — 임계값 아래)	이름 규칙으로만 접힘

셋 다 뮤테이션으로 판별력을 확인했다: 원래 로직으로 되돌리면 ①이, countChangedLines를 0으로 퇴화시키면 ②만, LOCKFILE_NAMES를 비우면 ③만 죽는다.

②③은 처음에 기존 스펙(retokenize-cache.e2e.ts, lockfile-freeze.e2e.ts)이 지킨다고 적었다가 거짓임을 확인하고 직접 채웠다. 두 스펙 어디에도 접힘 상태를 단언하는 코드가 없다 — 전자는 헤더를 click해 펼친 뒤 하이라이트를 기다리고, 후자는 hasHeader만 보는데 헤더는 접혔든 펼쳐졌든 있다. 자동 접힘이 사라지면 그 click이 반대로 파일을 접어 뒤따르는 단언이 깨지는 부수효과로만 빨간불이 된다. 게다가 그 lockfile 픽스처는 20줄마다 2줄을 바꿔 8k에서 1,596줄, 30k에서 5,996줄을 변경하므로(실측) 크기 규칙만으로 이미 접힌다 — LOCKFILE_NAMES를 통째로 비워도 초록이라 이름 규칙의 회귀망이 아니었다.

CLAUDE.md에도 이 함정(FileDiffMetadata.additionLines가 이름과 다르다)과 위 회귀망 사실관계를 기록했다.

Test plan

• bun test — 621 pass / 0 fail (countChangedLines 테스트 4종 추가)
• bun run test:e2e — 78 pass / 0 fail
• bun run test:coverage — 100% 유지 (largeFile.ts 포함)
• bun run typecheck
• bun run lint / bun run format:check — 새 경고 없음
• 뮤테이션 검증 3종 (위 표)
• 실제 앱 수동 검증 — 스크린샷은 dist/cli.js를 실제로 빌드해 headerlab을 서빙한 화면이며, before는 base 커밋을 빌드해 찍었다

참고: e2e 첫 전체 실행에서 retokenize-cache·worker-highlight 2건이 실패했는데, 실패 지점이 #status의 "Loading…" 타임아웃(서버 응답 계층)이라 접힘 판정과 무관한 기존 Bun $ never-settle flake였다. 부하 없이 재실행해 그린을 확인했다.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ArwfmcvGjKnRWMiEFBfJzF