Ubisam-MergeTool/doc/작업지시/11차.md

작업 지시 — MergeHub 11차 (변경분 추출을 믿고 들고 가게 · 베타 전에 깨지는 것 · 남은 기획 범위)

대상: D:\Sorce\MergeTool\MergeHub (플러그인) · D:\Sorce\MergeTool\UbisamPlatform (셸) 전제: 1~10차 지시서는 모두 끝났다(../진행상황.md).

이번 지시서가 나온 곳 — 10차 E-1 에서 다섯 길(병합 · pull · rebase · cherry-pick · revert)을 다시 끝까지 했고 새로 걸린 것은 없었다. 그래서 11차는 "고칠 버그" 가 아니라 기획안 v1.2 에서 아직 "일부" 인 것과 사내 베타(기획 4단계, 09.29 ~ 10.02) 전에 막아야 할 것에서 나왔다. 근거는 코드를 읽고 적은 것이다 — 실제로 해 보기 전의 짐작이므로 항목마다 먼저 다시 내고 시작한다.

어디서	무엇을 봤나	근거
변경분 추출 (기획안 "일부")	지운 파일은 개수만 알리고 목록이 어디에도 안 남는다(코드 주석은 "목록에만 남긴다") · 어느 범위를 뽑았는지 폴더에 안 남는다 · 이미 파일이 있는 폴더에 묻지 않고 덮어쓰고 옛 파일이 섞인다 · ZIP 없음	GitService.ExportChangedFiles · GitViewModel.ExportChangesAsync
배포 폴더	매뉴얼이 가리키는 bin\Release\net48 의 MergeHub.dll 이 09-07 14:11, 셸이 09-07 13:41 — 10일 동안 Debug 로만 빌드했다. 폴더 크기 96MB(LiveCharts · Skia · OpenTK 등 플랫폼 런타임 포함)	파일 시각 · README.txt
설정 · 로그 위치	플랫폼이 D:\UbisamConfig 를 고정으로 쓴다. D 드라이브가 없는 PC 에서 어떻게 되는지 모른다	UbisamAppBuilder.ConfigRoot · LogService · LockConfirmDialog
커밋 메시지 수정 (기획안 "일부")	마지막 커밋만 커밋 수정. 기획안은 "커밋 우클릭 → 이름 변경". 있는 [커밋 수정] 에도 걸리는 것이 보인다 — [마지막 메시지] 가 HEAD 가 아니라 이력 목록 맨 위 메시지를 가져옴([모든 브랜치] 면 다른 브랜치 커밋) · 스테이징해 둔 파일이 말없이 같이 들어감 · 원래 작성자 · 작성 시각을 지금 사람으로 바꿈(git 은 남김) · 병합 · rebase 중에도 켜짐 · 확인 창 · 되돌릴 옛 해시 없음 · 하네스에 amend 검사 0건	GitViewModel.AmendAsync · LoadLastMessage · GitService.Commit
10차 E-1 시험 도구	줄끝 검사 스크립트가 부모 하나인 커밋에서 오류를 찍음 · 요약 읽는 함수가 "차이 없음" 을 못 읽음	../history/2026-09-17-10차.md E-1 "남긴 것"

---

공통 규칙

• A → B → C → D → E 순서로 진행한다. A 는 사용자가 물어 본 것이라 먼저다. B 는 베타 날짜가 있어 C 보다 앞이다.
• 항목 하나를 끝낼 때마다 빌드하고 실제로 실행해 화면을 확인한 뒤 보고한다.
• 항목 하나가 끝나면 기록을 세 군데에 남기고 로컬 커밋한다(4차 D-2 규칙).
  1. 상세는 doc/history/YYYY-MM-DD-11차.md — 원인 · 판단 · 확인한 결과
  2. ../진행상황.md 은 대기 → 완료로 상태만
  3. ../history/changelog.md 에 한 줄 — 날짜 · 무엇을 왜 · 커밋
• 푸쉬하지 않는다.
• 실제 소스를 열지 않는다(2026-09-11 결정). 시험 재료는 C1Repo(병합 저장소) · FolderPerf/Corpus.cs(폴더 묶음) · 직접 만든 파일로 만든다. 고치기 전에 문제가 다시 나는 것부터 보이고, 고친 뒤 안 나는 것을 보인다. 다시 나지 않으면 짐작으로 고치지 않고 되풀이한 횟수와 짚은 곳을 적어 보고한다.
• 기존 검사 하네스(22벌 1,147건)는 계속 통과해야 한다. 로직을 건드리면 테스트를 먼저 늘린다.
• 빌드 경고 0 · 오류 0 을 유지한다. 앱이 실행 중이면 UbisamBase.Shell 을 먼저 종료한다.
• 사용자 설정 파일(D:\UbisamConfig\Settings\MergeHubSettings.json)은 시험 전에 백업하고, 끝나면 바이트 그대로 되돌린다. 창 기억(ShellWindowPlacement.json)은 시험 뒤 "기억 없음" 으로 둔다.
• 자동 조작으로 확인할 때는 사람이 갈 수 있는 길만 쓴다. 이름 창은 [저장], 접힌 영역은 [펴기], 이력 줄은 마우스로(10차 B-1 은 누르기 전에 묻는 길).
• 문서 글을 PowerShell 로 넣을 때는 작은따옴표 문자열만 쓴다(8차). PowerShell 변수 이름은 대소문자를 가리지 않는다 — 매개변수와 겹치는 이름을 쓰지 않는다(9차 A-2).
• 앱 안에 임시 측정 코드를 넣었다면 커밋하지 않고 잰 뒤 되돌리고 다시 빌드한다(9차 B-2).
• 레지스트리 HKLM · 셸 확장 · 보안(백신) 설정은 건드리지 않는다. 시스템 설정을 바꿔야만 재볼 수 있는 것은 재지 않고 적는다.
• 플랫폼을 고치면 다른 소비 프로그램에 미치는 영향을 함께 적고 UbisamPlatform/doc/history/changelog.md 에 남긴다. 배포는 사용자 확인 뒤.

---

A. 변경분 추출을 믿고 들고 가게

기획안: "장비에 소스를 통째로 넣지 못하는 현장에서 바뀐 파일만 들고 간다." 들고 간 폴더만 보고 무엇이 바뀌고 무엇을 지워야 하는지 알 수 있어야 쓸 수 있다.

A-1. 먼저 뽑아 보고 적는다 (고치지 않음)

• C1Repo 로 저장소를 새로 만들고 Git 탭 → 이력에서 사람 순서로 뽑는다. 경우마다 뽑은 폴더를 git diff --name-status · git show <커밋>:<경로> 바이트와 견준다.

#	경우	볼 것
1	커밋 하나(시작점 없음)	뽑은 파일 수 = git diff --name-status 부모 커밋 의 A · M 수, 바이트 같음
2	[여기부터] 로 범위	범위 안 중간 커밋에서만 바뀌고 되돌려진 파일이 들어가는지
3	지운 파일이 있는 범위	알림 "삭제되어 건너뜀 N개" 뒤 어느 파일인지 알 길이 있는지
4	이름 바뀐 파일	새 경로로 뽑히는지 · 옛 경로를 알 길이 있는지
5	병합 커밋 하나	첫 부모와만 견주는지(상대 브랜치에서 들어온 파일이 모두 나오는지)
6	시작점이 고른 커밋보다 뒤	무엇이 뽑히는지 · 경고가 있는지
7	이진 파일 · 한글 경로 · 깊은 폴더	바이트 · 경로 그대로인지
8	이미 파일이 있는 폴더에 다시 뽑기	덮어쓰기 · 옛 파일이 남아 섞이는지 · 묻는지
9	뽑는 중 대상 파일이 읽기 전용 · 열려 있음	오류 문구 · 반쯤 뽑힌 채 남는지

• 판정 기준: 9가지 경우의 결과를 값(파일 수 · 해시 · 알림 문구)으로 표에 적는다. 걸린 것은 A-2 ~ A-4 에 붙이거나 새로 적는다.

A-2. 뽑은 폴더에 "무엇을 뽑았는지" 를 남긴다 — 먼저 정한다

• A-1 의 3 · 4 · 6 결과를 보인 뒤 사용자에게 형식을 정한다.
  1. 뽑은 폴더 안에 안내 파일 하나(예: _변경분.txt) — 범위(커밋 해시 · 제목 · 날짜) · 뽑은 사람 · 뽑은 파일 목록(추가 / 수정 / 이름 바뀜 옛 경로) · 지워야 할 파일 목록
  2. 폴더 밖(옆)에 같은 내용 — 장비에 폴더째 넣을 때 안내 파일이 섞이지 않게
  3. 파일은 만들지 않고 화면(Git 탭 로그 · 결과 창)에만
• 결과 내보내기(3차)와 보고서의 머리글(만든 사람 · 만든 때, 4차 A-2)과 같은 꼴을 쓴다.
• 판정 기준: 정한 대로 뽑은 결과만 보고 지워야 할 파일 · 이름 바뀐 옛 경로 · 범위를 알 수 있다. A-1 의 1 · 2 · 7 바이트 결과가 고치기 전과 같다. 하네스로 "지운 파일 · 이름 바뀜 · 병합 커밋" 목록을 만든다.

A-3. 이미 파일이 있는 폴더에 뽑을 때 — 먼저 정한다

• A-1 의 8 결과를 보인 뒤 정한다.
  1. 비어 있지 않으면 묻는다(덮어쓰기 · 취소)
  2. 고른 폴더 아래에 새 폴더를 만든다(예: 변경분_ace42e3..f310f49_2026-09-17)
  3. 그대로 둔다(한계로 매뉴얼에 적음)
• 판정 기준: 정한 대로 옛 파일과 새 파일이 말없이 섞이지 않는다. [취소] 뒤 파일이 하나도 바뀌지 않았다.

A-4. ZIP 으로 뽑기 — 할지 먼저 정한다

• 폴더로만 뽑는다(기획안 "폴더·ZIP"). 필요한지 사용자에게 묻는다. 한다면 A-2 안내 파일이 ZIP 안에 들어가고, 풀었을 때 바이트 · 경로가 폴더로 뽑은 것과 같아야 한다.
• 판정 기준: 안 하기로 하면 기획안 · 웹 문서에 "폴더로만" 을 까닭과 함께 적는다. 하면 폴더 결과와 ZIP 을 푼 결과의 해시 목록이 같다.

---

B. 사내 베타 전에 깨지는 것

기획 4단계(09.29 ~ 10.02) 에 다른 사람 PC 에서 처음 켠다. 지금까지는 이 PC · 이 경로 · 이 설정에서만 켰다.

B-1. 배포 폴더가 10일 전 것이다 — 다시 만들고 무엇이 들어가야 하는지 정한다

• 매뉴얼("개발 PC 에서는 src\MergeHub\bin\Release\net48\UbisamBase.Shell.exe")이 가리키는 Release 출력의 MergeHub.dll 이 2026-09-07 이다. 먼저 지금 Release 로 켜면 무엇이 다른지(예: 6차 이후 기능이 없는지)를 한 번 확인해 적는다.
• Release 로 다시 빌드하고, 배포 묶음에 꼭 필요한 파일을 가린다: 셸 · 플러그인 · LibGit2Sharp 네이티브(lib\win32 · win-x64) · CommunityToolkit · 설정 기본값 · Lang. LiveCharts · Skia · OpenTK 가 MergeHub 에 필요한지는 지워 보고 켜서 가린다(플랫폼이 쓰는지 같이 본다).
• 빈 폴더(예: %TEMP%\mergehub-beta)에 묶음만 복사해 켜고, 다섯 탭 · 병합 한 길(C1Repo)을 끝까지 한다.
• 판정 기준: 배포 묶음 목록(파일 · 크기 · 왜 필요한지)과 총 크기를 적는다. 빈 폴더에서 켜 병합 커밋까지 된다. 매뉴얼의 실행 위치 문장이 사실과 같다. 플랫폼 배포 폴더를 바꿔야 하면 사용자 확인 뒤.

B-2. D 드라이브가 없는 PC · 설정 파일이 없는 첫 실행

• 플랫폼이 설정 · 로그 · 화면 잠금 기록을 D:\UbisamConfig 에 고정으로 쓴다. D 드라이브를 없애는 시험은 하지 않는다(디스크 설정). 대신 코드로 "D:\ 가 없을 때 어느 줄에서 무엇이 되는지" 를 따라가 적고, 설정 파일 · 폴더가 없는 첫 실행은 백업 뒤 폴더 이름을 잠시 바꿔 재 본다(끝나면 바이트 그대로 되돌림).
• 첫 실행에서 볼 것: 이름 창 · 기본 설정 값 · 창 위치 · 로그 폴더 생성 · 오류 창 여부.
• 방향: D 드라이브가 없을 때 켜지지 않는다면 플랫폼 문제다. 고치는 길(예: 없으면 사용자 폴더로)을 다른 소비 프로그램 영향과 함께 사용자에게 보이고 정한다.
• 판정 기준: 첫 실행이 오류 창 없이 켜지고 기본값이 매뉴얼 설정 표와 같다. D 드라이브 없는 경우의 결과를 코드 근거로 적었다(고쳤다면 플랫폼 changelog).

---

C. 커밋 메시지 수정 — 기획 범위에서 "일부" 로 남은 것

기획안 1차 범위 "커밋 메시지 수정 — 커밋 우클릭 → 이름 변경. 명령어와 옵션을 외울 필요 없음". 기획안 v1.2 · 웹 문서에는 "마지막 커밋만 커밋 수정" 으로 일부라고 적었다. 그런데 코드를 다시 읽으니 있는 [커밋 수정] 도 믿고 쓰기 어려운 곳이 있다. 새 기능(C-2)을 정하기 전에 있는 길부터 바로잡는다.

지금 모양 (Git 탭 → 변경 · 커밋, 아래 줄 커밋 메시지 [칸] [마지막 메시지] [커밋] [커밋 수정]):

• [커밋 수정] = GitService.Commit(message, amend: true) → LibGit2Sharp Repo.Commit(message, 지금 사람, 지금 사람, AmendPreviousCommit). 켜지는 조건은 저장소가 열려 있고 메시지 칸이 비어 있지 않음 뿐이다.
• [마지막 메시지] = _workspace.Commits[0].Message — 이력 목록의 맨 위 커밋 메시지.
• 이력 탭에서 고른 커밋과는 상관없이 늘 HEAD 를 고친다. 우클릭 메뉴는 없다.
• 하네스(GitOpTest 등)에 amend 를 재는 검사가 없다.

C-1. 있는 [커밋 수정] 을 다시 내 보고 바로잡는다 (원인부터)

• C1Repo 로 저장소를 새로 만들어 사람 순서로 한다. 경우마다 고치기 전 결과를 git log -1 --format="%H %an %ae %ad %cn %s" · git show --stat · git status 로 적는다.

#	짚이는 것	다시 내는 순서	git 은 어떻게 하나
1	[마지막 메시지] 가 다른 커밋 메시지를 가져온다	이력 [모든 브랜치] 켬(9차 A-2: 맨 위가 다른 브랜치 커밋) → 변경 · 커밋 [마지막 메시지] → 칸의 글이 HEAD 메시지인지 → 그대로 [커밋 수정] 하면 HEAD 가 다른 커밋의 메시지로 바뀌는지	git commit --amend 는 HEAD 메시지를 편집기에 띄운다
2	스테이징해 둔 파일이 같이 들어간다	파일 하나 고쳐 [스테이징] → 메시지만 고칠 생각으로 [마지막 메시지] → [커밋 수정] → 그 파일이 HEAD 에 들어갔는지 · 알림에 그런 말이 있는지	같이 들어간다(--only 없이). 다만 편집기 화면에 바뀔 파일 목록이 보인다
3	원래 작성자 · 작성 시각이 바뀐다	8차 C-2 처럼 작성자 박지훈 인 커밋을 cherry-pick 해 HEAD 로 만든 뒤 [커밋 수정] → %an · %ad	작성자 · 작성 시각은 그대로, 커밋한 사람 · 시각만 바뀐다(--reset-author 를 줄 때만 바뀜)
4	작업 중에도 켜진다	병합 충돌 중 · rebase 중 · cherry-pick / revert 중에 메시지 칸에 글을 넣고 [커밋 수정] 이 켜지는지 · 누르면 무엇이 되는지(부모 수 · MERGE_HEAD · rebase-merge 가 남는지)	병합 중에는 막는다("You are in the middle of a merge -- cannot amend") · rebase 중에는 멈춘 커밋을 고치는 뜻이 된다 · cherry-pick / revert 중은 재어 적는다
5	병합 커밋을 고치면	병합 커밋이 HEAD 일 때 [커밋 수정] → 부모 둘이 남는지 · 8차 F-1 본문(충돌 해결 내역)이 사라지는지	부모는 그대로
6	이미 올린 커밋	pull 길(10차 E-1)의 원격을 흉내 낸 bare 저장소로 push 한 뒤 [커밋 수정] → 막거나 알리는지 · 그 뒤 Push 가 어떻게 되는지	막지 않는다. 다음 push 가 거부된다
7	되돌리는 길	수정 뒤 알림 · 로그에 고치기 전 해시가 남는지	reflog 에 남는다
8	메시지 칸 · 첫 줄	여러 줄 메시지 · 빈 줄 · # 로 시작하는 줄이 그대로 들어가는지(6차 B-3 은 병합 메시지의 # 줄을 뺐다)	편집기를 거치면 # 줄이 빠진다

• 원인이 확인된 것만 고친다. 고칠 방향(사용자에게 보이고 정할 것은 정함 으로 표시):
  • 1 — [마지막 메시지] 는 HEAD 커밋의 메시지를 읽는다(목록 순서와 무관).
  • 2 — 정함: [커밋 수정] 을 누를 때 스테이징된 파일이 있으면 "파일 N개도 이 커밋에 들어갑니다" 를 묻는다 / 메시지만 고치는 길을 따로 둔다 / 그대로 두고 매뉴얼에 적는다.
  • 3 — 작성자 · 작성 시각은 원래 커밋 것을 쓴다(git 과 같게). 커밋한 사람만 지금 사람.
  • 4 — merge · rebase · cherry-pick · revert 진행 중에는 [커밋 수정] 을 끈다(단추 설명에 까닭).
  • 5 — 병합 커밋 본문이 사라진다면 [마지막 메시지] 가 본문까지 가져오는지 보고 적는다.
  • 6 — 정함: 원격 추적 브랜치에 이미 있는 커밋이면 묻는다 / 막는다 / 매뉴얼에만 적는다.
  • 7 — 알림 · 로그에 "커밋 수정 완료 (옛 abc1234 → 새 def5678)".
• 판정 기준: 여덟 가지 모두 고치기 전 · 뒤 결과를 값으로 적는다. 고친 것은 하네스에 먼저 넣는다 — HEAD 메시지 읽기([모든 브랜치] 목록에서도) · 작성자 · 작성 시각 보존 · 작업 중 꺼짐 · 병합 커밋 부모 둘 유지. 파일 비교 탭에 저장 안 한 편집이 있을 때 먼저 묻는 것(5차 A-2)이 그대로다.

C-2. 마지막 커밋이 아닌 커밋의 메시지 수정 — 할지 먼저 정한다

• C-1 을 끝낸 뒤 정한다. 기획안은 "커밋 우클릭 → 이름 변경" 이고, 이력 탭에서 고른 커밋의 메시지를 바꾸는 일이다.
• HEAD 가 아니면 그 뒤 커밋을 모두 다시 쓴다(해시가 모두 바뀜 · git rebase -i 의 reword). 사용자에게 보일 것:
  • 되는 범위: 현재 브랜치의 조상 커밋 · 원격에 없는 커밋 · 그 사이에 병합 커밋이 없을 때
  • 막을 것: 원격에 올라간 커밋 · 사이에 병합 커밋 · 작업 중(merge · rebase · cherry-pick · revert) · 워킹트리에 커밋 안 한 변경 · 파일 비교 탭에 저장 안 한 편집 · 다른 브랜치에만 있는 커밋([모든 브랜치])
  • 지켜야 할 것: 다시 쓴 커밋들의 트리 · 작성자 · 작성 시각 그대로, 메시지는 고른 커밋만
  • 되돌리는 길: 바꾸기 전 HEAD 해시를 알림 · 로그에 남긴다
  • 화면: 이력 줄 우클릭 메뉴 또는 이력 탭 단추 — 10차 B-1 대로 두 탭이 같은 커밋을 보는지
• 판정 기준: 안 하기로 하면 기획안 · 웹 문서에 "마지막 커밋만" 을 까닭과 함께 적고 닫는다. 하면 하네스로 "세 커밋 앞 커밋 메시지 바꾸기 → 그 뒤 커밋 수 같음 · 커밋마다 트리 해시 · 작성자 · 작성 시각 같음 · 고른 커밋 메시지만 바뀜" 을 보이고, 막을 경우 여섯 가지가 실제로 막힌다. 바꾼 뒤 두 탭의 고른 커밋이 새 해시를 따라간다(9차 A-1 · A-2 규칙).

---

D. 시험 도구 정리 (제품 아님)

D-1. 10차 E-1 에서 남긴 둘

• 줄끝 검사 스크립트(d1-verify.ps1)가 부모 하나인 커밋(rebase · cherry-pick · revert)에서 둘째 부모가 없어 git merge-base 오류를 찍는다 — 부모 하나면 첫 부모와만 견준다고 적고 오류 없이.
• 파일 비교 탭 요약을 읽는 함수(FileState)가 "차이 없음" 을 못 읽어 커밋 뒤 요약이 빈칸으로 적힌다.
• 판정 기준: 10차 E-1 의 rebase 한 길을 다시 돌려 오류 줄 0 · 커밋 뒤 요약 "차이 없음" 이 적힌다. 제품 코드는 바꾸지 않는다.

---

E. 확인 · 문서

E-1. 바꾼 길을 다시 끝까지

• A 를 고쳤으면 A-1 의 9가지를 다시 돌려 표를 채운다. C-1 을 고쳤으면 C-1 의 여덟 가지를 다시, C-2 를 했으면 메시지를 바꿔 이력을 다시 쓴 저장소로 병합 한 길을 끝까지.
• 제품의 병합 · 저장 코드를 건드렸다면 10차 E-1 처럼 다섯 길(+ pull) 을 다시 한다. 안 건드렸다면 병합 한 길만(회귀).
• 판정 기준: 줄끝 · BOM 바뀐 파일 0 · 충돌 표식 0 · class 이름 다른 Unit 파일 0 · 누른 수 = 줄 고른 로그. 10차 B-1(두 탭 같은 커밋)이 다시 나지 않는다.

E-2. 웹 문서 · 기획안을 11차에 맞게

• MergeHub 문서(doc/web/index.html, 아티팩트 "MergeHub 문서"): 매뉴얼 변경분 추출 · 실행 위치(B-1) · 설정 위치(B-2) · 알아 둘 한계 · 남은 일 · 지금까지 만든 것. 발행본을 먼저 읽고 합쳐 올린다.
• 기획안 v1.2(잠금 아티팩트 "UbiSam MergeTool 개발 기획안"): 3.2 기능 목록의 변경분 추출 · 커밋 메시지 수정 상태, 4단계 진행. 원문은 로컬에서 고치고 A4 쪽마다 원본과 같은 높이인지 그림으로 견준다. 잠금은 사용자가 비밀번호로 한다 — 잠그지 않은 파일은 올리지 않는다(공유 링크가 열린 사내 문서).
• 판정 기준: 문서의 단추 이름 · 흐름이 지금 화면과 같다(grep 대조). 태그 짝 맞음. 기획안 새 잠금 파일을 풀면 고친 원문과 바이트가 같다.

---

이번 지시서에서 하지 않는 것

• 실제 소스로 해 보기 — 실제 소스는 열지 않는다(2026-09-11 결정).
• 느린 디스크(HDD)에서 폴더 비교 재기 — 이 PC 에는 NVMe 뿐이다. 사내 베타 때 그 PC 에서 잰다(10차 D-1).
• 사내 베타 배포 자체 · 푸시 — 사내 Gitea 저장소와 대상 PC 가 정해지면 따로 지시한다. B 는 배포 전 확인까지.
• D 드라이브를 없애거나 디스크 · 백신 · 레지스트리(HKLM) 설정을 바꿔 보는 시험 — 보안 · 시스템 설정이라 하지 않는다.
• 빈 cherry-pick 을 커밋으로 남기는 길 — 두지 않기로 했다(2026-09-16 사용자 결정).
• 비교할 때만 C# 스타일을 맞추는 선택지 — 만들지 않기로 했다(2026-09-17 사용자 결정).
• MergeHub 밖에서 푼 충돌을 병합 본문에 적기 — 알 길이 없다(8차 F-1).
• 셸 창 반쪽 스냅 · 1px 테두리 — 8차 C-3 결정 그대로.
• 로그인·권한 · Gitea PR 코멘트 · 멀티 레포 · Roslyn · 같은 줄 접기(4차 B-2) · 외부 편집기(4차 B-4) · 창 여러 개 — 미룬 그대로 둔다.

---

보고 형식

항목마다 이렇게 적는다.

• 고치기 전에 문제가 다시 나는 것을 어떻게 보였는지 (만든 저장소 · 묶음의 어느 파일로, 몇 번 되풀이해서)
• 무엇이 원인이었는지 한두 줄 (코드 · 로그 근거)
• 사용자에게 정해 달라고 한 것과 정한 것
• 어떤 파일을 어떻게 고쳤는지
• 실제로 실행해 확인한 결과 (파일 수 · 해시 · 크기 · 알림 문구 · ms 처럼 눈이 아닌 값으로)
• 커밋 해시