muni

요약. muni: 자율 개선 회차 14회, 릴리즈 11건. 최근 릴리즈 v0.38.0 (자산 1개). 건강 C 14일: 릴리즈 11, 실패 0, 경고 1, 회귀 1

• 14회차
• 1프로젝트
• 11배포 준비 완료
• 0릴리즈 진행 중
• 0병합 완료
• 2검토 대기
• 0검증 실패
• 1변경 없음
• 0실행 오류
• $65.19비용
• 2시간 23분에이전트 시간

현황

저장소

https://github.com/hkjang/muni

마지막 회차

2026-09-12 20:59 KST — 🚀 릴리즈 merged PR #13, released v0.38.0

최근 릴리즈

v0.38.0 — released · 자산 1개 (이전 v0.37.0: 1개) 전체 릴리즈 →

회차 이력

비용·사용량

아이디어 백로그 — 대기 11 / 전체 12

교훈 (깨졌던 변경)

• 2026-09-07 rejected-by-human — 사람이 PR 을 반려함. 같은 접근은 피할 것. (링크)

원장 (에이전트가 남긴 기록)

2026-09-02

• 선택: 옛 한글 문서(.hwp)의 글자색·글꼴·크기 읽기 (가치 4 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: .hwp 리더가 CHAR_SHAPE 에서 굵게·기울임·밑줄·취소선 네 스위치만 읽고 기준 크기·글자 색·글꼴 번호를 버려서, 같은 문서를 .hwpx 로 저장한 것과 달리 강조한 낱말이 전부 검은 본문으로 들어왔습니다. COLORREF(0x00BBGGRR, 파랑이 먼저)와 FACE_NAME 목록(한글 글꼴이 앞에 놓이므로 번호를 앞에서부터 셈)을 읽고, 1/100 pt 크기 환산은 hangul.FontSize 로 두 리더가 공유하게 했습니다. 검정·10pt 는 한글이 손대지 않은 글에도 적어 두므로 표시하지 않습니다. 검증은 형식 문서대로 바이트를 깐 새 픽스처 세 개(색·크기·글꼴, 기본값 미표시, 표가 없는 글꼴 번호)와 go vet ./..., go test ./... 전체 통과. 커밋 15c09b4.
• 보류 아이디어:
  • .hwp/.hwpx 위첨자·아래첨자 읽기·쓰기 (가치 3 / 위험 2 / S) — CHAR_SHAPE 속성 비트 15·16, HWPX <hh:supscript/>
  • .hwpx 글자 음영(형광펜) 양방향 (가치 3 / 위험 2 / S) — charPr 의 shadeColor, .hwp 는 음영 색 오프셋 60
  • .hwpx 표 열 너비 읽기 (가치 3 / 위험 2 / M) — DOCX 는 이미 유지하는데 HWPX 는 버림
  • CI 에 go vet 과 gofmt -l 추가 (가치 2 / 위험 1 / S) — 이번에도 gofmt 를 손으로 돌려야 했음
• 릴리즈: v0.22.0 (2026-09-02)

2026-09-02

• 선택: 한글 문서(.hwp/.hwpx)의 위첨자·아래첨자 읽기와 .hwpx 쓰기 (가치 4 / 위험 2 / S)
• 결과: 성공
• 요약: 각주 번호·화학식·제곱미터가 붙는 자리인 첨자를 두 한글 리더가 모두 버려서, 같은 문서를 DOCX 로 내보내면 살아 있는 서식이 한글 쪽에서만 본문 글자로 들어왔습니다. .hwp 는 CHAR_SHAPE 속성 낱말의 15·16번 비트, .hwpx 는 charPr 의 <hh:supscript/>·<hh:subscript/>(“er” 없는 철자)에서 읽고, 올림과 내림이 동시에 켜졌을 때의 선택은 hangul.Script 한 곳에 두었습니다. 쓰는 쪽은 형식이 선언한 차례대로 strikeout 뒤에 놓습니다. 검증은 형식 문서대로 바이트를 깐 .hwp 픽스처 둘(첨자, 이웃한 양각 비트를 첨자로 오해하지 않는지), 한글이 쓰는 모양의 .hwpx 픽스처 하나, every-node.json 왕복 두 줄 — 셋 다 변경 전에 실패하는 것을 확인했고 gofmt -l·go vet ./...·go test ./... 전체 통과. 커밋 bed6ac2.
• 보류 아이디어:
  • .hwpx 글자 음영(형광펜) 양방향 (가치 3 / 위험 2 / S) — charPr 의 shadeColor, .hwp 는 음영 색 오프셋 60
  • .hwpx 표 열 너비 읽기 (가치 3 / 위험 2 / M) — DOCX 는 이미 유지하는데 HWPX 는 버림
  • CI 에 go vet 과 gofmt -l 추가 (가치 2 / 위험 1 / S) — 여전히 손으로 돌려야 함
  • .hwp 표 칸 음영·세로 정렬 읽기 (가치 3 / 위험 3 / M) — HWPX·DOCX 는 유지하는데 .hwp 만 버림
• 릴리즈: 없음(태그 푸시는 외부 절차)
• 릴리즈: v0.23.0 (2026-09-02)

2026-09-03

• 선택: 한글 표(.hwp/.hwpx)의 열 너비 읽기와 .hwpx 쓰기 (가치 4 / 위험 2 / M)
• 결과: 성공
• 요약: .docx 리더는 예전부터 colwidth 를 지켰는데 한글 리더 둘은 버려서, 좁은 항목 칸과 넓은 설명 칸이 있는 표가 한글 파일로 들어오면 전부 같은 폭이 되었습니다. .hwp 는 셀 LIST_HEADER 의 주소(열·행·병합) 다음에 오는 HWPUNIT 크기에서, .hwpx 는 <hp:cellSz width> 에서 읽고, 두 형식 모두 병합된 칸은 덮는 열들의 합만 말하므로 열 너비는 한 열만 덮는 칸에서 배웁니다. 픽셀 환산(인치당 96, hangul.PixelWidth)과 칸이 지키는 열 목록(hangul.ColumnWidths)은 hangul 패키지에 두어 두 리더가 공유하고, .hwpx 쓰기는 6인치 본문 폭을 균등 분할하는 대신 비율대로 나누도록 바꿨습니다(그 김에 열 개수를 세로 병합으로 내려온 칸까지 세도록 고침). 검증은 새 테스트 넷 — .hwp 픽스처 둘(너비 있는 표, 너비 없는 표는 아무것도 기록하지 않음), 한글이 쓰는 모양의 .hwpx 픽스처 하나, 쓰기 쪽 비율 검사 하나 — 과 gofmt -l·go vet ./...·go test ./... 전체 통과. 커밋 f971045.
• 보류 아이디어:
  • .hwpx 글자 음영(형광펜) 양방향 (가치 3 / 위험 2 / S) — charPr 의 shadeColor, .hwp 는 음영 색 오프셋 60
  • .hwp 표 칸 음영·세로 정렬 읽기 (가치 3 / 위험 3 / M) — HWPX·DOCX 는 유지하는데 .hwp 만 버림 (셀 LIST_HEADER 의 borderFill ID → DocInfo 의 BORDER_FILL)
  • CI 에 go vet 과 gofmt -l 추가 (가치 2 / 위험 1 / S) — 이번에도 gofmt 를 손으로 돌려야 했음
  • .hwp/.hwpx 표 행 높이 읽기 (가치 2 / 위험 2 / S) — 너비와 같은 자리에 있는데 muni 편집기가 행 높이를 들지 않음
• 릴리즈: 없음(태그 푸시는 외부 절차)
• 릴리즈: v0.24.0 (2026-09-03)

2026-09-03

• 선택: 옛 한글 문서(.hwp)의 표 칸 음영·세로 정렬 읽기 (가치 4 / 위험 3 / 작업량 M)
• 결과: 성공
• 요약: .hwpx·.docx 리더는 예전부터 칸 음영과 세로 정렬을 지켰는데 .hwp 리더만 버려서, 머리글 행을 옅은 색으로 칠한 한국어 보고서 표가 전부 흰 바탕에 위 정렬로 들어왔습니다. 색은 칸에 없고 셀이 DocInfo 의 BORDER_FILL 을 1부터 세는 번호로 가리키기만 하므로, 테두리 넷과 대각선 하나(각 종류·굵기·COLORREF) 뒤의 채우기 정보를 읽어 단색일 때만 배경색을 쓰고 그림·그러데이션은 넘깁니다. 세로 정렬은 칸 주소가 아니라 문단 리스트 속성 낱말의 5·6번 비트에 있습니다. 흰색이 음영이 아니라는 판단은 hangul.CellShade 한 곳에 두어 .hwpx 리더도 같이 쓰게 했고(그 김에 .hwpx 만 검은 음영을 버리던 것이 .docx 와 같아짐), 셀 픽스처를 형식이 적은 전체 길이(주소·크기·높이·여백·테두리 번호)로 늘렸습니다. 검증은 새 테스트 넷과 gofmt -l·go vet ./...·go test ./... 전체 통과. 커밋 ed23b5b.
• 보류 아이디어:
  • .hwpx 글자 음영(형광펜) 양방향 (가치 3 / 위험 2 / S) — charPr 의 shadeColor, .hwp 는 음영 색 오프셋 60
  • .hwpx 쓰기에 칸 음영 추가 (가치 3 / 위험 3 / M) — 이제 읽기는 세 형식 모두 되는데 .hwpx 로 내보내면 사라짐. 색마다 borderFill 을 헤더에 만들어야 함
  • CI 에 go vet 과 gofmt -l 추가 (가치 2 / 위험 1 / S) — 이번에도 gofmt 를 손으로 돌려야 했음
  • .hwp 표 캡션의 위치(위/아래) 읽기 (가치 2 / 위험 2 / S) — 지금은 언제나 표 뒤에 붙임
• 릴리즈: v0.25.0 (2026-09-03)

2026-09-03

• 선택: 한글 문서(.hwp/.hwpx)의 글자 음영(형광펜) 읽기와 .hwpx 쓰기 (가치 4 / 위험 2 / 작업량 S)
• 결과: 성공
• 요약: 형광펜은 muni 가 .docx·HTML·마크다운에서 예전부터 주고받던 표시인데 한글 두 형식만 버려서, 검토자가 칠해 둔 문장이 한글 파일에서만 맨 글자로 들어왔습니다. .hwpx 는 charPr 의 shadeColor 속성(굵게·기울임과 달리 요소가 아니라 속성이고, 한글은 표시하지 않은 런에도 shadeColor="none" 을 적습니다), .hwp 는 CHAR_SHAPE 의 세 번째 색(글자색·밑줄색 다음, 오프셋 60)에서 읽습니다. 음영이 아닌 값의 판단은 hangul.TextShade 한 곳에 두어 두 리더가 함께 쓰고(흰색은 표시하지 않은 글자가 이미 놓인 바탕이자 두 형식의 “없음”, 검정은 .hwp 가 아무도 손대지 않은 자리에 남기는 값이라 글자를 가림), .hwpx 쓰기는 표시한 charPr 에만 색을 적고 나머지는 none 으로 둡니다. 검증은 변경 전에 실패하는 것을 확인한 새 테스트 넷과 every-node 왕복의 형광펜 줄, gofmt -l·go vet ./...·go test ./... 전체 통과. 커밋 f6bbe86.
• 보류 아이디어:
  • .hwpx 쓰기에 칸 음영 추가 (가치 3 / 위험 3 / M) — 읽기는 세 형식 모두 되는데 .hwpx 로 내보내면 사라짐. 색마다 borderFill 을 헤더에 만들어야 함
  • CI 에 go vet 과 gofmt -l 추가 (가치 2 / 위험 1 / S) — 이번에도 손으로 돌려야 했음
  • .hwp 표 캡션의 위치(위/아래) 읽기 (가치 2 / 위험 2 / S) — 지금은 언제나 표 뒤에 붙임
  • .hwp/.hwpx 표 행 높이 읽기 (가치 2 / 위험 2 / S) — 너비와 같은 자리에 있는데 muni 편집기가 행 높이를 들지 않음
• 릴리즈: 없음(태그 푸시는 외부 절차)
• 릴리즈: v0.26.0 (2026-09-03)

2026-09-05

• 선택: .hwpx 칸 음영 — 실제 있는 자리에서 읽고, 쓰기에도 추가 (가치 4 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: 보류 목록의 “.hwpx 쓰기에 칸 음영 추가”를 하려다, 읽기 쪽이 애초에 동작하지 않았음을 찾았습니다 — 칸 음영은 칸에 없고 칸은 borderFill 을 번호로 가리키기만 하는데(런이 charPr 번호를 거치는 것과 같은 간접), 리더가 <hp:tc> 안에서 fillBrush 를 찾고 있었습니다. 공개 실제 파일 넷에서 칸 325개 중 칸 안에 fillBrush 를 둔 것은 0개라, 한글이 쓴 음영 표는 예외 없이 흰 표로 들어왔습니다(README 는 양방향이라고 적고 있었고, 테스트는 하나도 없었습니다). 머리를 읽을 때 borderFill 의 채우기도 imp.cellFills 에 담아 칸이 부르는 번호로 찾고, 쓰는 쪽은 색마다 borderFill 을 3번 뒤에 하나씩 만들어 같은 색 칸끼리 공유합니다. 무엇이 음영인지는 hangul.CellShade 한 곳의 판단이라 읽기와 쓰기가 어긋나지 않습니다. 검증은 변경 전에 실패하는 것을 확인한 새 테스트 둘(음영·흰색·채우기 없음·그러데이션 네 칸의 읽기 픽스처, borderFill 재사용과 왕복의 쓰기)과 gofmt -l·go vet ./...·go test ./... 전체 통과, 그리고 실제 .hwpx 넷으로 borderFill 의 요소 차례와 브러시 모양(hatchColor="#999999")을 맞췄습니다. 커밋 2d175c8.
• 보류 아이디어:
  • CI 에 go vet 과 gofmt -l 추가 (가치 2 / 위험 1 / S) — 이번에도 손으로 돌려야 했음
  • .hwpx 머리글 칸의 기본 음영 (가치 2 / 위험 3 / S) — .docx 쓰기는 F3F4FA 를 깔아 머리글 행이 보이게 하는데 .hwpx 는 굵게뿐. 리더가 머리글 행의 음영을 버리므로 왕복이 어긋날 자리가 있어 미뤘음
  • .hwp 표 캡션의 위치(위/아래) 읽기 (가치 2 / 위험 2 / S) — 지금은 언제나 표 뒤에 붙임
  • .hwp/.hwpx 표 행 높이 읽기 (가치 2 / 위험 2 / S) — 너비와 같은 자리에 있는데 muni 편집기가 행 높이를 들지 않음
• 릴리즈: 없음(태그 푸시는 외부 절차)
• 릴리즈: v0.27.0 (2026-09-05)

  2026-09-06

• 선택: 한글 문서(.hwp/.hwpx)의 쪽 나누기 읽기 (가치 4 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: 쪽 나누기는 muni 가 .docx·HTML·PDF 에서 예전부터 지키던 블록이고 .hwpx 쓰기도 이미 pageBreak 를 적고 있었는데 두 한글 리더가 모두 버려서, 별지 서식처럼 항목마다 새 쪽에서 시작하는 문서가 한 덩어리로 들어왔고 내보내면 쪽 구성이 사라졌습니다. 나뉜 자리에는 표시가 없고 다음 문단이 그것을 지니므로(.hwp 는 PARA_HEADER 의 문단 나누기 종류 셋째 비트, .hwpx 는 <hp:p pageBreak="1">) 그 문단 앞에 블록으로 놓고, 맨 앞의 나누기는 빈 쪽으로 문서를 열게 되어 버리며, 나누기만 들고 글자가 없는 문단은 나누기 하나로 읽습니다(muni 가 쓰는 모양이라 그렇지 않으면 왕복마다 빈 줄이 쌓입니다). 실제 파일 스물둘로 맞췄습니다 — .hwpx 여섯 개의 pageBreak="1" 열둘, .hwp 열여섯 개의 나누기 넷이 읽은 수와 정확히 같고, 모든 파일의 첫 문단이 지니는 0x03(구역·다단 나누기)은 쪽 나누기로 세지 않습니다. 그 김에 .hwp 픽스처가 글자 모양 개수를 형식이 정한 12번이 아니라 10번(스타일) 바이트에 적던 것을 고쳤습니다. 검증은 변경 전에 실패하는 것을 확인한 새 테스트 넷과 왕복 하나, 실제 .hwp 열여섯 개의 .hwpx 왕복, gofmt -l·go vet ./...·go test ./... 전체 통과. 커밋 a488f72.

• 보류 아이디어: CI 에 go vet 과 gofmt -l 추가 (가치 2 / 위험 1 / S) — 이번에도 손으로 돌려야 했음 / .hwpx 인용문·코드블록 왕복 (가치 3 / 위험 2 / M) — 쓰기는 들여쓴 문단과 고정폭으로 내보내고 ctx.quote 는 아무도 읽지 않는 죽은 값이며, 읽기는 되살릴 단서가 없음 / .hwp 표 캡션의 위치(위/아래) 읽기 (가치 2 / 위험 2 / S) — 지금은 언제나 표 뒤에 붙임 / .hwp/.hwpx 표 행 높이 읽기 (가치 2 / 위험 2 / S) — 너비와 같은 자리에 있는데 muni 편집기가 행 높이를 들지 않음

• 릴리즈: v0.28.0 (2026-09-06, run 2026-09-06-165045-muni-improve)

  2026-09-06

• 선택: 한글 문서(.hwp/.hwpx)의 그림을 그려진 크기대로 읽기 (가치 4 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: 그림의 바이트는 원본 크기 그대로이고 문서는 그것을 줄여서 그리는데, 두 한글 리더가 그린 크기를 버려서 실제 정부 문서의 머리글 그림(1632픽셀을 163픽셀로 그린 것)이 쪽을 가득 채운 채 들어왔습니다 — .docx 리더는 예전부터 <wp:extent> 를 지켰고 .hwpx 쓰기도 width 를 읽고 있었는데 한글 쪽 입구만 비어 있었습니다. 크기는 그림 자신에게 없어서 .hwp 는 그림 위 SHAPE_COMPONENT 의 두 크기 중 둘째(그려진 것)를 읽고 — 그 낱말이 어디서 시작하는지는 컴포넌트가 컨트롤 바로 아래인지(컨트롤 아이디를 두 번 적습니다) 묶음 안인지(한 번)에 따라 다릅니다 — .hwpx 는 <hp:sz>(<hp:orgSz> 는 원본)를 읽으며, 무엇을 크기로 볼지는 hangul.PictureSize 한 곳에 두어 두 리더가 함께 씁니다. .hwpx 쓰기는 이제 높이도 적힌 대로 써서 눌러 놓은 그림의 모양이 왕복에서 풀리지 않습니다. 그 김에 실제 파일 셋(basicsReport.hwp)에서 세 그림이 모두 이웃의 그림으로 들어오던 것을 찾아 고쳤습니다 — 그림이 적어 둔 번호는 스트림의 번호가 아니라 DocInfo BIN_DATA 레코드를 세는 번호였고, 그려진 크기가 자기 그림이 아니라 다른 그림의 생김새와 꼭 맞는 것(셋이 한 바퀴 도는 모양)이 증거였습니다. 검증은 변경 전에 실패하는 것을 확인한 새 테스트 넷(.hwp 크기·.hwpx 크기·쓰기 왕복·BIN_DATA 짝짓기)과 gofmt -l·go vet ./...·go test ./... 전체 통과, 실제 .hwp 열여섯·.hwpx 여섯 개의 Corpus·RealRoundTrip 통과(고친 뒤 세 그림 모두 그려진 크기와 원본 크기의 비율이 같아졌습니다). 커밋 두 개.

• 보류 아이디어: CI 에 go vet 과 gofmt -l 추가 (2/1/S) — 여섯 회차째 손으로 돌렸음 / .docx 리더가 그림 높이(<wp:extent cy>)도 읽기 (3/1/S) — 모델이 높이를 담게 되었는데 워드에서 온 그림만 가로만 지킴 / PDF 내보내기가 그림 크기를 쓰지 않음 (3/2/M) — 눌러 놓은 그림이 PDF 에서 다시 늘어남 / .hwpx 인용문·코드블록 왕복 (3/2/M) — 읽기가 되살릴 단서가 없어 스타일을 심어야 함 / .hwp 표 캡션의 위치(위/아래) 읽기 (2/2/S) — 지금은 언제나 표 뒤에 붙임

• 릴리즈: v0.29.0 (2026-09-06, run 2026-09-06-172046-muni-improve)

  2026-09-07

• 선택: 그림이 그려진 모양 그대로 편집기와 HTML·PDF 까지 가게 하기 (가치 4 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: 지난 회차에 한글 두 형식이 그린 높이를 읽게 되었지만 그 높이는 문 앞에서 계속 사라지고 있었습니다 — .docx 리더는 <wp:extent> 의 cx 만 읽었고(라이터는 예전부터 둘을 짝으로 읽습니다), PDF 리더도 상자의 너비만 담았으며, HTML 가져오기는 height 를 무시했고, 무엇보다 화면과 인쇄의 스타일시트가 쪽보다 넓은 그림을 줄이려고 모든 그림에 height:auto 를 주는 탓에 눌러 둔 그림이 다시 바이트의 모양으로 펴지고 있었습니다. 그래서 크기를 지닌 그림은 aspect-ratio 로 그리도록 서버의 HTML 과 편집기의 SizedImage 를 함께 고쳤습니다(비율은 줄어드는 동안 살아남고 고정 높이는 그러지 못합니다). 그림 메뉴의 % 단추도 높이를 같은 비율로 옮깁니다. 검증은 새 테스트 여덟(고치기 전에 실패하는 것을 확인한 .docx 왕복, 렌더·가져오기 넷, 프런트 넷)과 gofmt -l·go vet ./...·go test ./...·npm test(258)·npm run build·npm run lint 전체 통과, scripts/check-webui-placeholder.sh 로 빌드 산출물이 커밋에 섞이지 않았음을 확인. 커밋 7c5e172.
• 보류 아이디어: CI 에 go vet 과 gofmt -l 추가 (2/1/S) — 일곱 회차째 손으로 돌렸음 / .hwpx 인용문·코드블록 왕복 (3/2/M) — 읽기가 되살릴 단서가 없어 스타일을 심어야 함 / .hwpx 머리글 칸의 기본 음영 (2/3/S) — .docx 는 F3F4FA 를 까는데 .hwpx 는 굵게뿐 / .hwp 표 캡션의 위치(위/아래) 읽기 (2/2/S) — 지금은 언제나 표 뒤에 붙임 / 그림의 그린 크기를 markdown·.hwpx 왕복에서도 지키기 (2/2/S) — markdown 은 크기를 담을 자리가 없어 잃는 것이 정상이지만, 붙임말로 남길 수 있는지 볼 만함

2026-09-10

• 선택: .hwpx 인용문·코드 블록 왕복 (가치 3 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: 한글에는 인용문도 코드 블록도 없어서 쓰기는 인용을 들여쓴 문단으로, 코드를 고정폭 문단 여러 개로 흘려보내고 blockContext.quote 는 아무도 읽지 않는 죽은 값이었고, 읽는 쪽에는 되살릴 단서가 없었습니다 — 들여쓰고 고정폭으로 그린 문단은 리더에게 그저 문단입니다. .docx 쓰기가 하는 것과 같이 머리(Contents/header.xml)에 스타일 둘을 심고(인용/Quote, 코드/Code) 문단이 번호로 가리키게 했으며, 이름을 무엇으로 읽을지는 hangul.BlockStyle 한 곳에 두어 워드에서 옮겨온 이름(Source Code 따위)도 받습니다. 인용문은 목록처럼 시작도 끝도 표시가 없는 문단의 줄이라 한 블록으로 모으고, 코드 블록은 한 문단 안에 줄바꿈으로 넣습니다 — 줄마다 문단이면 끝을 알릴 것이 없어 나란한 코드 블록 둘이 하나로 돌아옵니다. 목록 항목·제목은 스타일을 받지 않고(항목의 줄이 통째로 인용이 됩니다), 인용이 여백에서 한 칸 물러난 것은 그리는 방법이지 글쓴이의 들여쓰기가 아니므로 읽을 때 덜어냅니다(그러지 않으면 왕복마다 한 칸씩 밀립니다). 검증은 변경 전에 실패하는 것을 확인한 새 테스트 셋(손으로 지은 파일의 인용 묶기·코드 줄바꿈, 왕복)과 gofmt -l·go vet ./...·go test ./... 전체 통과. 덤으로 여덟 회차 내리 손으로 돌린 gofmt·go vet 을 CI 단계로 넣었습니다(YAML 을 파싱해 단계 차례를 확인). 커밋 59cb89f, 7f6ac57.
• 보류 아이디어: .hwpx 머리글 칸의 기본 음영 (2/3/S) — .docx 는 F3F4FA 를 까는데 .hwpx 는 굵게뿐 / .hwpx 코드 블록의 언어가 왕복에서 사라짐 (2/2/S) — mermaid 코드 블록이 도형으로 다시 그려지지 않음. 스타일 이름에 언어를 담을 수 있는지 / 그림의 그린 크기를 markdown 왕복에서도 지키기 (2/2/S) — 붙임말이나 HTML 태그로 남길 수 있는지 / .hwp 표 캡션의 위치(위/아래) 읽기 (2/2/S) — 지금은 언제나 표 뒤에 붙임 / .hwp/.hwpx 표 행 높이 읽기 (2/2/S) — 편집기가 행 높이를 들지 않아 값어치가 낮음

2026-09-10

• 선택: 한글 문서(.hwp/.hwpx)의 구분선 읽기와 .hwpx 쓰기 (가치 3 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: 구분선은 muni 가 .docx·HTML·마크다운에서 예전부터 주고받던 블록인데 한글 두 리더가 모두 읽지 않았고, .hwpx 쓰기는 ─ 서른 개를 글자로 적고 있어서 — 글자는 글자로 돌아오므로 — 두 번 오간 문서에는 선이 있던 자리에 그 문단이 남았습니다. 한글에는 구분선이 없으므로 한글이 하이픈 한 줄을 그리는 방법(아무것도 담지 않은 문단 아래에 선 하나)을 그대로 씁니다. 선은 문단에 없고 문단은 머리의 borderFill 을 번호로 가리키기만 하며(칸 음영과 같은 간접 — .hwp 는 PARA_SHAPE 의 32번째 바이트, .hwpx 는 paraPr 의 <hh:border>), 네 면에 두른 선은 글을 감싼 상자이지 구분선이 아니라 위나 아래에만 그은 것을 읽습니다. 무엇이 구분선인지는 hangul.RuleBorder 한 곳의 판단이라 두 리더와 쓰는 쪽이 어긋나지 않고, 선이 그어진 문단이 글자를 지녔거나 표를 매달고 있으면 그 선은 그것을 그리는 방법이므로 세지 않습니다. 검증은 변경 전에 실패하는 것을 확인한 새 테스트 셋(.hwp·.hwpx 읽기, 쓰기 왕복)과 상자를 구분선으로 읽지 않는 것을 지키는 둘, gofmt -l·go vet ./...·go test ./... 전체 통과. 커밋 17c16d9.

• 보류 아이디어: .hwp 리더도 스타일 이름으로 인용문·코드 블록을 읽기 (2/2/S) — hangul.BlockStyle 이 생겼으니 DocInfo STYLE 이름으로 같은 판단을 할 수 있지만 한글이 쓴 실제 파일에 그런 스타일이 거의 없음 / .hwpx 머리글 칸의 기본 음영 (2/3/S) — .docx 는 F3F4FA 를 까는데 .hwpx 는 굵게뿐 / .hwpx 코드 블록의 언어가 왕복에서 사라짐 (2/2/S) — mermaid 가 도형으로 다시 그려지지 않음 / 그림의 그린 크기를 markdown 왕복에서도 지키기 (2/2/S) — 붙임말이나 HTML 태그로 남길 수 있는지 / .hwp 표 캡션의 위치(위/아래) 읽기 (2/2/S) — 지금은 언제나 표 뒤에 붙임

• 릴리즈: v0.36.0 (2026-09-10, run 2026-09-10-143110-muni-improve)

  2026-09-11

• 선택: 사용자 가이드와 관리자 가이드를 실제 화면 캡처와 함께 완성 (가치 5 / 위험 1 / 작업량 M)
• 결과: 성공
• 요약: muni 에는 README 와 운영 안내만 있고 화면을 쓰는 사람이 볼 문서도, 캡처도 한 장이 없었습니다. GUIDE-STANDARD 대로 docs/USER_GUIDE.md·docs/ADMIN_GUIDE.md 와 두 PDF 를 쓰고, 그림 스무 장을 실제로 띄운 v0.36.0 에서 찍었습니다 — postgres 컨테이너를 새로 띄우고 프런트를 빌드해 바이너리로 기동한 뒤, 새로 만든 frontend/scripts/guide-screenshots.mjs(npm run screenshots)가 데모 데이터를 채우고 1440x900 headless Chromium 으로 로그인·홈·워크스페이스·편집기·댓글·버전·내보내기·공유·검색·빠른 이동·개인 설정과 관리 화면 여덟 개를 찍습니다. 스크립트는 데모 데이터를 만들기 때문에 대상 주소를 e2e 와 공유하지 않는 전용 변수(MUNI_GUIDE_BASE_URL)로만 받고 로컬이 아니면 멈추며, 자격 증명은 환경 변수로만 받고 데모 계정 비밀번호는 실행할 때마다 새로 만들어 어디에도 적히지 않습니다. 문서의 사실은 코드에서 읽었습니다 — 환경 변수 표는 internal/config 와 export.go, API 의 메서드와 경로는 라우트가 등록된 자리, 오류 메시지는 writeError 가 실제로 내는 문구입니다. 겹치는 자리는 옮겨 적지 않고 링크해서 정본을 하나로 두었습니다(백업·복구·키 교체·퇴사자 정리는 운영 안내가 정본, 관리자 가이드가 그것을 가리키고 운영 안내는 관리자 가이드를 되가리킵니다). README 에도 두 문서로 가는 길을 냈습니다. 검증은 gofmt -l·go vet ./...·go test ./...·npm run lint·npm test(265) 전체 통과와 scripts/check-webui-placeholder.sh(프런트 빌드 산출물이 커밋에 섞이지 않았음), PDF 는 공용 md2pdf.mjs 로 만들어 쪽 수와 삽입된 그림 수(사용자 16쪽·12장, 관리자 13쪽·8장)를 확인했습니다. 캡처하며 편집기를 하드 로드하면 화면이 깨지는 결함을 찾았습니다(아래 보류 첫 줄). 커밋 270acca.

• 보류 아이디어: 편집기를 새로고침하거나 문서 링크로 바로 열면 “문제가 생겼습니다” — 빌드된 번들에서 TypeError: Cannot read properties of null (reading 'commands'), 목록에서 눌러 들어가는 SPA 이동만 정상 (5/2/M, 이번 회차 캡처 중 재현) / 관리자 설정을 켜야 나오는 화면(검토·승인, AI 패널, 발표자료, AI 호출 감사) 캡처 추가 — 설정을 켜고 되돌리는 형제 방식이 먼저 필요 (3/1/S) / .hwpx 머리글 칸의 기본 음영 (2/3/S) / .hwpx 코드 블록의 언어가 왕복에서 사라짐 (2/2/S) / .hwp 표 캡션의 위치(위/아래) 읽기 (2/2/S)

• 릴리즈: v0.37.0 (2026-09-11, run 2026-09-11-065112-muni-improve)

  2026-09-12

• 선택: 캠페인 tracking-2026-09 — 관리자가 화면에서 방문 추적 스크립트를 붙이고 CSP 가 막은 출처를 보고 허용하는 체계 (가치 5 / 위험 2 / 작업량 M)
• 결과: 성공
• 요약: muni 는 사람이 보는 화면(React SPA)을 제공하고 script-src 'self' 로 잠겨 있어 캠페인이 말한 그대로의 자리였습니다. TRACKING-STANDARD 를 따라 internal/tracking(설정·스니펫·정책 출처·차단 기록 고리 버퍼 100개)을 kanpic 의 구조에 맞춰 muni 의 언어로 만들고, 설정은 settings.All.Tracking 으로 저장소에 두어 화면(서비스 설정 → 「방문 추적」 탭)에서 바꿉니다. 페이지를 낼 때마다 nonce 를 만들어 스니펫의 모든 <script> 와 script-src 에 함께 넣고(servePage 한 자리에서 헤더와 마크업을 같이 만들어 어긋날 수 없게), 붙여 넣은 코드의 http(s) 출처를 읽어 세 지시어에 더하며, 켜진 동안에만 report-uri /api/v1/tracking/csp-report 로 신고를 받아 탭의 「정책이 차단한 출처」에 보여 주고 「허용」 한 번이 tracking.allowed_hosts 하나만 저장합니다(Store.PutValue — 저장하지 않은 폼을 함께 실어 나르지 않도록). provider 는 momento 가 첫 자리이고 기본이 같은 오리진 프록시(/momento/* → 수집기, 세션 쿠키는 떼고 X-Forwarded-For 를 붙이며, Momento 를 고르고 켠 동안에만 답함)라 바깥 출처가 정책에 등장하지 않습니다. 기본값은 꺼짐이라 새 설치의 페이지 정책은 예전 문자열 그대로이고(테스트가 바이트 단위로 지킴), /api·/mcp·/healthz·/readyz·/metrics·/momento 는 default-src 'none' 으로 오히려 좁혔으며 'unsafe-inline' 은 어디에도 넣지 않았습니다. 검증은 새 테스트 스물(tracking 11, httpapi 8, 프런트 3 — 꺼짐/켜짐/placement/nonce/출처 추출/관리 화면 제외/8KB/신고 기록·중복·상한/프록시의 쿠키 제거)과 gofmt·go vet·go test ./...(MUNI_TEST_DSN 포함)·npm run lint·npm test(268)·npm run build·check-webui-placeholder.sh 전체 통과, 그리고 실제로 띄워 확인했습니다 — postgres 컨테이너 + 빌드한 바이너리 + 가짜 Momento 수집기(node)로, headless Chromium 이 로그인 화면을 열자 /momento/collect 를 거쳐 방문(site·path, 쿠키 없음, XFF 127.0.0.1)이 들어왔고, 일부러 정책 밖 주소(http://127.0.0.1:9099, 코드에는 포트 없이 적힘)를 부르는 코드를 붙이자 브라우저 자신의 신고가 목록에 script-src-elem 으로 나타났으며 「허용」 API 뒤 새로 고치니 정책에 그 출처가 들어가고 스크립트가 실렸습니다. 관리자 가이드에 설정 표·Momento 우선·CSP 설명(nonce·출처 읽기·신고·끄면 원래대로·SPA 전환의 한계)을 더하고 새 화면(admin-tracking.png, 실제 캡처)을 실어 PDF 를 다시 구웠습니다(16쪽·그림 9장). 캡처 스크립트에도 설정을 켜고 되돌리는 shootTracking 을 넣었습니다. 커밋 bbb223a.

• 보류 아이디어: 편집기를 하드 로드하면 화면이 깨짐 — useEditor 가 첫 렌더에서 null 인 것을 지키지 않는 자리 (5/2/M) / 관리자 설정을 켜야 나오는 화면(검토·승인, AI 패널, 발표자료, AI 호출 감사) 캡처 — 이번에 만든 shootTracking 의 저장·복원 방식을 그대로 쓰면 됨 (3/1/S) / 방문 추적 설정을 페이지 요청마다 DB 에서 읽음 — index.html 요청에만 한 번이라 가볍지만 짧은 캐시(수 초)를 두면 더 좋음 (2/2/S) / .hwpx 머리글 칸의 기본 음영 (2/3/S) / .hwpx 코드 블록의 언어가 왕복에서 사라짐 (2/2/S)

• 릴리즈: v0.38.0 (2026-09-12, run 2026-09-12-202530-muni-improve)

← 대시보드 · 교훈 모음