- Shift+휠을 가로 스크롤로(파일 비교 · 메모). 파일 비교는 가로 휠(틸트)과 같은
길로 보내 마우스가 놓인 칸이 움직이고 나머지가 따라온다. 휠 아래 = 오른쪽.
- Ctrl+↓ / Ctrl+↑ 를 다음 · 이전 차이의 대체 키로. 칸과 상태 줄 사이에 캐럿 행의
BASE(변경 전) · LOCAL(변경 후)을 위아래로 보이는 칸 - 칸과 같은 CodeTextBlock
(문법 색 · 바뀐 글자 칠하기 · 줄 색), 긴 줄은 접는다. HomeViewModel.CaretLine.
- 폴더 비교에서 연 문서 탭을 닫으면(Ctrl+W) 폴더 비교 탭으로 간다.
RequestPlainCompare(fromFolder:) 로 표시를 보내 DocTab.FromFolder 에 붙이고,
◀ 이전 파일 · 다음 파일 ▶ 로 짝을 바꿔도 이어 받는다. 다른 길로 연 탭은 그대로.
- 어두운 테마에서 폴더 비교 목록만 흰 바탕 · 검은 글자였다 - 플랫폼 테마가
TreeView 는 칠하지 않는다. 바탕 · 글자색(항목 포함)을 테마에서 받는다.
색 구분의 0 항목 흐리기 0.35 -> 0.55(어두운 바탕에서 묻혔다).
시험: 빌드 경고 0 · 오류 0. 화면 g27-five(새, 어두운 테마) - Shift+휠 편집기 가로
0 -> 20% · 세로 그대로 · BASE 칸 위에서도 · 메모, Ctrl+↓ 로 차이 이동 · 아래 칸
표시, 폴더 비교에서 연 탭만 Ctrl+W 뒤 폴더 비교로, 사진으로 폴더 목록 · 아래 칸
확인. 실패 0. 기존 회귀는 돌리지 않았다.
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
[전체 반영] 은 줄마다 Apply 를 따로 불러 바뀐 줄마다 머지 주석이 붙고 Undo 도
줄마다 한 걸음이었다. [구간 반영] 처럼 구간마다 주석 한 줄로 바꾼다.
- 두 파일 비교 [전체 반영]: 반영할 수 있는 줄이 이어진 구간(BlockAround 와 같은
기준)을 먼저 나눠 구간마다 ApplyGroup. 지우는 반영은 "삭제 N줄". 모든 구간을 한
묶음 번호로 넘겨 Undo 한 번에 전체가 돌아간다. ApplyGroup 에 group · finish 를 더함.
- 3-Way [전체 반영] 은 끈다(사용자 결정) - 차이 나는 모든 줄을 공통 조상(BASE)으로
바꾸던 동작이라 병합에서 쓸 데가 없고 양쪽 작업을 지운다. 꺼져도 툴팁으로 까닭.
- 3-Way [자동 병합] 도 저쪽만 고친 줄 구간마다 주석 한 줄 · Undo 한 번. 사이에 낀
충돌 · 내가 고친 줄은 구간을 끊고 그대로 둔다.
시험: 빌드 경고 0 · 오류 0. 화면 g22-accept-all(새) 주석 7 -> 3 · 삭제 2줄 ·
BASE 와 같음 · Undo 한 번, g23-three-way(새, --merge) 전체 반영 꺼짐 · 주석 5 -> 2 ·
내 줄 · 충돌 줄 그대로 · Undo 한 번. 실패 0. 기존 회귀는 사용자 지시로 돌리지 않았다.
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
f105bab(칸 어긋남 고침) 뒤부터 스크롤을 내리면 응답 없음(AppHang)으로 닫혔다.
같은 재료로 BASE 칸을 휠로 끝까지 내려 재현했고, 임시 기록으로 원인 넷을 찾았다
(기록 코드는 뺐다).
1. 사람이 BASE 를 굴려도 BASE 맞추기가 LOCAL 기준으로 되돌렸다 - 굴린 만큼(48px)을
끌어당기고 보정값이 오르내려 초당 32번 밀고 당겼다. 손이 닿은 칸(휠 · 누름 · 키)을
기준(_scrollDriver)으로 삼고 LOCAL 쪽일 때만 BASE 를 맞춘다. 스크롤 이벤트로 정하면
글자 크기를 바꿀 때 목록이 저절로 내는 스크롤까지 BASE 로 읽었다. 확대 · 다음 차이 ·
줄 이동은 LOCAL 기준.
2. 따라 굴러가는 도중에 재서 휠 한 칸(48px)씩 보정값이 6,619px 까지 쌓였다. 메아리
막기 중이면 큰 맞추기는 앱이 한가할 때(ApplicationIdle) 한 번 하고, 못 굴리는
끝에서는 실제로 움직인 만큼만 보정한다.
3. 칸 목록(그 칸에 있는 줄만 거른 PaneView)의 항목 번호를 정렬 행 번호로 써서
한쪽에만 있는 줄만큼 엉뚱한 줄끼리 견줬다(10줄 -> 157px, 마지막 차이에서 칸이
228px 밀림). 줄 객체로 오간다(RowOf · ContainerOfRow).
4. 빠르게 굴리면 사람의 스크롤까지 메아리로 버려져 따라가는 칸이 멈췄다(BASE 784 ·
LOCAL 555). 버려지면 표시만 남기고 멈춘 뒤 한 번 따라잡는다. BASE 를 굴릴 때는
보정값을 보이는 줄에서 다시 잰다(MeasureBias).
시험: 빌드 경고 0 · 오류 0. 화면 g20-scroll-end(새, 보통 · 빠르게) 모든 단계 응답 ·
BASE · LOCAL 가운데 줄 한 줄 안, g21-blocks-fast(새, 한쪽에만 있는 묶음이 많은 재료)
응답 · 따라옴(가운데가 묶음에 걸리면 10줄 남짓 벗어날 때 있음), g7-verify(Alt+↓)
실패 0, g17(엔터 · 확대 · 내리기) 통과. 사용자 파일로는 확인하지 않았다. 기존 회귀는
사용자 지시로 돌리지 않았다.
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
편집이 있어도 하단 [종료] 를 누르면 묻지 않고 꺼졌다(편집은 보관본이 다음에
되살렸다). 사용자 판단 "잘못 고치고 있었으면 버릴 수 있어야 한다" 에 따라
끌 때 [저장하고 종료] · [저장하지 않고 종료] · [취소] 를 묻는다.
범위(사용자 결정): 파일 비교의 모든 탭 - 지금 화면(두 파일 · Git 모드 · 네 칸),
뒤에 맡겨 둔 탭, 닫았지만 편집이 남은 짝. 메모는 제외. 창에 파일 이름을 댄다.
저장은 기존 길(SaveWorkingCopy · WritePlainFile)로, 하나라도 못 쓰면 끄지
않는다. 버리면 걸려 있던 보관 쓰기를 기다린 뒤 보관본을 비워 다음에 되살아
나지 않게 한다.
플랫폼의 ICloseGuard 를 HomeViewModel 이 구현(플랫폼 수정 없음). 처음엔 곧바로
답해 셸의 Close() 가 Closing 안에서 불려 창이 안 꺼졌다(로그: 창을 닫는 중에는
Close 를 호출할 수 없습니다) - await Task.Yield() 로 비켜선 뒤 묻는다.
시험: 빌드 경고 0 · 오류 0. 화면 g19-exit-confirm 다섯 경우 실패 0 - 고친 것
없으면 묻지 않음, [취소] 면 그대로, [저장하지 않고 종료] 면 파일 그대로 · 보관본
빔 · 다시 켜도 안 살아남, 고친 직후 [저장하고 종료] 면 파일에 씀, 뒤 탭에만 편집이
있어도 묻고 그 파일만 씀. Git 모드는 화면 시험 안 함. 기존 회귀는 사용자
지시로 돌리지 않았다.
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
엔터를 꾹 누르면 캐럿 줄과 LOCAL 칸 줄이 벌어졌다 - 캐럿은 글에서 센 줄
자리로 두고, 메아리 막기 중에도 LOCAL 칸은 편집기 스크롤을 따라가게 했다.
Ctrl+휠로 키우면 칸 위가 비고, 내리면 BASE 가 다른 줄을 봤다. 칸 목록은
가상화라 안 그린 줄 높이를 어림으로 세어(1,806줄 847행: 편집기 28,896 ·
목록 27,940) 같은 픽셀이 다른 줄을 가리키는데, 이 차이를 네 칸 공통
이동값으로 메우다 467px 까지 커졌다. 두 줄 넘게 어긋나면 LOCAL 목록을
실제로 굴리고 차이를 칸별 보정(_paneBias)으로 기억한다. BASE · REMOTE 는
LOCAL 가운데 줄과 같은 줄끼리 맞춘다(AlignOtherPanesByRow) - 한쪽에만 있는
줄 묶음 안은 맞추지 않는다(짝을 억지로 불러 초당 600번 되풀이하며 타이핑을
밀어내던 것을 기록으로 잡았다).
맞추기 기준은 편집기에 보이는 첫 줄. 편집기에 묻는 값 둘이 틀려
(GetFirstVisibleLineIndex 886 -> 1033, 글자 크기 바꾼 뒤
GetRectFromCharacterIndex 가 몇 초씩 옛 배치로 1,892px 틀림) 줄 바꿈이
꺼져 있으면 고정 줄 높이로 계산한다. UIA 로 읽은 실제 첫 줄과 대조했다.
시험: 빌드 경고 0 · 오류 0. 화면 g17-hold-enter - 엔터 40번 뒤 LOCAL 칸
번호 = 편집기 줄(936) · 같은 높이, 확대 뒤 · 30칸 내린 뒤 LOCAL = BASE,
칸 위 비지 않음. 꾹 누름 흉내에서 40번 중 30~34번만 들어가는 것은 고치기
전 커밋도 같고 따로 누르면 40번 다 들어간다(Windows 가 반복 키를 합침).
기존 회귀는 사용자 지시(방금 요청한 것만)로 돌리지 않았다.
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Accept 뒤 Alt+Down 을 두 번 눌러야 다음 차이로 가던 것 - 반영하며 캐럿 위에
주석 줄이 끼면 글자 수로 지킨 캐럿 자리가 그 주석 줄이 됐다. 주석을 끼우거나
빼기 직전 캐럿 행을 기억했다가, 글을 갈아 끼운 뒤 그 행의 편집기 줄에 캐럿을
둔다. 임시 기록으로 확인한 것: 글을 막 갈아 끼운 TextBox 의 줄 정보는 아직
옛 글 기준이다 - 줄 시작 자리는 새 글에서 직접 센다.
줄을 지우는 반영(BASE 에 없는 줄)에도 주석을 남긴다. 한 줄이면 "삭제",
구간 · 메서드로 여러 줄이면 한 번만 "삭제 N줄"(사용자 선택). 왼쪽으로 반영 ·
3-Way 저쪽 반영에도 같은 규칙.
색 구분 "줄 안에서 바뀐 부분" 에 줄 수를 붙였다(이 칸만 없었다).
타이핑: 1,806줄에서 재 보니 엔터마다 도는 재정렬 0.4초의 대부분이 목록에
1,800줄을 한 줄씩 넣으며 알림이 1,800번 가는 것이었다(파일 비교 자체 0.012초).
MergeLineCollection 으로 한 번에 넣고(ReplaceAll), 재정렬에서는 번호 말고 모든
값이 같은 줄은 기존 객체를 두고 번호만 고쳐 가운데만 빼고 넣는다(Patch,
MergeLine.SameStateExceptNumbers). 엔터 한 번 약 0.55초 -> 약 0.05초.
화면 요소 재활용(Recycling)은 효과가 없어 넣지 않았다.
탭이 20개를 넘어 오래 안 본 탭이 조용히 닫히면 알림을 띄운다.
시험: 빌드 경고 0 · 오류 0. 하네스 NoteTest 106 · PatchTest(새) 16.
화면 g12-note(주석 · 캐럿 · 되돌리기) · g14-inline · g15-typing-tabs(새 줄
제자리 · 번호 896 -> 897 -> 898, 21번째 탭에서 알림 · 20개 유지) 통과.
기존 회귀는 사용자 지시("방금 요청한 것만")로 돌리지 않았다.
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Git 탭에 폴더나 파일을 끌어다 놓으면 그 저장소를 연다. [폴더...] 와 같은 규칙을
PathUtil.RepositoryFolderFor 한 곳에 두었다 - 파일이면 그 폴더, 저장소 안이면
최상위, 저장소가 아니면 그 폴더 그대로(열기가 "저장소가 아니다" 를 알린다).
탭 전체에서 PreviewDrop 으로 받는다. 경로 칸 · 커밋 메시지 칸이 TextBox 라
파일 놓기를 먼저 먹고 버리는 문제를 폴더 비교(7차 E-2)에서 겪었다.
PathTest 6건을 먼저 넣어 실패 확인 -> 68건 통과. 흉내 낸 OLE 끌기는 이미 되는
폴더 비교 칸에도 들어가지 않아 도구 한계로 보고, 사용자가 직접 끌어다 놓아
확인했다(로그에 저장소 열기 두 번, 그 사이 단추 누름 없음).
파일 비교 편집 칸은 바탕이 없어 페이지 바탕(밝음 #F2F2F3 · 어두움 #23262B)이
비쳐 회색이었다. PaneBackgroundConverter 가 물려받은 글자색 밝기로 테마를 가려
밝음 #FAFAFA · 어두움 #252830 을 준다 - 후보를 실제 코드 색으로 그려 보여 주고
사용자가 골랐다. g11-pane 두 테마에서 빈 자리 화소로 확인.
하단 탭이 따라가지 않던 문제(폴더 비교 -> 두 번 눌러 파일 비교)는 공용 플랫폼
셸에서 고쳤다(MergeHub 코드 변경 없음, 기록만).
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
G-3 "덩어리" 를 "구간" 으로 - 단추 [구간 반영] · [구간 왼쪽으로], 단축키 설명, 로그.
G-4 저장 형식 콤보 둘을 구별 - 원본 인코딩 유지 · 원본 줄바꿈 유지. 저장값은
"원본 유지" 그대로(세션 보관본 7·8칸) - SaveChoice(Value, Label) 로 보이는 글만 가른다.
G-5 사내 문의처 받침값 - csproj <SupportContact> 를 실행 파일에 박는다(문구는 아직 비움).
G-6 설정 > 개발자 정보. 담당 카드는 Platform 최민영 대리 · MergeHub 김승준 사원,
소개 문구는 "사내 Merge/Diff + Git 도구"(Merge 먼저 - 창 제목 · csproj · 정보 창).
G-7 Alt+Down 화면 잘림 - 가운데 맞추기의 두 번째 스크롤이 메아리 막기에 걸려 버려졌다.
CenterCharInView 가 다른 칸을 직접 맞춘다(g7-verify 고치기 전 10건 실패 -> 0).
G-8 메모 문법 강조 · 같은 글 칠하기 · 색 마킹(Ctrl+1~5) · 위치 막대. 투명 TextBox +
아래층(사용자 결정). 화면에서 찾은 셋: 플랫폼 TextBox 스타일이 아래층을 덮음
(Style={x:Null}), 콤보에 형 이름(LanguageProfile.ToString), 어두운 테마에서 메모 탭 ·
문서 탭 제목이 검정(ItemContainerStyle 에 Foreground).
마무리(사용자 지시)
- 설정의 "프로그램 정보" 칸(만든 사람 · 사내 문의처)을 뺐다. [정보] 창은 실행 파일 값만.
- 주석 남기기가 켜져 있는데 작성자가 비면 반영 명령 맨 앞에서 알리고 반영하지 않는다
(예전에는 git 이름 · 윈도우 계정으로 조용히 채웠다). 주석을 끄면 묻지 않는다.
- 데모(설정 두 칸 · [데모 ->] 단추 · 전환 코드)를 걷어냈다.
시험: 빌드 경고 0 · 오류 0. 하네스 MemoHlTest 45 · MemoTest 69 · OverviewTest 15 ·
AboutTest 30 · NoteTest 99. 화면 최종 회귀 22벌 423건(실패 4건은 대본이 툴팁을
읽은 것 - 고쳐 통과), 마무리 뒤 g5 · g6 · g9-author 실패 0. 한 번 나오고 재현 안 된
g8 가로 스크롤 항목은 12차 기록에 "값으로 확정 못 함" 으로 남겼다.
Agent: main (claude-opus-5-5)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
12차 B-1 로 왼쪽 파일로 반영하는 길([<] · TakeLineToBase)이 생겼는데 단축키가
없었다. 덩어리를 왼쪽으로 보내는 것은 명령 자체가 없었다 - AcceptBlock
(Alt+Shift+Right)은 오른쪽으로만 간다.
키를 어디에 둘지
사용자가 "Alt+Left 도 비어 있지 않냐" 고 물었다. 비어 있지 않았다 -
CopyRightToLeft 가 쓰고 있었는데, 2-Way 에서 그것이 하는 일은 이름·화살표와
달리 "이 줄 되돌리기" 였다. 그런데 이름이 가리키는 "왼쪽으로 반영" 이 B-1 로
실제로 생겼다. 그래서 감각이 맞는 쪽으로 넘겼다(사용자 결정).
Alt+Right 한 줄 오른쪽으로 그대로
Alt+Shift+Right 덩어리 오른쪽으로 그대로
Alt+Left 이 줄 되돌리기 -> 한 줄 왼쪽 파일로
Alt+Shift+Left (없음) -> 덩어리 왼쪽 파일로 (새로 만듦)
이 줄 되돌리기 Alt+Left -> 단축키 없음, Ctrl+Z 만
Alt+Right 가 이미 2-Way/3-Way 로 갈라져 있으므로 Alt+Left 도 같은 식으로
갈랐다. 3-Way(Take Theirs)는 안 건드렸다.
만든 것
- AcceptBlockToBase · ApplyGroupToBase - AcceptBlock/ApplyGroup 의 거울.
주석은 덩어리 첫 줄 위 한 줄, 되돌리기는 한 번에(11차 F-2 와 같은 규칙).
덩어리를 잡는 BlockAround 는 2-Way 에서 이미 CanTakeBase 로 잡으므로
그대로 썼다 - 가져올 수 있는 줄과 보낼 수 있는 줄이 같은 줄이고 방향만 반대다.
- [이 덩어리 왼쪽으로] 단추 - [이 덩어리 반영] 옆에. 두 파일 비교에서만 뜬다.
단축키만 두면 찾을 길이 없다.
겪은 것
- RaiseCanExecuteChanged 와 OnCaretRowChanged 에 새 명령을 안 넣어 단추가
꺼진 채였다. CommunityToolkit 커맨드는 CommandManager 를 구독하지 않는다.
- 덩어리 명령은 고른 줄이 아니라 CaretRow(편집기 캐럿)를 본다. 시험이 목록을
고르기만 해서 한 줄만 갔다 - Alt+Down 으로 캐럿을 놓아야 했다.
확인
- 화면 g2-verify 21건 실패 0 (연속 세 줄이 다른 재료를 따로 만들어 씀)
Alt+Left 는 한 줄만, Ctrl+Z 로 되돌아가고, 덩어리는 셋이 한 번에 가고
한 번에 돌아온다
- 하네스 ShortcutTest 88 -> 101건 (키 겹침 없음, 화살표 넷의 모양이 맞음,
충돌 이동을 안 빼앗음, Alt+Left 설명이 "되돌리기" 라고 거짓말하지 않음)
- 회귀 g1 · e2 · e3 · e4 실패 0, 빌드 경고 0 · 오류 0
값으로 확정하지 못한 것: Alt+Shift 조합을 흉내 낸 키로는 못 눌렀다. 윈도우가
입력 언어 전환으로 먼저 채간다 - SendKeys 로는 아예 안 닿고 keybd_event 로는
Shift 가 빠져 Alt+Left 처럼 동작했다. 기존 Alt+Shift+Right 로 견줘 봐도 같아
시험 도구 한계다(C-3 의 DragMove 와 같은 부류). 그래서 덩어리는 같은 명령을
부르는 단추로 확인했다. 사람 손으로 한 번 눌러 보는 것이 남았다.
Agent: main (claude-opus-5)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
짝을 바꾼 뒤 Ctrl+Z 를 누르면 앞 파일 글(234자)과 지금 파일 글(228자)을
끝없이 오갔다. 40번을 눌러도 안 끝났고, 글자를 하나도 안 쳐도 났다.
Ctrl+Z 는 우리 목록(_undo · _textUndo)이 비면 일부러 키를 먹지 않는다
(RunShortcut - 그래야 편집기의 글자 되돌리기가 살아 있다는 뜻이었다).
그러면 그 키가 TextBox 자체 되돌리기로 넘어가는데, WPF 의 그것은 한도가
없고 프로그램이 코드로 넣은 글까지 기록한다. 그래서 짝을 바꿔 새 파일을
실으면 그 글도 기록에 쌓이고, Ctrl+Z 가 앞 파일 글을 편집기에 되살렸다.
거기서 끝이 아니었다. 되살아난 앞 파일 글을 Reflow 가 "사용자가 친 것"
으로 보고 모델을 그쪽으로 되돌리며 되돌리기에 다시 쌓고 다시하기를 지운다.
다음 Ctrl+Z 는 우리 목록으로 되돌리고, 그러면 또 TextBox 것이 되살린다.
기록을 심어 고리를 떴다:
Sync 끝났다 편집기=228
편집알림 편집기=234 모델=216
Reflow 모델=216 편집기=221 같나=False
StepText 목표=216 … 편집기=234
221 = 234 - 13(줄 13개의 CRLF/LF 차이)이라 편집기가 쥔 것이 앞 파일임을
값으로 확인했다.
고침은 한 줄이다 - LocalEditor 에 IsUndoEnabled="False". 되돌리기는 우리
목록만 쓴다(줄 단위 _undo, 글 단위 _textUndo).
확인
- g1-verify 14건 실패 0. 30번을 눌러도 길이 자취가 228 하나뿐
- 앞 파일(234자)은 자취에 한 번도 안 나온다
- 되돌리기 자체는 살아 있다 - 친 글은 Ctrl+Z 로 되돌아간다
- 회귀 e1 · e2 · e2-reg · e3 · e4 전부 실패 0
- 빌드 경고 0 · 오류 0
헛짚은 것 둘도 기록에 남겼다. "문서가 바뀔 때 TextBox 기록을 비우면 된다"
(EditorUndoGate 를 만들어 하네스 16건까지 붙였다)와 "재정렬 타이머가 되돌린
뒤 뒤늦게 터진다" 는 둘 다 증상이 안 없어져 되돌렸다. 검증 안 된 동작
변경은 남기지 않는다.
남은 것: 글자 한 자 단위 되돌리기는 없어졌다. 이제 한 걸음은 "타이핑이
멈춘 자리" 다. 쓰다가 너무 굵으면 _textUndo 를 더 잘게 쌓는 것으로 따로 잡는다.
Agent: main (claude-opus-5)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
우리가 따로 쓰던 플랫폼 소스(D:\Sorce\ubsrepo, 원격이 Ubisam-MergeTool 이었다)에
얹어 둔 두 커밋을 진짜 플랫폼 저장소 D:\Sorce\UbisamCommonPlatform 으로 옮겼다.
MergeHub 코드는 손대지 않았다 - 문서만 고친다.
6991dfd 이후 양쪽이 갈라져 있었다. 우리 2커밋(트레이 · 창 자리 기억 · 세 갈래
묻는 창 · 탭 줄 크기 · 헤더 접기) vs 공용 4커밋(우클릭 메뉴 테마 · 앱 아이콘 ·
업데이트 기본값 · HANDOFF). 소스 파일이 하나도 겹치지 않아 부딪힌 것은
changelog.md 한 군데뿐이었고, 양쪽 줄을 다 살려 날짜순으로 합쳤다.
공용 쪽에 빠져 있던 문서도 채웠다 - 가이드 8-5 에 헤더 접기, HANDOFF 5·6절에
우리 기능. C-3 은 플랫폼 changelog 에도 줄이 없었다.
빌드해 이 PC 의 D:\UbisamPlatform\bin 까지 반영했다(오류 0 · 경고 4). dist 는
손대지 않았으므로 사내 다른 PC 는 그대로다.
화면 회귀 아홉 벌 208건 실패 0 · 예외 0. MergeHub 재빌드 경고 0 · 오류 0 -
플랫폼 API 는 깨지지 않았다.
지난번에 적은 "204건" 은 c3-verify 를 21건으로 잘못 센 것이었다(실제 25건).
세 문서 모두 208 로 고쳤다.
값 하나는 확정하지 못했다 - 이 회귀에서 C-3 의 모듈 시작 자리가 144px -> 51px
대신 154px -> 61px 로 나왔다. 벌어드린 높이는 93px · 62 DIP 로 똑같고, 따로
돌리니 다시 144 -> 51 이 나왔다. 공용 쪽 네 커밋(암시적 스타일이 ContextMenu ·
MenuItem 뿐)과 뜨는 모드(mode-probe.ps1 로 재 보니 둘 다 144px)는 원인이
아니었다. 무엇이 10px 을 밀었는지는 끝까지 캐지 않았다.
Agent: main (claude-opus-5)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
플랫폼을 바꿔 배포했으니 그 위에 얹혀 도는 12차 화면 시험을 전부 다시 돌렸다.
MergeHub 코드는 손대지 않았다 - 문서만 고친다.
f1 38 · d1 39 · e1 24 · e2 34 · e2-reg 18 · e2-start 8 · e3 16 · e4 6 · c3 21
= 204건, 실패 0 · 예외 0.
한 벌에 들어가기 전 앞 벌이 남긴 창과 보관함(D:\UbisamConfig\Memo ·
Session\MergeHub)을 치워 서로 섞이지 않게 했다(run-all-c3.ps1). 끝나고
MergeHubSettings.json · UiSettingsService.json · MergeHub.Recent.txt ·
ShellWindowPlacement.json 을 시작 기준본과 바이트까지 같게 되돌렸다.
여전히 사람 손이 필요한 것: 접은 C-3 띠를 끌면 창이 따라오는가.
흉내 낸 마우스로는 WPF DragMove 가 움직이지 않고, 예전부터 되던 기존 헤더
끌기로 견줘 봐도 같았다(시험 도구 한계).
Agent: main (claude-opus-5)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
플랫폼 쪽 코드는 D:\Sorce\ubsrepo 에 따로 커밋했다. 여기에는 값과 판단을 남긴다.
- 재현: 헤더가 모듈 화면을 144px 아래로 밀고 있었고, 접는 길은 설정 화면 체크박스뿐,
접으면 되살릴 띠도 단축키도 없었다
- 정한 것(사용자): 단축키 Ctrl+F11, 띠에는 화살표와 안내 글만(시계 · 이름은 빼고)
- 값: 모듈 시작 144px -> 51px (62 DIP 벌었다), 다시 켜도 접힌 채,
F11 은 그대로 아래 탭 줄만
- 확정 못 한 것: 접은 띠를 끌면 창이 따라오는가 - 흉내 낸 마우스로는 WPF DragMove 가
움직이지 않고 기존 헤더로 견줘 봐도 같았다(시험 도구 한계)
- 배포: 사용자 확인 뒤 빌드해서 바로 반영. 배포본은 bin-backup-c3 에 백업
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자가 정한 것: 메모 + 파일 열기 둘 다, 저장 단추 없이 계속 남는다,
이름은 "메모 1 · 메모 2" 번호만, 편집기는 줄 번호 · 글자 크기 · 줄바꿈 + 찾기/바꾸기.
무엇을 만들었나
- Services/Memos.cs: Memo(한 장) · MemoBook(번호 · 이름 · 넘기기 · 닫기, 계산만) ·
MemoStore(보관, {설정 폴더}\Memo\)
- ViewModels/MemoViewModel.cs: 새 메모 · 파일 열기 · 저장 · 다른 이름으로 · 닫기 ·
자동 보관(2초) · 켤 때 되살리기
- Views/MemoView.xaml(.cs): 동작 한 줄 · 메모 탭 줄 · 찾기/바꾸기 줄 · 줄 번호 편집기 · 상태 줄
- AppSetup: 하단 탭 맨 뒤에 넣었다 - 앞 세 탭의 차례가 바뀌면 손버릇도 바뀐다
정한 것
- 보관 자리는 {설정 폴더}\Memo\ - E-1 의 Session\ 과 따로. 저쪽은 "저장하면 사라지는 것",
메모는 "지우기 전까지 남는 것"이라 수명이 다르다. 모양(목록 한 장 + 글마다 파일)은 같다
- 이름 없는 메모는 번호만. 첫 줄을 따오면 글을 고칠 때마다 탭 줄이 요동친다.
번호는 비어 있는 가장 작은 수 - 메모 1 을 닫고 새로 만들면 다시 메모 1
- 파일로 연 메모와 이름 없는 메모를 한 탭 줄에 섞는다(notepad++ 와 같다)
- 탭 줄 · 저장 안 한 가운뎃점 · Ctrl+Tab · 가운데 단추 닫기는 12차 E-2 문서 탭과 같은 모양 -
두 화면이 서로 다르게 움직이면 배우는 것이 둘이 된다
- 닫을 때 저장하지 않은 것이 있으면 세 갈래로 묻는다(사용자 결정) -
저장하고 닫기 · 저장하지 않고 닫기 · 취소. 고친 것이 없으면 묻지 않는다.
저장이 막히면(취소 · 쓰기 실패) 닫지 않는다
- 메모는 문서 탭과 달리 글을 스스로 들고 있다 - 메모는 원래 작은 글이고,
이름 없는 메모에는 다시 읽어 올 파일 자체가 없다
화면을 보고 고친 세 가지(사용자 보고)
- 다른 탭에 갔다 오면 메모 글이 비어 보였다. 탭을 오가면 화면이 다시 만들어지는데
그때 편집기가 잠깐 비어 있고, 그 틈에 글을 거두면 빈 글로 메모를 덮어썼다.
편집기가 지금 어느 장을 싣고 있는지를 두고, 맞지 않으면 거두지 않게 했다
- 줄 번호와 글이 어긋났다. TextBlock 으로 그렸더니 줄 높이가 조금씩 달라 아래로 갈수록 벌어졌다.
편집기와 같은 종류(TextBox)로 바꾸고 글꼴 · 크기 · 여백을 같은 값으로 두니 같은 자로 줄을 잰다
- 글이 칸 한가운데에서 시작했다. 플랫폼 입력 칸 스타일이 글 칸을 세로 가운데에 붙박아 둔다 -
한 줄짜리 칸을 겨냥한 값이다. VerticalContentAlignment 로는 안 풀려 그 칸을 직접 늘렸다
확인
- 하네스 MemoTest 69건 새로 만듦. 전체 29벌 1,934건 · 실패 0. 빌드 경고 0 · 오류 0
- 화면 30건: 세 장 만들어 각각 쓰기 · 글 안 섞임 · 강제 종료 뒤 세 장이 차례 · 글 그대로 ·
Ctrl+F 찾기 · 모두 바꾸기 3곳 · 닫을 때 세 갈래로 묻고 취소하면 그대로 · 빈 메모는 안 물음 ·
40줄에서 줄 번호 40개가 글과 맞음 · 다른 탭 멀쩡
- 화면 여덟 벌(E-1 · E-2 · D-1 · 줄 번호 · 줄 밀림 · F-1) 모두 통과
시험 도구도 고쳤다: 스크립트가 변수 이름을 $keep 로 써서 라이브러리의 $Keep(되돌릴 설정 목록)을
덮어쓰는 바람에 시험이 끝나도 설정이 안 돌아왔다. 묻는 창을 찾는 도구도 단추 이름을
"저장하지 않고 계속" 로 못 박아 두어 말이 다른 창을 못 알아봤다 - 앞부분만 맞춰 보게 했다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
재현: 경로 · 옵션 · 찾기 · 색 범례가 네 줄로 305px(배율 150% 기준 203 DIP)를 먹었고,
비교하기 전에도 그대로였다. 자주 쓰는 [비교] 는 옵션 줄 끝에 묻혀 있었다.
위 한 줄
[...] 왼쪽 경로 <-> [...] 오른쪽 경로 [최근 v] 켠 옵션 [비교] [취소] [옵션 v]
- 폴더 고르기는 글자 대신 ... 로. 경로 칸 바로 앞에 두어 어느 쪽 것인지 헷갈리지 않는다
- 좌우 바꾸기를 새로 넣었다(사용자 결정) - 반대로 견주려고 두 번 고르지 않아도 된다
- 최근 목록은 화살표만 남겼다
옵션 서랍
- 빠른 비교 · 하위 폴더 포함 · 보기 · 포함 · 제외를 [옵션 v] 안으로. [폴더 안 찾기] 도 여기에
- 서랍에 넣으면 "내가 뭘 켜 뒀더라" 를 알 수 없게 된다 - 특히 제외 규칙은 켠 줄 모르고
"왜 이 파일이 안 보이지" 로 이어진다. 기본과 다른 것만 한 줄에 짧게 적는다(FolderOptionText).
기본 그대로면 아무것도 적지 않는다 - 늘 떠 있는 글은 눈에 띄지 않는다
찾기 · 색 범례
- 찾기는 늘 한 줄을 먹던 것을 Ctrl+F 로 부를 때만 편다. Esc · [찾기 접기] 로 접는다
- 색 범례는 아래 상태 줄로 내렸다 - 색은 목록을 보는 동안 필요한 것이라 결과 요약 옆이 제자리다
화면으로 확인
- 위쪽 높이 305px -> 77px (203 -> 51 DIP, -75%)
- 좌우 바꾸기: 누르면 맞바뀌고 다시 누르면 되돌아온다
- 옵션 서랍에 넣은 것이 다 있고, 빠른 비교를 켜면 줄에 "빠른 비교", 제외 규칙이 있어 "규칙 1"
- Ctrl+F 로 77 -> 158px, Esc 로 다시 77px
- 비교 그대로 동작(전체 2개 · 다름 2 · 왼쪽만 0 · 오른쪽만 0 · 같음 0)
- 되던 것이 하나도 없어지지 않았다: 폴더 고르기 · 최근 · 빠른 비교 · 하위 폴더 · 보기 거르기 ·
포함/제외 · 폴더 안 찾기 · 결과 내보내기 · 복사/삭제 · 줄 단위 비교 · 색 구분(아래로)
- 좁은 창(1920px = 1280 DIP)에서도 여전히 77px 한 줄, [비교] · [옵션] 다 보임
화면을 보고 고친 것: [옵션 v] 를 ToggleButton 으로 뒀더니 플랫폼 기본 스타일이 스위치 모양이라
같은 줄의 다른 단추와 따로 놀았다. 여느 단추로 바꿨다. 최근 목록도 폭을 못 박지 않아
넓게 벌어지던 것을 고쳤다.
하네스 FolderTest 118 -> 131건, 전체 28벌 1,865건 · 실패 0. 빌드 경고 0 · 오류 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
E-2 가 만든 보관함(탭이 사라져도 고친 글이 짝 이름으로 남는 자리)을 그대로 파일로
옮겨 적는 일이다. 새로 정할 것은 언제 쓰고 언제 되살리는가뿐이었다.
어디에 · 어떤 모양으로
{설정 폴더}\Session\MergeHub\
목록.txt 차례 · 짝 경로 · 캐럿 · 스크롤 · 저장 형식 · 보고 있던 탭 · 그때 파일의 자취
01-오른쪽.txt 저장하지 않은 오른쪽 글(있을 때만)
01-왼쪽.txt 저장하지 않은 왼쪽 글(12차 B-1, 있을 때만)
11차 F-9 백업과 다른 자리다 - 백업은 "저장하기 전 파일", 이것은 "저장하지 않은 편집" 이라
뜻도 수명도 다르다.
- JSON 을 쓰지 않는다(최근 목록과 같은 까닭). 사람이 열어 보고 고칠 수 있고, 무엇보다
글 안에 무엇이 들었든(따옴표 · 줄바꿈 · 제어 문자) 본문을 따로 파일로 두면 탈이 없다
- 원본 글은 담지 않는다. 파일에서 다시 읽으면 되고, 담아 두면 그 사이 파일이 바뀌었을 때
낡은 것을 보여 준다. 대신 그때 파일의 길이 · 마지막으로 쓴 때(FileStamp)만 적어 둔다
- 목록은 맨 나중에 쓴다 - 목록이 있다는 것이 곧 글 파일이 다 있다는 뜻이다
- 못 읽거나 못 써도 조용히 넘어간다. 보관 때문에 프로그램이 안 켜지면 안 된다
언제 쓰나
- 글자가 멈춘 뒤 2초에 한 번(DispatcherTimer)
- 탭을 옮길 때 · 닫을 때 · 새 짝을 열 때는 그 자리에서 바로 - 그 순간이 곧 끄기 직전일 수 있다
- 쓰는 일은 다른 실로 넘긴다(Task.Run). 화면 상태를 뜰 때 ParkCurrentTab 을 쓰지 않는다 -
그쪽은 되돌리기 목록을 글 단위로 눌러 담는데, 2초마다 이력을 주무를 까닭이 없다.
보관할 것은 글과 자리뿐이고 되돌리기 이력은 되살리지 않기로 정했다(사용자 결정)
언제 되살리나
켤 때 묻지 않고 그대로(사용자 결정). 다만 사용자가 지금 열라고 한 것이 먼저다 -
충돌 파일 열기 · git mergetool · 폴더 비교에서 고른 파일. 설정의 기본 저장소 · 기본 짝보다는 앞선다.
원본 글은 파일에서 다시 읽고 그 위에 편집을 얹는다(E-2 의 ResumePendingTab 그대로).
원본이 그 사이 바뀌었으면 되살리고 알린다 - "연 시점" 은 새로 읽은 글로 두어
[전체 되돌리기] 가 지금 파일로 가고, 고친 글은 편집으로 남는다.
두 파일이 다 없어진 짝은 되살릴 자리가 없으므로 버린다.
확인
하네스 SessionTest 65건 새로 만듦(글로 옮기고 되읽기 · 빈칸/한글/UNC 경로 ·
알아볼 수 없는 줄 건너뛰기 · 보관할 것 없으면 치우기 · 옛 글 파일 치우기 ·
글 파일이 없어져도 넘어가기 · FileStamp · 보관함 주고받기). 전체 28벌 1,852건 · 실패 0.
화면 24건: 두 짝을 고치고 작업 관리자로 끄듯 강제로 끝낸 뒤 다시 켜면 묻지 않고
탭 2개가 이름 · 차례 · 글 그대로 되살아나고, 한쪽을 저장하면 가운뎃점이 2->1,
둘 다 저장하면 보관본이 사라지고, 다시 켜면 되살릴 것이 없다.
원본이 그 사이 바뀌면 되살리고 "저장하면 바뀐 파일을 덮어씁니다" 를 알린다.
빠르기에 대해: 5,003줄(113KB) 짝에서 글자당 31ms 로 4줄짜리와 같았다(앱이 입력에 밀리지 않는다).
다만 "친 뒤 화면에 보이기까지" 는 값으로 확정하지 못했다 - 그것을 재려면 편집기 글을
UIA 로 읽어야 하는데 5,003줄 창에서는 그 읽기가 타이핑보다 훨씬 오래 걸려 값이 오염된다.
재는 법을 따로 마련해야 한다.
시험 도구: E-1 이 도니 지난 시험이 남긴 편집이 다음 시험에서 되살아나 화면이 달라졌다
(e3-verify 가 왼쪽 7줄 대신 14줄을 봤다). 시험마다 보관 자리를 치우고 시작해 끝에
되돌리도록 고쳤다 - 기능이 제대로 도는 증거이기도 하다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자가 그림으로 짚어 준 것. 12차 B-1 로 넣은 [<] 단추가 든 칸의 폭이 Auto 여서,
단추가 보이는 줄에서만 칸이 벌어져 뒤 칸이 통째로 오른쪽으로 밀렸다.
같은 칸 안에서도 줄마다 글이 시작하는 자리가 달랐다.
BASE LOCAL
01 class Axis 01 class Axis
< 03 int speed = 100; 03 > int speed = 200; <- 밀림
< 04 // left only line 05 > < void Stop() { } <- 더 밀림
05 void Home() { } 06 }
BASE 는 [<] 가 맨 앞 칸이라 번호까지, LOCAL 은 번호 뒤 칸이라 코드가 밀렸고,
단추가 하나 늘 때마다 한 칸씩 더 밀렸다.
Visibility="Collapsed" 은 자리까지 없애므로, 자리를 지키려면 칸 폭이 고정이어야 한다.
- GutterBothWaysWidth 를 두어 BASE · LOCAL 이 같은 자리를 늘 잡아 둔다
- 화면이 모드에 따라 갈아 끼운다(ApplyGutterReserve) -
두 파일 비교는 단추 폭, Git 모드와 네 칸은 0(그 단추가 아예 없다 - 여백이 예전 그대로)
- 투명한 편집기가 아래 표시층과 어긋나면 캐럿이 글자와 다른 자리에 선다 -
EditorGutterMargin 도 같은 값만큼 민다
- 글자 크기(11차 F-5)를 바꾸면 단추 폭이 따라 바뀌므로, 잡아 두는 자리도
CodeFontMetrics 한 벌에서 나온다
화면으로 확인: 한 칸의 모든 줄이 같은 x(BASE 137 · LOCAL 1283),
글자 크기를 키워도 한 x(147), Git 모드도 한 x(459). 오류 글 0.
E-2 화면 세 벌 · 왼쪽 번호 한 벌 모두 그대로 통과. 빌드 경고 0 · 오류 0.
남겨 둔 것: BASE 줄 끝의 [>](11차 F-10)는 아직 Auto 다. 왼쪽 가장자리를 밀지 않고
오른쪽에서 코드 칸을 조금 좁힐 뿐이라 눈에 띄지 않는다. 워드랩을 켜면 그 줄만
접히는 자리가 달라질 수 있다 - 워드랩은 기본이 꺼짐이라 이번에는 두었다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
사용자 보고. 12차 B-1 로 왼쪽에도 반영할 수 있게 되면서 왼쪽 줄이 늘고 주는데,
번호는 정렬기가 처음 준 것 그대로였다. 오른쪽에만 있던 줄을 왼쪽에 넣으면
그 줄은 번호가 비고 뒤 줄은 옛 번호를 달아 01 02 (빈) 03 04 05 (빈) 06 으로 보였다.
왼쪽 파일은 8줄이 됐는데 번호는 6까지라 어느 줄을 고쳤는지 짚을 수 없었다.
MergeLine.BaseNumber 의 설명에는 이미 "이제 두 파일 비교에서는 번호도 따라 바뀐다" 고
적혀 있었지만 실제로 다시 매기는 자리가 없었다 - 적어 둔 뜻과 코드가 어긋나 있었다.
- RenumberBase 를 RenumberMerged(8차 B-3) 옆에 두고, 그릴 때마다 왼쪽에 있는 줄만 1부터 다시 맨다
- 두 파일 비교(BothWays)에서만. Git 모드 · 네 칸의 BASE 는 지난 커밋 · 공통 조상이라
고칠 수 없고, 그때 번호는 그 파일의 번호이므로 건드리지 않는다
- "머지 반영함" 표시는 BASE 줄 번호를 열쇠로 붙들고 있다(_appliedBaseNumbers) -
번호가 실제로 달라질 때만 그 열쇠도 옛 번호에서 새 번호로 옮겨 담는다.
안 그러면 규칙을 한 번 건드리는 순간 엉뚱한 줄이 반영함으로 칠해진다
화면으로 확인: 연 직후 01..07, 두 줄 넣으면 01..09 로 이어짐, 되돌려도 이어짐,
왼쪽 저장하면 파일 9줄 = 칸의 끝 번호 09, Git 모드 회귀 그대로.
하네스 27벌 1,787건 · 실패 0. 빌드 경고 0 · 오류 0.
아직 확정하지 못한 것: 왼쪽에만 있는 줄을 [<] 로 뺄 때 왼쪽 줄 수가 하나 주는지.
따로 열어 한 번 누르면 잘 빠지는데(3줄 -> 2줄), 다른 반영을 몇 번 한 뒤에는
시험 도구가 읽은 줄 칸이 낡아 옆 줄 단추를 눌러 값이 흔들렸다.
번호 불변식(늘 1부터 이어지고 빠진 번호가 없다)은 어느 경우에도 지켜졌다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
새 플랫폼(UbisamBase.Launcher) 위로 옮기면서 12차 A~E 를 한 번에 담는다.
항목별 값과 판정은 doc/history/2026-09-23-12차.md, 요약은 doc/history/changelog.md.
A. 폴더 비교를 읽기 쉽게
- A-1 폴더 줄의 크기가 늘 0B 이던 것 - 안에 든 파일 크기 합계를 아래에서 위로 더해 적는다
(걸러 낸 파일은 합계에서도 빠진다)
- A-2 좌우로 나눠 보이기 - 왼쪽 · 오른쪽 목록을 나란히 두고 같은 줄에 맞춘다.
한쪽에만 있는 항목은 반대편을 비운다
B. 파일 비교 화면
- B-1 2-Way 에서 양쪽으로 머지 - 칸마다 반영 · 저장. 왼쪽 기준점을 따로 세고,
되돌리기 · 저장 백업도 양쪽 모두
- B-2 프로그램 정보 창 - 버전 · 빌드 날짜 · 만든 사람 · 사내 문의처 · 플랫폼 버전 · 로그 폴더
- B-3 칸 아래에 무엇이 달라졌는지 - 칸마다 줄 수 · 추가 · 삭제 · 수정, 가운데에 진행
C. 플랫폼 (플랫폼 저장소에서 함께 나감)
- C-2 하단 탭 줄을 한 단계 작게 - 74 -> 61 DIP. 실측 133 -> 109px 이고
그만큼 코드 칸이 늘어 파일 비교가 47 -> 48줄
E. 저장하지 않아도 남는 편집
- E-2 여러 짝을 동시에(문서 탭). 지금까지는 한 짝만 들어서 짝을 바꾸면
저장하지 않은 편집을 묻고 버리면 사라졌다(재현: 16줄 -> 15줄).
이제 떠 있던 탭이 그 글을 맡아 두므로 묻지 않는다.
- 탭마다 HomeViewModel 을 따로 만들지 않았다 - 이 화면은 GitWorkspace 의 여러 사건과
한 자리짜리 약속(ConfirmDiscardEdits · ConfirmLeaveCommit)에 물려 있다.
화면은 하나로 두고 탭이 파일에 없는 것만 맡는다(고친 글 · 왼쪽 글 · 되돌리기 이력 ·
두 기준점 · 캐럿 · 스크롤 · 저장 형식)
- 탭 이름은 파일 이름, 다르면 왼 <-> 오. 양쪽이 같은 부분은 한 번만 적는다
(WeldController_기준 <-> 내작업.cs, 421 -> 288px). 같은 이름이 겹치면
갈릴 때까지 위 폴더를 한 겹씩 덧붙인다
- 저장하지 않은 탭에 가운뎃점. 사람이 손댄 것만 센다 - 중괄호 맞춤으로만 바뀐 것은
묻는 자리와 같은 기준으로 뺀다(안 그러면 .cs 를 여는 것만으로 늘 점이 붙는다)
- 탭이 사라져도 고친 글은 보관함에 남아 다시 열면 되살아난다(짝 50개).
E-1(껐다 켜도 남는 편집)은 이 보관함을 파일로 옮겨 적으면 된다
- 이전 · 다음 파일은 지금 탭의 짝만 바꾸고, 폴더 비교에서 두 번 누르면 새 탭(사용자 결정)
- Ctrl+Tab · Ctrl+Shift+Tab · Ctrl+W · 가운데 단추 닫기. 닫을 때도 묻지 않는다
- Git 탭 · 병합 중 네 칸은 탭이 맡지 않는다 - 그쪽은 예전처럼 묻는다
하네스 27벌 1,787건 통과 · 실패 0(DocTabTest 106건 새로 만듦).
빌드 경고 0 · 오류 0. 화면으로 E-2 34건 · 회귀 19건 확인.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
