migrate

Run the migrate skill after extraction, direction, and prototyping are complete. It renders each inventoried page through one of three branches (approved prototype, template-applied sibling, or unique render) and writes a self-contained static HTML bundle under stardust/migrated/.

Each page is sha-compared across DESIGN.md, DESIGN.json, source content, proposed files, canon files, and archetype sources. Pages whose hashes all match are skipped and reported as unchanged; only edited inputs trigger re-renders.

Yes. All internal references are rewritten to depth-aware relative paths with explicit index.html targets, so the bundle works on file://, at a webserver root, or at any subpath. Phase 3 portability audits verify this with grep checks and a headless file:// round-trip.

Migration refuses the page. The placeholder gate blocks any page with data-placeholder elements or non-empty unsourced content lists, and there is no bypass flag. The user must source the real content and re-invoke migrate.

No. The output is platform-agnostic static HTML only. Downstream conversion to AEM EDS, a CMS payload, or framework components is the job of a separate plugin that consumes the migrated tree plus DESIGN.json and the per-page _meta.json sidecars.

Every in-scope page must carry live-render evidence in its state record. Pages synthesized without real extraction fail validateProvenance and abort the run, because migrating them would produce HTML that misrepresents the source site.