# Fv CMS Pipeline Vision **Restored 2026-07-17** by Mavis, from operator's spoken description in session 415655444668635. This is the canonical vision doc for the FvRE → static dist → FES → Dev button flow. For the multi-horizon strategic plan, see `freshvibe-worldclass-plan.md` in the FvRE pact. For the FreshVibe Way V8 doctrine (the rules every artefact must follow), see `freshvibe-way-v8/`. --- ## What the operator is building **The pipeline**: take any website (typically WordPress, but any page-builder works), capture it pixel-perfect as a static HTML dist, attach a CMS layer on top, ship it to a `*.freshvibeapps.com` subdomain. The site becomes editable live in the browser. **The operator (G) and the cycle they want**: 1. The operator gives Mavis a URL (e.g. `oscarstreeacademy.org.uk`). 2. Mavis runs the FreshVibe Reconstruction Engine (FvRE) directly against the live site. FvRE navigates the site like a real browser, scans every page, and extracts every region + widget + its data-settings. 3. FvRE produces a static dist + an `annotation.json` (regions + modules + their data-settings). 4. The dist preserves the **original framework tags** (`data-widget_type="eael-post-carousel.default"`, `data-settings="{...}"`, `data-id="..."` from Elementor / Bricks / etc.). These tags matter — they're the signal that tells the Frontend Editing System (FES) what was used to build the page. 5. FES takes the annotation + the dist and produces **canonical freshvibe-native modules** — one per widget archetype. If a widget is a slider with only 1-2 images captured, FES builds a robust slider module the operator can fully control: add more slides, change effects, reorder, etc. FES is told to **fill in gaps and make it world-class**. 6. The dist is shipped to a subdomain (e.g. `oscar-web.freshvibeapps.com`) as a static site. 7. The site loads with a `{ }` Dev button in the corner. 8. Pressing the Dev button enters **CMS overlay mode** — like Elementor's editor. 9. In overlay mode, the page shows **region tags** (yellow/brown) and **widget sub-tags** (purple) on every editable thing. 10. Click a region → a **region panel** opens in the dock (left or right edge), with controls for background, gradient, parallax, padding, columns, etc. 11. Click a widget sub-tag → a **module panel** opens with the **operator control panel** for that module — the form fields generated by FES, edit any field, save → live DOM patches in place. 12. The original page-builder nesting is preserved and editable: section > column > widget, all clickable, all editable. > **Note**: if the source site blocks FvRE's crawler (Cloudflare bot protection, captcha, rate-limiting), the operator can grab a `.wpress` export of the WordPress site from their own logged-in browser and drop the file into the Mavis sandbox. FvRE ingests the file offline. This is a workaround, not a normal pipeline step — see the section below. ## What the operator expects when they press Dev - **Regions visible as outlines on the page** — every region shows its label and a clickable handle. - **Widgets visible as sub-tags inside their region** — small clickable handles on every widget. - **Click a region** → region panel opens in the dock, with background, gradient, parallax, layout, column config. - **Click a widget** → widget panel opens, showing the operator control panel for that module (the form fields the FES generated for it). - **Edits apply live** — no save button, no reload, just patch the live DOM in place. Undo is available. - **Multiple panels can be open simultaneously** — chip in the dock per panel. - **Panels can be minimized to chips** — chip stays in the dock, panel body hidden. - **Panels can be closed entirely** — chip disappears. - **Dev button toggles everything** — press again, all chips disappear, all panels hide, back to plain site. - **Mobile behavior** — only one panel visible at a time (panels switch), but chips stay in the dock for fast access. ## The conversion arc (current active build) The pipeline G is actively running. The **canonical** path is direct-from-URL: - **Any live website URL** (typically WordPress + Elementor, but any page-builder works) → **FvRE scans it directly** - FvRE produces: `annotation.json` + `dist/` HTML + relationship graph - FES processes each widget → **canonical module** (3-tab inspector: Settings / Style / Advanced; 17 WCP primitive types) - **freshvibe-cms chrome** is adopted as the runtime editor layer - **Deploy** to `*.freshvibeapps.com` (nginx vhost + PB deployments-table registration per FRESHVIBE_DEPLOY_CONTRACT.md) - **Operator eyeballs** by pressing `{ }` on the live site ### The `.wpress` workaround (NOT a normal pipeline step) The `.wpress`-import step is a **sandbox workaround** for sites that block automated crawlers (Cloudflare bot protection, rate-limiting, IP blocks). It's not a stage of the canonical pipeline. **Why it exists**: some hosts detect Playwright/headless crawlers and either kick the crawler out, return captcha walls, or rate-limit so hard that the crawl can't complete. The `.wpress` workaround is: take a real WordPress `.wpress` export (via the operator's logged-in browser, in their own sandbox) and drop the file into the Mavis sandbox. FvRE then ingests the file offline. **The proof it works**: the canonical reference implementation (Oscar's Tree Academy) was originally captured via `.wpress` because the live host was hostile to crawlers at the time. We've since proved FvRE can scan the same kind of site directly when the host cooperates. So the canonical path is "any website URL → FvRE scans it"; the `.wpress` step is the fallback for when the host doesn't cooperate. For most people, the canonical path is what they use. The `.wpress` path is the safety valve. Sites that have been through this (all via the canonical path except where noted): - `oscar-web.freshvibeapps.com` (Oscar's Tree Academy — originally via `.wpress` workaround, has been re-verified via direct scan) - `oscar-platform.freshvibeapps.com` (the Oscar AI app) - `gallery.freshvibeapps.com` (FV gallery — second WP conversion, deployed yesterday, has portal registration gap) - `hopfan.freshvibeapps.com` (also previously converted) ## What's separate from this arc **Standalones** (FreshCards, VibeCoder, VibeScope) are a **separate** arc. They were built native, not converted from WordPress. They live at `freshcards.freshvibeapps.com`, `vibecoder.freshvibeapps.com`, `vibescope.freshvibeapps.com`. They are world-class on their own; the conversion pipeline's Dev-button chrome is not adopted into them. **Studio** (FreshVibe Studio) is **paused** per operator directive 2026-07-15 + 2026-07-17. The standalones are the active build. Studio may be redone, or look different when we come back. Don't re-propose Studio work. ## The 5 layers, in the order they apply | Layer | Repo | What it does | Status | |---|---|---|---| | FvRE | `avidtech6/freshvibe-reconstruction-engine` | Pixel-perfect WP → static dist with preserved tags | A–G complete, H (static-build) active | | FreshVibe Way V8 | `pact/vision/ideanet` + `freshvibe-way-v8/` | Constitutional rules (8 mandatory artefacts, anti-drift, modules-as-clusters) | v8 locked | | FES + WCP | `avidtech6/freshvibe-fes` (NOT YET PUSHED — lives in `/workspace/fvsf-fes/`) | FES worker turns widget config → canonical module spec; WCP catalog = 20 primitives | 21/24 modules generated, Inspector UI demo built | | freshvibe-cms chrome | `avidtech6/freshvibe-cms` | 6 fragments (outline, navigator, inspector, breadcrumb, context-menu, selection) + panel manager | canonical spec done, partial impl in Oscar-web's `oscar-*` fragments | | Deploy | VPS at 185.249.73.178 | nginx vhost + PB registration per `FRESHVIBE_DEPLOY_CONTRACT.md` | works for happy path, has gaps (gallery needs fix) | ## What "FES produces canonical modules" actually means When FES sees an `eael-post-carousel.default` widget with the data-settings `{slides_per_view: 3, autoplay: true}`, it produces a module spec like: ```json { "moduleType": "M-card-list", "fieldSchema": { "slides": "repeater", "autoplay": "boolean", ... }, "inspector": { "Settings": [ ... 4 controls ... ], "Style": [ ... 9 controls, 9 WCP primitives ... ], "Advanced": [ ... 4 controls ... ] } } ``` The module spec becomes the **operator control panel** the operator sees when they click a widget in Dev mode. The FES doesn't just replicate the original — it **fills gaps** (slider with 1 image gets a robust 6+ image editor with reorder, effects, etc.) and **makes it world-class** (parallax, hover effects, mobile-responsive controls). ## The 3 horizons (per `freshvibe-worldclass-plan.md`) - **Horizon 1 — Markers + Inspector (this quarter)**: tags ship in Stage 1, Inspector ships as a generic overlay, dev-only. - **Horizon 2 — Stage 2 CMS Core (next quarter)**: registry, override store, editor UIs. Sites become editable live. - **Horizon 3 — Studio Integration (Horizon 2+)**: Inspector in Studio preview, CSF Editor linkage, universal modules. **PAUSED.** ## What the operator wants to see next (today, 2026-07-17) Per the conversation that produced this doc, the next step is: 1. **Verify the Oscar-web dist works today** — open the live site, press `{ }`, walk through the dev flow, document gaps 2. **Compare to the canonical spec** — freshvibe-cms pact says what should work, Oscar-web dist says what does 3. **Decide the scope** — bridge gaps in Oscar-web, or adopt canonical freshvibe-cms 4. **Deploy + eyeball** — replace Oscar-wp on the VPS, operator activates Dev mode, gives feedback ## Why this doc exists The operator has the vision in their head. It has been said in fragments across many prompts, but it has never been written down as a single canonical artifact. This is that artifact. If you're a future Mavis session reading this: **the vision is the operator's, not yours**. Your job is to make the conversion pipeline + Dev-mode editing flow work exactly as described above. If you find yourself doing something else, stop and ask.