라인 레이어 판별 규칙, solo 토글, 폴더 일괄 로드

[yesonsys03-web]

이름이 line이라고 다 라인 레이어는 아니었다.

프리셋 규칙이 contains "line"이라, 작업자가 화면에서 직접 세 종류의 오탐을 발견했다.
lines 그룹이 이름으로 걸리면서 안의 fill·GRAIN_OVERLAY·h까지 전부 끌고 왔고,
line col·Line Colour는 라인이 아니라 색을 지정하는 레이어였으며,
Layer 866 (LINEAR DODGE)는 "LINEAR"의 앞 네 글자가 부분 문자열로 걸린 것이었다.

규칙은 추측이 아니라 실제 납품 파일에서 나왔다

HH0306의 PSD 25개를 열어 현재 규칙에 걸리는 leaf 740장을 전부 덤프하고, 후보 규칙을 그 740장에
대고 쟀다. 이름만으로 판단이 안 서는 레이어는 렌더해서 봤다 — LINE WIN은 창문 위에 흰 빛을 얹는
overlay 패스(순백색 단색 6,629픽셀)였지 라인 아트가 아니었다.

규칙	잡아내는 것
① 토큰 매칭	LINEAR DODGE, Linear Light — "line"을 부분 문자열이 아니라 낱말로 본다
② 그룹 규칙	걸린 그룹 안에 진짜 라인이 있으면 그것만. lines 그룹의 12장이 여기서 빠진다
③ 제외 토큰	line col, LINE_COL — 프리셋에서 어휘를 편집할 수 있다
④ blend ≠ normal	LINE WIN 같은 합성 패스

\blines?\b 같은 단순 정규식을 쓰지 않은 이유가 있다. 정규식 \b는 _에서 끊기지 않아
Wall_Line·Ring_Line·CurtainsLine 같은 진짜 라인 43장이 같이 날아간다.

실파일 25개 기준 740장 → 587장. scripts/audit-line-matching.py로 언제든 다시 잴 수 있고,
엔진의 match_preset을 그대로 부르므로 숫자가 앱 동작과 갈라지지 않는다.

이름으로 못 가르는 것은 solo로 본다

BG/FLOOR/line은 알파가 bbox를 100% 덮는 보라색 채움이다. 어떤 이름 규칙도 이걸 가려낼 수 없고,
결국 눈으로 봐야 한다. 그런데 한 장만 보려면 나머지를 전부 꺼야 했다.

툰붐 하모니의 solo를 그대로 따랐다 — 하나라도 solo면 그것만 보이고, 여러 장을 동시에 걸 수 있고,
풀면 원래 화면이 그대로 돌아온다. 체크박스와 눈을 둘 다 무시하는 것이 요점이다. 아직 결정하지 않은
레이어를 보려는 기능이기 때문이다. 미리보기 전용이라 내보내기에는 영향이 없다.

픽셀 신호로 자동 판별하는 것도 재봤지만 쓸 수 없었다. 커버리지는 흐린 그라디언트를 놓치고,
침식은 굵은 라인을 오탐한다. 애매한 것은 사람이 0.5초 만에 보는 편이 낫다.

함께 담긴 것

폴더를 통째로 열어 첫 클릭 전에 준비해두는 대량 로드 작업 2커밋이 이 브랜치 밑에 깔려 있어 같이
올라간다. 규칙으로 뺀 레이어가 그 로드 큐의 오류 카드를 덮지 않도록 필터를 거부 목록에서 허용
목록으로 바꾼 것이 두 작업이 만나는 지점이다.

---

리뷰에서 나온 것

리뷰와 실사용 검증을 한 바퀴 돌면서 9커밋이 더 붙었다. 대부분은 일괄 로드가 드러낸 문제다 —
파일 하나를 열어 보던 때는 드러나지 않던 것들이, 25개를 한꺼번에 열고 오가기 시작하자 나왔다.

세션 경합 — 로그로 원인을 확정했다

unknown or evicted session이 프리셋 자동 적용과 자동 병합에서 간헐적으로 났다. 두 번 추측해서
두 번 빗나갔고(둘 다 부분적으로는 맞았다), 세 번째에 엔진에 임시 로그를 심어 순서를 그대로 찍었다.
결정적인 한 줄:

evict sid=94 (Hallway006)  keep=96  pinned=Hallway006

고정해둔 파일이 자기 자신의 복제본에게 밀려났다. store.open()이 같은 파일이 이미 열려 있어도
매번 새 세션을 만들고 있었다. 상한이 2칸이라 그 복제본이 원본을 밀어내고, pin은 경로의 가장 최근
세션 하나만 지키므로 고정도 소용이 없었다. 축출 복구 재시도가 둘 이상 겹치면 서로를 걷어차다
넷 다 소진하고 실패했다 — 사용자가 본 "10초 멎었다가 에러"가 이것이다. 700MB짜리가 메모리에 두 벌
올라가 있던 것은 덤이다.

open()이 경로 + mtime이 같으면 기존 세션을 재사용한다. mtime을 함께 보므로 아티스트가
포토샵에서 저장했다면 여전히 새로 읽는다.

같은 뿌리에서 두 가지가 더 나왔다:

• 로드 중에는 pin을 풀었다. 그때는 pin이 지키는 것이 없는데(캔버스는 paused, 썸네일·준비 큐는
  loading에 막힘) 두 칸 중 한 칸을 묶어 큐의 여유를 0으로 만들고 있었다.
• 자동 병합은 세션을 아예 안 쓴다. 이름만 보고 묶는 순수 계산인데 RPC 껍데기가 s["tree"]를
  꺼내려고 살아 있는 세션을 요구했다. 화면이 이미 들고 있는 트리를 보낸다 — 규칙은 그대로 엔진에
  있으므로 배치 실행과 갈라지지 않는다. 옮긴 것은 입력이지 규칙이 아니다.

성능 — 썸네일이 엔진 시간의 66%였다

자동 병합이 "어떤 파일은 즉시, 어떤 파일은 몇 초"로 갈렸다. 계산 자체는 중앙값 0.01초였다.
기다린 것은 앞에 쌓인 썸네일이었다 — 엔진은 stdin 큐를 순서대로 처리한다.

RPC	횟수	중앙값	엔진 점유
render_thumbnails	303	0.49초	1038초 (66%)
render_preview	100	0.41초	177초
auto_merge_preview	27	0.01초	7.8초

파일을 열면 pixel leaf 전부(실파일 500장, 청크 31번)의 48px 썸네일을 만들고 있었다. 화면에
보이는 건 30행 남짓인데.

IntersectionObserver로 보이는 행만 만든다. 지나간 행은 큐에서 빠진다 — 한 번 보인 것을 계속
쌓으면 한 번 빠르게 훑는 것만으로 예전과 같아진다.

청크도 8 → 2로 줄였다. 48px 한 장에도 레이어의 원본 해상도 RGBA를 통째로 디코드하기 때문에 장당
비용이 파일 크기를 따라간다 — 1.4GB 파일은 8장 묶음 하나가 19초였고, 그동안 누른 것이 전부 그
뒤에서 기다렸다. 총량은 그대로지만 한 번에 잡는 시간이 1/4이 된다.

미리보기 캐시 예산은 48MB → 256MB. 25개를 오가면 예산을 넘겨 오래된 파일이 버려지고, 그 파일을
다시 누르면 합성을 처음부터 했다. 가장 무거운 파일이 41초짜리라 몇 MB 아끼자고 치를 값이 아니다.

그 밖에 리뷰가 잡은 것

matchedIds가 앱 전역에 하나였다. opsByPath는 파일별인데 이것만 전역이라, 로드 큐가 배경에서
파일마다 프리셋을 붙이고 나면 마지막으로 처리된 파일의 id가 남았다. 레이어 id는 세션 안에서만
유일하므로 그 숫자들이 화면이 보고 있는 파일의 엉뚱한 레이어를 가리켰다 — "라인만"에 mask·fill·
grain multiply가 섞여 나왔다. 파일별로 나눴고, 그 덕에 파일을 옮겨도 각자의 결과가 보인다(전역 칸
하나로는 애초에 표현할 수 없던 동작이다).

"중지"가 중지로 남지 않았다. 취소 표시를 ref에 뒀는데 큐 효과가 재진입할 때마다 지웠고, 재진입은
state.files가 바뀌면 일어난다. 중지 직후 파일을 하나 클릭하는 것만으로 로드가 통째로 다시 시작됐다.
상태로 올리고, 재개 버튼을 중지가 있던 자리에 뒀다. ref만으로는 되돌릴 방법이 없었다 — 이미 있는
폴더를 다시 추가하면 addFiles가 같은 state를 그대로 돌려주기 때문이다.

미리보기가 1:1로 떴다. 엔진이 1500px로 렌더하는데 max-width: none이라 열자마자 화면 밖으로
넘쳤다. 뷰어에 맞춰 들어오게 하고, 배율이 정해질 때까지 그림을 감춰 1:1 프레임이 아예 안 그려지게
했다. 사람이 휠을 한 번이라도 돌리면 그 배율을 지킨다.

그릴 것이 없는 solo 버튼이 눌리기만 했다. 그룹·병합 행의 solo는 pixel leaf로 좁히는데, 좁힌
결과가 비어도 버튼은 살아 있어 눌러도 아무 일이 없고 켜지지도 않았다.

미리보기 캔버스가 렌더 중에 "안 바쁨"을 알렸다. 정리 함수는 대기 중인 타이머만 끊으므로 렌더가
겹칠 수 있고, 먼저 끝난 쪽이 신호를 내리면 준비 큐가 비켜서기를 멈춘다.

검증

• 엔진 uv run pytest → 154 통과
• 프론트엔드 npm test → 290 통과, tsc --noEmit 클린, npm run build 성공
• Rust cargo test → 14 통과
• 실파일 25개 감사 → 587장 포함 / groupHasOwnLine 55 · excludedToken 18 · notLineWord 5 ·
  blendMode 5 · noPixels 4 (판별 규칙은 리뷰 라운드에서 바뀌지 않았다)
• 일괄 로드를 실파일 25개로 반복 실행해 오류 카드 0장을 확인했다. 수정 전 같은 조건에서
  프리셋 자동 적용 실패 3건이 났다.
• solo·재개·뷰어 맞춤·자동 병합은 작업자가 실제 파일을 열고 눌러 확인했다 — 이 저장소에는 컴포넌트
  테스트가 없어 자동으로 메울 수 없는 부분이다.

리듀서와 순수 함수 쪽은 테스트로 잠갔다. matchedIdsByPath는 "배경 파일의 프리셋 결과가 활성
파일을 덮지 않는다"를 포함해 3개, 세션 재사용은 실제 실패 로그를 그대로 옮긴 것을 포함해 4개,
썸네일 큐는 6개. 앞의 둘은 수정을 되돌리면 정확히 그 테스트만 깨지는 것까지 확인했다.

알려진 한계

• 무거운 파일의 첫 합성은 줄일 수 없다. 가장 큰 파일이 41초다. 준비 큐가 미리 만들어두는 것이
  유일한 답이고, 아직 준비되기 전에 누르면 기다려야 한다. 무거운 파일을 먼저 준비하도록 순서를
  바꾸는 것이 다음 후보다.
• 썸네일은 구조적으로 비싸다. psd_tools가 축소 디코드를 지원하지 않아 48px 한 장에도 원본
  해상도를 읽는다. 정말 문제가 되면 큰 파일에서 썸네일을 끄는 선택지가 현실적이다.
• 준비 큐와 썸네일은 여전히 겹칠 수 있다. 그 구간은 pin도 걸려 있어 2칸을 셋이 나눠 쓴다.
  지금은 오류로 이어지지 않지만, "미리보기를 미리 만들지 못한 파일" 카드가 다시 나온다면 여기다.
• 제외 토큰과 blend 규칙은 leaf에만 적용된다. 이름에 제외 토큰이 붙은 그룹은 여전히 자식을
  일괄 포함시킬 수 있다. 실파일 25개로 재봤을 때 해당 사례가 0건이라 두었다(line으로 걸리는 그룹
  21개 중 제외 토큰을 단 것이 없었고, 21개 전부 blend가 그룹 기본값인 pass_through였다).

설계와 구현 계획은 docs/superpowers/에 있다.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Ltm3qkFkyb9oANqu3A2HRc