stardust

stardust

你正在使用 stardust 技能：引导式重新设计现有网站。用户负责说明需求；你的任务是理解需求的含义、提出计划，并通过一组精简的子命令执行，实际设计工作则交由 impeccable 完成。

设置（先于其他所有操作运行）

1. 确认已安装 impeccable。 Stardust 强依赖 impeccable，且不提供备用方案。请在运行环境安装技能或插件的位置查找 impeccable 技能：运行环境向你公开的技能列表、项目技能目录（.claude/skills/、.agents/skills/、.cursor/skills/、.github/skills/），或运行环境的插件缓存（Claude Code：~/.claude/plugins/cache/；GitHub Copilot：~/.copilot/installed-plugins/*/impeccable/skills/impeccable）。如果未安装，请停止并告知用户：

   Stardust 需要 impeccable。请从 https://github.com/pbakaus/impeccable 安装，然后重新运行命令。

   版本提示（仅供参考，绝不阻塞）。 Stardust 有意不固定 impeccable 版本——设计工艺应始终采用最新版本——而且运行环境默认不会通知第三方插件更新（Claude Code 的市场自动更新功能对 impeccable 这样的第三方市场处于关闭状态；Copilot 不会提供更新通知）。因此，每个会话运行一次 node <plugin>/skills/stardust/scripts/impeccable-version-check.mjs （如果 impeccable 位于运行环境的技能目录而非插件注册表中，请添加 --local <impeccable-dir>），并在检测到新版本时，将其输出的一行内容原样告知用户；该脚本会打印适用于找到 impeccable 的运行环境的更新命令。其他任何结果（当前、未知、离线）都只是无关信息——不要提及，也绝不要因此停止运行或降低运行质量。 同一脚本加上 --where 会打印 impeccable 的技能目录（其中包含 SKILL.md 和 reference/）；记下该目录一次——读取 impeccable 格式规范的阶段（reference/init.md、reference/document.md）应按章节从该目录读取，不要在之后进行文件系统搜索。

2. 检查目标状态文件。 项目根目录下的 PRODUCT.md 和 DESIGN.md 是 stardust 的目标状态；检查它们是否存在（列出目录即可）。此处不要运行 impeccable 的上下文加载器（scripts/impeccable context）：它会输出适用于 impeccable 自身流程（init、new-work、detector、更新检查）的指令，不适用于 stardust 的设置，而且每当 stardust 调用 impeccable 命令时，impeccable 都会自行运行该加载器。如果本会话历史中已知结果，则跳过。

3. 读取 stardust 状态。 如果存在 stardust/state.json，请读取它（reference/state-machine.md 定义了其架构）。记录哪些页面处于 extracted、directed、prototyped、approved 或 migrated 状态。

4. 读取 impeccable 命令注册表。 解析 <harness>/skills/impeccable/scripts/command-metadata.json。这是 24 个 impeccable 命令的唯一事实来源；推理时绝不要硬编码这些命令。

5. 状态台账。 每个 stardust 技能都必须在每个阶段开始和结束时，按照 reference/run-status.md 向 stardust/status.jsonl 追加一行阶段转换记录——使用 skills/stardust/scripts/ledger.mjs <skill> <phase> <start|end|blocked> [--detail …] 写入（它知道每个技能的阶段名称，并会对未知名称发出警告；--strict 会拒绝未知名称），绝不要用手动构造的 printf 写入。页面状态通过 skills/stardust/scripts/state.mjs advance <slug…> --to <status> 更新；恢复运行的 Agent 可通过 ledger.mjs tail 和 state.mjs summary 了解当前状态。

6. 项目卫生（幂等）。如果 stardust/.gitignore 不存在，则从 reference/stardust.gitignore 写入；绝不要编辑项目中的副本。在 git 仓库中：根目录 .gitignore 应涵盖 .env / .env.*（由受管的 # >>> stardust 区块维护）；如果存在 .hlxignore，其中应列出 stardust/；并且 git check-ignore -q stardust/state.json 必须失败——如果成功，则停止并指出对应规则。对于 stardust/ 下超过 50 MB 的已跟踪二进制文件，应提出使用 LFS 的建议，但不要写入配置。详见 reference/artifact-map.md § 版本管理。

路由

设置完成后，根据用户的输入进行路由：

• 无参数。 按照 reference/state-machine.md 中的说明，呈现状态报告：项目状态、各页面状态表格、建议的下一条命令及理由。不要编写任何内容。任何恢复会话也同样适用：在包含 stardust/state.json 的项目上开启新会话、“继续”、“进展到哪了”，或由记忆文件驱动的恢复会话。先呈现状态报告（其中会注明工作流和最后的关卡编号），然后通过其技能进入下一阶段——由流程驱动，而不是由记忆驱动。（记录：一次持续 144 小时的恢复会话完全没有调用 stardust 技能，而是通过 grep 重新阅读流程，并遵循了先前上下文中的记忆。）

• 第一个词是子技能名称。 委派给匹配的子技能，并传递其余参数。下方列出的是子技能的裸技能名称；如何调用取决于所用工具环境。Claude Code 会将插件技能命名为 stardust:<name>（Skill 工具）；GitHub Copilot 和其他会扁平化插件技能的工具环境则会公开裸名称 <name>。如果工具环境没有技能调用工具，就阅读子技能的 SKILL.md 并按其中的说明执行。切勿将 stardust 的 extract 和 audit 技能与 impeccable 的 extract 和 audit 命令混淆；后者始终写作 $impeccable <command>。主技能会路由到所有同级子技能：

  关键字	负责范围
  extract	抓取并采集当前网站
  direct	确定视觉方向
  prototype	为各页面制作重新设计原型
  migrate	将整个网站迁移为平台无关的静态 HTML
  prepare-migration	migrate-prep 流程（准备阶段、资源、动态功能关卡）——仅限重新设计工作流
  replica	同设计迁移（更换平台，保留当前设计）——运行自身的保留模式准备流程，然后移交给 migrate/deploy/rollout
  reskin	将忠实于字节的内容重新排布到单独定义的供体设计系统上
  deploy	将单个页面转换为 EDS 区块 + DA 交付
  rollout	将整个迁移后的网站转换为 EDS，并设置覆盖范围 + 交付关卡
  dynamics	迁移中的动态界面——检测、分类、分流、实现、验证（API、搜索、表单、模态框、媒体、标签、客户端渲染、表格数据）；与迁移绑定，可由 prepare-migration / replica / migrate / rollout 调用，也可在已迁移的网站上单独调用
  diff	原型 ↔ 构建保真度探测（像素 + 结构）
  audit	从三个视角进行网站审计——设计张力、SEO/技术、LLM 可见性——生成带评分的报告 + 发现项台账
  qa	对线上网站进行只读式部署后 QA 扫描——路由、保真度、模板一致性、渲染、视觉回归、SEO、链接、无障碍、性能——仅生成发现项报告，从不修复
  uplift	一次性售前编排器（3 种变体）
  spec	迁移前的网站规格说明——页面、附带复用判定的区块、动态功能、营销技术、待定决策——作为已提交的知识文件保存

  • prototype 可接受 --cinematic（或 --cinematic=<register>）， 在静态原型之上叠加符合品牌风格的动态效果配置 （参见 skills/prototype/reference/motion-registers.md）。
  • uplift 是一次性售前编排器：接收一个 URL，并生成三个差异化变体 （其中一个为全动态效果版本），无需用户进一步协调。适用于用户希望 跳过 extract/direct/prototype 流程链的情况（参见 skills/uplift/SKILL.md）。

• 迁移到 EDS——从两种流程中选一种，绝不可混用。 在回答任何“如何迁移 X” 相关问题之前，请先参阅下文的「两种迁移流程」；路由方式取决于是否保留设计。

• 首词是其他内容（自由措辞）。 将其视为重新设计意图。加载 reference/intent-reasoning.md 并逐步执行其中的流程。在向用户展示已确定的 计划之前，不要执行任何 impeccable 或 stardust 命令（在自动执行模式下， 计划会记录在 stardust/direction.md 中，而不是等待确认——参见「自动执行模式」）。

两种迁移流程——选一种，绝不可混用

当用户想将网站迁移到 AEM Edge Delivery（或任何全新的前端）时，需求会决定保留还是 更改设计：除非需求明确要求重新设计，否则迁移应保留原有设计。这将决定所选流程； 后续流程链是共用的。

• 任一流程开始前的范围界定：“界定范围／估算／规划／编写 X 的迁移 规范”、“哪些页面使用了区块 X”、重定向或 404 清单 → spec。与流程无关：绝不标记 flow。
• 迁移时重新设计： extract → direct → prototype，或通过一个编排步骤 prepare-migration（带确认关卡的准备级联）→ migrate → deploy（单页试点）/ rollout（整个网站）。
• 保留当前设计（重新平台化）： replica → migrate → deploy / rollout。replica 涵盖保留模式下的准备级联——extract --prep 是其第 1 阶段，机械式的方向保留步骤取代 direct --prep，而带关卡的原型复现 （按断点衡量源站保真度）取代 prototype --prep。绝不可在 replica 之前或 之后运行 prepare-migration；此流程没有独立的准备步骤。
• 采用供体的新设计，内容保持不变： reskin——内容通过字节级门禁，设计取自 另一个线上网站或本地原型。
• 默认情况下，两种迁移流程都会涵盖动态界面。 导入前的关卡 （prepare-migration 4.5 / replica 第 2 阶段，并以 migrate 作为安全网） 会运行 stardust dynamics 技能的第 1–3 阶段，确保每个 API、搜索框、表单、模态框、 播放器、标签和客户端渲染界面在导入前都确定处理方式；rollout D2 会实现可复现的 条目，qa 会重新验证一致性。仅重新设计的工作（uplift、单独的 extract）绝不运行： dynamics 属于迁移范畴。

选择并记录流程。 在加载任何子技能之前，先阅读用户需求：

• 表示保留设计的措辞无需提问，直接选择 replica：“exact replica”“1:1”“pixel-perfect”“faithful”“same design”“keep the current design”“as is”“re-platform only”“migrate keeping the design”，或明确要求所有维度保持不变的表述（ ia-fidelity: verbatim，且固定调色板、字体和密度）。
• 表示重新设计的措辞选择重新设计流程：“redesign”“modernise” “refresh”“new look”“rethink”“reimagine”——任何会改变设计维度的表述。只有明确措辞才会触发；不会自行推断。
• 其他任何情况（“migrate X to EDS”）均视为忠实迁移：选择 replica，flowSource: "default"，不提问，无论交互模式还是无人值守模式。首次回复会附上 replica 的流程说明（“流程：replica——保留设计。如需更改，现在请说 switch to redesign。”），让这一决策始终明确。 如果网站地图包含 1,000 个以上的 URL 且没有规范说明，还会提示“大型网站：请说 spec first 来界定范围。”仅提供此选项，无人值守模式下不提供。

委派前，将选择写入 state.json 中的 flow / flowChosenAt / flowSource （reference/state-machine.md § Flow keys）。子技能会强制执行该选择：如果项目有 state.json 但没有 flow，migrate、deploy、rollout 和具有迁移意图的 extract 会拒绝启动迁移；prepare-migration 在 flow: replica 时会拒绝执行，而 replica 在 flow: redesign 时会拒绝执行。切换必须明确发起——$stardust replica --switch-flow / $stardust prepare-migration --switch-flow——并将旧流程中已原型化或已迁移的页面标记为过时（§ Per-page state）。

规划辅助内容只属于一种流程。 重新设计流程：prepare-migration 计划及其阶段门禁、规范、模块目录、“先学习模板，再编译”类型的模板计划。保留设计流程：replica 的不一致登记表和 progress.json、原型门禁账本、rollout 波次。在 replica 运行中使用重新设计流程的操作步骤或计划模板——反之亦然——属于路由缺陷：应拒绝执行，或在 direction.md 中标记并返回本节。（记录：一次保留原设计的迁移采用了仅适用于重新设计的“先训练模板，再编译”计划，耗费 1 小时、45 轮交互和 36 M 个 token，之后才回退；另一次则针对要求保留设计的请求，在一个已经说明这两种流程的插件上加载了 prepare-migration——只有说明、没有防护措施并不能阻止这种情况。）

在针对迁移的首次回复中明确说明所选流程，并说明 replica 无需执行 prepare-migration 步骤，以免用户还要追问适用哪种准备流程。

无人值守模式

在任何 stardust 调用中使用 --hands-off，或用户明确提出（“fully hands-off”“no approval gates”“run autonomously”）时启用。启用后，将 state.json.handsOff: true 写入状态文件（架构说明见 reference/state-machine.md § Hands-off keys），并在 stardust/direction.md 中追加一行启用记录。此模式取消的是等待，而非验证：流水线中的每个质量门禁仍会完整运行；改变的只是由谁来处理交互式暂停。

在无人值守模式下，流水线中的所有交互式门禁都会自动处理：

gate	自动处理方式
direct 澄清问题	根据已收集的证据（stardust/current/）推导答案，并在 direction.md 中将每项标记为具名假设
prototype 简报确认等待	跳过；依据已撰写的简报继续
prototype 审批	仅在所有质量门槛均通过后，由 Agent 自行判断予以批准；在 state.json 中该页面的 approved 历史记录里标记为 approvedBy: "hands-off"
prepare-migration 阶段门槛	按照 --skip-confirm 处理
rollout	端到端全自动运行
dynamics 所有者决策（后端、新主机上的标签、数据源所有权、区域设置范围）	发布临时层级，将每项决策按名称记录在 dynamic-features.md 和一致性报告中，然后继续；受监管的 PII 表单保持阻止状态；具名假设绝不会将状态设为 decided-out

免人工处理时的默认值（仅当调用中另有说明时才覆盖）：

• 统一的规范方向。 不要扩散出多个变体——确定一个方向，并在 direction.md 中记录理由。
• 有理有据地提出容量上限，并明确说明。 默认上限为总计 100 个页面，每种模板 20 个；调用时使用“所有页面”（或 --all-pages）即可解除上限。页面清单优先级：（1）页眉和页脚中的所有链接页面；（2）章节着陆页／概览页；（3）涵盖所有模板的各类详情页。设置状态行会根据网站说明页面清单的数量（roster 94 of 2,532 discovered — cap 100/20）；达到上限的页面清单绝不能称为完整网站。将上限记录在 direction.md 中。
• 先做第一个页面。 完整网站复刻任务会先交付一个页面（首页或指定页面）：../replica/reference/first-page-first.md。
• 已捕获的页面必须保留在页面清单中。 语言地区绝不是丢弃已捕获页面的理由：必须交付 state.json 中的每一行——内容重复的语言地区外壳页面归入其对应页面的同级层；D3-multilingual 用于从未捕获的语言树。
• 通过文件指针委派，按章节阅读。 委派给 Agent 的任务说明应列出所需文件和章节（state.json、页面的 schema、阶段的 SKILL.md 章节）；绝不内嵌参考文档。阅读参考文档时，应按标题和行范围查阅，而不是从头到尾通读（replica 提供了 skills/replica/scripts/section.mjs，正是为此而设计：使用 --list 查看文档大纲，再选取一个标题；它适用于任何 Markdown 文件——整份参考文档有 30–40k 个字符，而一个步骤所需的章节只有 2–4k 个字符；在一次有记录的会话中，由于 cat 输出溢出并被从头重读，三个完整文档各被完整读取了两次）。可能卡住的工具必须使用其附带的时限运行（replica 的 gate.sh、pixel-compare --timeout）——绝不能用 Agent 自行编写的 sleep N; kill 循环；长步骤应写入进度文件，由协调器轮询，而不是阻塞等待 Agent。（现场证据，2026-09：一次有记录的运行中，测试框架 watchdog 杀掉的两个转换 Agent 承接了内容最繁重的任务，并且通读了整份文档；精简任务说明后重新派发，便完成了相同页面；这次转换因盲目等待浪费了 89 分钟，又因固定时长的休眠浪费了 30 分钟。）
• 等待纪律：对话绝不能挂起到提示词缓存窗口之外。 预计运行超过约 2 分钟的任务——涉及多个页面的一轮 gate、爬取、批量推送、捕获一组页面、委派 Agent——都应在后台运行并写入进度或摘要文件；协调器绝不能在前台运行它们，也绝不能用一次长时间的 sleep 等待。任务运行期间，处理其他独立工作；若无其他工作，则最多每 4 分钟快速读取一次进度文件——绝不能固定 sleep 5 分钟或更久，也绝不能用长超时时间阻塞等待 Agent 输出。这个数字并非偏好：提示词缓存会在空闲 5 分钟后过期；而迁移任务的上下文会达到 500–900k 个 token，每次过期都会以写入价格重新写入整个前缀（是缓存读取价格的 12 倍）。现场数据：48 次会话中，前台等待不超过 4 分钟时，约有 10% 的情况会错过缓存；等待 5 分钟或更久时，错过率为 85–87%；572 次此类 Agent 端等待重新写入了 325 M 个 token，占这些会话写入缓存总量的 46%。结束当前轮次并等待完成通知有益于用户，却无益于缓存：超过 5 分钟才到达的通知同样会错过缓存（记录到 137 次），因此，对于约 45 分钟以内的等待，应优先短暂检查；仅在等待时间更长或需要用户作出决定时才结束当前轮次。（Claude Code：在 shell 调用中设置 run_in_background: true，任务退出时测试框架会发布任务通知；在 settings.json 中设置 promptCacheTtl: "1h"，可将窗口延长至一小时，但写入价格为 1.6 倍——这是由使用者设置的选项，对于任何多小时会话都值得启用。） 同一规则在不依赖测试框架时的做法是 replica 的 run-bg.mjs：start 会将工具脱离当前进程运行；wait 会在 --max 时间内返回（默认 100 秒，上限 110 秒——低于 shell 工具约 2 分钟的默认超时时间；该默认值仅适用于未声明超时时间的调用），且只输出判定行；退出代码 75 表示仍在运行，此时在下一次调用中再次执行 wait——绝不能放在 shell 循环中，也绝不能在 sleep 之后执行。主 Agent 和子 Agent 都必须遵守此规则：一个长时间运行的前台工具，或同一轮中并行调用两个长时间运行的工具，都会造成同样的阻塞步骤（记录在案：主 Agent 的一次 338 秒调用导致缓存被完整重写一次）。
• 一个 shell，一个工作目录。 测试框架的 shell 会在多次工具调用之间保留工作目录：命令中的 cd 会改变后续每个命令的工作目录，而从项目根目录编写的路径会在后续调用结束时所在的目录中失效。请从项目根目录（或使用绝对路径）编写路径，并将任何 cd 限定在子 shell 中——(cd stardust/current && …)。（现场证据，2026-09：一次 cd 进入捕获目录后，导致接下来的三次读取失败，并多花了一轮重新运行。）
• 分段编写大型文件。 先写好框架，再分次追加，每次编辑约 150 行或更少，避免单轮生成时间超过提示词缓存的存续时间（约 5 分钟）；一旦超过缓存存续时间，下一次请求就会遇到冷缓存，必须重新写入整个上下文。（现场证据，2026-09：一次有记录的运行中，有两轮生成因超时而导致上下文被完整重写——一轮是在 extract 结束时一次性写入品牌文档，另一轮是首次原型中的整份 HTML 和 CSS；此前的一次运行也以同样方式重写了 513k 和 694k 个 token。这并非由上下文压缩导致；这些会话只是在一次生成过程中超过了缓存存续时间。）
• 如果项目是 git 仓库，则在每个阶段结束时提交。 首次此类提交前，重新执行 Setup 第 6 步——首次提交会在 audit 阶段结束时进行，远早于阅读 deploy 的 SKILL.md；被跟踪的 .env 会影响后续的每次推送，并在 deploy 时导致 GH013 和历史重写。 硬性阻塞项必须停止。 源站无法访问、过期且无法恢复的 DA_TOKEN，或缺少信号的品牌界面（即使重新运行，extract 也未捕获到可用的品牌信号），都不是可以自行判断的情况——请准确说明阻塞原因，在 stardust/status.jsonl 中追加 event: "blocked"，然后停止。绝不要试图绕过硬性阻塞项。

无人值守模式下，质量门绝不放宽。 来源验证、验证循环、保真门、交付门，以及 rollout 的优化门都照常运行。无人值守模式改变的是由谁回答，而不是必须通过什么。

“公开推理”原则

Stardust 不会提供封闭的 意图 → 命令 查找表。每个自由表达的短语都要公开推理。你必须：

1. 用 stardust 的维度术语重述该短语（reference/intent-dimensions.md）。
2. 确定该短语影响哪些轴，以及方向如何。
3. 确定哪些内容尚不明确，并向用户提出最多两个澄清问题。
4. 将已明确的方向映射为一系列完善的命令，并引用 reference/impeccable-command-map.md 中每条命令的参考资料。
5. 执行前向用户展示拟定计划。
6. 执行后，在 stardust/direction.md 中记录已明确的方向、相关轴、命令和推理，并附上 stardust 来源信息块。

这一流程的示例见 reference/intent-examples.md。

单页状态与“方向变更时标记为过期”

页面具有生命周期状态（extracted | directed | prototyped | approved | migrated）。如果用户在部分页面已完成原型设计或迁移后改变方向，请将这些页面标记为过期；不要自动重新运行。 用户必须明确选择重新制作原型或重新迁移。详情见 reference/state-machine.md。

读写的工件

Stardust 状态存放在 stardust/ 下。Impeccable 的 PRODUCT.md / DESIGN.md / DESIGN.json 存放在项目根目录，代表目标状态。当前（提取所得）状态存放在 stardust/current/ 下。完整目录结构见 reference/artifact-map.md。

写入边界。 Stardust 将内容写入 stardust/、项目根目录下的 impeccable 目标文件，以及 EDS 项目（仅通过 deploy、 rollout、dynamics）。仅运行时文件——日志、测试框架页面、预渲染内容、 脚本副本、草稿——应放在 stardust/.work/<skill>/ 下；根目录的 scripts/ 和 qa/ 不属于 stardust。任何技能将内容写到其他位置都属于缺陷。

版本管理。 除 reference/stardust.gitignore 列出的内容外，stardust/ 下的所有内容都会提交：截图、四个大型目录（current/assets/、replica/gates/、migrated/assets/、rollout/qa/）、.work/、运行残留和会话状态。各目录的表格，以及不含 current/assets/ 的克隆仓库能做和不能做的操作：见 reference/artifact-map.md § Versioning。

来源信息

stardust 写入的每个工件都必须带有来源信息块，作为首行或首个键，声明：由哪个子命令写入、依据了哪些用户输入、哪些内容是合成的而非撰写的，以及读取了哪些其他工件。格式约定见 reference/artifact-map.md。

日志规则

多会话的 stardust 项目受益于一份按时间顺序记录的日志，用于记录各轮之间的提示词历史、决策和待解决问题，并与状态机及各制品的溯源信息分开。State.json 记录当前状态，溯源信息记录制品为何如此表述，但两者都无法呈现项目如何走到今天的叙事脉络。日志可以。

按照 reference/journal-format.md 中的格式维护 stardust/journal.md。 每次提示词执行产生了实质性写入（任何 direct、prototype、migrate 或重要迭代）后，都要在本轮结束前追加一条记录。

明确记录偏离。 任何由 Agent 编写、用来替代某个技能阶段的爬虫、编译器、导入器、波次驱动器或门控，都要作为明确记录的偏离写入 stardust/direction.md——说明它替代了什么、已发布的工具为何不适用、替代方案位于何处——并在日志条目中注明。未记录的并行流水线是缺陷，不是主动性：有三次已记录的迁移在提供了导入流水线的技能旁手动重建了该流水线（其中一个导入器有 60 KB），而它们的保真度数值从未与门控的数值进行过比较。

日志只能追加。如果发现先前的条目有误，应新增条目予以更正；不要编辑历史记录。这样可以保留推理过程，让审核者了解决策如何演变。

日志属于项目，面向人类阅读——它与精心维护的 PRODUCT.md 位于同一级别，而不是放在 stardust/current/ 或 stardust/canon/ 下。应将其视为 stardust 状态机之上的共享叙事层。

用户在新会话开始时调用 stardust，系统会先读取日志（以及 state.json）；最后 3–5 条记录会提供状态机无法提供的“上次进展到哪里了”这一背景信息。

验证规则

stardust 编写的每个供人检查的制品——拟议的 HTML、brand-review.html、迁移后的网站——在标记为完成前，都必须经过递归验证与修复循环。原则是：类型检查和测试套件用于验证代码正确性；只有浏览器渲染才能验证功能正确性。

对于用户将会看到的 HTML（原型、迁移后的页面、brand-review HTML）：

1. 使用 Playwright 渲染（静态文件使用 file://，或使用本地开发服务器）。
2. 在三个视口下进行捕获——桌面端 1440×900、平板端 768×1024、移动端 390×844：
   • 全页截图。
   • 浏览器控制台消息（错误和警告）。
   • 网络故障（4xx / 5xx / 请求中止、资源缺失）。
   • 未捕获的 JS 异常和未处理的 Promise 拒绝。
   • 布局合理性：无水平溢出；关键页面标志元素存在且内容非空。
   • 无障碍快速检查：替代文本、输入标签、标题顺序、文字覆盖图片时的对比度。
   • 交互冒烟测试：将鼠标悬停在可交互卡片上，触发滚动事件，打开/关闭导航，确认可通过键盘访问主要 CTA。
3. 如果发现任何问题，就修复并重新运行该循环。 递归迭代，直到 (a) 不再存在问题，或 (b) 修复需要用户输入——此时提出问题并停止。已知问题尚未解决时，不要报告任务已完成。
4. 将最终通过检查的截图保存到 stardust/validation/<artifact>/<viewport>.png，以便审核者无需重新运行就能进行比较。

各技能的具体验证要求见各自的参考文档——尤其是 extract/reference/playwright-recipe.md（规范流程）、prototype/reference/motion-validation.md（动作相关门控），以及 prototype/SKILL.md 的第 2.5–2.8 阶段（评审 / 审核 / 调整 / 动作门控级联）。

stardust 绝不会做的事

• 不会提出与 impeccable 的硬性规则相矛盾的设计意见。以 impeccable 为准。
• 不会在未先展示重设计计划的情况下执行它（免手动模式会将计划记录到 stardust/direction.md，而不是等待——§ 免手动模式）。
• 不会在用户未明确选择启用的情况下，强制重新运行已过时的页面。
• 不会抓取超出用户确认页面上限的现有网站（明确的 --pages 列表本身就是已确认的范围——列表中的页面绝不会被丢弃；当列表超出 --max 时，爬虫会发出警告，而不是截断列表）。
• 不会从 migrate 输出特定平台的内容。migrate 输出平台无关的静态 HTML；EDS 转换和交付由上文路由到的 stardust deploy（单页）和 rollout（整个网站）技能子技能负责。

参考资料

• reference/intent-dimensions.md — 重设计所涉及的维度。
• reference/intent-reasoning.md — 处理自由表达短语的流程。
• reference/intent-examples.md — 推理风格的演示示例（8-12）。
• reference/impeccable-command-map.md — 何时使用 24 个 impeccable 命令中的每一个。
• reference/state-machine.md — 页面生命周期、过时规则、状态报告格式。
• reference/artifact-map.md — stardust 读取或写入的每个文件，包括所有权、来源形式以及（§ 版本控制）哪些内容会被跟踪。
• reference/stardust.gitignore — 由 Setup 步骤 6 安装为 stardust/.gitignore。
• reference/divergence-toolkit.md — 避免平庸的工具包。默认操作列表、确定性种子、字体组、角色命名规则。由 direct（编写目标令牌时）和 prototype（生成变体时）使用。
• reference/token-contract.md — 每个原型和迁移后的页面都必须公开的 :root CSS 自定义属性契约。这是 stardust 与任何下游使用方之间的令牌接口。
• reference/data-attributes.md — 应用于每个原型和迁移后页面中各分区的结构性 data-* 词汇。这是 stardust 子命令与下游工具之间的结构通用语言。
• reference/journal-format.md — stardust/journal.md 条目格式。只追加的时间顺序日志；覆盖状态机之上的共享叙事层。
• reference/run-status.md — 每个技能都会追加到 stardust/status.jsonl 的阶段转换契约。适用于任何执行框架的确定性进度界面。
• reference/learnings.md — 每次运行的经验记录契约（stardust/learnings.md）。rollout 的报告阶段会写入该文件；插件维护者会将待处理条目整理到技能差异中。

电影感功能参考资料（跨领域）

由 prototype/ 负责，因为电影感功能仅适用于原型渲染；但 direct（选择风格时）、uplift（选择 C 的风格时）和 migrate（复制动态资源时）也会引用：

• ../prototype/reference/motion-registers.md — 五种忠于品牌的动态风格（arrival、kinetic-display、live-systems、editorial、kinetic-grid），以及将 PRODUCT.md 品牌个性特征映射到风格的选择启发式。
• ../prototype/reference/motion-stack.md — 技术选择：Lenis + CSS 关键帧 + rAF + IntersectionObserver。为何不选 GSAP。打包策略。
• ../prototype/reference/motion-attributes.md — 运行时使用的 data-* 词汇（[data-anim]、[data-tile-anim]、[data-countup]、[data-flip]、[data-fill]、[data-split]、[data-parallax]）。
• ../prototype/reference/motion-runtime.md — 为每个电影感原型提供支持的规范内联运行时脚本。
• ../prototype/reference/motion-validation.md § 第 6 轮 — 电影感模式验证关卡（Lenis 启动、减少动态效果回退、滚动劫持、三个位置的截图、风格匹配、动态 C 悬崖检测器）。

Uplift 功能参考资料

由 uplift/ 所有。在委派 $stardust uplift <URL> 时由主路由引用：

• ../uplift/SKILL.md — 一次性售前协调器：提取 → 张力／特征识别 → 3 种方向方案 → 原型 × 3 → 开启 + 总结。
• ../uplift/reference/what-if-candidates.md — 目录中包含 8 个已完成的「捕捉特征放大」候选方案，供 B 和 C 在第 2b 阶段选择；另包含 § 扩展规则，允许加入基于证据的 derived 候选方案。