0장. 한 장 요약 (사장님이 이것만 읽어도 되게)

무엇을 조사했나

세 시스템(광고디렉터 · 웹 파이프라인 2 · PPT 계열 4스킬 + 실전 기록 4폴더)을 능력 하나 = 한 줄로 전부 옮겨 적고(40편 · 약 10,000행), 새 검수관이 줄마다 실물과 대조하고(40편), 「이 시스템의 능력을 저 시스템의 이 모드에 넣으면」을 23편·약 3,000줄로 판정하고, 그 판정을 다시 검수하고(23편) 반려분을 수리본에 반영했습니다(23편). 우선 4모드(상세페이지·인쇄물·인스타·메타 카드뉴스)는 모드 통째 비교(3안)와 실행 테스트 8건까지 했습니다. 원본은 한 글자도 안 고쳤습니다.

결론 여섯 줄

1. PPT → 광고: 두 시스템은 같은 종류의 일이지만 검사 항목이 거의 안 겹칩니다(상세페이지 24 vs PPT 17, 겹침 2). 「합치면 둘 다 는다」가 실측입니다. PPT 검사기를 그대로 대면 위반의 51~100%가 판 크기 허수라 캔버스 값 층(카드뉴스·상세페이지) + 글자 하한 mm/pt 층(인쇄물)이 먼저 필요합니다.
2. 갈아엎기(3안 중 ⑶)는 네 모드 어디서도 근거가 약합니다. 정책 게이트(표시광고법·Meta·업종)·플랫폼 규격·인쇄 규격·Affinity 두 갈래·크몽 흐름이 PPT 에 대응물이 없어 통째로 사라집니다. 제 추천은 네 모드 모두 ⑴ 능력 삽입(인스타는 ⑵ 제작 단계만 검사기 붙이기까지).
3. PPT → 웹: 웹이 검사기·증거 규율에서 앞서 있어 「그대로」는 적고, 넣을 것은 레퍼 계측 서식·정본 판정 순위·은퇴 선언 철회·판정 다루는 법입니다. component-intake 는 픽셀 비교 실물이 있는데 모드 문서가 안 가리킵니다(배선만 하면 됨).
4. 광고 ↔ 웹: 같은 창고에서 설치한 자매라 겹치는 건 옮길 게 아닙니다. 광고→웹 = 발사 게이트·지시문 3줄·UTF-8·쉬운 말·AI 인물 공시. 웹→광고 = 「초록불은 증거가 아니다」 계열(변이 하네스는 광고에 0건).
5. 사장님이 정해야 정합이 성립하는 자리 16곳(8장). 그중 「생성물 시각 판정을 사람이 하나 AI 가 하나」(2026-07-03 지시가 광고에만 있음) 하나를 정하면 세 줄이 같이 정해집니다.
6. 파이프라인 자체의 결함(9장): 돈에 걸리는 것 1(Kling 유료 발사가 import 만으로 과금) · 초록불인데 안 도는 검사기 다수 · 완성 표시인데 실사용 0인 프로파일 · 문서-코드 드리프트 여러 건.

사장님이 답하실 것 (번호로)

• 1장 Q1-1~4 · 2장 Q2-1~5 · 3장 Q3-1~5 · 4장 Q4-1~3 · 5장 Q5-1~3 · 6장 Q6-1~3 · 7장 Q7-1~4 · 8장 Q8-1~8. 각 질문마다 제 추천이 1번에 있습니다.
• 답이 없는 항목은 「제 추천」으로 진행하고 그 사실을 적습니다.

조사의 신뢰도 (10장)

• 검수 4층이 실제로 걸러낸 것: 인벤토리 반려·재감사 다수, 매핑의 「받는 쪽에 없다」 오판 12~31%(뿌리 = 광고 스크립트 285개 미열람). 수리본에서 「없음」 줄 전수 재확인.
• 남은 한계: 인용 검사기는 앞 20자만 · 「없음」 재확인은 낱말 검색 기반 · 미실행 테스트 3건 · 「부분」 판정 중 안 본 줄 잔존.
• 세션 한도로 서브에이전트가 두 번 일괄 사망했으나 산출물은 전부 살아 있었습니다.

다음 단계 (11장)

번호 답 → 흡수 실행(계약 테스트 동반) → share-pack 보강 → 브로슈어 키트 → PPT 규칙 키트 → intake.

1장. 광고디렉터 · 상세페이지 모드 (사장님 1순위)

이 장의 근거 파일: 매핑 수리본 _감사/v2/02-mapping/MAP-PPT→AD-commerce-detail-page-v2.md · 비교 COMPARE-commerce-detail-page.md · 실행 테스트 04-tests/TEST-cdp.md. 아래 숫자는 전부 그 파일에서 옮겼고, 원본 파이프라인은 한 글자도 안 고쳤습니다.

1-1. 한 줄 결론

두 시스템은 같은 종류의 일(고정 폭 위에 HTML 을 짜서 픽셀로 검사하고 캡처해 내보냄)을 하지만, 검사하는 항목이 거의 안 겹칩니다. 광고 게이트 24항목과 PPT 검사기 17항목 중 겹치는 건 2개(글자 최소 크기 · 판 밖으로 나감)뿐입니다. 그래서 「어느 쪽이 더 정확하냐」보다 「합치면 둘 다 는다」가 실측 결과입니다. 다만 PPT 검사기를 그대로 얹으면 위반 357건 중 252건(71%)이 판 크기 차이 때문에 생기는 헛경고라, 판 크기 값을 따로 주는 층이 먼저 있어야 합니다.

1-2. 지금 상세페이지 모드가 갖고 있는 것 (광고디렉터 쪽)

모드가 스스로 「비어 있다」고 적은 자리 4개 1. 골격 메뉴 — 「카페24 상세설명에 그대로 얹을 수 있는 스니펫이 하나도 없다」(snippet-skeletons/카탈로그.md 19줄). 스니펫 269개 중 앞 10개만 실측했고 전부 JS 끄면 깨짐. 2. 도해 부품 — 프로파일이 「벤다이어그램」·「타원 세로 체인」을 이름으로 부르는데 실물 부품은 카드·표·구분선 3장뿐, 도해 0개. 3. 차트 — 「수치 섹션에 그래프가 붙지 않는다. 수치+그래프로 적으면 거짓」(인벤토리 AD-A5-226). 4. 게이트 구멍 ~~3종~~ 2종(정정 2026-09-07) — 글자가 다른 요소에 덮이는 것 · 글자가 판 네 모서리에 붙는 것을 못 잡음. ~~글자 없는 도형이 판 밖으로 나가는 것~~ → 실물 L1 은 전 요소를 재므로 이미 잡는다(흡수 2호에서 확인). 두 구멍은 2026-09-07 L4·W7 로 막았다.

1-3. PPT 쪽에서 넣을 수 있는 것 (매핑 90묶음 판정, 수리본 기준)

값 큰 자리 4곳 (위 「비어 있는 자리」를 정확히 메우는 것) - 골격 메뉴 ← PPT 골격 은행 54종 + 증보 후보 81종. 단 PPT 은행은 슬라이드(가로 1600×900)·핀 111장에서 귀납된 것이라 세로 652~990px 상세페이지에 맞게 골라서 값을 바꿔야 함. - 도해 부품 ← PPT 도해 원자 38종(등급 S/A/B) + 정적 도해 부품 19종 + 「데이터 모양 → 도해 결정표」(이건 그대로 넣을 수 있는 6개 중 하나). - 차트 ← 같은 도해 결정표 + 부품 은행. 단 서드파티 차트 스킬(lieflat)은 라이선스가 비상업이라 판매 페이지에 못 씀. - 게이트 구멍 3종 ← PPT 검사기가 이미 코드로 막은 것 2개(덮임 · 도형 넘침. 사고 원문: 「어둡게 하는 베일이 본문을 통째로 덮었는데 검사기는 통과」 2026-09-04) + 4모서리 검사. 세 번째는 PPT 쪽도 미조치.

이미 광고 쪽에 있어서 「없다」가 틀렸던 것 (검수에서 잡혀 수리본에서 고침) - 누끼(배경 제거) 절차 — 룰/클라이언트-작업-운영.md 73줄 - 색치환 절차 3단 + 실행기 — 흐름/06 172~183줄, 스크립트 인벤토리 AD-A7c-180 - 판정 원문 장부 — 룰/확정-사장님.md(훅이 매 턴 주입) - 취향 로그 — feedback/taste-log.md - 업스케일 규칙 5건(수리 때 추가 발견)

1-4. 못 넣는 것 8개와 이유 (전부 광고 쪽 규칙 원문에 근거)

1-5. 실제로 돌려본 결과 (메인이 직접 실행, 출력 전문은 04-tests/)

1-6. 3안 비교

1-7. 사장님이 정하실 것 (번호로 답하시면 됩니다)

Q1-1. 상세페이지 모드는 어느 안으로 갑니까? - 1 = ⑴ 능력만 삽입 (제 추천 — 실측상 두 게이트가 안 겹쳐 합치면 둘 다 늘고, 되돌리기 쉬움) - 2 = ⑵ 제작 단계만 교체 (충돌 3건 해법을 먼저 정해야 함) - 3 = ⑶ 전체 재개설 - 4 = 안 함

Q1-2. ⑴로 가면 먼저 넣을 것 순서 (제 제안: 게이트 구멍 2종 코드 삽입 → 도해 결정표 → 골격 54종 중 세로 폭에 맞는 것 선별 → 여백·라운드 값 층) - 1 = 이 순서대로 / 2 = 순서 바꿈(적어 주세요)

Q1-3. PPT 마감 검사기의 값 층 — 판 크기·안쪽 여백 하한·라운드 토큰을 매체별로 주는 층을 만들면 카드뉴스에도 같이 쓸 수 있습니다(4장 참고). 상세페이지 값 제안: 판 = 캔버스 폭×무한 세로, 여백 하한 = 폭의 3%(652 → 20px), 라운드 토큰 = 광고 쪽에 규약 없음 → 새로 정함 - 1 = 이 값으로 / 2 = 값 고침(적어 주세요) / 3 = 값 층 안 만듦

Q1-4. 문서-코드 드리프트 1건(어두운 섹션 경고) — 코드가 실제이고 문서 주석이 낡음 - 1 = 문서 주석 고침 / 2 = 그대로 둠

1-8. 이 장의 한계(정직 표기)

• 「없음」 유지 17줄은 낱말 12종 검색으로 재확인했고 전문 통독은 아닙니다.
• 게이트 본문 중 디자인 룰 함수(design_audit) 860~1081줄은 안 읽었습니다.
• 「좋아지는 것」 근거로 쓴 PPT 작업기록 5편은 타자검수 전입니다.
• 테스트 B 미실행.

2장. 광고디렉터 · 인쇄물 모드 (print-collateral) — 이혜진 님 브로슈어 키트가 떼 갈 갈래

근거: 매핑 수리본 _감사/v2/02-mapping/MAP-PPT→AD-print-collateral-v2.md · 비교 COMPARE-print-collateral.md · 실행 테스트 04-tests/TEST-print.md. 원본 파이프라인 무수정.

2-1. 한 줄 결론

인쇄물은 네 모드 중 「PPT 모드로 갈아엎기」에 가장 안 맞는 축(mm 판형·제본·도련·인쇄용 PDF·Affinity 두 갈래)을 갖고 있고, 반대로 검수·학습층이 거의 비어 있어 PPT 것을 받을 자리는 넓습니다. PPT 검사기를 그대로 대면 위반 1,417건이 나오지만 전부 매체 차이(판 크기 절반 + 글자 단위계 절반)라 그대로는 못 씁니다. 브로슈어 키트에 실어야 할 것은 광고 쪽 인쇄 체인이고, PPT 에서는 「규칙·판정·마감 검사의 방식」만 값을 바꿔 보탭니다.

2-2. 지금 인쇄물 모드가 갖고 있는 것

구조 결함 2개(원본에서 발견) - 검수관 문서에 print-collateral 이 0회 — 굽지 않는 타입인데 「codex 로 컷을 굽는 타입 전제」 체크리스트를 탐. - 같은 규칙을 두 번 어긴 기록 — 인덱스 탭 규칙이 프로파일에 이미 있었는데 2026-09-01 에 다시 어겼고 사장님이 잡으심(환류층이 안 돌아서인지 문서를 안 읽어서인지는 원문에 없음).

2-3. PPT 쪽에서 넣을 수 있는 것 (매핑 84묶음 → 수리본 108줄)

넣을 자리가 넓은 곳: 검수 순서 「기계 먼저 사람 마지막」 · 판정 원문을 날짜와 함께 보존하는 파일 · 「같은 결함 3회면 검사기로 승격」 규칙 · 눈검수 사고를 코드로 옮기는 관행 — 인쇄물 쪽 학습층이 비어 있어 부딪힐 것이 거의 없음.

키트에 직접 걸리는 정정 1건: 처음 매핑은 「대비 재는 실행기가 없다」고 적었으나 틀렸습니다. gallery_contrast.py 가 WCAG 상대휘도로 글자색·스크림을 정합니다. 없는 것은 실행기가 아니라 인쇄물용 판정 임계값(있는 임계값 3:1 은 상세페이지 전용). → 키트에 이 도구를 싣되, 임계값은 인쇄 조건으로 새로 정해야 합니다.

2-4. 못 넣는 것과 이유 — 핀 모사 공정이 정면으로 부딪힘

PPT 의 핀 모사 공정(수집 → 격자 판독 → 태그 → 모사 → 판정 → 역추출)은 격자 픽셀 카운트·bbox·색 추출을 스크립트로 합니다. 광고 쪽 레퍼 정독 규칙은 사장님 원문으로 이를 금지합니다.

「절대절대 지금부터 스크립트 쓰지마 디자이너 작업에는 스크립트 절대 쓰면안돼」 · 「이미지 하나만 봐도 목업처럼 되어 있고 안에 내부를 봐야 해서 루프로 봐야 한다」 (templates/ref-study-recipe.md 287줄)

경계선은 이미 그어져 있습니다: 금지 대상은 「레퍼의 내용을 스크립트로 재는 일」이고, 파일 목록·장수 세기·중복 확인 같은 사무 처리는 허용(같은 파일 295줄). 그리고 광고 프로젝트는 2026-09-04 에 이미 판정을 내렸습니다 — 핀 모사 공정의 정본은 PPT 스킬 쪽이고 광고 단계에는 안 넣기로(intake-인포그래픽핀모사-20260904, 축① X · 축⑤ O).

두 사고의 방향이 반대라는 것도 확인됐습니다: PPT 는 기계를 건너뛴 손픽에서 사고(실험14, 폐기핀 손픽), 광고는 손검수를 덜 해서 사고(14면 중 한 펼침만 보고 넘김). 어느 쪽이 더 정확한지 직접 비교 근거는 없습니다.

2-5. 실제로 돌려본 결과 (04-tests/TEST-print.md)

카드뉴스·상세페이지는 「판 크기 값 층」만 있으면 PPT 검사기가 성립했지만, 인쇄물은 글자 하한을 mm/pt 로 다시 정의하는 층이 추가로 필요합니다. 또 인쇄 규격 축(mm·재단선·300dpi)은 PPT 검사기에 없고, CMYK·A3 는 양쪽 다 없습니다(광고 PDF 관문 170줄에 색공간 항목 없음, 좌표계는 A4 하나).

2-6. 3안 비교

2-7. 브로슈어 키트에 무엇을 싣나 (이 장의 부산물 — 결정은 사장님)

• 광고 쪽 인쇄 체인 그대로: 프로파일 print-collateral · 확정사양 절차 · 9-bis 방향 회의 · HTML 지면 생성기 · 낱말갈림/넘침/정렬/사진 아귀 검사 4종 · 좌표 추출 → Affinity 조립(㉮) / 소스만(㉯) · 인쇄용 PDF 관문 · 인쇄 검수 5항목. affinity-sdk 는 무료(사장님 확인).
• 함께 실을 도구: gallery_contrast.py(임계값은 새로) · 스톡 이미지 검색 스킬(API 키는 받는 쪽이 직접) · 레퍼 정독 서식(사람이 눈으로, 스크립트 금지 조항 포함) · 핀 판독 절차는 「사장님이 했던 방식」대로 수집 → 격자 판독 → 태그 → 모사 → 판정 → 역추출, 흡수 끝난 레퍼는 ref흡수완료/ 로.
• 싣지 않을 것: PPT 은행(파란펭귄 390·핀 128) · lieflat 차트(비상업 라이선스) · 유료 영상 발사기.
• 정규화가 필요한 것: PPT 계열이 web-ppt 절대경로와 0. FONTS PACK 에 의존해 단독으로 안 돎(1단계 검수 발견) — 키트에 PPT 검사기를 넣는다면 share-pack §E 에서 경로를 풀어야 함.

2-8. 사장님이 정하실 것

Q2-1. 인쇄물 모드는 어느 안? 1 = ⑴ 능력만 삽입(제 추천 — 학습·검수층이 비어 있어 넣을 자리가 넓고 잃는 것이 없음) / 2 = ⑵ / 3 = ⑶ / 4 = 안 함 Q2-2. 검수관 문서에 인쇄물 분기를 신설(지금 0회) — 1 = 신설(인쇄 검수 5항목을 분기표로) / 2 = 그대로 Q2-3. PPT 마감 검사기의 인쇄용 값 층 — 제안: 판 = 면 크기(판형.json mm × 3.048) · 글자 하한 = 본문 9pt·캡션 7pt(제 제안값, 근거 없음 — 사장님 값으로) · 재단선 안쪽 5mm 를 「판 가장자리」 값으로 — 1 = 이 값으로 시작 / 2 = 값 고침 / 3 = 안 만듦 Q2-4. 핀 모사 공정은 광고 인쇄 단계에 안 넣는다(2026-09-04 판정 유지) — 1 = 유지 / 2 = 「사무 처리」 범위 안에서 장수 세기·중복 확인만 넣음 / 3 = 재검토 Q2-5. 브로슈어 키트 구성은 2-7 대로 — 1 = 그대로 / 2 = 고침(적어 주세요)

2-9. 한계

• 「해당 없음」 27줄은 개별 대조 안 함(검수도 표본 3줄). 흐름/02-페르소나.md·taste-log.md 는 이번 비교에서 열었으나 매핑 수리본에는 파일 단위로만 반영.
• 「값 바꿔서」 24줄의 실값은 정하지 않음.
• T3 미실행.

3장. 광고디렉터 · 인스타 카드뉴스 모드 (insta-cardnews)

근거: 매핑 수리본 _감사/v2/02-mapping/MAP-PPT→AD-insta-cardnews-v2.md · 비교 COMPARE-insta-cardnews.md(테스트 3건 실측 포함). 원본 무수정.

3-1. 한 줄 결론

이 모드의 마감 검사 7종 중 5종이 지면의 생김새인데 전부 사람이 판정하고, 실제 세션이 남긴 「기계 검수」는 파일 존재·크기 1080×1350·md5 세 가지뿐입니다. PPT 검사기는 캔버스 두 줄만 고치면 이 지면에서 돌아갑니다(위반 28 → 9, 68%가 판 크기 허수). 다만 광고 쪽엔 카드뉴스를 굽는 조판기가 이 모드에 배선돼 있지 않고(메타 카드뉴스 전용), 피드백 창고는 4개월째 비어 있습니다.

3-2. 지금 인스타 카드뉴스 모드가 갖고 있는 것

3-3. PPT 쪽에서 넣을 수 있는 것 (88묶음 → 수리본 90줄)

검수에서 뒤집힌 것(광고 쪽에 이미 있었음): 카드뉴스용 대비 계산기 gallery_contrast.py(테스트가 1080×1350 그대로) · 픽셀 격자 검사기 grid_layout_audit.py(전 모드 공용) · 레퍼 판독표 9칸(1단계 흐름 문서) · 7단계 게이트에 insta 항목(흐름/07-검수완료.md 60줄 — 인벤토리가 빠뜨림). 처음 매핑의 「없음」 33줄이 수리 뒤 26줄.

3-4. 실제로 돌려본 결과 (비교 에이전트가 직접 실행, 출력 전문은 비교 파일 안)

두 검사기의 도입 비용이 자릿수가 다릅니다: 마감 검사기는 2줄, 무대 검사기는 템플릿 103장.

3-5. 3안 비교

3-6. 사장님이 정하실 것

Q3-1. 어느 안? 1 = ⑴ / 2 = ⑵(제 추천 — 2줄 수정으로 마감 검사기가 돌고, 이 모드는 기계 검수가 0에 가까워 얻는 것이 큼. 단 Q3-2 답이 먼저) / 3 = ⑶ / 4 = 안 함 Q3-2. 「텍스트 가독 판정 = 사용자」(2026-07-03) 와 기계 측정의 관계 — 1 = 기계 측정은 숫자라 지시와 별개, 붙여도 됨 / 2 = 지시 유지, 기계 측정 안 붙임 Q3-3. 카드뉴스 라운드 토큰·왼쪽 여백 하한 — 광고 쪽에 규약이 없음. 제안: 라운드 {0, 16, 24, 999} · 여백 하한 폭의 4%(1080 → 43px) — 1 = 이 값으로 / 2 = 고침 / 3 = 안 정함 Q3-4. 조판기를 insta 에도 배선(지금 메타 전용, 역할 목록 불일치) — 1 = 배선 / 2 = 그대로 Q3-5. 5장 표준 vs 「내용이 넘치면 다음 장으로」 — 원문은 항목별 처리가 다르고 우선순위가 안 적혀 있음. 1 = 5장 우선(넘치면 강등·삭제) / 2 = 카드 분리 허용(10장 상한) / 3 = 항목별로 다르게

3-7. 한계

• 환산값은 전부 미검증(폭 비율 산술뿐). 검수관 문서 10편 본문 미열람. 「해당 없음」 정정 뒤에도 「없음」 26줄은 낱말 검색 기반.

4장. 광고디렉터 · 메타 카드뉴스 모드 (meta-cardnews)

근거: 매핑 수리본 _감사/v2/02-mapping/MAP-PPT→AD-meta-cardnews-v2.md · 비교 COMPARE-meta-cardnews.md · 실행 테스트 04-tests/TEST-metacn.md. 원본 무수정.

4-1. 한 줄 결론

인스타 카드뉴스와 판(4:5 1080×1350)은 같지만 메타 광고 정책·표시광고법 게이트가 마감 검사에 들어 있고, 글자를 코드가 렌더한다는 점이 다릅니다. 이 모드는 PPT 능력의 큰 수용처(94줄 중 「그대로 13 + 값 바꿔서 30」)이고, 승인 템플릿은 PPT 마감 3칙 값을 이미 만족합니다(4:5 사본으로 통과). 가장 값어치 있는 빈칸은 마감 검사가 판 안쪽을 안 재는 것과 색 계열을 세는 코드가 양쪽 다 없다는 것입니다.

4-2. 지금 갖고 있는 것 (인스타와 다른 점 위주)

4-3. PPT 쪽에서 넣을 수 있는 것 (77묶음 → 수리본 94줄)

빈칸 3: ① 마감 3칙(판 안쪽 여백·라운드·글자 하한) — 마감 검사 7줄에 0개 ② 색 계열을 「세는」 코드 — 프로파일이 「세는 것은 색 개수가 아니라 계열 개수」라 적어 놓고 세는 코드가 양쪽 다 없음 ③ 검사기 양방향 계약 테스트 강제(있으나 문서-코드 괴리가 실제로 났음: KIT.md 가 고쳐진 버그를 「수리 대기」로).

이미 있어서 「없음」이 틀렸던 것: 한글 낱말 줄바꿈 검사 html_text_audit.py · 대비 계산기+테스트 · 테스트 78개 · 누끼 여백 정규화 · 골격 스니펫 · 사진 아귀 검사 · 촬영 조건 3종.

4-4. 실제로 돌려본 결과 (04-tests/TEST-metacn.md)

4-5. 3안 비교

4-6. 사장님이 정하실 것

Q4-1. 어느 안? 1 = ⑴(제 추천 — 템플릿이 이미 마감 값을 만족하므로 검사기만 얹으면 됨, 정책 게이트 유지) / 2 = ⑵ / 3 = ⑶ / 4 = 안 함 Q4-2. 색 계열 세는 코드 — 양쪽 다 없음. 1 = 새로 만듦(hue 계열 수 ≤ 카드 장수) / 2 = 사람 판정 유지 Q4-3. 인스타·메타 카드뉴스 공용 값 층(판 · 여백 하한 · 라운드 토큰) — 3장 Q3-3 과 같은 값으로 갈지: 1 = 같이 / 2 = 따로

4-7. 한계

• 룰·검수관 인벤토리(A4 440행)·흐름 06(1,889행)은 비교에서 대조 못 함. 승인 템플릿 183 vs 카탈로그 103 의 차이 80개가 무엇인지 미확인. 테스트 표본은 템플릿 1장.

5장. 광고디렉터 · 나머지 7모드 + 크몽 갈래 + 공통 (능력 삽입 표만 — 모드 통째 비교는 안 함)

근거: _감사/v2/02-mapping/MAP-PPT→AD-amazon-listing-aplus-brandstory(-v2) · …amazon-store-visualrevision-v2 · …meta-ad-product-video(-v2) · …kmong-common-v2. 각 편의 3단계 검수(03-review/)를 거쳤고, 아래 숫자는 수리본 기준(수리 중인 편은 「v1」 표시).

5-1. 한 줄 결론

아마존 5모드·메타 광고·제품 영상은 「최종 픽셀을 AI 가 굽고 시각 판정은 사람이 한다」는 공통 벽 때문에 PPT 의 HTML 조판·기계 판정 능력이 정면으로 안 들어갑니다. 들어가는 것은 절차·판정 규율(발화 원문 보존·판정 전 의견 금지·양방향 계약 테스트·흡수 4단계)과, 판 크기를 바꾼 값들입니다. 크몽 갈래는 별도 파이프라인이 아니라 인쇄물·상세페이지 모드를 그대로 쓰는 것이라, 2장·1장 결정이 곧 크몽 결정입니다.

5-2. 모드별 판정 요약

5-3. 공통 벽 세 개 (원문)

1. 「시각·가독 항목의 판정 주체 = 사용자 … AI 는 생성 이미지를 열람하지 않음」 — 아마존 3 프로파일 전부, 메타 광고 175줄, 제품 영상 111~114줄 (2026-07-03 지시). ⚠️ 이 벽이 막는 것은 「AI 가 그림을 보고 잘잘못을 판정하는 것」이지 「좌표·크기·색을 계산으로 재는 것」이 아닙니다 — 광고 쪽에 이미 예외가 셋 있습니다(생성 PNG 격자 감사 grid_layout_audit.py 전 모드 공용 · ROI 색 측정 · SKU 확장 레시피). 그래서 아마존 3모드에서 처음 「못 넣음 4」였던 것이 수리 뒤 1(클라이언트 footage 필수 — AI 생성 불가 명문 금지)로 줄었습니다. → 8장 Q8-1 은 「보고 판정」 축만 정하시면 됩니다.
2. 「최종 픽셀은 AI 가 굽는다 — 로컬 HTML/CSS/PIL 합성 금지」 — 스토어·수정 모드. PPT 는 정반대(HTML 로 굽고 기계가 판정).
3. 판이 다르다 — PPT 값은 전부 1600×900/1280×720 슬라이드 분모. 아마존·메타·영상 규격으로 옮기려면 값을 다시 정해야 하고, 「폭 비율 산술」은 실측 반례(1.509배)가 있어 못 씀.

5-4. 그래도 들어가는 것 (모드 공통)

• 발화 원문 축자 보존 · 판정 전 의견 표명 금지 + 정정 기록 · 흡수 4단계 · 도전 슬롯 · 검사기 양방향 계약 테스트 강제 — 전부 절차라 매체 값 없음.
• 크몽 갈래: 의뢰 건 색·폰트를 확정.md 에 사장님 원문과 함께 적는 완료 조건이 이미 있음(흐름/06 37줄) — PPT 「디자인계약」과 같은 것.
• 한글 낱말 줄바꿈: 양쪽이 각자 풀었음(광고 쪽이 렌더 후 실측이라 더 강함).

5-5. 이 장에서 나온 정본 결함 (9장에도 있음)

• meta-ad 완성 표시 vs 실사용 0 / product-video 스텁 vs 12건.
• amazon-aplus.md 66줄 「PNG ≤1024」 vs 356줄 「폐기, 5.2MB·1792px」 같은 파일 안 모순.
• AD-A8-S10 세션 기록의 모드가 실제 작업과 다름.
• Kling 유료 발사기 2개가 import 만으로 과금(9-1).
• 룰/확정-사장님.md(매 턴 주입되는 판정 원장)이 매핑 3편에서 통째로 빠졌다가 검수에서 잡힘 — 조사 결손.

5-6. 사장님이 정하실 것

Q5-1. 아마존·메타 광고·영상 모드는 1 = 절차·규율만 삽입(제 추천 — 벽 3개가 지시 사항이라 그 이상은 8장 결정 뒤에) / 2 = 8장 Q8-1 을 정한 뒤 다시 봄 / 3 = 안 함 Q5-2. 크몽 갈래는 1 = 1장·2장 결정을 그대로 따름(제 추천 — 별도 파이프라인이 아님) / 2 = 따로 봄 Q5-3. meta-ad 프로파일(실사용 0) 1 = 「완성」 표시를 내리고 보류 / 2 = 그대로

5-7. 한계

• 9편 전부 v2 반영 완료. meta-ad·영상은 「없음」 55→3 · 34→2 로 줄었으나 판정 개수는 안 바뀜(못 넣음 사유가 「없어서」가 아니라 대상 부재·판 전용 값·픽셀 판정=사용자 벽이라).
• 스토어 3000×1500 환산값 4자리는 안 쟀습니다.

6장. 웹 파이프라인 2 · 5모드 + 공통 — PPT 에서 넣을 수 있는 것

근거: _감사/v2/02-mapping/MAP-PPT→WEB-*.md(client-build · component-intake-v2 · client-feedback-v2 · maintenance-portfolio-common) + 03-review/REVIEW-MAP-PPT→WEB-*.md 4편. 사장님이 직접 지목한 것: "intake 모드 있잖아, 캡처해서 그거대로 똑같이 만드는 거".

6-1. 한 줄 결론

웹 파이프라인은 검사기·증거 규율·변이 시험에서 PPT 보다 앞서 있어 「그대로」가 적고, 넣을 값이 있는 곳은 레퍼런스를 재는 서식(판독표·비례·마스크), 정본 판정 순위, 은퇴 규칙의 선언 철회, 판정을 다루는 법입니다. 그리고 component-intake 모드는 「원본과 우리 것을 픽셀로 비교한 실물」이 이미 있는데 모드 문서가 그것을 안 가리켜 상시 게이트가 아닙니다.

6-2. 모드별 판정 (수리본 기준)

6-3. 모드별 요지

client-build — 웹 ref-first 는 「레퍼를 어느 방식으로 쓰나」(7분기)까지 있고 「몇 장을 어느 분모로 재나」의 계측 서식(마스크 방향·주인공 비례%·프레임 실루엣·사진 bbox)이 없습니다. PPT 쪽 실측: 그 서식이 없을 때 핀 4장이 분모 오독으로 3~4배 틀렸음. 축은 visualDescription(AI 는 썸네일을 못 보므로 판단이 전부 글 설명에서 남) — PPT 판독표·문법카드·원자표가 같은 문제의 다른 이름. 마감 검사 강도는 반대(PPT 하드 차단 vs 웹 WCAG 「시안 보고로 하향」). 검수에서 「없음」 7줄이 뒤집힘(판정 원문 보존 = taste-log.md 「오너의 말 원문 그대로」 · 3연속 금지 · 궁합 제약 · 영상 임베드 규격 등이 이미 있음).

component-intake — 캡처 → 픽셀 비교 → 렌더 증명 → 3패널 검수 실물(parity/ 13항목 · 자가검수 50/50 · 픽셀차 최대 0.022)이 있는데 모드 문서 434줄이 한 번도 안 가리킴. snippet-parity-check.py 는 웹 자체 감사가 이미 「죽은 배선」으로 적발. 판독 서식·적대적 대조·3회 상한이 GOAL-taxonomy-v2.md 에 설계돼 있으나 역시 배선 없음. 그래서 PPT 능력의 값어치는 「없는 것을 넣는다」가 아니라 「한 번 한 것을 상시 게이트로 굳힌다」. 검수 기본값이 정반대(웹 「반례 없으면 통과」 vs PPT 「기본 불합격」) → 8장 14번.

client-feedback — 「라우터」라 디자인 지식은 못 받고, 받는 12묶음은 전부 「판정을 다루는 법」(판정 원문 축자 보존 · 자가검수 축 · 3회 반복 승격 · 재시도 상한). 받는 쪽이 이미 앞선 것 2(A10 RED/GREEN 증거 6파일 · 소유권 경계). 조사 결손 1건(리뷰 허브 문서 194줄 미독)은 보충 인벤토리로 닫음.

maintenance · portfolio · 공통 — maintenance 는 화면을 안 만들어 시각 규칙은 원리상 안 걸리고 검사기·증거·변이 규율만 걸림. 값 큰 자리 3: ① PPT 「마감 게이트 BLOCK/PASS 쌍 계약 테스트」 → 웹 변이 시험 5종은 「막혀야 할 것」만 재고 「통과해야 할 것」은 흩어져 있음 ② PPT 「정본 판정 순위」 → 웹은 중복만 금지하고 충돌 승자를 안 정해 실측 오진(rc=2) ③ PPT 「은퇴 파일에 선언 철회」 → 웹 「변이 시험은 지워진 규칙을 못 잡는다」 자백(8차에 지운 규칙이 15회차 초록불). portfolio 고유 규칙은 6행뿐. 검수에서 「없음」 7 뒤집힘(이모지 금지·차트 금지·컨택트시트·폰트 조달·브랜드 토큰이 이미 있음).

6-4. 웹 쪽 결함 (9장에도)

• 검수관이 초록불을 내면서 안 도는 것(Stage5 파일 없음 5 · Stage6 파서 부재 4) · 6-build 「검사 있음≠돎」 6.
• component-intake 배선 부재(snippet-parity-check.py·finalize-intake.py 모드 문서 0회) · CI-1 86 전승인 vs CI-2 41 거절(설명은 verdicts.json note 에 사장님 원문 «50개 승인은 모두 승인할께»).
• 스니펫 지도 CSV 287 vs 문서 266·183 · 2-design-system.md 「10 mandatory_reads」 실물 20 · 와이어 3~5안 vs 4안 어긋남.
• codex 안내 블록 두 벌 복제(5-images.md = 8-imagelab.md), 낡은 stdin 포인터 두 벌.

6-5. 사장님이 정하실 것

Q6-1. component-intake 에 픽셀 비교·자가검수를 상시 게이트로 배선 — 1 = 배선(제 추천 — 실물이 이미 있음) / 2 = 그대로 Q6-2. 계측 서식(마스크·비례·bbox)을 웹 ref-first 에 추가 — 1 = 추가 / 2 = 안 함 Q6-3. 정본 판정 순위·은퇴 선언 철회·BLOCK/PASS 쌍 계약을 maintenance 에 — 1 = 셋 다 / 2 = 골라서(적어 주세요) / 3 = 안 함 Q6-4. 검수 기본값(8장 14번) — 8장에서 답하시면 됩니다.

6-6. 한계

• maintenance v2 는 「부분」 115줄 중 12줄만 원본 재확인. 웹 원본을 안 연 채 인벤토리로만 판정한 줄이 많았고(mpc 편은 원본 0건), 3단계 검수가 그 부분을 잡았습니다.

7장. 광고디렉터 ↔ 웹 파이프라인 2 — 서로 넣을 것

근거: _감사/v2/02-mapping/MAP-AD→WEB-G1~G4(.md / -v2) · MAP-WEB→AD-G1·G2a·G2b·G3·G4 + 03-review/REVIEW-MAP-AD→WEB-*·REVIEW-MAP-WEB→AD-*. 3단계 검수 8편 전부 완료, 수리본(v2) 8편 전부 반영.

7-1. 한 줄 결론

두 파이프라인은 같은 창고(0-공통-도메인)에서 게이트 키트·codex 발사 규약·쉬운 말 게이트를 각자 설치한 자매라, 겹치는 것은 옮길 대상이 아닙니다. 실제로 오가는 것은 방향이 뚜렷합니다. 광고 → 웹: 서브에이전트 발사 게이트(지시문 칸 게이트)·지시문 필수 3줄·UTF-8 출력 정본·쉬운 말 게이트·맥락 0 회귀 하네스·AI 인물 공시·레퍼 5장/5.2MB 상한. 킬리스트·Subtraction pass 는 이미 이식돼 있음. 웹 → 광고: 「초록불은 증거가 아니다」 계열 중 광고에 없는 것만(검수 확인: 증거 규칙 7 중 4·판정 규율은 광고에 이미 있음) — sha256 검수 신선도·preflight 에 pass 없음·변이 하네스(광고 0건)·검수관 네트워크 차단(부분)·한글 조판·모션 이징 토큰·레터박스 탐지기.

7-2. 광고 → 웹 (4묶음)

7-3. 웹 → 광고 (5묶음, 받는 모드 = 11 프로파일 + 크몽 + 공통)

7-4. 이 장에서 사장님이 정하실 것

Q7-1. 웹 → 광고 「변이 하네스 + 검수 신선도(sha256) + preflight 에 pass 없음」 — 1 = 광고 공통에 넣음(제 추천 — 광고에 변이 하네스가 통째로 없고, 미해결 F-번호 9건이 그 부재로 설명됨. 증거 규칙·판정 규율은 검수 결과 광고에 이미 있어 뺌) / 2 = 안 넣음 Q7-2. 광고 → 웹 「서브에이전트 발사 게이트 + 지시문 필수 3줄」 — 1 = 넣음(웹에 지시문 칸 게이트 없음) / 2 = 안 넣음 Q7-3. snippet_skeletons.py 다리 — 1 = 정식 배선(상세페이지 골격 메뉴 미완과 같은 뿌리) / 2 = 그대로 Q7-4. 웹의 낡은 codex 포인터 두 벌(광고 2026-07-29 폐기본) — 1 = 광고 규약으로 갱신 / 2 = 그대로

7-5. 한계

• 첫 판은 원본을 안 연 채 인벤토리로만 판정한 편이 많아 「없음」 오판이 검수에서 12~31% 잡혔고, 수리본은 원본(광고 12파일·웹 4인벤토리 등)을 직접 열어 고쳤습니다. 그래도 「부분」 판정 중 아직 아무도 안 본 줄이 남아 있습니다(웹→광고 G4 45줄 · G1 82줄 일부).
• 한 칸 두 판정 병기는 수리본에서 전부 갈랐습니다.

8장. 두 시스템이 같은 문제에 반대 결론을 낸 자리 (사장님이 정하실 것)

이 장은 「넣자/말자」가 아니라 어느 쪽이 기본값인지 사장님이 정해야 두 파이프라인 정합이 성립하는 자리만 모았습니다. 각 항목의 원문 위치는 해당 매핑 파일(_감사/v2/02-mapping/)에 있고, 3단계 검수가 원문을 재확인한 것은 「확인」 표시. 안 정하면 정합 시 한쪽이 반드시 깨집니다.

이 표를 읽는 법

• 1·2·9 는 같은 뿌리(2026-07-03 「AI 는 생성 이미지를 안 본다」)입니다. 이 지시가 광고에는 있고 웹·PPT 에는 없습니다. 이 하나를 정하면 세 줄이 같이 정해집니다.
• 4·8 은 사장님 디렉션끼리 부딪히는 자리라 규칙 우선순위로 못 풉니다.
• 10·12 는 「화면 습관 vs 종이 습관」 축입니다 — 인쇄물은 안 채우는 규칙, 웹은 채우고 맞추는 규칙. 매체가 다르면 둘 다 맞을 수 있어 「공통 기본값」이 아니라 「매체별로 갈라 둔다」가 답일 수 있습니다.
• 5·6·7 은 「막는 강도」의 문제입니다. PPT 가 가장 세고(게이트로만 막힘·3회 승격), 광고는 모드별로 다르고(영상은 알림만, 상세페이지는 차단), 웹은 중간에서 완화 선례가 있습니다.

사장님이 정하실 것

Q8-1. 생성물 시각 판정(1·2·9 묶음) — 1 = 광고 쪽 유지(사람이 본다, 기계는 숫자만) 을 세 시스템 공통 기본값으로 / 2 = 웹 쪽(AI 검수관이 본다) 을 공통으로 / 3 = 시스템마다 다르게 둠(정합 때 이 축은 안 옮김) Q8-2. 법정 표현(4) — 1 = 차단 / 2 = 쓰고 보고 / 3 = 플랫폼 금지어만 차단, 나머지는 보고 Q8-3. 판정 환류(5) — 1 = 광고식(confirm 뒤 저장) 을 공통으로 / 2 = PPT 식(바로 쌓고 3회면 검사기로) / 3 = confirm 은 유지하되 3회 승격 카운터만 추가(제 추천) Q8-4. 넘침 처리(6) — 3장 Q3-5 와 같음 Q8-5. 검사기 강도(7) — 1 = 시스템마다 그대로 / 2 = 「FAIL 이면 차단」을 공통으로 / 3 = 「알림 + 사람 확인」을 공통으로 Q8-6. 질문 툴(8) — 1 = 질문지 툴 사용 을 공통으로 / 2 = 평문 / 3 = 시스템마다 그대로 Q8-7. 형태·등높이(10·12) — 1 = 매체별로 갈라 둠(제 추천) / 2 = 웹 쪽 하한을 공통으로 / 3 = 광고 쪽 자유를 공통으로 Q8-8. 모션 엔진(16) — 1 = 웹 쪽(GSAP 비권장·바닐라 IO)을 공통으로 / 2 = 매체별로 갈라 둠 / 3 = 광고 쪽 GSAP 허용을 공통으로

9장. 파이프라인 자체의 결함 (원본은 안 고쳤습니다 — 고칠지는 사장님이 정하십니다)

전부 실물(파일:줄)로 확인된 것만 적었습니다. 「조사 결손」(우리 인벤토리가 빠뜨린 것)은 따로 표시. 최종본에서 파일:줄을 한 번 더 재확인합니다.

9-1. 먼저 볼 것 (돈·안전에 걸리는 것)

• 🔴 scripts/video-compose-pipeline/regen_319.py 49~54줄 · video_gen.py 42~47줄 — Kling 유료 영상 발사가 모듈 최상위에 있어 import 만 해도 과금됩니다(3단계 검수 실측). 같은 폴더 11개 전부 __main__ 블록 없음, 유료 발사기 4개(그중 video_gen.py 는 인자 파싱이 발사보다 앞서 있어 인자 없이 import 하면 그 자리에서 멈추므로 「무조건」은 아니고, 나머지 3개는 무조건). 전역 규칙(「돈 나가는 호출은 __main__ 아래」) 위반.
• 🔴 검사기가 초록불을 내면서 실제로 안 도는 것: 웹 검수관 Stage5 파일 없음 오류 5개·Stage6 파서 부재 4개 · PPT 검사기 3개(verify2.py·verify_DOC1.py·D3_contrast.py) 종료코드 없음 · 웹 6-build 「검사 있음≠돎」 6건.
• 🔴 meta-ad 프로파일 「완성」 표시인데 실사용 0건 / product-video 12건 실사용인데 프로파일은 스텁.

9-2. 시스템별 목록

광고디렉터

• templates/profiles/meta-ad.md:17 status fully-pinned 인데 실사용 세션 0건(A8 39세션 전수) · product-video.md 12건 실재인데 engine-ready-stub(presets 비어 있음)
• scripts/video-compose-pipeline/ 11개가 __main__ 없이 최상위 실행, 그중 kling 유료 발사 4개(batch_gen.py·regen_319.py·regen_frontref.py·video_gen.py) — import 만으로 과금 구조 · 세션 절대경로 상수
• templates/KIT.md:90 「exit 0 으로 버림·수리 대기」 낡음 — scripts/kit_apply.py:120-138 에 이미 수리 코드(sys.exit(2))
• 프로파일 5개 공통 스크립트 줄번호 오기(실제 527·209) · commerce-detail-page.md 게이트 「25종」 vs 실제 24(:480 자백)
• scripts/detail_page_audit.py W2 docstring 「경고」 vs 코드 출력 「(경고 아님)」 드리프트(테스트 C 실측)
• templates/amazon-aplus.md:66 «PNG ≤1024» vs :356 «폐기, 5.2MB·1792px» 같은 파일 안 어긋남 · amazon-listing-image-production-recipe.md:380 「§13」 부재(실제 §12) · :359 4종 vs :269 5종
• reviewers/*.md 에 print-collateral 0회(굽지 않는 타입인데 codex 컷 전제 체크리스트) · feedback/ 29건 전부 2026-05 식물조명 seed, 인쇄·카드뉴스 0건(4개월 정지)
• cardnews_compositor.py:19 ROLES 가 insta 5역할과 불일치 · 흐름/06:1419 조판기 meta 전용 → insta 는 조판기 배선 없음 · 실물 기계 검수 = _machine-audit.json 파일존재·1080×1350·md5 셋뿐
• templates/cardnews-gallery/references/thumbs/ 2,211 에 pin__·meta__ 두 계열 섞임 · 자산 폴더 3개(4,066장) 규약 문서 없음
• AD-A8-S10 output_type 기록이 실제 작업(visual-revision)과 다름(모드 경계 흐림)
• 자동화 크롬 CDP 포트를 스크립트 8개가 각자 하드코딩(정본 모듈 없음) — 2026-09-03 포트 이사를 겪은 머신이라 다음 이사 때 또 죽음(광고 CLAUDE.md 64·79줄 「10종」 표기도 실물 11과 어긋남)
• 흐름/07-검수완료.md:60 insta 게이트 — 인벤토리(A2) 누락(원본 결함 아님, 조사 결손)
• scripts/snippet_skeletons.py 34줄 — 웹 파이프라인 폴더 경로를 하드코딩한 채 두 시스템을 잇는 유일한 다리인데, 호출처가 README·흐름·룰·templates 어디에도 없음(배선 안 됨). 골격 메뉴 미완(1장 빈칸 1번)과 같은 뿌리
• feedback/ 전체가 2026-05-31 이후 정지 — C-handling.md·taste-log.md·stage2/4/5/7 defects 전부 5월, sessions/·stage0·1·3 빈 폴더(웹 쪽은 살아 있음: taste-log 09-04·stage5 09-05)

웹 파이프라인 2

• 검수관이 초록불 내면서 안 돎: Stage5 치명 5개 FileNotFoundError · Stage6 R35/38/52/63 파서 부재 · Stage3 R20 무측정(W-W1b)
• stages/2-빌드/6-build.md 「검사 있음 ≠ 돎」 6건 · WCAG AA 「시안 보고로 하향」 · check-vh-cap 비소급 선례
• components/data/C-00_SNIPPET_MAP.csv 실물 287행/295KB vs 3-site-plan.md 266·183·276KB 셋 다 다름 · :513 «7 enum» 실제 8
• 2-design-system.md:116·:204 «10 mandatory_reads» 실물 20
• feedback/stage6:453 이 부르는 scripts/check-build-order-sync.py 부재 · 어긋나 보이는 룰 쌍 2(picture 강제 vs 폐기 — :443 둘째 갈래로 동시 준수 가능 / GSAP 폐기 vs 고쳐 쓰기, 선후 못 가림) · CDP 포트 9222 낡음(stage6:295·:465) · 만족 불가 룰 2·미수리 「고칠 방향」 3
• stages/0-진입전/modes/component-intake.md 434줄에 snippet-parity-check.py·finalize-intake.py 0회(배선 없음) · parity/·self-review-report 실재하나 모드 문서가 안 가리킴 · CI-1 86 전승인 vs CI-2 41 거절 설명 없음
• reviewers/REVIEWER_STAGE_6_critical.md 낱개 CR 1개(도구마다 줄 수 다름) · REVIEWER_STAGE_6_build.md +6줄 · _critical.md +21~22줄 밀림(인벤토리가 잡음)
• C-handling.md:113 이 가리키는 feedback/stage6-build/inspiration.md 부재 · fixed_look 열 287행 중 3행만 · round2-args.json = .min.json 동일
• docs/review-hub/README.md §8 검사기 3개 누락 · §4.6 dead-ref RED/GREEN 증거 소멸(자백) · 더 새 로그 _작업보고/_verify/a10-a11-green-v5·v5b·v6 미참조
• W-W5b-SP-12 「생성자 자기채점 금지」 집행자(Codex 리뷰) 은퇴 → 빈자리
• stages/2-빌드/5-images.md 703~716줄과 stages/3-변환후/8-imagelab.md 350~363줄이 14줄 중 13줄 바이트 동일로 복제(Hardening·Windows codex CLI·Prompting 블록) — 한쪽만 고치면 실행 단계 사본이 낡음. 그 안의 「멀티라인 프롬프트 = 파일 + 한 줄 래퍼」 포인터 두 벌은 광고가 2026-07-29 폐기한 방식을 가리킴(광고 AD-A3b-209)
• stages/0-진입전/modes/client-build.md 51~52줄 «전 구간 사장님 손이 안 간다» vs 8-imagelab.md 344~348줄 «One 사장님 육안 확인» — 웹 안에서도 시각 판정 주체가 갈림(8장 1번과 같은 축)
• stages/1-사전/·2-빌드/·3-변환후/ 를 한 검수관 문서가 안 나눠 부르고, snippet-parity-check.py 는 웹 자체 감사(audit-G1-scripts-20260829.md:42)가 이미 「죽은 배선 5개」로 적발

PPT 계열

• 260827_SVG신규성_테스트/surgery/verify2.py·verify_DOC1.py·D3_contrast.py sys.exit 0건 → 게이트 구실 못 함 · D3_contrast.py MARGIN=0.3 vs D3_팔레트.md §2 0.6
• deck-content-prep check_layout.py:29·build_deck.py:25 web-ppt 절대경로 · visual-direction.md:49 0. FONTS PACK 의존 → 단독으로 안 돎(키트 정규화 대상)
• svg-motion SKILL «부품 10종» 실제 11 · check_slides.py 는 slide_lint 실패를 :240 에서 상위로 전파(문서 미기재였음)
• 사장님 결정 대기 건이 문서에만: logs_motion/AL1.md:134 팔레트 뒤집기 · DK1.md 14줄 중단
• lieflat_charts = 서드파티 PolyForm Noncommercial → 배포 키트에 못 넣음
• 이미지 자산 4,066장·references/ 등은 광고 쪽; PPT 은행(파란펭귄 390·핀 128)은 배포 금지 결정(D)

9-3. 정정 — 흡수 실행 중 실물과 다시 대조해 고친 것 (2026-09-07)

• 「상세페이지 게이트 구멍 3종」 → 2종. 「글자 없는 도형이 판 밖」은 L1 이 전 요소를 재므로 이미 잡고 있었다(흡수 2호에서 확인). 두 구멍(가려짐·4모서리)은 L4·W7 로 막음.
• 「골격 카탈로그: 카페24 에 그대로 얹을 스니펫이 하나도 없다」 → 391개 전량 실측 결과 282개가 JS 를 꺼도 산다. 앞 10개(React 계열)만 본 착시(흡수 4호).
• 「cardnews_compositor.py ROLES 가 insta 5역할과 불일치」 → 결함이 아니라 문서 공백. 조판기는 meta 전용이고 insta 는 cardnews-gallery/executable/ 템플릿으로 조판한다 — 그 사실을 어느 문서도 안 적어 두었을 뿐(흡수 7호에서 둘 다 명시).
• 「자동화 크롬 CDP 포트를 스크립트 8개가 하드코딩」 → 코드로 포트를 쓰는 것은 1개(gallery_collect_pinterest.py)뿐이고 나머지 7개는 docstring 의 「9322 안 씀」 문장이었다. 그 1개를 신설 scripts/_cdp_port.py(정본 모듈)로 돌렸다.
• 「PPT 검사기 3개(verify2.py·verify_DOC1.py·D3_contrast.py) 종료코드 없음」 → 세 파일은 PPT 스킬이 아니라 실험 폴더(260827_SVG신규성_테스트/surgery/)에만 있고 어느 스킬도 부르지 않는다. 스킬 안 svg-motion-graphics/scripts/contrast.py 는 margin 을 인자로 받는다(0.3 은 예시값). 흡수 대상 아님으로 정리.
• 「gallery_contrast.py 임계값 3:1 은 상세페이지 전용」(2장) → 그 스크립트는 임계값 판정기가 아니라 글자색 자동 선택기다. 임계값 3:1 은 detail_page_audit.py B1 의 것.
• 「component-intake CI-1 86 전승인 vs CI-2 41 거절 설명 없음」 → 실물 대조 결과 방향이 반대: 이른 라운드(verdicts-round1-2026-07-22.json) = 41 거절 + 9 승인, 나중 라운드(verdicts.json) = 86 전량 승인(사장님 원문 «50개 승인은 모두 승인할께»). 문서에 「CI-1/CI-2」 표기 자체가 없어 편집 보류(웹 결함 수정 에이전트 2026-09-07).

10장. 어떻게 조사했고, 무엇을 못 봤나

10-1. 네 층으로 검수했습니다

10-2. 정직하게 남은 한계

• 인용 검사기의 사각: 인용의 앞 20자만 기계로 대조했습니다. 「OK」는 「앞부분이 원문에 있다」이지 「인용 전체가 원문 그대로」가 아닙니다. 타자검수 중 몇 편은 검수관이 인용 전체를 따로 대조했습니다(A6c 582/583 일치).
• 「없음」 판정: 3단계 검수 뒤 수리본에서 「없음」 줄을 다시 찾았지만, 낱말 검색 기반이지 전문 통독이 아닙니다. 「부분」 판정 중 검수·수리 모두 안 본 줄(웹→광고 G4 45줄 등)은 같은 비율의 오판이 남아 있을 수 있습니다.
• 「좋아지는 것」 근거: PPT 작업 기록 5편은 검수 통과했으나 매핑 대부분이 그 이전 판을 「검수 전」 표기로 썼습니다. 근거 ID 는 실재 확인됐고 내용 대조는 표본입니다.
• 안 돌린 테스트 3건: 상세페이지 B(PPT 조립기 감사기 — 같은 계열이 다른 모드에서 실행 전 예외로 죽는 것을 확인) · 인쇄물 T3(인쇄용 PDF 관문 — 실물 경로 미확정) · 메타 카드뉴스 2(조판기 끝단 — 원본 폴더 안에 산출물이 생겨서).
• 자산 본문 미열람: 이미지 4,066장·템플릿 HTML 183장·스니펫 269개는 개수·존재만 셌습니다.
• PPT 계열이 4:5·세로 지면을 만들 수 있는지는 확인 안 했습니다(재개설 안의 전제).
• 원본은 한 글자도 안 고쳤습니다. 결함은 9장에 목록만 있습니다. 다만 조사 중 다른 세션이 원본 일부를 고친 흔적(2026-09-06 새벽·10:57 수정 시각)이 있어 일부 줄 번호 드리프트는 그 탓일 수 있습니다.
• 세션 한도: 서브에이전트가 두 번 일괄 사망했습니다. 산출물은 「끝날 때마다 파일에 붙여라」 규칙 덕에 전부 살아 있었고 이어받았습니다.

10-2-1. 검수관끼리 어긋난 것 2건 — 원본이 이겼습니다

• 광고 「형태 규칙 폐기」의 범위: 한 검수관은 「위치 규칙 1개만 폐기」, 다른 검수관은 「형태 전반 폐기」. 원문(룰/광고-소재-파운데이션.md 54~56줄)을 직접 열어 보니 §6 은 형태 전반을 폐기하고, 정렬·행간은 §7 여백 판정의 별개 조건이었습니다 → 후자가 맞음. 먼저 반영했던 수정을 다시 고쳤습니다.
• 웹 component-intake 판정 파일(verdicts.json) 유무: 한 검수관은 「86행 note 까지 읽음」, 다른 검수관은 「실제로 없다」. 디스크에 있습니다 → 전자가 맞음. 결함 목록에서 뺐습니다.
• 교훈: 검수관 판정도 사람 판정처럼 틀립니다. 두 판정이 어긋나면 원본을 직접 여는 것 외에 방법이 없고, 이 조사는 그렇게 했습니다.

10-3. 숫자로 본 규모 (참고)

• 인벤토리 40편 / 타자검수 40편 / 인벤토리 수리본 20편 이상 / 매핑 23편(약 3,400줄 판정) / 모드 비교 4편 / 매핑 검수 23편 / 매핑 수리본 23편 / 실행 테스트 8건.
• 서브에이전트 약 90회 발사, 40턴 한도 재개 약 30회, 세션 한도 사망 2회(27개).

10-4. 이 조사에서 고쳐야 할 것(조사 도구 자체)

• 매핑 지시문에 「받는 쪽 스크립트 인벤토리를 반드시 연다」를 처음부터 넣었어야 했습니다(중간에 보정).
• 웹 「실제 수요」 근거 파일을 처음에 잘못 지정했습니다(설계 문서 요약을 사고 원장으로 오인 → 중간에 defects 인벤토리로 보정).
• 프로파일 수를 12 로 적었으나 11 입니다(색인 파일을 셈).

11장. 다음 단계 제안 (사장님 번호 답 뒤에 바로 시작할 수 있게)

11-1. 순서 (제 제안)

1. 사장님 번호 답 수집 — 1~5장 각 모드 Q, 8장 Q8-1~7. 답이 없는 항목은 「제 추천」 값으로 진행하되 그 사실을 적어 둡니다.
2. 흡수 실행(1단계) — 답에 따라 「그대로/값 바꿔서」 묶음을 그 자리에 넣습니다. 원칙: 원본 파이프라인을 고칠 때는 해당 프로젝트의 유지보수 모드를 타고(웹 = maintenance 모드 + check-doc-chain.py, 광고 = 룰 문서 + 계약 테스트), 넣은 것마다 계약 테스트를 같이 둡니다. 9장 결함 중 사장님이 「고친다」로 답한 것도 여기서.
3. share-pack 보강 — 이번 건에서 드러난 빈칸: 라이선스 템플릿(PolyForm Internal Use 1.0.0) · 원칙 검수표 · 첫 작업 워크스루 · 막혔을 때 절차 · 베타테스터 피드백 양식 · 선택 부품 분기(Affinity · codex 로그인 · 스톡 API 키) · Codex CLI / Gemini CLI / Claude Desktop 어댑터(Agent Skills 표준: 폴더명 = name 소문자-하이픈, description 필수) · 원장 SHA 열 · 조건 분기 안내문.
4. 브로슈어 키트 패키징 — 2장 2-7 구성대로. 정규화 대상: PPT 계열의 절대경로(web-ppt·0. FONTS PACK) 풀기, 폰트팩·이미지 은행 제외, 스톡 키는 받는 쪽 입력.
5. PPT 규칙 키트 — 다른 세션의 PPT 업데이트가 끝난 뒤. 은행(파란펭귄 390·핀 128)은 배포 금지, 규칙·게이트·판정 방식만.
6. intake — 이 조사에서 나온 교훈(「없음」 오판 뿌리 · 세션 한도 · 검수 4층)을 창고에 넣을지는 사장님이 「intake」라고 말씀하실 때만.

11-2. 흡수 실행 때 지킬 것 (이 조사에서 배운 것)

• 「받는 쪽에 없다」를 적기 전에 스크립트 인벤토리를 반드시 연다 — 매핑 오판의 뿌리였습니다.
• 값을 옮길 때 폭 비율 산술 금지 — 실측 반례(1.509배). 판 크기·여백·글자 하한은 매체별 값 층으로.
• PPT 검사기를 광고 지면에 쓰려면 캔버스 값 층(카드뉴스·상세페이지) + 글자 하한 mm/pt 층(인쇄물) + 무대 표식(#stage·잉크 표식)이 필요합니다. 마감 검사기는 2줄, 무대 검사기는 템플릿 103~183장.
• 유료 발사 코드는 손대기 전에 __main__ 아래로 — Kling 2개가 import 만으로 과금되는 상태입니다.
• 원본 수정은 한 파일씩, 계약 테스트 동반, 커밋은 사장님 말씀 때만.

11-3. 이 보고서 뒤에 남는 것

• 매핑 검수가 안 끝난 편(광고↔웹 8편 중 검수 진행분)은 결과가 오면 7장 표를 갱신합니다.
• 인벤토리 미세 수리는 끝났습니다(W-W1b 인용 4행 · W-W5 ID 중복 26개).
• 「값 바꿔서」의 실값(인쇄 mm·pt · 카드 4:5 · 아마존 규격)은 흡수 실행 때 사장님 값으로 채웁니다.

12장. 웹 파이프라인 2 — 속도·최적화 (사장님 추가 요청, 2026-09-07)

사장님이 물으신 「웹 파이프라인 최적화·속도 증가」에 대한 답입니다. 원본 파이프라인 폴더 안의 기록·코드를 읽어서 낸 것이고, 파이프라인을 실제로 돌려 재지는 않았습니다(원본 수정 금지·유료 실행 금지). 근거 전문 = C:/Users/outaekPC/Desktop/Cowork/260905_배포패키징_이혜진/_감사/v2/05-web-speed/WEB-속도-최적화-조사.md.

「속도」는 세 가지 뜻이 있어서 셋으로 나눠 봤습니다.

12-1. 파이프라인이 도는 속도 — 어디서 시간이 새나

예시로 먼저. 2026-08-05 기록에서, 시안 HTML 한 장(52KB)을 검수하는 데 검수관을 12번 불렀고 토큰 약 300만·검수관 가동 311분을 썼습니다. 스크린샷 부산물이 466장(453MB). 그중 한 라운드는 「문서의 한 줄이 옛날 값」 하나를 잡는 데 90만 토큰을 썼습니다.

같은 일을 두 방법으로 잰 대조가 있습니다.

이유가 기록에 있습니다. 검수관은 맥락 없는 새 세션이라 매 라운드 필독 문서를 처음부터 다시 읽습니다. 단계 문서가 요구하는 필독은 합쳐서 165편이고, 한 세션이 읽은 글 분량의 60%가 「이미 읽은 파일을 또 읽은 것」이었습니다(사이트플랜 문서 21회).

이미 고쳐진 것. 검수관 재호출 상한 3회가 코드로 들어갔고(2026-07-30 사고 = 4라운드 250만 토큰 뒤에 생김), 기계 검사 통합 실행기(preflight, 36종·약 2분)가 도입돼 검수관이 손으로 재던 것의 상당 부분을 대신합니다. Stage 5·6 검수관은 2명 동시 파견으로 바뀌었습니다.

아직 남은 것. Stage 6 차단조건 33개 중 27개는 「기계가 참·거짓을 못 내는」 문장이라 지금도 검수관이 읽어야 합니다. 파이프라인 문서 스스로 「통과했다」가 아니라 「안 봤다」로 읽어야 한다 고 적어 뒀습니다.

⚠️ 위 300만 토큰은 preflight 도입 전(2026-08-05) 값입니다. 도입 뒤 실측 기록은 없습니다. 「지금도 300만이 든다」로 읽으시면 안 되고, 「지금 얼마나 드는지는 아무도 안 쟀다」가 정확합니다.

12-2. 만들어진 사이트의 속도 — 손님이 느끼는 것

• 측정기가 있고 실제로 막습니다. LCP(첫 화면이 다 뜨는 시간, 2.5초 이하면 좋음)·CLS(로딩 중 덜컹거림, 0.1 이하면 좋음)를 재서 넘으면 차단.
• 8개 빌드 전부 통과. LCP 144~620ms(0.15~0.6초), CLS 0~0.084. 한 번 CLS 0.184 로 막힌 뒤 재실행에서 0 으로 내려간 기록도 있습니다.
• 그러나 세 가지 구멍. 1. 위 값은 전부 내 컴퓨터에서 파일로 연 화면입니다. 실제 서버·인터넷 속도가 안 들어갑니다. 배포 주소에서 잰 기록 = 0건. 2. Lighthouse(구글 종합 점수) 구현 0건. 문서가 목표(성능 90 이상 등)만 적고 「사람이 재서 붙여라, 못 쟀으면 미측정이라 써라」 로 넘겼습니다. 이미지 장당 500KB 상한도 「Lighthouse 로 확인」이라 적혀 있어 지금 아무도 안 막습니다. 3. INP(누른 뒤 반응속도)는 사람이 눌러야 나오는 값이라 8개 빌드 전부 미측정(사유는 기록됨).
• 이미지 최적화는 자동입니다(PNG/JPG → WebP, 히어로만 AVIF 추가). 문서가 스스로 적은 구멍: 카카오·페북 공유 이미지(OG)를 WebP 로 바꾸면 안 뜨는데 제외 목록이 없음(수동 복구) · Next.js 정적 빌드 경로는 안 바꿈 · 결과 리포트 파일을 안 남김.
• 측정이 흔들린 실측. 컴퓨터가 바쁠 때 LCP 가 안 잡혀 멀쩡한 빌드가 막힌 적이 있습니다(같은 입력이 88초 → 266초). 지금은 「못 잼」 칸으로 따로 보내는 것으로 완화.

12-3. 도구 자체의 낭비

12-4. 개선 후보 12개 — 결정 아님, 고르실 재료

각 항목 = 무엇을 / 안 하면 어떻게 되나. 근거 파일:줄은 위 조사 원문에 있습니다.

제 추천 순서 = 6(덮어쓰기 위험 제거, 반나절) → 12(반영 여부 표, 후보 중 이미 된 것 걸러냄) → 2(Lighthouse) → 1(27개 조건 갈라내기). 이유: 6은 돈·클라 자료에 걸리고, 12를 먼저 닫아야 나머지 후보 중 이미 구현된 것을 두 번 안 만듭니다.

Q12-1. 웹 속도·최적화 — 어디부터 손댈까요? — 1 = 위 추천 순서(6 → 12 → 2 → 1) / 2 = 사이트 속도(2·3·4·5)부터 / 3 = 파이프라인 토큰(1·9·11)부터 / 4 = 이번 배포 건 끝난 뒤로 미룸 Q12-2. 「지금 실제로 몇 토큰이 드는지」 한 벌 재 볼까요? — 1 = 다음 실클라 시안 1건에서 시간·토큰을 기록해 이 장에 붙임(추천, 비용 0) / 2 = 안 잼 Q12-3. 이 장의 후보를 9장 결함 목록과 합쳐 한 표로 관리할까요? — 1 = 합친다(추천) / 2 = 따로 둔다

12-5. 못 본 것

• 작업패키지 10장 중 7장(A2·B1·B5·B6·B8·W2-B6 등)은 안 열었습니다. 그래서 후보 12개 중 일부는 이미 구현돼 있을 수 있습니다 — 후보 12 를 먼저 닫자는 이유입니다.
• Stage 7 이후(Next.js 변환~배포)의 시간·토큰은 어느 문서도 안 쟀습니다.
• 창고 쪽 성능 문서 2편은 이름만 확인하고 안 열었습니다(범위가 파이프라인 폴더 안).

12-6. 실측 추가 (2026-09-07) — 주담교회 실클라 빌드를 세션 기록에서 되짚어 잼

사장님 15번 답(「다음 실클라에서 시간·토큰을 재라, 주담교회를 추적할 수 있으면 그걸로」)에 따라, 새 세션을 열지 않고 이미 남아 있는 기록으로 쟀습니다. 재료 = 빌드를 돌린 세션 2개의 응답마다 붙은 사용량 + 그 세션이 띄운 서브에이전트 기록 96개 + 빌드 폴더의 단계 도장 파일 120개. 표 전체·방법·주의 = C:/Users/outaekPC/Desktop/Cowork/260905_배포패키징_이혜진/_감사/v2/05-web-speed/JDCHURCH-실측.md (다시 재는 스크립트 같은 폴더).

어디서 시간이 갔나 1. 시안 마무리(단계 6 재작업, 도장 49개) + Next.js 변환 시작 구간이 가장 큼 — 37시간, 메인 $794, 사장님 발화 46회. 단계 6 도장이 시안 3장 합쳐 49번 찍혔다는 것은 사장님 검수 → 수정 → 재검사가 그만큼 반복됐다는 뜻. 단계 7 이후는 08-05 진단서가 「범위 밖」이라 한 번도 안 쟀던 곳. 2. 브리프·리서치(단계 0) 재작업 — 도장 31개, 18.7시간, $265. 단계 0 완료 검사를 31번 다시 돌렸다는 뜻. 3. 제작 서브에이전트가 오래 돈다 — 이미지(단계 5) 10개 1,113분 · 빌드(단계 6) 6개 1,512분. 검수관 23회는 합쳐 3시간 남짓. 4. 캐시 읽기가 새 입력의 30배 — 같은 맥락을 계속 다시 읽는 구조. 단가 1/10 이라 비용은 버텼지만, 12-4 후보 9(필독 줄이기)가 여기 걸린다.

08-05 진단서와 비교 — 그때는 시안 1장의 단계 6 검수에 검수관 12회·300만 토큰. 이번엔 시안 3장의 단계 6 구간에 검수관 1회 + 제작 서브 6개(새 입력 21M·출력 0.4M). 검수관 호출은 확실히 줄었고(기계 검사 36종 도입 효과), 대신 제작 서브의 가동 시간이 길어졌습니다. 단 08-05 「300만」이 어느 항목인지 미확인이라 토큰 수 자체를 직접 비교하지는 않습니다.

정직 표기 — 같은 세션에서 연수치과 빌드와 도구 수리가 병행돼 이름·경로 낱말로 갈랐습니다(직접 태그 1,744 · 이어받음 2,294). 구간은 도장 시각으로 잘라 앞 단계 마무리와 다음 단계 본작업이 섞입니다. 빌드가 끝나면 스크립트를 다시 돌려 15단계까지 채웁니다.

12-7. 후보 1 「27개 조건 갈라내기」 실측 (2026-09-07 06:2x, 서브에이전트 조사 → 메인 판정)

전문 = C:/Users/outaekPC/Desktop/Cowork/260905_배포패키징_이혜진/_감사/v2/05-web-speed/Stage6-27조건-갈라내기.md.

• 「27개」는 낡은 숫자였습니다. 2026-08-31 스냅샷이고, 오늘 저장소 자신의 파서(check-stage-completion.py)로 다시 세면 Stage 6 완료조건 44개 중 문장(기계가 못 읽는 것)은 9개. 나머지는 그 뒤 검사기가 흡수했거나 목록에서 빠졌습니다.
• 9개의 갈래: 사람만 판정 2(출고 승낙 · 3초 인지) · 기계화 가능 5 · 이미 기계화 2(조건줄만 문장으로 남음).
• 더 큰 구멍이 따로 있습니다 — 「기계가 판정한다」는 35개 중 33개가 AI 자기신고 파일(asset-audit.json)을 읽을 뿐이고, 필드를 안 쓰면 0 으로 읽혀 조용히 통과합니다(문서 6-build.md:143-147 자백 + 실제 사고 D-6-H). 기계가 직접 재는 것은 2개.
• 한 것(코드 0): 사람만 판정하는 2개를 [report:demo](명예제와 섞임) → [human] 태그로 바꿔 「안 재는 것」과 「몰라서 안 잰 것」을 갈랐습니다(6-build.md:129·210, 파서가 이미 그 태그를 알고 있음). doc-chain 0 hard.
• 안 한 것: 기계화 가능 5개 중 ①한글 모바일 타이포(스크립트는 이미 돎, 조건줄만 문장) ②캡처 열람 영수증 ③애니 최소치 ④Premium-flow ⑤_build-intent.md 존재 — ①·⑤는 조건 문법상 자기신고 필드나 mandatory_executions 로 옮겨야 해서 다음 회차, ③·④는 사장님 판정이 먼저입니다.

Q12-4. 「애니메이션 최소 개수」 게이트를 만들까요? — 1 = 안 만들고 사람 판정(①)으로 둔다(추천 — 만들면 「장식을 더 붙여서 통과」 압력이 생겨 2026-07-13 필러 금지 규칙과 부딪힘) / 2 = 만든다 Q12-5. 자기신고 33개 — 1 = 「필드 없음 = 통과」를 「필드 없음 = FAIL」로 바꾸는 근본 처방을 다음 회차에(추천) / 2 = 그대로

12-8. 후보 12 「08-05 진단서 반영 여부 표」 실측 (2026-09-07 06:4x, 서브에이전트 조사)

전문 = C:/Users/outaekPC/Desktop/Cowork/260905_배포패키징_이혜진/_감사/v2/05-web-speed/08-05진단서-반영표.md.

• 진단서 3장의 개선안 21건 = 반영 10 · 일부 7 · 미반영 3 · 폐기 1. 세 진단서가 공통으로 지목한 것(preflight 선검사·수정 창 기계화·인계 노트·검수 등급·블라인드 픽·취향 로그·시안 경량 트랙·사각지대 선언)은 전부 반영됐습니다. 다음 세션이 같은 진단을 또 할 이유는 없어졌습니다.
• 후보 7(브라우저 13개 묶기)은 내립니다 — preflight 가 이미 「브라우저 한 번만」 구조(6-build.md:454-456, 실측 88초). 12장이 스스로 적어 놓고 후보로 또 올린 중복이었습니다(정정).
• 후보 9(필독 165편 줄이기)가 진짜 빈 자리 — 「재독 60%」를 세 진단서가 공통 지목했는데 처방(reviewer_reads 분리 · _worknote.md·재읽기 경고) 둘 다 미반영. 설계 문장은 이미 있어 바로 착수 가능.
• 후보 1(조건 갈라내기)의 지속 엔진이 꺼져 있음 — 「리뷰어 = 새 검사 제안자」 규칙이 REVIEWER_STAGE_6_build.md:87 한 장에만, 설계서에서 「선택」으로 격하.
• 토큰을 모델 등급으로 줄이는 길은 닫혀 있음 — MODELS.md:22 사장님 결정(Sonnet 의도적 부재, 2026-09-05 재확인) + 위반 자수 기록.
• 못 본 것: _작업보고/파이프라인-개선제안-20260831.md 두 장은 존재만 확인(안 읽음) — 「폐기됨」 사유가 거기 있을 수 있어 판정을 뒤집을 유일한 자리.

갱신된 추천 순서 = 6(끝) → 12(끝) → 2(끝) → 9(필독 줄이기) → 1(엔진 켜기: 리뷰어 「새 검사 제안」 필수화). 후보 7 삭제.

12-9. 다음 순서 실행 (2026-09-07 08~12시, 사장님 «추천대로 ㄱㄱ»)

검수·증거 = 4. website pipeline 2/_작업보고/REVIEW-speed-three-20260907.md · _evidence-20260907/speed-three-*. 남은 결정 1 = 새 훅 스크립트의 git add -N(추적 등록만)을 둘지 되돌릴지.

13장. 흡수 실행 기록 — 2026-09-07 새벽 (사장님 답 14개 → 원본에 넣은 것)

실시간 순서도 = https://pipeline-report.invisibleworks.co/progress.html · 답 원장 = 답-2026-09-07.md · 정합 결정 = 정합-결정-2026-09-07.md. 원본은 한 파일씩, 계약 테스트 동반으로 고쳤고 커밋은 안 했습니다. 각 호의 상세 = 광고 _작업보고/흡수N호-….md, 웹 _작업보고/absorb-from-ad-ppt-20260907.md.

13-1. 넣은 것 13호 (전부 실행 확인)

13-2. 새로 드러난 것 (사장님이 보실 것)

1. Lighthouse 와 preflight 가 딴말을 합니다. 같은 빌드(연수치과 시안1)를 preflight 는 LCP 0.26초로 통과시켰는데 Lighthouse(모바일 4G 흉내)는 15초·성능 56점입니다. 12장의 「8개 빌드 전부 통과」는 로컬 무제한 값이었습니다. 배포 뒤 진짜 주소로 다시 재는 것이 이제 배포 단계 필수 실행입니다.
2. 테스트 초록불 뒤의 구멍 — 상세페이지 게이트 규칙 18개 중 7개는 시험이 아예 안 건드렸고 3개는 건드려도 안 보고 있었습니다(변이 하네스 1차). 지금은 전부 물려 있습니다.
3. 값 층이 드러낸 진짜 신호 둘 — 인스타 템플릿 부제 30px(폰 10.8px, 12px 하한 아래) · 인쇄 16면 본문 9px(≈8.4pt, 제안값 9pt 아래). 값을 바꿀지 지면을 바꿀지는 사장님 판정.
4. 정정 3건(2장·1장·9장 서술이 실물과 달랐던 것) — 위 표 2·4호와 카드뉴스 ROLES(결함이 아니라 문서 공백).

13-3. 아직 안 한 것 (순서도의 대기 항목)

• 광고 9장 결함 나머지(문서-코드 드리프트·포트 하드코딩 8개·KIT.md 낡음·meta-ad 「완성」 표시 등) — 기계 수정으로 진행 중.
• 웹 속도 후보 12(08-05 진단서 반영 여부 표)·후보 1(27개 조건 갈라내기) — 조사 진행 중.
• 웹 PPT→웹 4가지(계측 서식·정본 판정 순위·은퇴 선언 철회·BLOCK/PASS 쌍)·광고→웹 5가지(발사 게이트·지시문 3줄·UTF-8·쉬운 말) — 진행 중.
• fresh-context 최종 검수 → share-pack 정식 호출 → 크로스체크 → intake.

13-4. 이번 회차의 한계

• 카톡 보고는 05:45 이후 앱이 프로필 탭에 있어 발송 실패(가드가 정확히 막음). 순서도 페이지가 대신합니다.
• 흡수 중 원본을 고친 파일은 전부 _작업보고 에 적었으나, 다른 세션이 같은 시각에 웹 파이프라인·PPT 스킬을 고치고 있어(component-intake 04:48 · BASELINE 09-07) 줄 번호는 흔들릴 수 있습니다.

13-5. 06:30 ~ 07:10 에 더 한 것 (사장님이 보실 것)