Lieflat Charts — 차트 취향 법전은(는) 무엇을 하나요?

Lieflat Charts는 Agent Skills 형식을 따르는 데이터 시각화 skill입니다. 기본적으로 Mono 그레이스케일을 사용하지만, 데이터 의미와 사용 시나리오에 적합할 때 자동으로 컬러 프리셋을 선택합니다. 데이터 차트를 편집된 느낌이 나고, 읽을 수 있으며, 완전한 페이지를 구성할 수 있는 시각적 콘텐츠로 만드는 데 집중합니다. 이 skill은 moxt.ai에서 제작되었으며, Lupi 편집형, Glance 빠른 판단형, Basics 기본 편집형, Interactive 대형 차트를 지원합니다. 사용자가 데이터와 상황을 제공하면, 빌드가 필요 없고 더블 클릭으로 열 수 있는 단일 파일 HTML을 생성합니다. 데이터를 변경하려면 상단의 배열 하나만 수정하면 됩니다. 순수 SVG 차트는 오프라인에서 실행 가능합니다. Chart.js, ECharts 또는 온라인 폰트를 사용하는 차트는 종속 항목이 인라인되지 않으면 네트워크가 필요합니다. 기본적으로 Lupi Editorial과 Lupi Basics 중에서 먼저 유형을 선택해야 합니다. 두 가지 모두 적절한 템플릿이 없거나 사용자가 명시적으로 Glance / dashboard / 3초 훑기를 요청한 경우에만 Glance를 사용할 수 있습니다.

색상은 사용자가 명시적으로 트리거할 필요가 없습니다. 섹션 6.5에 따라 Mono와 color-presets.js의 세 가지 내장 스킴 사이에서 자동으로 판단합니다. 사용자가 브랜드 색상이나 사용자 정의 색상 값을 명시한 경우, 납품 내에 custom 팔레트를 설정할 수 있습니다. 동일한 HTML 또는 동일한 납품 세트는 하나의 색상 시스템만 사용해야 하며, 혼용할 수 없습니다. 스킨 변경 샘플은 templates/color/에 있습니다.

차트의 참조 코드를 찾는 방법: catalog에서 차트 유형을 찾습니다 → 해당 gallery 파일을 엽니다 → 카드 제목으로 <div class="card"> 블록을 찾아 구조를 확인합니다 → <script>에서 동일한 이름의 // ════ 주석 블록을 검색하여 렌더링 코드를 가져옵니다. 전체 페이지를 그대로 복사하지 마십시오. gallery는 여러 카드가 합쳐진 페이지이며, 사용자에게 납품하는 것은 항상 섹션 9의 골격에 따라 조립된 단일 차트 파일입니다.

대상 사용자는 비프로그래머(작가, 마케터, PPT 제작자)입니다. 그들은 일상 언어로 말합니다("이번 분기 전환율을 차트로 그려서 공식 계정에 게시해 주세요"). 차트 유형 이름을 말하지 않습니다. 당신의 임무는 일상 언어를 올바른 차트로 번역하고, 바로 게시할 수 있을 정도로 예쁘게 만드는 것입니다.

0. 템플릿 우선권 엄격 규칙

다음 규칙은 권장 사항이 아닙니다. 하나라도 위반하면 반드시 재작업해야 합니다:

반드시 저장소 템플릿에서 생성해야 합니다. 각 완성된 차트는 먼저 catalog.md에서 차트 유형 번호를 확정한 다음, 해당 gallery의 실제 구현을 엽니다: Lupi는 templates/lupi-gallery.html을, 기본형은 templates/basics-gallery.html을, Glance는 templates/glance-gallery.html을, 대화형 대형 차트는 templates/big-*.html을 사용합니다. 컬러 차트도 이 원본 템플릿을 구조적 기준으로 사용합니다. templates/color/는 색상 구성만 확인하는 데 사용됩니다.
선택한 템플릿의 코드 골격을 반드시 따라야 합니다. 카드 제목에 해당하는 <div class="card">와 동일한 이름의 // ════ 차트유형명 ════ 주석 블록에서 시작하여, 핵심 SVG / Canvas / ECharts 구조, 데이터 인코딩 방식, 비율, 애니메이션 템포를 유지해야 합니다. 데이터, 제목, 부제, 출처 및 필요한 레이아웃 변경은 허용되지만, 템플릿을 벗어나 "비슷해 보이는" 차트를 새로 그리는 것, 여러 템플릿을 결합하여 혼합 차트 유형을 만드는 것, 또는 차트 라이브러리의 기본 스타일로 되돌리는 것은 금지됩니다.
기본 선택 순서는 고정되어 있습니다. 먼저 Lupi Editorial(L1–L15)을 완전히 비교한 다음 Lupi Basics(F1–F13)를 비교합니다. 데이터를 정직하게 담고, 레이블을 수용하며, 읽을 수 있는 템플릿이 이 두 그룹 중에 존재한다면 반드시 이 중에서 선택해야 합니다.
Glance는 기본 대체 방식이지, 동등한 첫 번째 선택이 아닙니다. Lupi Editorial과 Lupi Basics가 모두 부적합하거나, 사용자가 명시적으로 Glance, dashboard, 모니터링, 주간 보고서, 3초 훑기를 요청한 경우에만 Glance를 사용합니다. 다운그레이드하기 전에 Lupi / Basics가 부적합한 구체적인 이유를 반드시 작성해야 합니다.
라이브러리 외부에서 새로 만드는 것은 최후의 수단입니다. Lupi, Basics, Glance 및 대화형 템플릿으로 모두 처리할 수 없는 경우에만 섹션 6의 번역 프로세스를 진행합니다. 새 차트는 여전히 가장 가까운 gallery 템플릿의 시각적 문법과 코드 구조를 상속해야 합니다.

1. 작업 흐름 (매 요청마다 이 6단계를 거침)

데이터 형태 판단. 사용자에게 어떤 차트를 원하는지 묻지 말고, 데이터가 어떻게 생겼는지 보십시오: 몇 가지 카테고리의 비교? 시간이 있는 시퀀스? 비율? 양수/음수 포함? 다대일 귀속? 네트워크? 레코드별 분포? 형태가 차트 선택의 기본 키입니다.
먼저 Lupi와 Basics를 감사합니다. 데이터 형태에 따라 이를 처리할 수 있는 모든 Lupi Editorial(L1–L15) 및 Lupi Basics(F1–F13) 후보를 스캔합니다. 최소 3개의 후보를 비교하고, 3개 미만이면 모든 후보를 나열합니다. 의미론적 적합성, 단위 정직성, 레이블 수용 능력, 읽기 속도, 내러티브 긴장감 및 이 배치에서의 중복 여부를 비교합니다.
필요할 때만 Glance를 확인합니다. Lupi와 Basics 후보가 모두 실패했거나, 사용자가 명시적으로 Glance / dashboard / 모니터링 / 주간 보고서 / 3초 훑기를 요청한 경우에만 Glance(G1–G18)를 스캔합니다. Glance를 선택할 때는 Lupi와 Basics가 처리할 수 없는 이유를 기록해야 하며, "Glance가 더 직관적이다"라고만 쓰면 안 됩니다.
실제 템플릿을 확정한 후에 전체 페이지를 구성합니다. 각 차트는 시스템, 차트 유형 번호, gallery 파일 및 카드 제목을 기록해야 하며, 해당 카드의 실제 구조와 렌더링 코드를 골격으로 사용해야 합니다. "이 페이지에서 6가지를 말할 것"을 먼저 생각한 다음 즉석에서 차트 유형을 만드는 것은 금지됩니다. 페이지 내러티브는 템플릿이 확정된 후에만 구성할 수 있습니다.
차트 수 규칙에 따라 배치를 구성합니다. 하나의 차트는 하나의 독립적인 결론만을 담당합니다. 중복 결론을 제거한 후 섹션 1.1의 기본 범위에 따라 수량을 결정합니다. 템플릿은 전역적으로 할당되어야 합니다: 중복 없음, 동일한 윤곽의 반복 없음, 수를 채우기 위해 차트를 억지로 추가하지 않음.
템플릿에 따라 렌더링하고 자체 점검합니다(섹션 0, 2, 3, 8). 완성된 결과물이 여전히 선택한 gallery 구현에 해당하는지 항목별로 확인합니다. 데이터를 변경했다고 해서 템플릿의 핵심 기하학, 인코딩 또는 동적 효과를 바꾸면 안 됩니다. 섹션 6.5에 따라 전체 납품을 위해 Mono 또는 하나의 컬러 프리셋을 선택합니다. 라이브러리 외부 차트 유형은 번역 프로세스(섹션 6)를 따릅니다.

1.1 차트 수 규칙

차트의 수는 독립적인 결론의 수에 의해 결정되며, "데이터 열이 몇 개인지" 또는 고정된 5~6장에 의해 결정되지 않습니다:

요청 유형	기본 완성물 수량	규칙
단일 질문 / 단일 테이블 / 하나의 지표	1	가장 강력한 하나만 납품하고, 템플릿을 보여주기 위해 확장하지 않음
두세 개의 명확한 결론	2–3	각 차트는 다른 결론을 담당하며, 동일한 데이터 소스를 공유할 수 있음
하나의 기사, 논문 또는 완전한 사례	4–6	개요, 구성, 비교, 관계 또는 변화 등 다양한 데이터 형태를 포함
사용자가 명시적으로 수량 요청	사용자 요청에 따름	그래도 중복 차트는 제거함; 충분하지 않으면 설명하고 더 적게 만듦

기본 단일 페이지 상한은 6장입니다. 6장을 초과하면 여러 페이지로 나누거나 장(chapter)별로 납품합니다.
후보 솔루션, Glance/Lupi 비교 초안은 최종 차트 수에 포함되지 않습니다. 이들은 선택 과정이지 완성된 배치가 아닙니다.
한 페이지에 여러 차트가 있는 경우 최소한 하나의 개요 결론을 유지하고, 나머지 차트는 새로운 비교 차원, 관계, 시간적 변화 또는 세부 증거를 제공해야 합니다.
두 차트가 동일한 결론을 표현하는 경우, 읽기 장면에 더 적합하고 데이터 계약이 더 정직한 하나만 유지합니다.

2. Mono 문법 · 엄격 규칙 (위반 시 재작업)

기본적으로 mono-tokens.js를 참조합니다(오픈 소스 배포 시 내용을 HTML에 인라인 처리). 토큰과 충돌하는 값은 항상 토큰을 우선합니다. 컬러를 사용하는 경우에는 색상 토큰만 교체하고, 글꼴, 둥근 모서리, 레이아웃 및 애니메이션은 여전히 mono-tokens.js를 기준으로 합니다.

색상

기본적으로 종이 회색 #F0EFEB와 숯검정 #1C1C1A 두 극단과 그 사이의 7단계 그레이스케일 사다리만 있습니다. 컬러 예외는 섹션 6.5에 따라 프리셋에서 시작합니다.
명도 = 데이터: 가장 중요 = 가장 검게(어두운 카드에서는 반전되어 가장 밝게). 여러 시리즈는 중요도에 따라 사다리를 따라 할당되며, 순서대로随便 가져가지 않습니다.
항상 단색: 불투명 재질, 발광 없음, 그라데이션 필터 없음, 그림자 없음. 질감은 전적으로 명도 대비와 형태에 의존합니다. 유일한 예외는 중첩형 차트(Radial Patchwork)에서 투명도 자체가 밀도를 인코딩하는 경우입니다. 이는 데이터이지 장식이 아닙니다.
어두운 카드(.card.dark)는 두 가지 차트에만 제공됩니다: 어두운 배경이 필요한 형태(꽃잎, 발광 실/네트워크 느낌). 기본값은 밝은 카드입니다. 한 화면(4카드)당 최대 1개의 어두운 카드.

타이포그래피

Inter 패밀리 전체. 제목 700 / 차트 내 숫자 800 / 축 레이블 600. 카드 구조는 고정 4종 세트: 결론형 제목(h2) + 부제(범례와 시간 범위를 여기에 쓰고 ·로 구분) + 차트 + 출처 행(모두 대문자, 자간 추가).
제목에는 결론을 쓰고 차트 유형명을 쓰지 않습니다: "Revenue by plan"은 괜찮고, "막대 차트"는 안 됩니다. 더 좋은 것은 판단을 포함하는 것입니다: "Where we gained, where we bled".
SVG 최소 글꼴 크기: 반폭 카드 6.5px, 전체 너비 5.5px. 들어갈 수 없는 정보는 hover로 빼내고, 글꼴 크기를 줄여 억지로 넣지 마십시오.

형태

카드 둥근 모서리 24px, 테두리 및 그림자 없음, 여백으로 카드 구분. 막대 끝 캡슐 둥근 모서리(세로 막대는 상단 둥글게, 가로 막대는 외부 끝 둥글게).
막대 차트는 축을 끊지 않습니다. 막대의 계약은 길이 ∝ 값입니다. 축을 끊으면 계약이 파괴됩니다. 극단값 시나리오의 올바른 접근 방식: ① 극단값을 하늘로 솟아오르게 함(가장 정직함) ② 메인 차트 + 확대경 작은 차트 ③ 막대를 찢되 축은 찢지 않음(분명히 그릴 수 없다고 말함).
꽃잎 껍질(굵은 검정 실 + 둥근 부채꼴)은 균등 또는 거의 균등한 방사형 차트에만 적용됩니다. 너비 차이가 큰 부채꼴은 서로를 가려 가독성을 떨어뜨립니다.

애니메이션

입장 애니메이션은 기본적으로 켜져 있으며, quarticOut 빠른 시작 및 정지, 튕기지 않음(웨이브 입장은 elasticOut 사용 가능). 도트 매트릭스 stagger 8–15ms/개, 막대 80–130ms/개.
통일된 reveal 메커니즘: 스크롤 시야에 들어올 때 재생 + 클릭 시 다시 재생(token의 obsReveal 사용, timer 정리 포함).
반드시 prefers-reduced-motion 다운그레이드 포함(token의 CSS에 이미 포함됨).
애니메이션은 구조보다 우선할 수 없습니다. 효과를 배치하기 위해 새로운 레이아웃을 발명해야 한다면, 그 효과는 존재할 가치가 없습니다(effectScatter 교훈).

데이터

데모 데이터는 token의 rnd(i,k) 결정론적 의사 난수를 사용하며, Math.random()은 금지됩니다. 새로고침할 때마다 동일하게 보여야 합니다.
숫자와 시각적 요소는 엄격하게 비례합니다. 면적 인코딩은 Math.sqrt(v)를 사용하여 반경을 변환하며, 숫자를 직접 반경으로 사용하지 마십시오.

3. 두 가지 스타일 시스템의 분업

동일한 mono 팔레트 아래에 두 가지 세계관이 있습니다. 상황과 독자가 얼마나 많은 시간을 투자할 의향이 있는지에 따라 선택합니다:

	Glance 계열 (18개)	Lupi 계열 (정독, 15개)
기본 단위	형태 (굵은 막대, 큰 호, 색상 블록)	레코드 (점 하나 = 데이터 하나)
선	2px+, 당당함	0.5–0.7px 머리카락 선
집계	미리 집계하여 결론 제시	집계 거부, 원자재 펼쳐 보임
읽는 방식	한눈에 (< 10초)	가까이서 읽음 (30초+)
사용 장면	주간 보고서, 대시보드, 간편 용도	연례 보고서, 외부 스토리 페이지, 포스터
엔진	Chart.js / ECharts	직접 작성 SVG

기본 전략: Lupi Editorial → Lupi Basics → Glance. 명확한 상황이 없을 때 기본적으로 Glance를 선택하는 것을 금지합니다. 연례 보고서, 공식 계정 장문, 포스터, 오픈 소스 README, 포트폴리오를 작성할 때는 Lupi Editorial을 먼저 선택합니다. 데이터가 적거나 친숙한 차트 유형에 적합할 때는 Lupi Basics를 선택합니다. 처음 두 그룹에 적절한 템플릿이 없거나, 사용자가 명시적으로 dashboard, 모니터링, 주간 보고서, 3초 훑기를 요청한 경우에만 Glance 후보 풀에 진입합니다.

전체 후보 감사는 "모든 차트를 다 만들어 보는 것"이 아닙니다. 먼저 데이터 형태로 동일한 본체를 인코딩할 수 있는 후보를 걸러낸 다음, 후보를 다음과 같이 나눕니다:

의미적으로 적합: 각 점, 선, 면, 구슬 뒤에 실제 단위 또는 명확한 집계 기준이 있음.
시각적으로 적합: 레이블을 넣을 공간이 충분하고, 밀도가 적절하며, 독자가 예상 시간 내에 읽을 수 있음.
내러티브에 적합: 그래픽 자체가 이 데이터가 전달하려는 판단을 담을 수 있으며, 단순히 숫자를 늘어놓는 것이 아님.

최종 선택은 이 세 항목의 교집합이며, "어느 템플릿 파일이 가장 복사하기 쉬운가"가 아닙니다. 기본 감사는 먼저 Lupi Editorial과 Lupi Basics 내에서 완료됩니다. 두 그룹이 모두 실패한 경우에만 Glance로 확장됩니다. 동일한 배치에서 여러 차트를 만들어야 하는 경우, 후보에 대해 전역 할당을 수행합니다: 템플릿 중복 없음, 형태 순환, 최대 하나의 어두운 카드, 전체 페이지가 여섯 개의 유사한 링 또는 가로 막대가 되지 않도록 방지.

데이터가 적은(몇 퍼센트일 뿐) 것이 Glance만 가능하다는 의미는 아닙니다. Lupi화의 올바른 길은 단위 분해입니다: 집계된 숫자를 셀 수 있는 단위(1점 = 1명 / 1퍼센트 포인트)로 다시 펼쳐 놓습니다. 밀도는 레코드 수가 아닌 단위에서 비롯됩니다. 단위 의미는 부제에 쓰고, 정직한 단위만 펼쳐 놓습니다(비율 합계 100 → 100개 점). 존재하지 않는 개별 레코드를 조작하지 마십시오. 반올림 시 합계가 100이 안 되는 경우(예: 49.0+27.4+13.9+5.0+3.2 → 98), 각주에 "나머지 N명은 반올림되어 사라졌습니다"라고 쓰고, 가짜 단위를 만들지 마십시오.

소규모 데이터가 Lupi를 따르는 경로 우선순위(여러 사례 검증됨):

먼저 전체 스캔 후 코드 골격 선택 — 기본형 그룹 F1–F13(templates/basics-gallery.html)은 희소 데이터를 위한 Lupi 어휘(막대/꺾은선/영역/도넛/가로 막대/그룹/누적/산점/폭포/히트맵/진행/덤벨/트리맵)입니다. 편집형 L1–L15는 레코드별, 단위 분해, 관계 및 주석 문법을 제공합니다. basics-gallery.html에 기성 코드가 있다고 해서 바로 F 차트를 선택하지 마십시오.
가장 본체에 가까운 템플릿으로 시작 — 객관식 백분율은 L15, F5, L2를 우선 비교합니다. 100% 구성은 L14, L5, F4, G4를 우선 비교합니다. 퍼널은 L13, F1/F5의 다운그레이드 표현을 우선 비교합니다. 선택 기준은 데이터 인코딩 방식이지 파일 순서가 아닙니다.
라이브러리에 실제로 해당 형태가 없는 경우에만 새로 만들며, 새로 만들 때는 반드시 gallery의 기존 문법에서 확장해야 합니다(머리카락 두께 tick, 결정론적 rnd 지터, paint-order 글로우, 대문자 표기). 라이브러리 외부 참조를 도입하지 마십시오. "Lupi 스타일"은 gallery의 해당 차트들의 시각적 문법을 의미하지, Giorgia Lupi本人的 수작업 스타일을 의미하지 않습니다.
새로 만든 소규모 데이터 차트는 환경 구조 레이어로 가득 채워야 합니다. gallery의 멋짐은 절반이 데이터가 없는 가구(장부 종이 가로선, 점선 가이드, rim 눈금, 10단위 기둥 그리드, 주석 인출선)에 의존합니다. 데이터 레이어는 정직하게 희박하게 만들고, 밀도 예산은 가구에 사용합니다. 데이터 + 바닥선 하나만 있는 소규모 데이터 차트는 반드시 초라해 보입니다.

동일 배치(한 페이지 여러 차트) 내에서 템플릿이 중복되지 않습니다. 15개의 Lupi 계열이 순환하기에 충분합니다. 동일한 데이터가 여러 템플릿으로 처리될 수 있는 경우, 이 배치에서 아직 사용되지 않은 것을 선택합니다.

4. 차트 유형 결정 트리 (데이터 형태 → 후보)

번호는 catalog.md에 해당합니다. 이는 후보 리콜 테이블일 뿐이며, 화살표와 작성 순서는 우선순위를 나타내지 않습니다. 실제 선택은 다음을 준수해야 합니다: 먼저 모든 Lupi Editorial과 Lupi Basics 후보를 확인하고, 적절한 템플릿이 없음을 확인한 후에만 Glance 후보를 사용할 수 있습니다.

소수 카테고리 비교(≤8) → G3 Chunky Bars ⇄ 세로 F1 Rung Bars / 가로 F5 Tick Rows ⇄ L2 Dot Cascade (⚠️ cascade는 카테고리명을 세로로 표시하며, 이름이 ≤4자 또는 짧은 약어인 경우에만 사용 가능; 긴 한글 카테고리는 F5/L5/L12로 변경)
객관식 백분율 (각 항목 독립 0–100, 합계는 100 초과 가능) → G3 Chunky Bars ⇄ L15 Ballot Tally
다중 카테고리 분포 (30–60개) → G12 Stagger Wave
양수/음수가 있는 카테고리 값 → G10 Diverging Bar
비율 / 100% 구성 → G4 Dot Waffle ⇄ L14 Hundred Field ⇄ F4 Tick Donut (파이 차트의 기본 대체); 거의 균등 분할이고 멋져야 하는 경우 → G2 Petal Rose; 비율 × 강도 이중 인코딩 → G13 Big Slice; 카테고리별 누적 → F7 Stacked Rungs
두 시점 비교 (전후 / 과거-현재) → 카테고리 수준(≤6개 카테고리) → F12 Dumbbell Queue (가로, 구슬 = 실제 단위) ⇄ F6 Paired Rungs (나란한 쌍 사다리); 2–4개의 시리즈만 추세선을 그려야 하는 경우 → Glance chunky slope (굵은 선, 큰 숫자, 결론을 제목에 삽입). 교차가 너무 많은 기울기 차트는 가독성을 크게 떨어뜨리므로, Lupi화를 위해 장식 구조를 추가하지 마십시오.
일일 시퀀스 (≤30일, 구간 포함) → G1 Range Capsules ⇄ 일별 판독 F2 Hairline Line ⇄ (90일 수준, 질감 필요) L3 Barcode Lollipop; 30–60일은 형태 확인 → F3 Hairline Area
누적 성장 → G18 Draw-in + Counter
이중 시퀀스 인과 (투입 vs 산출) → G8 Rainfall
실시간 데이터 → G17 Dynamic Stream
순위의 시간에 따른 변화 → G16 Bar Race
요일×시간×수량 → G14 Single Axis ⇄ F10 Dot Heat
폭포 / 증감 분해 (≤6단계) → F9 Rung Waterfall
단일 값 진행 (0–100%) → F11 Tick Gauge ⇄ G18 Draw-in + Counter
2차원 산점 (≤20점) → F8 Plumb Scatter; 수백 점 분포 → G15 Jitter Strip
그룹 분포, 레코드별 기록 → G15 Jitter Strip
카테고리×카테고리+수량 (행렬) → 가벼움 (≤100셀) L4 Arc Matrix ⇄ 무거움 (큰 범위, 주석 필요) L9 Bubble Almanac
다대일 귀속 → 형태 강조 L5 Radial Convergence ⇄ 명단 포함 L12 Type Colonnade
퍼널 / 단계별 감소 → L13 Hourglass Stream
계층 구조 → G7 Tree LR
계층 + 비중 / 가중치 (두 레벨, 값은 양수) → F13 Nested Treemap; 누가 누구에게 속하는지만 보기, 크기 비교 안 함 → G7 Tree LR
이벤트 시퀀스 생애사 → L11 Trend Lineage
다중 개체 출생 시간 + 현재 상태 → L1 Launch Fan
이벤트별 시간 분포 (하루 내) → L10 Radial Patchwork
양극 척도 (양쪽 끝 모두 유효) → L7 Brand Spectrum. 단극 점수(레이더)와 구별하십시오. 단극은 ECharts 기본 레이더 사용
네트워크 → ≤15 노드 G6/G11 작은 차트; >15 또는 숫자 확인 필요 → B1 링 / B2 힘 기반; 다중 경로 흐름 → B3 Threads
다중 그룹 × 그리드 (장식성 필요) → L8 Dotty Matrix; 숫자 판독 필요 → G14 사용
동일 개체 집합의 다차원 슬라이드쇼 (데모) → G9 Scatter Morph

F13 Nested Treemap 엄격 규칙

계층적 데이터와 음수가 아닌 가중치만 수신합니다. 상위 값은 하위 값의 합계로 계산되며, 상위-하위 총계가 모순되는 것을 금지합니다. 면적은 ECharts treemap 레이아웃에 직접 위임하며, 값에 대해 제곱근을 취하지 않습니다.
기본적으로 두 레이어(상위 그룹 + 리프)를 표시합니다. 두 레이어를 초과하고 독자가 레이어별로 질의해야 하는 경우에만 drill-down을 활성화합니다. 일반 정적 납품은 nodeClick:false를 유지하여 실수로 터치하여 뷰가 변경되는 것을 방지합니다.
Mono의 그레이스케일은 계층만 나타내며, 각 리프에 무작위로 밝고 어두움을 할당하지 않습니다. 상위 그룹은 제목 띠, 그룹 간 여백 및 경계로 구분합니다. 색상을 제거한 후에도 그룹을 명확히 볼 수 있어야 합니다.
porcelain은 단일 색조의 명도를 사용하여 순서가 있는 상위 그룹 비중이나 계층을 나타냅니다. palm은 최대 4개의 최상위 카테고리에 해당하는 색조를 사용합니다. wire는 그레이스케일을 유지하며, 명확한 주인공 하나만 HERO를 사용할 수 있습니다.
면적이 이미 값을 표현하는 경우, 색상은 설명 없이 동일한 값을 다시 반복해서는 안 됩니다. 부제는 area = ...를 명확히 써야 하고, 컬러를 사용하는 경우 color = ...도 명확히 써야 합니다.
리프가 30개를 초과하거나, 레이블이 대부분 생략되거나, 최소 사각형이 안정적인 핫존을 형성할 수 없을 정도로 작은 경우, 먼저 긴 꼬리를 Other로 병합하거나, 여러 개로 분할하거나, G7 / L12 / B 계열 관계형 차트를 사용합니다.
Tooltip은 최소한 전체 계층 경로, 원래 값 및 총량 대비 비율을 표시해야 합니다. 카드 내 레이블을 넣을 수 없으면 숨기고, 최소 글꼴 크기 미만으로 줄이지 마십시오.

5. 대화형 질문 3가지 (정적 또는 대화형 결정)

순서대로 질문합니다:

이 선/점 뒤에 실제 레코드가 있는가? 없음(순수 질감 장식, Cluster Field의 스포크, Hourglass의 흐르는 선 등) → 대화형 추가 금지. 내용이 없는 요소에 hover를 추가하는 것은 속임수입니다.
레코드 있음 → 클릭하지 않고도 읽을 수 있는가? 요소 < 50개이고 양쪽 끝에 주석이 있는 경우(예: Colonnade) → 정적으로 충분함, hover는 옵션입니다.
요소 > 50개 또는 다중 경로(예: Threads) → 반드시 hover/pin 필요, 그렇지 않으면 분위기 차트일 뿐. 대화형 구현은 templates/big-threads.html을 참조하십시오: 보이는 선 아래에 9px 투명 쌍둥이 선을 깔아 핫존으로 만들고, hover 시 단일 선이 전체 경로를 강조하고, hover 시 레이블이 전체 묶음을 당기고, 클릭 시 고정.

6. 라이브러리 외부 차트 유형 · 번역 프로세스

사용자가 원하는 차트가 49개 유형에 없거나(참조 차트를 보내는 경우), 할 수 없는 것이 아니라, 즉석에서 문장을 만드는 것입니다. 프로세스는 4단계이며, 첫 번째 단계는 건너뛸 수 없습니다:

먼저 본체에 답하십시오: 이 차트 유형은 무엇을 인코딩합니까? 각 시각적 채널(위치/길이/각도/면적/명도/밀도)은 각각 어떤 데이터 차원에 해당합니까? 대답할 수 없으면 사용자에게 데이터 구조를 요청하십시오. 형태를 베끼고 본질을 놓치는 것은 헛수고입니다(pictorial bar가 "기호 개수"를 잘못 "나무가 자라는 것"으로 만들어 재작업한 사례).
가장 가까운 친척을 찾으십시오: catalog에서 데이터 형태가 가장 유사한 것을 시작점으로 선택하고, 그 레이아웃 골격과 애니메이션 템포를 상속하십시오.
토큰으로 문장을 만드십시오: 팔레트, 글꼴, 둥근 모서리, 애니메이션 매개변수는 모두 mono-tokens.js에서 가져오며, 새로운 색상이나 글꼴 크기를 발명하지 마십시오. 결과물은 라이브러리의 차트와 "한 가족처럼" 보여야 합니다. 컬러를 사용하는 경우 색상은 color-presets.js의 단일 프리셋에서 변경하며, 다른 토큰은 여전히 mono-tokens.js를 기준으로 합니다.
섹션 2의 엄격 규칙과 섹션 8의 자체 점검을 통과해야 하며, 라이브러리 내 차트와 동일한 기준을 적용합니다.

참조 차트 번역에 대한 추가 규칙: 참조 차트가 어떤 계열(Glance 또는 편집부)에 속하는지 식별합니다. 편집부 스타일의 밀도, 주석, 손으로 그린 느낌(blob)은 본체의 일부이므로 제거하지 마십시오. almanac이 "감히 좁힐 수 없다"는 이유로 재작업한 사례가 있습니다.

6.5 컬러 (시나리오에 따라 자동 선택, 단일 색상 시스템)

Mono는 대체 솔루션이지, 컬러가 트리거되지 않았을 때의 강제 답변이 아닙니다. 사용자가 색상을 언급하지 않았더라도 데이터 의미론, 카테고리 수, 읽기 장면 및 콘텐츠 성격에 따라 컬러가 적합한지 평가해야 합니다. 적응 관계가 명확하지 않거나 색상이 실제 정보 가치를 제공하지 않는 경우 Mono로 돌아갑니다.

컬러 초안은 세 가지 프리셋 중 하나를 선택하여 시작하며, 색상 값은 color-presets.js에 있고, 샘플은 templates/color/에 있습니다. 프리셋은 빠르게 안정적이고 통일된 첫 번째 버전을 얻기 위한 것이지, 고정된 팔레트가 아닙니다. 사용자가 "이 파란색을 좀 더 진하게" 요청하면 현재 색상 시스템 내에서 계속 조정합니다. 사용자가 브랜드 색상, 색상 값 또는 전체 팔레트를 명시적으로 제공하는 경우, 아래 규칙에 따라 custom 팔레트를 설정합니다. 조정 후에는 반드시 대비, 시각적 위계 및 데이터 의미론을 다시 확인해야 합니다.

동일한 HTML 또는 동일한 납품 세트는 먼저 전역 색상 시스템(Mono, porcelain, palm, wire 또는 custom 하나)을 고정해야 합니다. 모든 차트는 해당 선택을 공유합니다. 특정 차트가 선택한 시스템을 지원하지 않는 경우, 단독으로 색상을 변경할 수 없습니다. 전역적으로 호환되는 시스템으로 변경하거나 전체 그룹을 Mono로 되돌립니다.

구조적 원본은 항상 원본 gallery입니다. 렌더링 코드는 templates/ 루트 디렉토리의 gallery에서 확인하고, templates/color/는 색상 구성만 확인합니다. 먼저 섹션 0에 따라 구조를 선택한 다음, 스킨 변경 여부를 결정합니다.

컬러 사용 여부

다음 우선순위로 판단합니다:

사용자가 명시적으로 지정. 사용자가 특정 색상, 분위기 또는 프리셋을 요구하면 우선 따르지만, 여전히 용량, 대비 및 데이터 의미론 검사를 통과해야 합니다.
Agent 자동 선택. 사용자가 색상을 언급하지 않았더라도, 데이터 형태와 장면이 특정 프리셋과 명확한 대응 관계가 있으면 자동으로 사용할 수 있습니다: 순서가 있는 단일 시퀀스는 porcelain에 적합합니다. 소수의 순서 없는 카테고리는 palm에 적합합니다. 통제된 시선 지점이 필요하면 wire에 적합합니다.
관계가 명확하지 않으면 Mono를 사용합니다. 카테고리가 너무 많거나, 고밀도 레코드이거나, 색상이 안정적인 의미를 갖지 못하거나, 전체 차트 그룹이 동일한 프리셋을 공유할 수 없는 경우 Mono를 사용합니다.

컬러는 업그레이드 버전이 아니라 Agent가 능동적으로 선택할 수 있는 의미론적 도구입니다. 납품 시 한 문장으로 선택한 색상 시스템과 그 데이터적 의미를 설명하십시오.

사용자 정의 팔레트 (사용자가 명시적으로 요청한 경우에만 활성화)

Agent는 스스로 다섯 번째 기본 심미성을 발명할 수 없습니다. 사용자가 명확한 색상 값, 브랜드 색상, 브랜드 가이드라인 또는 "이 참조 차트의 색상을 따라"를 제공하는 경우에만 custom 팔레트를 설정합니다. 단순히 "좀 더 예쁘게"라고 말하는 경우는 여전히 세 가지 내장 프리셋 중에서 선택합니다.

먼저 색상 로직을 결정한 다음 색상 값을 할당합니다. 순서 있는 데이터는 단일 색조 명도 그라데이션을 사용합니다. 순서 없는 카테고리는 구분 색상을 사용합니다. 초점이 필요한 경우 중성 색상 + 하나의 강조 색상을 사용합니다. 먼저 다섯 가지 색상을 얻은 다음 모든 요소에 균등하게 뿌리는 것을 금지합니다.
전체 역할을 설정하고, hex를 직접 흩뿌리지 마십시오. custom은 최소한 BG, TXT, MUT, GRID, DATA를 정의해야 합니다. 강조가 필요하면 HERO를 정의하고, 순서 있는 데이터는 RAMP를 정의하고, 분류 데이터는 CAT를 정의합니다. 완성물 내에 CUSTOM 객체를 인라인 처리하고, 모든 차트는 역할에서 색상을 가져옵니다.
입력 수량에 따라 해석합니다. 1개의 색상은 동일한 색조 명도 그라데이션을 생성합니다. 2개의 색상은 기본적으로 주 데이터 색상 + 강조 색상으로 구분되며, 자동으로 두 개의 동등한 카테고리로 간주하지 않습니다. 3–6개의 색상은 데이터가 실제로 해당 카테고리를 가질 때만 CAT에 진입합니다. 6개 초과 시 먼저 카테고리를 병합하고, 위치/레이블을 사용하거나 Mono로 되돌립니다.
명도 파생은 허용하지만, 새로운 색조의 밀입국은 허용하지 않습니다. 밝은 색상은 사용자 색상과 BG를 혼합하고, 어두운 색상은 사용자 색상과 TXT를 혼합합니다. porcelain, palm, wire의 색상 값을 빌려 custom을 보완하는 것을 금지합니다.
대비는 엄격한 기준입니다. 본문 및 작은 레이블은 배경 대비 최소 4.5:1, 큰 글자는 최소 3:1을 유지해야 합니다. 주요 경계, 데이터 형태 및 상호작용 상태는 인접 색상 대비 최소 3:1을 유지해야 합니다. 기준에 미달하면 명도를 먼저 조정하고, 사용자가 지정한 주 색조를 임의로 변경하지 마십시오.
색상은 유일한 단서가 될 수 없습니다. 분류에는 여전히 레이블이 있고, 서수 데이터는 여전히 위치/길이/면적을 유지하며, 강조는 여전히 제목 또는 주석 설명이 있습니다. 색각 이상 사용자가 색상을 제거한 후에도 차트의 구조를 읽을 수 있어야 합니다.
한 번에 이 custom 하나만 고정합니다. custom은 내장 프리셋과 혼용되지 않습니다. 여러 차트 납품은 동일한 CUSTOM을 공유합니다. 사용자가 브랜드 색상을 프로젝트 수준 프리셋으로 고정하도록 명시적으로 요청하지 않는 한, custom은 현재 완성물에만 인라인 처리되고 color-presets.js에 다시 기록되지 않습니다.

사용자가 이후에 "좀 더 진하게", "배경을 좀 더 따뜻하게" 요청하거나 특정 색상 값을 교체하는 경우, 해당 역할을 수정하고 전체 대비 및 의미 매핑을 다시 확인하며, 지목된 요소만 수정하지 마십시오.

어떤 프리셋을 선택할까: 먼저 데이터 형태를 보고, 그 다음 분위기를 보십시오

데이터 형태	허용	이유
순서 있음 / 단일 시퀀스 (진행, 히트맵, 타임 시리즈, 단일 지표, 순위)	porcelain, wire	명도 = 데이터의 계약이 여전히 유효
순서 없는 카테고리 ≤4	palm	색조가 카테고리에 해당
순서 없는 카테고리 5–6	palm(간신히)	명도와 채도로 구분 보조
카테고리 >6	Mono 그레이스케일	컬러 프리셋 용량 부족
절제 필요하지만 시선 집중점 하나 필요	wire	그레이스케일이 데이터를 담고, 주황색은 주인공만 표시

사용자가 말할 것	프리셋	분위기
파란색, 차가움, 학술, 이성, 진지함, 테크 느낌	porcelain	단일 색조 파란색 계열
초록색, 따뜻함, 자연, 부드러움, 레트로, Morandi	palm	초록-노랑 저채도, 호박색 포인트
흑백, 절제, 잡지 느낌, 편집부	wire	흑회색 + 약간의 형광 주황색

컬러 엄격 규칙

동일 납품에는 하나의 색상 시스템만 사용합니다. 하나의 차트, 동일한 HTML 또는 동일한 자매 차트 그룹은 Mono, color-presets.js의 한 프리셋, 또는 사용자가 명시적으로 요청한 하나의 custom만 사용해야 합니다. 프리셋 간 혼용을 금지하며, custom이 내장 프리셋의 색상을 빌려 보완하는 것도 금지합니다.
선 두께 × 1.8, 투명도 바닥 .85. 그레이스케일의 머리카락 선은 연한 색상으로 바꾸면 쉽게 사라집니다. dot heat는 예외입니다.
각 차트는 최소 3개의 색조 또는 색상 단계를 가져야 합니다. 1–2개의 색상만 사용하면 그레이스케일로 되돌립니다.
색상은 반드시 실제 차원에 연결되어야 합니다. 서수 그라데이션은 값에 연결되고, 구분 색상은 월 또는 섹션에 연결되며, 분류 색상은 카테고리에 연결됩니다. 각주에 색상이 무엇을 인코딩하는지 명확히 씁니다.
강조 색상은 오직 하나의 주인공에게만 제공됩니다. 두 번째 주인공은 강조를 무력화합니다.
어두운 카드 데이터 색상은 카드 배경보다 밝아야 합니다. 어두운 배경의 큰 차트는 preset의 DARK 블록을 사용합니다. big-circular / big-force / big-threads는 porcelain과 palm만 있습니다. wire는 원본 Mono 대형 차트를 사용합니다.
palm에서 DATA와 HERO는 반드시 달라야 합니다. 호박색과 올리브색은 명도가 비슷하므로, 둘을 동등한 카테고리 색상으로 취급하지 마십시오.

7. 거절해야 할 때

무엇이든 받아들이는 것보다 거절하는 것이 더 신뢰를 줍니다. 다음 경우에는 작업하지 않고 대안을 제시합니다:

축이 끊긴 막대 차트 → 거절, 세 가지 정직한 솔루션 제공(하늘로 솟아오르기 / 확대경 / 막대를 찢되 축은 찢지 않음).
발광 / 유리질감 / 3D → 거절, 기존 시각적 문법 유지. 사용자 정의 색상 값은 custom 규칙에 따라 매핑. 색상 시스템 간 혼용은 거절.
다중 색조로 단일 시퀀스 그리기 → 거절. porcelain, wire 또는 Mono로 되돌림.
카테고리 >6인데 컬러 요청 → 거절, Mono 그레이스케일로 되돌림.
지도 유형(choropleth, 경로 지도) → 라이브러리에 지리 파이프라인이 없으므로, 솔직히 할 수 없다고 말하고 억지로 그리지 마십시오.
순수 장식 요소에 대화형 추가(섹션 5 질문 1) → 거절하고 설명.
레이더 차트 재구성 → 재구성하지 않음, ECharts 기본 레이더 + Mono token 스킨 변경 사용(실제 테스트 완료: 프레젠테이션 장면에서 "알아볼 수 있는 차트 유형"이 가치 있음).
데이터가 너무 적어 선택한 차트 유형을 지탱할 수 없음(예: 3개의 노드로 힘 기반 레이아웃) → 더 단순한 차트로 다운그레이드하고 설명.

8. 납품 전 자체 점검 목록

숫자와 시각적 요소가 비례하는가? (면적에 sqrt 사용? 막대 축 안 끊김?)
팔레트가 통제되었는가? 전체 HTML 또는 동일 납품 세트가 Mono, 단일 내장 프리셋 또는 단일 custom만 사용하는가? Mono에 사다리 이외의 색상이 나타나면 즉시 재작업. 내장 컬러에 다른 프리셋 색상이 나타나면 즉시 재작업. custom이 CUSTOM 역할에서만 색상을 가져오고 대비 검사를 통과했는가?
레이블이 겹치지 않는가? (barcode 교훈: 인접 피크 레이블은 최소 간격을 강제해야 함)
최소 글꼴 크기를 위반하지 않았는가? (반폭 6.5 / 전체 너비 5.5)
데모 데이터가 rnd 결정론적인가? 두 번 새로고침해도 동일한가?
reveal이 정상 작동하는가? (스크롤 시 재생, 클릭 시 다시 재생, timer 중복 없음, reduced-motion 다운그레이드 존재)
node --check 구문 검사 통과( <script> 내용을 추출하여 확인).
카드 4종 세트가 완비되었는가? 제목이 결론이고 차트 유형명이 아닌가?
부제가 범례를 명확히 설명했는가? (독자가 코드를 보지 않고 이 한 줄만으로 이해할 수 있는가?)
전체 후보 감사를 완료했는가? 최소 3개의 후보와 탈락 이유를 기록하고, 단순히 "어떤 템플릿을 채택했습니다"만 기록하지 않았는가?
한 페이지에 여러 차트인 경우, 템플릿이 전역적으로 할당되었는가? 유사한 윤곽의 반복, 어두운 카드 과다, 모든 차트가 동일한 방사형 차트가 되지는 않았는가?
각 차트에 차트 유형 번호, gallery 파일 및 카드 제목이 기록되었는가? 완성품의 핵심 구조가 실제로 해당 템플릿에서 비롯되었는가, 재발명한 것은 아닌가?
Glance를 사용하는 경우, Lupi Editorial과 Lupi Basics가 왜 모두 부적합한지 명시했는가? 그렇지 않으면 Lupi / Basics로 재작업해야 함.
마지막 질문: 이 차트를 선택한 gallery의 해당 카드 옆에 놓았을 때, 동일한 템플릿 패밀리인가, 아니면 단지 "스타일이 비슷한" 것인가?

9. 단일 파일 템플릿 골격

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>Mono — {차트명}</title>
<!-- ECharts 필요 시: -->
<script src="https://cdn.jsdelivr.net/npm/echarts@6/dist/echarts.min.js"></script>
<!-- Chart.js 필요 시 (G1 / G3): -->
<!-- <script src="https://cdn.jsdelivr.net/npm/chart.js@4/dist/chart.umd.min.js"></script> -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link href="{MONO.FONT.link}" rel="stylesheet">
<style>/* MONO.CARD_CSS 인라인 */</style>
</head>
<body>
<div class="grid2">
  <div class="card"><!-- 또는 card dark / card wide -->
    <h2>{결론형 제목}</h2>
    <div class="sub">{설명} · {범례} · {시간 범위}</div>
    <!-- 차트 컨테이너는 엔진에 따라 3가지 중 하나 선택: -->
    <div class="ch" id="ch"></div><!-- ECharts -->
    <!-- 직접 작성 SVG: <svg id="ch" viewBox="0 0 400 320"></svg> -->
    <!-- Chart.js (G1/G3): <div class="wrap"><canvas id="ch"></canvas></div>, .wrap{position:relative;height:320px} 함께 -->
    <!-- ⚠️ Chart.js 필수: 컨테이너 래퍼와 고정 높이. -->
    <div class="source">{출처}</div>
  </div>
</div>
<script>
// MONO.TOKENS 인라인
// rnd, obsReveal 등 유틸리티
</script>
</body>
</html>

마크다운 렌더시 유의사항: <style>과 <script> 사이의 내용은 토큰 객체, 유틸리티 함수 및 차트 렌더링 코드가 인라인으로 포함된 완전한 실행 파일입니다. 삭제하거나 다시 작성하지 마십시오. 최종 사용자에게는 완전한 단일 HTML 파일을 보내십시오.

축약 규칙: 완성된 <script> 내에서 const { ref, effect } = Vue;로 객체 분해를 사용하여 반복적인 MONO.TOKENS.X 작성을 피할 수 있습니다.

Lieflat Charts는 데이터 차트의 품질과 가독성을 향상시키도록 설계된 Agent Skills 형식의 데이터 시각화 도구입니다.

Lieflat Charts — 차트 취향 법전