Rp Website Continuation

Use this resource only when the orchestration router returns nextResource: resources/rp-website-continuation/. The router dispatches it only for deliveryMode=website or deliveryMode=management_and_website; a management run, including an explicit editorWebsiteDecision=management_only, never enters this resource.

Contract

Editor destinations. When targetSiteType is studio or harmony, there is no supported automatic website migration: never invoke wix-headless-replatform, never scaffold frontend/, and never publish the site. The router reports editor_website_handoff_outstanding; keep the website obligation outstanding as the completion report’s editor_website_unfinished / editor_publication_outstanding operator actions (site owner/designer, then Cutover Operator) and do not claim combined completion until a valid released website/completion.json exists for the bound site.

For deliveryMode=website, this is a frontend-only run — but it still needs a destination, and that destination is still rp-destination‘s job, not this skill’s or wix-headless-replatform‘s. Do not let wix-headless-replatform scaffold its own site here: its only safeguard against a duplicate is “does a local folder already have a package.json,” which is not the same account-confirmation gate, WIX_SITE_ID persistence, and dashboard-URL report that every other delivery mode gets.

1. Resolve the destination via rp-destination first, scaffolding into <projectDir>/frontend with --site-template blank (there is no backend catalog to provision for, and this matches wix-headless-replatform‘s own default template choice for the home-scope clone this invocation performs). Persist WIX_SITE_ID in config/wix.env and report the dashboard URL, same as any other mode.
2. Then invoke wix-headless-replatform with the source URL and --out <projectDir>/frontend; do not run backend discovery, mapping, setup, or import. Because <projectDir>/frontend already contains a valid scaffold from step 1, wix-headless-replatform‘s own standalone reuse check finds it and continues from there instead of scaffolding a second site.

Finish its build and gap loop. Only when the user explicitly requested facelift at intake, run the separate post-clone UI/UX Pro Max facelift and acceptance review; otherwise do not load that stage. Then release and write website/completion.json with finalize-migration-website.mjs --project-dir <projectDir> --out <projectDir>/frontend --release-url <public-url>.

execution/completion-report.json means backend import accounting. It is not the terminal result of a deliveryMode=management_and_website migration.

Two different documents, two different jobs. website/handoff.json is the backend-to-frontend package: a website build needs its bindings contract before it starts, so it keeps being produced when it is, from the plan. It is not the run’s account of the migration. That is execution/review/migration-handoff.md, generated after the last write from execution/completion-report.json — never hand handoff-summary.md to anyone as the account of what the migration did.

The freshness check composes with this: once the backend import writes its completion report, liveImportSummary or recoveryLog, the recorded fingerprint moves and the router returns stale_website_handoff, forcing the package to be regenerated from the finished run before the frontend build consumes it.

When the route reason is missing_website_handoff or stale_website_handoff, first run node skills/wix-replatform/scripts/website-handoff-generate.js <projectDir> and route again. Otherwise load the current website/handoff.json, then invoke wix-headless-replatform in migration mode via its --handoff flag:

node scripts/site-clone.mjs <source-url> --handoff <projectDir>/website/handoff.json

--handoff is required here, not optional. It is the only thing that puts wix-headless-replatform into migration-phase mode; without it the skill falls back to standalone mode and unconditionally scaffolds and executes a new @wix/new headless call — a second, orphaned site, which is exactly the failure “never create a second destination site” (see rp-destination) exists to prevent. Continue its actual build, post-build gap analysis, bounded fix loop, and release sequence. Do not stop after implementation or a successful build.

The frontend skill must atomically write website/completion.json before this resource can finish. A successful receipt has the current handoffFingerprint, completed screenshot review, zero unresolved critical/high gaps, and a released (or explicitly not-applicable) release state.

If a genuine blocker remains after required 1-click recovery/escalation retries, persist a status: "blocked" receipt with the blocker code, evidence, attempted recovery, owner, and exact unblock action. Then route again. Do not describe a pending storefront as a completed migration.

After the gap loop has passed and the storefront is released, write the receipt with:

node skills/wix-headless-replatform/scripts/finalize-migration-website.mjs \
  --handoff <projectDir>/website/handoff.json --release-url <public-url>