| name | infocard-handline-style |
| description | 手绘便签 / 白板草图风信息卡主题。适合把复杂工作流、并行调度、方法论与策略拆成像手绘草图一样直观的知识图。可允许使用第三方手绘风前端框架（如 rough.js / hand-drawn SVG 工具链）来增强线条抖动与草稿感，但主题约束必须由本 skill 统一定义。 |
| version | 1.0.0 |
| author | Hermes Agent |
| license | MIT |
| metadata | {"hermes":{"tags":["infocard","style","hand-drawn","sketch","workflow","theme","svg"],"related_skills":["any2card","infocard-style-man-skill","infocard-pub-publisher"]}} |
infocard-handline-style
Overview
infocard-handline-style 是一套“手绘草图 / 白板便签 / 纸上讲解”风格的信息卡主题。
它不是极简科技风，也不是严肃技术手册风，而是用“手写笔触 + 草图框线 + 便签 + 流程箭头 + 中心隐喻图”把复杂概念讲得像在白板前边画边解释。
这套主题最适合：
- 并行调度、编排、工作流
- 方法论拆解、策略图、流程图
- 技术博客分享、Recent Articles 导读、内容入口地图
- 复杂系统的“视觉隐喻 + 分层说明”
- 需要降低说教感、增强亲和力的知识图
Use Cases
适合
- AI agent 工作流
- 多项目并行与 orchestration
- 提示词 / 方法论 / 教程
- 产品策略拆解
- 个人知识管理图解
- 让复杂概念“像手绘笔记一样”易读的内容
不适合
- 法律、财务、合规等需要强正式性的内容
- 纯数据密集报表
- 需要极简品牌感或强科技感的页面
- 必须严格网格化、工业化、冷感的系统说明
典型触发词
- 手绘
- 草图
- 便签
- 白板
- 指挥 / 调度 / 并行
- 工作流图
- 讲解图
- sketch
- doodle
- hand-drawn
Design DNA
核心气质
- 像在米黄色纸张上用黑笔和橙笔快速讲解
- 有“草稿未完工”的亲和力，但信息结构必须清楚
- 视觉中心通常是一个隐喻图，而不是一堆文字
- 文字是解释隐喻，不是替代隐喻
- 风格关键词：whiteboard / doodle / sketch / sticky note / workflow map / orchestration diagram
视觉母题
这套主题优先吸收三类图像母题：
- 对话驱动的工作流图：左侧聊天窗口 + 中央步骤图 + 底部总结句，强调“你发一个 prompt，系统替你调度”。
- 代码到运行结果的三段式图：设计原型 → 代码实现 → 模拟器/部署结果，强调“草图、实现、验收”三步闭环。
- Before / After 技能系统图：技能创建模板 → 安装/调用 → 实际运行效果，强调“从 prompt 到可复用 skill”的转化。
视觉原则
- 先有一个中心隐喻，再展开说明。
- 使用少量强调色，主色永远是黑/米白，橙色只负责引导视线。
- 所有线条都应该带一点“手写抖动”或“笔刷毛边”，避免几何完美。
- 模块之间保持明显的手工分隔感，不追求过度精致。
- 节奏上要像“边画边讲”，不是像工业产品页。
- 视觉层级优先于装饰密度：标题、流程、便签、注释必须一眼分明。
- 允许局部使用手绘 SVG / rough.js 之类第三方框架，但它们只能增强“笔触感”，不能替代结构设计。
- 禁止全页过度规整：handline 不应像 dashboard 或组件文档。主模块允许存在轻微错位、尺度不完全一致、手工留白节奏变化，但阅读顺序必须稳定。
- 必须存在批注层：除正文层外，至少要有一层“批注 / 圈点 / 箭头 / 划线 / 贴纸注释”来制造思考痕迹，不能只靠印刷体内容块完成页面。
- 中心隐喻必须压过说明卡片：首屏最强视觉锚点应是手绘隐喻图或流程草图，而不是右侧说明框或整齐卡片阵列。
Color Tokens
:root {
--bg: #f5efe6;
--paper: #fbf6ee;
--ink: #2d2926;
--muted: #6b6258;
--line: #2f2a27;
--accent: #e67e22;
--accent-dark: #d35400;
--note: #fff3df;
--note-line: #b57a43;
}
使用规则
--bg: 整体纸张底色--paper: 卡片/便签浅底--ink: 主文字与主轮廓--muted: 辅助说明--line: 框线、箭头、分隔线--accent: 箭头、标题强调、重点标注--accent-dark: 更强的橙色高亮--note: sticky note 背景--note-line: 便签边缘与贴纸辅助线- 正文颜色分层必须克制：正文主文默认用
--ink 的柔化深墨版本（接近 #3a342e ~ #4a433b），避免纯黑大段文字压得太硬；只有标题、关键短标签、极短结论才用最深墨色。
- 线条颜色分层：主骨架线用
--line；次级分组线、虚线、批注连接线应降到更浅、更暖的墨褐色，不要整页所有线都同一黑度。
- 线条粗细也必须分层：主骨架线最稳，次级线更细，虚线更轻，禁止所有边框使用同一 stroke weight。
- 橙色只做点状强调：优先用于箭头、圈点、虚线高亮框、批注标签、手绘下划线；默认不应用作大面积主背景。
- 边框颜色底线（强制）：所有结构性边框颜色必须 ≥
#2c2723（深墨褐），禁止使用 #d0c8be、#c0b8a8 等浅色作为 topbar 底边、footer 边框、section 分隔线等任何结构性线条；浅色边框在米纸底上无法形成视觉锚点，必须替换为深墨褐。
- 参考图色值（2026-06-12 实测）：
- 标题纯黑：
#171513 或 #181614
- 正文深灰：
#2d2926 或 #2c2723
- 辅助灰：
#5a5248 ~ #6b6258
- 蓝色强调：
#1e5cb5（非浅蓝）
- 土橘背景：
#c99d78 ~ #b07b51
- 深色块：
#111111（纯黑背景）
- 边框：
#2c2723（不淡、不灰）
- 底线：边框绝不能是
#d0c8be 这类浅色；在纸张底上必须足够深才能成为视觉锚点。
- chip / label 的目标是“单层外框”，不是“双层边框的壳”。
- 若截图出现内壳或右下角双线，先检查 rough-box / SVG path 的叠线与角部处理，再动 chip CSS。
- chip 填充尽量向纸色靠拢；避免独立色块把边框变成一个内部容器。
- 除非视觉验收证明没有双线，否则不要用更粗的 border / shadow 去“压住”问题。
Typography
字体策略
- 主标题：手绘感标题字体，优先粗糙、笔画不完全统一的字形
- 正文：可读性优先，允许使用清晰无衬线字体
- 备注 / 标签 / 箭头注释：可使用更窄、更像手写标注的字重
- 文字层级不只靠字号，也要靠墨色深浅区分：标题最深、正文次深、说明/脚注更浅
层级建议
- Hero title: 30–56px
- Subtitle: 13–16px
- Section title: 18–24px
- Body: 12.8–14.5px
- Caption / note / label: 10.5–12px
- 最小字号底线：11.2px
笔触要求
- 标题可略显不规则，但不能像花体装饰字
- 正文不应过度手写化，否则会影响密度阅读
- 注释与框内标签可以更像“手绘标注”
- 大段正文避免纯黑；正文与说明层要形成柔和的墨色梯度，而不是三层都用同一深度
Layout Skeleton
默认骨架：
hero/title
subtitle/underline
central metaphor block
supporting workflow diagram
side note / sticky note
sections or callout blocks
footer/source note
save button
默认结构偏好
- 上：标题 + 核心判断
- 中：中心隐喻（手、轨道、指挥棒、手机、代码编辑器、表单、便签等）
- 下：流程、步骤、原则、便签式总结
- 右侧或角落：sticky note / tip note / summary note
- 若内容是“工具链 / 开发流程 / 自动化”，可用三段式：输入界面 → 工作流步骤 → 结果/启用状态
版式特征
- 不追求严丝合缝的工业网格
- 允许“手工感”的不完全对齐
- 但整体阅读路径必须稳定：标题 → 隐喻 → 结构说明 → 结论
- 若有多块流程图，优先“中心大图 + 底部摘要”，而不是平均分配所有模块
- 去容器化优先：不是所有信息都必须放进重边框卡片。能用留白、邻近关系、虚线、批注连接表达分组时，优先不用实体卡片壳。
- 垂直节奏必须有松紧变化：不同段落/模块之间的留白不应完全等距，允许像白板讲解一样出现“停顿区”和“密集区”。
- 间距要比 dashboard 更松一点：handline 允许局部紧凑，但整体不应所有模块都贴得很近；标题区、隐喻区、批注区之间必须有可感知呼吸。
- 间距也是颜色的一部分：若文字已变柔，仍需要通过模块间呼吸把视觉压强降下来，不要只调色不调空白。
Blog archive / recent articles pattern
- 把“最近文章列表”视为阅读入口，不要只是标题堆叠
- 先识别连续系列：最近 2-4 篇是否构成同一条教程线或主题演进
- 抽取三类信息：
系列主线、观点类文章、适合分享的阅读顺序
- 推荐结构：hero 判断句 + 右侧黑盒（列表 ≠ 随机链接）+ 中部阅读流程 + 底部文章条目/主题雷达/分享格式
- 每篇条目至少保留：日期、标题、阅读时长、链接或路径、1 句摘要
- 分享文案优先写“这组文章说明了什么”，而不是“站点最近更新了什么”
- 若页面是 blog recent / archive / index 类列表，handline 的中心隐喻可以是“reading map / route / radar / guide”，而不必强行做成生产力 workflow 图
Component Rules
1. Hand-drawn frame
- 使用略带抖动的边框、圆角或不规则闭合线
- 线宽要统一，但边缘可以略有噪点
- 不可使用过于光滑的现代卡片边框
- 相邻模块不应全部严丝合缝平行对齐；允许轻微错位或边距差，避免 dashboard 感
2. Arrow
- 用于表达“流程”“调度”“指向”“因果”
- 箭头尽量短而明确，不要过度装饰
- 橙色箭头是主题的核心强调方式
- 优先让箭头承担层级引导，而不是让纯色块承担层级
3. Sticky note
- 用于放“核心原则”“提醒”“一句话总结”
- 要有贴纸感：卷角、阴影、贴住纸面的感觉
- 常放在右下角或图右侧
- sticky note 应像批注层，而不是普通内容卡换底色
4. Central metaphor block
- 必须是页面最强的视觉锚点
- 例如：手、铁轨、导线、机械臂、白板草图、流程节点
- 用来代替单纯的大段文字
- 若首屏出现多列说明卡，中央隐喻图的视觉权重必须仍然大于说明卡阵列
5. Workflow diagram
- 适合用流程块、轨道、箭头、编号节点表达
- 节点可以不完全对齐，但逻辑必须严格对齐
- 如果内容复杂，优先拆成两层流程
- 移动端应允许简化为更少节点/更短连接，不保留桌面级复杂线网
6. Callout box
- 用于“核心原则”“总结”“边界条件”
- 深底浅字或浅底深字均可，但必须和主纸面形成明确对比
- 数量要克制；不能靠大量整齐 box 堆出结构
7. Annotation layer（新增，强制）
- 每张 handline 卡至少要有一层独立的批注语言：圈点、手写短标签、箭头批注、下划线、虚线框、划掉重写、贴纸提示等
- 这层的作用是制造“思考痕迹”，让页面看起来像边画边讲，而不是一次性排版完成的印刷页面
- annotation layer 可以轻量，但不能缺席
- annotation layer 应参与组织内容关系：连接跨区块信息、提示阅读顺序、制造局部强调；不能只是贴在单个卡片上的装饰贴纸
8. Save button
- 必须保留在卡片底部或安全浮层
- 底部主按钮默认居右对齐，不要居中或居左
- 若底部有多个操作，主按钮放最右，次级操作靠左或降级为轻量文本链接
- 不得遮挡正文
- 移动端优先落在正常流末尾，必要时再做轻量浮层
- 任何 handline 卡的底部 CTA / 保存按钮 / 导出按钮都应遵守同一右对齐规则，避免像居中工具条
Mobile Rules
720px 以下
- 单列化优先
- 流程图要减少并排节点
- sticky note 下沉到正文后面
- 文本字号不能过小
- 优先保结构，不要保留过多手绘小组件
- 优先减少重边框容器数量，让移动端首先像一张可读草图，而不是一串 stacked cards
- 如果页面用了 JS 生成的 rough-box / hand-drawn SVG 边框，改完视口后先触发一次
resize 再判断 overflow；见 references/rough-box-mobile-regeneration.md
390px 验收重点
- 不允许横向溢出
- 关键隐喻图不能被裁切
- 节点与箭头不能太密
- save button 不能盖住正文
- 便签内容要能完整读完
- 不能出现“桌面整页缩小稿”观感
- 边框和装饰不能压过正文可读性
- 任何正文/说明文字都不能出现“几乎看不见”的浅灰状态
移动端密度退化原则（强制）
- 先减列数，再减装饰
- 先保留结构，再简化图形
- 先保留核心隐喻，再压缩边缘注释
- 若出现 card-in-card-in-card 拥挤感，先减少最内层手绘容器，而不是继续缩字体
- workflow / principles / defense 这类区块在移动端优先改为上下堆叠，不硬保并排
- 禁止桌面缩小稿观感：如果移动端只是把桌面多块规整模块整体压窄，视为失败；应主动减少模块并列、简化线网、增加呼吸留白
- 边框层级少于桌面端：移动端允许主动隐藏次级轮廓，只保留核心结构边界，避免黑线密度压过正文
可读性底线（新增，强制）
- 文字可读性高于风格氛围；任何时候都不能为了“轻”“纸感”“编辑感”把正文降到近乎不可见
- 浅色底上的正文、说明文、英文副标题、标签字都必须保持明确对比，禁止使用接近背景色的浅灰
- 如果某个模块需要靠很细的灰字才能成立，该模块设计应被视为失败，优先改文字深度、字号和间距，而不是保留原样
- 手绘双线、抖动边框、装饰虚线都必须服从阅读；一旦边框存在感比文字更强，就应降权边框
Third-party Hand-drawn Framework Policy
允许使用第三方手绘风前端框架。对 infocard-handline-style 来说，wired-elements 和 rough 系列不是"点缀"，而是这类主题的核心视觉语言。
可以使用
- rough.js
wired-elements- 手绘 SVG / canvas 工具链
- 手写风字体配合的草图框架
- 任何能帮助制造"笔触抖动 / 线条粗糙感"的前端库
Tag / Chip 元素规则（强制）
handline 风格中的 tag / chip 标签（如 .tag-chip）必须遵守以下规则：
- 只用 rough-box 外边框：tag 元素应同时带
rough-box 类，只靠 JS SVG 抖动路径生成手绘外边框
- 禁止同时加 CSS border：
border: 1.5px solid #... 这类 CSS border 属性会与 rough-box SVG 边框叠加，形成内外双层边框（内 solid + 外 sketchy），视觉上错误且冗余
- 正确做法：
.tag-chip { background: ...; color: ...; ... } — 只保留背景色、文字颜色、圆角，不加 border
- 色值变体（
.tag-chip.blue、.tag-chip.orange 等）：继承 .tag-chip 基类，不单独声明 border
- 验证方法：截图放大 tag 区域，若出现内外两层边框 → 基类或变体有 CSS border、outline 或 box-shadow 未清理，需移除
- 同类禁区：任何已经挂了
rough-box 的容器（尤其 footer、label、summary band、quote band）都不要再叠加 border / outline / box-shadow 充当第二层框；要么用 rough-box，要么用 CSS border，不能两者并存
- 发布时区联动：如果卡片的发布日期需要写进正文或页脚，统一用 Asia/Shanghai 壁钟时间（UTC+8），避免首页时间与正文时间不一致。
⚠️ 核心原则：边框线条手绘，文字必须清晰（Text-Clean / Borders-Sketchy）
这是 handline 风格实现时最重要的设计原则：装饰性元素（边框、线条、容器）手绘抖动，文字保持干净印刷体。
错误做法 ❌：
- CSS SVG
feTurbulence + feDisplacementMap 滤镜：作用于整块内容，包括文字笔画，文字会被抖歪模糊
- 任何让正文段落出现笔触抖动的方案
正确做法 ✅：
- 纯 JS SVG 抖动路径生成边框线条（每边分 4 段，每端点加
±roughness*2 随机偏移）
- 文字层完全不参与抖动，始终保持清晰可读
验证方法：截图后放大看文字边缘——若有锯齿/模糊感，说明文字被滤镜波及，需切回纯 JS SVG 方案。
⚠️ CDN 访问限制与兜底方案（关键）
在受限网络环境（如某些服务器环境）中，unpkg.com、cdn.jsdelivr.net 等 CDN 会被阻塞，导致 wired-elements 和 rough.js 无法加载。
因此，必须优先使用纯 JS SVG 抖动路径方案，它不依赖任何外部 CDN，100% 可靠：
function jitter(v, amt) { return v + (Math.random() - 0.5) * amt; }
function applyHandDrawnBorder(el, r) {
r = r || 3;
var svg = document.createElementNS('http://www.w3.org/2000/svg', 'svg');
svg.setAttribute('width', '100%'); svg.setAttribute('height', '100%');
svg.style.cssText = 'position:absolute;top:0;left:0;pointer-events:none;overflow:visible';
var path = document.createElementNS('http://www.w3.org/2000/svg', 'path');
var w = el.offsetWidth, h = el.offsetHeight;
var r2 = r * 2;
var d = 'M ' + jitter(0, r2) + ' ' + jitter(0, r2);
d += ' L ' + jitter(w, r2) + ' ' + jitter(0, r2);
d += ' L ' + jitter(w, r2) + + (h, r2);
d += + (, r2) + + (h, r2);
d += ;
path.(, d);
path.(, );
path.(, );
path.(, );
path.(, );
path.(, );
svg.(path);
el.. = ;
el.(svg, el.);
}
.().(applyHandDrawnBorder);
SVG 抖动算法核心：每条边分 4 段，每段端点加 ±roughness*2 的随机偏移，strokeLinecap round，产生手绘抖动感。
wired-elements shadow DOM 问题：即使 CDN 正常加载，wired-card 的 shadow DOM 在复杂页面嵌套结构中 shadow innerHTML 可能为空（SVG 未正确挂载），且 shadow DOM 内的 SVG 会被子元素背景覆盖。纯 JS SVG 生成器对 DOM 结构无依赖，更可靠。
方案优先级：
- ✅ 纯 JS SVG 抖动路径（首选，不依赖 CDN，文字保持清晰）
- ❌ rough.js CDN（网络受限环境不可用）
- ❌ wired-elements CDN（shadow DOM 在复杂结构中不稳定）
- ❌ CSS SVG feTurbulence 滤镜（文字会被抖动感干扰，只抖动边框线条、不抖文字的正确做法是纯 JS SVG 路径，不能用 CSS filter 方案）
⚠️ 关键坑：CSS SVG filter 会抖动整块内容，包括文字
filter: url(#rough) 作用于 .rough-box 时，feTurbulence + feDisplacementMap 会把文字笔画也抖歪，造成阅读障碍- 正确做法：只用 JS 生成 SVG
<path> 边框线条，filter 方案必须废弃
- 验证方法：截图后放大看文字边缘——若有锯齿/模糊感，说明文字被滤镜波及，需切回纯 JS SVG 方案
验证方法：截图后检查边框线条是否明显不规则/有抖动；若边框是完美直线则方案失效。
结构优先级（强制）
当 handline 主题用于 workflow 图 / 产品流程图 / 白板说明图 / infographic 时，必须采用下面的层级：
- 骨架层：rough.js / 手绘 SVG 优先
- 外框
- 箭头
- 流程连接
- 批注圈 / 放射线
- 虚线高亮框
- 便签轮廓 / 胶带
- section outline
- 主结构层：
wired-elements 的卡片 / 标签语言
- 主要内容块
- 对比框
- 步骤条
- label / badge / chip
- CTA / 次级操作按钮
- 内容层：普通 HTML/CSS
- 标题 / 副标题 / 正文
- 列表 / 表格退化后的堆叠结构
- 栅格密度、断点、移动端阅读顺序
原则：handline 的风格辨识度，必须同时来自 rough 的骨架笔触和 wired 的边框卡片 / label 语言。
必须满足
- 主题定义仍以本 skill 为准
- 框架不是“自动出图工具”，它只负责提供统一的手绘边框语言
- 不能让框架把正文可读性拉低
- 不能把所有模块都做成装饰，导致信息阅读断裂
- 当参考图本身具有强 editorial 骨架时，应优先重建其结构语言（topbar / serif hero / quote banner / process bar / multi-column body），再叠加 wired 卡片与标签；不要只抽色值和氛围
- 当用户明确给出白板 / 流程图 / sketch 风参考图时，rough.js + wired-elements 的组合优先于纯 CSS 直边框
- 预览页
theme/*.html 只是示例实现，不能反过来绑架 style skill；skill 才是主规范，preview 只是样张
- 橙色只能做点状强调：按钮、放射线、虚线框、重点标记；不能大面积铺色
- 必须显式防浏览器自动深色污染：根节点加
color-scheme: light
handline × wired-elements 专项边界
wired-elements 在 handline 里是主视觉骨架之一，不是只给按钮用的轻量点缀- 允许大块使用
wired-card，并配合 label / badge 形成“手绘卡片群”
- 不能把每个细碎文本都单独组件化，避免
card-in-card-in-card 的组件展板感
- 对 workflow / 调度 / whiteboard 内容，优先用 rough 骨架 + wired 卡片 + 普通排版的三层组合；不要退回成平面硬边框
wired-elements 视觉控制规则
- 重点不是“有没有 wired”，而是边框语言是不是 wired 风格
wired-card / wired-button 的存在是为了获得抖动边框、手绘轮廓和手工感，不是为了把文字颜色交给组件默认值- 文本层仍然要由你自己的 CSS 明确控制：标题纯黑、正文深灰、辅助蓝 / 土橘分层不可丢
- 如果某个组件里的文字可读性差，优先改字号 / 对比 / 间距 / 载荷，而不是取消 wired 语言
禁止
- 只靠第三方框架“自动生成”视觉而不定义版式
- 用过度动画掩盖结构混乱
- 用复杂 SVG 堆出花哨效果，牺牲内容识别速度
- 只做“米纸底 + 圆角盒子 + 橙色强调”的浅层 retheme，却没有形成明确的 handline / whiteboard identity
- 把所有内层小块都 wired 化，做成“组件展板”而不是“手绘信息图”
- 为了追求全局手绘，把深色重点块全部交给深色容器；移动端易被自动深色模式 / 浏览器强制配色错误干预
- 用过度动画掩盖结构混乱
- 用复杂 SVG 堆出花哨效果，牺牲内容识别速度
- 只做“米纸底 + 圆角盒子 + 橙色强调”的浅层 retheme，却没有形成明确的 handline / whiteboard identity
- 把所有内层小块都 wired 化，做成“组件展板”而不是“手绘信息图”
- 为了追求全局手绘，把深色重点块全部交给深色容器；移动端易被自动深色模式 / 浏览器强制配色错误干预
References（长期查阅价值）
references/handline-text-clean-borders-sketchy.md：核心渲染规则——Text-Clean / Borders-Sketchy 原则、纯 JS SVG 抖动路径算法（含代码）、tag/chip 双层边框 Bug 修复、验证方法、已验证参数、commit 记录，以及三次回归笔记（CSS filter 抖歪文字、tag 双层边框、浅色边框消失）。references/handline-double-border-and-utc8-publish-time.md：本次回炉笔记——rough-box 不能叠 CSS border、footer 也算二次边框风险、发布时间必须用 UTC+8 壁钟时间references/handline-tech-blog-sharing-pattern.md：技术博客 Recent Articles / archive 页面如何转成 handline 阅读地图（系列主线、主题雷达、分享格式、条目字段）references/handline-wired-full-surface-rebuild.md：full-wired 边框语言重建记录（含 wired shadow DOM CSS 覆盖问题）references/handline-visual-review-rounds.md：会话级视觉校调记录（多轮预览→评判→修订循环）references/handline-wired-editorial-rebuild.md：wired-elements + editorial skeleton 重建主题预览页的方法references/handline-screenshot-verify.md：发布后截图验收的标准流程（CDP 截图 + VLM 视觉验证 + 边框颜色检查命令）
Naming / Aliases
- 不要做成严肃技术手册风
- 不要做成极简冷感海报
- 不要让所有线条都光滑得像工业 UI
- 不要让橙色泛滥到失去重点
- 不要把手绘感做成低可读性的涂鸦
- 不要让便签抢走标题层级
- 不要让中心隐喻消失，变成普通信息卡
Naming / Aliases
- 英文名：
infocard-handline-style
- 中文名：手绘草图风 / 白板便签风
- 常用别名：handline、doodle-note、sketch-workflow
- 触发词：手绘、草图、白板、便签、调度、并行、工作流图
- 对应主题 slug：
handline
Deployment Discipline（关键）
skill 规则必须同步到 live 页面
theme/handline.html 是 handline 风格的 live 真相源，不是临时 demo- 本 skill 的所有规则（Color / Typography / Mobile / Framework）必须同时更新到
theme/handline.html，不能只在 skill 文档里"有规则"但 live 页不应用
/tmp/handline-skill-r*.html 这类文件只是验证样本，不是风格部署目标- 每次 skill 修订后，必须把对应的 CSS 改动 commit 到
theme/handline.html
已知工作流陷阱（2026-06-12）
本次会话中：skill 通过三轮预览→评判→修订循环不断变强，但所有修订都写进了 /tmp/ 的临时文件，theme/handline.html 持续保持"文字极浅、字号极小"的失败状态，直到用户截图报告"严重不可读"才被强制修复。
正确流程：
skill 修订 → 同步改动到 theme/handline.html → commit → push → 截图验收公网页
已验证可读的 CSS Baseline
以下数值经 VLM 视觉审查确认为 390px mobile PASS。不要把正文改得更浅、更小：
| 元素 | 字号底线 | 颜色底线 | 说明 |
|---|
| 顶部元信息 | ≥12px | ≥#2a4f9e | 深蓝不可用浅蓝 |
| 标签 chip | ≥11.5px | ≥#4a4238 | 底色浅时字必须够深 |
| 对比框正文（深色底） | ≥12px | ≥#c8bfb3 | 深底上灰字最低值 |
| 对比框标题（深色底） | ≥12.5px | ≥#f2ede5 | 白字够亮 |
| 流程步骤正文 | ≥11.8px | ≥#d4cdc2 | 暖灰不可更浅 |
| 流程步骤标题 | ≥13.8px | — | 保持对比 |
| 英文副标签 | ≥11px | ≥#3d5f9e | 深蓝不可浅蓝 |
| 原则正文 | ≥11.8px | ≥#3e3830 | 深灰不可接近背景 |
| subcard 正文 | ≥11.8px | ≥#4a4238 | — |
| tiny-rail | ≥11.5px | — | — |
| 移动端 720px 正文 | ≥12.5px | — | MQ 里必须整体抬高 |
| 移动端 420px 正文 | ≥12px | — | 不能再缩 |
对比框深层规则：深色底（#171617 类背景）上的浅色字必须与背景保持足够对比；建议正文灰度不低于 #c0bab0，不要用接近米白的极浅色。
Acceptance Checklist
已知的 CSS border 坑（新增，2026-06-13）
坑：新建 handline 卡时只写 HTML 骨架、漏掉 JS 脚本（2026-06-13 新增）
症状：写了新的 handline HTML 但没有 handline 风格——看起来像"白底细黑线普通卡片"。
根因：handline 的视觉识别度来自两套机制：
- 内联 CSS（完整 token 系统 +
.tag-chip、.stats-box、.quote-band 等组件类）
- 内联 JS 脚本（SVG 手绘边框生成器：
jitter → mk → roughRect → drawRough → initRough）
这两套机制都在 ponuta 卡的 <style> 和 <script> 块里，不是从外部文件加载。/theme/handline.js 这个文件不存在，引用它会 404。
正确做法：
cp docs/20260613-ponytail.html docs/YYYYMMDD-newcard.html — 从 ponuta 复制完整骨架- 清空正文内容，保留全部 CSS / JS 脚本 / class 名称
- 只替换文字内容，不改 class 名称和 HTML 结构层级
- 推送到 GitHub Pages 后截图验收
详细操作步骤见 references/handline-card-authoring-from-ponytail.md。
坑：浅色纯 CSS 边框在米纸底不可见
坑：浅色纯 CSS 边框在米纸底不可见
症状：topbar 底边、footer 边框、section 分隔线用了 #d0c8be / #c0b8a8 等浅色，在 #f5efe6 米纸底上对比度极低，视觉上"消失"了。用户截图反馈"边框看不见"。
根因：handline 的米纸底背景是 #f5efe6（暖米黄），#d0c8be（浅暖灰）与之太接近，无法形成视觉锚点。
批量修复（已发布后发现）：
for f in docs/YYYYMMDD-*.html; do
sed -i 's/#d0c8be/#2c2723/g; s/#c0b8a8/#2c2723/g; s/#c9c0b3/#2c2723/g' "$f"
done
验证：
grep -rn "d0c8be\|c0b8a8\|c9c0b3" docs/YYYYMMDD-*.html
相关 commit：f0c7408 — Fix handline border colors: #d0c8be/#c0b8a8 → #2c2723
Implementation Notes
如果要真正落地为可发布信息卡，建议在 HTML 中使用：
- 手绘感主标题字体
- 米纸纹理背景
- 轻微噪点或手工阴影
- 关键箭头 / 便签 / 边框用橙色强调
- 中央隐喻图尽量用 SVG 或插图表达
- 内容层次控制在"标题 → 隐喻 → 解释 → 结论"
- 若使用
wired-elements，优先把它当作大区块骨架增强器，不要把所有内层小组件都 wired 化，否则页面容易像组件展板而不是 editorial cheat sheet
- theme/demo 落地后，默认执行 两轮视觉审核：桌面 + 390px 移动端各审一轮，修改后再重复一次；单轮验收通常会残留对齐问题或"桌面缩小稿"问题
- 本主题的会话级视觉校调记录见
references/handline-visual-review-rounds.md
已验证通过的 live 实现（Text-Clean / Borders-Sketchy）
commit 8ddbd17（2026-06-12）：theme/handline.html
commit ead6d9a（2026-06-12）：docs/20260612-repo-to-agent-context.html、docs/20260612-murphys-law.html、docs/20260612-matthew-effect.html
- 移除
.tag-chip 基类的 border: 1.5px solid #2c2723（与其他 rough-box 元素叠加形成内外双层边框）
- 三张卡各移除 1 行 border；验证后 tag 区域只有单层 sketchy SVG 边框
- skill Acceptance Checklist 新增 tag/chip 双层边框验收条目
commit 255c627（2026-06-12）：docs/sn-cc-gui.html
Style Boundary
references/handline-card-authoring-from-ponytail.md：新建 handline 卡时必须从 ponuta 复制完整骨架（HTML + CSS + JS 脚本），不是从零写 HTML；ponuta 卡是唯一可信的已验证实现，/theme/handline.js 不存在。references/handline-wired-editorial-rebuild.md：当用户嫌 handline 主题"只是换肤、不够像真正手绘 editorial 卡"时，如何用 wired-elements + editorial skeleton 重建主题预览页。references/handline-html-first-authoring.md：复杂 handline 信息卡何时应直接写成完整 HTML，以及 meta 里必须补齐 slug/path/category 的发布约束。
Authoring Workflow
- 对于需要多个自定义块（表格、skill grid、use-case grid、定制 footer/CTA）的 handline 卡，必须从
docs/20260613-ponytail.html 复制完整 HTML 骨架，然后替换正文内容；不要从零写 HTML，不要引用不存在的 /theme/handline.js。
- 写完 HTML 后，先补齐同名
.meta.yaml，并明确写出 slug、path、category，否则 npm run build 会在索引阶段直接失败。
- 如果你临时给页面挂了主题脚本或 DOM 初始化 hook，必须确认对应的 live 主题/页面真的提供了这些函数；不要留下依赖不存在初始化逻辑的脚本尾巴。
- 禁止行为：写了新的
.html 文件后，没有完整复制 ponuta 的 CSS + JS 脚本，就直接"看起来像普通 HTML 卡片"；这类卡片的根本问题是缺少 JS 脚本生成的手绘边框，不是 CSS 色值问题。
- Build index 工件必须同 commit（2026-06-13 新增）：
npm run build 会修改 _index.yaml 和 index.html。如果只 commit 新卡文件而漏掉这两项，CI 的 "Verify Generated Index Artifacts" 会失败，Pages 部署也会因为 _index.yaml 不含新卡 slug 而无法访问。正确顺序：npm run build → git add 新卡文件 + _index.yaml + index.html → 同一 commit → push。
Style Boundary
这套主题强调“像人在纸上边画边讲”，不是“像软件产品页面”。
如果页面看起来过于精致、过于几何、过于理工 UI 化，说明已经偏离 handline 风格。
