rollout

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

stardust:rollout — whole site → AEM (Edge Delivery Services)

stardust:rollout —— 全站点部署至AEM（Edge Delivery Services）

deploy

converts one page to AEM.

rollout

delivers the whole site: it inventories the agnostic output of

migrate

, then drives

deploy

across every page, tracking delivery coverage so you always know what's done and what's left.

rollout

is delivery-only — it does not redesign. The page-by-page redesign (

extract → direct → prototype → migrate

) and

deploy

itself are unchanged;

rollout

is the across-pages layer on top. Design rationale, coverage model, and phasing are in

notes/rollout/PLAN.md

. The flow runs A→I below.

deploy

负责将单个页面转换至AEM，而

rollout

则负责交付整个站点：它会盘点

migrate

生成的通用输出内容，然后针对每个页面调用

deploy

，同时跟踪交付覆盖范围，让你随时了解已完成和待完成的任务。

rollout

仅负责交付——不涉及重新设计。逐页重新设计的流程（

extract → direct → prototype → migrate

）以及

deploy

本身均保持不变；

rollout

是构建在这些流程之上的跨页面统筹层。设计原理、覆盖模型和阶段划分详见

notes/rollout/PLAN.md

，整体流程分为以下A→I阶段。

When to use

使用场景

Full mode — the user has a fully migrated site at

stardust/migrated/

(per-page HTML +

_meta.json

from

stardust migrate

), an EDS/AEM project + DA destination (the same target

deploy

needs), and wants the entire site delivered, incrementally and resumably.

Archetypes-only mode — the user has one migrated archetype per template plus a full page inventory in

stardust/state.json

(with

type

per page), and wants to ship all block code immediately without waiting for every page to be migrated. Sibling pages register as

content-pending

and get their content later via a separate track.

If there is no

stardust/migrated/

tree at all, recommend

stardust migrate

on at least the archetype pages first. For a single page, use

stardust deploy

directly.

完整模式——用户已在

stardust/migrated/

目录下拥有完整的迁移站点（由

stardust migrate

生成的逐页HTML文件 +

_meta.json

），同时拥有EDS/AEM项目及DA目标地址（与

deploy

所需的目标地址一致），希望完整交付整个站点，支持增量式交付和断点续传。

仅原型模式——用户针对每个模板拥有一个已迁移的原型页面，且

stardust/state.json

中包含完整的页面清单（每个页面都标注了

type

），希望立即部署所有区块代码，无需等待每个页面完成迁移。同模板的其他页面会被标记为

content-pending

，后续通过单独的内容交付流程补充内容。

如果完全没有

stardust/migrated/

目录，建议先对至少原型页面执行

stardust migrate

。若仅需部署单个页面，请直接使用

stardust deploy

。

Setup

前置准备

Run the master skill's setup (
```
skills/stardust/SKILL.md
```
§ Setup).
Verify
```
stardust/migrated/
```
exists with at least one
```
*.html
```
page (full mode: all pages; archetypes-only: the archetypes + a
```
state.json
```
with
```
type
```
populated). If not, recommend
```
stardust migrate
```
on the archetypes and stop.
Verify the EDS/AEM target is ready exactly as
```
deploy
```
requires (project scaffolding,
```
DA_TOKEN
```
, code branch pushable).
```
rollout
```
adds no new transport.
If
```
state.json.handsOff
```
is true (
```
skills/stardust/SKILL.md
```
§ Hands-off mode), run full-auto: no per-phase pauses. Every gate and verify step below runs unchanged — hands-off removes waiting, not validation.

运行主技能的设置流程（详见
```
skills/stardust/SKILL.md
```
§ 安装设置）。
确认
```
stardust/migrated/
```
目录存在，且至少包含一个
```
*.html
```
页面（完整模式：包含所有页面；仅原型模式：包含原型页面 + 已填充
```
type
```
字段的
```
state.json
```
）。若不存在，建议先对原型页面执行
```
stardust migrate
```
，然后停止当前流程。
确认EDS/AEM目标地址已准备就绪，完全符合
```
deploy
```
的要求（项目框架搭建完成、
```
DA_TOKEN
```
配置妥当、代码分支可推送）。
```
rollout
```
不会新增任何传输方式。
如果
```
state.json.handsOff
```
为
```
true
```
（详见
```
skills/stardust/SKILL.md
```
§ 全自动模式），则运行全自动流程：无阶段间暂停。以下所有检查和验证步骤均保持不变——全自动模式仅移除等待环节，不会跳过验证。

Procedure

操作流程

Phase A — Inventory (build the coverage)

阶段A —— 盘点（构建覆盖范围）

bash

node skills/rollout/scripts/inventory.mjs --site-url <source-url>

bash

node skills/rollout/scripts/inventory.mjs --site-url <source-url>

defaults: --migrated stardust/migrated --out stardust/rollout

默认参数: --migrated stardust/migrated --out stardust/rollout

archetypes-only mode: add the full page roster from state.json

仅原型模式：从state.json加载完整页面清单

node skills/rollout/scripts/inventory.mjs --site-url <source-url> --state stardust/state.json


Writes `coverage/pages.json` (one row per page: slug, delivered `path`,
`templateId`, `blocks`, `sourceHash`, `delivery` status), `coverage/templates.json`
(pages grouped by template), and `rollout.json` (target + DA config + `lastRun`).

**Archetypes-only mode** (`--state`): pages with a `_meta.json` are seeded as in
full mode; pages present only in `state.json` are seeded with `templateId` from
`type`, `blocks` from the archetype sidecar, and `delivery.status:
content-pending`.

Inventory is **idempotent and incremental**: delivery status is preserved; a page
whose migrated HTML changed after delivery is re-flagged `stale`. Fill in the DA
coordinates in `rollout.json` (`site.da.org`, `site.site`, `site.da.ref`,
`site.liveHost`) if not inferred.

node skills/rollout/scripts/inventory.mjs --site-url <source-url> --state stardust/state.json


生成`coverage/pages.json`（每页一条记录：slug、交付路径`path`、`templateId`、`blocks`、`sourceHash`、`delivery`状态）、`coverage/templates.json`（按模板分组的页面信息）和`rollout.json`（目标地址 + DA配置 + `lastRun`记录）。

**仅原型模式**（使用`--state`参数）：带有`_meta.json`的页面会按完整模式初始化；仅在`state.json`中存在的页面会通过`type`字段获取`templateId`，通过原型侧栏文件获取`blocks`，并标记`delivery.status: content-pending`。

盘点操作具备**幂等性和增量性**：交付状态会被保留；若交付后已迁移的HTML文件发生变更，页面会被重新标记为`stale`（过期）。如果未自动推断出DA坐标，请在`rollout.json`中填写相关信息（`site.da.org`、`site.site`、`site.da.ref`、`site.liveHost`）。

Phase B — Block dedup plan (FIRST-CLASS, before any conversion)

阶段B —— 区块去重规划（核心步骤，在任何转换之前执行）

bash

node skills/rollout/scripts/blocks.mjs   # → coverage/blocks.json (the dedup unit)
node skills/rollout/scripts/plan.mjs     # → plan.json + a readable conversion plan

```
blocks.mjs
```
collapses every block instance (per-page
```
modules
```
+ chrome) into the distinct set, assigns each a canonical
```
edsBlockName
```
(kebab, reserved-class-guarded per deploy #15), and records
```
usedByPages
```
/
```
instanceCount
```
. Chrome (
```
header
```
/
```
nav
```
/
```
footer
```
) is
```
kind: chrome
```
→ site-wide authored documents (
```
/nav
```
,
```
/footer
```
) fed to the header/footer blocks. In archetypes-only mode the archetype sidecars fully determine the block set;
```
content-pending
```
pages add none.
```
plan.mjs
```
orders pages representative-first per template and gives each distinct block a single conversion point: the first page that uses it CONVERTS it, every later page REUSES it by name. The per-page
```
convert
```
/
```
reuse
```
lists are exactly
```
deploy
```
's Step-7 brief input, so each block converts once without changing deploy.
```
content-pending
```
pages are always
```
convert: []
```
.

Extending an already-delivered site? A "new template" is almost always a new COMPOSITION of the existing block library, not new block code — audit
blocks/
first. See
reference/operational-learnings.md
.

bash

node skills/rollout/scripts/blocks.mjs   # → coverage/blocks.json（去重后的区块单元）
node skills/rollout/scripts/plan.mjs     # → plan.json + 可读的转换规划文档

```
blocks.mjs
```
会将每个区块实例（每页的
```
modules
```
+ 通用组件）合并为唯一集合，为每个区块分配标准的
```
edsBlockName
```
（短横线命名格式，遵循deploy #15的保留类规则），并记录
```
usedByPages
```
/
```
instanceCount
```
。通用组件（
```
header
```
/
```
nav
```
/
```
footer
```
）标记为
```
kind: chrome
```
，对应站点级的可编辑文档（
```
/nav
```
、
```
/footer
```
），供页眉/页脚区块调用。在仅原型模式下，区块集合完全由原型侧栏文件决定；
```
content-pending
```
页面不会新增任何区块。
```
plan.mjs
```
会按模板优先排序规划页面顺序，为每个唯一区块分配唯一转换节点：第一个使用该区块的页面负责转换它，后续所有页面均通过
```
edsBlockName
```
复用该区块（无需重新创建）。每页的
```
convert
```
/
```
reuse
```
列表完全匹配
```
deploy
```
步骤7的输入要求，因此每个区块仅需转换一次，且无需修改
```
deploy
```
流程。
```
content-pending
```
页面的
```
convert
```
列表始终为空。

扩展已交付的站点？“新模板”几乎总是现有区块库的新组合，而非新的区块代码——请先审核
blocks/
目录。详见
reference/operational-learnings.md
。

Phase B2 — Metadata contract for dynamic listings (PRE-IMPORT GATE)

阶段B2 —— 动态列表的元数据约定（导入前检查）

Do this before Phase C — the import is blocked on it. What a dynamic listing block can show is bounded by what each page emits, and retrofitting metadata across thousands of already-published pages is a second migration. Before importing, produce

dynamic-blocks-map.md

(which blocks are dynamic vs static, the index each reads, the fields its cards need) and a metadata contract (the

<meta name="…">

each content TYPE must carry). Then have Phase C's

deploy

brief emit the contract per page, and author

helix-query.yaml

from the same contract. When

stardust:prepare-migration

Phase 4.5 already ran,

stardust/dynamic-blocks-map.md

and

helix-query.yaml

exist — verify them against the inventory here instead of redoing them.

Mechanics (key→meta-name rules, what a row can carry):

reference/dynamic-listings.md

必须在阶段C之前完成此步骤——导入操作会被此步骤阻塞。动态列表区块能展示的内容受限于每个页面输出的元数据，而在数千个已发布页面中补全元数据相当于二次迁移。导入之前，需生成

dynamic-blocks-map.md

（标记哪些区块是动态/静态、每个区块读取的索引、卡片所需的字段）以及元数据约定（每种内容类型必须包含的

<meta name="…">

标签）。随后在阶段C的

deploy

流程中，按约定为每个页面生成元数据，并根据同一约定编写

helix-query.yaml

。如果

stardust:prepare-migration

阶段4.5已执行，

stardust/dynamic-blocks-map.md

和

helix-query.yaml

已存在——此时只需在此阶段根据盘点结果验证其正确性，无需重新生成。

实现机制（键→元数据名称规则、每条记录可包含的内容）：详见

reference/dynamic-listings.md

。

Phase C — Deliver the site (drive

deploy

per page, per the plan)

阶段C —— 交付站点（按规划逐页调用

deploy

）

Blocked on Phase B2 — author each page's metadata contract into its metadata block during delivery, so the indexes are rich at import time.

Walk

plan.json.steps

in order (representative pages first). For each page:

Convert + push the migrated HTML (
```
source.migratedHtml
```
) to AEM via the
```
deploy
```
methodology. Pass the plan step into deploy's brief: create only the blocks in
```
convert
```
; for each block in
```
reuse
```
, REUSE the existing block by its
```
edsBlockName
```
(do not recreate).
content-pending
pages (archetypes-only): no migrated HTML — skip the document push entirely (no shell/placeholder), record
```
content-pending
```
, surface as "awaiting content track." Their block code is already deployed via the archetype.
Static contract lint (pre-PUT, deterministic). Before the push, run the delivery-contract linter — it catches the cheap, deterministic failures (wrapper, one-CTA-per-
```
<p>
```
, trailing-slash, path-safety,
```
/img/
```
src,
```
about:error
```
) offline so a broken page never reaches preview. Mechanics in
```
reference/delivery-lint.md
```
. A P0/P1 blocks the PUT.
bash
```
node skills/rollout/scripts/delivery-lint.mjs --file <html> --path </da/path>
node skills/rollout/scripts/media-reconcile.mjs --file <html> --deploy-host <branch>--<repo>--<owner>.aem.live [--apply]
```
```
media-reconcile
```
resolves every image on the network and decides optimize/keep/rewrite/omit (
```
skills/migrate/reference/media-reconciliation.md
```
) — the authoritative form of the image-fidelity gate below.
Run the delivery gates before flipping a page to
```
deployed
```
. Each is a one-line rule here; mechanics + helpers in
```
reference/delivery-gates.md
```
:
- Source-fidelity — don't add sections the source lacks; never fabricate facts.
```
node skills/rollout/scripts/section-fidelity.mjs --file <html> --source <url>
```
- Image-fidelity — every authored
```
<img>
```
  src must return 200 or be omitted; never ship
```
<img src="about:error">
```
  . Run
```
media-reconcile.mjs
```
  (step 2).
- Path-safety — normalize source paths to AEM-Edge-safe form (lowercase, no trailing
```
-
```
  /
```
_
```
  , no
```
--
```
  segment); record original→normalized in
```
stardust/redirects.tsv
```
  . (delivery-lint flags violations.)
- Source-content hygiene — skip dead source URLs; author bodyless/PDF-only sources thin and faithful (tier
```
thin
```
  ,
```
skills/migrate/reference/fidelity-tiers.md
```
  ), don't pad with invented prose.
- Fidelity tier declared — record each page's
```
fidelityTier
```
  (archetype/sibling/thin) so coverage shows what was craft-gated vs cloned (
```
skills/migrate/reference/fidelity-tiers.md
```
  ).

Record outcomes with the state-writer (never hand-edit the ledger):

bash

node skills/rollout/scripts/update-coverage.mjs <slug> --status converting
node skills/rollout/scripts/update-coverage.mjs --block <id> --status converted --eds-name <name>
node skills/rollout/scripts/update-coverage.mjs <slug> --status deployed --url <branch-preview-url>
node skills/rollout/scripts/update-coverage.mjs <slug> --status content-pending   # no document push

Publish in the loop (
PUT → preview → live
), don't stop at preview — any query-index (Phase D2) builds from the live tree, so a preview-only delivery leaves indexes empty. On failure:

--status failed --error "<reason>"

and continue (one page's failure never aborts the rollout).

Foundation-first gate (hard block, once per rollout). When the FIRST archetype page flips to

deployed

, stop and prove the foundation before authoring any second page: run

stardust:diff

(both probes) against its prototype, plus computed-style invariants in a headless render — grid containers compute

display: grid

(not stacked single-column), sections are full-bleed where the design says so, and the CTA/button classes are actually styled (per

stardust/runtime-contract.json

skills/deploy/SKILL.md

§ Runtime-detection probe). A wrong runtime assumption (block wrapper class, button classes) is silent and sitewide — typography still looks fine while every grid stacks. This one gate is the difference between fixing one page and rebuilding every template.

Execution model: waves. Deliver in waves of parallel author-only agents — each agent curls its source pages and writes files only, never deploys or edits blocks — template clusters concurrently (non-overlapping pages), representative-first so blocks exist to be reused; then a central deploy per page; then background batches with a per-page OK/FAIL ledger, re-driving FAILs only. For clusters of 6–20+ siblings, the full flow is

reference/delivery-gates.md

§ Batched delivery. The central deploy step should run the bundled, resumable driver rather than a serial loop:

node skills/deploy/scripts/deploy-batch.mjs --org <org> --repo <repo> --branch <branch> --content <dir>

(concurrency pool, persistent ledger that skips already-live pages, retry/backoff, append-only log, delivered-

.plain.html

check). After a transient blip, re-run the same command — it re-drives only the FAILs. Then reconcile the ledger into coverage with

update-coverage.mjs

此阶段被阶段B2阻塞——交付过程中需将元数据约定写入每个页面的元数据区块，确保导入时索引内容完整。

按

plan.json.steps

中的顺序执行（优先处理代表页面）。针对每个页面：

转换并推送已迁移的HTML文件（
```
source.migratedHtml
```
）至AEM，遵循
```
deploy
```
的流程规范。将规划步骤传入deploy的简短指令：仅创建
```
convert
```
列表中的区块；对于
```
reuse
```
列表中的每个区块，通过
```
edsBlockName
```
复用现有区块（无需重新创建）。
content-pending
页面（仅原型模式）：无已迁移的HTML文件——完全跳过文档推送（无需创建占位符/外壳），标记为
```
content-pending
```
，显示为“等待内容交付”。其区块代码已通过原型页面部署完成。
静态约定检查（推送前执行，确定性检查）。推送之前，运行交付约定检查工具——它会离线检测简单的确定性错误（包装器、每个
```
<p>
```
标签仅包含一个CTA、尾斜杠、路径安全性、
```
/img/
```
资源地址、
```
about:error
```
），避免错误页面进入预览环境。实现机制详见
```
reference/delivery-lint.md
```
。P0/P1级错误会阻止推送。
bash
```
node skills/rollout/scripts/delivery-lint.mjs --file <html> --path </da/path>
node skills/rollout/scripts/media-reconcile.mjs --file <html> --deploy-host <branch>--<repo>--<owner>.aem.live [--apply]
```
```
media-reconcile
```
会解析网络上的每张图片，决定优化/保留/重写/忽略（详见
```
skills/migrate/reference/media-reconciliation.md
```
）——这是图片保真度检查的权威标准。
执行交付检查，然后将页面标记为
```
deployed
```
。以下是每条检查的简要规则，详细机制和辅助工具详见
```
reference/delivery-gates.md
```
：
- 源内容保真——不得添加源页面没有的内容；不得虚构信息。执行命令：
```
node skills/rollout/scripts/section-fidelity.mjs --file <html> --source <url>
```
- 图片保真——每个可编辑的
```
<img>
```
  资源地址必须返回200状态码，否则需忽略；不得发布
```
<img src="about:error">
```
  。执行步骤2中的
```
media-reconcile.mjs
```
  。
- 路径安全性——将源路径标准化为符合AEM-Edge安全规范的格式（小写、无尾部
```
-
```
  /
```
_
```
  、无
```
--
```
  分段）；在
```
stardust/redirects.tsv
```
  中记录原始路径→标准化路径的映射。（交付检查工具会标记违规情况。）
- 源内容清理——跳过无效的源URL；对于无正文/仅含PDF的源页面，生成简洁且保真的内容（
```
thin
```
  层级，详见
```
skills/migrate/reference/fidelity-tiers.md
```
  ），不得添加虚构内容。
- 保真层级标记——记录每个页面的
```
fidelityTier
```
  （原型/同模板/简洁），以便覆盖范围统计显示哪些页面经过人工检查、哪些是批量克隆的（详见
```
skills/migrate/reference/fidelity-tiers.md
```
  ）。

记录结果（必须使用状态写入工具，不得手动编辑台账）：

bash

node skills/rollout/scripts/update-coverage.mjs <slug> --status converting
node skills/rollout/scripts/update-coverage.mjs --block <id> --status converted --eds-name <name>
node skills/rollout/scripts/update-coverage.mjs <slug> --status deployed --url <branch-preview-url>
node skills/rollout/scripts/update-coverage.mjs <slug> --status content-pending   # 未推送文档

在流程中完成发布（
PUT → preview → live
），不要停留在预览阶段——任何查询索引（阶段D2）都基于**已发布（live）**的内容树，因此仅完成预览的交付会导致索引为空。若失败：执行

--status failed --error "<reason>"

并继续流程（单个页面失败不会终止整个部署）。

基础验证检查（硬阻塞，整个部署流程仅执行一次）。当第一个原型页面被标记为

deployed

时，暂停流程并先验证基础内容：针对其原型页面运行

stardust:diff

（两种探测方式），加上无头渲染中的计算样式不变性检查——网格容器需计算为

display: grid

（而非堆叠的单列布局），设计要求全屏的区域需全屏显示，CTA/按钮类需正确应用样式（遵循

stardust/runtime-contract.json

、

skills/deploy/SKILL.md

§ 运行时探测规则）。错误的运行时假设（区块包装器类、按钮类）不会产生警告，但会影响整个站点——排版看起来正常，但所有网格都会堆叠。此检查是修复单个页面还是重建所有模板的关键区别。

执行模式：分批交付。以并行的仅编辑代理分批交付——每个代理仅获取源页面并写入文件，不执行部署或编辑区块操作；按模板集群并行处理（页面不重叠），优先处理代表页面以便区块可被复用；随后针对每个页面执行集中部署；最后后台批量处理失败页面，仅重新执行失败任务。对于包含6–20+个同模板页面的集群，完整流程详见

reference/delivery-gates.md

§ 批量交付流程。集中部署步骤应使用捆绑的可续传驱动程序，而非串行循环：

node skills/deploy/scripts/deploy-batch.mjs --org <org> --repo <repo> --branch <branch> --content <dir>

（包含并发池、跳过已发布页面的持久化台账、重试/退避机制、追加日志、已交付

.plain.html

检查）。遇到临时故障后，重新运行同一命令——它会仅重新执行失败任务。随后使用

update-coverage.mjs

将台账同步至覆盖范围统计。

Phase D — Site assembly (whole-site artifacts)

阶段D —— 站点组装（全站点 artifacts）

bash

node skills/rollout/scripts/assemble.mjs   # → rollout/site/{sitemap.xml,robots.txt,manifest.json}

Generates site-wide artifacts:

sitemap.xml

robots.txt

from delivered paths, and a fragments manifest mapping chrome blocks to the authored chrome documents (

content/nav.html

content/footer.html

) with their

canon/*.html

source (

deploy

authors + deploys the documents through the normal content chain — they MUST be published or the chrome 404s sitewide). Redirects: if Phase C's path-safety gate emitted

stardust/redirects.tsv

, wire it into the EDS redirects mechanism here so original inbound URLs don't 404.

bash

node skills/rollout/scripts/assemble.mjs   # → rollout/site/{sitemap.xml,robots.txt,manifest.json}

生成站点级 artifacts：从已交付路径生成

sitemap.xml

robots.txt

，以及将通用组件映射至可编辑通用文档（

content/nav.html

、

content/footer.html

）的片段清单，同时包含它们的

canon/*.html

源文件（

deploy

通过常规内容链编辑并部署这些文档——必须发布这些文档，否则全站通用组件会返回404）。 重定向配置：如果阶段C的路径安全性检查生成了

stardust/redirects.tsv

，在此阶段将其接入EDS重定向机制，避免原始入站URL返回404。

Phase D2 — Dynamic listings (query-index) — optional

阶段D2 —— 动态列表（查询索引）——可选

Blocks that LIST other pages (directories, news/event feeds, "related" rails) should read an EDS query-index rather than static cards. Build it from the B2 contract: author

helix-query.yaml

(scoped indexes), rewrite the listing blocks to

fetch

their index (with filter/sort/paginate + an authored fallback), and validate one flagship end-to-end. The index builds from the published (live) tree — publish before expecting rows. Full mechanics:

reference/dynamic-listings.md

Index resilience. After a bulk publish, poll the index
total
with a timeout (indexing is async; a freshly-synced config sits at

building

/404 first) — don't assert once and fail. Decode

"requested path returned a 301 or 404"

per row as not-published, not a bad selector: publish the page and re-poll (

reference/dynamic-listings.md

§ The publish gotcha). If the index never settles inside the timeout, the documented degraded mode is a committed static index JSON (generated from the coverage ledger, served from the code branch) + regeneration on content change — the listing blocks read the same row shape either way, so the swap back is a URL change.

用于列出其他页面的区块（目录、新闻/活动提要、“相关内容”侧边栏）应读取EDS的查询索引，而非静态卡片。根据B2阶段的约定构建索引：编写

helix-query.yaml

（范围索引），重写列表区块以

fetch

索引（包含过滤/排序/分页 + 可编辑的回退内容），并验证一个旗舰页面的端到端流程。索引基于**已发布（live）**的内容树构建——发布后才能获取记录。完整机制详见

reference/dynamic-listings.md

。

索引容错性。批量发布后，轮询索引的
total
字段并设置超时（索引构建是异步的；新同步的配置最初会处于

building

/404状态）——不要仅检查一次就判定失败。将每条记录中的

"requested path returned a 301 or 404"

解读为未发布，而非选择器错误：发布页面后重新轮询（详见

reference/dynamic-listings.md

§ 发布陷阱）。如果索引在超时时间内仍未就绪，文档中规定的降级模式是使用已提交的静态索引JSON（从覆盖范围台账生成，从代码分支提供服务） + 内容变更时重新生成——列表区块读取的记录格式一致，因此切换仅需修改URL。

Phase D3 — Multilingual (per-language trees) — optional

阶段D3 —— 多语言支持（按语言划分内容树）——可选

When the source has language trees (

/fr/…

/en/…

), add them as parallel content trees that REUSE the same block library — only authored content and a little wiring change (language-routed chrome documents, per-language indexes, per-language path-safety). See

reference/multilingual.md

如果源站点包含语言目录（

/fr/…

、

/en/…

），将它们作为并行内容树添加，复用同一区块库——仅需修改可编辑内容和少量配置（按语言路由的通用文档、按语言划分的索引、按语言进行路径安全性检查）。详见

reference/multilingual.md

。

Phase E — Full-site verify

阶段E —— 全站点验证

bash

node skills/rollout/scripts/verify.mjs            # uses rollout.json site.liveHost

bash

node skills/rollout/scripts/verify.mjs            # 使用rollout.json中的site.liveHost

or: --base <url> (explicit host) | --root <dir> (offline, against a local export)

或：--base <url> (指定主机) | --root <dir> (离线模式，针对本地导出内容)


For every delivered page, `verify` confirms HTTP 200, no `about:error` (deploy
#75), and that every internal `href="/…"` resolves to a known delivered path — then
flips each page to `verified` or `failed`. Exits non-zero if any page failed.

**Headless render check (per template).** A 200 `.plain.html` can still render
blank — decoration failures (missing script, wrong block wrapper class, 404
chrome) are invisible to a text check. On the FIRST delivered page of each
template (home included), load the live URL in a headless browser and assert
decoration ran: the runtime's `body.appear` class is set (per
`stardust/runtime-contract.json`), `main .section` count > 0,
zero `pageerror` events, zero broken images.


针对每个已交付页面，`verify`会确认HTTP状态码为200、无`about:error`（deploy #75）、每个内部`href="/…"`均指向已交付的已知路径——然后将每个页面标记为`verified`或`failed`。如果有页面失败，命令会返回非零状态码。

**无头渲染检查（按模板执行）**。返回200状态码的`.plain.html`页面仍可能渲染空白——装饰失败（缺少脚本、错误的区块包装器类、通用组件404）无法通过文本检查发现。针对每个模板的第一个已交付页面（包括首页），在无头浏览器中加载在线URL并确认装饰已执行：运行时已设置`body.appear`类（遵循`stardust/runtime-contract.json`）、`main .section`数量>0、无`pageerror`事件、无损坏图片。

Phase E2 — Link-audit completeness

阶段E2 —— 链接审计完整性

verify.mjs

checks the links on delivered pages; this phase closes the set of link targets a roster-driven batch misses (

reference/operational-learnings.md

§ Two verify checks):

Nav/footer/landing targets are NOT archetype siblings. Enumerate every
```
href
```
in the
```
/nav
```
+
```
/footer
```
documents plus each section's index/landing page and confirm each is deployed + published + verified — and that the chrome documents THEMSELVES are published — otherwise they get committed but never published, their links 404, and the dashboard still reads 100%.
Localize source-site bounce links whose path has a delivered local 200 page (header/footer/home first); keep an absolute source link only when no local page exists (a bounce beats a 404).
Strip trailing slashes and
.html
from internal links. EDS serves extensionless documents with no trailing slash, so
```
/x/y/
```
and
```
/x/y.html
```
both 404 (render the 404 block) while
```
.plain.html
```
still passes — nav reads green, every link is dead. Normalize every internal
```
href
```
(keep bare
```
/
```
); repoint
```
.html
```
links with no local page at the working source URL.
The audit GETs each href against the LIVE tree. Structural resolution against the ledger misses trailing-slash and case defects that only delivery exposes.

verify.mjs

检查已交付页面上的链接；此阶段会补全基于清单的批量交付遗漏的链接目标（详见

reference/operational-learnings.md

§ 两次验证检查）：

导航/页脚/落地页目标并非原型同模板页面。枚举
```
/nav
```
+
```
/footer
```
文档中的所有
```
href
```
，以及每个板块的索引/落地页，确认每个目标均已部署 + 发布 + 验证——同时确认通用文档本身已发布，否则这些文档会被提交但从未发布，其链接会返回404，而仪表盘仍显示100%完成。
本地化源站点的跳转链接：如果路径对应的本地页面已交付并返回200（优先处理页眉/页脚/首页），则使用本地化链接；仅当本地页面不存在时保留绝对源链接（跳转链接优于404）。
移除内部链接的尾斜杠和
.html
后缀。EDS提供无后缀、无尾斜杠的文档，因此
```
/x/y/
```
和
```
/x/y.html
```
都会返回404（渲染404区块），而
```
.plain.html
```
仍会通过检查——导航显示正常，但所有链接均失效。标准化每个内部
```
href
```
（保留裸路径
```
/
```
）；对于无对应本地页面的
```
.html
```
链接，重新指向可用的源URL。
审计会针对已发布内容树获取每个href。基于台账的结构解析无法发现仅在交付时才暴露的尾斜杠和大小写问题。

Phase F — Optimize: multi-source audit + gate (delivery quality)

阶段F —— 优化：多源审计 + 检查（交付质量）

The in-flow quality gate. optimize aggregates findings from existing audit skills into one ledger (

optimize/findings.json

optimize/scorecard.json

), tags each by fixability, and gates the rollout. Sources (full mapping in

reference/audit-sources.md

rollout:baseline
— built-in deterministic detectors:

bash

node skills/rollout/scripts/optimize.mjs        # uses rollout.json site.liveHost
# or: --base <url> | --root <dir> | --slug <s> | --all

impeccable:critique
+
impeccable:audit
— design quality + a11y/perf.
The marketing SEO skills —
```
seo-audit
```
,
```
schema
```
,
```
ai-seo
```
,
```
site-architecture
```
.

stardust:tensions
— mechanical design tensions from

stardust/current/brand-review.html

Normalize each source's findings into the ledger with the writer:

bash

node skills/rollout/scripts/findings.mjs record \
  --source marketing:seo-audit --layer seo --check thin-content \
  --severity P2 --fixability platform-migration \
  --scope-ids blog/post --evidence "…" --recommend "…"
node skills/rollout/scripts/findings.mjs resolve <id> --status accepted --note "…"

All sources share one id space, dedup, scorecard, and the detect → fix → verify loop: re-running a source resolves its own gone findings; a regressed

fixed

finding re-opens; human

accepted

wontfix

are preserved. Fixability routing:

platform-migration

→ autofix / re-deploy;

design-pass

→ upstream (surface only);

out-of-scope

→ informational. The gate exits non-zero if any open P1 is in scope — a page is delivery-clean only when verify passes and the ledger has no open P1.

At ~1k-page scale: a
head.html
-level fix needs a site-wide republish to land and flip its per-page findings; the optimize gate only audits pages in
coverage/pages.json
; and faithfully migrated parallel source trees produce legitimate duplicate-title findings (a canonical decision, not a bug). See
reference/operational-learnings.md
.

The judgment layers (brand-tensions, design-ux, content-conversion) are scored

null

until populated by the impeccable/tensions sources — the scorecard shows not-assessed rather than faking a score.

流程内的质量检查。optimize会将现有审计技能的结果汇总至一个台账（

optimize/findings.json

optimize/scorecard.json

），按可修复性标记每个问题，并阻塞部署流程。数据源（完整映射详见

reference/audit-sources.md

）：

rollout:baseline
——内置的确定性检测器：

bash

node skills/rollout/scripts/optimize.mjs        # 使用rollout.json中的site.liveHost
# 或：--base <url> | --root <dir> | --slug <s> | --all

impeccable:critique
+
impeccable:audit
——设计质量 + 无障碍/性能审计。
营销SEO技能——
```
seo-audit
```
、
```
schema
```
、
```
ai-seo
```
、
```
site-architecture
```
。可选；如果缺失，显示提示信息。

stardust:tensions
——来自

stardust/current/brand-review.html

的机械设计冲突。

使用写入工具将每个数据源的结果标准化至台账：

bash

node skills/rollout/scripts/findings.mjs record \\
  --source marketing:seo-audit --layer seo --check thin-content \\
  --severity P2 --fixability platform-migration \\
  --scope-ids blog/post --evidence "…" --recommend "…"
node skills/rollout/scripts/findings.mjs resolve <id> --status accepted --note "…"

所有数据源共享同一ID空间，支持去重、计分卡和检测→修复→验证循环：重新运行数据源会自动标记已解决的问题；已修复的问题若再次出现会重新打开；人工标记的

accepted

wontfix

状态会被保留。可修复性路由：

platform-migration

→ 自动修复 / 重新部署；

design-pass

→ 上游反馈（仅展示）；

out-of-scope

→ 信息提示。如果存在任何未解决的P1级问题，检查会返回非零状态码——只有当验证通过且台账中无未解决的P1级问题时，页面才符合交付质量要求。

针对约1000页规模的站点：
head.html
级别的修复需要全站重新发布才能生效并更新每页的问题记录；optimize检查仅审计
coverage/pages.json
中的页面；忠实迁移的并行源站点会产生合法的重复标题问题（这是规范决策，而非bug）。详见
reference/operational-learnings.md
。

判断层（品牌冲突、设计UX、内容转化）的分数默认为

null

，需等待impeccable/tensions数据源填充后才会更新——计分卡会显示“未评估”，而非伪造分数。

Phase G — AEM autofix (close the loop)

阶段G —— AEM自动修复（闭环处理）

bash

node skills/rollout/scripts/autofix-aem.mjs --project <eds-root>   # [--dry-run] [--slug s] [--check c]

The platform autofix engine (AEM-EDS, v1 — aggressive). For every open finding whose

check

has a registered EDS fixer, it edits the EDS project files, logs the change on

finding.autofix

, and stages the finding

in-progress

deterministic —
```
eds-fix-h1
```
(exactly one
```
<h1>
```
), sitemap (re-assemble).

content-draft (logged for review) —

eds-metadata-title

eds-metadata-description

eds-alt-draft

eds-disambiguate-title

manual (prepares guidance/payload) —

eds-jsonld

(use

marketing:schema

eds-canonical

eds-landmark-main

Use

--dry-run

first. After applying, re-deploy the edited pages, then re-run verify + optimize — staged findings flip to

fixed

design-pass

findings are surfaced, not auto-fixed.

bash

node skills/rollout/scripts/autofix-aem.mjs --project <eds-root>   # [--dry-run] [--slug s] [--check c]

平台自动修复引擎（AEM-EDS，v1版本——主动修复）。对于每个未解决且

check

字段已注册EDS修复器的问题，它会编辑EDS项目文件，在

finding.autofix

中记录变更，并将问题标记为

in-progress

：

确定性修复——
```
eds-fix-h1
```
（确保仅有一个
```
<h1>
```
）、站点地图（重新组装）。

内容草稿（记录供审核）——

eds-metadata-title

eds-metadata-description

、

eds-alt-draft

、

eds-disambiguate-title

。

手动修复（准备指导/负载）——
```
eds-jsonld
```
（使用
```
marketing:schema
```
）、
```
eds-canonical
```
、
```
eds-landmark-main
```
。

建议先使用

--dry-run

参数试运行。应用修复后，重新部署已编辑的页面，然后重新运行verify + optimize——已标记为

in-progress

的问题会切换为

fixed

。

design-pass

问题仅展示，不自动修复。

Phase H — Report

阶段H —— 生成报告

Read

rollout.json.lastRun

optimize/scorecard.json

(or re-run

inventory.mjs

rollout — <site> → aem-eds
==================================================
Pages       <N> total · <v> verified · <d> deployed · <p> pending · <cp> content-pending · <s> stale
Templates   <T> (per-template delivered/total)
Blocks      <B> total · <c> converted · <p> pending
Quality     health <H>/100 · open P1 <n> / P2 <n> / P3 <n>
To deliver  <list of remaining slugs>
Content     <cp> pages awaiting content track (block code deployed, document not yet pushed)

Surface

pending

stale

failed

as the explicit "what's missing" list.

content-pending

pages are listed separately — not failures; their block code is live and they advance to

pending

automatically when

migrate

emits their HTML and

inventory

is re-run.

Also write/refresh
stardust/learnings.md
per

skills/stardust/reference/learnings.md

: one entry per failure class this run surfaced (evidence, proposed skill + section to change,

status: pending

). plugin maintainers harvest pending entries into skill diffs — this is how a run's hard-won fixes stop being re-learned.

读取

rollout.json.lastRun

optimize/scorecard.json

（或重新运行

inventory.mjs

）：

rollout — <site> → aem-eds
==================================================
页面总数       <N> · 已验证 <v> · 已部署 <d> · 待部署 <p> · 内容待处理 <cp> · 过期 <s>
模板数量       <T>（按模板统计已交付/总数）
区块总数       <B> · 已转换 <c> · 待转换 <p>
质量评分     健康度 <H>/100 · 未解决P1 <n> / P2 <n> / P3 <n>
待交付页面  <剩余slug列表>
内容待处理  <cp>个页面等待内容交付（区块代码已部署，文档尚未推送）

将

pending

stale

failed

页面列为明确的“待完成”列表。

content-pending

页面单独列出——不属于失败页面；其区块代码已上线，当

migrate

生成其HTML文件并重新运行

inventory

后，会自动从

content-pending

转为

pending

。

同时编写/更新
stardust/learnings.md
，遵循

skills/stardust/reference/learnings.md

的规范：针对本次部署中出现的每个故障类别添加一条记录（包含证据、建议修改的技能及章节、

status: pending

）。插件维护者会收集待处理记录并更新技能——这能避免重复踩坑，将本次部署积累的经验固化为流程改进。

Phase I — Dashboard

阶段I —— 生成仪表盘

bash

node skills/rollout/scripts/dashboard.mjs    # → dashboard/index.html + data.json

A self-contained, no-external-JS dashboard rendered in the project's design identity (brand tokens read from a migrated page's

:root

). Centerpiece: a page tree of every identified page, nested by URL path, each node colour-coded by the most-advanced lifecycle stage it reached:

identified → prototyped → deployed → optimised

The stage spans

state.json

(

rostered/extracted/directed

→ identified,

prototyped/approved/migrated

→ prototyped), rollout coverage (

deployed

verified

→ deployed), and optimize (

optimised

= verified and no open findings). A

content-pending

sibling stays at

identified

(it's in the ledger so delivery can be tracked, but has no designed document yet). Legend counts are cumulative. Template archetypes are badged

; a page with open findings shows a red count. Also a templates table + the quality scorecard.

dashboard/data.json

is the inspectable snapshot — regenerate at every iteration boundary. (

state.json

is read-only and optional.)

bash

node skills/rollout/scripts/dashboard.mjs    # → dashboard/index.html + data.json

生成一个独立、无外部JS依赖的仪表盘，采用项目的设计风格（从已迁移页面的

:root

读取品牌标识）。核心功能：展示所有已识别页面的页面树，按URL路径嵌套，每个节点按其达到的最高生命周期阶段标记颜色：

已识别 → 已原型化 → 已部署 → 已优化

阶段状态涵盖

state.json

（

rostered/extracted/directed

→ 已识别，

prototyped/approved/migrated

→ 已原型化）、rollout覆盖范围（

deployed

verified

→ 已部署）和optimize（

optimised

= 已验证且无未解决问题）。

content-pending

的同模板页面会停留在

已识别

阶段（已纳入台账以便跟踪交付，但尚未生成设计文档）。图例计数为累计值。模板原型会标记

徽章；存在未解决问题的页面会显示红色计数。同时包含模板统计表 + 质量计分卡。

dashboard/data.json

是可检查的快照——每次迭代边界都需重新生成。（

state.json

为只读，可选。）

Inputs

输入项

Input	Source	Used for
`stardust/migrated/*.html`	`migrate`	the pages to deliver (read-only)
`stardust/migrated/**/_meta.json`	`migrate`	`templateId` ( `template` / `type` ), `blocks` ( `modules` ), `title`
`stardust/state.json`	stardust core	(archetypes-only mode) full page roster + `type` for pages not yet migrated
`stardust/rollout/rollout.json`	rollout / user	DA target coordinates

输入项	来源	用途
`stardust/migrated/*.html`	`migrate`	待交付的页面（只读）
`stardust/migrated/**/_meta.json`	`migrate`	`templateId` （ `template` / `type` ）、 `blocks` （ `modules` ）、 `title`
`stardust/state.json`	stardust核心	(仅原型模式) 完整页面清单 + 未迁移页面的 `type`
`stardust/rollout/rollout.json`	rollout / 用户	DA目标地址坐标

Outputs

输出项

Path	Purpose
`stardust/rollout/coverage/pages.json`	per-page delivery ledger (schema: `schemas/rollout-pages.schema.json` )
`stardust/rollout/coverage/templates.json`	template grouping + roll-ups (schema: `schemas/rollout-templates.schema.json` )
`stardust/rollout/coverage/blocks.json`	the block dedup ledger + EDS mapping (schema: `schemas/rollout-blocks.schema.json` )
`stardust/rollout/plan.json`	dedup-driven delivery order + per-page convert/reuse briefs
`stardust/rollout/optimize/findings.json`	multi-source quality findings ledger (schema: `schemas/rollout-findings.schema.json` )
`stardust/rollout/optimize/scorecard.json`	quality scorecard + history (schema: `schemas/rollout-scorecard.schema.json` )
`stardust/rollout/rollout.json`	config + `lastRun` summary (schema: `schemas/rollout-config.schema.json` )
`stardust/rollout/site/{sitemap.xml,robots.txt,manifest.json}`	site-level assembly artifacts
`stardust/rollout/dashboard/{index.html,data.json}`	self-contained progress dashboard + snapshot
edits to the EDS project ( `content/**` , `styles/` )	applied by `autofix-aem` (the only files rollout writes outside `stardust/rollout/` )
the delivered EDS site	produced by `deploy` per page (blocks/, content/, fragments — owned by `deploy` )

rollout

writes under

stardust/rollout/

and — only via

autofix-aem

— to the EDS project it delivers to. It never modifies the agnostic core,

state.json

, or

migrated/

— those are read-only inputs.

路径	用途
`stardust/rollout/coverage/pages.json`	逐页交付台账（ schema: `schemas/rollout-pages.schema.json` ）
`stardust/rollout/coverage/templates.json`	模板分组 + 汇总信息（ schema: `schemas/rollout-templates.schema.json` ）
`stardust/rollout/coverage/blocks.json`	区块去重台账 + EDS映射（ schema: `schemas/rollout-blocks.schema.json` ）
`stardust/rollout/plan.json`	基于去重的交付顺序 + 逐页转换/复用指令
`stardust/rollout/optimize/findings.json`	多源质量问题台账（ schema: `schemas/rollout-findings.schema.json` ）
`stardust/rollout/optimize/scorecard.json`	质量计分卡 + 历史记录（ schema: `schemas/rollout-scorecard.schema.json` ）
`stardust/rollout/rollout.json`	配置 + `lastRun` 汇总（ schema: `schemas/rollout-config.schema.json` ）
`stardust/rollout/site/{sitemap.xml,robots.txt,manifest.json}`	站点级组装 artifacts
`stardust/rollout/dashboard/{index.html,data.json}`	独立进度仪表盘 + 快照
对EDS项目的修改（ `content/**` , `styles/` ）	由 `autofix-aem` 执行（rollout仅在此处修改 `stardust/rollout/` 之外的文件）
已交付的EDS站点	由 `deploy` 逐页生成（blocks/、content/、fragments —— 归 `deploy` 所有）

rollout

的输出文件均位于

stardust/rollout/

目录下，仅通过

autofix-aem

会修改EDS项目文件。它绝不会修改通用核心文件、

state.json

或

migrated/

目录——这些均为只读输入项。

Dependencies (audit sources — referenced, not vendored)

依赖项（审计数据源——仅引用，未内置）

optimize orchestrates existing audit skills by invocation; they must be installed:

impeccable (
```
critique
```
,
```
audit
```
) — already a stardust dependency.
marketing skills —
```
seo-audit
```
,
```
schema
```
,
```
ai-seo
```
,
```
site-architecture
```
. Optional; surface a note if absent.
stardust tensions — emitted in-repo by
```
extract
```
(
```
brand-review.html
```
).

Normalize each one's output into the ledger via

findings.mjs record

. See

reference/audit-sources.md

optimize通过调用现有审计技能进行统筹，需确保这些技能已安装：

impeccable（
```
critique
```
、
```
audit
```
）——已作为stardust的依赖项。
营销技能——
```
seo-audit
```
、
```
schema
```
、
```
ai-seo
```
、
```
site-architecture
```
。可选；如果缺失，显示提示信息。
stardust tensions——由
```
extract
```
在仓库内生成（
```
brand-review.html
```
）。

通过

findings.mjs record

将每个数据源的输出标准化至台账。详见

reference/audit-sources.md

。

What rollout does NOT do

rollout不负责的事项

No upstream redesign.
```
design-pass
```
findings are surfaced, not fixed here. autofix only touches platform-fixable findings in the EDS project.
No new transport. Delivery is
```
deploy
```
's DA Source API path, unchanged.
No redesign of the agnostic core.
```
extract
```
/
```
direct
```
/
```
prototype
```
/
```
migrate
```
and
```
deploy
```
are untouched.
No full pre-migration requirement. Archetypes-only mode is first-class: block code is deployed from the archetypes; remaining pages advance from
```
content-pending
```
to
```
deployed
```
as
```
migrate
```
emits their HTML — no rollout restart.

不负责上游重新设计。
```
design-pass
```
问题仅展示，不在此处修复。自动修复仅处理EDS项目中可通过平台修复的问题。
不新增传输方式。交付使用
```
deploy
```
的DA Source API路径，保持不变。
不修改通用核心流程。
```
extract
```
/
```
direct
```
/
```
prototype
```
/
```
migrate
```
和
```
deploy
```
均保持不变。
不要求完成预迁移。仅原型模式为一等功能：区块代码从原型页面部署；剩余页面会在
```
migrate
```
生成其HTML文件后自动从
```
content-pending
```
转为
```
deployed
```
——无需重启rollout流程。

Scripts

脚本说明

```
scripts/inventory.mjs
```
— migrated tree → page + template coverage (idempotent, stale-aware).
```
--state <path>
```
enables archetypes-only mode.
```
scripts/blocks.mjs
```
— distinct-block dedup ledger (
```
blocks.json
```
).
```
scripts/plan.mjs
```
— dedup-driven delivery order + per-page convert/reuse briefs.
```
scripts/update-coverage.mjs
```
— deterministic delivery state-writer for pages and blocks; re-derives all roll-ups.
```
scripts/section-fidelity.mjs
```
— source-fidelity gate scaffold (authored sections vs source heading outline; informs the gate, never auto-decides).
```
scripts/assemble.mjs
```
— site-level sitemap / robots / fragments manifest.
```
scripts/verify.mjs
```
— full-site structural verification (HTTP or offline
```
--root
```
).
```
scripts/optimize.mjs
```
—
```
rollout:baseline
```
detectors + the multi-source gate; exits non-zero on open P1.
```
scripts/findings.mjs
```
— record/resolve findings from the external audit sources.
```
scripts/autofix-aem.mjs
```
— the AEM autofix engine (edits the EDS project).
```
scripts/dashboard.mjs
```
— design-identity dashboard +
```
data.json
```
snapshot.
```
scripts/lib.mjs
```
— shared IO + roll-up + page-loading + autofix-registry helpers.

```
scripts/inventory.mjs
```
—— 将已迁移目录树转换为页面 + 模板覆盖范围统计（幂等、支持过期检测）。使用
```
--state <path>
```
启用仅原型模式。
```
scripts/blocks.mjs
```
—— 生成唯一区块去重台账（
```
blocks.json
```
）。
```
scripts/plan.mjs
```
—— 生成基于去重的交付顺序 + 逐页转换/复用指令。
```
scripts/update-coverage.mjs
```
—— 页面和区块的确定性状态写入工具；自动重新生成所有汇总信息。
```
scripts/section-fidelity.mjs
```
—— 源内容保真检查脚手架（可编辑板块与源页面标题大纲对比；仅提供检查依据，不自动决策）。
```
scripts/assemble.mjs
```
—— 生成站点级站点地图 / robots协议文件 / 片段清单。
```
scripts/verify.mjs
```
—— 全站点结构验证（支持HTTP或离线
```
--root
```
模式）。
```
scripts/optimize.mjs
```
——
```
rollout:baseline
```
检测器 + 多源质量检查；若存在未解决的P1级问题，返回非零状态码。
```
scripts/findings.mjs
```
—— 记录/解析来自外部审计数据源的问题。
```
scripts/autofix-aem.mjs
```
—— AEM自动修复引擎（修改EDS项目文件）。
```
scripts/dashboard.mjs
```
—— 生成符合设计风格的仪表盘 +
```
data.json
```
快照。
```
scripts/lib.mjs
```
—— 共享IO + 汇总 + 页面加载 + 自动修复注册工具。

References

参考文档

```
notes/rollout/PLAN.md
```
— design, coverage model, phasing, open questions.
```
reference/delivery-gates.md
```
— Phase C gates + batched-delivery-at-scale flow.
```
reference/dynamic-listings.md
```
— metadata contract + query-index mechanics (B2/D2).
```
reference/multilingual.md
```
— per-language trees (D3).
```
reference/operational-learnings.md
```
— scaled-rollout gotchas (extend, republish, verify).
```
reference/audit-sources.md
```
— the audit-source → layer → fixability → autofix map.
```
reference/checks.md
```
— the
```
rollout:baseline
```
check catalog.
```
skills/stardust/reference/learnings.md
```
— the per-run learnings ledger the report phase writes.
```
skills/migrate/reference/fidelity-tiers.md
```
— the archetype/sibling/thin tier contract Phase C records.
```
skills/migrate/reference/media-reconciliation.md
```
— the image-fidelity resolver's decision table.
```
skills/deploy/SKILL.md
```
— the single-page conversion methodology rollout drives.
```
skills/deploy/da-deploy-protocol.md
```
— the DA Source API transport.

skills/migrate/SKILL.md

— produces the

migrated/

_meta.json

inputs.

```
schemas/*.schema.json
```
— the coverage + config contracts.

```
notes/rollout/PLAN.md
```
—— 设计方案、覆盖模型、阶段划分、待解决问题。
```
reference/delivery-gates.md
```
—— 阶段C检查 + 大规模批量交付流程。
```
reference/dynamic-listings.md
```
—— 元数据约定 + 查询索引机制（B2/D2阶段）。
```
reference/multilingual.md
```
—— 按语言划分内容树（D3阶段）。
```
reference/operational-learnings.md
```
—— 大规模部署的常见陷阱（扩展、重新发布、验证）。
```
reference/audit-sources.md
```
—— 审计数据源 → 层级 → 可修复性 → 自动修复映射。
```
reference/checks.md
```
——
```
rollout:baseline
```
检查目录。
```
skills/stardust/reference/learnings.md
```
—— 报告阶段写入的每次部署经验台账。
```
skills/migrate/reference/fidelity-tiers.md
```
—— 阶段C记录的原型/同模板/简洁层级约定。

skills/migrate/reference/media-reconciliation.md

—— 图片保真度解析器的决策表。

```
skills/deploy/SKILL.md
```
—— rollout调用的单页转换流程。
```
skills/deploy/da-deploy-protocol.md
```
—— DA Source API传输协议。

skills/migrate/SKILL.md

—— 生成

migrated/

_meta.json

输入项的流程。

```
schemas/*.schema.json
```
—— 覆盖范围 + 配置约定。",

rollout

Original

Translation

stardust:rollout — whole site → AEM (Edge Delivery Services)

stardust:rollout —— 全站点部署至AEM（Edge Delivery Services）

When to use

使用场景

Setup

前置准备

Procedure

操作流程

Phase A — Inventory (build the coverage)

阶段A —— 盘点（构建覆盖范围）

defaults: --migrated stardust/migrated --out stardust/rollout

默认参数: --migrated stardust/migrated --out stardust/rollout

archetypes-only mode: add the full page roster from state.json

仅原型模式：从state.json加载完整页面清单

Phase B — Block dedup plan (FIRST-CLASS, before any conversion)

阶段B —— 区块去重规划（核心步骤，在任何转换之前执行）

Phase B2 — Metadata contract for dynamic listings (PRE-IMPORT GATE)

阶段B2 —— 动态列表的元数据约定（导入前检查）

Phase C — Deliver the site (drive deploy per page, per the plan)

阶段C —— 交付站点（按规划逐页调用deploy）

Phase D — Site assembly (whole-site artifacts)

阶段D —— 站点组装（全站点 artifacts）

Phase D2 — Dynamic listings (query-index) — optional

阶段D2 —— 动态列表（查询索引）——可选

Phase D3 — Multilingual (per-language trees) — optional

阶段D3 —— 多语言支持（按语言划分内容树）——可选

Phase E — Full-site verify

阶段E —— 全站点验证

or: --base <url> (explicit host) | --root <dir> (offline, against a local export)

或：--base <url> (指定主机) | --root <dir> (离线模式，针对本地导出内容)

Phase E2 — Link-audit completeness

阶段E2 —— 链接审计完整性

Phase F — Optimize: multi-source audit + gate (delivery quality)

阶段F —— 优化：多源审计 + 检查（交付质量）

Phase G — AEM autofix (close the loop)

阶段G —— AEM自动修复（闭环处理）

Phase H — Report

阶段H —— 生成报告

Phase I — Dashboard

阶段I —— 生成仪表盘

Inputs

输入项

Outputs

输出项

Dependencies (audit sources — referenced, not vendored)

依赖项（审计数据源——仅引用，未内置）

What rollout does NOT do

rollout不负责的事项

Scripts

脚本说明

References

参考文档

Phase C — Deliver the site (drive
`deploy`
per page, per the plan)

阶段C —— 交付站点（按规划逐页调用
`deploy`
）