dynamics

stardust:dynamics — 迁移的动态表面

静态迁移将页面视为内容和布局。此技能将页面视为行为： 源站通过 JavaScript、服务或数据源呈现的所有内容，以及目标主机无法以相同方式提供的所有内容。三次真实迁移都发现了同一问题：对按区块执行、经像素验证的流水线来说，动态表面不可见，而且这种不可见会让每道关卡都认证其结果正确。模态框被呈现为链接，视频胶囊按钮变成没有目标的 CTA，搜索框指向 404，表单虽然呈现出来却无法提交。此技能会让这部分表面显现出来，并在导入前要求为每一行做出决定，然后在交付后验证行为。它不会阻止静态路径；每个页面仍必须能作为静态页面正常工作。

何时运行 — 仅限迁移流程，在其中默认启用，在其他流程中绝不运行

入口点	此处运行的内容
prepare-migration Phase 4.5 · replica Phase 2	Phases 1–3（检测原型、分类、分诊）——导入前关卡
migrate Phase 1	安全网：没有清单时，立即运行 Phases 1–3（手动运行 extract → direct → prototype → migrate 从未经过关卡）
deploy	将清单作为简报输入读取（回退行、#modal 标记、端点配置；绝不展平 client-only / 带模态框的区块）
rollout B2 · D2	B2 根据新证据验证清单；D2 = 对 self 集合和一批负责人运行 Phase 4
qa dynamics 检查 · rollout 报告	重放 parity.json 的 Phase 5
独立运行 $stardust dynamics <origin>	对已在未使用此技能的情况下完成迁移的网站运行所有阶段

uplift、audit 和单独的 extract 绝不会触发此流程：动态功能是迁移相关事项（目前针对 EDS，之后会支持其他平台），而非重新设计事项。

Phase 1 — 检测

node skills/dynamics/scripts/dynamics-detect.mjs --from-state stardust/state.json --out stardust/current [--reach stardust/current] （或使用 --urls，每个原型提供一个 URL，并包含主页）。原型使用深度检测，覆盖范围来自爬取时 extract --dynamics 生成的逐页信号。输出 stardust/current/_dynamics.json + dynamic-features.generated.md。仅包含证据。参见 reference/classes-and-signals.md。对于发现的每个搜索表单，在 SOURCE 上运行一个探测词并记录显示的内容——可见结果数量、排名靠前的标题（≤ 3 个）、一个已知匹配项——作为该功能 search-query 检查（Phase 5）的 expectCount / expectTitles / expectIncludes（规范的 knowledge/search-probes.json 已包含这些内容）；如果没有这些信息，只能检查重建后的搜索功能是否存在。

Phase 2 — 分类

每条发现都要归入 L S F M V T A R X I18N CR D 中的一个类别；已知供应商通过 scripts/vendors.json 映射到相应角色；未知第三方主机则保留为可见的“inspect”。当目标主机已存在时，dynamics-plan.mjs --target-origin <host> 会探测所有记录的一方 API 路径，并将失效路径标记为受主机限制——这正是像素关卡会报告为“区块更短”的信号。

阶段 3 — 分诊（关卡输出）

node skills/dynamics/scripts/dynamics-plan.mjs [--target-origin …] [--migrated stardust/migrated] [--knowledge] [--chrome] --out stardust/dynamics 为每项发现草拟一行，并预填四个维度——类别 · 处置方式 · 可复现性 · 状态——以及模式、阶段、负责人决策和 target，即交付形式（没有剩余作者行时为 widget——见 reference/triage.md § Target）；--knowledge 会添加规格中整理后的功能，以及对未决问题的决策；--chrome 会为每种页眉契约系列添加一行（购物车和账户由负责人决定后端，UI 负责交付）。将其整理到 stardust/dynamic-features.md（§ Listings contract + § Features + § Decision batch + § Register）和 stardust/dynamic-features-plan.md 中。reference/triage.md 是契约。决定此阶段形态的规则：

• 在安排任何事项之前，先与迁移后的输出核对。
• 只有可复现性为 self 的内容可以自主交付；其他所有内容都属于一个决策批次。
• 绝不为客户端渲染的空白采集内容编造文案；绝不自动接入 regulated-pii 表单；搜索框意味着需要结果页；明确排除必须由负责人明确说明——绝不能仅凭不介入的假设就写入。
• **关卡：**没有处置方式的行会导致 prepare-migration 4.5 / replica Phase 2 / rollout B2 失败。静态迁移仍会继续。
• **仅按需处理 Martech：**负责人要求保留标签或同意机制时，添加 --martech（reference/martech.md）；默认不进行任何搭建。

阶段 4 — 实施（按计划阶段）

参考 reference/patterns.md（目录 + 契约 + 嵌入式示例机制）、reference/listings.md、reference/off-origin-data.md、reference/forms.md、reference/locale-trees.md。在三个网站上验证有效的原则：先静态，再接入 · 先定义创作契约，再编写代码 · 不等负责人输入，不等待（先交付过渡层级，并明确指出待决事项）· 优先使用现有库（为其提供数据，不要分叉）· 明确排除。每个阶段结束时，都要在已发布源站的 1440 和 360 宽度下验证流程，添加一条奇偶校验记录和一条日志记录，并提交代码。工具：snapshot-api.mjs、snapshot-forms.mjs、sync-sheets.mjs。查询索引来自代码分支中的 helix-query.yaml——提交、推送、发布上线并轮询——绝不通过配置服务写入；仅当分支不可写时，才使用以表格为后端的过渡索引（见 reference/listings.md § Getting an index at all）。搜索遵循 reference/patterns.md § search-index-backed。列表和数据驱动区域以文档为先：文档将条目文本作为作者行承载，区块仅读取索引或快照中的非文本字段并补足内容（见 reference/listings.md § Block contract；原因：deploy/reference/ai-readability.md）。

阶段 5 — 验证：动态奇偶校验

使用已封闭集合中的可重放检查编写 stardust/dynamics/parity.json（reference/parity-report.md）；node skills/dynamics/scripts/dynamics-check.mjs --origin <published origin> [--auth-header … | --token-env SITE_TOKEN] 会生成 stardust/qa/dynamics-report.md。检查流程，而非检查是否存在。 search-query 检查会将结果数量和排名靠前的标题与源站记录的值进行比较——数量不匹配即判定失败。站点密钥只能通过限定源站范围的路由过滤器传递；每条断言旁都会记录第三方请求状态。

无需人工介入的处理方案

gate	处理方案
负责人决策（后端、新主机上的标签、数据源归属、区域设置范围）	发布临时层级，在计划和一致性报告中按姓名记录决策，继续推进——绝不能标为 decided-out，该状态需要负责人的声明或明确的阻塞项
未知的第三方主机	根据 XHR 正文分类；否则标记为 T“检查”——绝不能悄然丢弃
空白的客户端渲染捕获内容	内容严重缺失 → 批量人工捕获；绝不能迁移空白内容
涉及受监管个人身份信息的表单	重建 UI，阻止提交，必须做出决策
从测试网络无法访问交接目标	添加 environment-limit 行并注明出口区域；这不是缺陷
内容源无法接收提交内容	本地捕获，并明确显示“未连接后端”消息；注明决策者姓名

硬性阻塞项（event: "blocked"）

探测网络无法访问源站；需要端点间接访问时，目标配置不可写；会捕获受监管数据的临时层级（应记录为 decided-out）。

产物

stardust/current/_dynamics.json、dynamic-features.generated.md · stardust/dynamics/dynamic-features.generated-plan.{md,json} · stardust/dynamic-features.md、stardust/dynamic-features-plan.md（人工整理）· helix-query.yaml（列表 + 搜索，在代码分支中提交）· data/<feature>/*.json + _provenance.json（快照，代码总线）· scripts/site-config.js（面向负责人的集成，已禁用）· stardust/martech-contract.json、martech-handoff.md、scripts/martech.js（选择启用）· stardust/dynamics/parity.json · stardust/qa/dynamics-report.{md,json} · 登记行 · 日志 + 状态行。

参考资料

• reference/classes-and-signals.md — 类别轴、检测流程、供应商表格策略、源站限定探测。
• reference/triage.md — 四个轴、规则、清单文件格式。
• reference/patterns.md — 目录：每种模式的契约 + 验证、机制示例。
• reference/listings.md — 元数据契约 + 查询索引机制（原为 rollout 的 dynamic-listings）。
• reference/off-origin-data.md — 如何从站外为现有库提供数据；由表格提供的数据；chrome URL 空间。
• reference/forms.md — 控件而非表单标签；按内容源接收数据；受监管数据。
• reference/parity-report.md — 架构、检查类型、规则。
• reference/locale-trees.md — 将 I18N 视为树。
• reference/martech.md — 选择启用的 martech 契约、负责人启用方式、运行时、验证。
• scripts/ — dynamics-detect.mjs、dynamics-plan.mjs、dynamics-check.mjs、snapshot-api.mjs、snapshot-forms.mjs、sync-sheets.mjs、vendors.json、lib.mjs、martech.mjs。