# KRB WordPress → Webflow Page-Group Migration Plan

**Client/site:** Kincoppal-Rose Bay / Webflow site `6a1e37436b332da28ecc3001` (`krb-rebuild`)

**Goal:** Continue static/page content migration page-group by page-group with fast readback through page-client artifacts where possible, safe edits through Webflow MCP Designer tools where available, and reliable generation of scoped JS when scripted audit/update files are required.

**Operating model:**
- Use page-client / exported page audit scripts for broad readback because they can quickly dump page/component/prop state to structured JSON/CSV.
- Use Webflow MCP Designer tools for actual edits when the MCP bridge is connected and reliable.
- Generate JS only as reviewed, task-scoped files with explicit page/component targets, dry-run/readback support, forbidden-operation checks, and structured verification output. Reference: `/Users/iggy/.hermes/profiles/ignite_team/skills/ignite-company-knowledge/krb-webflow-mcp-page-migration/references/js-generation-plan.md`.
- Treat every page as read-before-write, smallest safe write, readback verification.
- Do not publish. Do not delete. Do not use generic bulk booleans or guessed prop shapes.

---

## 0. Known current MCP state

Last checked via MCP:

- Site: `Kincoppal-Rose Bay`
- Site ID: `6a1e37436b332da28ecc3001`
- Current Designer page: `Our People`
- Current page ID: `6a2b903289294179fd567656`
- Parent group: `About Us`
- Designer mode: `design`
- Branch: `null` / not on a branch
- MCP can read page elements and component instance props.

---

## 1. Page-group scope and source-of-truth files

For About Us, use these existing local artifacts first:

- Source content:
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-source-content.json`
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-live-wp-scrape-summary.json`
- Prior readback/audit helpers:
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-current-page-readonly-prop-audit-v2.js`
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-page-client-audit.zip`
- Prior generated write references, for mapping only unless explicitly chosen:
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-strict-current-page-content-v3.js`
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-full-page-group-import-v7.js`
- Asset/image references:
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-gallery-image-manifest.json`
  - `/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-image-grab/krb-webflow-other-static-images-uploaded-to-webflow.csv`

Do not regenerate these unless necessary. If updated files are uploaded later, treat the newest user-supplied artifact as source of truth.

---

## 2. Fast readback workflow

### 2.1 Discover page group pages

Use MCP Data API first:

1. `data_pages_tool.list_pages(site_id)`.
2. Filter pages with parent folder/page `About Us`, or slugs matching known About Us source pages.
3. Record: page name, slug, page ID, draft status, parent ID.

Expected About Us pages include at least:

- About Us
- Principal's Welcome
- Our People
- Our History
- Our Policies
- Our Campus

Confirm exact list from Webflow before writing.

### 2.2 Read current Webflow page state

Preferred quick readback order:

1. If current page is open in Designer, use MCP Designer directly:
   - `de_page_tool.get_current_page`
   - `element_tool.query_elements` for component instances
   - `de_component_tool.get_component_instance_props` for suspicious or targeted instances
2. For broad page dumps, use page-client audit output/scripts if they can be run faster than MCP one-by-one.
3. For each page, capture a compact JSON record:
   - page ID/name/slug
   - ordered component instance list
   - component names
   - prop labels/current values/override state
   - slot children component names and prop labels/current values
   - obvious placeholders/defaults (`Heading`, `subtitle`, lorem ipsum, blank rich text, hidden sections)

### 2.3 Compare against WordPress source

For each page:

1. Load source content from `krb-about-us-source-content.json`.
2. Compare page title, intro, main rich text, section headings, CTAs, gallery images, and repeated cards/people/policy links.
3. Classify each component instance:
   - `complete`
   - `missing-content`
   - `default-placeholder`
   - `hidden-but-needed`
   - `extra-starter-content`
   - `needs-image`
   - `unclear/manual-review`

Output a short page checklist before editing.

---

## 3. Edit workflow with Webflow MCP

### 3.1 Guardrails before every write

- Confirm the correct page is open/switch to it via MCP.
- Read the target component props immediately before writing.
- Use prop labels/types from readback; do not infer IDs from old scripts if MCP readback gives current IDs.
- Update only the specific prop/element required.
- For booleans, confirm the semantic label: e.g. `Hide section` means `false` to show, while `Show X?` means `true` to show.
- For nested/slotted content, write to the slotted child component instance that owns the prop, not the parent.
- Skip image props unless the accepted asset value shape is proven for that component/prop. Prefer text/visibility first.

### 3.2 Preferred MCP edit tools

Use in this order:

1. `mcp_webflow_de_page_tool.switch_page` — navigate to target page.
2. `mcp_webflow_element_tool.query_elements` — locate component instances by type/component name/text/default values.
3. `mcp_webflow_de_component_tool.get_component_instance_props` — inspect prop IDs and value types on exact instance.
4. `mcp_webflow_de_component_tool.set_component_instance_prop_values` — set text/boolean/number/link/richText props where value shape is clear.
5. `mcp_webflow_component_builder` — only if a required component instance is missing and should be inserted.
6. `mcp_webflow_asset_tool` / existing asset CSV — only for image asset checks or uploads.

### 3.3 Minimal write unit

For each component instance:

1. Record before state.
2. Apply one logical component update: e.g. heading + paragraph + visibility for one Text Content section.
3. Re-read the same instance.
4. Mark outcome:
   - `updated-and-verified`
   - `already-correct`
   - `skipped-unknown-shape`
   - `failed-with-error`

Do not run a page-wide script unless it is a reviewed/generated MCP-compatible plan and the page-level diff is clear.

---

## 4. Verification workflow

After each page:

1. Re-run page readback for all component instances.
2. Confirm no obvious placeholders remain unless intentionally hidden:
   - headings equal `Heading`
   - eyebrow equals `subtitle`
   - lorem ipsum paragraphs
   - blank rich text with visible section
   - required sections still hidden
3. Check key source strings from WordPress exist in Webflow props.
4. If image/gallery work was done, verify asset ID/name and prop readback.
5. Optional visual spot check through MCP element snapshot for hero/main section if available.
6. Write a page status note locally with:
   - page ID
   - components changed
   - fields changed
   - skipped/manual-review items
   - verification result

---

## 5. About Us page-group execution order

Recommended order:

1. **Our People** — already open; use as the MCP pilot page.
2. About Us index page.
3. Principal's Welcome.
4. Our History.
5. Our Policies.
6. Our Campus.
7. Any extra About Us children discovered by `list_pages`.

For each page, follow:

```text
switch/open page → read current state → compare source → prepare targeted edits → apply MCP writes → read back → note status
```

---

## 6. Autonomy rules

I can proceed autonomously when:

- The source content is already present in local KRB artifacts.
- The target Webflow page/component/prop is unambiguous.
- The write is non-destructive and limited to component props/elements on the open KRB site.
- Verification readback proves the change.

Pause and ask Sylvain when:

- A source section does not map cleanly to an existing component.
- A required component is missing and adding a new instance may alter layout.
- Image/asset prop shape is not proven.
- Existing Webflow content conflicts with WordPress source in a way that looks intentional.
- Any publish/delete/redirect/global style/site setting action would be required.

---

## 7. Reliable JS generation workflow

Use this when a required audit/update step is faster or safer as a generated JavaScript file than as one-off MCP calls.

1. Read the source content artifact and current Webflow readback/audit artifact.
2. Produce a page-by-page diff: source content, current Webflow prop values, placeholders, missing values, and uncertain mappings.
3. Split the work into:
   - read-only audit JS, and
   - separate write JS only for confirmed safe, narrow updates.
4. At the top of every generated JS file declare:
   - expected site ID,
   - page group,
   - target page IDs/slugs,
   - mode (`read-only`, `dry-run`, or explicit write),
   - generated timestamp and source artifacts used.
5. Build in hard safety checks:
   - no publish/delete/global style/site setting/redirect operations,
   - no guessed prop IDs or broad boolean flips,
   - skip-with-warning for missing/ambiguous component targets,
   - idempotent writes where possible.
6. Log structured results: pages inspected, components inspected, proposed/applied changes, skipped items, warnings, errors, and verification checks.
7. Save generated files under `/Users/iggy/.hermes/profiles/ignite_team/outbound/` with a versioned descriptive filename and a short notes file.
8. If Sylvain needs to test externally, create a `.zip` containing only the current JS/notes files.

Detailed reference:

`/Users/iggy/.hermes/profiles/ignite_team/skills/ignite-company-knowledge/krb-webflow-mcp-page-migration/references/js-generation-plan.md`

---

## 8. Working log format

Create/update a local status file per run, e.g.:

`/Users/iggy/.hermes/profiles/ignite_team/outbound/krb-about-us-mcp-run-status.md`

Use this format:

```markdown
# KRB About Us MCP Migration Status

## Page: Our People
- Webflow page ID:
- Source URL:
- Audit timestamp:
- Components checked:
- Changes made:
- Verification:
- Skipped/manual review:

## Page: ...
```

Final Slack updates should be concise: pages completed, changes verified, blockers/manual review, and next page.