build(www): deploy the hosted editor from this repo on Vercel

.claude/skills/maintain/SKILL.md

@@ -109,6 +109,10 @@ packages/www/package.json
 
 The release builders **reject** a tag whose version does not match every one of these.
 
+### 1a. The Bun version is pinned in two places
+
+`packageManager` in the root `package.json` (`bun@1.3.11`, with `engines.bun`) and the `bunx bun@1.3.11` install and build commands in `packages/www/vercel.json`, which is what the hosted web app builds with. `bun run bump` touches neither. Change them together, or Vercel builds with a different Bun than CI.
+
 ### 2. The open-source boundary gate
 
 `bun run check:open-source` (`scripts/check-open-source-boundaries.ts`) is an **architecture test, not a lint**. It fails the build on forbidden strings in `packages/{core,figma,wp,www}/src`, `packages/wp/wp`, and — in CI — the built `packages/figma/dist` and `packages/wp/dist`:

.claude/skills/release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release
-description: How core-framework ships, and the agent's operating procedure around it. Covers the three distinct release paths — the WordPress plugin (tag-driven, deployed to WordPress.org over SVN), the Figma plugin (packaged by the same tag but published to Figma Community by hand), and the web app (a static bundle this repo does not deploy at all) — plus what must be true on main first, which single version constant drives all ten pinned files, what the tag workflow does automatically, and which steps are irreversible and therefore need David's explicit go-ahead. Use this skill when cutting a release in core-framework, when preparing main for one, when a tag or publish is being considered, or when working out whether a change has actually shipped.
+description: How core-framework ships, and the agent's operating procedure around it. Covers the three distinct release paths — the WordPress plugin (tag-driven, deployed to WordPress.org over SVN), the Figma plugin (packaged by the same tag but published to Figma Community by hand), and the web app (deployed by Vercel to alpha.coreframework.com, the iframe behind coreframework.com/app, on every merge to main, with no tag involved) — plus what must be true on main first, which single version constant drives all ten pinned files, what the tag workflow does automatically, and which steps are irreversible and therefore need David's explicit go-ahead. Use this skill when cutting a release in core-framework, when preparing main for one, when a tag or publish is being considered, or when working out whether a change has actually shipped.
 ---
 
 # Releasing core-framework
@@ -9,17 +9,24 @@ description: How core-framework ships, and the agent's operating procedure aroun
 
 > **Cutting a release is David's decision, never inferred.** Do not bump, tag, or publish because a change looks finished, because CI is green, or because the changelog has entries. Ask.
 
-## Three release paths, one tag
+## Three release paths
 
-They share a version and a trigger but end in different places on different cadences. Never merge them into one narrative — the wrong one gets run.
+The two plugins share a version and a tag trigger; the web app ships on every merge. They end in different places on different cadences. Never merge them into one narrative — the wrong one gets run.
 
 | Artifact | Trigger | Destination | Automated? |
 |---|---|---|---|
 | **WordPress plugin** | push tag `v*.*.*` | WordPress.org (SVN) + GitHub Release | fully |
 | **Figma plugin** | push tag `v*.*.*` | GitHub Release ZIP only | packaging only |
-| **Web app** (`www`) | — | static `packages/www/dist` | **not deployed by this repo** |
+| **Web app** (`www`) | merge to `main` | Vercel `core-bunch/core-framework` → alpha.coreframework.com | fully, by Vercel's Git integration |
 
-**The web app has no release path here.** No workflow builds or deploys it; `README.md:210` describes it as a static bundle to serve from any host. Hosting lives outside the repository, so "released" for www means whatever the external host does. Do not claim a www change has shipped on the strength of a tag.
+**The web app deploys on merge, not on tag.** coreframework.com/app (private repo `OxyNinja/CoreFramework.com`) embeds the editor in an iframe from `https://alpha.coreframework.com/`. That domain is the Vercel project `core-framework` in the `core-bunch` team, connected to `CoreBunch/Core-Framework` on `main` with Root Directory `packages/www`. The build settings are in `packages/www/vercel.json` (`RELEASING.md` → *Web app*). So:
+
+- **Merging a PR that touches `packages/www` or `packages/core` is the web-app release.** Treat merging as outward-facing for www: it reaches every coreframework.com/app user within minutes. A tag changes nothing there.
+- **The live version string lags.** The app shows `APP_VERSION` from `main`, which only moves on `bun run bump`, so merged-but-unreleased changes run under the previous number.
+- **The embed messages are a cross-repo contract.** The website sends `cf-embed-load-preset`, `cf-embed-load-preset-default`, `cf-push-response` and `cf-read-clipboard`, and the editor sends `cf-ready`, `cf-push`, `cf-copy-to-clipboard` and `cf-read-clipboard`. Renaming one breaks the hosted editor on the next merge.
+- **Dashboard changes are David's.** Reconnecting Git, changing the Root Directory or build settings, redeploying, promoting or rolling back in Vercel: describe the steps, never run them.
+
+On 2026-09-26 the project was found still connected to the old private repo `OxyNinja/core-framework`, serving 1.10.4. If the live bundle reports an old version, check the project's Git connection before anything else.
 
 **Figma Community publishing is manual and separate.** The tag packages `core-framework-figma-X.Y.Z.zip` and attaches it to the GitHub Release, but does not touch Figma Community. That is a maintainer action through Figma Desktop (`RELEASING.md` → *Figma Community publishing*). A tagged release therefore leaves Figma Community users on the old version until David publishes. Say so rather than implying the release is complete.
 
@@ -76,3 +83,4 @@ Reverting means shipping a *new, higher* version. Plan accordingly.
 - The GitHub Release carries **both** `core-framework-X.Y.Z.zip` and `core-framework-figma-X.Y.Z.zip`.
 - The `publish` job succeeded — a green `verify` alone means nothing shipped.
 - Figma Community still shows the old version until David publishes by hand. Report that as outstanding, not done.
+- The web app: fetch `https://alpha.coreframework.com/`, take the `assets/index-*.js` it loads, and search it for the expected `APP_VERSION` (for example `curl -s https://alpha.coreframework.com/assets/index-XXXX.js | grep -o '"2\.[0-9]*\.[0-9]*"'`). The Vercel deployment for the merge commit must be green on GitHub. This lands on merge, not on tag.

.claude/skills/run-and-test/SKILL.md

@@ -65,6 +65,12 @@ Jest with coverage, 23 suites / 147 tests, about 4s. This is the **only** automa
 
 Build is `tsc && vite build` — the type-check is part of the build, so a change that runs in dev can still fail `build:www`.
 
+### The hosted build and the embed
+
+Vercel builds the hosted editor from `packages/www/vercel.json` (see `release`). To reproduce it exactly, run its two commands from `packages/www` in a clean checkout: `bunx bun@1.3.11 install --frozen-lockfile`, then `bunx bun@1.3.11 run build`. Install works from the package directory because bun resolves the workspace root and its `bun.lock`.
+
+coreframework.com/app runs the editor inside an iframe, which switches on the embed code paths (`isEmbed()`: save posts `cf-push` to the parent instead of writing `localStorage`). A plain `dev:www` tab never exercises them. To test them, serve a small host page on another port that iframes `http://localhost:5173/` and plays the website's side: answer `cf-ready` with `cf-embed-load-preset` (`{ preset: <JSON string>, isViewOnly }`) or `cf-embed-load-preset-default`, answer `cf-push` with `cf-push-response` (`{ success }`), and answer `cf-read-clipboard` with `{ type: "cf-read-clipboard", text }`. The website's side lives in the private repo `OxyNinja/CoreFramework.com`, `src/pages/app/[slug].tsx`.
+
 ## packages/wp — the WordPress plugin
 
 ### PHP tests, and the trap that makes them look broken
@@ -132,6 +138,8 @@ bun install --frozen-lockfile
 
 You only need to copy `packages/wp/.env` (gitignored) if you intend to run `dev:wp` against a local WordPress from the worktree.
 
+**The first `build:wp` in a fresh worktree fails.** With no `packages/wp/.env`, its `env:prod` step creates one (`APP_ENV='development'`), prints "Please, start project again." and exits 1. Run `build:wp` a second time and it passes. `check:open-source` then needs the `wp` and `figma` builds to exist: it fails with `ENOENT ... packages/figma/dist` if they have not been built in this checkout.
+
 ## The verification gate
 
 Run this **once, at the end**, not after every edit. Capture exit codes directly — piping into `tail` or `grep` reports the pipe's status and will show green over a failed build.

README.md

@@ -217,6 +217,8 @@ bun run --filter './packages/www' build -- --base=/core-framework/
 
 Then publish `packages/www/dist` at the matching path, such as `https://example.com/core-framework/`.
 
+The hosted editor at [coreframework.com/app](https://coreframework.com/app) deploys from `main` of this repository on Vercel, using [`packages/www/vercel.json`](packages/www/vercel.json). See [RELEASING.md](RELEASING.md#web-app).
+
 ## WordPress development
 
 Requirements: WordPress 6.6 or newer, PHP 8.0 or newer, Composer, Bun 1.3.x, and a local HTTPS certificate.

RELEASING.md

@@ -1,6 +1,6 @@
 # Releasing Core Framework
 
-Core Framework uses a tag-driven release process. A push to `main` never publishes a WordPress or Figma update.
+Core Framework uses a tag-driven release process for the WordPress and Figma plugins. A push to `main` never publishes a WordPress or Figma update. It does deploy the web app; see [Web app](#web-app).
 
 ## Release flow
 
@@ -44,6 +44,18 @@ The GitHub Release contains:
 - `core-framework-X.Y.Z.zip` for WordPress and WordPress.org deployment.
 - `core-framework-figma-X.Y.Z.zip` for a self-contained local Figma installation.
 
+## Web app
+
+The hosted editor at [coreframework.com/app](https://coreframework.com/app) is not versioned by tags. The website (a separate, private repository) embeds it in an iframe from `https://alpha.coreframework.com/`, and that domain is served by the Vercel project `core-framework` in the `core-bunch` team.
+
+- **Source:** the `CoreBunch/Core-Framework` repository, branch `main`.
+- **Root Directory:** `packages/www`. The build settings live in [`packages/www/vercel.json`](packages/www/vercel.json): install with `bun install --frozen-lockfile`, build with `bun run build` (`tsc && vite build`), and serve `dist`. Both commands run Bun 1.3.11 through `bunx`, the version in the root `packageManager` field; change the two together.
+- **Trigger:** every merge to `main` deploys to production. Pull requests get preview deployments. With the project's **Skip deployment** setting on, Vercel skips commits that change nothing `packages/www` depends on (it reads the `@core-framework/core` workspace dependency).
+
+The editor shows `APP_VERSION` from `main`, so between releases it runs merged, unreleased changes under the last released number. To check what is live, fetch the page, find the `assets/index-*.js` bundle it loads, and search that bundle for the version string.
+
+The website and the editor talk through `postMessage`. The website sends `cf-embed-load-preset`, `cf-embed-load-preset-default`, `cf-push-response` and `cf-read-clipboard`. The editor sends `cf-ready`, `cf-push`, `cf-copy-to-clipboard` and `cf-read-clipboard`. Renaming any of them breaks the hosted editor until the website changes too, and a merge to `main` ships the rename immediately.
+
 ## Figma Community publishing
 
 The tag workflow packages the Figma plugin but does not publish or update it in Figma Community. Community publishing is a separate maintainer action:

packages/www/vercel.json

@@ -0,0 +1,7 @@
+{
+	"$schema": "https://openapi.vercel.sh/vercel.json",
+	"framework": "vite",
+	"installCommand": "bunx bun@1.3.11 install --frozen-lockfile",
+	"buildCommand": "bunx bun@1.3.11 run build",
+	"outputDirectory": "dist"
+}