--- task_id: task-2432 type: design-spec section: brainstorming created: 2026-05-03 status: draft --- # IDS Phase 4 — Phase 0-A: Brainstorming (Visual Companion) > 회장 핵심 원칙: **"디자인 자산을 코드로 옮기는 것이 아니라, 타겟 사용자에게 먹히는 디자인을 토큰+구조+룰로 번역"** > > HARD GATE: 본 문서는 설계만 다룬다. 코드/scaffolding/패키지 변경/skills 또는 scripts 수정 일체 금지. 본 문서는 IDS Phase 4 Phase 0의 핵심 산출물 4종 중 하나로, mapping-tables.md / html-skeleton.md / target-audience.md 작성을 가이드할 **시스템 아키텍처 결정**을 회장 승인 게이트로 제시한다. 결과물은 "어떤 토큰/컴포넌트/룰 구조를 채택할 것인가"에 대한 회장 confirm을 받는 것이다. --- ## 1. 컨텍스트 탐색 (Context Exploration) "디자인 자산 → 코드 시스템" 번역의 본질 질문 4개. 각 답변은 회장 승인을 거쳐 mapping-tables.md / html-skeleton.md의 작성 방향을 결정한다. ### Q1. 토큰만 정의 vs 토큰 + 컴포넌트 + 룰 — 무엇이 적절한가? - **토큰만**: design-tokens.json + CSS variables. 단순하지만 "어디에 어떻게 적용?"이 비어 있음. - **토큰 + 컴포넌트 + 룰**: 토큰 + 컴포넌트 매핑 + 적용 룰(예: "headline은 반드시 token-headline-min 적용") + 검증 룰. - **결론(추천)**: 후자. task-2428 평가("ΔE=0.00 정확해도 색 대비 안 맞음")는 토큰 정확성만으로 부족하다는 회장의 명시적 신호. 룰 누락이 아마추어 수준의 원인. ### Q2. 단일 디자인 시스템 vs 페르소나별 분기 - **단일**: 한 세트의 토큰/컴포넌트로 FA/소비자 모두 커버. - **분기**: `theme: fa-pro` / `theme: consumer-friendly` preset 분리. - **결론(추천)**: 분기. target-audience.md 표 3.2의 충돌(색상 톤 Dark vs White, weight 600+ vs 400~700, 정보 밀도 高 vs 低)은 단일 시스템으로 양립 불가. 단, "공통 base + persona layer" 2-layer로 분기 비용을 최소화. ### Q3. dq-rules 32+ 항목을 그대로 매핑 vs 핵심 5~7개 우선 - **전체**: 32+ 항목 모두 토큰화. 완성도 높지만 Phase 0.5 Lite Evaluator가 무거워짐. - **핵심 우선**: contrast / safe-area / font-size / grid-align / color-palette 5항목만 Phase 0.5에 매핑, 나머지는 Phase 2 Full Evaluator로 이연. - **결론(추천)**: 핵심 우선. 회장 명시 "Lite Evaluator 먼저 정의 → Track A 안전장치"는 5항목 빠른 회귀 게이트가 목표. 32+ 전체는 mapping-tables.md에 매핑만 정의하되, **활성화는 Phase 0.5 → Phase 2 단계적 진행**. ### Q4. 회귀 게이트(Lite Evaluator) vs 풀 평가 — 어디에서 분리? - **분리 안 함**: 모든 검증을 한 곳에서. 무거움, 빠른 회귀 불가. - **분리**: Phase 0.5 Lite (5항목, 빠른 게이트) / Phase 2 Full (10+항목, 전체 평가) 명확 분리. - **결론(추천)**: 분리. mapping-tables.md 5번 매핑(quality_evaluator 5축 → regression gate)이 분리 지점. Lite는 PASS/FAIL 게이트 전용, Full은 점수+개선제안 포함. --- ## 2. Clarifying Questions (회장 승인 필요) 회장에게 확정 받아야 할 7개 질문. 각 항목에 추천 답변(R) 동봉. ### CQ1. Lite Evaluator 5항목 — 정확히 어떤 5개? 후보: contrast / safe-area / font-size / grid-align / color-palette / hierarchy / text-overflow / aspect-ratio. **R**: **contrast (WCAG AAA 7:1) / safe-area (canvas 8% 패딩) / font-size (headline_min 84px, body_min 40px) / grid-align (8pt 그리드 위반 0) / color-palette (preset palette 외 색상 사용 0)**. 근거: task-2428 회장 평가("색 대비 안 맞음 = 아마추어")의 직접 대응이 contrast 1순위. 나머지 4개는 dq-rules 빈도 상위 + Lite Evaluator의 빠른 검증 가능성. ### CQ2. theme preset 3종 확정? 회장 명시: "Phase 1 MVP = Brex/Supabase/Apple 3종". **R**: **Brex / Supabase / Apple 3종 확정 + 페르소나 매핑 별도 정의**. - Brex orange `#FF6E2B` → 일반 소비자(따뜻 핀테크 신뢰) — `consumer-friendly` 계열 - Supabase green `#3ECF8E` → 일반 소비자(친근 활기) — `consumer-friendly` 계열 - Apple monochrome → 보험 FA(전문 절제) — `fa-pro` 계열 **보험 도메인 친화 preset 추가 여부**: Phase 1 MVP에서는 추가 X (회장 명시 3종 우선). Phase 3에서 노하우 누적 후 `kb-financial`, `samsung-life` 등 도메인 특화 preset 검토. ### CQ3. base layer와 persona layer의 책임 분리 경계? **R**: 다음과 같이 분리. | Layer | 포함 항목 | 변경 빈도 | |---|---|---| | **Base layer** | grid (8pt), font-size-min, contrast-min, safe-area, aspect-ratio | 낮음 (분기당 1회) | | **Persona layer** | palette, font-weight-range, density, tone, CTA 어휘 | 중간 (preset별 조정) | | **Brand preset** | brand color, accent, signature font | 높음 (Brex/Supabase/Apple별) | **근거**: target-audience.md 룰 E "절대 하한"은 base, 페르소나 가치는 persona, 브랜드 색은 preset. ### CQ4. dq-rules.json 전체 32+ 항목 중 Phase 0 매핑 범위? **R**: **mapping-tables.md에 32+ 전부 매핑은 정의 (read-only inventory 의무)**, 단 **활성화(Lite Evaluator 코드 연결)는 Phase 0.5의 5항목만**. 나머지 27+ 항목은 mapping-tables.md에서 "Phase 2 활성화 예정" 표시. **근거**: 회장 명시 "dq-rules.json 100% 커버" + "Lite Evaluator 5항목 먼저"는 매핑은 100%, 게이트는 단계적이라는 의미로 해석. ### CQ5. Satori HTML/CSS skeleton에서 컴포넌트 hierarchy 깊이는? 후보: (a) 1-level flat (Card 1개에 모든 슬롯) / (b) 2-level (Card > [Headline/Body/CTA]) / (c) 3-level (Card > Section > Atom). **R**: **2-level**. - 1-level은 재사용성 부족 - 3-level은 Phase 0 단계에 과설계 - 2-level: `` (preset 받음) > ``, ``, ``, ``, `` atoms ### CQ6. 페르소나 감지(detection) 방식 — 명시적 prop vs 자동 감지? 후보: (a) `` 명시 / (b) brief 텍스트 분석으로 자동 분류. **R**: **명시적 prop 우선 (Phase 0~1), 자동 감지는 Phase 3 노하우 누적 후**. 근거: 자동 감지는 정확도 검증 비용 큼. Phase 0 단계는 명시적 prop으로 단순화하고, 휴먼이 brief 작성 시 페르소나 명시. ### CQ7. preset 충돌 해결 — target-audience.md 룰 A~E 그대로 채택? **R**: **그대로 채택 + brainstorming.md에 알고리즘 형태로 명시화**. - 룰 A (theme preset 분리) → 1차 적용 - 룰 B (컴포넌트 variant) → 2차 적용 - 룰 C (density 토큰) → 미세 조정 - 룰 D (보수적 우선) → 결정 불가 시 - 룰 E (가독성/접근성 절대 우선) → 모든 룰을 무력화하는 최상위 게이트 --- ## 3. Visual Companion Wireframes 3개 각 alternative는 **다른 시스템 아키텍처 접근**을 보여준다. ASCII 다이어그램으로 데이터 흐름과 책임 분리를 표현. ### Alternative A: Token-First (토큰 우선 단일 시스템) #### 구조 ``` ┌─────────────────────────────────────────────────────────────┐ │ dq-rules.json (32+ 항목) │ │ font_min, contrast_min, safe_area, grid, palette, ... │ └──────────────────────────┬──────────────────────────────────┘ │ (1:1 매핑) ▼ ┌─────────────────────────────────────────────────────────────┐ │ design-tokens.json (단일 진실원본) │ │ --font-headline-min: 84px │ │ --contrast-min: 7:1 │ │ --safe-area: 8% │ │ --grid-base: 8px │ │ --color-primary: ... │ └──────────────────────────┬──────────────────────────────────┘ │ (CSS var 주입) ▼ ┌─────────────────────────────────────────────────────────────┐ │ tokens.css (CSS variables) │ │ :root { --font-headline-min: 84px; ... } │ └──────────────────────────┬──────────────────────────────────┘ │ (참조) ▼ ┌─────────────────────────────────────────────────────────────┐ │ Satori HTML 컴포넌트 (단일 세트) │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────┘ ``` #### 특성 - **장점**: - 단일 진실원본(design-tokens.json) — dq-rules 변경 시 즉시 전파 - 학습 곡선 가장 낮음 (1-layer) - Lite Evaluator 코드가 단순 — 토큰 1세트만 검증 - **단점**: - **페르소나 분기 불가** — FA/소비자 충돌(Dark vs White, 정보 밀도 高 vs 低) 해결 못 함 - target-audience.md 표 3.2의 7개 충돌 항목 모두 우회해야 함 → 결국 매번 "어느 쪽으로 갈지" 즉흥 결정 - 토큰만 있고 적용 룰 누락 시 task-2428 재발 (회장 평가 직접 인용) - **리스크**: - **타겟 연결 명확성 약함** — 회장 핵심 원칙 "타겟 사용자에게 먹히는 디자인" 충족 어려움 - "단일 시스템이라 양쪽 모두 어정쩡" 결과 가능 --- ### Alternative B: Persona-Branched (페르소나 분기 시스템) #### 구조 ``` ┌─────────────────────────────────────────────────────────────┐ │ target-audience.md │ │ Primary: 보험 FA Secondary: 일반 소비자 │ └────────────┬───────────────────────────┬────────────────────┘ │ │ ▼ ▼ ┌──────────────────────┐ ┌──────────────────────┐ │ preset: fa-pro │ │ preset: consumer │ │ ├ palette (Navy) │ │ ├ palette (White) │ │ ├ font-weight 600+ │ │ ├ font-weight 400+ │ │ ├ density: compact │ │ ├ density: spacious │ │ ├ CTA: 명령형 │ │ ├ CTA: 탐색형 │ │ └ 정보 밀도: 高 │ │ └ 정보 밀도: 低 │ └──────────┬───────────┘ └──────────┬───────────┘ │ │ ▼ ▼ ┌──────────────────────┐ ┌──────────────────────┐ │ Components.fa-pro │ │ Components.consumer │ │ │ │ │ │ │ │ │ │ │ │ │ └──────────────────────┘ └──────────────────────┘ ``` #### 특성 - **장점**: - **타겟 연결 명확성 최강** — 회장 핵심 원칙 직접 충족 - 페르소나별 최적화 100% 가능 (target-audience.md 표 3.2 모든 충돌 해결) - 카피/디자인팀이 "이 콘텐츠는 어느 preset?" 명확히 결정 - **단점**: - **단일 진실원본 약함** — preset마다 토큰 중복, 공통 변경 시 양쪽 동시 수정 필요 - preset이 추가될 때마다(Phase 3에서 도메인 preset 등) 매핑 비용 선형 증가 - 두 preset 간 **공통 가치(접근성, grid)** 일관성 깨질 위험 - **리스크**: - 보수 비용 증가 — Phase 1에서 Brex/Supabase/Apple 3종 × 페르소나 2종 = 6종 변형 가능성 - "FA용에서는 7:1 대비 지키는데 소비자용에서는 깜빡함" 같은 회귀 발생 가능 --- ### Alternative C: Hybrid (Token + Persona Layer) — **추천** #### 구조 ``` ┌─────────────────────────────────────────────────────────────┐ │ target-audience.md │ │ Primary: 보험 FA Secondary: 일반 소비자 │ └────────────┬───────────────────────────┬────────────────────┘ │ │ │ ┌───────────────────┘ │ │ ▼ ▼ ┌─────────────────────────────────────────────────────────────┐ │ BASE LAYER (단일 진실원본 — 양쪽 공통) │ │ │ │ --grid-base: 8px ← dq-rules.grid │ │ --font-headline-min: 84px ← dq-rules.font_min │ │ --contrast-min: 7:1 ← dq-rules.contrast (WCAG AAA) │ │ --safe-area: 8% ← dq-rules.safe_area │ │ --aspect-ratio: 1:1, 4:5, 9:16 │ │ │ │ ★ 절대 하한 (룰 E) — preset과 무관하게 강제 │ └────────────────────────────┬────────────────────────────────┘ │ (extend) ┌────────────┴────────────┐ ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────┐ │ PERSONA LAYER: fa-pro │ │ PERSONA LAYER: consumer │ │ │ │ │ │ --palette: Navy/Gold │ │ --palette: White/Accent │ │ --font-weight-min: 600 │ │ --font-weight-min: 400 │ │ --density: comfortable │ │ --density: spacious │ │ --tone: 명령형/공식 │ │ --tone: 탐색형/일상 │ │ --info-density: high │ │ --info-density: low │ └──────────────┬───────────┘ └──────────────┬───────────┘ │ │ ▼ ▼ ┌──────────────────────────┐ ┌──────────────────────────┐ │ BRAND PRESET (Phase 1) │ │ BRAND PRESET (Phase 1) │ │ Apple monochrome │ │ Brex orange / Supabase │ │ (fa-pro와 합) │ │ (consumer와 합) │ └──────────────┬───────────┘ └──────────────┬───────────┘ │ │ └─────────────┬───────────────┘ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Satori 컴포넌트 (2-level hierarchy) │ │ │ │ │ │ ← base.font-headline-min 적용 (절대) │ │ ← persona.density 적용 │ │ ← persona.tone 자동 분기 │ │ │ │ │ │ ★ 컴포넌트는 base + persona + brand 3-layer 모두 참조 │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Lite Evaluator (Phase 0.5) — base layer만 검증 │ │ ✓ contrast (7:1) ✓ safe-area ✓ font-min │ │ ✓ grid-align ✓ palette-in-preset │ │ │ │ ★ persona 변형은 검증 X (preset 책임) │ └─────────────────────────────────────────────────────────────┘ ``` #### 특성 - **장점**: - **단일 진실원본 + 페르소나 분기 동시 충족** — A의 강점(base) + B의 강점(persona) - **타겟 연결 명확성 보장** — 회장 핵심 원칙 직접 충족 - **Lite Evaluator 즉시 작성 가능** — base layer 5항목만 검증, persona 무관하게 PASS/FAIL - **task-2428 재발 차단 메커니즘 내장** — base.contrast-min은 어떤 preset에서도 양보 X (룰 E) - **Phase 1 MVP 효율** — Brex/Supabase/Apple 3종 × persona 2종 조합이 base layer 공유로 인해 검증 비용 낮음 - **단점**: - **2-layer 관리 복잡도** — 컴포넌트가 base + persona 둘 다 참조해야 함 - **초기 학습 곡선** — Phase 0~1 단계에 휴먼이 layer 분리 룰을 익혀야 함 - 컴포넌트 변형 룰 명확화 필수 (CQ5, CQ6 답변에 의존) - **리스크**: - layer 경계 모호 시 "이건 base인가 persona인가?" 결정 비용 - 완화 방법: CQ3 답변 표(base/persona/brand 책임 분리)를 mapping-tables.md에 명시적 룰로 고정 --- ## 4. Tradeoffs 표 (3안 비교) | 평가 기준 | A: Token-First | B: Persona-Branched | C: Hybrid (추천) | |---|---|---|---| | **단일 진실원본** | 충족 | 약함 (preset별 중복) | 충족 (base layer) | | **타겟 연결 명확성** | 약함 (단일 시스템 한계) | 강함 | 강함 | | **회장 핵심 원칙 충족** | 부분 (코드 번역만) | 강함 (타겟 우선) | 강함 (타겟 + 룰 둘다) | | **매핑 비용** | 낮음 | 높음 | 중간 | | **Phase 0.5 Lite Evaluator 즉시성** | 즉시 가능 | preset 결정 후 가능 | 즉시 가능 (base만) | | **task-2428 재발 차단** | 약함 (룰 누락 가능) | 중간 (preset별 누락 위험) | 강함 (룰 E 강제) | | **Phase 1 MVP 효율 (3 brand × 2 persona)** | 낮음 (페르소나 분기 X) | 중간 (각 preset 6종) | 높음 (base 공유) | | **확장성 (Phase 3 도메인 preset)** | 낮음 | 중간 (선형 증가) | 높음 (persona layer만 확장) | | **학습 곡선** | 낮음 | 중간 | 중간~높음 | | **dq-rules 100% 커버 가능성** | 충족 | 충족 (preset별) | 충족 (base에 임계값 집중) | | **회귀 0 보장** | 약함 | 중간 | 강함 | | **추천 채택도 (10점 만점)** | **6/10** | **7/10** | **9/10** | --- ## 5. 추천 (Recommendation) ### **Alternative C (Hybrid: Token + Persona Layer) 채택 권장** #### 채택 근거 5가지 1. **회장 핵심 원칙 직접 충족** - "디자인 자산을 코드로 옮기는 것이 아니라, 타겟 사용자에게 먹히는 디자인을 토큰+구조+룰로 번역" — base layer(토큰+룰) + persona layer(타겟) 정확히 매칭. 2. **task-2428 재발 차단 메커니즘 내장** - base layer의 contrast-min(7:1) / font-min(84px) 등은 어떤 preset에서도 무력화 불가 (target-audience.md 룰 E). "ΔE=0.00 정확해도 색 대비 안 맞음" 케이스가 컴파일 타임에 차단됨. 3. **Phase 0.5 Lite Evaluator 즉시 작성 가능** - 5항목(contrast/safe-area/font-size/grid-align/color-palette)이 모두 base layer 소속 → preset 결정 대기 없이 코드 작성 진입 가능. 회장 명시 "Lite Evaluator 먼저" 충족. 4. **Phase 1 Satori MVP 효율** - Brex/Supabase/Apple 3종 × persona 2종 = 6 조합이지만, base layer 공유로 인해 새로 검증할 토큰 수가 선형이 아닌 상수. 회장 육안 검수("아마추어 느낌 줄음") 통과 가능성 최대. 5. **Phase 3 노하우 누적 시 확장 용이** - 도메인 특화 preset(예: `kb-financial`, `samsung-life`)을 persona layer 확장으로 추가 가능, base layer 변경 없음. 회귀 위험 최소. #### Alternative C의 위험 완화 방안 - **위험**: base/persona layer 경계 모호. **완화**: CQ3 답변의 책임 분리 표(base = 절대 하한 / persona = 가치 반영 / brand = 시각 정체성)를 mapping-tables.md에 알고리즘 형태로 고정. 새 토큰 추가 시 이 표로 결정. - **위험**: 컴포넌트가 3-layer 모두 참조해야 하는 복잡도. **완화**: CQ5 답변(2-level hierarchy) + CQ6 답변(persona는 명시적 prop) 채택. 자동 감지는 Phase 3 이후로 이연. #### 회장 카운터 제안 시 대응 방안 - 회장이 **"Alternative B(persona-branched)가 더 명확하다"** 결정 시: target-audience.md 룰 E를 별도 검증 게이트(공통 contract)로 승격해 base layer 부재의 위험을 보상. - 회장이 **"Alternative A(token-first)로 시작하고 Phase 3에서 분기"** 결정 시: persona 분기를 mapping-tables.md에 "Phase 3 활성화 예정" 표시로 미리 정의해 후속 비용 최소화. --- ## 6. Section-by-Section 회장 승인 게이트 (HARD GATE) 각 게이트는 **회장 confirm 없이 다음 단계 금지**. 완료 시 본 문서 status를 `draft → reviewed → approved`로 단계 전환. ### Gate G1: 컨텍스트 탐색 4개 질문 + 답변 승인 - [ ] Q1: 토큰만 vs 토큰+컴포넌트+룰 → **토큰+컴포넌트+룰** 승인 - [ ] Q2: 단일 vs 페르소나 분기 → **분기 (Hybrid 형태)** 승인 - [ ] Q3: 32+ 전체 vs 핵심 5~7개 → **매핑은 32+, 활성화는 5개** 승인 - [ ] Q4: 회귀 게이트 분리 → **Phase 0.5 Lite / Phase 2 Full 분리** 승인 ### Gate G2: Clarifying Questions 7개 답변 승인 - [ ] CQ1: Lite Evaluator 5항목 = contrast / safe-area / font-size / grid-align / color-palette 승인 - [ ] CQ2: theme preset 3종 (Brex/Supabase/Apple) + 페르소나 매핑 승인 - [ ] CQ3: base / persona / brand 3-layer 책임 분리 표 승인 - [ ] CQ4: dq-rules 32+ 매핑 100%, 활성화 5개 승인 - [ ] CQ5: 컴포넌트 hierarchy 2-level 승인 - [ ] CQ6: 페르소나 명시적 prop (자동 감지 X) 승인 - [ ] CQ7: target-audience.md 룰 A~E 그대로 채택 승인 ### Gate G3: Wireframe 3안 중 채택안 결정 - [ ] Alternative A / B / C 중 **C (Hybrid) 채택** 또는 회장 카운터 제안 결정 ### Gate G4: Tradeoffs 표 검수 - [ ] 11개 평가 기준 + 채택도 점수 회장 검수 - [ ] 누락된 평가 기준 추가 또는 가중치 조정 결정 ### Gate G5: 추천(Alternative C) 채택 또는 카운터 제안 수용 - [ ] 추천 근거 5가지 + 위험 완화 방안 회장 승인 - [ ] 채택 시: mapping-tables.md / html-skeleton.md 작성 진입 권한 부여 - [ ] 카운터 제안 시: 본 문서 재작성 후 G1부터 재시작 **G1~G5 모두 통과 후에만** Phase 0-B (mapping-tables.md), Phase 0-C (html-skeleton.md) 작성 진입. --- ## 7. HARD GATE 준수 명시 본 문서는 **설계만** 다루며 다음을 절대 포함하지 않음: | 금지 항목 | 본 문서 적용 여부 | |---|---| | 코드 (CSS, HTML, JS, Python 등) 실제 구현 | 미포함 (ASCII 다이어그램과 의사 토큰 이름만 사용) | | scaffolding (디렉토리 생성, 파일 보일러플레이트) | 미포함 | | 의존성 추가 또는 패키지 변경 | 미포함 | | skills/** 변경 (skills/satori-cardnews 등) | read-only 유지 | | scripts/** 변경 | read-only 유지 | | memory/specs/dq-rules.json 변경 | read-only 유지 (매핑만 정의) | | memory/specs/image-workflow-v2.5-final.md 변경 | read-only 유지 | | memory/reports/task-2421* / task-2428* 변경 | 보존 | ### 다음 Phase 진입 조건 - Phase 0-B/C/D 산출물 4종 모두 작성 + 회장 승인 - Phase 0.5 진입: **Codex 사전 검증 + 마아트 QC + 로키 DA 통과 후만 가능** - Phase 0.5에서 처음으로 코드 작성 권한 발생 (Lite Evaluator 5항목 한정) - Phase 1/2/3 각 단계는 별도 task로 분리, 본 task에서 진입 X --- ## 8. 참조 - 본 task 자매 산출물: target-audience.md (작성 완료) / mapping-tables.md (Phase 0-B 진입 대기) / html-skeleton.md (Phase 0-C 진입 대기) - 회장 명시 (2026-05-03): "디자인 자산을 코드로 옮기는 것이 아니라, 타겟 사용자에게 먹히는 디자인을 토큰+구조+룰로 번역" - 회장 명시 (2026-05-03): "A+B+C 동시진행 X, Phase 분리 + Lite Evaluator 먼저" - 회장 명시 (2026-05-03): "Phase 0에 HTML skeleton + Target Audience 추가" - task-2428 회장 평가 (2026-05-03): "ΔE=0.00 정확해도 색 대비 안 맞음 = 아마추어 수준" → 룰 E 및 base layer contrast-min의 직접 근거 - 회장 메모리 ★ feedback_design_philosophy.md, feedback_creative_work_principle.md, system_governance_4layer.md - /brainstorming 스킬 (Visual Companion + 2~3 alternatives + section-by-section approval gate)