uplift

stardust:uplift

一个入口，一个 URL，三种达到预售演示品质的重设计方案。

uplift 将 extract → direct → prototype × 3 流程整合为一条有明确主张的命令：它会根据已采集的品牌表面自行确定所有可变项，而不是让用户选择。输出与完整流程相同（state.json、brand-review.html、三个提案文件、动效验证），用户只是不必再协调这些步骤。

明确的默认设置

• 提取单页——默认选择主页（品牌所有者的首个表面），除非通过 --page <slug> 覆盖。
• 忠于品牌的 Mode A——固定调色板和字体。不得臆造颜色，也不得使用采集表面之外的字体。
• 三个变体，角色契约固定——A 是获批方案，B 是激励设计团队的方案，C 是富有远见的电影感提案。
• 自动选择电影感风格——根据采集到的 PRODUCT.md Brand Personality，为 C 选择动效风格，依据 ../prototype/reference/motion-registers.md § Selection heuristic。
• “What if...”候选项以证据为依据——B 和 C 各自选择一个已采集但未充分利用的特质，可从 reference/what-if-candidates.md 中的八个示例候选项中选择，也可依据其 § Extension rule 派生候选项。每个变体使用不同的特质。
• 运行验证级联——触发 prototype/SKILL.md Phases 2.5–2.8 中的所有关卡，包括针对变体 C 的电影感 Pass 6。

输入

• <URL>——必填。要重设计的页面。如果 URL 没有路径，则默认使用主页（https://example.com/ → 主页）。
• --page <slug>——可选。如果 URL 指向其他页面，或用户想要不同的表面，则覆盖 slug。
• --cinematic-register <name>——可选。覆盖为变体 C 自动选择的风格。可选值为 arrival、kinetic-display、live-systems、editorial、kinetic-grid。在 C 的溯源信息中记录为 registerSource: "user-override"。
• --two-variants——可选。仅渲染 A 和 C（跳过 B）。当品牌表面内容较少，强行区分三种方案会导致中间方案表现薄弱时，此选项很有用（见下方的停止条件）。
• --re-extract——可选。即使同一 URL 的先前提取结果距今不足 7 天，也强制重新抓取（见 § Setup、reuse-if-fresh）。

没有其他标志。其他所有内容都根据采集到的品牌表面推导，或由底层技能的契约决定。

设置

1. 运行主技能的设置步骤 （../stardust/SKILL.md § Setup）：检查依赖项是否完备、加载上下文、读取状态。
2. 确认 Playwright 可用（没有它，extract 将无法运行——显示与 extract 相同的安装提示）。
3. 如果存在 stardust/state.json，则读取。**新鲜数据复用：**如果同一 URL 的先前提取结果距今不足 7 天，则跳过 Phase 1，使用现有采集结果进行渲染，并显示一行提示（“正在复用 的提取结果——传入 --re-extract 以重新抓取”）。无论提取结果距今多久，--re-extract 都会强制重新抓取；提取结果距今 ≥ 7 天时，无需询问即可重新提取。

流程

六个阶段，另加一个基于参考资料的中间阶段。Phases 1、4、5 委托给现有技能；Phases 2、2.5、3、6 由 uplift 负责。

阶段 1 — 提取（委派给 stardust extract 技能）

调用 $stardust extract <URL> --single（单页模式）。 extract 负责：

• 使用标准等待方案，通过 Playwright 实时渲染。
• stardust/current/_brand-extraction.json（调色板 + 字体 + 图案 + 语气 + 系统组件 + 摄影）。
• stardust/current/pages/home.json（完整的逐页采集结果）。
• 应用了张力检测器的 stardust/current/brand-review.html —— 这是阶段 2 的关键输入。
• stardust/current/PRODUCT.md 和 DESIGN.md（描述当前状态，而非目标状态）。

uplift 不会爬取超过一个页面。单个首页的品牌呈现足以支持三个变体；多页面提取则由 stardust extract 技能（不带 --single）负责。

阶段 2 — 识别张力与特征（由 uplift 负责）

阅读 stardust/current/brand-review.html § 已发现的张力以及 _brand-extraction.json。生成两个产物：

2a — stardust/uplift-improvements.md

至少列出 3 项在采集的网站中观察到的具体弱点——证据支持多少就列多少，不设固定数量。要求与现有售前工作流中的关键约定相同：没有具体细节，“做得更好”就缺乏依据。类别标签（有证据支持时，可在不同条目中重复使用）：

• [dated-pattern] — 设计领域已经淘汰的模式（请具体说明：“居中主视觉搭配图库照片 + 主蓝色双 CTA，呈现出约 2019 年的 SaaS 模板风格”）
• [ia-clutter] — 信息架构杂乱 / 层级不清晰 / CTA 效果弱 / 内容板块冗余
• [contrast-or-density] — 对比度问题、无障碍缺陷、信息密度问题
• [cliché] — 品牌可以摆脱、同时仍能保持自身辨识度的惯例
• [missed-opportunity] — 采集到的页面未能发挥自身优势（“采集到的摄影作品很出色，但布局将其裁剪成了缩略图大小”）

具体性要求——适用于每个条目。 每个条目都要引用采集结果中的某项测量数据、张力 ID 或截图观察结果，指出有问题的模式，并提出一项具体修复方案。不符合要求的条目应直接删除，不要凑数。

审计结果的使用。 如果该来源已有 stardust/audit/<domain-slug>/audit.json（由 stardust audit 技能写入），则将其中的设计发现用作候选改进项，而不是从头重新推导——在条目的证据中引用发现 ID，并将审计文件添加到 readArtifacts。

如果无法列出至少 3 项具体弱点，则拒绝继续（参见 § 停止条件）。

格式（与 stardust 其余部分使用的来源记录格式一致）：

---
_provenance:
  writtenBy: stardust:uplift
  writtenAt: <ISO-8601>
  againstInput: <URL>
  readArtifacts:
    - stardust/current/_brand-extraction.json
    - stardust/current/pages/<slug>.json
    - stardust/current/brand-review.html
---

# Improvements — <URL>

1. **[<category-tag>]** <one-line headline> — <measurement /
   tension ID / screenshot observation> · <pattern at fault> ·
   fix: <one concrete fix>.
2. **[<category-tag>]** … (≥ 3 items; tags may repeat)

每项弱点前的方括号标签均为上述列表中的一个类别。标题是单句摘要；当变体 A 的形状说明应用修复方案时，Agent 会重述这句话。

2b — stardust/uplift-questions.md

从已采集的品牌特征中推导出 6 到 8 个“如果我们更进一步……”候选方向。每个候选方向都要引用使其具体可行的已采集证据。候选方向取自 reference/what-if-candidates.md 中的目录，该目录包含八个详尽示例，是最低标准，而非上限：

1. 加强展示型字体
2. 重新突出摄影
3. 提升实时数据的地位
4. 延展标志性手势
5. 转换语调风格
6. 重新调整色彩层级权重
7. 重新构想受众导流方式
8. 替换主题元素词汇

目录之外的衍生候选方向，只要具备与目录条目相同的证据结构，即可纳入：≥ 2 条已采集的引用 + 明确的淘汰测试 + 所服务的变体角色（参见 reference/what-if-candidates.md § Extension rule）。在候选列表中记录每个候选方向的来源——catalog | derived。

对于生成的每个候选方向，Agent 都要提供：一句“如果……会怎样？”式表述；使该候选方向具体可行的已采集证据；其最适合服务的变体角色（B 的构图押注或 C 的电影感押注）；以及该候选方向是否因不适合此品牌而淘汰（例如：“重新突出摄影已淘汰——已采集的摄影素材是普通图库照片；加强它只会暴露其弱点”）。

淘汰步骤能避免 Agent 反复为每个品牌选择同一个候选方向。

第 2.5 阶段 — 参考资料佐证（由 uplift 负责）

当可进行参考资料调研时（何时启动、3–5 项参考资料的预算、证据结构和来源记录方式均见 skills/stardust/reference/reference-research.md），应在第 3 阶段确定方向之前，使用真实世界的参考资料佐证第 2 阶段的主张：

(a) 为 uplift-improvements.md 中每条 [dated-pattern] 主张提供佐证，引用一个具名的当代反例——一条真实网站 / 屏幕的引用，展示该模式所在领域的发展方向。 (b) 使用一个具名的真实世界构图参照，支撑变体 B 的构图押注——其构图与该押注相似的真实屏幕。 (c) 根据该领域实际使用动态效果的方式，验证 C 选择的风格——该风格是否符合这类品牌当前可观察到的实践？

按照 reference-research.md 的来源记录约定，记录各项参考资料（在每项佐证所服务的制品上记录 _provenance.referencesUsed[]）。如果无法进行参考资料调研，则跳过并在该来源记录中用一句话说明，然后继续——此阶段会平稳降级。

此阶段绝不能取代对已采集证据的严谨要求：**参考资料佐证的是变化方向，已采集证据佐证的是特征。**无论该变化方向的参考资料多么充分，没有已采集引用的候选方向都不可纳入。

第 3 阶段 — 选定三个变体方向（由 uplift 负责）

默认：三个变体（A + B + C）。启用 --two-variants 时，跳过 § 3c（为 B 选择候选方向），并且 § 3d 编写的 direction.md 仅声明 A + C。随后，第 4 阶段只会在项目根目录写入 DESIGN-A 和 DESIGN-C 文件，第 5 阶段也会相应地进行渲染。所有下游约定（变体差异化、对 C 的动态效果验证、第 6 阶段的摘要）均在缩减后的变体集合上运行，无需修改。

3a — 为变体 C 选择电影感风格

阅读 PRODUCT.md 的 Brand Personality（来自 stardust/current/PRODUCT.md），并应用 ../prototype/reference/motion-registers.md § Selection heuristic 中的启发式规则。记录所选风格及一句话理由。

3b — 选择 C 的“假如”候选项

候选项必须是所选寄存器能通过运动自然增强的那一个。reference/what-if-candidates.md 中每个候选项的 C 的自然寄存器字段，是寄存器→候选项映射的唯一事实来源——请在该文件中读取映射（根据 § Extension 规则准入的衍生候选项必须声明相同字段）。本文件不重复该表格。

当 C 的自然候选项全部被排除时的回退方案： 重新选择第二选择的寄存器——即 ../prototype/reference/motion-registers.md § Selection heuristic 中的次佳匹配项——并选取它对应的自然候选项。如果第二选择寄存器的自然候选项也全部被排除，则根据停止条件 (d) 转入 --two-variants：舍弃 B，让 C 选择剩余未被排除的候选项中最强的一个。

3c — 选择 B 的“假如”候选项

从 uplift-questions.md 中剩余（未被排除、且非 C）的候选项中选择。优先考虑：

1. 能解决 brand-review.html § Tensions 中提出的矛盾的候选项。
2. 视觉手法侧重构图 / IA / 语气而非运动的候选项（这样 B 和 C 的区别体现在维度上，而不只是强度上）。

3d — 编写 stardust/direction.md

编写已确定的方向，并声明三个变体：

## Variant A — Faithful + improvements

Role: risk-averse green-light. "Yes, that's us, with the obvious
fixes."
Composition: same as captured.
Motion: static (no cinematic layer).
Improvements applied: <list from uplift-improvements.md>.

## Variant B — What if we amplified <captured trait>?

Role: design-team motivator. The brand's underused capability
foregrounded.
What if: "<one-line "what if…" framing>"
Captured trait amplified: <trait from uplift-questions.md>
Evidence: <captured citation>
Composition: <specific layout strategy that amplifies the trait>
Motion: static (no cinematic layer).

## Variant C — What if motion was part of the identity?

Role: visionary pitch. The brand's third dimension — kinetic.
What if: "<one-line "what if…" framing tied to the register>"
Cinematic register: <register> (auto-picked from PRODUCT.md
Brand Personality)
Captured trait amplified: <trait — the one register naturally
amplifies>
Evidence: <captured citation>
Composition: identical IA to A; the bet is motion, not layout.
Motion: cinematic, register <register>.

Phase 4 — Direct（委托给 stardust direct 技能）

使用已确定的方向调用 stardust direct 技能。将三变体声明作为输入短语传入（“uplift presales redesign — three variants per stardust/direction.md”）。Direct 负责：

• 以 Mode A 编写 PRODUCT.md、DESIGN.md、DESIGN.json（根目录）。
• 各变体的 DESIGN-A / DESIGN-B / DESIGN-C 文件。
• DESIGN-C.json 中的运动寄存器区块（从 direction.md 声明中读取）。
• IA 优先级保留审计。
• 密度下限检查。
• 反工具箱审计。
• 变体差异化契约。

uplift 不会重复执行这些检查；它依赖 direct 现有的验证器，在变体违反品牌忠实度契约时拒绝。

第 5 阶段 — 原型 × 3（委派给 stardust prototype 技能）

先渲染 A，再渲染 B 和 C：

1. 渲染 A — 调用 $stardust prototype <slug>，并限定为变体 A。A 会确立并冻结规范（令牌、界面框架、模块渲染），供 B 和 C 继承；先渲染 A 可避免顺序竞争。
2. 依次渲染 B 和 C（默认：串行；仅当运行环境提供子 Agent 原语时才并行，例如 Claude Code 的 Agent 工具或 Copilot CLI 的 task 工具）。B 和 C 使用相同的 slug进行原型渲染；根据 ../stardust/reference/state-machine.md § Concurrency，相同 slug 的并发运行会对 state.json 采用最后写入者获胜，因此在原位置并行渲染并不安全。只有通过隔离的工作区副本才允许并行：每个子 Agent 都获得一份项目副本（Git worktree 或目录副本），根目录中只包含它自己的 DESIGN-<id>.json（将其他文件暂存到别处），这样 prototype 的文件存在检测就只会渲染该变体。子 Agent 返回其 <slug>-<id>-shape.md、<slug>-<id>-proposed.html（C 还包括 -cinematic.html）以及来源信息；父 Agent 复制回这些产物，并对两个变体执行一次 state.json 更新。
3. 每个原型完成后立即打开（使用第 6 阶段第 1 步中的 open 机制），不要等到三个全部完成后再打开。

Prototype 会根据第 4 阶段 direct 写入的各变体 DESIGN-A、DESIGN-B、DESIGN-C 文件来检测变体集合，并根据变体收敛检测器约定（../prototype/SKILL.md § Phase 2.5 / Discipline 10）编写 <slug>-A-shape.md / -B-shape.md / -C-shape.md，并生成 <slug>-A-proposed.html / <slug>-B-proposed.html / <slug>-C-proposed.html。

电影级动态效果根据各变体的 DESIGN 文件触发，而不是由 CLI 标志控制。**绝不要在 uplift 中向 prototype 传递 --cinematic。**由于第 4 阶段只将 extensions.motion.register 写入了 DESIGN-C.json（A 和 B 都省略了它），prototype 的第 2.4 阶段（动态效果应用）只会对变体 C 触发。变体 C 会同时生成 <slug>-C-proposed.html（静态参考）和 <slug>-C-cinematic.html（应用 register 后的界面）。变体 A 和 B 会以静态方式渲染，不会加载动态效果运行时。

Prototype 负责：

• 根据 prototype 第 1 阶段编写页面结构概要。
• 按变体委派 $impeccable craft 进行渲染。
• 对声明了 extensions.motion.register 的 DESIGN-<id>.json 所对应的变体应用第 2.4 阶段的动态效果。
• 对每个变体执行第 2.5–2.8 阶段的质量关卡（评审、审计、调整、动态效果）。
• 根据 ../prototype/reference/motion-validation.md，执行变体 C 的电影级模式关卡（第 6 遍）。
• 根据 Discipline 10 执行变体收敛检测（每对变体至少有 2 处结构性变化）。

多变体渲染由项目根目录中存在多个 DESIGN-<id>.json 文件来驱动，而不是由 CLI 选择器驱动——prototype 不接受 --variant <id> 输入。这正是第 2 步中的并行方式要求使用隔离工作区副本的原因：每份副本中都只能包含一个固定的 DESIGN-<id>.json 文件，因为文件是否存在是 prototype 唯一的变体选择器。无论采用哪种方式，上述先渲染 A 的顺序都能确保 B 和 C 的渲染保持规范一致。

第 6 阶段 — 打开并总结（由 uplift 负责）

三个原型都在 state.json 中标记为 prototyped 后：

1. 确认三个原型都已在浏览器中打开 — 每个变体完成时都已打开（第 5 阶段第 3 步）；如果有未打开的，则使用 open shell 命令打开（不要使用 playwright-cli open），以便通过预览 service worker 提供 VFS 路径：

   open stardust/prototypes/<slug>-A-proposed.html
   open stardust/prototypes/<slug>-B-proposed.html
   open stardust/prototypes/<slug>-C-cinematic.html
   

   playwright-cli open 会绕过预览 service worker，并导致 VFS 路径出现 FILE NOT FOUND 错误。打开本地原型文件时，始终使用 open <vfs-path>。

2. 在聊天中打印三方案摘要：

   uplift complete — three variants for <URL>
   
   A · Tomorrow's version of the site you have today.
      Improvements applied: <count>.
      File: stardust/prototypes/<slug>-A-proposed.html
      Pitch: "yes, that's us, fixed."
   
   B · What if we amplified <captured trait>?
      Trait: <name>.
      Composition bet: <one-line summary>.
      File: stardust/prototypes/<slug>-B-proposed.html
      Pitch: "the brand's underused capability, foregrounded."
   
   C · What if motion was part of the identity?
      Cinematic register: <register>.
      Motion bet: <one-line summary>.
      File: stardust/prototypes/<slug>-C-cinematic.html
      Pitch: "the brand's third dimension."
   
   Differentiation: A vs B ≥ 2 changes (✓), A vs C ≥ 2 changes (✓),
   B vs C ≥ 2 changes (✓).
   
   Validation: all three pass critique + audit + adapt; C additionally
   passes motion validation Pass 6.
   
   Next: iterate any variant via chat ("make B's hero quieter") or
   approve via the standard prototype approval flow (records the
   approval in state.json).
   

摘要是用户与这三个变体唯一的直接接触点。保持简短——相关内容都保存在磁盘上，可直接打开。

三种变体的角色契约（硬性要求）

变体	定位	构成	动效	相关方
A	“明日版本。”	相同的信息架构 + 已应用的改进	静态	风险规避型的拍板买家
B	“如果我们放大 <captured trait> 呢？”	在信息架构 / 构图 / 语气中突出一种已捕捉但未充分利用的特征	静态	希望探索品牌的设计团队
C	“如果动效成为品牌标识的一部分呢？”	与 A 相同的信息架构	完全电影化，风格取自品牌表面	有远见的买家 + 设计负责人

这项契约不可协商。“C 必须电影化”这条规则能让 uplift 可靠地交付第三种主张，使其有理有据地不同于 A 和 B（而非陷入 C 悬崖失效模式——“把 B 中的一切都做得更大”）。

如果捕捉到的品牌表面无法支撑三种有差异的变体（例如，调色板只有一种颜色、捕捉到的页面只有两个版块、品牌风格无法与任何动效风格清晰对应），则通过 --two-variants 将变体缩减为两种（A + C），而不要交付三种薄弱的变体。

硬性约束

继承自底层技能——uplift 不会重述这些约束， 但依赖它们得到强制执行：

• 模式 A 锁定——采用捕捉到的品牌表面的调色板 + 排版。 由 direct/SKILL.md § Mode A 强制执行。
• 信息架构优先级保留——配置器保持在首屏上方，危机处理入口保持在第一视口，等等。由 direct/SKILL.md § IA-priority preservation audit 强制执行。
• 密度下限——版块数 > 5 的品牌风格页面将 sectionPadding.desktop 限制在 ≤ 64px。由 direct/SKILL.md § Hard floor enforcement 强制执行。
• 变体差异化——每个变体与其他变体相比至少有 ≥ 2 项改动。由 direct/SKILL.md § Variant differentiation contract 强制执行。
• 在语义对应位置重复使用捕捉到的图片——主视觉图仍作为主视觉图，故事图片仍作为故事图片。由 prototype/reference/proposed-file-shell.md § Content sourcing hierarchy 强制执行。
• 不得编造内容——统计数据、地址、引言、具名人物均渲染为 [data-placeholder]，不得编造。由 prototype/SKILL.md Phase 2 § Content sourcing scan 强制执行。
• 每个变体的页面 head 中都包含网站 favicon——当 stardust/current/assets/favicon.<ext> 存在时，每个变体页面都会将其内联为 data: URI <link rel="icon">。由 prototype/reference/proposed-file-shell.md § Hard requirements #8 强制执行。
• 拒绝变体 C 的 C 悬崖模式——变体 C 应押注于动效，而不是“把 B 中的一切都做得更多”。由 prototype/reference/motion-validation.md § Pass 6f motion C-cliff detector 强制执行。
• 变体 C 的减少动态效果回退方案——在 prefers-reduced-motion: reduce 下，所有动效元素都会被禁用。 由 prototype/reference/motion-validation.md § Pass 6b 强制执行。

如果任何一道关卡拒绝通过，uplift 会原样显示底层技能给出的拒绝原因——用户看到的是具体违规项，而不是笼统的“uplift 失败”消息。

停止条件

仅在以下情况下停止并询问：

(a) 提取失败 — 网站无法访问、结构无法解析， 或在尝试带界面的 Chrome 回退方案后仍被 机器人管理系统拦截。 (b) 品牌表征不足 — 聚类后调色板中少于 2 种 不同颜色；或者捕获的页面少于 3 个版块；或者捕获的 PRODUCT.md 品牌个性无法对应五种动态类型中的任何一种。 如实说明：“捕获到的品牌表征过于单薄，无法制作 三个有明显差异的变体——改为制作一个强有力的变体？” (c) 改进列表为空 — Phase 2a 无法指出 3 个具体 弱点。没有具体内容，变体 A 就没有设计简报， “提升”也无从谈起。如实说明。 (d) 两个候选方向同样薄弱 — 如果 B 的“假如……”候选 和 C 的电影感候选会强化同一个捕获到的特征， 这些变体就无法形成差异。改用 --two-variants（仅 A + C）。 (e) 硬性规则冲突 — 捕获到的调色板只有一种颜色、 捕获到的字体没有展示字体样式，或捕获到的网站没有系统组件。 不进行臆造就无法满足品牌忠实度约束。请说明情况并询问。

该技能不会在正常流程中因等待确认而停止。原始预售提示词中的 “继续。运行所有阶段，不要停止”要求保持不变。

输出

stardust/
├── state.json                              ← extracted + 3× prototyped
├── direction.md                            ← resolved direction + 3 variant declarations
├── uplift-improvements.md                  ← load-bearing weakness list (≥ 3 items)
├── uplift-questions.md                     ← 6–8 "what if…" candidate list with disqualifications
├── current/                                ← from extract
│   ├── PRODUCT.md
│   ├── DESIGN.md
│   ├── DESIGN.json
│   ├── brand-review.html
│   ├── _brand-extraction.json
│   ├── _crawl-log.json
│   ├── pages/<slug>.json
│   └── assets/
└── prototypes/
    ├── <slug>-A-shape.md
    ├── <slug>-A-proposed.html              ← faithful + improvements
    ├── <slug>-B-shape.md
    ├── <slug>-B-proposed.html              ← "what if amplifying <trait>"
    ├── <slug>-C-shape.md
    ├── <slug>-C-proposed.html              ← static fallback for C
    ├── <slug>-C-cinematic.html             ← cinematic variant C
    ├── lenis.min.js                        ← copied from skill assets
    └── lenis.min.css

PRODUCT.md                                  ← shared (Mode A)
DESIGN.md / DESIGN.json                     ← shared
DESIGN-A.md / DESIGN-A.json
DESIGN-B.md / DESIGN-B.json
DESIGN-C.md / DESIGN-C.json                 ← carries motion.register

范围

• 每次运行处理一个页面。多页面改版使用标准的 extract → direct → prototype 链。
• 提供三个供审阅的呈现版本，而非可部署的软件包。品牌 负责人选定一个变体后，通过聊天驱动的 impeccable 命令迭代，并通过标准的 prototype 审批流程批准。 迁移使用 stardust migrate 技能。

参考资料

• reference/what-if-candidates.md — 八个经过实际处理的 捕获特征强化候选方案，供 B 和 C 选择， 以及用于依据证据推导候选方案的 § 扩展规则。
• skills/stardust/reference/reference-research.md — 搜集真实设计 参考资料的流程（Phase 2.5）：何时启动、3–5 个参考资料的预算、 证据形式和来源记录。
• ../prototype/reference/motion-registers.md — 用于 Phase 3a 的动态类型 目录和选择启发式。
• ../prototype/reference/motion-validation.md § Pass 6 — 适用于变体 C 的电影模式验证关卡。
• ../prototype/SKILL.md — 多变体渲染和动态效果由 direct 在 Phase 4 写入的各变体 DESIGN-<id>.json 文件驱动， 而非由 CLI 选择器或标志驱动（uplift 从不传入 --cinematic）。
• ../direct/SKILL.md § Phase 2.6 — 多变体分支；uplift 会原样传递三个变体的声明。
• ../stardust/reference/data-attributes.md — prototype 为所有三个变体 应用的结构版块属性。
• ../prototype/reference/proposed-file-shell.md — 内容 来源层级和占位符约定。