# 발표 준비 체크리스트 — 2026-08-25 if(kakao) 세션에서 운영자 발화로 벼려진 규율

> 출처: v8.5 → v9.0 재구성 세션의 운영자 피드백 전건. 프로젝트 무관 일반 규율만 남겼다.
> 그린룸(preprep) 하네스의 판정 렌즈 후보 — 각 항목이 «검사 가능한 질문» 형태다.

## A0. 발표 프로파일 — 서사보다도 먼저 (운영자 정식화 2026-08-26)

모든 판정 렌즈보다 앞서, 두 질문에 한 줄씩 답을 박고 시작한다. 이 답이 아래 전 장의
«어떻게 풀어내나»를 가른다 — 리뷰 의견은 대부분 이 프로파일의 함수였다.

- [ ] **A0-1. 어떤 발표인가?** (기술 공유 / 제품 소개 / 리더 보고 / 컨퍼런스 세일즈 …)
- [ ] **A0-2. 어떤 청중인가?** — 아는 것과 모르는 것을 각각 한 줄로.
      예: «하네스 엔지니어링을 알고 기술적 관심은 있으나, 개발자 위주라 QA 를 깊이는 모른다»

**프로파일 → 풀어내기 규칙 (한국식 기술 발표 실측, if(kakao)26 리뷰 6건에서 수렴)**:
| 청중 신호 | 풀어내기 |
|---|---|
| 도메인(QA 등)을 깊이 모름 | 결과 수치보다 **실물 샘플**(차단 화면·코드 조각)이 먼저 — 수치 강조는 관심을 분산시킨다 |
| 내부 어휘에 노출된 적 없음 | 축약어·은유는 일반어로 번역(«검사»·«줄»·«고장 방향» 급도 걸린다) — 저자 눈엔 안 보이므로 대조군 필수 |
| 사례를 따라오며 앞을 잊음 | **마지막에 방법론 한줄요약 재점등** — 지도 장 재사용 |
| 사람의 역할이 논지에 있음 | 다이어그램에 **사람 아이콘**을 실제로 세워라 — «사람이 서는 자리»를 글자만으로 두지 마라 |
| 한국 개발자 커뮤니티 | 글리프(—·«»·「」)·볼드 밀도·완결성 과잉 = AI 티 (D6·D7) |

## A. 서사 — 도형보다 먼저

- [ ] **A1. 서사 척추가 먼저, 도형은 그 다음이다.** 재구성 전에 다듬으면 없어질 장표를 다듬는다.
- [ ] **A2. 이론·방법론은 축약하고, 실제 사례 «한 건»에 태워라.** 방법론이 어떻게 들어갔는지는
      추상 설명이 아니라 사건의 순서로 보여준다. (막힘 → 넣음 → 나온 것)
- [ ] **A3. «우리 것»을 말하기 전에 «일반적인 것과의 차이»를 세워라.** 정의 → 차이 → 그 차이를
      만든 방법 순서로 넘어가면 다리가 자연히 놓인다.
- [ ] **A4. 결론이 첫 질문에 답하는지 확인하라.** 마지막 장에서 첫 장의 질문으로 돌아가는
      연결 고리(«그래서 ~하게 만든다»)가 빠지면 서사가 안 닫힌다.
- [ ] **A5. 내부 기여와 외부 사례의 균형.** 외부(공개) 사례가 화려해도, 내부 청중에게는
      «우리 일에 어떻게 돌아가고 있나»가 빠지면 공허하다.
- [ ] **A6. 필요 없는 장은 뺀다.** 좋은 장이어도 서사에 일이 없으면 목차에서 뺀다
      (파트는 남겨 되돌릴 수 있게).

## B. 애니메이션 — 효과가 아니라 장표 분할

- [ ] **B1. 시간이 제약이고 장수는 자유다.** 낭독 총량을 늘리지 않는 분할은 시간 비용 0.
- [ ] **B2. 전체 지도를 먼저 보여주고, 하나씩 점등하라.** (목차 전체 흰색 → 현재 섹션만 노랑)
- [ ] **B3. 같은 배치에서 «한 요소만» 변화시켜라.** 장 넘김이 곧 애니메이션이 되는 조건은
      좌표 고정이다 — 옮기지 말고 색·길이만 바꾼다. (예: 개발 화살표만 자란다)
- [ ] **B4. 진행 상태는 색으로.** 지나간 것 흰색 · 지금 노랑 · 아직 회색.

## C. 시각 어휘 — 토큰으로 고정

- [ ] **C1. 선 굵기를 토큰으로 고정하라.** (구조 1pt · 테두리 3pt · 흐름 7pt) 이 밖은 못 쓴다.
- [ ] **C2. 의도된 예외는 «예외»로 명시하라.** 강조를 굵기로 내는 자리가 있다면 그 굵기도
      토큰(강조 14pt)으로 — 예외가 무기록이면 다음 수리 때 «통일»된다며 지워진다.
- [ ] **C3. 화살표 방향을 서사 방향과 대조하라.** «아래에서 위로 쌓인다»는 그림에서 화살촉이
      아래를 보면 즉사. (DrawingML: headEnd=시작점, tailEnd=끝점 — 직관과 반대)
- [ ] **C4. 채운 블록 화살표보다 선 + 삼각 화살촉.** 레퍼런스 덱의 어휘와 맞추면 절반은 간다.
- [ ] **C5. 아이콘은 흰 선화 · 강조 노드에만 채움색 · 캡션은 도형 아래 작은 회색.**
- [ ] **C6. 「알고도 남긴 것」과 「몰라서 남은 것」을 갈라 적어라 (2026-09-04 실측).** 팔레트
      밖 색이나 규칙 밖 값을 **정해서** 남긴 자리가 있으면 그 자리에 이유를 적는다 — C2 와
      같은 원리를 값 전반으로 넓힌 것이다. 안 적으면 다음 감사자가 같은 것을 다시 «발견»하고,
      지운 값이 다른 번호로 되살아나기도 한다(실측: 지운 색이 다른 색번호로 되살아나 있었다).

## D. 언어 — 청중이 실제 쓰는 말

- [ ] **D1. 어휘 기준은 «청중이 실제 쓰는 말»이다.** 테크블로그·커뮤니티에서 쓰는 표기
      (머지·커밋·레포·게이트)를 그대로 써라.
- [ ] **D2. 과잉 순화도 결함이다.** «낸 것 / 안 낸 것» 식으로 풀면 오히려 안 읽힌다 —
      기술 청중에게 기술어는 일상어다.
- [ ] **D3. 같은 행위를 두 낱말로 부르지 마라.** (병합/머지 · 릴리스/릴리즈 혼용)
- [ ] **D4. 문장 성분 결손 검사 — 반복 지적 1위 클래스.** 주어·목적어·서술어 중 하나가
      빠져 «뭔 말인지 모르겠다»가 되는 자리. 낭독은 직전 문장 안에서 성분이 복원돼야 하고,
      화면은 명사구가 문법이되 «문장 꼴인데 성분이 빈 것»만 잡는다.
- [ ] **D5. 콜로케이션 한 칸 검사.** «맹점을 놓치다»(중복) · «약점을 사다»(직역) ·
      «병목이 늘어나다»(어긋난 동사) — AI 티는 대개 여기서 난다.

- [ ] **D6. AI 티는 문장 단위가 아니라 문서 단위에서도 난다** (실측 2026-08-26, GeekNews §32868:
      ko-tech-writer 5라운드 통과·기계 클래스 전부 0인 글이 «AI가 쓴 듯» 판정을 받았다).
      문장 계기가 못 재는 네 축을 따로 봐라 —
      ① **문장부호 어휘**: —(롱대시) · «» · 「」 · … — 한국 일반 저자는 '' ""를 쓴다. «»는
      입력조차 번거로워 «사람이 안 치는 부호»고, 「」·«» **혼용**은 더 큰 티. 하우스 스타일이라
      저자 눈에는 안 보인다는 점이 함정.
      ② **구조 정형성**: 훅→반전→정밀 숫자→겸손 고백→한계 명시→CTA 의 완전 병렬 —
      «정직·한계 고지» 패턴 자체가 이제 LLM 시그니처로 학습돼 있다.
      ③ **서식 밀도**: 문장 중간 볼드 강조 남발 · «첫째, 둘째,» 열거.
      ④ **무결점 완결성**: 오탈자 0 + 전 주장 선제 헤지 — 완벽함 자체가 티다.
      보정 시 주의: n=1 댓글로 과보정하지 마라 — 베이스레이트(그 커뮤니티의 AI 글 홍수에 대한
      패턴 매칭) 몫이 섞여 있고, 근거 없는 판정은 위치 신호일 뿐 처방이 아니다(E3).

- [ ] **D7. 판별자는 대조군으로 좁혀라 — 같은 플랫폼의 사람 글이 known-pair 다** (운영자 발안
      2026-08-26). GN Show 상위 10건 실측: **제목 10/10 이 하이픈(-) 구분, em-dash(—) 0건** —
      우리 제목과 문법(«이름 - 설명»)은 같고 글리프 하나가 갈랐다. 제목은 위치 가중치가 최대다
      (독자가 목록에서 처음 만나는 글자). 인간 본문 프로파일 대조로 **티가 아닌 것**도 확정:
      합니다체 일관·문제-해결 정형 구조·개발 철학 문장·숫자는 사람 글에도 그대로 있다 —
      이 축들로 과보정하지 마라. 남는 판별자: ① 글리프(—·«»·「」 vs 하이픈·괄호·따옴표)
      ② 문장 중간 볼드 밀도 ③ **자기 코퍼스 사투리 유출** — «같이 적습니다»·«적어 둡니다»·
      «이름으로 남긴다» 류 하우스 어휘가 공개 아티클로 이식되면 한국인 아티클 어휘가 아니게
      읽힌다. 하우스 스타일은 저자 눈에 안 보이므로 **대조군 없이 자가 판정하지 마라.**

## E. 검증 — 렌즈는 입장으로 가른다

- [ ] **E1. 슬라이드만 보고 읽히는가.** 발화를 놓친 청중 페르소나로 콜드리드 —
      «이 장만 보고 무슨 말인지 아는가». 낭독 의존 장이 터널이 된다.
- [ ] **E2. 맥락 없는 외부인이 «승인»할 화면·형식인가.** 심사자 렌즈 — 형식 붕괴(클리핑·겹침·
      중복 문장·귀속 없는 인용)가 감점이지, 내용의 난이도가 아니다.
- [ ] **E3. 콜드리드 산출 자체를 적대검토하라.** 콜드리드는 관측이지 처방이 아니다 —
      지적의 «위치»는 믿되 «처방»은 검증 후 반영. 운영자가 의도로 정한 것을 되살리는
      형태(예: 의도된 굵기 강조를 «통일» 명목으로 제거)를 특히 경계.
- [ ] **E4. 컨트롤을 심어라.** 렌즈를 돌릴 때 알려진 결함 하나를 심어 그걸 잡는지 본다 —
      «지적 없음»은 컨트롤 없이는 못 믿는다.
- [ ] **E5. 무대에 오르는 수치는 원문 확인된 것만.** 2차 기록(세션 카드·요약)을 1차처럼
      인용하지 마라 — 발표가 «우리 숫자를 우리가 내렸다»를 논지로 쓸수록 치명적.
- [ ] **E6. 피드백은 문구가 아니라 «원 사건 기록»으로 닫아라.** «세 줄이 뭐였는지» 류 질문은
      리뷰 문구를 다듬어서가 아니라 원 기록(27건→24/3)을 찾아 실체를 싣는 것으로 닫힌다.
- [ ] **E7. 발행 직전 최종본에 전 스캔을 재실행하라.** 수리는 결함의 주된 출처다 —
      「한 번 훑었다」는 그 시점의 사실일 뿐이다.

- [ ] **E8. 디자이너 렌즈 — 느낌의 렌즈와 원인의 렌즈는 다른 입장이다.** 청중 렌즈는 «헷갈린다»를
      느끼고, 디자이너 렌즈는 «강조색이 한 화면에서 두 가지 일을 한다»를 짚는다 (2026-08-25 실측:
      간격 색 혼동·좌우 비대칭을 운영자 눈이 청중 렌즈보다 먼저 잡았다 — 그 구멍이 신설 사유).
      페르소나 = 소프트웨어/웹 디자이너 출신 프레젠테이션 전문가. 축은 실존 프레임워크로 뒷받침한다:
      A1 색 의미 체계(Stephen Few) · A2 정렬·격자(CRAP-Alignment, Gestalt-Proximity) ·
      A3 시각 계층+3초 글랜스(Duarte Glance Test) · A4 장간 일관성(CRAP-Repetition, Nielsen #4) ·
      A5 여백 의도성(Reynolds, Tufte) · A6 접근성 대비 — 유일한 측정형(WCAG 4.5:1/3:1, 프로젝터
      마진으로 경계값 FAIL 처리) · A7 다크모드 고유 결함(순검정+순백 halation · 대면적 풀채도 진동).
      발화 규칙(Discussing Design): 지적 = «원칙 출처 + 의도 손해» 2절 형식, 취향 단독 금지,
      관측·처방 분리(E3 그대로 적용). A6 는 렌즈에 맡기지 말고 색 전수 추출 → 대비비 계산으로
      먼저 실측해 렌즈에 입력으로 준다 (계기는 known-pair 캘리브레이션: FFFFFF=21:1, 000000=1:1).

- [ ] 🟥 **E9. 페르소나에게 «렌더된 그림»을 줘라 — 좌표·텍스트 덤프로는 그 렌즈가 안 선다**
      (운영자 발안 2026-08-28: *"페르소나들은 직접 눈으로 보게 할 때 효과가 극대화될 것 같아"*).
      **실측된 결함이다.** 2026-08-28 세션은 페르소나 에이전트에게 `[y=… x=… …pt] 텍스트` 덤프를
      줬다 — 에이전트가 렌더를 못 본다고 가정했기 때문이다. 그 형태로 **좌표 결함은 잡혔지만
      «안 이쁜 것»은 한 건도 안 나왔다**. 같은 세션에서 운영자 눈이 잡은 것들:
      카드 안 텍스트가 미묘하게 위로(146,240 EMU) · 표 1열이 낱말 한가운데서 줄바꿈
      (`3자 대/면`) · `**'X'**조사` 가 굵게 안 먹고 별표가 화면에 찍힘 · 남은 취소선.
      **넷 다 텍스트 측정으로 0건이고 렌더를 보면 즉시 보인다.**
      **배선은 이미 가능하다** — 에이전트는 이미지 파일을 읽는다:
        · 마크다운 → `gh api --method POST /markdown -f mode=gfm -f text=<본문>` → HTML →
          로컬 http 서빙 → Playwright 스크린샷 → 그 png 경로를 페르소나에게 준다
        · pptx → PDF/PNG 로 굽고(§F1) 해당 장 이미지를 준다
      ⚠️ **덤프를 대체하는 게 아니라 짝짓는다** — 좌표 덤프는 «몇 EMU 어긋났나»를 재고
      그림은 «그게 눈에 보이나»를 잰다. H1 이 이미 그 분업을 적어 뒀다(렌즈 : 겹침·정렬·여백 /
      계량 : 굵기·크기·앵커·색). E9 는 그 «렌즈» 쪽에 **실제로 눈을 달아 주는** 배선이다.
      ✅ **계측 완료 2026-08-29 — 알려진 쌍 + 블라인드 6런**. ARM A(결함 살아있는 판) vs
      ARM B(고친 판)를 실제로 렌더(`gh api /markdown` → Chrome headless PNG)해 **레포 밖 cwd
      헤드리스 세션**에 힌트 0 프롬프트로 각 3회 줬다(프롬프트 블라인드는 안 통한다 —
      서브에이전트가 CLAUDE.md 를 상속한다).
        · A 전용 결함 적발 **3/3** — 리터럴 `**` 노출 · 낱말 중간 줄바꿈 · 표 볼드 뒤섞임
        · **출제자 목록에 없던 3종을 추가로 냈다** — 이탤릭 낱말 중간 끊김 · 괄호와 인라인코드
          사이 여백 · 두 표의 그리드 어긋남. 목록을 프롬프트에 넣었으면 안 나왔을 것들이다
        · 🟥 **ARM B(컨트롤)가 깨끗하지 않았고, 그것이 이 계측의 최대 수확이다** — 3/3 이
          «출제자가 방금 넣은 회귀»를 지적했다(1열 `<br>` 이 그 열을 더 좁혀 세로 쪼개짐).
          컨트롤 팔이 오탐 0 을 보여주는 데 그치지 않고 **저자가 못 본 신규 결함을 냈다.**
      🟥 **UNION 이지 치환이 아니다 — 외부 벤치가 그 경계를 정한다.** VLM-SlideEval
      (`arXiv:2510.22045`)의 방향은 **VLM 이 기하·위치에서 약하다**는 것이고, 그건 좌표 덤프
      렌즈가 **강한** 자리다. 그러므로 그림 팔을 붙였다고 좌표 팔을 은퇴시키면 더 강한 계기를
      잃는다. E9 의 알려진 쌍에는 **known-negative 로 «좌표 렌즈가 이미 잡던 기하 결함»을
      반드시 포함**해서, 그림 팔이 그것을 놓치는지 확인해라 — 놓치면 UNION 이 맞다는 증거다.
      🟥 **계기의 오탐도 같이 재라 — 렌더 CSS 는 소비자의 렌더러가 아니다.** 6런 중 4런이
      «헤더 가운데정렬 vs 본문 좌정렬»을 지적했는데 그건 **로컬 CSS 산물**이고 GitHub 실렌더가
      아니다. 계기≠대상. 판정에 쓸 렌더는 **소비자가 실제로 여는 렌더러**로 뽑아라.
      ⚠️ **남은 미측정**: pptx 팔은 못 돌렸다 — 이 머신에 `soffice`/LibreOffice 가 없다.
      마크다운 팔만 계측됐고, 덱 팔은 렌더러가 생기면 같은 절차로 재라.

## F. 도구 배선 (이번 세션 실측)

- [ ] **F1. 렌더해서 눈으로 보라 — 기계 검사는 «안 읽히는 것»을 못 잡는다.**
      XML 유효·텍스트 존재·색 정합이 전부 통과한 덱에서 글자 잘림·도형 겹침이 나왔다.
      경로: `soffice --headless --convert-to pdf` 또는 PowerPoint AppleScript → `pdftoppm` → 눈.
- [ ] **F2. 낭독 시간은 자수 기준선으로 관리하라.** (실측 기준선 확보 후 선형 환산 —
      단, 최종은 실낭독으로 재야 한다.)
- [ ] **F3. 스크립트가 «돌았다»와 «내용이 바뀌었다»는 다르다.** 치환 후 무변경 단언을 걸어라.
- [ ] **F4. `<a:t>` 안에 개행·탭을 넣지 마라.** XML 로는 유효하고 LibreOffice·python-pptx 도
      통과하지만 **PowerPoint 는 복구 대화상자를 띄운다**(2026-08-25 실측 — 4파일 6런이 원인,
      관계·파트·CT 검사는 전부 통과했는데 이것 하나로 «파일 손상» 판정). 줄바꿈은 `<a:br/>`.
      🟥 관대한 파서로 열린다는 것은 엄격한 파서로 열린다는 뜻이 아니다 — 최종 소비자의
      파서(PowerPoint)로 열어보는 것까지가 굽기다.

- [ ] **F5. 패키지 메타 캐시도 검사 대상이다.** `docProps/app.xml` 의 슬라이드 수·파트 목차는
      원본의 화석이 재저장을 통과해 살아남는다 (실측 2026-08-26: 원조 158장 캐시가 69장 덱에
      그대로 — python-pptx 는 통짜 보존). 굽기 게이트에 «app.xml ↔ 실제 파트 수 정합»과
      «중복 도형 id 0 · 고아 파트 0»을 함께 걸어라.
- [ ] **F6. 복구본은 버리지 말고 계기로 써라.** PowerPoint [Repaired]를 **딴 이름으로** 저장하면
      «무엇을 읽을 수 없었는지»를 소비자가 직접 알려주는 diff 짝이 생긴다 (운영자 발안 2026-08-26).
      원인 추격이 막히면: 복구본과 원본의 **내용 등가를 3중 증명**(전 장 텍스트·도형 수·노트 동일
      + 미디어 참조 결손 0 + 렌더 대조)한 뒤 **복구본을 정본으로 채택**하는 길이 있다 —
      «[Repaired] 저장 금지»는 «지워진 것을 모른 채 삼키지 마라»이지, 지워진 것이 0 임을 측정으로
      증명한 채택까지 막는 규칙이 아니다.

- [ ] **F7. 덱 XML 에 문자열 절단 수술을 하지 마라 — 파스가 게이트다.** 오프셋 문자열로 도형을
      잘라내는 수술이 두 파일을 찢었다(여는/닫는 태그 불일치 — 2026-08-26 실측, 자력 적발은
      사후 파스 검사). 구조 변경은 lxml 로 요소 단위로 하고, **모든 굽기 직전에 전 파트 파스
      검사 + 중복 id + 개행 + app.xml 파트 수 정합**을 한 게이트로 돌려라. 스크립트가 돌았다 ≠
      내용이 맞다(F3)의 구조판이다.

## G. 손편집 왕복 — 운영자가 직접 고친 판을 베이스로 삼는 절차 (2026-08-26 심야 실측)

- [ ] **G1. 운영자가 파일을 직접 고쳤으면 그 판이 새 베이스다.** 세션의 작업 트리를 버리고
      운영자 판을 언팩해 새 트리로 삼는다. 먼저 커밋해 보호한 뒤 diff 로 의도를 읽는다.
      🟥 그 반대(내 트리 위에 운영자 편집을 재적용)는 운영자 편집을 조용히 덮어쓴다.
- [ ] **G2. 손편집본 diff 는 «텍스트 델타»가 아니라 «의도»로 읽어라.** 문체를 습니다체로
      바꿨다면 그건 그 문장 하나가 아니라 **전 덱 문체 규칙**이다. 제목에 콜론 표기를 썼다면
      전 장 제목 표기 규칙이다. 한 곳을 고쳐 준 것은 «여기만 고쳐라»가 아니라 «이 규칙으로 전부».
- [ ] **G3. 손초안은 최종 레이아웃이 아니라 «이렇게 말해달라»는 지시다.** 운영자가 넣어 둔
      텍스트 블록을 그대로 두면 «리디자인 안 했다»가 된다 — 내용은 살리고 **덱의 도형 문법으로
      다시 세워라**(실측: 규율 3 부연을 텍스트 나열로 남겨 지적받음 → 사람/AI 두 카드 대비로 재설계).
- [ ] **G4. PowerPoint 메모(코멘트)는 작업 지시서다.** `ppt/comments/modernComment_*.xml` 를
      슬라이드 rels 로 페이지에 매핑해 전건 목록화하고, 하나씩 닫아라. 파일 안에 있는 지시를
      «봤다»로 끝내면 그게 미반영 잔여가 된다.
- [ ] **G5. 열려 있는 파일에 덮어쓰면 운영자 화면은 옛 판이다.** PowerPoint 는 메모리로 읽으므로
      디스크를 바꿔도 화면이 안 따라온다. 「대본이 안 바뀌었다」류 어긋남이 나오면 **먼저 파일을
      닫았다 다시 열게** 하고, 그때까지는 서로 다른 판을 보고 있다고 가정하라.

## H. 계량 검사 — 눈으로 못 잡는 축 (2026-08-26 심야 실측)

- [ ] **H1. 저해상도 렌더 육안 검사는 «수치 일관성»을 구조적으로 못 잡는다.** 50dpi 에서
      선 12700 과 25400 은 둘 다 «가는 선»으로 보인다. 렌즈에게 맡길 축과 XML 을 세어야 하는
      축을 갈라라 — 렌즈: 겹침·정렬·여백·자기설명 / 계량: 선 굵기·글자 크기·앵커·색값.
- [ ] **H2. 전 덱 스트로크 히스토그램을 뽑아 규칙 하나로 정규화하라.** 실측에서 화살표가
      88900:38100 = 53:13 으로 이원화, 제목 크기가 여섯 갈래(4400~9600)로 갈려 있었다.
      규칙 예: 화살표 = 강조 88900 / 표준 63500, 실선 12700, 카드 테두리 = 강조 25400 / 표준 12700.
- [ ] **H3. 🟥 «통일»이 새 결함을 만든다 — 통일 후 반드시 재렌더해서 눈으로 확인하라.**
      제목 크기를 한 값으로 통일했더니 긴 제목이 2줄로 접혔다(자력 적발 0, 운영자 지적).
      크기는 단일값이 아니라 **길이 구간별 단계**로 잡아라(예: ≤18자/≤24자/≤30자/그 이상).
- [ ] **H4. 요소를 옮기면 그 요소가 «비키는» 자리도 확인하라.** 아이콘을 라벨 쪽으로 붙였더니
      라벨이 화살표를 관통했다 — 한 요소의 이동은 인접 요소의 충돌 검사를 동반한다.
- [ ] **H5. 빌드 프레임 간 기하 동일성을 강제하라.** 같은 요소가 다음 프레임에서 크기·위치·
      감싸기(카드 유무)가 달라지면 화면이 «점프»한다. 프레임 A 를 만들 때 B 에서 기하를 읽어
      그대로 복사하라(실측: 가정/측정, 지쳐서/믿어서, 규율 1·2·3 전부 이 결함).

## I. 박스 문법 — 무엇을 감싸고 무엇을 감싸지 않는가 (운영자 정식화 2026-08-26)

- [ ] **I1. 박스 = 흐름에 참여하는 «물건».** 산출물·게이트·모델·도착지처럼 화살표로 이어지며
      상태가 옮겨 다니는 것은 카드로 감싼다.
- [ ] **I2. 맨 글자 = 주장·범주.** «지쳐서/믿어서» 같은 두 갈래 범주, 펀치 문장, 금언은
      감싸지 않는다 — 감싸면 흐름의 노드처럼 읽혀 문법이 무너진다. 범주 구분은 **구분선**으로.
- [ ] **I3. 판정선은 카드 가족 안에서 해결하라.** 세 카드 중 마지막을 «판정 카드»로 쓰면
      별도 바를 띄우지 않고도 결론이 선다(실측: 구버전 카드 문법이 신버전 바보다 직관적이라는
      운영자 판정으로 되돌림).

## J. 발표 유형·대상 프로파일 → 규칙 파생 (범용판 출하 시 진입점)

- [ ] **J1. A0 프로파일(발표 유형 · 청중 · 시간 · 시청 환경)을 먼저 확정하고, 나머지 규칙을
      거기서 파생시켜라.** 이번 실측 프로파일 = 기술 공유 발표 / 개발자 중심·QA 얕음 /
      20분 / 모바일 병행 시청 → 파생: 키워드 위주 · 슬라이드 자립성(E1) · 작은 글씨 금지 ·
      제목=주장.
- [ ] **J2. 한국어 특화 축을 별도 렌즈로 세워라.** 조사 붙여쓰기(«'잘 나온다' 로»→«'잘 나온다'로»),
      쉼표·콜론 앞 공백, 문체 일관(습니다체/한다체 혼용 금지), 위계 어휘(«장표»→«발표자료» 같은
      조직 안에서만 통하는 은어 제거), 줄바꿈 위치(어절 중간 끊김). 이 축은 영어권 디자인 렌즈가 못 잡는다.
- [ ] **J3. 출하 형태.** 프로파일 입력 → ① 서사 스켈레톤(A) ② 시각 토큰 세트(C·I) ③ 대본
      자수 예산(F2) ④ 검증 렌즈 조합(E) ⑤ 굽기 게이트(F4·F5·F7) ⑥ 계량 정규화(H)
      — 여섯 묶음이 한 파이프라인이다.

---

## K. OOXML 직접 조작 — 굽기 게이트 (2026-08-27 실측, 하루 4시간을 태운 계열)

pptx 를 lxml 로 직접 고치는 파이프라인에서 **PowerPoint 「복구」 다이얼로그**가 세 번 났다.
셋 다 렌더(LibreOffice)로는 안 잡히고, **PowerPoint 로 열어 화면을 봐야만** 잡힌다.

- [ ] **K1. `<p:spTree>` 첫 두 자식은 `nvGrpSpPr` · `grpSpPr` 다.** 새 도형을 `spTree` 맨 앞에
      넣으면(= `list(spTree)[0].addprevious(...)`) 스키마 위반이고 **PowerPoint 가 복구를 띄운다.**
      🟥 이 세션의 실제 원인이 이것이었다. 삽입은 **실재하는 도형의 앞/뒤**에 하거나 `append` 하라.
- [ ] **K2. 관계 참조(`r:id`/`r:embed`)가 자기 `.rels` 에 실재하는가.** 슬라이드를 복제할 때 원본
      끝의 `<p:extLst>` 안 `p188:commentRel r:id="rId3"`(댓글 앵커)가 따라오는데, 복사본 rels 에서
      그 rId 를 지우면 **끊긴 참조**가 된다. 파트 전체를 훑어 대조하라.
- [ ] **K3. `docProps/app.xml` 의 `TitlesOfParts` 벡터 크기 = 실제 `lpstr` 개수.** 슬라이드를
      더하거나 뺀 뒤 한쪽만 고치면 복구가 뜬다. `Slides`·`Notes`·HeadingPairs 의 «슬라이드 제목»
      카운트도 같은 값이어야 한다.
- [ ] **K4. 굽고 나면 «내가» 먼저 PowerPoint 로 열어 화면을 본다.** 운영자가 발견하게 두지 마라.
- [ ] 🟥 **K5. 탐지기를 알려진 쌍으로 보정하고 쓴다 — 그리고 무엇을 재는지 확인하라.**
      이 세션에서 `osascript … get name of active presentation` 을 탐지기로 썼는데, 그건
      «복구가 **이미 수락됐나**»를 재지 «복구가 **뜨는가**»를 재지 않는다. **거짓 음성**이 나왔고
      정상본이라 보고했다가 운영자가 다이얼로그를 보고 있었다. 화면 스크린샷이 유일하게 옳은 계기다.
      (계기≠대상 — `feedback_green_for_the_wrong_reason` 과 같은 계열)
- [ ] 🟥 **K6. 텍스트 치환은 「문단(`<a:p>`) 단위」로 합쳐라. 파일 단위로 합치면 슬라이드가 뭉개진다.**
      run 이 쪼개져 있어서 `<a:t>` 하나만 보면 패턴이 안 잡히는데, 그렇다고 파일 전체 `<a:t>` 를
      이어붙여 첫 칸에 몰아넣으면 **도형 여러 개의 텍스트가 한 도형으로 합쳐진다**(실제로 4장을
      그렇게 망가뜨리고 렌더로 잡아 되돌렸다). 도형(`<p:txBody>`) 또는 문단 단위가 안전 경계다.
- [ ] **K7. 한국어 조판 정규식은 좁게.** `([가-힣])\s+(합니다|됩니다|겁니다)` 같은 규칙은
      «크로노라고 합니다» · «올리면 됩니다» 처럼 **띄는 게 맞는 자리**를 붙여버린다.
      따옴표·라틴·의존명사 뒤(`"…있는가" 입니다`, `forge-harness 라는`, `등 입니다`)만 좁게 잡아라.

## L. 제목 정규화 (H3 의 후속 — 「통일」이 만든 결함의 반복)

- [ ] **L1. 제목이 두 줄로 접히는 원인은 글자 크기가 아니라 「상자 폭」인 경우가 많다.**
      `ext cx` 가 8M 인 제목 상자가 섞여 있어 6200 이 접혔다. **폭을 먼저 통일**(22M)하고
      그 다음에 길이별 크기를 정하라.
- [ ] **L2. `wrap="none"` + 오토핏 해제.** `normAutofit` 이 켜져 있으면 접힌 뒤 **글자를 줄여서**
      같은 크기 지정이 화면에서 다른 크기로 보인다. 크기를 강제하려면 오토핏을 꺼라.
- [ ] **L3. 세로 앵커도 제목의 일부다.** 한 장만 `bodyPr anchor="ctr"` 이면 그 장의 제목이
      **아래로 내려앉는다**(상자 높이의 절반만큼). 실측 8장이 그랬고, 운영자가 «14페이지가
      13페이지보다 내려왔다»로 잡았다. 전수로 `anchor="t"` 로 맞춰라.
- [ ] **L4. 목록 항목을 별도 텍스트 상자로 빼면 들여쓰기가 어긋난다.** 본문 목록의 `marL`/indent
      를 물려받지 못해 번호가 왼쪽으로 튀어나온다. 같은 목록은 **같은 `txBody` 안 문단**으로 두고,
      서식은 형제 문단을 `deepcopy` 해서 물려받게 하라.

## M. 정렬·강조가 「조용히 안 먹는」 자리

- [ ] **M1. `<a:pPr>` 가 없는 문단에 `algn` 을 지정하면 아무 일도 안 일어난다.** 정렬이 안 먹는
      대부분이 이것이다 — **없으면 만들어서** 넣어라. 이 세션에서 제목·부제·캡션 여러 곳이
      이 이유로 「고쳤는데 그대로」였다.
- [ ] **M2. 텍스트 상자에 `<a:ln>` 을 붙이면 흰 테두리가 생긴다.** 색만 바꾸려고 `ln(color=…)`
      을 호출하면, 선이 없던 텍스트 상자에 **선을 만들어 붙인다.** 색 변경은 `rPr` 쪽만 건드려라.
- [ ] **M3. 중앙정렬은 「상자 폭」과 함께 봐야 한다.** `algn="ctr"` 이어도 상자가 화면 중심에서
      벗어나 있으면 텍스트도 벗어난다. 기준선(세로선·카드 중심·슬라이드 중심)을 정하고
      **상자 중심을 그 값에 맞춰라**.
- [ ] **M4. 흐림(dim) 값은 하나로.** 같은 「비활성 목록 항목」이 한 장은 `3A3A3A`(1.85:1),
      다른 장은 `A9A9A9`(8.94:1) 였다. 운영자가 «어둡고 얇다»로 잡았는데 굵기는 같았고
      **색만 달랐다**. 단, 큰 글자의 고스트는 더 어두워야 같은 「꺼짐」으로 보인다 — 값이
      하나여야 한다는 규칙은 **같은 역할·같은 크기 안에서만** 적용하라.

> **§K~M 을 공개 FH 자산으로 승격할 때** — 이 절 대부분은 **OOXML/PowerPoint 고유**다(K1~K4·K7·L·M).
> 일반 규율은 **K5(계기가 무엇을 재는지)** 와 **K6(대량 치환의 안전 경계)** 둘뿐이고, 그 둘도
> 「pptx」·「슬라이드」 어휘를 그대로 옮기면 방향·단위·대상이 소실된다
> (`feedback_transplanted_terms_lose_direction`). 승격하려면 **그 렌즈를 먼저 태우고**,
> 나머지는 여기(발표 하네스)에 남겨라. — peer 지적 2026-08-27