mcpField
R
replica

replica

github.com/adobe开发316246 次安装今天更新
代码仓库

关于 replica

replica 是 Stardust 技能,用于将网站迁移到 AEM Edge Delivery,或重建前端平台,同时保留原有设计与内容。它依据采集的内容和源站样式,以语义化 HTML 和 CSS 重建页面,并通过测量门槛与线上站点核验保真度。

主要功能

  1. 01逐字保留采集的内容
  2. 02沿用设计而不重新设计
  3. 03以语义化 HTML 和 CSS 重建
  4. 04提取源站 CSS 数值
  5. 05按断点测量保真度
  6. 06用不一致登记表限定变更

适用场景

  1. 01保留原设计迁移网站平台
  2. 02将单个页面作为试点复刻
  3. 03交付前对照线上页面检查原型类型

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/adobe/skills --skill replica

安装后在 Claude Code 中输入/replica确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

reference/
first-page-first.md
handoff-contract.md
preserve-direction.md
reading-discipline.md
recreation-procedure.md
source-fidelity-gate.md
scripts/
anchor.mjs
breakpoint-lint.mjs
cap-probe.mjs
chrome-parity.mjs
crop-compare.mjs
css-rules.mjs
diff-report.mjs
foundation-freeze.mjs
gate-all.mjs
gate-evidence.mjs
gate.sh
html-slice.mjs
json-query.mjs
measure.mjs
motion-compare.mjs
motion-observe.mjs
pixel-compare.mjs
row-profile.mjs
run-bg.mjs
run-capped.mjs
section.mjs
sibling-variance.mjs
stitch-shot.mjs
scripts/test/
breakpoint-lint.test.mjs

详细介绍

stardust:replica — 同设计迁移

页面相同、内容相同、设计相同——平台焕新。replica 将网站迁移到 AEM Edge Delivery(或仅重新搭建前端),并让现有设计保持近乎像素级一致:目标规范就是捕获到的当前状态,唯一允许的差异是明确列出的不一致登记表条目,并且每种页面原型在发布前都必须通过针对线上网站的实测源站保真度门槛。

两项特性让它与重新设计流程截然不同:

  1. 不做创意决策。 方向步骤是对捕获到的规范进行机械式提升——绝不调用 stardust direct 技能。replica 运行中的每项判断都是测量策略判断,而非审美判断。
  2. 重建,而非复制。 页面原型根据捕获的内容,以及从源网站自身 CSS 中提取的值,编写为简洁的语义化 HTML/CSS——绝不复制 DOM,也绝不移植页面级样式表。保真度由测量工具证明,而非通过构建方式宣称。

已完成端到端验证(某排版风格零售首页,2026-07-03):3 轮测量迭代中,像素差异从 8.31% → 2.93% → 1.31%;高度差 Δ 为 0,内容差异“结果:无”(198/198 个节点)。每项修正都依据测量工具得出,而非凭肉眼判断。

输入项

  • <URL> — 必填。要迁移的网站。
  • --breakpoints <list> — 可选。门槛检测宽度,默认为 1440,360;每个宽度都会单独通过门槛检测(移动端并非免费——见门槛文档 § 按断点检测)。
  • --target-breakpoints <list> — 可选。移动端优先的 min-width 阶梯值(例如 600,900,1200),交付的网站会在这些宽度切换布局,而非采用源网站的断点。未提供时保留源网站断点,并跳过所有目标阶梯值。保存于 DESIGN.json 的 extensions.breakpoints.target。
  • --register <file> — 可选。用户提供的不一致项,用于初始化登记表(见阶段 2)。若未提供此项且未执行审计,登记表将为空——即纯复刻。
  • --first-page <url|home> — 可选;默认不操作时为 home。全站运行时优先交付的页面(reference/first-page-first.md)。

设置

  1. 运行主技能的设置步骤(../stardust/SKILL.md § Setup):加载上下文、读取状态。流程防护。 如果 state.json.flow 为 redesign,则拒绝执行:打印不可混用提示行和切换命令 ($stardust replica --switch-flow,该命令会将 redesign 流程中已原型化和已迁移的页面标记为过期——主技能 § Two migration flows)。如果缺少 flow,则写入 flow: "replica"、 flowSource: "user-phrase"(../stardust/reference/state-machine.md § Flow keys):调用 replica 即表示作出此选择。
  2. 验证能否从项目根目录导入 Playwright(提取需要它; 因此门控脚本也需要它)。
  3. 先从项目根目录检查门控依赖—— node -e "import('pixelmatch').then(()=>process.exit(0))"(以及 playwright、 pngjs、cheerio)——仅在失败时将它们安装为开发依赖, 绝不要使用 --no-save:npm i -D playwright pixelmatch pngjs cheerio --legacy-peer-deps(../extract/SKILL.md § Setup)。如果现有测试框架已经能解析这些依赖,就不会改动交付代码仓库;否则开发依赖会写入技能将要提交的仓库。 所有检查都从项目根目录运行:ESM 会从脚本自身所在位置解析 playwright。
  4. 将脚本复制到项目中,并从项目内运行,不要从插件运行:将此技能的整个 scripts/ 目录复制到 stardust/scripts/replica/,将主技能的 ../stardust/scripts/ (ledger.mjs、state.mjs)复制到 stardust/scripts/stardust/,将迁移技能的 ../migrate/scripts/(migrate.mjs)复制到 stardust/scripts/migrate/, 还要将整个 ../diff/scripts/ 目录复制到 stardust/scripts/diff/(diff 脚本会导入 diff-profiles.mjs,所有线上目标加固逻辑——包括 stitch-shot 的——都位于其 live-session.mjs 中;stitch-shot 会从与 stardust/scripts/replica/ 同级的 stardust/scripts/diff/ 解析它,因此这两个目录必须保持同级)。绝不要复制到项目根目录下的 scripts/——那是 EDS 样板代码的目录(主技能 § Artifacts,写入边界)。

阅读与检查规范——上下文就是预算 (在设置时阅读一次 reference/reading-discipline.md)。每个步骤输出的每个字节,都会在之后的每次模型调用中重新读取(记录:一次 77 分钟的会话中,工具输出达 750k 个字符)。规则,每条一行: 参考文档按章节读取(section.mjs <doc> --list,然后每次调用读取一个标题下的一个章节);通过 css-rules.mjs 查看捕获的 CSS,通过 json-query.mjs 查看捕获的 JSON(为命令提供数据的值使用 --tsv/--path,不要读取表格);通过 html-slice.mjs 查看捕获的 HTML;通过 run-bg.mjs wait 和 log --grep 查看仪器输出,绝不要用 cat;通过 measure.mjs 比较线上页面与原型的布局框,绝不要自行编写探测脚本;每个事实只截取一张图片,绝不要拼接整页,也不要同时查看线上页面/构建产物/差异图(三者并列);唯一例外是提取缩略图 thumb.mjs;先查看 ../stardust/reference/scripts-index.md 了解脚本标志,再运行 --help,绝不要查看源码。将之后还需要的内容写入 stardust/ 下的文件,并通过查询读取回来。

流程

共五个阶段。阶段 1 和 5 原样委派给现有技能;阶段 2–4 由 replica 负责。运行完整站点时,先打开第一页: reference/first-page-first.md。

阶段 1 — 提取(委托给 $stardust extract --prep --dynamics)

不做任何修改地调用 $stardust extract <URL> --prep。必须使用 Prep 模式 — Replica 会使用完整的迁移清单,而不是发现上限:

  • stardust/current/pages/<slug>.json — 每个页面的结构与内容 (原样保留原文,是原型中每个字符串的来源)。
  • stardust/current/assets/screenshots/ — 每个页面的截图(重现时的真实依据, 以及关卡自带的拼接截图)。
  • stardust/current/assets/ — 字体(通过网络拦截获取的 woff2)、徽标、媒体。
  • stardust/current/PRODUCT.md、DESIGN.md、DESIGN.json — 当前状态的描述性资料(阶段 2 会原样提升这些资料)。
  • state.json.pages[].type — 页面类型(每种类型都会成为一种原型)。
  • DESIGN.json.extensions.modules[] — 模块候选项(会成为区块)。

收到 extract 的摘要后,先显示流程提示语 — “流程:Replica — 保留设计。若要更改,请立即说 switch to redesign。” — 确保用户在此流程中首先看到其所依据的选择。switch to redesign 会运行 $stardust prepare-migration --switch-flow;extract 的结果会复用,不会执行其他操作。

受限/单页入口(单页或试点运行)。 --prep 是全站范围的约定,但它并非唯一入口。当用户要求“只复刻此页面”——或希望在决定全面迁移前先试点一种原型时,应改为调用 $stardust extract <URL> --single --dynamics(若页面列表较短,则使用 --pages <slug,...> --dynamics)。这是正式支持的入口,并非临时变通:重现阶段需要每个页面的页面 JSON(原样保留内容)、每页截图(真实依据)和已捕获的字体;受限提取会提供这些内容。无论采用哪种方式,源 CSS 收集和各断点的计算样式都来自阶段 3 的 CSS 提取。受限运行跳过的是仅限 Prep 的清单(页面分类、模块检测);只有阶段 5 需要扩展到同类页面时才需要这些内容。而描述性综合则会采用阶段 2 的受限提升分支:reference/preserve-direction.md § 1a。

Extract 的故障处理方式照常适用(Bot 管理下的有头浏览器回退、同意处理、禁止综合)。如果 extract 必须回退到有头 Chrome,则关卡截图也可能需要相同的处理方式。

阶段 2 — 保持方向(机械执行——绝不调用 stardust direct 技能)

完整约定:reference/preserve-direction.md。摘要:

  1. 将 stardust/current/PRODUCT.md、DESIGN.md、DESIGN.json 原样提升到项目根目录,作为目标规范。不进行差异轮次、不重新定向,也不使用 Mode A/B——当前状态 就是目标。有界入口(--single/--pages):这些文件不存在——改为执行有界提升分支(reference/preserve-direction.md § 1a):根据捕获的页面 JSON 和 Phase-3 CSS 提取结果(调色板、字体比例、容器、按钮——正是提取操作本来就会生成的值),合成最精简的描述性规范,来源标记为 bounded-single。绝不可混用两个分支:如果 current/PRODUCT.md 存在,则原样提升(Track A 的 first page first 情况除外)。

  2. 编写 stardust/direction.md,记录保持模式:提升了哪些内容、来自何处、来源标记(原样 --prep 提升或 bounded-single 合成),以及寄存器指针。这能告知下游技能“方向步骤已完成”。

  3. 在 stardust/replica/inconsistency-register.md 中建立不一致寄存器——唯一允许的设计差异,也就是“几乎像素级完美”中的“几乎”。来源:stardust audit 技能的设计发现(只有用户希望获取改进候选项时才运行 audit)和/或用户提供的条目(--register)。每个条目都必须包含捕获的证据、最小改动和状态。空寄存器 = 纯复刻——这是有效且常见的结果,不是失败。

  4. 目标断点(仅使用 --target-breakpoints 时),必须在任何 CSS 存在之前确定(reference/preserve-direction.md § 4):保存列表,按意图在 stardust/replica/breakpoint-map.md 中将每个源断点映射到一个步进,并加入唯一一条寄存器条目。Phase 3 和 C0 应用该映射;它们绝不负责确定映射。

  5. 动态界面(迁移门槛——stardust dynamics 技能的 Phase 1–3)。 Phase 1 必须已运行 extract --dynamics。对原型运行检测器,起草分流方案(已知 EDS 主机时使用 --target-origin),整理 stardust/dynamic-features.md + -plan.md。每一行都必须确定处置方式;静态复刻仍照常继续。这一步会识别模态框、播放器、表单、搜索、标签和主机绑定的 API,而像素门禁会将它们判定为正确。约定: skills/dynamics/reference/triage.md。

任何未列入寄存器的内容都不在变更范围内。若复刻选择会“改进”未登记的内容,那就是保真度缺陷。

第 3 阶段 — 重建(每种页面类型一个原型)

完整方法:reference/recreation-procedure.md。针对清单中的每种页面类型(原型类型:规范中 archetypes.json 的该类型 rep_url),以三个来源为依据,按以下顺序编写 stardust/prototypes/<slug>-proposed.html(以及每页对应的 CSS),使用干净、语义化的 HTML/CSS:

(a) 捕获的页面 JSON 内容 — 原样照录。 从 current/pages/<slug>.json 获取标题、正文、CTA 及其 href、替代文本和元数据。迁移内容保留规则(../migrate/reference/content-preservation.md)从第一行起就适用:不得改写,不得编造。 (b) 从源网站自身的 CSS 中提取的精确值。 获取在线样式表;提取字体级别、按钮规格、区块内边距、圆角、阴影和首屏高度。容器模型需测量,不能直接提取——使用 DESIGN.json extensions.breakpoints(运行 extract 的 cap-probe.mjs;如果条目有边界,先运行 cap-probe.mjs <live-url> --write-design stardust/current/DESIGN.json)。保真度数值来自原网站的 CSS,而非目测——这能将 3–4 轮猜测和截图缩减为一轮。对在线页面与已提供服务的原型进行逐框比较,使用已发布的 measure.mjs(node stardust/scripts/replica/measure.mjs <live-url> --against <prototype-url> --selectors "<css>,…" — 每个选择器、每种宽度对应一个矩形框及计算值,每个差异占一行),绝不使用自行编写的探测脚本。 (c) 捕获的截图是所有 CSS 未明确指定内容的真实依据(构图、图像裁剪、绘制效果)。

设定目标步长后,每条 @media 规则和 JS 宽度阈值(matchMedia、innerWidth)都必须从第一行起按目标步长编写,遵循 breakpoint-map.md,绝不能事后修补(事后修补需要重新进行完整验证);原型必须在验证前通过 breakpoint-lint.mjs,退出码为 0。

每种原型类型都必须有自己的独立原型——逐步累积,不得跳过。 新原型类型绝不能跳过原型制作、直接进行平台编写:在实际应用中,制作了原型的页面类型始终保持最高质量水平(3.5%/5.6%),而直接编写的页面在 8–16% 停滞。每个新原型都会导入早期原型中已通过验证的共享层(共享规范 CSS + 每种原型类型对应的文件),并且只针对其全新模块迭代——完整约定见:reference/recreation-procedure.md § 累积式原型类型原型。

这是重建,不是重新设计——不要委托给 impeccable craft。 Impeccable 的重新设计验证(评审、反模板、差异化)不适用;源保真度验证(第 4 阶段)会完全取代它们。“经过精心改进”的区块就是不合格的区块。

字体: 在可用时使用相同的公共来源(对于开源或可自托管字体,使用 extract 拦截到的 woff2)。对于许可的商业字体包:绝不能在新域名上重新托管——选择度量匹配的替代字体,将品牌字体系列名称放在字体堆栈的首位,以便稍后替换为已获许可的字体时优先生效,并向用户说明这一替代。(先例:早期机场网站迁移的改进说明,§3.7。)

CSS 移植仅作为逐区块的后备方案——仅适用于无法通过计算样式还原的绘制级效果、由 JS 水合的电商组件、视频或动画首屏。移植该区块所需的最少源规则,并限定作用域;绝不能移植整页规则。判定标准见 reference/recreation-procedure.md § 后备方案。

第 4 阶段 — 源保真度验证(核心 — 按断点测量)

完整约定:reference/source-fidelity-gate.md。针对每种原型类型、每个断点运行(默认 1440 和 360),以在线 URL 为源,对比已提供服务的原型:

PROTO="http://localhost:8791/<slug>-proposed.html"   # python3 -m http.server from the prototypes dir
# ONE server, ONE port — probe with curl first (gate doc § Per-breakpoint procedure): no answer →
# start yours; answers but not your file → foreign server, never kill it, take a per-project port
curl -sI localhost:8791/<slug>-proposed.html | head -1   # 200 = it serves YOUR dir: reuse it
LIVE="https://<site>/<path>"

# One command per round — gate.sh, through run-bg. The FIRST round of a breakpoint and the
# CONFIRMATION round after the last fix run `--full` (pixel probe — stitched captures, NEVER
# fullPage:true — plus content-diff, visual-diff and chrome-parity under deadlines, one verdict
# line each, reports in the gate dir); rounds in between are pixel rounds. Never hand-write a
# wrapper around the instruments (a recorded one lost the deadlines; a round took 15 minutes).
# content-diff inside --full compares --main AND the header/footer roots by default — no chrome flag.
node stardust/scripts/replica/run-bg.mjs start --name <slug>-1440-iter1 -- \
  stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 1440 iter1 --full --main "<content-root>"
node stardust/scripts/replica/run-bg.mjs start --name <slug>-360-iter1 -- \
  stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 360 iter1 --full --main "<content-root>"
# A consent manager the built-in candidates miss: add --consent "<accept selector>" to every gate.sh
# round — it reaches both stitched captures and the probes alike (gate doc § Hardening rule 6).
node stardust/scripts/replica/run-bg.mjs wait      # verdict lines: pixel %, height delta, hot bands, structural 🔴, flags, chrome deltas

# Iteration inner loop (gate doc § Band breakdown): anchor probe + pixel round
G=stardust/replica/gates/<slug>-1440
node stardust/scripts/replica/anchor.mjs "$LIVE"  --width 1440 --cache $G/anchor-live.json   # live side: probed once, reused
node stardust/scripts/replica/anchor.mjs "$PROTO" --width 1440   # build-side runs are free
# Chrome: computed-style parity BEFORE any pixel round on header/footer/strips
node stardust/scripts/replica/chrome-parity.mjs "$LIVE" "$PROTO" --width 1440 --live-cache $G/chrome-live.json   # exit 0 = quiet, then crop-compare
# --headed in any instrument = the window-free real-Chrome stealth tier (#125); STARDUST_HEADED_WINDOW=1 is the only way to a window.
# gate.sh: live.png cached, every step under a deadline (exit 124 = re-run, not FAIL). Rounds run in
# the BACKGROUND: start every round at once (the slots pace the Chromiums — no `sleep N;` staggering),
# then `wait` prints verdict lines only; exit 75 = still going → `wait` again as your NEXT step, never
# in a shell loop, never after a `sleep` (gate doc § Iteration discipline). A propagation wait is a
# bounded inline poll (`curl -sf` ≤ 5 s apart, capped), never a fixed sleep.
node stardust/scripts/replica/run-bg.mjs start --name <slug>-1440-iter2 -- stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 1440 iter2
node stardust/scripts/replica/run-bg.mjs start --name <slug>-360-iter2  -- stardust/scripts/replica/gate.sh <slug> "$LIVE" "$PROTO" 360  iter2
node stardust/scripts/replica/run-bg.mjs wait      # returns within 100 s; full output: run-bg.mjs log <job> --grep <re>
# Content-cap row — once per archetype after the 1440 pass, at DESIGN.json's derived probeWidth (never a pinned 1920)
node stardust/scripts/replica/cap-probe.mjs "$LIVE" --against "$PROTO" --design DESIGN.json --slug <slug> --main "<content-root>"

gate.sh --help 会列出标志和退出码(124 = 截止时间,需重新运行,不代表判定结果;仅当四项全部运行并通过时,退出码才为 0)。 通过标准(每个断点须满足以下全部四项,另加内容上限行):

  • content-diff:主根节点和 Chrome 根节点上 0 个 🔴,且 0 个内容丢失 🟡(gate doc § Pass bar 第 1 项);
  • visual-diff:无标记,或标记均有合理解释;
  • 像素差异:整页 ≤ 10%,且每个 500px 区间的差异都必须有解释 (区间细分是导航工具——从上到下修复第一个高差异区间; 其下所有区间都受到偏移污染);
  • 高度差 |Δ| ≤ 8px(pixel-compare 自带的警告阈值);
  • 内容上限行:cap-probe.mjs … --against 输出 cap-probe: PASS (gate doc § Pass bar 第 6 项——每个有效上限都须按类型控制在 ±20 px 以内, 只有原型存在的上限不计;✗ 会指出尺寸规则,无需反复调整像素);
  • clip-probe:构建侧 Clipped: 0(--full 轮次会运行该项;文本或控件被截断或隐藏 都会导致轮次失败,如同像素差异超限——#125);声明的重复单元族(stardust/replica/units.json,gate doc 第 7 项) 须控制在 4 px 以内;
  • 以及,不计入通过标准和内容上限的水平溢出断言: 构建侧每个断点的 document.documentElement.scrollWidth 与视口宽度相差不超过 4 px (整数舍入;GATE_OVERFLOW_TOLERANCE)——无论像素差异数值如何, 超出此范围都会导致 gate.sh 判定轮次失败;capture failed (exit 1) 轮次 (gate.sh 重试一次后)会重新排队,绝不计入结果。

设置目标值时(#131): gate 宽度会逐步加入每个目标步长;在偏移区间内,像素差异失败属于 层级偏移(记入登记表条目,不再反复调整)或缺陷(仍会导致失败)——gate doc § Target breakpoints。

每个原型都是一行(#125)。 架构类型通过后,每个宽度运行一次, 将原型表写入文件——通过 run-bg.mjs 执行 node stardust/scripts/replica/gate-all.mjs --stage prototype --proto-base "$PROTO_BASE" --width 1440(然后是 360); 它会重用各架构类型缓存的 live.png。gate-evidence.mjs 会将其作为记录依据: 没有对应行的原型未通过 gate 检查。

迭代纪律:每个断点最多迭代 3 次。 每次迭代的修复都必须依据检测工具,而非肉眼判断。迭代 3 次后, 将残留问题记入台账并继续——记录在案的 2% 残差胜过没有记录的第四轮迭代。任何单一步骤等待时间都不得超过上下文缓存的存续时间: 较长的检测工具必须通过 run-bg.mjs 运行(先执行 start,再以不超过 100 秒的时间片 执行 wait);主 Agent 和子 Agent 都一样——在前台运行较长的检测工具,或在同一轮中并行调用两个工具,都属于同一个受阻步骤(参考文档 § Iteration discipline)。

加固措施(每项都是有记录的错误测量陷阱——完整列表见参考文档): 每次捕获都使用真实 Chrome UA 和标准请求 标头(已集成到共享的 diff/scripts/live-session.mjs);遇到质询/拦截中间页或 2xx 拒绝页面时,明确失败(exit 3),绝不进行测量——使用 --headed 升级处理;如果网站仍然拦截,则需使用 crawl.mjs 级别的捕获方式; 对真实目标使用 domcontentloaded,绝不使用 networkidle; 两侧都采用对称的 --main 作用域(--main body 永远无效); 通过 --dismiss 关闭两类覆盖层(同意提示和定时营销 弹窗);捕获时冻结动画;任何关闭点击后都将指针移至空闲位置; 固定/粘性 Chrome 必须以固定方式复现,并保留其 滚动状态变化(reference/recreation-procedure.md § Fixed and sticky chrome); 为 JOIN/SPLIT 的假阳性红色结果采用粒度对齐策略(#87);对 CDN-403 图片和水合占位符采用捕获状态 策略(按捕获结果复现 + 记录)。有两类缺陷只有 gate 能捕获——DOM/样式捕获会漏掉:内部 span 上实际渲染字体的分叉(宽度探测),以及计算样式中不可见的覆盖层遮罩(通过逐行亮度拟合找出)。 实时目标加固功能以差异脚本的标志形式提供(--ua、 --wait-until、--dismiss、--headed、--locale、视觉差异的 --main), 由 live-session.mjs 提供支持——复制脚本并传入标志;包含手动修改的项目副本 属于缺陷 (reference/source-fidelity-gate.md § 脚本适配)。

静态门禁通过后,交互一致性是每种原型类型都必须输出的门禁结果 ——不是后续步骤 (reference/recreation-procedure.md § 交互一致性)。动效必须通过观察确认, 绝不能根据静态类或 CSS 推断:针对每种原型类型的实时 URL 运行 stardust/scripts/replica/motion-observe.mjs → stardust/replica/motion/<slug>.json,只实现实际触发的行为(未触发的类 = 未实现),然后用相同顺序的 --click/--hover 操作观察已提供服务的原型 (→ stardust/replica/motion/<slug>-build.json),并使用 stardust/scripts/replica/motion-compare.mjs 比较两个文件。它是报告工具,不是门禁 (页眉的行为由页眉契约规定):缺失或额外的行须在类行中确认(采样器无法检测类切换 和伪元素机制),并在原型中解决,或记录为未触发。 在 progress.json 中记录 motion: {observed, implemented, dead[]},并重新运行像素比较——数值必须恢复到门禁值。 必须实现组件,而不是找理由省略——在 EDS 中,若组件没有作者编写的内容,则作为 widgets/<path>/<name> 实现,绝不能使用空行的区块。 由计时器驱动的媒体也算作已触发(autoplay/loop 视频、自动切换的幻灯片——观察 JSON 中的 media 区块):捕获冻结状态须记录为 captureState[].restoreAtDelivery 并交付,绝不能作为规范发布。 扇出简报须原样包含证据规则和检测工具调用方式。

所有断点均通过后,按标准原型审批流程提交原型类型及其门禁指标供审批 (免手动模式会根据 ../stardust/reference/state-machine.md 记录 approvedBy: "hands-off")。 记录工作状态时,每项操作都须用一条命令完成,绝不手动编写 JSON 行,也不以内联的 node -e 修改 state.json:node stardust/scripts/stardust/state.mjs advance <slug> --to approved --by hands-off --prototype stardust/prototypes/<slug>-proposed.html 以及 node stardust/scripts/stardust/ledger.mjs replica source-fidelity-gate end --detail "<per-breakpoint numbers>"。恢复运行时,先执行 ledger.mjs tail 和 state.mjs summary --slugs,而不是 cat。 此技能的每个阶段——包括提取和保留方向——都必须以 node stardust/scripts/stardust/ledger.mjs replica <phase> start 作为 第一条命令,在运行该阶段的任何脚本之前执行(某次有记录的免手动运行在 109 分钟的工作后才 将阶段的 start 与 end 写在一起,监督者因此将其视为空闲;在 --strict 模式下, ledger.mjs 拒绝没有未关闭 start 的 end),并以 end 行及 stardust/journal.md 中标题为 ## <Phase name> — <what happened> (<date>) 的章节结束—— 该章节是阶段 end 的组成部分,缺失时 ledger.mjs … end 会发出警告 (某次有记录的运行在第二次会话才开始写日志;另一次运行则为整个过程只写了一个章节)。

阶段 5 — 交接(委派——迁移 → 部署 → 推出,保持不变)
  • 先阅读契约卡:reference/handoff-contract.md — 本阶段所需的精简迁移/部署/发布规则、确切的发布台账阶段字符串(A-inventory … I-dashboard)、每个部署和发布脚本各一行用法说明,以及记账命令。切勿完整阅读同级的 SKILL.md 文件(曾有一次记录在首次输出 Phase 5 内容之前,先读了其中 260k 个字符,随后又重读了超出部分);只有在某个步骤需要深入了解时,才用 section.mjs 获取引用的章节。
  • 超出原型范围的页面,通过同级层级的 stardust migrate skill 处理(../migrate/reference/fidelity-tiers.md)——且只有在其原型已上线并通过已发布源站的门禁之后(契约 § 3,C 行,单元 C-archetype;#126):结构克隆作为编码器输入 + 内容保真度 + 交付 lint + 媒体对账;同级页面唯一计入的数字是 PUT + 预览后其门禁行的结果(没有本地像素门槛)。同级页面沿用原型已验证的编码器——绝不重新编写。模板恒定性需要测量,不能靠假设:克隆之前,每个模板运行一次 stardust/scripts/replica/sibling-variance.mjs <archetype> <siblings…> --probe <block>=<sel> …,并将每项差异都作为同级页面内容中的区块 VARIANT 类纳入预算(同一文件,§ 同级页面方差探测)。内容保真度会在导入时按页面测量(同一文件,§ 内容计数验收),以便在修复成本低时发现导入器错误。
  • 交付:按页面通过 stardust deploy skill 进行。对于固定构图的部分,解码层级优先选择模板插槽式(deploy #95):副本区块是与线上原始页面匹配的固定构图。重复组(卡片、列表)仍采用重构方式。区块遵守 Experience Workspace 可编辑性契约(deploy § 8,EW1–EW10:采用节点插槽,绝不采用值插槽),并通过 block-roundtrip --ew。
  • 全站发布:通过 stardust rollout skill 进行,保持不变——其区块去重机制正是实现“整个站点使用相同区块”的方式。
  • 目标断点: C0 在目标断点上构建基础结构和复用区块,并将 breakpoint-lint.mjs 接入 npm run lint(reference/handoff-contract.md),因此每次 deploy 和 rollout lint 都会检查这一要求。
  • C-deliver 按单元运行(reference/handoff-contract.md § 3,C 行 + 扇出纪律):C0 — 一个基础结构子 Agent 负责编写并部署基础结构;主 Agent 在已发布源站上检查外壳,包括页眉契约(chrome-compare 退出码为 0,../diff/SKILL.md § 页眉契约),然后运行 foundation-freeze.mjs freeze 并提交;C-archetype — 每个模板各自处理,已通过门禁的原型先完成部署,并在预览 URL 上通过完整门禁行(最多修复 3 轮,之后做是否重新制作原型的决策),再渲染其同级页面;C1…Cn — 每个模板集群由一个子 Agent 执行完整流程,包括 PUT → 预览 → 已发布源站门禁,并使用自己的批次台账(deploy-batch.mjs --ledger …,支持锁安全),报告一行结论;主 Agent 只负责协调和记录;C-final — 执行 check,应用排队中的 foundation-requests.md 条目一次,然后运行 C-deliver end。每个单元都记录在 stardust/rollout/progress.json 并提交——这是安全的恢复点,本身绝不是结束会话的理由;一轮执行期间不得编辑已冻结的文件。
  • 最终门禁针对已发布源站运行——而非测试框架(reference/source-fidelity-gate.md § 已发布源站门禁):先部署(PUT → 预览),再通过 run-bg.mjs 运行 gate.sh <slug> "$LIVE" "<preview-url>" <width> pub1 --full --marker "<brand or domain string>",放在常规的 gates/<slug>-<width>/ 目录下,并使用 pub<N> 标签(新目录会强制重新捕获线上页面)。本地测试框架上不运行任何像素相关检查——它只供 qa-gate/block-roundtrip 使用。
  • 交付门禁是全页面运行,包含四项标准——不只是像素数值(reference/source-fidelity-gate.md § 全页面已发布源站门禁,#125):通过 run-bg.mjs 运行 node stardust/scripts/replica/gate-all.mjs [--only <slug,…>] [--skip-existing] [--eds-host <host>]。DELIVERED = 像素差异 % ≤ 10 且 |Δh| ≤ 5 %,并且无被裁切的文本/控件(clip-probe)以及无 MISSING/HIDDEN 链接/标题(content-presence);曾有记录显示某页面通过了像素门槛,但其所有卡片都被裁切。证据和附属文件位于 stardust/replica/gates/all-<width>/;结合 Phase 4 的 prototypes-<width>/ 表格,两者构成 gate-evidence.mjs 读取的一对文件(没有对应行的页面即未通过门禁)。每个集群子 Agent 在扇出期间对自己的页面运行 --only;C-final 的名册运行是已记录的单元 gate-all(--skip-existing,复用已有捕获结果),随后运行 update-coverage.mjs --gate(handoff contract § 3,C 行)。 状态: replica 在 stardust/replica/ 下写入自己的状态——不一致项登记表、progress.json(一张映射表:types.<archetype>——页面类型、已用迭代次数、各断点的 gate 结果、残余项、动效清单——与 gate-evidence.mjs 的 siblings / migrate 并列;按条目扩展,绝不替换)、motion/<slug>.json,以及 gates/<slug>-<width>/ 证据。 交付 gate(#125)会添加 gates/all-<width>/——每个已部署页面一个目录(origin.png、eds.png、diff.png、pixel.json、content.json、clip.json、units.json)、summary.{json,md}、用于 --only 运行的 runs/,以及文档中列出的 sidecar(masks.json、overrides.json、clip-allow.json、presence.json、units.json)。 Phase 5 会在 stardust/rollout/ 下添加三个文件:progress.json(C-deliver 单元台账——每个单元的状态、gate 和判定结果)、foundation-freeze.json(冻结基础的 sha256 清单)和 foundation-requests.md(排队等待的基础变更请求,在 C-final 时一次性应用)。 流水线状态(extracted → prototyped → approved → migrated)仍保存在核心 state.json 中,并遵循标准状态机——replica 绝不重新定义它。

replica 绝不做的事

  • 不重新设计。 不添加新调色板、字体、间距、构图或动效。目标规范就是捕获到的当前状态。
  • 不重写内容。 捕获到的字符串原样保留;占位符和 hydration 状态按捕获内容复现,而不是“修复”。
  • 不凭空改进。 任何未在不一致项登记表中记录的更改都是缺陷,无论它看起来多么妥当。
  • 不复制 DOM。 绝不粘贴实时 DOM,也不将页面级 CSS 移植为原型(那是规避限制的后门,不属于此技能)。重点在于干净地重新创作——如果逐字节保真却没有重新实现的价值,就失去了迁移的意义。

输出

stardust/
├── state.json                          ← core state machine (unchanged contract)
├── direction.md                        ← preserve-mode record (Phase 2)
├── current/                            ← from extract --prep
├── prototypes/<slug>-proposed.html     ← gated archetypes (one per page type)
├── replica/
│   ├── inconsistency-register.md       ← the ONLY permitted design deltas
│   ├── breakpoint-map.md               ← source → target breakpoint map (only with --target-breakpoints)
│   ├── progress.json                   ← per-page-type ledger: iterations, gate results, residuals, motion inventory
│   ├── motion/<slug>.json              ← motion-observe evidence
│   └── gates/<slug>-<width>/           ← live.png, proto.png, diff.png, probe outputs per iteration
├── migrated/                           ← from migrate (Phase 5)
└── rollout/                            ← from rollout (Phase 5); coverage/, plan.json … per its SKILL.md
    ├── progress.json                   ← C-deliver unit ledger: status, gates, verdict per unit
    ├── foundation-freeze.json          ← sha256 manifest of the frozen foundation (C0 → C-final)
    └── foundation-requests.md          ← queued foundation change requests, applied once at C-final

PRODUCT.md / DESIGN.md / DESIGN.json    ← promoted verbatim from current/ (Phase 2)

参考资料

  • reference/preserve-direction.md — 机械式晋升契约 + 不一致项登记条目架构。
  • reference/recreation-procedure.md — CSS 提取方法(按 gate 断点)、字体策略、scrim / luminance 恢复、span-face 分支、捕获状态策略、换行交界处边距、固定 / 粘性 chrome、粒度对等、角色对等(按每个字符串镜像实时外观)、交互对等(动效以观察为准,绝不推断;Swiper 锁定)、CSS 移植的回退标准。
  • reference/source-fidelity-gate.md — 完整的 gate 契约:命令、阈值、各断点的操作流程、加固规则、分段细分结果阅读指南(+ section-anchor 内循环)、迭代规范、已发布来源 gate(EDS 流水线差异)、残余项日志格式。
  • ../diff/SKILL.md — replica 复用的两个探测器(--profile generic);如何阅读 content-diff 输出;#87 JOIN/SPLIT 的限制。
  • ../extract/SKILL.md § Prep mode — Phase 1 提供的内容。
  • reference/reading-discipline.md — 完整的阅读和检查规则:哪个辅助工具读取什么、图片规则,以及相应依据。
  • reference/handoff-contract.md — Phase 5 契约卡:同级层级步骤、部署可编辑性 / 解码 / DA 协议、rollout 阶段 A–I 及其台账阶段字符串、每个 deploy 和 rollout 脚本各一行用法说明、记账命令。
  • ../stardust/scripts/ledger.mjs、../stardust/scripts/state.mjs — 台账和状态写入器(项目副本位于 stardust/scripts/stardust/);每个脚本的 --help。
  • ../migrate/reference/fidelity-tiers.md — Phase 5 移交给的 archetype / sibling 模型。
  • ../deploy/SKILL.md § 解码层级(#95)— 模板插槽偏置。
  • ../stardust/reference/scripts-index.md — 每个已交付脚本各占一行(功能和关键标志);使用任何 --help 之前先阅读此文。

评论

支持 Markdown