---
task_id: task-2432
type: context
scope: phase-system (Phase 0~3)
created: 2026-05-03
updated: 2026-05-03
status: phase-0-completed
---

# IDS Phase 4 — Phase System Context Notes

> 본 문서는 Phase 0~3 전체에 걸친 결정 근거를 보존한다. 각 Phase는 별도 task의 context-notes에서 세부 결정을 기록하되, 본 문서는 시스템 전체 의사결정의 single source.

---

## 1. 회장 직접 명시 (2026-05-03)

### 1.1 큰 그림 — A+B+C 동시 X, Phase 분리
- procedural PIL = 회귀 테스트 fixture로 격하 (폐기 X)
- Satori/HTML/CSS = 진짜 디자인 렌더러
- Lite Evaluator (Phase 0.5) 먼저 정의 → Track A 안전장치
- Track A → Track B → Track C 순차

### 1.2 Phase 0 필수 조건
- HTML/CSS skeleton 정의 (token 정의로 끝내지 X, 실제 렌더링 구조)
- Target Audience 명시 (primary 보험 FA, secondary 일반 소비자)
- 모든 매핑은 타겟 기준과 연결

### 1.3 task-2428 회장 평가
"ΔE=0.00 정확해도 색 대비 안 맞음 = 아마추어 수준"
- 본 IDS Phase 4의 출발점
- Phase 0.5 Lite Evaluator L1 Contrast가 이 문제 차단 메커니즘
- target-audience §7.2 Contrast SSOT가 상위 잠금

## 2. 핵심 결정

### [결정 1] Phase 분리 (A+B+C 동시 X)
- 회장 명시 직접 인용
- 동시 진행 시 의존성 미해결로 모든 트랙 동시 실패 위험
- 대안 기각: A+B+C 동시 = 평가 도구 → 평가 무한 루프

### [결정 2] HTML skeleton + Target Audience 필수
- 토큰 정의만으로는 "어디에 어떻게 적용되는가" 결정 불가
- 타겟 명시 없이는 임계값 정당화 불가 (84px headline 왜 84px인지)
- 대안 기각: 토큰만 = "멋있게 만들자" 회귀

### [결정 3] quality_evaluator를 회귀 게이트로만, contrast/hierarchy/safe-area는 분리 (Codex 사전 검증 발견 2026-05-03)
- 사실: `check_brand_color_match`는 ΔE+면적만 측정, contrast 미측정
- task-2428 회장 평가의 직접 원인
- 결정: mapping-tables #4 = PIL fixture 회귀 한정, #5 = Lite Evaluator 신규 5항목 (L1 Contrast가 핵심)

### [결정 4] Lite Evaluator는 OCR 비의존 (Codex 발견)
- 사실: `check_font_size`/`check_ocr_confidence`는 Tesseract 의존, 환경 부재 시 BLOCKED
- 결정: Lite 5항목은 PIL/CSS 정적 분석만, OCR은 Phase 2 Full로 이관

### [결정 5] L1 Contrast 알고리즘 = 글리프 픽셀 percentile 분포 (로키 CRITICAL #1 보강)
- 단순 픽셀쌍 측정 → 그라데이션/photo bg에서 우회 가능
- 글리프 픽셀 추출(alpha mask) + 픽셀별 WCAG 분포 → **5th percentile ≥ 4.5:1** (절대 하한), **95th percentile ≥ 7:1** (권장)
- 반투명 오버레이 alpha-composite 후 effective bg 계산
- knowhow-design `LR_GRADIENT_ENDPOINT_45` 자동 충족

### [결정 6] preset 결정 권한자 = brief 작성자 (로키 CRITICAL #2 보강)
- brief에 `targetPersona` 필드 강제: `insurance-fa` | `consumer` | `hybrid`
- 자동 매핑: fa → theme-fa-fintech, consumer → theme-consumer-warm, hybrid → 슬라이드별 분기
- decision authority: 카피라이터/팀장이 brief에 명시. Satori 코드는 silent default 금지
- fallback: theme-fa-fintech (보험 도메인 base, fail-loud)

### [결정 7] dq-rules 절대 양보 X, preset은 적용 영역 분리 (로키 CRITICAL #3 보강)
- "광고 배너 vs 일반 페이지" 분기 폐기 — Satori 출력 = 100% 광고/콘텐츠
- preset의 weight/font-family/palette/radius는 적용 가능, font-size/contrast/grid는 dq-rules 우선
- 자동 룰: `LR_DECISION_AUTO_DQRULES` (디자이너 주관 X)

### [결정 8] Phase 0.5 evaluator 입력 계약 = JSON Schema + LayoutMeta (Codex HIGH 4 보강)
- 현재 `evaluate_image()`는 PNG + meta 없음 → Lite Evaluator 작동 불가
- Phase 0.5 첫 task = `canvas-props.schema.json` 작성 + `evaluate_image(layout_meta=...)` 시그니처 확장
- target-audience §7.4에 LayoutMeta 형식 정의 (themePreset, components bbox/fontSize/fill, safeArea, grid, background)

### [결정 9] preset 명명 SSOT (Codex HIGH 2 보강)
- 정식 명명: `theme-fa-fintech` (Brex base, FA 전용) / `theme-consumer-warm` (Apple base, 소비자 전용)
- `theme-product-modern` (Supabase base) = Phase 2 이후 회장 confirm 시 도입, **Phase 1 MVP 제외**
- 초안 명칭 (`fa-pro`, `consumer-friendly`)은 SSOT 표에서 호환 참조용으로만 유지

### [결정 10] Contrast SSOT (Codex HIGH 3 보강)
- target-audience §7.2 표가 단일 진실원본
- 본 IDS 시스템 권장 = AAA 7:1 (헤드라인/CTA), 절대 하한 = AA 4.5:1 (5th percentile)
- dq-rules와 충돌 시 더 엄격한 값 채택

## 3. 3 Step Why (회장 직접 명시 검증)

### 1st Why: 왜 본 시스템(Phase 0~3)이 필요한가?
A: task-2428 "ΔE=0.00이어도 색 대비 안 맞음 = 아마추어"가 드러낸 본질적 문제 = 디자인 자산이 코드로 옮겨지긴 했으나 "타겟에게 먹히는 기준"이 없음. dq-rules.json 32+ 항목과 노하우 파일이 산재하지만 통합된 매핑/구조/룰이 없어 매번 즉흥 판단으로 회귀.

### 2nd Why: 왜 A(Phase 0~3 통합 시스템)가 최선의 접근인가?
B: Codex 검증 결과 1) quality_evaluator는 contrast 미측정, 2) OCR 환경 의존, 3) dq-rules는 임계값만 있고 적용 위치 없음. 평가 도구만 추가 = 측정 누락 잔존, 토큰만 정의 = 적용 위치 누락. **매핑표(임계값) + skeleton(적용 위치) + target audience(정당화 근거) + Lite Evaluator(자동 검증) + Full Evaluator(휴먼 통합) 5종이 동시에 있어야 task-2428 재발이 구조적으로 차단됨.**

### 3rd Why: 왜 B(통합 시스템)가 다른 대안(평가 도구 우선 / 토큰 우선 / brainstorming만)보다 나은가?
C:
- 평가 도구 우선 = 측정 대상 없는 평가, task-2428 재발
- 토큰 우선 = "멋있게 만들자" 회귀, 회장 명시 X
- brainstorming만 = 검증 불가능한 wireframe 누적

→ Phase 0 통합 정의는 후속 Phase 0.5 작성 시 "어떤 입력으로 어떤 임계값을 어디 컴포넌트에 적용해 측정"이 즉시 결정. Phase 1 Satori MVP는 이미 검증 알고리즘이 있는 상태에서 시작. **의존성 그래프가 가장 짧고, 각 Phase의 회장 confirm 게이트가 명확.**

**A-B-C 일관성**: ✅ "통합 시스템(매핑+skeleton+target+Lite+Full) → Phase 0.5 즉시 작성 → task-2428 재발 차단" 일관

## 4. 검증 결과 누적

### 4.1 Codex 사전 검증 (1차, 산출물 미존재 시)
- 결과: FAIL (산출물 미존재)
- 핵심 발견: quality_evaluator contrast 미측정, OCR 환경 의존, allowed_resources 자기모순
- 반영: 결정 3, 4 + mapping-tables #4/#5 분리

### 4.2 마아트 3자 QC (1차)
- 결과: PASS (FAIL 0, WARN 0)
- 인용: "산출물 7종 모두 회장 명시 5항 준수, Codex 2대 발견 mapping #4/#5에 분리 반영"

### 4.3 로키 DA 공격 (1차)
- 결과: REWORK (CRITICAL 3, HIGH 5, MEDIUM 3, LOW 1)
- 핵심 발견: L1 Contrast 알고리즘 모호 / preset 결정 권한자 부재 / dq-rules vs preset 양보 경로
- 반영: 결정 5, 6, 7 + mapping-tables/html-skeleton 보강

### 4.4 Codex 사전 검증 (2차, 보강 후)
- 결과: **PASS** (critical=false, risks 6건 — high 4 + medium 2)
- 핵심 발견: 산출물 경로 일부 불일치 / preset 명명 미통일 / contrast SSOT 부재 / Phase 0.5 evaluator 계약
- 반영: 결정 8, 9, 10 + target-audience §7 SSOT + 본 plan/context/checklist 신설

## 5. 참조

- 회장 메모리 ★ `system_governance_4layer.md`
- 회장 메모리 ★ `feedback_creative_work_principle.md`, `feedback_design_philosophy.md`
- 회장 메모리 ★ `feedback_design_team_routing_v2.md`
- dq-rules.json (단일 임계값 소스)
- 노하우 3종 / 벤치마크 4종 / 132 design-md
- task-2428 회장 평가
- 본 task 산출물 5종

## 6. 주의사항

- **코드 변경 절대 금지** (Phase 0 only — 설계 문서)
- **silent fix 금지**: 산출물 수정 시 본 context-notes에 결정 기록 의무
- **추측 금지**: dq-rules / 노하우 / design-md / 회장 명시 기반
- **PII 마스킹**: 외부 AI(Codex/Gemini) 호출 시 자동 (codex_gate_check가 처리)
- **회장 confirm 의무**: SSOT 변경 / preset 추가 / contrast 임계값 변경 / Phase 진입 게이트 통과