진짜 .docx 생성 — 순수 한선씨 zip 패키징층 (과제 B1)

개요

/Users/ef/crowny-word/도구/DOCX조각.한선(OOXML WordprocessingML 조각 생성, 기존 완성분)의 "===FILE:경로===" 마커 번들 산출물을 받아 진짜 .docx(zip) 파일로 만드는 한선씨 계층을 신규 작성했다. store(무압축) zip: 로컬파일헤더 + 센트럴디렉토리 + EOCD, CRC32 포함, 전부 순수 한선씨(hanseonc_high)로 구현.

무엇을 했는지

1. CRC32 순수 한선씨 구현 실증 — 이 VM의 비트연산(비트곱/비트배타 등, opcode90-95)은

균형3진 trit-wise라 이진 CRC와 안 맞는다는 가드레일 경고가 있었으나, 실제로는 그 트릿 연산을 쓸 필요가 없었다. 절단나눗셈/절단나머지(TRUNC_DIV/MOD, 0방향 절단 내장함수, opcode738/752)로 정수를 순수 산술 비트 분해하고, XOR을 (a+b-2ab)(0/1비트 기준) 산술로 합성하는 방식으로 표준 IEEE802.3 CRC32(256엔트리 테이블)를 구현 — 표준 테스트벡터 CRC32("123456789")=3421780262, CRC32("")=0, CRC32("abc")=891568578 전부 zlib과 byte-perfect 일치 확인. 체계()+zip 폴백은 불필요 — 순수 한선씨로 완전 해결.

1. ZIP저장.한선 — store 무압축 zip writer. 버퍼바이트(opcode850, 절대오프셋+자동성장)로

로컬헤더/센트럴헤더/EOCD 필드를 u16LE/u32LE 바이트분해 기록. 문자열은 항상 문자열버퍼()+버퍼바이트읽기로 UTF-8 바이트 기준 처리(글자수=문자수 함정 회피).

1. DOCX파일.한선 — 번들 마커 파싱(===FILE:경로===) → [Content_Types].xml/_rels/word 5파트

구성 → ZIP저장 로직으로 .docx 산출하는 CLI. 환경변수 CROWNY_DOCX_BUNDLE(입력)/ CROWNY_DOCX_OUT(출력) 경로 수령. 입력 번들이 없으면 3문단 데모 문서를 자동생성.

1. 처음엔 가져오기로 재사용 시도했으나 자기완결로 전환 — libs/gzip.한선의 검증된

CRC32계산()을 가져오기로 재사용하는 버전을 먼저 만들었으나 3가지 문제 실측: - RPN 변환기(high2rpn.sh)가 gzip.한선의 deflate/huffman 부속코드까지 통째로 끌고 들어가 미인식 단어 4000+건 폭발 - 동일 이름 함수(예: 검사)가 가져오기 대상과 충돌해 이름충돌 경고 - 가져오기=텍스트삽입 방식이라 self-test top-level 전역이 뒤섞이는 사고 → crowny-word/도구/ 프로젝트의 기존 관례("가져오기 금지 규칙 때문에 파일마다 자기완결로 중복 보유", 메일머지.한선 주석 참조)대로 두 파일 모두 자기완결로 재작성.

1. 신규 VM 함정 실측(★중요, 가드레일/메모리 갱신 후보): 같은 프로그램 실행 안에서 배열

요소를 채우는 함수(예: ZIP생성)를 두 번째로 호출하면(예: 자체시험이 먼저 호출하고 실사용측이 다시 호출), 함수 안 변수 x = []로 선언한 배열 지역변수가 첫 호출 때의 스토리지를 그대로 재사용한다 — 두 번째 호출에서 추가()해도 비어있지 않고, 꺼내(x,i)가 범위를 벗어난 i에서 옛 값으로 랩어라운드(모듈로 인덱싱처럼 동작)해 조용히 틀린 값을 반환. 실측: 첫 호출 때 크기들=[5,10]이던 걸, 5개 엔트리로 두 번째 호출하자 꺼내(크기들,i)가 5,10,5,10,(새값) 순으로 새어나와 zip 센트럴디렉토리 크기 필드만 오염(로컬헤더/실데이터는 멀쩡해 unzip -l에서만 드러나는 조용한 함정 — unzip -t는 처음엔 통과하는 것처럼 보일 수 있어 더 위험). 스칼라 지역변수(pos 등)는 호출마다 정상 리셋되는 게 확인됨 — 배열만 위험. 해결: 인덱스로 배열에 캐시하지 않고 필요한 값을 전부 스칼라로 재계산(중복 계산 비용 감수). ZIP저장.한선/DOCX파일.한선 양쪽 소스 상단 주석에 상세 기록.

게이트 검증 (같은 턴 실측)

/tmp/오피스검증/테스트.docx(hanseonc_high 실행) + RPN 컴파일 버전 별도 실행 양쪽 다:

• unzip -t: 5개 엔트리 전부 OK, 오류 없음
• textutil -convert txt: exit 0, 3문단 텍스트 정확히 추출(한글 포함)
• unzip -p word/document.xml | xmllint --noout: OK (well-formed)
• 부가: [Content_Types].xml/_rels/.rels/word/_rels/document.xml.rels/word/styles.xml

전부 xmllint OK

관련 파일

• /Users/ef/crowny-word/도구/ZIP저장.한선 (신규, 자기완결, 자체시험 14/14 PASS)
• /Users/ef/crowny-word/도구/ZIP저장.rpn.한선 (RPN 변환본, hanseonc_rpn 컴파일+실행 검증)
• /Users/ef/crowny-word/도구/DOCX파일.한선 (신규, 자기완결, 자체시험 7/7 PASS)
• /Users/ef/crowny-word/도구/DOCX파일.rpn.한선 (RPN 변환본, hanseonc_rpn 컴파일+실행 검증)
• /Users/ef/crowny-word/도구/DOCX조각.한선 (기존, 수정 없음 — 조각 함수 로직만 두 신규 파일에

이식)

크라우니코드 학습

• lookup 조회: search "zip 저장"(0건), search "CRC32"(HIT crc32_checksum — Python zlib

트랜스리터레이션 스텁으로 미동작 확인, MISS 취급), search "docx zip"(0건) → 전부 MISS로 신규 생성.

• learn 등록: zip저장_store무압축(ZIP저장.한선 전체), docx파일_zip패키징CLI(DOCX파일.한선

전체), crc32_한선씨_검증됨(CRC32계산 함수 단독, 기존 오염 엔트리 대체) — 3건.

잔여 이슈

• 성능: 순수 산술 CRC32는 O(32×8) per byte 오버헤드가 있어 대용량(수백KB+) 문서엔 부적합할

수 있음(수 KB급 실측은 수 초 내). 실제 문서 규모(챕터 단위 등)에서 재측정 필요.

• "함수 내 배열 지역변수가 재호출 시 스토리지 재사용" VM 함정은 이번에 처음 실측된 것으로

보이며, ZIP저장/DOCX파일 두 파일 소스 주석에만 기록했다 — 세션 종료 후 사용자가 원하면 ~/.claude/templates/한선씨-가드레일.md와 MEMORY.md에도 반영 필요(본 세션은 서브에이전트 라 공유 가드레일 파일은 수정하지 않음).

• DOCX조각.한선의 표XML기초/태그짝검증 등 문서표/검증 기능은 이번 zip 패키징 범위 밖(요청

범위=CLI 3문단 데모 + zip 산출까지).