reskin

stardust:reskin — 内容不变，采用供体设计

用户拥有一个网站（内容源），以及一套已在其他地方存在的设计（供体：另一个线上网站，或静态 HTML 原型目录；Figma 属于未来范围）。Reskin 会重建内容网站的页面，确保所有可见内容字节都得以保留——文本、按序排列的图片、CTA、SEO 元数据——而页面表层完全采用供体的设计令牌和模块词汇。

两部分的约定各不相同：

• 内容不可妥协。 验收条件是经空白字符规范化后的可见文本、按序排列的可见图片集合，以及完整的元数据继承都逐字节相等。不是“大致相同”，而是在明确声明且可执行的规范化记录表处理后完全相等。
• 设计具有灵活性。 内容会重新布局到供体模块中；轮播图可以变成静态卡片网格，侧边栏可以变成横幅区域。结构（元素数量、标签序列）仅供参考，绝不作为验收条件——重新设计本就会重构标记。

在 UC2-E1 实验中验证的决定性规则（医疗保健网站 × 金融科技供体：2281/2281 个文本字节、7/7 张图片、47/47 个插槽、13/13 项元数据、17/17 项供体令牌探测）：页面通过内容模型以编程方式生成——绝不重新输入内容字符串。 因此，字节保真度从构造上即可保证，内容验收也就成为回归检查，而非调试工具。

输入

• <content-url> — 必填。要保留其内容的网站。
• 供体，以下选项恰选其一：
  • --donor <url> — 采用其设计系统的线上网站。
  • --donor-dir <path> — 本地静态 HTML 原型目录（claude-design / Mobirise / Relume / Lovable / v0 / 手工编码）。通过 localhost 提供服务，并通过相同路径捕获 — 参见 reference/donor-sources.md § 本地原型中的操作方案。
  • --donor-figma <url> — 尚未实现。 约定已定义（reference/donor-sources.md § Figma），但适配器属于未来范围。请准确告知用户："目前尚未实现 Figma 供体。请将画板导出为静态 HTML 原型（或提供设计的线上预发布 URL），然后使用 --donor-dir / --donor 重新运行。Figma 适配器 — variables→palette、text styles→type、frame screenshots→vision references、provenance class figma-mcp — 已在 skills/reskin/reference/donor-sources.md 中编写规格，将在后续版本推出。" 不要临时尝试不完整的 Figma 捕获。
• --pages <slug,slug,...> — 可选。将内容捕获限制为指定页面。默认值：原型集（每个页面系列选一个页面；规格中的 archetypes.json 会列出这些页面；第 6 阶段通过 migrate 将方案扩展到同系列页面）。
• --scope <selectors> — 可选。为单页运行预先声明内容根节点范围（以逗号分隔；! 后缀表示保持整个范围不变；参见 reference/content-model.md § 范围声明）。若未指定，则按页面运行范围发现流程。

设置

1. 执行主技能的设置（../stardust/SKILL.md § Setup）： 检查 impeccable 依赖、加载上下文、读取状态。流程。 如果尚未设置， 将 state.json.flow: "reskin" 写入状态 （../stardust/reference/state-machine.md § Flow keys）；如果已设置其他 流程，则打印该流程和切换命令 （$stardust reskin --switch-flow），而不是继续运行。
2. Playwright 导入解析探测——与 ../extract/SKILL.md § Setup 中的约定相同： 在项目根目录运行 node -e "import('playwright').then(()=>process.exit(0))"；如果失败， 运行 npm i -D playwright --no-save --legacy-peer-deps。在每个会进行渲染的阶段开始时 重新运行探测；后续任何一次实际的 npm i 都会清除通过 --no-save 安装的依赖。
3. 将脚本复制到项目中。 ESM 会从脚本所在的目录解析 import('playwright')，而插件目录树不包含 node_modules。将 skills/reskin/scripts/*（全部 五个文件——capture-content.mjs 和 dom-equality.mjs 会将 source-normalize.mjs 作为同级文件导入）逐字节复制到 stardust/scripts/reskin/， 并且将 skills/diff/scripts/ live-session.mjs 复制到 stardust/scripts/diff/——每个 reskin 门禁脚本（capture-content、dom-equality、donor-probe、以及 slot-coverage）都会在启动时无条件导入该文件，无论目标类型为何：没有复制该文件，每个脚本都会立即以状态码 2 退出， 即使使用 --help 或本地文件 --rendered 目标也是如此。该文件提供所有实时目标加固（真实 Chrome UA + 标准请求头、 挑战检测、无头模式隐身升级），并从 ../reskin/ 旁的 ../diff/ 解析，因此请保持这两个目录为同级目录。 执行复制操作。
4. Origin 冲突——如果 stardust/state.json 记录了不同的 site.originUrl，请停止并询问后再混用站点，遵循 ../extract/SKILL.md § Setup。

流程

阶段 1 — 摄取设计来源

设计来源的设计系统需与内容网站分开采集，存入 stardust/canon-source/。各类设计来源的完整操作步骤见 reference/donor-sources.md；概要如下：

• 线上 URL（--donor <url>）：调用 $stardust extract <content-url> --design-source <donor-url>——使用 现有技能，不做修改。采集结果存入 stardust/canon-source/：设计来源的 pages/、assets/（包括截图）、_brand-extraction.json、_crawl-log.json，以及描述性文档 DESIGN.md + DESIGN.json；同时写入 state.json.designSource = { url, capturedAt, path }——参见 ../extract/SKILL.md § 跨站点品牌来源。
• 本地原型目录（--donor-dir <path>）：在本地主机上提供目录服务（python3 -m http.server <port> --directory <path>），并针对本地主机来源运行相同的 --design-source 采集流程。在 canon-source/_crawl-log.json 中记录真实来源（对 <path> 提供的本地主机服务）。操作步骤详情——页面列表、缺少索引文件的目录、端口管理——见 reference/donor-sources.md § 本地原型。
• Figma（--donor-figma）：未来支持。原样显示 § 输入中的确切消息，然后停止。

随后编写两个由重设计流程维护的设计来源产物（约定见 reference/donor-sources.md）：

• stardust/reskin/donor-tokens.json — 经过筛选且可探测的令牌表：包含调色板角色、字体阶梯、布局尺寸、按钮规格、圆角、阴影、图案；每个值都是 Phase 5 探测可逐字断言的计算样式字符串。根据 canon-source/DESIGN.json + _brand-extraction.json + 原始计算样式筛选而来；每个值都注明来源页面。对于范围受限的设计来源采集（仅采集一个设计来源页面，不运行完整的 --design-source 流程），没有可用于筛选的 DESIGN.json、 _brand-extraction.json 或 designSource 标记——令牌表完全根据对设计来源页面进行的原始计算样式采样编写，这是一条一等并行路径（见 reference/donor-sources.md § 两条一等令牌来源路径）。
• stardust/reskin/donor-modules.md — 列举式模块词汇表（M1..Mn）：每个设计来源模块占一行，附有截图证据及其所在位置和结构描述。这是封闭集合，Phase 3 的映射说明将映射到该集合。

固定一个参考页面的规则（硬性要求）。 真实设计来源会同时运行多个设计系统——实验中的设计来源首页采用 4px 圆角和 1266px 宽度，而较早的产品页面则采用胶囊形圆角和 1080px 宽度。把它们合并会产生一个任何线上页面都未曾采用的混合设计，令牌探测也就无从断言。设计来源页面的令牌不一致时，每个模块系列固定一个设计来源参考页面，并将其记录在 donor-tokens.json 中（curatedFrom + 注明参考页面的备注），其他页面则降为佐证材料。

阶段 2 — 内容模型采集

新增能力：对每个内容页面进行面向字节的采集，与 extract 面向设计的采集不同。为每个页面运行移植后的采集脚本：

node stardust/scripts/reskin/capture-content.mjs \
  --url <page-url> \
  --scope '<sel1,sel2!,...>' \
  --normalize stardust/reskin/normalize/<slug>.mjs \
  --out stardust/reskin/content-model/<slug>/

脚本会写入 stardust/reskin/content-model/<slug>/content-model.json（完整约定见 reference/content-model.md）：每个 section-slot 包含标题及其层级、眉题和其他残留内容、正文段落、列表项、带有绝对 href 的 CTA、按顺序排列的可见图片（currentSrc + alt），以及有序流（ordered）——按文档顺序排列、带类型标签的节点，包含嵌套关系和分隔符标记；这是阶段 4 使用的渲染表面。页面级内容包括：完整的 SEO 元数据（title、description、canonical、OG、Twitter、JSON-LD、lang、favicon）、经过空白字符规范化的作用域可见文本（内容门禁的参考字符串），以及整页截图。

每个页面必须声明两项内容，因为它们是实验中最常见的两种失败模式：

1. CONTENT-ROOT SCOPE 声明。 朴素的作用域选取会悄无声息地漏掉实验页面 30% 的内容——hero 和横幅轮播位于 <header> 内，处于显而易见的 #content 根节点之外，导致字节相等性检查会与不完整的参考内容“通过”。切勿盲目信任 main 或 #content。运行作用域发现流程（见 reference/content-model.md § Scope discovery）：将捕获的作用域文本与整个 body 文本和页面截图进行对比，确认 h1 位于作用域内，并通过逗号分隔的多作用域选择器扩大范围，直到截图中所有可见且未声明为 chrome 的内容都包含在模型中。Chrome 排除项（nav、footer）应作为声明的差异项（D1 风格）记录，而不是悄悄省略。采集脚本会输出一行覆盖率信息（bodyTextLen / scopeTextLen / h1InScope），以便机械化检查。
2. 可执行规范化账本。 Cookie 同意界面的 chrome 移除、轮播去重（隐藏幻灯片不会出现在 innerText 中；克隆幻灯片会导致重复——轮播旋转会破坏字节确定性），以及任何页面特定清理，都应放在每页的账本模块 stardust/reskin/normalize/<slug>.mjs 中，该模块扩展共享默认配置（scripts/source-normalize.mjs）。采集和每项门禁都必须原样传入同一个账本文件（--normalize），这样门禁测量的就是采集所声明的规范化方式。账本是代码，不是说明文字。格式见 reference/content-model.md § Normalization ledger。

阶段 3 — 映射简报

编写 stardust/reskin/mapping.md——跨源映射简报。 完整规范和条目架构见 reference/mapping-brief.md。针对内容模型中的每个内容槽位：

• 指定供体模块 ID（来自 donor-modules.md 的封闭词汇表），并用一句话说明槽位结构与模块结构为何匹配；
• 状态 ∈ {mapped, new-module, chrome, carried-invisible}——最后一种用于字节范围内的仅供屏幕阅读器读取／视觉隐藏内容（原样带入等效隐藏元素，不使用供体模块；见 reference/mapping-brief.md § 状态语义）。

渲染前的门槛：

• 至少 80% 的内容槽位必须 mapped 到指定的供体模块。低于此比例，说明供体词汇表无法涵盖这些内容——停止并报告（见 § 停止条件）。
• 每个 new-module 条目都必须明确由供体令牌组合而成（注明借用了哪些令牌：输入框规范 + 主按钮规范等），并列入简报的统计信息块。绝不允许在渲染过程中临时拼凑新模块。
• 记录界面元素替换情况——将导航栏／页脚替换为包含源内容链接的供体界面元素，属于已声明的差异，不计入内容门槛范围。
• 声明大小写／文本转换策略。 供体可能会将眉题渲染为大写（或源内容本身如此——Chrome 的 innerText 会反映 text-transform，因此捕获的文本是渲染后的大小写形式）。底层文本必须保持字节级忠实；只能通过 CSS text-transform 应用大小写，绝不编辑字符串。策略详情见 reference/mapping-brief.md § 大小写策略。

复合源章节（一个包装器 div 中包含两个逻辑区域）必须在简报中拆分为原子槽位——章节 ≠ 槽位。

阶段 4 — 编程式渲染

已验证的决定性规则：页面由 content-model.json 生成——绝不能手动重新输入。 按页面原型编写渲染器脚本（stardust/reskin/renderers/<archetype>.mjs，参考实验中的 render-reskin.mjs），要求：

• 读取页面的 content-model.json，并从模型中插值输出所有可见字符串、href 和图片 URL（进行 HTML 转义）——如果输出的 HTML 中出现了模型里没有的字符串，渲染器就有问题；
• 根据有序流为每个槽位构建结构（sections[].ordered，reference/content-model.md § The ordered stream）：按文档顺序排列带类型标签的节点，保留嵌套关系（CTA 可以包裹标题，标题也可以包裹 CTA），用 sep 标记零分隔符的内联拼接。该流在构造时就与 innerText 一致（其文本节点是从父级渲染后的 innerText 中切分得到的——这是字节门禁的依据），因此逐字输出是安全的。按流的顺序输出节点；sep: "" 的相邻节点之间不加空白（保持内联）；绝不重新排序，也绝不根据 visibleText 重建顺序或分隔符——首轮字段处理正是这么做的（将各类型数组与 visibleText 进行贪心匹配，并将其当作判定依据），结果在重复的相同字符串、CTA 与容器两个方向的嵌套关系，以及零分隔符的内联 li 序列上耗费了三轮调试；这些情况现在都由有序流以结构化方式捕获；
• 将 formControl 节点渲染为等效控件，而非文本：<select> 中按顺序原样保留捕获到的选项文本；输入框/文本区域保留 value/placeholder——使用捐赠页面的设计 token 重新设置样式（遵循新模块的组合规则），绝不能将其扁平化为文本，也不能丢弃。<select> 的选项文本属于源页面的 innerText，因此丢弃控件会导致字节门禁失败，且没有可供结构化渲染的内容（reference/content-model.md § Slot taxonomy, formControls）；
• 将元数据块原样写入 <head>（title、description、canonical、OG、Twitter、JSON-LD——包括源内容中的错误信息，例如损坏的 JSON-LD URL：保真优先于修复；标记这类项目并在运行报告中告知人工处理，绝不能悄悄修复或悄悄保留）；
• 页面样式只能取自 donor-tokens.json（作为 CSS 自定义属性输出），以及 mapping.md 中指定的捐赠页面模块模式。遵循阶段 5 探测器所断言的渲染页面规范：内容放在 <main> 中，使用 .container 控制版心宽度，捐赠页面的主按钮使用 .btn（reference/gates.md § Rendered-page conventions）；
• 写入 stardust/reskin/pages/<slug>.html，文件自包含。

渲染器可以拆分单个节点的文本（例如将列表项拆分为眉题/日期/标题），但如果拆分结果无法还原该节点的文本，就必须明确报错（throw）——静默的部分解析就是静默丢失内容。orderedVerified 为 false 的槽位必须在渲染前检查，绝不能盲目信任；如果检查确认流中的文本确实不存在于槽位的 visibleText 中，获准的回退方案是在渲染前丢弃这些文本，并在模型的来源记录中记录此次丢弃——依据 visibleText 过滤幽灵文本是文档明确规定的解决方法，与被禁止的顺序重建做法不同（reference/content-model.md § When orderedVerified is false）。

第 5 阶段 — GATES

每个页面有 3 类门禁；命令、通过标准、容差和失败模式见 reference/gates.md。通过服务或 file:// 地址访问渲染后的页面，然后运行：

(a) 内容门禁 — 以下 3 项都必须通过：

node stardust/scripts/reskin/dom-equality.mjs \
  --source <page-url> --source-scope '<declared scope>' \
  --normalize stardust/reskin/normalize/<slug>.mjs \
  --rendered stardust/reskin/pages/<slug>.html --rendered-scope main \
  --report stardust/reskin/reports/<slug>-content-gate.md
node stardust/scripts/reskin/slot-coverage.mjs \
  --model stardust/reskin/content-model/<slug>/content-model.json \
  --rendered stardust/reskin/pages/<slug>.html \
  --report stardust/reskin/reports/<slug>-slot-coverage.md

dom-equality.mjs（从 github.com/aemcoder/skills 引入并改编，Apache-2.0）以空白规范化后的可见文本字节相等以及按顺序排列、URL 规范化的可见图片集合作为门禁条件；元素数量和标签序列仅作报告，不作为判断依据。 slot-coverage.mjs 还会证明每个模型槽位都已呈现（槽位文本子串、每个 CTA 作为一个（文本、绝对 href）对、每张图片），并逐字段断言元数据已沿用。

(b) 设计采纳门禁：

node stardust/scripts/reskin/donor-probe.mjs \
  --tokens stardust/reskin/donor-tokens.json \
  --rendered stardust/reskin/pages/<slug>.html \
  --report stardust/reskin/reports/<slug>-donor-probe.md

对渲染页面进行计算样式断言，验证其采用了供体的令牌值 — 背景色/前景色、字体系列令牌字符串、显示字重、按钮规格、容器宽度、色带配色、区块节奏。容差（颜色/圆角/字体系列精确匹配；按钮内边距 ±2px；容器 ±20px；区块节奏 ±16px）记录于 reference/gates.md § Tolerances。 接着进行并排判断：在供体参考页面截图（canon-source/assets/screenshots/）旁打开渲染页面，目视判断其采纳情况 — 探针验证令牌，肉眼确认页面呈现出供体的风格。记录判定结果。

(c) 健全性检查 — 在 1440 和 360 宽度下均不得出现水平溢出（donor-probe 会自动运行此检查；使用 --widths 可覆盖默认值）。

每类门禁最多修复一次 — 内容门禁一次，设计采纳/健全性检查一次。如果某类门禁失败，修复一次后重新运行所有门禁（修复一项门禁可能导致另一项门禁失败）。某类门禁用完修复次数后仍未解决的失败项，记录在 stardust/reskin/ledger.json 中该页面的 residuals[] 下 — 绝不悄悄忽略，也不无限循环。（两次实地运行都证明此预算合理：验证实验在 360px 页面框架上用了一次迭代；冒烟测试在每类门禁上恰好用了一次迭代 — 一次修复内容侧的分隔符输出，一次修复健全性检查侧的 360px 页面框架。若共用一次迭代，就会被迫留下虚假的残余问题；按类分配迭代次数既能限制循环，又不会掩盖真正的问题。）

第 6 阶段 — 交接

Reskin 负责原型页面；扩展和发布使用现有流水线，不作改动：

• 通过 stardust migrate 技能扩展（../migrate/SKILL.md），并指定固定供体的目标（第 1 阶段写入的 state.json.designSource 标记正是 direct/migrate 用于固定供体的内容；有界供体采集不会写入标记 — 此时应在交接说明中记录供体来源，见 reference/donor-sources.md § Two first-class token-sourcing paths）。 同类型的同级页面以同级页面层级对照通过门禁的原型进行渲染。内容规则沿用 reskin 已执行的规则 — 完整继承 ../migrate/reference/content-preservation.md。
• 通过 stardust deploy 和 rollout 技能发布，不作改动。为供体模块编写的区块遵守 Experience Workspace 可编辑性契约（deploy SKILL.md § 8、EW1–EW10），并通过 EW 门禁（block-roundtrip --ew）后才算完成。

Reskin 将自身状态写入 stardust/reskin/ — ledger.json 保存每个页面的状态（captured → mapped → rendered → gated）、门禁结果和残余问题。它不会更改核心状态机（../stardust/reference/state-machine.md）；唯一对 state.json 的操作是 extract 在第 1 阶段写入的 designSource 标记。

reskin 绝不会做什么

• 不重写或总结内容。 不管是标题、正文还是 CTA 标签，都不会；也不会通过编辑改变大小写。忠实 ≠ 整洁：源内容中的垃圾会原样保留并标记，而非修正。
• 不擅自添加章节。 每个渲染槽位都对应一个内容模型槽位；每个模块都对应 donor-modules.md 中的条目，或 mapping.md 中明确列出的新模块条目。
• 不偏离捐赠方令牌。 不使用 donor-tokens.json 之外的颜色、字体、圆角或间距。授权的捐赠方字体采用其家族令牌字符串并配置本地回退，绝不会重新打包。
• 不悄悄丢弃槽位。 任何排除在门禁范围之外的内容，都必须声明为外观差异或台账规范化操作——在 mapping.md 中声明，并可在 normalize 模块中执行。

停止条件

• 捐赠方捕获失败（带界面的回退仍被机器人拦截，原型目录无法提供服务）——原样显示 extract 的错误。
• 映射比例 < 80%——捐赠方词汇无法承载这些内容。应询问：扩大捐赠方捕获范围（增加捐赠方页面 → 增加模块），还是接受一份更长的明确新模块列表。
• 范围无法判定——内容页面上的可见内容无法由任何选择器集合覆盖（存在大量 shadow-DOM、内容嵌入 iframe）。附上截图证据并显示此情况。
• 请求 Figma 捐赠方——属于未来范围；具体消息见 § Inputs。

输出

路径	用途
stardust/canon-source/	捐赠方捕获 + 描述性 DESIGN.md/json（extract --design-source，保持不变）
stardust/reskin/donor-tokens.json	精选的可探测令牌表，固定到一个参考页面
stardust/reskin/donor-modules.md	列举的捐赠方模块词汇（M1..Mn），附截图证据
stardust/reskin/content-model/<slug>/content-model.json	面向字节的逐页内容模型（+ 源截图）
stardust/reskin/normalize/<slug>.mjs	逐页可执行规范化台账（捕获 ↔ 门禁共用）
stardust/reskin/mapping.md	映射说明：每个槽位 → 捐赠方模块、状态、理由
stardust/reskin/renderers/<archetype>.mjs	程序化渲染器（输入模型，输出 HTML）
stardust/reskin/pages/<slug>.html	渲染后的 reskin 页面
stardust/reskin/reports/	逐页门禁报告 + 截图
stardust/reskin/ledger.json	逐页状态、门禁结果、剩余差异
stardust/scripts/reskin/	五个技能脚本的项目本地副本

参考资料

• reference/donor-sources.md — 三种捐赠方类型及其捕获方案；固定一个参考页面；donor-tokens.json 和 donor-modules.md 的约定；Figma 未来约定。
• reference/content-model.md — 捕获约定：槽位分类、排序流（渲染表面）、范围发现流程、规范化台账格式、来源信息。
• reference/mapping-brief.md — 条目模式、≥80% 门禁、新模块组成规则、大小写策略。
• reference/gates.md — 两道门禁的命令、通过标准、容差、故障模式、剩余差异记录。
• ../extract/SKILL.md § 跨站品牌来源 — Phase 1 委托使用的 --design-source 捐赠方捕获路径。
• ../migrate/reference/content-preservation.md — reskin 继承的内容规则（并收紧到字节级）。
• ../diff/SKILL.md — 像素 + 结构探测；Phase 6 部署后，将其作为补充的构建侧检查复用，使用 --profile eds。