1.0.0-beta.24 — the conversion report is delivered with the theme

CONVERSION-REPORT.md now lands in the project directory beside the theme ZIP,
where the ZIP was previously the only thing that crossed out of the workspace.
It is the record of what the conversion did, what it found and what is left
open, and it was worth nothing in a cache directory nobody opens.

Writing it is also no longer optional. whats-here.sh keys on that filename to
tell a finished conversion from an abandoned one, and cleanup.sh keeps it by
name — but the documented contract said the report "may be written", so a run
that only printed it looked exactly like one that died at stage 5, and a later
repair visit would resume rather than repair.

Repairs re-copy it, because a rebuilt theme with the old report beside it is a
document describing something that no longer exists under a filename that did
not change.

Author: BELNEM s.r.o

.claude-plugin/marketplace.json

@@ -14,7 +14,7 @@
       "source": "./plugins/html2wp",
       "displayName": "html2wp — HTML to WordPress",
       "description": "BETA. Convert a static HTML site into a standalone WordPress block theme, verified against the original at three viewport widths — and reviewed by you before handover. The conversion runs through a verified Astro 5 build, so the Astro project is a real output too — proven pixel-identical to the source before anything WordPress-shaped is generated.",
-      "version": "1.0.0-beta.23",
+      "version": "1.0.0-beta.24",
       "author": {
         "name": "BELNEM s.r.o.",
         "email": "hello@html2wp.dev",

VERSION

@@ -1 +1 @@
-1.0.0-beta.23
+1.0.0-beta.24

plugins/html2wp/.claude-plugin/marketplace.json

@@ -14,7 +14,7 @@
       "source": "./",
       "displayName": "html2wp — HTML to WordPress",
       "description": "BETA. Convert a static HTML site into a standalone WordPress block theme, verified against the original at three viewport widths — and reviewed by you before handover. The conversion runs through a verified Astro 5 build, so the Astro project is a real output too — proven pixel-identical to the source before anything WordPress-shaped is generated.",
-      "version": "1.0.0-beta.23",
+      "version": "1.0.0-beta.24",
       "author": {
         "name": "BELNEM s.r.o.",
         "email": "hello@html2wp.dev",

plugins/html2wp/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "html2wp",
   "description": "BETA. Convert a static HTML site — or anything that builds to one (Lovable, Bolt, v0, Next export) — into a standalone WordPress block theme: pixel-1:1, pages, blog, forms, menus, SEO and redirects, with no plugin required and verification gates at every stage. Every conversion ends in your own page-by-page review; the gates catch most fidelity drift, not all of it.",
-  "version": "1.0.0-beta.23",
+  "version": "1.0.0-beta.24",
   "author": {
     "name": "BELNEM s.r.o.",
     "email": "hello@html2wp.dev",

plugins/html2wp/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "html2wp",
-  "version": "1.0.0-beta.23",
+  "version": "1.0.0-beta.24",
   "description": "Convert static HTML or buildable web projects into verified, editable WordPress block themes.",
   "author": {
     "name": "BELNEM s.r.o.",

plugins/html2wp/README.md

@@ -1,10 +1,10 @@
-# html2wp
+# html2wp — convert HTML to a WordPress theme
 
-**Turn a static site into a real WordPress theme — pixel-identical, and still editable.**
+**HTML to WordPress — pixel-identical, and still editable.**
 
-A Codex and Claude Code plugin that converts a static HTML site, or anything that builds
-to one (Lovable, Bolt, v0, Claude artifacts, Next.js export, hand-written
-pages), into a standard WordPress block theme. Pages, blog, forms, menus, SEO
+A Claude Code and Codex plugin that converts HTML to WordPress: a static site, or
+anything that builds to one (Lovable, Bolt, v0, Claude artifacts, Next.js
+export, hand-written pages), becomes a standalone WordPress block theme. Pages, blog, forms, menus, SEO
 and redirects work with **no plugin required**. The markup stays the design's
 own — no page builder, no rebuild.
 
@@ -306,7 +306,7 @@ and the skill will not call a conversion finished until it is done.
 | Node.js | 20 or newer |
 | Python 3 | with Playwright (chromium) and Pillow |
 | Docker | plus `docker compose` — used for the verification WordPress |
-| Also | `php-cli`, `jq`, `curl`, `bash` |
+| Also | `php-cli`, `jq`, `curl`, `bash`, `tar` |
 | Target | WordPress 6.6 or newer |
 
 You do not have to work that list out yourself. Ask for a conversion and the
@@ -332,7 +332,7 @@ python3 -m pip install playwright pillow && python3 -m playwright install chromi
 
 ## What is free
 
-**Three conversions per network address, up to 5 pages each**, plus five
+**Three conversions per IP address, up to 5 pages each**, plus five
 re-runs to share between them.
 A re-run is the same built site uploaded again — so fixing how a page was
 described and trying again does not spend a conversion. That is enough to
@@ -346,7 +346,7 @@ commercial use and needs a licence key — see [LICENSE](LICENSE).
 |---|---|---|
 | Commercial use, client work | no | yes |
 | Pages per conversion | 5 | 20 (Theme Unlock, Pro) · 10 (yearly Visual Edit Pro) · 100 (Agency) |
-| Conversions | 3 per network address | 1 (Theme Unlock) · 5 / 30 days (Pro) · 50 / 30 days (Agency) · 2 (yearly Visual Edit Pro) |
+| Conversions | 3 per IP address | 1 (Theme Unlock) · 5 / 30 days (Pro) · 50 / 30 days (Agency) · 2 (yearly Visual Edit Pro) |
 | Parallel conversions | — | Agency: up to 3 side by side |
 | Re-runs | 5 in total | unlimited while the licence is live |
 | Blog → WordPress Posts | yes | yes |
@@ -449,6 +449,8 @@ can catch one, and the answer is a decision rather than a reading of it.
 ## Links
 
 - Documentation — [html2wp.dev/docs](https://html2wp.dev/docs)
+- Converting a Lovable project, step by step — [html2wp.dev/blog/lovable-to-wordpress](https://html2wp.dev/blog/lovable-to-wordpress/)
+- Converting a design made in Claude — [html2wp.dev/blog/claude-design-to-wordpress](https://html2wp.dev/blog/claude-design-to-wordpress/)
 - Visual Edit plugin — [html2wp.dev/visualedit](https://html2wp.dev/visualedit)
 - Licences — [html2wp.dev/licenses](https://html2wp.dev/licenses)
 - Done-for-you conversions — [24design.eu](https://24design.eu/)

plugins/html2wp/VERSION

@@ -1 +1 @@
-1.0.0-beta.23
+1.0.0-beta.24

plugins/html2wp/skills/html2wp/SKILL.md

@@ -123,10 +123,17 @@ The owner's project keeps exactly this:
 their-project/
 ├── <their source, untouched>
 ├── <slug>-<version>.zip        the theme
+├── CONVERSION-REPORT.md        what was done, what was found, what is left
 ├── visual-edit.zip             only when the conversion was licensed
 └── .html2wp/state.json         one hidden pointer: build id + workspace path
 ```
 
+The report is delivered beside the theme deliberately. It was workspace-only
+until the owner asked why a document the product advertises was not in the
+folder the ZIP arrived in — and they were right: it is the record of what this
+conversion did, what it found and what is still open, and it is worth nothing
+in a cache directory nobody opens. It is the one non-ZIP file that crosses.
+
 `.html2wp/state.json` is the single exception — a hidden pointer, no secret in
 it (see below), so a later `/html2wp repair` finds the workspace that holds
 the re-run kit. If the workspace has aged out, that file is enough to say so
@@ -147,8 +154,8 @@ Why the workspace is a cache dir and not the project:
 `.html2wp/state.json` must never contain an API secret, a bearer token or a
 key — it is a pointer, not a credential.
 
-**Deliver by copying, at stage 6, the ZIP(s) from `{workspace}` into the
-project. Nothing else is copied out.**
+**Deliver by copying, at stage 6, the ZIP(s) and `CONVERSION-REPORT.md` from
+`{workspace}` into the project. Nothing else is copied out.**
 
 **`assets/scripts/…` throughout this file is relative to THIS FILE'S
 directory, never to the workspace.** Resolve it once, at the start, and use
@@ -209,7 +216,8 @@ assets/scripts/whats-here.sh <dir>
 re-run kit in `~/.cache/html2wp/jobs/<slug>/`, and a pointer at
 `<project>/.html2wp/state.json`. So when the owner returns for a repair: read
 that pointer, and run `whats-here.sh` against the `workspace` it names. Run
-against the project directory it would see only the ZIP and a pointer, report
+against the project directory it would see only the ZIP, the report and a
+pointer, report
 "nothing converted here", and start a NEW conversion out of the allowance —
 the exact mistake this stage exists to prevent. No pointer and no workspace
 means it really is a first conversion; resolve `{workspace}` (above) and begin.
@@ -1799,23 +1807,29 @@ project, and where the machine is left tidy.
 - **`visual-edit.zip`**, when the conversion was licensed — it came back beside
   the theme. A free-tier delivery ships the theme alone and is fully usable:
   say so plainly rather than leaving the owner wondering what is missing.
-- **A conversion report**: pages converted; the chrome variants kept and which
-  pages use each; the menus wired, per location; the per-page findings from
-  stage 5.5; every warning from every stage, including the ones you decided
+- **`CONVERSION-REPORT.md`**: pages converted; the chrome variants kept and
+  which pages use each; the menus wired, per location; the per-page findings
+  from stage 5.5; every warning from every stage, including the ones you decided
   were acceptable; inherited console errors from gate A; and anything left for
-  the owner to do. It is printed to the owner and may be written into the
-  workspace — never into the project as a file.
+  the owner to do. **Print it to the owner AND write it to
+  `{workspace}/CONVERSION-REPORT.md`** — writing it is not optional, and used to
+  be described as though it were. `whats-here.sh` treats its absence as a
+  conversion that did not finish and answers a later visit with RESUME, so a run
+  that only printed the report was indistinguishable from one that died at stage
+  5. `cleanup.sh` keeps it by name for the same reason.
 - **The credit that is left**, as the service stated it. The transform reply
   carried a `credit` line (the script printed it as `credit: …`) counting this
   conversion — relay it verbatim so the owner knows where they stand before the
   next one: how many free conversions and re-runs remain, or a licence's next
   window. Do not compute it yourself; pass on the service's sentence.
 
-- **Hand only the ZIP(s) to the project.** Copy them out of the workspace into
-  the owner's project directory; leave everything else where it is.
+- **Hand the ZIP(s) and the report to the project.** Copy them out of the
+  workspace into the owner's project directory; leave everything else where it
+  is.
 
   ```bash
   cp {workspace}/{slug}-{version}.zip <project>/
+  cp {workspace}/CONVERSION-REPORT.md <project>/
   # licensed conversions only:
   cp {workspace}/visual-edit.zip <project>/
   ```
@@ -1828,9 +1842,12 @@ project, and where the machine is left tidy.
     "{slug}-{version}" "{workspace}" "{slug}-{version}.zip" > <project>/.html2wp/state.json
   ```
 
-  After this, the project contains the owner's source, the ZIP(s) and
-  `.html2wp/state.json` — nothing else. No `verify-*`, no `astro-project`, no
-  `theme/`, no `*-report.json` in the project. Those stay in `{workspace}`.
+  After this, the project contains the owner's source, the ZIP(s),
+  `CONVERSION-REPORT.md` and `.html2wp/state.json` — nothing else. No
+  `verify-*`, no `astro-project`, no `theme/`, no `*-report.json` in the
+  project. Those stay in `{workspace}`. The distinction is not tidiness for its
+  own sake: the report is a document written for the owner, the rest is
+  scaffolding written for the pipeline.
 
 - **Ask before leaving a WordPress container running.** Every conversion (and
   every repair) starts a WordPress in Docker — `h2wp-<slug>-<runid>` — and they
@@ -1952,8 +1969,8 @@ What to do instead, in order:
 2. **Check the deployed plugin is the delivered one** (below) — a stale
    `bridge.js` looks exactly like a plugin bug and is fixed by reinstalling,
    not by editing.
-3. **If it truly is the plugin, report it** — `assets/scripts/report.sh`, or
-   an issue on the plugin's own repository. A fix there ships to everybody as
+3. **If it truly is the plugin, report it** — `POST /v1/report` (the form is
+   in the README under Status), or an issue on the plugin's own repository. A fix there ships to everybody as
    a release, which is the only way a plugin fix is allowed to reach a site.
 
 The same rule holds for the delivered theme: hand-editing it is pointless
@@ -2015,8 +2032,14 @@ the result over the ZIP in the project (stage 6), then ask about the container
   version (`--version=`), delivers `<slug>-<new>.zip`, and says which ZIP is
   now the one to install so two versions in the folder are never ambiguous.
 
-Either way the project ends with a current ZIP and nothing else new, exactly
-as a first conversion leaves it.
+**Re-copy `CONVERSION-REPORT.md` too.** A repair that rebuilds the theme and
+leaves the old report in place ships a document describing a theme that no
+longer exists — and the owner has no way to tell, because the filename did not
+change. Update the report with what the repair did, then copy it over the
+delivered one.
+
+Either way the project ends with a current ZIP, a current report and nothing
+else new, exactly as a first conversion leaves it.
 
 **And tell the owner what the repair cost.** Re-delivering runs the transform,
 so its reply carries a fresh `credit` line (printed as `credit: …`) — relay it:

plugins/html2wp/skills/html2wp/VERSION

@@ -1 +1 @@
-1.0.0-beta.23
+1.0.0-beta.24