prototype

stardust:prototype

对于每个 directed 页面，都要将提议的重新设计渲染为独立的静态 HTML 文件，保存到 stardust/prototypes/<slug>-proposed.html。在浏览器中打开文件；通过聊天驱动的 impeccable 命令迭代（“让主视觉更醒目”“收紧杯测笔记网格”）。用户在对话中确认后，将其标记为 approved。

prototype 本身不会渲染设计，而是将 direct 编写的目标规范（PRODUCT.md、DESIGN.md、 DESIGN.json、stardust/direction.md）应用到 extract 捕获的页面内容（stardust/current/pages/<slug>.json）。视觉创意交由 $impeccable craft 和迭代命令（bolder、quieter、distill、polish、colorize、typeset、layout、adapt、animate、delight、overdrive、impeccable）处理。

输入

• <slug> — 可选的位置参数。仅对该页面制作原型。如果未指定，则为每个未标记为 stale 的 directed 页面制作原型。
• --all — 为所有 directed 页面制作原型，包括过时页面。
• --prep — 可选。以 migrate-prep 模式运行：补齐页面类型缺失（每种类型制作一个代表性原型），并在获得批准后，将规范写回 stardust/canon/ 和 DESIGN.json.extensions.canon。参见下文的 § Prep mode 和 reference/canon-extraction.md。通常通过 prepare-migration 编排器调用。
• --canon-from <slug> — 可选。覆盖默认的规范编写页面（即第一个获批的原型，通常是 home）。 当应由其他页面确立设计规范时使用。
• --publish-sample <slug> — 将指定的 slug 提交到 stardust 展示库。触发 reference/publish-sample.md 中说明的 publish-sample 子流程：资格检查、文件暂存、针对上游 stardust 仓库创建 PR。 需要安装并完成身份验证的 gh。展示库用于视觉演示，而非可部署的网站；允许使用占位内容，并会记录在 PR 正文的 § Unsourced content 部分。设计质量门槛仍然严格：若存在缺乏依据的 anti-toolbox 命中项、:root 令牌契约失败、data-attributes 契约失败或违反 impeccable 硬性规则，则会拒绝。P0/P1 批评结果仅发出警告，不会导致拒绝。 合并后，展示内容会通过 GitHub Pages 发布。
• --cinematic — 可选。在静态原型上叠加电影感动效风格。风格取自 DESIGN.json.extensions.motion.register（由 direct 写入）； 如果不存在，原型阶段会按照 reference/motion-registers.md § Selection heuristic 中相同的启发式规则选择一种。输出文件名为 <slug>-cinematic.html（与静态的 <slug>-proposed.html 并列，绝不替换后者）。会触发动效验证中的电影感门槛（reference/motion-validation.md § Pass 6）。
• --cinematic=<register> — 可选。与 --cinematic 相同，但强制使用指定的风格（arrival、kinetic-display、live-systems、editorial、kinetic-grid）。此覆盖会记录在 _provenance.motion.registerSource = "user-override" 中，以便审核者识别方向启发式何时被绕过。

不允许跳过

prototype 不支持 --no-* 或 --skip-* 标志。质量门槛（评审、审计、移动端适配审计、anti-toolbox 审计、内容来源扫描）就是产品本身，不是可选项。如果某项门槛拒绝文件，应修复文件或直接编辑文件以覆盖该门槛，而不是传入会悄然降低标准的标志。仍可通过聊天手动覆盖（“按现状发布”“接受 P1 发现项”）；Agent 会在 _provenance 中逐字记录覆盖内容，让下游使用者看到明确的确认。

设置

0. 重新探测 Playwright（必须作为第一步）。 先前阶段通过 --no-save 安装的 Playwright 会在之后任何一次实际运行 npm i 时被清除（摘录自 SKILL.md § Setup → --no-save 安装是临时的）。在任何渲染步骤之前，从项目根目录运行 node -e "import('playwright').then(()=>process.exit(0))" 进行探测；如果失败，则重新安装（npm i -D playwright --no-save --legacy-peer-deps）。
1. 运行主技能的设置步骤 （skills/stardust/SKILL.md § Setup）。
2. 确认 stardust/state.json 存在且至少包含一个 directed 页面。如果没有，建议运行 $stardust direct 并停止。
3. 确认项目根目录下的 DESIGN.md 和 DESIGN.json 存在。如果 不存在，则说明方向尚未完整编写——建议运行 $stardust direct 并停止。
4. 确认 stardust/direction.md 中存在有效（非待处理）的方向。待处理方向会阻止原型制作。
5. 验证范围内每个页面的来源。 根据 skills/stardust/reference/state-machine.md § Provenance validation，对本次运行将要渲染的每个页面调用 validateProvenance(page)（如果提供了单个 <slug> 参数，则验证该页面；否则验证每个非过期的 directed/prototyped/approved 页面）。如果任何页面缺少实时渲染证据，则使用该辅助函数的错误信息中止——对合成的页面记录重新运行 prototype，会在不提示的情况下将合成内容传播到渲染的原型中。检查通过后，显示 Provenance OK on N pages。
6. 阅读 stardust/current/DESIGN.md（对现有网站的描述性快照；当提议文件需要反映已捕获界面的某个方面时，在渲染期间将其用作备用参考）。

委派机制

prototype 不会直接编写 <slug>-proposed.html。主要的创作工作会委派给 $impeccable craft，并在需要时将结构规划委派给 $impeccable shape。明确说明这一机制很重要，因为 skills/stardust/reference/artifact-map.md 中记载的例外（stardust 会直接编写 PRODUCT.md、DESIGN.md、DESIGN.json、current/PRODUCT.md、current/DESIGN.md，并将 impeccable 的参考资料视为格式规范，而非运行时命令）仅适用于这五个文件。它不适用于：

• stardust/prototypes/<slug>-proposed.html — 必须由 $impeccable craft 编写，不能由 stardust 直接编写。
• 对提议文件进行迭代 — 必须通过明确的 impeccable 命令进行聊天驱动调用 （参见迭代路径一节）。
• 页面复杂到需要结构规划时 — $impeccable shape。

过去内容被编造的直接原因，是 Agent 将直接编写的例外过度泛化到了提议的 HTML。不要这样做。

调用 impeccable

Impeccable 是一项 skill，而非 CLI。通过宿主环境的 skill 调用工具来调用它，将子命令及其参数作为 skill 的参数字符串传入，格式与斜杠命令相同。在 Claude Code 中，插件会将其命名空间设为 impeccable:impeccable：

Skill {
  skill: "impeccable:impeccable",
  args: "craft <feature-description>"
}

在 GitHub Copilot 和其他会扁平化插件 skills 的宿主环境中，该 skill 名为 impeccable，并接受相同的参数字符串（craft <feature-description>）。本 skill 中的每个 Claude Code Skill { ... } 示例都可以用相同方式转换。

本 skill 中提及的子命令都通过同一个 skill 路由：craft、shape，以及迭代命令（bolder、quieter、distill、polish、colorize、typeset、layout、adapt、animate、delight、overdrive、impeccable）。

当无法使用 impeccable 时（仅 CLI 的环境、未安装插件、无法访问 skill 的沙盒），请停止并告知用户，原型渲染需要 impeccable。建议安装 impeccable 插件。不要改为直接编写 <slug>-proposed.html——craft 强制执行的验证契约（反工具箱审查、差异规则、类型比例、内容来源层级）无法通过直接编写来复现，悄悄采用替代方案会交付未经验证的输出。

因此，Stardust 在阶段 2 中的工作是：

• 整理 craft 所需的输入（来自 current/pages/<slug>.json 的页面内容、来自 DESIGN.md / DESIGN.json 的目标规范、来自 direction.md 的硬性约束，以及 reference/proposed-file-shell.md § Content sourcing hierarchy 中的内容来源规则）。
• 通过 skill 调用工具调用 craft。
• 根据契约验证结果（:root 块、数据属性、差异审查、impeccable 硬性规则、内容来源）。如果验证失败，则拒绝写入——绝不掩盖 Agent 认为“足够接近”的 craft 输出。

提案文件是 craft 写入的内容加上验证报告，并非 Stardust 编写的产物。

流程

第 1 阶段 — 规划原型（页面形态简报）

对于范围内的每个页面：

1. 阅读 stardust/current/pages/<slug>.json，了解页面的结构 和内容。

2. 阅读 stardust/current/_brand-extraction.json，了解系统 组件和交叉推广数据（网站范围内重复出现的页面元素）。

3. 阅读 stardust/direction.md 的 Active 部分，了解已确定的 方向、差异化输入和命令顺序。

4. 阅读项目根目录中的 DESIGN.md + DESIGN.json，了解目标 站点系统——设计令牌、抽象组件词汇，以及具名的 系统组件角色。站点系统告诉 Agent 设计语言是什么；本阶段决定 如何将其应用到这个特定页面。

5. 编写 stardust/prototypes/<slug>-shape.md — 每个页面的 组合式简报。格式规范： reference/page-shape-brief.md。简报包含章节 列表、布局策略、关键状态、交互模型、结构化 数据属性，以及未注明来源内容列表（衔接到 占位符契约）。直接编写——无需访谈，也无需调用 impeccable；这是 stardust 根据内容推理如何将系统应用到此页面的结果。

6. 向用户展示简报，并等待确认后再进入第 2 阶段。 用户可以直接编辑简报（调整章节顺序、取消开放问题、更改组合决策）；重新渲染第 2 阶段时，会根据编辑后的简报重新构建提议文件。

   免操作合规。 当 state.json.handsOff 为 true 时， 仍会编写并验证页面形态简报，但会跳过 等待用户确认的步骤——简报本身就是记录。 免操作模式下的审批（第 5 阶段）遵循 skills/stardust/SKILL.md § 免操作模式中定义的模式契约。

v0.2 中不会调用 $impeccable shape（理由见 reference/page-shape-brief.md § 编写流程；如果在多个站点中逐页手动编写证明不足，则重新评估）。

简报将站点级关注点（位于 DESIGN.md）与 页面级应用（逐页简报）分离。方向变更会使系统失效；只有当系统变更导致现有简报无法实现其组合时，简报才会因内容相关而过时。此项对过时标记机制的重新校准记录于 skills/stardust/reference/state-machine.md § 过时标记。

简报阶段规范（由验证器强制执行）

编写简报时必须遵守五项规范。缺少任一规范的简报都会被 验证器拒绝；验证器会指出违反的具体规则，并在第 2 阶段渲染任何内容之前停止第 1 阶段。这些规范旨在防止 AI 滥用模式：仅以 (DESIGN tokens) + (captured content) 为输入的简报，无论品牌为何都会生成模板化输出。

规范 1 — 每个章节的采集来源沿袭。 ## Sections 中的每个 章节都必须声明其采集来源。形式如下：

• "subscription-card-on-bay（整合了 pages/home.json#landmarks[hero] 中采集的横幅 2 + 右侧双卡片）" — 源自一个或多个采集的页面元素
• "site-wide system-component（继承自 _brand-extraction.json #systemComponents[kind=footer]）" — 继承自品牌页面元素的框架组件
• "direction-authorized new" — 根据 direction.md 进行组合，而非 源自采集来源（需添加一行说明，指出为该新章节提供依据的方向调整）

缺少来源沿袭信息的章节会被拒绝。来源沿袭列表保存在简报中的 _provenance.capturedSourceLineage，并会传递到渲染后的文件中。

规范 2 — 反模板审查。 对于页面应用的每种采集组件 模式（卡片／横幅／搜索行／CTA 区块／主视觉组合）， 简报都要考虑 2–3 种布局方案，并选出差异化最明显的一种。精选的默认模式规避标记用于标出凭直觉做出的选择：

• 英雄区后接品牌带状图的剪影（通用 AI 剪影）
• 用于类别导航的 5 栏图片卡片网格
• 以字体排印形式呈现的导航图标（搜索／购物车／账户）
• 居中堆叠式英雄区，配有一组双按钮 CTA
• 将捕获的形状镜像转译为新的设计要素

当设计简报采用默认模式时，必须引用捕获来源并说明该模式为何符合品牌特征（例如，“保留 5 栏网格，因为捕获网站的网格本身就是品牌标志性的目录形态；备选方案曾考虑纵向账册式布局，但品牌风格排斥这种形式”）。

如果有可用的参考研究，备选方案 SHOULD 以参考资料为依据（参见 skills/stardust/reference/reference-research.md）：备选方案应在条目的 reference? 字段中引用真实的参考屏幕，并采用该文件规定的证据格式。若无法进行研究，纯粹基于审美判断的备选方案仍然有效。

审计记录位于 _provenance.antiTemplatePass[]，每种捕获的模式对应一条记录：{ pattern, defaultReflex, alternatives[], picked, rationale, reference? }。

纪律 3——惊喜预算。 设计简报声明一个 surprise 字段，取值为 low | medium | high。设计手法来自非模板手法库——参见 skills/stardust/reference/divergence-toolkit.md § 非模板手法库，其中包含详细示例：reference/anti-template-bank.md；也可依照该库的 § 扩展规则，基于证据进行扩展。各级别的含义如下：

• low——仅限忠实于品牌的设计与改进。reimagined 模式下，变体 A 的定位；verbatim 模式下，所有 A1/A2/A3 的定位。
• medium（reimagined 模式下 B 变体的默认级别）——用一个库中的设计手法替换一个捕获到的陈词滥调。
• high（reimagined 模式下 C 变体的默认级别）——替换两个陈词滥调，并替换一种文档形态。

在 ia-fidelity: verbatim 模式下（参见 skills/stardust/reference/intent-dimensions.md § 9），每个页面的惊喜预算在全站范围内上限为 low。验证器会拒绝任何 surprise: medium 或 high 的 verbatim 方向设计简报。

low ≠ 泛泛而谈。 预算限制的是额外的偏离程度，而非工艺水准或忠实度。low 的含义是忠实于品牌 + 改进 + 完整保留标志性元素，而不是“最显而易见的忠实诠释”。常见的失败模式（某个金融科技迁移项目）是 Agent 将 low / verbatim 误解为可以把页面简化成纯文字英雄区和纯色背景，结果虽然忠实，却令人难忘，且未能充分体现改版的价值。在 low 下也要保持高工艺标准：保留品牌的鲜明元素，落实改进清单，并复现标志性设计。

必须保留标志性元素，且不计入预算。 如果捕获页面包含标志性的英雄区媒介（背景视频／画布／WebGL／Lottie）、标志性动效（滚动／视差／动态效果），或标志性视觉母题（参见 intent-dimensions.md § 8b），设计简报必须复现它——并提供静态回退方案、prefers-reduced-motion 替代方案，以及（对于叠加文字）确保可读性的遮罩层。这不会占用 low 额度：延续品牌自身的标志性元素属于忠实还原，而非偏离（§ 8b § 惊喜预算豁免）。在 _provenance.signatureElements[] 中，将保留的标志性元素记录为 { kind, capturedSource, mechanism, fallback }。**拒绝渲染：**若设计简报将捕获到的视频／画布／动画英雄区简化为静态图、渐变或纯文字英雄区，或移除了贯穿全站的视觉母题，则形态设计简报审计会拒绝该设计；应改为复现标志性元素。 字体比例让步条款。 当 medium 级或更高级别变体的捕获特征强化与 DESIGN.md 中的品牌级字体比例规则在结构上冲突时（例如“Names-At-Headline-Scale”规则，或任何其他命名的字体比例下限／上限），品牌级规则可以按页面让步。发生让步时，必须在 _provenance.surpriseTier_typeScaleYields[] 中注明，格式为：{ rule, variantDominantDimension, capturedTraitAmplified, yieldedTo, rationale }。品牌级让步条款本身（即 DESIGN.md 中命名的例外）属于项目侧，而非规范侧；规范只要求在让步生效时提供逐页引用。参见下文“摩擦豁免条款”第 4 条。

准则 4 — 基底转换必须有意为之、有明确名称且少见。 默认情况下，整页使用单一基底。每个基底例外都必须在简报中注明用途（“突出展示特色咖啡促销时刻”）。每页基底转换超过两次即不符合简报要求。 转换记录在 _provenance.substrateTransitions 中，格式为 { default, exceptions[] }。

例外 — 以基底为键的文档形态（摩擦豁免条款第 2 条）。 当变体的 surprise: high 手法采用以基底为键的文档形态（zine、catalog-card、poster-sequence）时，各分区的基底即为该文档形态的结构节奏。不适用最多 2 次转换的限制；相反，每个分区的基底都必须附带逐分区的捕获来源引用（通常是每个 SKU 的标签颜色、每页的品牌颜色，或来自捕获站点的每种内容类型的背景惯例）。该例外记录在 _provenance.substrateTransitions.note 中，并注明文档形态名称及引用来源。当满足以下条件时，验证器允许超过 2 次转换：

1. 声明了 surprise: high，并且
2. 从库中选取的手法是 document-shape，且其子类型以基底为键（zine / catalog-card / poster-sequence），并且
3. exceptions[] 中的每次转换都附带逐分区的捕获来源引用。

如果三项条件中任意一项不满足，则重新启用次数限制。

准则 5 — 按分区跟踪标题层级和语气分类。 简报要求：

• 每页只声明一次 H1；后续分区使用 H2；子级使用 H3。
• 文案中的每个字面值都必须归类为以下类别之一：captured-verbatim、direction-authorized rewrite 或 placeholder。任何分区都不得在文案未分类的情况下交付。

分类列表保存在 _provenance.voiceClassification[] 中，格式为 { section, classification, copy?, source? }，并传递到渲染后的文件中。

占位符缎带标签（摩擦豁免条款第 3 条）。 系统组件中的诚实提示标签（占位符缎带、“TBD”徽章、“from the brand team at migrate”标记）属于方向授权的界面装饰，而非占位符内容。它们用于标记占位符文案／数据；应在 _provenance.unsourcedContent[] 中列出的是文案／数据本身，而不是缎带文字。将缎带标签归类为 direction-authorized chrome (per friction #3)，以保持占位符枚举清晰（避免在每个组件实例中重复计数）。

阶段 2 — 渲染提议页面

按照 reference/proposed-file-shell.md § Required structure 渲染 stardust/prototypes/<slug>-proposed.html。其中的硬性要求：

• :root 令牌块必须是第一个 <style> 中的首个内容（遵循 skills/stardust/reference/token-contract.md）。
• 每个 section 都必须带有结构性数据属性（遵循 skills/stardust/reference/data-attributes.md）。
• 来源信息块必须是 <head> 的第一个子元素。
• 自包含：不使用外部 CSS，不使用外部 JS。
• 如果 stardust/current/assets/favicon.<ext> 存在，必须在 head 中将网站的 favicon 内嵌为 data: URI（遵循 reference/proposed-file-shell.md § Hard requirements #8）。
• 除非 direction.md 授权更改内容，否则必须保留当前页面的内容（主视觉文案、CTA、导航、正文）。
• 内容来源层级（reference/proposed-file-shell.md § Content sourcing hierarchy）：渲染的每个字面值都必须来自 current/pages/<slug>.json、语气样例，或方向授权的更改；否则必须使用强制性的 PLACEHOLDER 视觉标记进行渲染。不得编造统计数据、地址、引语、税号、营业时间、价格或具名人士的文字。提议文件的 _provenance.unsourcedContent[] 会列出所有占位符，以便 migrate 拒绝发布未经验证的内容。

将繁重的创意工作交给 $impeccable craft：

• 将页面内容和已确定的方向作为功能描述传入。
• 将 DESIGN.md / DESIGN.json 作为设计系统参考。
• 将 direction.md § Anti-references 和 § Divergence inputs 作为硬性约束传入（避免 craft 悄然偏离已确定的方向）。
• 跳过 craft 的“北极星样稿”生成步骤（direction.md 已是设计简报）。跳过 craft 的“shape”调用（如果阶段 1 需要，已完成）。

现代 Web 指南查阅。 当渲染实现滚动驱动动画、视图过渡、锚点定位、容器查询或对性能敏感的主视觉媒体，且已安装 modern-web-guidance 插件时，搜索该插件（npx -y modern-web-guidance@latest search "<query>"），并遵循检索到的指南；在 _provenance.guidesConsulted[] 中注明指南 ID。若未安装该插件，则静默跳过。

craft 返回后，验证输出：

• 存在完整的 :root 块（token-contract.md）。
• 每个 section 都带有数据属性（data-attributes.md）。
• Anti-toolbox 审核通过（每项命中都依据 divergence-toolkit.md § 1 进行说明；在 DESIGN.json.extensions.divergence.anti_toolbox_hits 中记录审核结果，并注明审核时的修订）。
• 遵守 Impeccable 硬性规则（OKLCH、类型比例 ≥ 1.25、无条件反射式套路）。
• 内容来源扫描——渲染输出中的每个字面值都必须可追溯至允许的来源（reference/proposed-file-shell.md § Content sourcing hierarchy）。任何不符合要求的值，都必须包裹在带有强制视觉标记的 [data-placeholder] 元素中，否则验证失败。在此扫描期间构建 _provenance.unsourcedContent[] 列表。

如果验证失败，不要写入文件。向用户说明违反的具体规则并给出建议的修复方法。

Craft 阶段规范（写入前验证器）

渲染后的文件写入磁盘前会触发四项规范检查。这些检查在 craft 返回输出后、文件写入前运行；失败时将拒绝写入，并提供替代方案（规范 6）或规则引用（规范 7、8）；规范 9 会登记检测器忽略项，而非拒绝写入。

规范 6 — 反射式拒绝字体预检。 使用 grep 检查已声明的 font-family，对照 skills/stardust/reference/divergence-toolkit.md § Reflex-reject fonts 中的拒绝列表。如果命中拒绝列表中的字体系列 ≥ 3 个，则拒绝写入，并从替代表中提出维度等效且不在列表中的替代字体。 这项检查仅针对智能体可以自由选择 font-family 声明的已渲染文件。使用已捕获的展示字体和正文字体（参见 direct/SKILL.md § Mode A — Brand-faithful mode）进行渲染的 Mode A 会绕过此检查——继承的字体并非凭直觉选择。请在 _provenance.reflexRejectAudit.bypassed 中记录绕过原因，并注明已捕获的字体。

准则 7 — 可变字体轴的运用。 当已解析方向的 expressive 或 distinctiveness 轴偏离默认值时（参见 skills/stardust/reference/intent-dimensions.md §§ 2 + 5），每个页面都必须使用差异化工具包中的字体方案，至少非平凡地运用 1 个可变字体轴。工具包的字体集提供了具名轴方案：

• serif-luxury 字体集 → Fraunces 轴方案：opsz 144, SOFT 100, WONK 1
• bauhaus-functional 字体集 → Bricolage 轴方案：opsz 96, wght 600
• tactile-humanist 字体集 → Recursive 轴方案：MONO 1, CRSV 0, CASL 0.5

如果页面声称实现了表达性或鲜明度上的变化，但页面中所有文字都使用静态字重和静态样式，则无法通过此项检查。

仅含静态字体的字体系列优先规则（摩擦豁免 #1）。 当已捕获／固定的展示字体不包含可变轴时，按以下规则替换字体系列：

1. 如果已捕获／固定的展示字体是可变字体，按字体方案运用其轴（标准路径）。
2. 如果已捕获的展示字体所属字体系列仅含静态字体（Bellfort、GT Sectra static、其 woff2 文件在运行时检查前无法解析出 fvar 表的手写自定义字型），则将展示字体系列豁免于此项检查，改为运用正文字体系列的轴（通常是 Public Sans 或 Hanken Grotesk 等常用字体中的 wght 和 ital）。
3. 请在 DESIGN.json.extensions.divergence.font_deck.notes 中记录该字体系列仅含静态字体的情况，以免下游页面重复执行检查。

如果预检无差别地搜索 font-variation-settings，那么每个使用仅含静态展示字体的品牌忠实渲染页面都会触发检查。此豁免既保留了准则的本意（在可变行为存在之处运用它），也遵循了准则的字面要求：已捕获的字体系列确实没有可供运用的轴。

非字体集中的强调字体必须提供具名的表达性位置（marginal-tag、pointer-scribble、headline-callout、badge-fill——参见工具包 § Font deck — expressive positions）。引入字体却未指定位置，属于凭直觉选择，而非表达性位置。

准则 8 — 保真度等级（--fidelity=quick|refined|production）。

• quick（默认）——草图级保真度。简报中的决策已落实；细节决策仍为暂定。
• refined——按 reference/fidelity-refined-pass.md 增加一次工艺细化：将正式的字体比例设为 CSS 自定义属性；对行内数字使用 font-variant-numeric: tabular-nums；对标题使用 text-wrap: balance，对正文使用 text-wrap: pretty，并在 html 上使用 hanging-punctuation: first；导航悬停时显示滑动式左侧线条；列表项悬停时显示细线；将眉题、标题和基线对齐的更多链接组合成小节标题三联组；用斜体展示性文字对替换结构含糊的 <b>；将侧边栏底部重新设计为字体排版信息板。
• production——在 refined 的基础上，为每次渲染进行 WCAG AA 审核，并执行加固流程（加载状态、错误状态、内容溢出边界）。

此等级在运行调用中声明，并持久化到 _provenance.fidelity。默认值为 quick。 规范 9 — 在逐字保真模式下绕过文案节奏检测器。 这将规范 6 的 Mode-A 推理从字体扩展到文案。impeccable 的设计检测器包含文案语气规则（em-dash-overuse、marketing-buzzword 以及类似的文案节奏检查），这些规则默认文案可以由 Agent 改写。在 ia-fidelity: verbatim 模式下——或任何正文文案被标记为 captured-verbatim 的保真/Mode-A 渲染中——这种假设从根本上就是错误的：文案属于源品牌，按内容来源层级逐字复现；为了满足节奏规则而改写文案，正是保真设置要防止的捏造行为。因此，当渲染文件的文案分类为 captured-verbatim（根据规范 5 的 voiceClassification）时，应在设计钩子触发前，将这些文案节奏规则登记为 <slug>-proposed.html 文件的有意忽略项——就像规范 6 绕过对固定字体系列的反射式拒绝检查一样。忽略范围仅限提案文件，绝不可涵盖项目自身的源文件（区块、样式、组件），因为这些规则仍适用于此处：这些文案确实由 Agent 编写。将绕过情况记录在 _provenance.copyCadenceBypass 中，并列出被忽略的规则和分类依据。2026-06-26 的一次 SaaS 网站运行就遇到了这种情况：在逐字指令下，钩子标记了网站自身标题中的破折号和“enterprise-grade”（“Built on Enterprise-Grade Components”），唯一正确的应对方式是保持捕获的文案原样不动，并记录绕过情况。

绕过范围有限：仅涵盖文案节奏规则。逐字保真不豁免结构和工艺检测规则（design-system-radius、对比度问题、反射式布局瑕疵）——这些规则约束的是 Agent 自己的 CSS 和结构，而保真模式不会冻结这些内容。要将某条规则列入此绕过项，它必须是以捕获文案为对象的文案语气规则。

阶段 2.4 — 动效应用（使用 --cinematic 时）

仅当传入了 --cinematic（无论是否显式指定了 register），或者 DESIGN.json.extensions.motion.register 由 direct 编写且用户未选择退出时，才会触发。生成 stardust/prototypes/<slug>-cinematic.html，与静态的 <slug>-proposed.html 并存——绝不替换静态原型。

步骤：

1. 解析 register。 对于单变体运行，读取 DESIGN.json.extensions.motion.register。对于多变体运行（项目根目录中存在 DESIGN-<id>.json 文件时），读取当前正在渲染的变体对应的 DESIGN-<id>.json.extensions.motion.register——每个变体都可以有自己的 register，也可以完全省略（此时变体将静态渲染）。如果在 CLI 中传入了 --cinematic=<register>，则 CLI 值仅对作用范围内的变体生效（未设置 <slug> 筛选器时适用于每个变体；否则仅适用于匹配筛选器的变体）。

   在 _provenance.motion.registerSource 中记录来源（每个变体由 DESIGN 编写时为 "direct"，CLI 覆盖时为 "user-override"）。如果这两种方式都未为当前变体解析出 register，则使用 reference/motion-registers.md § Selection heuristic 中的选择启发式。如果启发式本身也没有返回 register（例如，变体的 PRODUCT.md 品牌个性不匹配五种 register 中的任何一种，并且根据 reference/motion-registers.md § Extension rule，资源库中也没有适用的、符合证据形态的扩展 register），则完全跳过该变体的阶段 2.4——以静态方式渲染。

   按变体解析 register，可让 uplift 生成仅变体 C 使用动效的三变体集合：direct 仅将 register 写入 DESIGN-C.json，因此阶段 2.4 仅对 C 触发（A 和 B 以静态方式渲染）。

2. 暂存 Lenis 资源。 将 skills/prototype/assets/motion/lenis.min.js 和 lenis.min.css 复制到 stardust/prototypes/（操作幂等 — 如果哈希值匹配，则跳过）。 电影感原型通过相对路径加载这些文件。

3. 读取规范运行时。 原样嵌入 reference/motion-runtime.md § The canonical script 中的内联脚本， 并根据当前寄存器的令牌默认值重写 animConfig 常量（reference/motion-registers.md § The five registers § Token defaults）。

4. 添加寄存器 CSS。 将寄存器专属的关键帧和类规则（入场关键帧、视差 CSS 自定义属性、跑马灯动画、脉冲动画）追加到文件的 <style> 块中。每个寄存器的 关键帧集合都是固定的；参见 reference/motion-runtime.md § Per-register tuning。

5. 为目标 HTML 添加标注。 遍历渲染后的 DOM，并根据寄存器的词汇表添加动态 data-* 属性：

   • arrival：在章节标题、正文、CTA 和卡片上添加 [data-anim]；在数值上添加 [data-countup]；在主视觉照片上添加 [data-parallax]。
   • kinetic-display：在大多数章节上添加 [data-anim]；在展示屏风格的标题上添加 [data-split] （<h1 data-split>DINE</h1>）；在终端代码／闸机编号上添加 [data-flip]；在展示屏标题上添加 .word 跨度，以实现剪切路径文字擦除效果。
   • live-systems：在每个 ops-tile 和 卡片上添加 [data-tile-anim]；在每个数值数据上添加 [data-countup]； 在每个条形图内部元素上添加 [data-fill]；在实时数据容器上添加 .live-sweep； 在顶部滚动条上添加 .marquee__track。
   • editorial：仅添加 [data-anim]；在主视觉图像上添加幅度较小的 [data-parallax]；绝不添加 [data-flip]／[data-fill]／[data-split]。
   • kinetic-grid：在卡片上添加 [data-tile-anim]；在章节标题上添加 [data-anim]。

   完整的寄存器属性矩阵：reference/motion-registers.md § Data-attributes consumed。

6. 注入 <noscript> 回退内容。 将 reference/motion-runtime.md § No-JS fallback 中的无 JS 覆盖规则添加到 <head>， 使文件在没有 JavaScript 时退化为静态结束状态。

7. 更新 _provenance。 添加 motion 块：

   "motion": {
     "register": "<register-name>",
     "registerSource": "direct | user-override | heuristic | extension",
     "runtimeVersion": "v1",
     "lenisAssets": { "js": "lenis.min.js", "css": "lenis.min.css" },
     "attributesEmitted": ["data-anim", "data-countup", ...]
   }
   

8. 交接给 Phase 2.8（动态效果验证）。由于渲染后的文件声明了 _provenance.motion.register 字段，reference/motion-validation.md § Pass 6 中的 电影感检查门会自动触发。

静态 <slug>-proposed.html 不受此阶段影响。 两个文件都可供审核；如果重设计需求包含动态效果，品牌负责人会看到电影感版本；如果重点是迁移／无障碍审核，则会看到静态版本。

输出路径

文件	所属阶段	时机
stardust/prototypes/<slug>-proposed.html	Phase 2（始终）	始终写入。
stardust/prototypes/<slug>-cinematic.html	Phase 2.4（--cinematic）	同时写入；保留静态版本。
stardust/prototypes/lenis.min.js	Phase 2.4（--cinematic）	从技能资源复制。
stardust/prototypes/lenis.min.css	Phase 2.4（--cinematic）	从技能资源复制。

何时使用纯静态路径

静态原型仍是以下工作的核心产物：

• 符合品牌规范的继承审核（动效是增量内容—— 静态原型是“没错，这就是我们，只是焕然一新”的标准 展示界面）。
• 无障碍审核（动效驱动的页面在减少动态效果状态下更难 评估）。
• 迁移使用（migrate 将静态原型作为 主要来源。它不会合并电影化层—— 根据 skills/migrate/SKILL.md § Phase 2 → Cinematic sibling，它会 将动效资源（lenis.min.*）保留到 migrated/assets/motion/，并在 sidecar 中记录 cinematic-variant-not-consumed）。

静态原型必须独立通过每一项关卡—— 电影化层无法弥补未通过 Phase 2.5–2.7 的静态原型。

Phases 2.5 – 2.8 — 质量关卡：评审 → 审核 → 适配 → 动效（原则 9）

默认情况下，四个强制关卡阶段会在任何原型 进入 prototyped 前运行。它们落实原则 9：评审涵盖设计， 审核涵盖技术正确性，适配涵盖视口行为，动效涵盖由滚动 和时间驱动的编排正确性。来自这四个阶段中任何一个的 P0/P1 发现项，都会阻止进入 prototyped，直至得到确认。没有任何阶段 提供退出标志（根据 § No opt-outs）。

子阶段	重点	检查内容
2.5 Critique	设计判断	AI 廉价感惯性、层级退化、对比度／认知问题、风格偏移
2.6 Audit	技术正确性	a11y（替代文本、焦点、计算所得的对比度比率）、4–6 种视口下的响应式溢出、性能（LCP、图像大小）、依赖 JS 的隐藏状态
2.7 Adapt	视口行为	文档宽度 · 溢出 · 粘性定位 · 网格列 · 在 1920 / 1440 / 1280 / 800 / 414 / 375 下的字体缩放、移动导航折叠审核
2.8 Motion	滚动／时间驱动的正确性	容器裁切导致的显现时机、动画范围与阅读位置、anim-enter 触发器可达性、减少动态效果覆盖的完整性、无 JS 回退、多视口滚动驱动检查

只有在渲染文件声明了 ≥ 1 个具名编排（根据页面形态说明中的动效栈）， 或使用了 animation-timeline:、@scroll-timeline、IntersectionObserver 驱动的 进入触发器，或读取 getBoundingClientRect() 的 rAF 循环时， 或者 Phase 2.4（在 --cinematic 下应用动效） 生成了带有动效属性的 <slug>-cinematic.html 文件（根据 reference/motion-attributes.md），才会运行 Phase 2.8。电影化原型还会 触发 reference/motion-validation.md § Pass 6 中的电影化模式关卡（Lenis 引导、减少动态效果回退的完整性、 滚动劫持检查、三个位置的截图、风格匹配 审核、动效 C 悬崖检测器）。静态原型完全跳过 该原则对应的检查。

2026-05-13 的 wasatch 演练发现了简报和制作阶段都未发现的两个真实缺陷（/beers 变体 C 中多个配对的 WCAG 计算偏差 0.27–1.86 分，以及目录首个条目中的 LCP 图像被延迟加载）。两个问题都是由 审核部分发现的，而非评审。检测器的对比度 计算和响应式性能检查是核心审核项；缺少这些检查，文件就会带着可量化的 WCAG 缺陷交付。

Phase 2.5 — 评审

在浏览器中打开拟议文件之前，针对渲染后的拟议文件运行两个并行 验证器：critique 和 audit。它们明确设计为互补的一对——评审 涵盖设计（AI 廉价感惯性、层级、品牌契合度、 认知负荷）；审核涵盖技术正确性 （无障碍／性能／主题／响应式／ 反模式）。只运行评审会遗漏所有可量化的 WCAG／性能／响应式缺陷；只运行审核会遗漏 品牌不符和设计廉价感。此项检查是契约， 而非客套。 一次针对 2026-05-04 硬件厂商首页原型的评审返回了 1 个 P0 + 2 个 P1 + 3 个 P2；对同一产物进行审计后又发现了 六项额外问题（没有跳过链接、主题轮播图不支持键盘方向键导航、主视觉约 3.5MB 且没有响应式 <picture>、动画使用布局属性、通过 JS 控制显示但没有 <noscript> 回退、scroll-behavior: smooth 未遵循 prefers-reduced-motion）。这些都不是设计问题，仅靠评审也无法发现。如果没有 审计关卡，该页面就会被标记为 prototyped，同时存在可量化的 WCAG 违规问题。

流程：

1. 并行运行两个验证器。 在一批技能调用中调用两次 impeccable（此处展示 Claude Code 的形式；参见 § 调用 impeccable）：

   Skill { skill: "impeccable:impeccable",
           args: "critique stardust/prototypes/<slug>-proposed.html --json" }
   
   Skill { skill: "impeccable:impeccable",
           args: "audit stardust/prototypes/<slug>-proposed.html --json" }
   

   每个验证器都会返回一个 JSON 问题列表——每项问题都包含 priority（P0 / P1 / P2 / P3）、category（hierarchy / contrast / motion / a11y / perf / responsive / 等）和一行描述。将评审问题写入 提议文件的 _provenance.critique[]，将审计问题写入 _provenance.audit[]（追加；绝不覆盖以往运行的条目）。

2. 自动排除忠于品牌的反转。 两个验证器在 Mode A 渲染中都存在已知误报：Arial 回退字体会被判为“字体过度使用”，眉题全大写会被判为“正文全大写”，而品牌采集的调色板中若包含纯白或纯黑，也会触发标记。向用户显示问题前，将每项问题与 DESIGN.json#extensions.divergence.brand_faithful_inversions[] 以及 DESIGN.md#narrative.rules（例如允许使用全大写的场景）进行比对。若问题的类别和目标与已批准的反转相符，则将其排除；为保留审计追踪，将原始列表保存在 _provenance.<critique|audit>[] 中，并为相应条目添加 dismissedAsBrandFaithful: true 标记。面向用户的报告只显示实际问题。

3. 视觉关卡。 渲染提议文件的屏幕截图，并将其与采集的源屏幕截图并排查看 （若存在，则为 stardust/current/assets/screenshots/<slug>.png）。 根据视觉判断，而不是查看 DOM：品牌契合度（品牌所有者会说“这就是我们”吗？）、标志性元素保留（是否保留了主视觉媒介 / 核心图案，符合原则 3 中关于标志性元素的条款）以及一眼可见的层级（视线是否落在简报指定的位置？）。记录 _provenance.visionCheck = { verdict: pass|fail, observations[] }； fail 会按照与评审 / 审计相同的关卡机制作为 P1 问题处理。视觉关卡是确定性的评审 / 审计组合的补充，绝不取代它们。

4. 在面向用户的报告中呈现问题，按两个验证器的优先级分组，并注明来源 （critique: / audit:）。逐字列出最前面的 5 项 P0/P1；将 P2/P3 汇总为各来源的问题数，并提供“展开查看全部”指引。格式如下：

   Critique + audit on home-proposed.html
   
   P0 (1)
     audit:    skip-link missing — header has no <a href="#main"> as first focusable
   P1 (4)
     critique: hierarchy regression — H2 visually heavier than H1 in section #features
     audit:    hero <img> 3.5MB; no responsive <picture> set despite captured srcset
     audit:    transition: width animates layout properties (jank)
     audit:    .hero scroll-behavior: smooth not gated by prefers-reduced-motion
   P2 (3 critique, 1 audit) — expand to see
   P3 (0)
   

5. 若任一验证器发现 P0/P1 问题，则阻止状态变为 prototyped。 如果合并去重后的问题列表（排除忠于品牌的误报之后，并计入第 3 步中视觉关卡的 fail，该失败在此处作为 P1 处理）包含任何 P0 或 P1，则暂时不要在 state.json 中将页面标记为 prototyped。提议文件已写入磁盘，可在浏览器中打开，但页面仍保持 directed，直到满足以下任一条件：

   • Agent 修复问题（按照第 4 阶段的迭代路径，运行由聊天驱动的 impeccable 命令，然后重新运行第 2.5 阶段）。
   • 用户明确确认（例如“按现状发布” / “接受这些 P1 问题”）。将用户的确认原话分别记录到 _provenance.critique[] 和 _provenance.audit[]，这样重新运行时就能识别已有确认，不会再次询问。

   P2/P3 问题不会阻止状态变为 prototyped，只作为建议呈现。

6. 可选择启动 LLM 设计审查子 Agent，在用户希望获得超出确定性检测器所能提供的内容时，提供独立意见（如果执行环境提供子 Agent 原语；否则在同一会话中单独进行一轮审查）。仅在用户明确提出请求（“给我更深入的评析”“再听听另一种意见”）或确定性检查发现 ≥3 个 P0/P1 问题时触发（这表明渲染存在多个值得仔细检查的问题）。默认关闭，以保持循环快速运行。

两个验证器都是必需的。没有可选退出标志——如果某项发现会造成问题，但用户仍想发布，用户需要在聊天中明确说明（“按原样发布”／“接受 P1 问题”），并将确认内容逐字记录在 _provenance.critique[] 和 _provenance.audit[] 中。约定是必须运行关卡；用户可以覆盖关卡，但覆盖操作必须明确记录。

失败处理：根据委派机制，如果 impeccable 不可用，原型将拒绝运行（impeccable 是硬性要求）。不存在发布未经验证输出的降级模式。

阶段 2.6 — 审计（检测器详情）

审计子阶段作为上文 § 阶段 2.5 中 impeccable 调用的第二个并行分支实现。本节介绍该分支中触发的审计专用检测器，包括并行评析流程未涵盖的检测器。

WCAG 对比度计算。 审计会重新计算文件中每一组文字与底色之间的对比度。先前在简报阶段／制作阶段手动估算的 _provenance.wcagContrast 区块不具权威性；以审计计算的值为准。手动估算值与计算值之间相差 ≥ 0.25 时，会作为 P1 问题呈现。2026-05-13 的 wasatch dry-run 在 /beers 的变体 C 中发现了 0.27–1.86 个点的差异；在审计结果推动下，将 Cutthroat 底色从 #1c8a7a 加深到 #177566，以达到正文 AA 标准（4.5:1），并将 pour-link 从黄色改为白色。

大号文字豁免检查。 若声称符合 WCAG“大号文字”的 3:1 最低对比度要求（而非正文的 4.5:1），则渲染后的字号必须为 ≥ 18pt 常规 或 ≥ 14pt 粗体。审计会验证渲染后 DOM 中的字号，而不是源 CSS 中的字号。声称符合大号文字豁免的 13px Bellfort 700 链接未通过检查（13px 的 Bellfort 700 低于 14pt 粗体的最低字号）；该问题为 P0。

LCP 图像审计。 页面首屏中的第一张图像必须声明 loading="eager" 和 fetchpriority="high"。采用延迟加载的 LCP 图像属于 P1 问题。检测方式：计算 getBoundingClientRect() 后与初始视口相交的第一个 <img> 必须同时具备这两个属性。

依赖 JS 的隐藏状态检测器。 审计会捕获通过 clip-path: inset(0 100% ...)、opacity: 0 或 transform: translateX(-100%) 隐藏内容的初始状态 CSS，且这些内容的显示依赖 JS 类名切换（通常由 IntersectionObserver 切换 .in-view／.is-visible／html.js-anim）。如果观察器失效（JS 运行缓慢、CDN 被拦截、启用了 NoScript），元素就会一直不可见。

对 CSS 文本使用以下检测正则：

/(clip-path:\s*inset\(0\s+100%|opacity:\s*0\s*[;}]|transform:\s*translate[XY]\(-?100%)/

如果检测到匹配项，且没有 <noscript> 为相同选择器添加可见样式，也没有 prefers-reduced-motion 规则跳过隐藏操作，则该问题为 P0（对于 JS 未执行的用户来说，页面默认处于损坏状态）。页面可在 _provenance.audit.acknowledged[] 中声明以下缓解措施：

• 使用 <noscript> 块将隐藏的选择器重新设为可见。
• 使用 prefers-reduced-motion: reduce 块完全跳过隐藏操作。
• 使用动画门控选择器模式（html.js-anim .selector { ... hidden ... }），并在样式表加载前于 <head> 中内联设置门控类，避免观察器失效时元素一直无法显示（wasatch /beers 的变体 C 证实了此模式有效——借助 html.js-anim 门控和 CDN 故障回退，全部 4 个文件的检测均通过）。

阶段 2.7 — 适配（审批前强制执行）

每个原型都必须经过 $impeccable adapt 和适配审计，之后才接受用户的审批。否则，整个流程只会交付桌面版 HTML——视口经过渲染和迭代调整，适用于约 1440×900 的尺寸，而流程中更早的阶段都不会生成响应式适配。

在 stardust 的早期版本中，此阶段是阶段 5.5（在审批之后运行）。当前规范将其提前至阶段 2.7，使其与评审和审计一起成为 prototyped 的门槛。适配的实质逻辑未变；改变的只有触发时机（审批前，而非审批后）。有关未变更的实现，请参见下文的 § 适配流程。

适配流程

对渲染后的文件运行 impeccable adapt（Claude Code 形式；参见 § 调用 impeccable）：

Skill {
  skill: "impeccable:impeccable",
  args: "adapt stardust/prototypes/<slug>-proposed.html"
}

如果存在，则传入从 DESIGN.json#extensions.breakpoints 捕获的视口断点；否则，adapt 会选择默认值（640 / 768 / 1024 / 1280 是 stardust 规范默认值——根据下文 § 移动端适配审计，将高于 640 的值用作“移动端断点”是不妥的）。完整的目标列表是 1920 / 1440 / 1280 / 800 / 414 / 375——adapt 会验证每个视口的文档宽度 · 溢出 · 粘性行为 · 网格列 · 字体缩放。

根据阶段 2 运行的相同契约验证适配后的文件（:root 令牌块、数据属性、反工具箱审计通过、impeccable 硬性规则、内容来源）。适配是在现有渲染结果上进行迭代；不得重新引入违反契约的内容。

在提议文件的 _provenance.adapt[] 中追加一条记录，记录：ISO 时间戳、应用的断点列表、新增的 @media 规则数，以及适配过程中发现的任何布局决策（轮播 → 堆叠、侧边栏 → 抽屉、汉堡菜单 → 菜单）。

移动端适配审计

阶段 2.7 还会执行一项严格审计，与适配过程本身分开，检查生成的文件能否通过发布或迁移。同一审计也会在 migrate 和 --publish-sample 时重新运行，防止适配后仍有问题的渲染结果漏过检查。

出现以下任一情况时，拒绝该文件：

• 缺少 <meta name="viewport" content="width=device-width, ...">，或 width 被设为固定像素值。
• 文件中完全没有 @media (max-width: ...) 规则（仅适用于桌面端）。
• 文件声明的移动端断点高于 640px——如果 @media (max-width: 1024px) 是最窄的断点，这就是“实际上并未针对手机进行适配”的明显特征。Adapt 至少应生成一条 ≤ 640px 的规则。
• **在宽度为 360px 的渲染视口下：**某个定位标记导致 document.documentElement 或 document.body 的 scrollWidth > clientWidth。拒绝代码： audit/responsive: horizontal-overflow-at-360px。
• 在宽度为 360px 的渲染视口下：<header> 内 <nav> 的任何后代元素，其计算后的 font-size 小于 11px。拒绝代码：audit/responsive: nav-readability-floor。
• 在宽度为 360px 的渲染视口下：<header> 内任何 flex/grid <nav> 的计算后 gap（或 column-gap）小于 10px。拒绝代码相同。

最后三项条件需要实际渲染文件才能检查——无法仅从 CSS 文本推断。标准检查方式是一个简短的 Playwright 代码片段（fixtures/mobile-nav-audit.mjs），由 Agent 在 360×800 的视口下针对该文件运行。审计消息必须包含指向 stock-template 文档的提示：

建议修复方法：套用 stock hamburger 模式 skills/prototype/reference/mobile-nav-collapse.md

移动端导航折叠

当审计拒绝上述任一导航相关代码时，Agent 会应用 reference/mobile-nav-collapse.md 中记录的标准纯 CSS 汉堡菜单模式（HTML + CSS + ≤10 行内联 <script>，用于无障碍支持）。页眉会添加 data-nav-collapse="hamburger"，以便下游使用者检测是否应用了该模式。

源码顺序至关重要。 基础 .ds-nav-burger { display: none; ... } 规则必须放在 <style> 块的顶部（在 :root 之后、任何 @media 规则之前）。注入后的顺序检查是 reference/mobile-nav-collapse.md § 源码顺序中记录的一行 awk 命令；它会断言基础规则的行号小于第一个 @media (max-width: 640px) 规则的行号。退出码 0 = 顺序正确；退出码 1 = 出现回归。

标准模式为默认选项；reference/mobile-nav-collapse.md § 替代模式记录了优先级 + 溢出、底部导航和侧边抽屉等有效替代方案，用户可以提出请求，但 Agent 不会自行选择。

阶段 2.8 — 动效验证（声明动效时必须执行）

静态 DOM 门禁（2.5 评审、2.6 审计、2.7 调整）均在 scrollY=0 且时间未流逝时读取提议文件。因此，它们无法捕获动效特有的故障模式：

• 当 anim-enter 触发器在用户阅读位置之后触发时，内容会卡在 opacity: 0。
• 当 translateY 动画的幅度超出父级的余量空间时，内容会渲染在其父级 overflow: clip 边界之外。
• 滚动驱动的动画只有在整个区块完全滚出视野后才完成 animation-range，导致内容在可阅读时段内一直不可见。
• rAF 循环在调整大小、加载字体或延迟加载图片时，因基线测量值过期而产生偏移。
• 变换导致的区块重叠不会出现在静态 DOM 中。
• prefers-reduced-motion 回归：编排被禁用，但元素仍停留在隐藏的“from”状态。
• 无 JS 回归：编排的隐藏初始状态没有 <noscript> 回退方案。

完整流程（5 轮——滚动位置探测、问题分类、动效错误检查、无 JS 状态、滚动驱动动画的多视口检查）见 reference/motion-validation.md。

当渲染后的文件声明 ≥ 1 个具名编排（根据 _provenance.motion.choreographies[]），或包含以下任一内容时，执行阶段 2.8：animation-timeline:、@scroll-timeline、使用 target.classList.add('anim-enter-visible') 模式的 IntersectionObserver，或由 getBoundingClientRect() 驱动的 rAF 循环。静态原型跳过此阶段。

问题分为设计如此（编排在此位置理应产生此状态；简介中有具名编排说明）或错误（编排产生了非预期状态）。错误会阻止状态变为 prototyped，直到问题得到确认或修复。

如果经过 3 次递归循环迭代仍无法自动修复错误，请向用户说明问题、分类理由、已尝试的 3 种修复方案，以及需要用户输入才能完成的建议补救措施。不得悄悄降低门禁要求。

在提议文件的 _provenance.motionValidation 中追加一条记录，包含：ISO 时间戳、运行过的探测位置、测试过的视口、问题（hiddenInViewport、sectionOverlaps、clippedReveals、rangeMismatches）及每个问题的分类，以及 fixesApplied[]。将通过验证的截图保存至 stardust/validation/<slug>/motion-<viewport>.png。

变体趋同检测器（规范 10）

当渲染的变体数 N > 1 时，每个 <slug>-<id>-shape.md 都要声明：

• 一个独特的 dominantDimension 值（各变体之间不能重复）。
• 一个 compositionDelta 字段，列出该变体的章节顺序或布局策略与每个同级变体存在差异的 ≥ 2 种方式。 示例：
  • compositionDelta: ["section-order: hero ↔ stats", "layout: 3-up-grid → vertical-narrative"]
  • compositionDelta: ["ia-priority: commercial-conversion → catalog-browse", "hero-layout: split-photo → type-led"]

如果 compositionDelta 为空或流于形式（仅有 token 级别的差异——“颜色 A 与颜色 B”、“字体粗细 400 与 600”），Phase 1 将视为未满足需求，并重新开始构思。验证器会逐对检查：每对变体 (A,B)、(A,C)、(B,C) 都需要 ≥ 2 项结构性改动。

模式感知契约（与 stardust/reference/intent-dimensions.md § 9 中的 ia-fidelity 配合）：

• 在 ia-fidelity: verbatim 模式下——A1/A2/A3 只能在表层维度上有所不同（type-weight、type-scale、density、motion-energy、color-temperature、spacing-rhythm）。在 verbatim 模式下，禁止结构性差异（章节顺序／有无／IA 优先级／布局策略）。检测器会反向判定：仅有表层差异则通过，存在结构性差异则拒绝。
• 在 ia-fidelity: reimagined 模式下——A、B、C 变体必须声明结构性 compositionDelta，且每对至少有 2 项改动。仅有表层差异则视为未满足需求。

wasatch /beers A / B / C 的试运行中，每对都声明了 5 项结构性差异（_provenance 中的 compositionDelta_vs_A、compositionDelta_vs_B 区块）——substrate-strategy、section-presence、photo-treatment、section-order、section-completeness。检测器对全部三对均判定为通过。

单变体运行（N = 1）完全跳过规范 10。

Phase 4 — 打开并迭代

（阶段编号跳过 3；原 Phase 3——构建查看器——因移除了逐页前后对比查看器而被删除。文档中的交叉引用仍使用 Phase 4、5、5.5。）

1. 使用 open <vfs-path> shell 命令，在浏览器中打开刚写入或刚更新的 <slug>-proposed.html（当 N > 1 时，则打开用户选择的变体后缀）。该命令会通过预览 service worker 路由 VFS 路径——本地原型文件不要使用 playwright-cli open，因为它会绕过预览 service worker，并导致 FILE NOT FOUND 错误。pipeline-automation 模式下跳过。
2. 在 state.json 中将页面标记为 prototyped——须以 Phase 2.5 critique + Phase 2.6 audit + Phase 2.7 adapt + Phase 2.8 motion validation（如触发）的结果为准（规范 9）。如果其中任何一项在（品牌忠实度反转机制自动关闭相关发现后）返回 ≥ 1 个 P0 或 P1 发现，且用户尚未确认，则页面保持为 directed（而非 prototyped）；在报告中按来源分组展示发现（critique: / audit: / adapt: / motion:），并建议修复问题或明确确认。此状态转换本身不需要审批（后续有单独的审批步骤）——但必须通过所有门槛，因为若在任何门槛未通过 P0/P1 检查的情况下标记为 prototyped，会误导下游使用方（migrate、dashboard）对原型质量的判断。
3. 报告原型路径并停止。后续迭代通过聊天驱动的 impeccable 命令或直接调用进行（参见下文 § 迭代路径）。

迭代路径

初次渲染后，可以通过两种方式进行优化。两者并不互斥——单个页面在其整个生命周期中可以同时经历这两种方式。

1. 聊天驱动（默认）。 用户在聊天中给出优化短语——“让首页的主视觉更醒目”、“收紧杯型备注网格”、“少点企业风”。Agent 会：

   • 对照 skills/stardust/reference/intent-dimensions.md 阅读该短语，识别它调整了哪些维度。
   • 查阅 skills/stardust/reference/impeccable-command-map.md，选择匹配的 impeccable 命令（通常是 bolder、quieter、distill、typeset、colorize 或 layout）。
   • 执行前向用户展示解析出的计划。
   • 对 <slug>-proposed.html 执行所选命令（如果短语指定了某个范围，则针对其中的特定部分执行）。
   • 按照 Phase 2 重新验证（:root 块、数据属性、反工具箱审查无问题、impeccable 硬性规则），并更新提案文件的来源信息。

2. 直接调用 impeccable。 用户直接运行 impeccable 命令——$impeccable bolder stardust/prototypes/home-proposed.html。Stardust 不会参与；浏览器标签页会重新加载磁盘上的内容。这是允许的，文档也将其列为受支持的备用方式。（包括对提案文件运行 $impeccable live，以便用户在浏览器中迭代选择器——这是用户直接调用的外部工具；stardust 不会驱动其轮询循环。）

主技能中的“开放且有理有据”原则适用于路径 1：Agent 会在运行任何命令前公开说明对该短语的理解，绝不会悄悄将优化映射为固定命令。

Phase 5 — 批准（+ 回并，第 III 部分）

批准必须明确进行。Stardust 不会自动批准。

用户在对话中说 “approve ” 或仅说 “approve”，即可表示批准。Agent 会在写入状态前确认 slug，然后继续操作。

批准时：

1. 确认提案文件的来源信息块列出了当前启用的 direction.md（防御性检查——如果迭代期间方向发生变化，用户必须先根据新方向重新制作原型）。
2. 按照 reference/approval-fold-back.md（合并规范的第 III 部分）执行批准回并。当获批的变体不是 A 且 ia-fidelity 为 reimagined 时，原型会读取获批文件的 _provenance.differentiationFromA[andB] 块以及简报的 compositionDelta，与当前启用的方向进行比较，并建议回并任何结构性调整。用户选择 fold site-wide（默认）/ fold page-local / don't fold。在 ia-fidelity: verbatim 下，根据设计，回并操作无效（A1/A2/A3 是表层分支；没有结构性内容需要回并）。标志：--auto-fold 跳过确认；--no-fold 完全退出回并。
3. 在 state.json 中将页面标记为 approved。追加一条 { status: "approved", at: <ts> } 历史记录。
4. 清除页面上的任何 stale 标志。
5. 输出：

   home: approved
     proposed: stardust/prototypes/home-proposed.html
     mobile:   adapted at Phase 2.7 (4 @media rules at 640/768/1024/1280)
     fold-back: page-local (substrate-keyed-zine pattern stays on /beers)
   
   Next: $stardust migrate home  (write final redesigned static HTML)
   

批准时不再运行 Adapt——它已在 Phase 2.7 作为 prototyped 前置关卡运行。mobile: 行会报告 Phase 2.7 的结果，以便在审核时保持上下文连贯。

如果有多个页面正在处理中，批准按页面分别进行；用户可以批准部分页面，同时继续迭代其他页面。

阶段 5.5 — 适配移动端（已停用；请参阅阶段 2.7）

作为 Discipline 9「评审 → 审计 → 适配」循环的一部分，适配和移动端适配审计已移至阶段 2.7，并成为将状态设为 prototyped 的门槛，而非审批门槛。2026-05-03 的电商展示失败模式（利益相关者在手机上查看不同版本时，看到的却是未经调整的桌面布局）并未改变——只是门槛在生命周期中更早触发，因此未经适配的原型根本不会进入 prototyped 状态。

实现（impeccable adapt 调用、移动端适配审计、mobile-nav-collapse 内置模式）位于上文 § 阶段 2.7。本节保留为锚点，供仍引用阶段 5.5 的外部交叉引用使用。

过期处理

当 direction.md 发生变化时，原型的 againstDirection 来源信息会过期，state.json 会将页面标记为 stale: true。默认行为：

• $stardust prototype（无 slug）会跳过过期页面并报告数量：2 stale pages (home, about) — re-run with --all.
• $stardust prototype home 会对 home 执行操作，即使其已过期。
• $stardust prototype --all 会为所有已设定方向的页面重新制作原型，包括过期页面。

成功为过期页面重新制作原型后，清除其 stale 标记，并将 againstDirection 更新为新的当前方向。

输出

路径	用途
stardust/prototypes/<slug>-shape.md	每页的构成简报（阶段 1 输出，供 craft 使用）。
stardust/prototypes/<slug>-proposed.html	重新设计方案（聊天驱动迭代的目标、迁移来源、面向用户的审阅界面）。
stardust/state.json	更新页面状态和审批历史。
DESIGN.json	更新 extensions.divergence.anti_toolbox_hits，以及本原型渲染产生的任何审计修订。

失败模式

• 没有已设定方向的页面。 建议运行 $stardust direct，然后停止。
• 方向待定。 拒绝运行；用户必须先解决方向问题。
• 验证失败（缺少 :root 块、缺少数据属性、anti-toolbox 命中缺乏依据、违反 impeccable 规则）。 不写入文件。指出具体失败并建议修复方法。
• impeccable 不可用。 拒绝运行——impeccable 是硬性要求（Delegation 机制）。建议用户安装 impeccable 插件后重新调用。

并发

根据 state-machine.md：stardust 不会锁定。对不同 slug 并发运行两个 prototype 是安全的。对同一 slug 并发运行时，最后写入者生效；如果用户明确尝试，应发出警告。

准备模式（--prep）

使用 --prep 调用时，prototype 会执行扩展流程，补齐页面类型缺口并编写规范。探索模式运行方式不变：按 slug 编写构成简报、通过 $impeccable craft 渲染、在浏览器中打开、迭代、审批。

--prep 会在标准流程基础上增加三项内容：

1. 补齐页面类型缺口

找出 state.json.pages[].type 中尚无已审批原型的所有页面类型。对于每个缺口，prototype 会制作一个代表性页面的原型（由用户选择 slug；默认使用某个 spec 的 archetypes.json 中该类型的 rep_url，否则使用该类型的第一个页面）：

• article 类型页面中没有已审批文章：制作一篇原型
• listing 类型页面中没有已审批列表：制作一个原型
• program、form、static——同样处理
• landing——首页；如果尚未制作原型，则优先处理
• unique 类型页面——不创建原型；迁移时会将其渲染为单独页面

用户为每种类型选择一个变体。同类型的后续页面会通过派生该审批版本来迁移（skills/migrate/SKILL.md 中的路径 A′）。

2. 首次批准时写回 Canon

首个获批的原型（默认是首页；通过 --canon-from <slug> 覆盖）将成为 Canon 作者。批准后，按照 reference/canon-extraction.md 提取 Canon 并写回：

1. Chrome HTML → stardust/canon/header.html、 stardust/canon/footer.html、可选区域。
2. 复合 CSS → stardust/canon/canon.css。
3. 固定的设计令牌 → DESIGN.json.extensions.canon.pinned。
4. 模块的 Canon 渲染 → stardust/canon/modules/<id>.html。
5. 组合式调整（由 LLM 编写，3–7 行）→ DESIGN.json.extensions.canon.compositionalMoves。

通过 DESIGN.json.extensions.canon.files 中的 { path, sha } 引用所有提取的文件。每个 Canon 文件都带有 stardust:canon 来源注释，注明源 slug、源原型和区域。

3. 后续批准时写回 Canon

对于非 Canon 作者的模板获批（文章、列表等）， canon-extraction 会按照 reference/canon-extraction.md § 冲突解决的说明以差异模式运行：

• 全新项目（Canon 中尚不存在的模块、新的复合 CSS 类、新的组合式调整）→ 以增量方式追加到 Canon。 添加一条历史记录，说明添加的内容。
• 与 Canon 逐字节匹配 → 不执行任何操作。
• 与 Canon 冲突 → 默认记录为偏离： 迁移或原型页面会以内联方式携带该偏离，并以 data-deviation="<reason>" 标记；页面的 migrationDecisions[] 会记录一条 canon-deviation 条目。 Canon 保持不变。

如用户希望将新变体提升为 Canon（这会为使用了已更改项目的下游页面添加过期标记），或拒绝并重新迭代原型，可在准备摘要中按冲突覆盖默认行为。若未明确覆盖，则将冲突记录为偏离并继续批准。

准备摘要

prototype --prep complete
=========================

Approved archetypes:
  landing   home (V01 Polish)            canon-author
  article   news/post-housing-summit
  listing   news (the index)
  program   programs/shelter
  form      donate
  static    about

Canon: stardust/canon/ + DESIGN.json.extensions.canon
  Sources:  home → article (1 deviation logged), listing (clean),
            program (1 deviation logged), form (clean), static (clean)
  Modules:  8 confirmed; canonical renderings written
  Pinned:   sectionPadding, densityTier, typeScale set

Next: $stardust migrate  (apply canon to every page in inventory)

默认模式保持不变。

参考资料

• reference/page-shape-brief.md — 每页的构成简报 格式（Phase 1 输出，craft 输入）。页面级部署决策记录在此； 站点级系统决策记录在 DESIGN.md 中。
• reference/canon-extraction.md — 在 --prep 模式下批准原型时 执行的五步 canon 提取流程。
• reference/proposed-file-shell.md — 拟议文件的架构和 必需结构（:root token 块、数据属性、 溯源信息、内容来源层级、移动端适配审计）。
• reference/publish-sample.md — --publish-sample 子流程： 资格检查、文件暂存，以及针对上游 stardust showcase 创建 PR。最终将原型作为公开 示例发布到 https://{owner}.github.io/stardust-2/。
• reference/mobile-nav-collapse.md — 当移动端适配审计因 horizontal-overflow-at-360px 或 nav-readability-floor 而拒绝时，Phase 2.7 自动应用的 纯 CSS 标准汉堡菜单模式。包含可直接复制粘贴的 HTML+CSS+JS、审计冒烟测试命令，以及 替代模式词汇表。
• reference/motion-validation.md — Phase 2.8 流程： 滚动位置探测、问题分类、动画问题 检查（裁剪容器的显现时机、动画范围与阅读位置的关系、anim-enter 触发器的可达性、 减弱动态效果覆盖的完整性、无 JS 时的状态、多视口滚动驱动检查）。 文中记录了可复用的 Playwright 探测模式。
• reference/motion-registers.md — 五种忠实于品牌的动态 配置（arrival、kinetic-display、live-systems、 editorial、kinetic-grid）、将 PRODUCT.md 品牌个性特征映射到配置的 选择启发规则，以及针对从网站自身捕获的动态效果定制配置的 § 扩展规则。 Phase 2.4（动态效果应用）会使用此文档。
• reference/motion-stack.md — 电影感原型的技术选型：Lenis + CSS keyframes + rAF + IntersectionObserver。 不选择 GSAP 的原因、包策略和 Lenis 固定版本流程。
• reference/motion-attributes.md — 电影感运行时使用的 data-* 词汇（[data-anim]、[data-tile-anim]、 [data-countup]、[data-flip]、[data-fill]、[data-split]、 [data-parallax]）。根据当前启用的配置添加了注释。
• reference/motion-runtime.md — 为每个电影感原型提供支持的规范内联运行时 脚本。唯一真实来源；Phase 2.4 会原样嵌入。
• reference/fidelity-refined-pass.md — 用于 --fidelity=refined craft 微调阶段（纪律 8）的具体 CSS 配方。
• reference/anti-template-bank.md — 纪律 3 所用非模板化设计手法的 实例（字体替换 / 基底提升 / 反转 / 文档形态 / 尺度位移），以及针对基于证据的新手法的 § 扩展规则。
• skills/stardust/reference/reference-research.md — 搜集 真实设计参考（使用 refero MCP，无法使用时回退到 WebSearch；不可用时优雅跳过）；纪律 2 在提供以参考为依据的替代方案时会使用。
• reference/approval-fold-back.md — Phase 5 回写流程（合并规范的第三部分）：差异算法、呈现 UX、写入逻辑、标记过时、 --auto-fold / --no-fold 标志、 原样无操作判定。
• fixtures/composition-delta-good.md — 示例构成简报，包含较强的结构性 compositionDelta（通过纪律 10）。
• fixtures/composition-delta-trivial.md — 示例构成简报， 仅包含 token 级差异（未通过纪律 10）。
• ../stardust/reference/token-contract.md — :root token 块（跨领域使用，供 prototype 和 migrate 使用）。
• ../stardust/reference/data-attributes.md — 结构化数据 属性词汇（跨领域使用，供 prototype 和 migrate 使用）。
• ../stardust/reference/divergence-toolkit.md — 渲染和迭代期间使用的反平庸规则。
• ../stardust/reference/intent-dimensions.md — 用于解读聊天驱动的优化短语的 7 轴 词汇（迭代路径 2）。
• ../stardust/reference/impeccable-command-map.md — 何时 使用各个 impeccable 命令。聊天驱动的迭代期间（路径 2）会查阅此文档，以便为优化短语选择命令。
• ../stardust/reference/state-machine.md — 页面生命周期 和过时规则。
• ../stardust/reference/artifact-map.md — 溯源信息结构。
• impeccable 的 reference/craft.md 和 reference/live.md — stardust 委托使用的底层 impeccable 命令。