/replica

name: replica
description: Same-design migration — re-platform a site to AEM Edge Delivery (or any clean front end) keeping its current design near pixel-perfect. Recreates key pages (one archetype per page type) as clean re-authored HTML/CSS (never DOM copies), verifies each against the live site with a measured source-fidelity gate (structural diff + visual diff + stitched pixel diff per breakpoint), then hands off to migrate/deploy/rollout for site-wide delivery with reusable blocks. The only permitted design changes are entries in an explicit inconsistency register. Use when the user says "migrate this site keeping its current design", "same-design migration", "pixel-perfect replatform to AEM", "rebuild the site exactly as it is but clean", or "keep the design, change the platform". NOT for redesigns — a new or refreshed design is the stardust core pipeline (direct/prototype) or uplift.
license: Apache-2.0

stardust:replica — same-design migration

Same pages, same content, same design — new platform. `replica` migrates a site to AEM Edge Delivery (or just re-platforms its front end) keeping the current design **near pixel-perfect**: the target spec IS the captured current state, the only permitted deltas are the entries of an explicit **inconsistency register**, and every archetype must pass a **measured source-fidelity gate** against the live site before anything ships.

Two properties make this a different animal from the redesign pipeline:

1. **No creative decisions.** The direction step is mechanical promotion of the captured spec — `stardust:direct` is never invoked. Every judgment call in a replica run is a *measurement-policy* call, not a taste call. 2. **Recreation, not copying.** Archetypes are authored as clean semantic HTML/CSS from captured content + values lifted from the source site's own CSS — never DOM copies, never ported page-level stylesheets. Fidelity is proven by instruments, not asserted by construction.

Validated end-to-end (aesop.com home, 2026-07-03): 8.31% → 2.93% → **1.31%** pixel diff in 3 measured iterations, height Δ 0, content-diff "findings: none" (198/198 nodes). Every fix came off the instruments, never off eyeballing.

Inputs

• `<URL>` — required. The site to migrate.
• `--breakpoints <list>` — optional. Gate breakpoints, default `1440,360`.

Mobile is NOT free: the validation run's 1440-tuned prototype measured 24% at 360. Each breakpoint gets its own gate pass.

• `--register <file>` — optional. User-supplied inconsistency items to seed

the register (see Phase 2). Without it and without an audit, the register is empty — a pure replica.

Setup

1. Run the master skill's setup (`../stardust/SKILL.md` § Setup): context loader, state read. 2. Verify Playwright is importable from the project root (extract needs it; so do the gate scripts). 3. Install the gate's pixel deps in the project: `npm i -D playwright pixelmatch pngjs --no-save --legacy-peer-deps`. Same trap as diff's prereq 0: a `--no-save` install is PRUNED by any later real `npm i` — re-probe before every gate run (`node -e "import('pixelmatch').then(()=>process.exit(0))"`). 4. Copy scripts into the project and run them from there, not from the plugin: this skill's `scripts/` (stitch-shot.mjs, pixel-compare.mjs) AND the whole `../diff/scripts/` dir (the diff scripts import diff-profiles.mjs, and ALL live-target hardening — including stitch-shot's — lives in its live-session.mjs; stitch-shot resolves it from `scripts/diff/` next to `scripts/replica/`, so keep the two dirs siblings).

Procedure

Five phases. Phases 1 and 5 delegate to existing skills unchanged; phases 2–4 are owned by `replica`.

Phase 1 — EXTRACT (delegate to `stardust:extract --prep`)

Invoke `stardust:extract <URL> --prep`, unchanged. Prep mode is required — replica consumes the full migration inventory, not the discovery cap:

• `stardust/current/pages/<slug>.json` — per-page structure + content

(verbatim source of every string the prototypes will carry).

• `stardust/current/assets/screenshots/` — per-page captures (ground truth

for recreation, alongside the gate's own stitched shots).

• `stardust/current/assets/` — fonts (network-intercepted woff2), logo, media.
• `stardust/current/PRODUCT.md`, `DESIGN.md`, `DESIGN.json` — the descriptive

current state (Phase 2 promotes these verbatim).

• `state.json.pages[].type` — page types (each becomes one archetype).
• `DESIGN.json.extensions.modules[]` — module candidates (become blocks).

**Bounded/single-page entry (one-page or pilot runs).** `--prep` is the site-wide contract; it is NOT the only way in. When the ask is "replicate just this page" — or the user wants to pilot one archetype before committing to a full migration — invoke `stardust:extract <URL> --single` (or `--pages <slug,...>` for a short list) instead. This is a first-class entry, not an improvisation: the recreation phase needs, per page, the captured page JSON (verbatim content), the per-page screenshot (ground truth), and the captured fonts — all of which a bounded extract provides; the source-CSS harvest and per-breakpoint computed styles come from Phase 3's CSS lifting either way. What a bounded run skips is the prep-only inventory (page typing, module detection), which is only needed when Phase 5 fans out to siblings — a pilot that later grows to site scope re-runs Phase 1 with `--prep`. **A bounded run also skips the descriptive synthesis**: crawl.mjs alone writes `pages/<slug>.json`, screenshots, and `_crawl-log.json` — it does NOT produce `current/PRODUCT.md` / `DESIGN.md` / `DESIGN.json`, so Phase 2's verbatim promotion has nothing to promote. On this path Phase 2 takes the **bounded promotion branch** instead (`reference/preserve-direction.md` § 1a): replica synthesizes a minimal descriptive target spec from the captured page JSON + the Phase-3 CSS lift, marked `provenance: bounded-single`.

Extract's failure modes