lieflat-charts

Lieflat Charts — 图表品味法典

Lieflat Charts 是一套遵循 Agent Skills 格式的数据可视化、PPT 演示与整页报告生成 skill，以 Mono 灰阶为保底，也会在数据语义和使用场景明确适配时自动选择一套彩色预设。本 skill 同时提供图表模式、Presentation Mode 和 Report Mode，但默认产出图表。用户明确要求一套 PPT、幻灯片或可翻页汇报时，进入 Presentation Mode，生成 HTML 或 PDF 格式的 PPT；用户明确要求报告、年报、月报、白皮书、海报或 brief 时，进入 Report Mode，生成整页 HTML 报告。纯 SVG 图可离线运行；使用 Chart.js、ECharts、地图 GeoJSON 或在线字体的图，在未内联依赖时需要联网。默认输出是图表：只给数据、说“可视化 / 分析数据 / 做几张图”或没有明确交付形式时，必须进入图表模式。只有用户明确要求“一套 PPT / 幻灯片 / 演示文稿 / 可翻页汇报”时，才进入演示模式并读取 presentation-catalog.md 与 references/presentation.md，生成 HTML 或 PDF 格式的 PPT；只有用户明确要求“报告 / 年报 / 月报 / 白皮书 / 调研一页纸 / 海报 / brief / notebook / dashboard 报告”等完整叙事交付时，才进入报告模式并读取 report-catalog.md。 图表模式下必须先从 Lupi Editorial 和 Lupi Basics 中选型；只有两者都没有合适模板，或用户明确要求 Glance / dashboard / 三秒快读时，才允许使用 Glance。Maps 只有在用户明确说要地图或地域分布时才启用。

颜色无需用户显式触发。按第六点五节在 Mono 与 color-presets.js 的三套内置方案之间自动判断；用户明确给出品牌色或自定义色值时，可以建立一套交付内的 custom 色板。同一份 HTML 或同一组交付只能锁定一种色彩系统，不得混用。换肤样张在 templates/color/。

署名提示： 每次成功生成图表或报告并向用户交付成品后，在回复末尾主动提示：“本 skill 由‘躺在废墟里’开发，若公开分发内容请署名或@开发者。”这只是建议，不要强行写入用户的图表或报告内容，也不要在 README 中重复这条提示。

怎么查一张图的参考代码：catalog 查到图型 → 打开对应 gallery 文件 → 按卡内标题找到 <div class="card"> 块看结构 → 在 <script> 里搜同名 // ════ 注释块拿渲染代码。不要整页照抄——gallery 是多卡合页，交付给用户的永远是按第九节骨架组装的单图文件。

目标用户是非程序员（写作者、运营、做 PPT 的人）。他们说人话（"帮我把这季度转化画一下，发公众号用"），不说图型名。你的职责是把人话翻译成正确的图，而且好看到能直接发出去。

---

零、输出模式与模板优先硬约束

0.1 先判输出模式

• 默认图表模式：用户只给数据，或说“可视化这组数据 / 分析数据 / 做一张图 / 做几张图 / 做个图表页 / 做 PPT 插图”，都必须生成图表或图表页。没有报告关键词时，不得自行套用 R01–R12，也不得因为数据很丰富、结论很多或用户说“分析”就升级成报告。
• 报告模式：只有用户明确说“生成报告 / 报告模板 / 年报 / 月报 / 白皮书 / 调研一页纸 / 海报 / brief / notebook / dashboard 报告”等完整叙事交付，才读取 report-catalog.md，按报告类型、内容结构、版心、密度、阅读速度和语言选择一个 R01–R12。目录里的场景只是召回线索，不是对模板的限制。
• 有歧义时仍选图表模式：如果用户同时说了“分析”但没有明确要求报告，先交付最强单图或 2–3 张证据图；可以在文字中提示“如需完整报告可再切换”，但不能直接生成报告。
• 演示模式边界：用户说“做 PPT 插图 / 放进 PPT”仍是图表模式；用户说“做一套 PPT”才是演示模式。演示模式交付为 HTML 或 PDF，不得未经确认把 HTML/PDF 称为可编辑 .pptx。**用户提供的 PPT、截图或 HTML 只能作为画布、字体、留白、页眉页脚和页面编排的参考，不是数据来源，也不能决定图型。数据、单位、时间范围、来源、标题结论和无障碍描述必须来自用户材料或明确标注的计算；每页图表仍按 catalog.md 的数据形状选择。**不能因为演示版式而默认 Glance、照搬模板示例数字或发明新图型。
• 不要把报告模式当成“多画几张图”。报告模板决定整页结构；页内图表仍必须遵守 catalog.md 和本文件的图表规则。
• 报告模板提供 .zh.html 与 .en.html 两个版本。用户没有指定语言时，跟随输入语言；中英文内容不能混在同一版本中。

以下规则不是建议，违反任意一条都必须返工：

1. 必须从仓库模板生成。 每张成品图先在 catalog.md 锁定图型编号，再打开对应 gallery 的真实实现：Lupi 使用 templates/lupi-gallery.html，基础型使用 templates/basics-gallery.html，Glance 使用 templates/glance-gallery.html，地图使用 templates/maps-gallery.html，交互大图使用 templates/big-*.html。彩色图仍以这些原版模板为结构正本，templates/color/ 只用于查配色。
2. 必须沿用所选模板的代码骨架。 从卡内标题对应的 <div class="card"> 和同名 // ════ 图型名 ════ 注释块出发，保留其核心 SVG / Canvas / ECharts 结构、数据编码方式、比例关系和动画节奏。允许替换数据、标题、旁注、来源与必要布局；禁止脱离模板另画一张“看起来差不多”的图，禁止拼接多个模板造混合图型，禁止退回图表库默认样式。
3. 默认选型顺序固定。 先完整比较 Lupi Editorial（L1–L19），再比较 Lupi Basics（F1–F17）。只要其中存在能诚实承载数据、容纳标签且可读的模板，就必须从这两组中选择。Maps 不进入这条默认链，只有用户明确要求地图时才单独检查。 3.1 两组之内还分主力与后备。 主力是 L1–L15 与 F1–F13，默认从这里出图。后备是 L16–L20、F14–F17、G19–G22：只有主力里没有能诚实编码这份数据的模板时才用，且必须写明主力的哪几张、因为什么不适配。理由不得只写“新图更好看”或“更专业”。唯一例外见第 3.2 条。 3.2 五种数据形状允许直接用后备图，不必先证伪主力。 因为主力里不存在对应的诚实编码，硬套只会画出错的图：OHLC 四值行情 → F17 Candlestick；五数概括 + 异常值 → F15 Tick Box；同一实体跨 3–6 个连续维度 → L20 Parallel Coordinates；整年 52 周 × 7 天日期热力 → L17 Calendar Heat；多系列构成随连续时间变化且要同时看总量 → F16 Stream Ribbon。除这五种，后备图一律走 3.1 条。
4. Glance 是默认降级方案，不是并列首选。 只有 Lupi Editorial 与 Lupi Basics 都不适配，或用户明确要求 Glance、dashboard、监控、周报、三秒快读时，才使用 Glance。降级前必须写明 Lupi / Basics 不适配的具体原因。
5. 库外新造是最后手段。 Lupi、Basics、Glance 和交互模板都无法承载时，才能走第六节翻译流程；新图仍必须继承最接近 gallery 模板的视觉语法和代码结构。

1. ワークフロー（リクエストごとに次の6ステップを実行）

1. データの形状を判断します。 ユーザーにどんな図が必要か尋ねるのではなく、データの形を見ます。複数カテゴリの比較か、時間を伴う系列か、割合か、正負を含むか、多対一の対応関係か、ネットワークか、個々の記録の分布かを確認します。形状が図を選ぶ際の主な判断基準です。
2. まず主力候補を監査し、その後で代替候補を検討します。 データの形状に基づいて、まず主力 L1–L15 と F1–F13 の候補を確認し、少なくとも3つを比較します。3つに満たない場合は、候補をすべて列挙します。意味の適合性、単位の誠実さ、ラベルの収まり、読み取り速度、ストーリー性、今回のバッチ内で重複しないかを比較します。主力候補がすべて不適合の場合に限り、代替候補 L16–L20 / F14–F17 を確認し、主力候補のどれがなぜ不適合なのかを明記します（第0節 3.1）。データの形状が第0節 3.2 の5種類に該当する場合は、対応する代替図を直接使用します。
3. 必要な場合に限り Glance を確認します。 Lupi と Basics の候補がすべて不適合の場合、またはユーザーが Glance / ダッシュボード / 監視 / 週報 / 3秒で読めるものを明示的に要求した場合に限り、Glance の20候補（G3–G22）を確認します。Glance を選ぶ場合は、Lupi と Basics では対応できない理由を記録します。「Glance のほうが直感的だから」とだけ書いてはいけません。ユーザーが地図を明示的に要求した場合は Maps（M1–M2）に進み、地図を通常の候補に混ぜてはいけません。
4. 実際のテンプレートを確定してから、ページ全体を組み立てます。 それぞれの図について、体系、図の番号、ギャラリーファイル、カード内のタイトルを記録し、そのカードの実際の構造と描画コードを骨組みにします。「このページでは6つのことを伝えよう」と先に決めて、後から図の種類を作り出してはいけません。ページ全体のストーリーは、テンプレートを確定した後にのみ組み立てます。
5. 図数のルールに従ってバッチを構成します。 1枚の図が担うのは、独立した結論1つだけです。重複する結論を取り除いた後、第1.2節のデフォルト範囲に従って枚数を決めます。テンプレートは全体を通して割り当てます。重複させず、同じ輪郭の図を積み重ねず、数合わせのために図を無理に追加してはいけません。
6. テンプレートに従って描画し、自己点検します（第0、2、3、8節）。完成物が選んだギャラリー実装に対応しているか、項目ごとに照合します。データを変更しても、テンプレートの核となる幾何形状、エンコーディング、アニメーションを変えてはいけません。第6.5節に従って、納品物全体に Mono または1つのカラープリセットを選びます。ライブラリ外の図形は翻訳ワークフローに従います（第6節）。

1.1 レポートモードのワークフロー

1. report-catalog.md を読み込み、少なくとも3つのレポート候補を比較して、却下した理由を記録します。内容構成、情報密度、版面、読み取り速度に基づいてテンプレートを選び、テンプレート名を業界の制限とみなしてはいけません。たとえば「旅行記」はスポーツや個人生活のデータにも使え、「月次運営」は財務諸表や業務データのレポートにも使えます。
2. 1つの言語版と1つのレポートテンプレートファイルを確定します。2つのレポートテンプレートのレイアウトを組み合わせてはいけません。
3. ページ全体の主結論、根拠となる結論、背景説明、出典を先に整理し、テンプレートに既存のタイトル、リード文、KPI、グラフ、注釈、結びの各スロットに割り当てます。
4. グラフの各スロットは catalog.md に従って個別に選定し、Lupi / Basics の実際の実装を優先して再利用します。レポートテンプレートのレイアウトを、グラフのデータ契約を無視する理由にしてはいけません。
5. 対応するレポートテンプレートの HTML 全体を起点として複製し、データ、文案、出典、凡例、言語、必要なモジュールだけを置き換えます。デモデータ、デモの出典、Moxt リンク、テンプレート本来の結論を残してはいけません。
6. レポートページの配色は、テンプレートの現在の配色に固定します。ユーザーが明示的に色の変更を要求した場合は、ページ全体を Mono、単一の組み込みプリセット、または完全なカスタム配色に統一して置き換えます。一部だけを混在させてはいけません。
7. レポートモードでは、納品前に追加で次の点を確認します。版面サイズが変わっていないこと、章の順序が成り立っていること、ページ内のグラフ数に根拠があること、固定サイズのテンプレートからはみ出していないこと、中国語フォントと英語のフォールバックが読みやすいこと。

1.2 プレゼンテーションモードのワークフロー

1. テーマ、聴衆、言語、用途、資料の範囲を確認します。納品形式が HTML または PDF の PPT であることを明確にし、ユーザーが .pptx を求めた場合は代替形式を確認します。
2. スライドごとのアウトラインを作成します。各スライドに主な結論を1つ記載し、出典、データ定義、図の番号、レイアウトの番号、確認が必要な項目を記録します。
3. まず catalog.md で Lupi Editorial と Lupi Basics を監査し、確定した実際の図を presentation-catalog.md の P04–P08 のスライドスロットに配置します。
4. 確定した全体の配色に合わせてテンプレートを選びます。Mono の場合は templates/presentations/presentation.zh.html または .en.html を複製します。カラープリセットの場合は、対応する complete-porcelain / complete-palm / complete-wire（各19ページ、中国語版と英語版の両方、入場アニメーション付き）を複製し、すべてのサンプル内容を置き換えます。レポートテンプレートを組み合わせてはいけません。
5. ナビゲーション、フォントのフォールバック、アニメーションのライフサイクル、アクセシビリティの説明、印刷時のページ分割、1280×720 での表示を検証します。

プレゼンテーションモードのルールの詳細は references/presentation.md を参照してください。

1.3 図数のルール

図の枚数は、独立した結論の数で決まります。「データ列がいくつあるか」では決まらず、5枚または6枚と固定するものでもありません。

リクエストの種類	成果物のデフォルト枚数	ルール
1つの質問 / 1つの表 / 1つの指標	1	最も強い図を1枚だけ納品し、テンプレートを見せるために増やさない
明確な結論が2～3つ	2–3	各図は異なる結論を1つずつ担い、同じデータソースを共有してもよい
1つの記事、論文、または完結した事例	4–6	概要、構成、比較、関係、変化など、異なるデータの形状をカバーする
ユーザーが枚数を明示的に指定	ユーザーの指定どおり	重複する図は削除し、根拠が足りない場合は説明して枚数を減らす

• 1ページあたりのデフォルト上限は 6枚 です。6枚を超える場合は複数ページに分けるか、章ごとに納品します。
• 候補案、Glance/Lupi の比較案は最終的な図数に含めません。これらは選定プロセスであり、成果物のバッチではありません。
• 1ページに複数の図を置く場合は、少なくとも1枚を全体像の結論に割り当てます。残りの図は、新たな比較軸、関係、時間的な変化、または詳細な根拠を示す必要があります。
• 2枚の図が同じ結論を表す場合は、利用場面により適し、データ契約により忠実なほうだけを残します。

2. Mono の構文・厳守ルール（違反した場合はやり直し）

デフォルトでは mono-tokens.js を参照します（オープンソースとして配布する場合は、内容を HTML にインライン化します）。トークンと競合する値は、すべてトークンを優先します。カラーを使用する場合は色のトークンだけを置き換え、フォント、角丸、レイアウト、アニメーションは引き続き mono-tokens.js に従います。

色

• デフォルトでは紙のグレー #F0EFEB とチャコールブラック #1C1C1A の2色を両端とし、その間に7段階のグレースケール ladder を設けます。カラーの例外は、第6.5節に従ってプリセットから始めます。
• 明度がデータを表します：重要度が最も高いものは最も暗くします（暗いカードでは最も明るく反転します）。複数系列は重要度に応じて ladder に割り当て、順番に適当に選んではいけません。
• すべて不透明にします：不透明な素材、発光、グラデーションフィルター、影は使いません。質感は明度のコントラストと形状だけで表現します。唯一の例外は、重ね合わせ型の図（Radial Patchwork）で、透明度自体が密度を符号化する場合です。これは装飾ではなくデータです。
• 暗いカード（.card.dark）を使うのは、暗い背景が必要な形（花びら、発光感のある糸／ネットワーク）の2種類だけです。デフォルトは明るいカードとし、各画面（4枚のカード）につき暗いカードは最大1枚までです。

タイポグラフィ

• Inter ファミリーを使用します。タイトルは700、図内の数値は800、軸ラベルは600です。カードの構成は次の4要素に固定します。結論を示すタイトル（h2）+ サブタイトル（凡例と期間をここに記載し、· で区切る）+ 図 + 出典行（すべて大文字で、文字間隔を広げる）。
• タイトルには図の種類ではなく結論を書きます。「Revenue by plan」は可、「柱状図」は不可です。判断を含む「Where we gained, where we bled」のような表現がより適切です。
• SVG の最小フォントサイズ：半幅カードでは6.5px、全幅カードでは5.5pxです。収まらない情報はホバー時に表示し、文字を縮小して詰め込んではいけません。

形状

• カードの角丸は24px、枠線と影はなしとし、余白でカードを区切ります。棒の端はカプセル状の角丸にします（縦棒は上端、横棒は外端を丸くします）。
• 棒グラフの軸を切ってはいけません。 棒のデータ契約は「長さ∝値」です。軸を切るとこの契約が損なわれます。極端な値がある場合の正しい対処法：①極端な値をそのまま突き抜けさせる（最も誠実）②メインの図に拡大表示用の小図を添える③軸ではなく棒を途中で切り、描ききれないことを明記する。
• 花びらの表現（太い黒のすき間+角丸の扇形）は、等分またはほぼ等分の放射状の図にのみ適しています。幅の差が大きい扇形は互いに隠れ合い、読みやすさが低下します。

アニメーション

• 入場アニメーションはデフォルトで有効にし、quarticOut で素早く進んで滑らかに停止させます。バウンスは使いません（波状の入場には elasticOut を使用できます）。ドットは1つにつき stagger 8–15ms、バーは1本につき80–130msです。
• reveal の仕組みを統一します。視野に入ったときに再生し、クリックで再生し直します（タイマーのクリーンアップを含む、トークン内の obsReveal を使用）。
• prefers-reduced-motion による劣化対応を必ず含めます（トークンの CSS に含まれています）。
• 構造よりアニメーションを優先してはいけません：効果を配置するために新たなレイアウトを考案する必要があるなら、その効果は不要です（effectScatter の教訓）。

データ

• デモデータにはトークンの rnd(i,k) による決定論的な疑似乱数を使用し、Math.random() は禁止します。更新しても常に同じ表示になる必要があります。
• 数値と視覚表現は厳密に比例させます。面積で符号化する場合は Math.sqrt(v) で半径に変換し、値をそのまま半径として使ってはいけません。

三、两个风格系的分工

同一份 mono 色板下有两种世界观，选哪个看场合和读者愿意花几秒：

	Glance 系（20 张）	Lupi 系（细读，19 张）
基本单元	形状（粗柱、大弧、色块）	记录（一个点 = 一条数据）
线条	2px+，理直气壮	0.5–0.7px 发丝
聚合	提前聚合好，给结论	拒绝聚合，摊开原材料
读法	扫一眼（<10s）	凑近读（30s+）
场合	周报、dashboard、随手贴	年报、对外故事页、海报
引擎	Chart.js / ECharts	手写 SVG

默认策略：Lupi Editorial → Lupi Basics → Glance。 没有明确场合时，禁止默认 Glance。放年报、公众号长文、海报、开源 README、作品集时先选 Lupi Editorial；数据较少或适合熟悉图型时再选 Lupi Basics。只有前两组都没有合适模板，或用户明确要 dashboard、监控、周报、三秒快读时，才进入 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 的路径优先级（经多轮案例验证）：

1. 先全量扫描，再选代码骨架——基础型组 F1–F13（templates/basics-gallery.html）是稀疏数据的 Lupi 词汇：柱/折线/面积/环形/横条/分组/堆叠/散点/瀑布/热力/进度/哑铃/矩形树图；编辑型 L1–L15 则提供逐记录、单位分解、关系与旁注语法。这两组是主力，小数据几乎总能在这里落地。F14–F17 与 L16–L20 是后备，按第零节 3.1 / 3.2 判断。不要因为 basics-gallery.html 里有现成代码就直接选 F 图。
2. 用最接近本体的模板起步——多选题百分比优先比较 L15、F5、L2；100% 构成优先比较 L14、L5、F4、G4；漏斗优先比较 L13、F1/F5 的降级表达。选择依据是数据编码方式，不是文件顺序。
3. 库里真没有对应形状才新造，且新造必须从 gallery 现有语法延伸（发丝 tick、确定性 rnd 抖动、paint-order 光晕、全大写注记），不引入库外参照——“Lupi 风”指 gallery 那批图的视觉语法，不是 Giorgia Lupi 本人的手绘风。
4. 新造的小数据图要配满环境结构层：gallery 好看有一半靠无数据的家具（账本纸横线、虚线导轨、rim 刻度、每 10 单位的立柱网格、旁注引线）。数据层诚实稀疏，密度预算花在家具上。只画数据 + 一根底线的小数据图必然寒酸。

同一批产出（一页多图）里模板不重复。 19 张 Lupi 系够轮换；同一数据能被多个模板承接时，选这一批里还没用过的。

四、图型决策树（数据形状 → 候选）

编号对应 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（饼图的默认替代）；占比×强度双编码 → G13 Big Slice；按类堆叠 → F7 Stacked Rungs
• 两时点对比（前后 / 今昔） → 类目级（≤6 类）→ F12 Dumbbell Queue（横向，串珠 = 真单位）⇄ F6 Paired Rungs（并肩双梯）；只有 2–4 条序列要画趋势线 → Glance chunky slope（粗线、大数、结论进标题）。交叉过多的斜率图会显著降低可读性，不要为了 Lupi 化增加装饰结构。
• 日序列（≤30 天，逐日读数） → 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
• 二维散点（≤20 点） → F8 Plumb Scatter；几百点分布 → G15 Jitter Strip
• 单变量分箱频数 → 先看 F1 Rung Bars 能不能直接承接（bin 当类目）；确实需要分箱语义时用 F14 Rung Histogram。bin 边界必须有业务含义；不要为了好看任意切箱。
• 分组连续分布 → 五数概括 + 异常值直接用 F15 Tick Box（主力无对应编码）。只看密度轮廓时先比较 G15 Jitter Strip；G19 Violin 与 L19 Ridgeline 属后备，要写明为什么 Jitter / F15 不够。
• 逐条记录分布 → G15 Jitter Strip。
• 分类×分类+量（矩阵） → 主力优先：轻量 L4 Arc Matrix，跨年份带旁注 L9 Bubble Almanac。两者都撑不住（格子多到气泡互相挤、必须靠明度读）才用 L16 Matrix Heat；要快读且每格直接标数才用 G20。
• 全年日期×数量 → 整年 52 周 × 7 天直接用 L17 Calendar Heat（主力无对应编码，L3 只到 90 天级）。星期×小时的重复周期仍用 F10 / G14。
• 多对一归属 → 造型强 L5 Radial Convergence ⇄ 带名单 L12 Type Colonnade
• 漏斗 / 分阶段递减 → L13 Hourglass Stream
• 层级结构 → G7 Tree LR
• 层级 + 份额 / 权重（两层、值为正数） → F13 Nested Treemap；只看谁属于谁、不比较大小 → G7 Tree LR
• 多系列构成随连续时间变化 → 静态类目构成先用 F7 Stacked Rungs；要同时看总量与构成的连续时间流，直接用 F16 Stream Ribbon（主力无对应编码）。只有单序列总量用 F3 / G17。
• 同一实体跨 3–6 个连续维度 → 直接用 L20 Parallel Coordinates（主力无对应编码）。维度超过 6 个先筛选或拆图。
• OHLC 行情 → 直接用 F17 Candlestick（主力无对应编码）。只有 min–max 区间而无开收盘值时用 G1。
• 两端聚合流量 → 先看 L5 Radial Convergence / L12 Type Colonnade 能否承接归属关系；确实要看流量宽度才用 G22 Aggregate Sankey。要查每条真实路径用 B3 Threads。
• 排名随离散时间变化（静态） → 先比较 L11 Trend Lineage / L2 Dot Cascade；确实要逐期格子对位才用 G21 Rank Strip。
• 事件序列生命史 → 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

地图显式触发规则

• 只有用户明确说“地图”“地域分布”“按国家/州着色”或点名 choropleth，才检查 Maps。数据表里仅出现地区字段不得自动触发。
• 美国州级区域数值用 M1 US Choropleth；世界国家级区域数值用 M2 World Choropleth。地图面积是地理面积，不代表数值，副标题必须说明 shade = value。
• M1/M2 依赖 ECharts 与在线 GeoJSON；交付时说明需要联网，或在用户明确要求离线时再内联合法来源的地图数据。
• 中国地图不从 M1/M2 改名套用。只有拿到符合当前地图合规要求的完整数据源和审图信息后才制作。

F13 Nested Treemap 硬规则

• 只接收层级数据和非负权重；父级值由子级求和，禁止父子总数互相矛盾。面积直接交给 ECharts treemap 布局，不再对值开方。
• 默认展示两层（父组 + 叶子）。超过两层且读者需要逐层查询时才开启 drill-down；普通静态交付保持 nodeClick:false，避免误触改变视图。
• Mono 的灰度只表示层级，不给每个叶子随机分配深浅；父组靠标题带、组间留白和边界区分。去掉颜色后仍能看清分组。
• porcelain 用单色相明度表示有序的父组份额或层级；palm 用色相对应不超过 4 个顶层类目；wire 保持灰阶，只允许一个明确主角使用 HERO。
• 面积已经表达数值时，颜色不得再次无说明地重复同一数值。副标题必须写清 area = ...，使用彩色时再写清 color = ...。
• 叶子超过 30 个、标签大面积省略，或最小矩形小到无法形成稳定热区时，先合并长尾为 Other、拆成多张，或改用 G7 / L12 / B 系关系图。
• Tooltip 至少显示完整层级路径、原始值和总量占比；卡内标签放不下就隐藏，不缩到低于最小字号。

五、交互三问（决定静态还是可交互）

按顺序问：

1. 这根线/点背后有没有一条真实记录？ 没有（纯肌理装饰，如 Cluster Field 的辐条、Hourglass 的淌线）→ 禁止加交互，给没有内容的元素加 hover 是欺骗。
2. 有记录 → 不点能不能读出来？ 元素 <50 且两端有标注（如 Colonnade）→ 静态够用，hover 是锦上添花。
3. 元素 >50 根或多段路径（如 Threads）→ 必须 hover/pin，否则只是氛围图。交互实现参考 templates/big-threads.html：可见线下垫 9px 透明孪生线当热区，hover 单线亮整条路径、hover 标签拉整束、点击钉住。

六、库外图型 · 翻译流程

用户要的图不在 63 张里（或发来一张参考图）时，不是做不了，是现场造句。流程四步，第一步不许跳：

1. 先回答本体：这个图型编码了什么？每个视觉通道（位置/长度/角度/面积/明度/密度）分别对应哪个数据维度？答不出来就问用户拿数据结构。抄形不抄魂 = 白做（pictorial bar 曾把"符号计数"错做成"树长高"，返工）。
2. 找最近的亲戚：在 catalog 里找数据形状最像的一张当起点，继承它的布局骨架和动画节奏。
3. 用 token 造句：色板、字体、圆角、动画参数全部从 mono-tokens.js 拿，不许发明新颜色新字号。产出必须和库里的图"一眼一家人"。走彩色时颜色改从 color-presets.js 的单一预设中取，其他 token 仍以 mono-tokens.js 为准。
4. 过第二节硬规则和第八节自检，和库内图同一标准。

参考图翻译的附加规则：识别参考图属于哪个流派（Glance or 编辑部），编辑部风格的密度、旁注、手绘感（blob）是本体的一部分，别做收敛了——almanac 曾因"不敢挤"返工。

六点五、彩色（按场景自动选择，单一色系）

Mono 是保底方案，不是未触发彩色时的强制答案。 用户没有提颜色时也要根据数据语义、类目数量、阅读场景和内容气质评估是否适合彩色；适配关系不明确，或颜色没有带来真实信息价值时，回到 Mono。

彩色初稿从三套预设中选择一套，色值在 color-presets.js，样张在 templates/color/。预设用于快速得到稳定、统一的第一版，不是锁死的色板。用户要求"这个蓝再深一点"时，在当前色系内继续调整；用户明确给出品牌色、色值或完整色板时，按下方规则建立 custom 色板。调整后必须重新检查对比度、视觉主次和数据语义。

同一份 HTML 或同一组交付必须先锁定一个全局色彩系统：Mono、porcelain、palm、wire 或一套 custom。 所有图共享该选择。若其中某张图不支持已选系统，不得单独换色；改选一套全局兼容的系统，或整组退回 Mono。

结构正本永远是原版 gallery。 查渲染代码去 templates/ 根目录的 gallery，templates/color/ 只查配色。先按第零节选定结构，再决定是否换肤。

用不用彩色

按以下优先级判断：

1. 用户明确指定。 用户要求某种颜色、气质或预设时优先服从，但仍要通过容量、对比度和数据语义检查。
2. Agent 自动选择。 即使用户没提颜色，只要数据形状和场景与某套预设有清楚的对应关系，就可以自动使用：有序单序列适合 porcelain；少量无序类目适合 palm；需要一个受控视线落点适合 wire。
3. 关系不明确就用 Mono。 类目过多、高密度记录、颜色没有稳定含义，或整组图无法共享同一预设时，使用 Mono。

彩色不是升级版，而是 Agent 可以主动选择的语义工具。交付时用一句话说明所选色系及其承担的数据含义。

自定义色板（只在用户明确要求时启用）

Agent 不得自行发明第五套默认审美。只有用户给出明确色值、品牌色、品牌规范或"沿用这张参考图的配色"时，才建立 custom 色板；仅说"好看一点"仍从三套内置预设选择。

1. 先确定颜色逻辑，再分配色值。 有序数据用单色相明度梯；无序类目用分类色；需要聚焦时用中性色 + 一个强调色。禁止先拿到五个颜色，再平均撒到所有元素上。
2. 建立完整角色，不直接散落 hex。 custom 至少定义 BG、TXT、MUT、GRID、DATA；需要重点时再定义 HERO，有序数据定义 RAMP，分类数据定义 CAT。成品内联一个 CUSTOM 对象，所有图从角色取色。
3. 按输入数量解释。 1 个颜色生成同色相明度梯；2 个颜色默认分为主数据色 + 强调色，不自动当作两个平等类目；3–6 个颜色只有在数据确有对应类目时才进入 CAT。超过 6 个先合并类目、改用位置/标签，或退回 Mono。
4. 允许派生明暗，不允许偷渡新色相。 浅色由用户色与 BG 混合，深色由用户色与 TXT 混合；不得借用 porcelain、palm、wire 的色值补齐 custom。
5. 对比度是硬门。 正文和小标签相对背景至少 4.5:1，大字至少 3:1；关键边界、数据形状和交互状态相对相邻颜色至少 3:1。不达标时优先调整明度，不擅自改变用户指定的主色相。
6. 颜色不能成为唯一线索。 分类仍带标签，序数仍保留位置/长度/面积，强调仍有标题或旁注说明。色觉异常用户去掉颜色后，图的结构仍应读得懂。
7. 一次只锁定这一套 custom。 custom 不与任何内置预设混用；多图交付共享同一个 CUSTOM。除非用户明确要求把品牌色固化为项目级预设，否则 custom 只内联在当前成品，不回写 color-presets.js。

用户后续要求"再深一点"、"背景暖一点"或替换某个色值时，修改对应角色并重新检查整套对比度和语义映射，不只改被点名的那一个元素。

选哪套：先看数据形状，再看气质

数据形状	允许	原因
有序 / 单序列（进度、热力、时间序列、单指标、排名）	porcelain、wire	明度即数据的契约仍然成立
无序类目 ≤4	palm	色相对应类目
无序类目 5–6	palm（勉强）	依靠明度和饱和度辅助区分
类目 >6	Mono 灰阶	彩色预设容量不足
需要克制但要一个视线落点	wire	灰阶承载数据，橙色只标主角

用户会说	预设	气质
蓝、冷、学术、理性、严肃、科技感	porcelain	单色相蓝阶
绿、暖、自然、温柔、复古、莫兰迪	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 必须不同。 琥珀和橄榄明度接近，不要把两者当作平等类目色。

七、什么时候说不

敢拒绝比什么都接更可信。以下情况不做，并给替代：

• 断轴柱状图 → 拒绝，给三个诚实方案（冲天 / 放大镜 / 撕柱不撕轴）。
• 发光 / 玻璃拟态 / 3D → 拒绝，保持现有视觉语法。自定义色值按 custom 规则映射；跨色彩系统混用拒绝。
• 拿多色相画单序列 → 拒绝。给 porcelain、wire 或退回 Mono。
• 类目 >6 还要彩色 → 拒绝，退回 Mono 灰阶。
• 用户未明确要求地图 → 不因数据里有地区字段自动使用 M1/M2；继续按普通比较、排名或构成选图。
• 地图范围超出 M1/M2（中国省级、城市点位、轨迹图等）→ 不套用错误边界；确认数据源、投影、合规和交互要求后再现场制作。
• 给纯装饰元素加交互（第五节第 1 问）→ 拒绝并解释。
• 雷达图重构 → 不重构，用 ECharts 原生雷达 + Mono token 换肤（实测过：展示场景里"认得出的图型"有价值）。
• 数据太少撑不起所选图型（如 3 个节点要力导向）→ 降级到更简单的图并说明。

八、交付前自检清单

1. 数值和视觉成正比？（面积用了 sqrt？柱没断轴？）
2. 色板是否受控？整份 HTML 或同一组交付是否只使用 Mono、单一内置预设或单一 custom？Mono 中出现任何非 ladder 颜色即返工；内置彩色出现另一套预设颜色即返工；custom 是否只从 CUSTOM 角色取色并通过对比度检查？
3. 标签会不会重叠？（barcode 教训：邻近峰值标签要强制最小间距）
4. 最小字号踩线没有？（半宽 6.5 / 通栏 5.5）
5. 演示数据是 rnd 确定性的？刷新两次长得一样？
6. reveal 正常？（滚入播、点击重播、timer 不叠加、reduced-motion 降级在）
7. node --check 过语法（把 <script> 内容抽出来查）。
8. 卡片四件套齐全？标题是结论不是图型名？
9. 副标题把图例说清了？（读者不看代码只看这一行）
10. 是否完成全量候选审计？至少写下 3 个候选和淘汰理由，而不是只记录“采用了哪个模板”。
11. 如果是一页多图，模板是否全局分配过？有没有相似轮廓重复、暗卡过量、所有图都变成同一种径向图？
12. 每张图是否记录了图型编号、gallery 文件和卡内标题？成品的核心结构是否确实来自该模板，而不是重新发明？
13. 如果使用 Glance，是否写明 Lupi Editorial 与 Lupi Basics 为什么都不适配？如果没有，返工回到 Lupi / Basics。
14. 最后一问：这张图放回所选 gallery 的对应卡片旁边，是不是同一个模板家族，而不只是“风格有点像”？

九、单文件模板骨架

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>Mono — {图名}</title>

<script src="https://cdn.jsdelivr.net/npm/echarts@6/dist/echarts.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">
    <h2>{结论式标题}</h2>
    <div class="sub">{说明} · {图例} · {时间范围}</div>
    
    <div class="ch" id="ch"></div>
    
    
    
    <div class="src">{图型名} · {系列} · {数据来源}</div>
  </div>
</div>
<script>
// 内联 mono-tokens.js 全文
// ── 数据（用户只需要改这里）──
const DATA = [ /* ... */ ];
// ── 渲染 ──
MONO.obsReveal('ch', el => { /* ... */ });
</script>
</body>
</html>

十、报告与演示模式骨架

report-catalog.md                # 先按场景选 R01–R12
presentation-catalog.md            # 演示模式 P01–P10
references/presentation.md          # 演示模式完整规则
templates/presentations/index.html # 演示模板索引
templates/presentations/presentation.zh.html # 中文 16:9 演示正本（Mono）
templates/presentations/presentation.en.html # English 16:9 deck source (Mono)
templates/presentations/complete-{porcelain,palm,wire}{,-zh}.html # 彩色完整版，19 页中英双版
templates/reports/report-NN.zh.html  # 中文整页正本
templates/reports/report-NN.en.html  # English full-page source
templates/reports/index.html         # 本地可打开的模板索引
docs/assets/reports/report-NN.png    # 中文版静态预览

报告交付仍然是单文件 HTML；templates/reports/ 中的文件是可复制的起始骨架，不是需要逐字照抄的内容样例。模板内的演示数据只用于展示结构，生成最终报告时必须全部替换。