motely-wasm 6.1.0 → 7.0.2

package/README.md

@@ -1,76 +1,19 @@
-# Motely browser WASM (`motely-wasm` / `motely-wasm-compat`)
+# motely-wasm (NativeAOT-LLVM + Bootsharp)
 
-## What Bootsharp actually does
+This project compiles Motely to **browser WASM** with **Bootsharp** interop. Prefer **`createPlan` → chain on `settings` (same as `JamlSearchBuilder` / `IMotelySearchSettings` in C#) → `runSearch`**; the `start*` helpers are optional shortcuts. Progress/results go through **`SearchEvents`**.
 
-**`dotnet publish Motely.BrowserWasm`** is the **entire** build. [Bootsharp](https://github.com/korif/Bootsharp) emits the **complete** npm package: `index.mjs`, WASM, TypeScript typings, and the JS interop glue. You are **not** hand-assembling an npm package.
+The **`Program`** class here is only the **runtime bootstrap** (`Main` → `RunBootsharp()`). Do not confuse it with `Motely.CLI`.
 
-After publish, you get **two** npm-ready folders: `Motely.BrowserWasm/motely-wasm/` (canonical name) and `Motely.BrowserWasm/motely-wasm-compat/` (same WASM bits and `exports`; alternate package name for consumers). Both are **real** packages you can `npm pack`, depend on with `"file:…"`, or publish to the registry.
+**Bootsharp glue** (`JSExport` / `JSImport` / `JSPreferences`) is isolated in **`BootsharpInterop.cs`** so you can ignore it while working in C#. **MotelyWasmHost.cs** is the real API surface.
 
-The only extra step in this repo is **MSBuild**: it copies `Motely/package.json`, `jaml.schema.json`, README metadata, and Monaco assets **on top of** Bootsharp’s output so `name`, `description`, `exports`, and shipped files match what you want on npm. **Version** comes from `$(MotelyVersion)` in `Directory.Packages.props` via the project `Version` property — not from editing `package.json` by hand for every release.
+After `dotnet publish` on this project, the npm package is emitted under `motely-wasm/` (and `motely-wasm-compat/` is built by the csproj target).
 
-### JavaScript: default export = boot API, flat named exports for the generated API
+**Breaking change (vs older builds):** the exported host type was renamed from `MotelyProgram` to `MotelyWasmHost`.
 
-The browser-first package is emitted as a real npm module and can be consumed from browsers, workers, Node, Bun, or Deno. Use it like this:
+**Sequential batch size:** `batchCharCount` applies only to **sequential** search (`startSequentialSearch*`, and `startConfiguredSearch` when the JAML has **no** `aesthetics`). Keyword/random/aesthetic/seed-list modes are **provider** searches and do **not** take `batchCharCount` (the engine uses fixed vector-width batches).
 
-```js
-import bootsharp, {
-	MotelyProgram,
-	SearchEvents,
-	MotelyDeck,
-	MotelyStake,
-} from "motely-wasm";
+**Threads:** the browser host runs search with **one** worker (`threadCount` is not a parameter). Use the CLI/TUI for configurable parallelism.
 
-await bootsharp.boot();
+**Seed list:** `startSeedListSearch` takes **`string[]` seeds** (trimmed, empties dropped), not a CSV string.
 
-const ver = MotelyProgram.getVersion();
-```
-
-Types are under `motely-wasm/types/`; the generated API is exported directly as named exports such as `MotelyProgram`, `SearchEvents`, `MotelyDeck`, and `MotelyStake`.
-
----
-
-## Commands (from repo root `MotelyJAML`)
-
-### Default package
-
-```powershell
-dotnet publish Motely.BrowserWasm -c Release
-```
-
-Output: **`Motely.BrowserWasm/motely-wasm/`**. With embedded binaries enabled, this is the low-friction package shape for browser and bundler consumers.
-
-### Parallelism: Web Workers (not pthread WASM)
-
-This project does **not** ship or promise a pthread / multi-threaded Emscripten WASM build. Combining **.NET WASM + NativeAOT-LLVM + pthreads** is a separate, poorly documented matrix; there is no reproducible “proof script” checked in here that threaded AOT-LLVM WASM is a supported combination—so we do not bet the browser story on it.
-
-**What we actually use:** scale in the browser by spawning **Web Workers**, importing `motely-wasm` in each worker, and calling `bootsharp.boot()` once per worker. Workers are a normal, well-defined browser API; each worker is its own isolate—no `motely-wasm-mt` package, no COOP/COEP requirement for that pattern.
-
-**Proof:** after `dotnet publish`, run **`Motely.TestWebsite`** (or your app) locally and confirm behavior. Treat any WASM path as “works on my machine / CI” until you’ve verified it for your SDK and host.
-
-### Optional: `npm pack` / `npm publish`
-
-Tarball verification or registry publish still use the **npm CLI** on the publishing machine or in CI:
-
-```powershell
-cd Motely.BrowserWasm/motely-wasm
-npm pack --dry-run
-cd ../motely-wasm-compat
-npm pack --dry-run
-```
-
-From repo root, **`Build-Release.ps1`** does the full pipeline (solution build, schema, jaml-language, `dotnet publish`, optional npm). **`publish.ps1`** is a shortcut for `Build-Release.ps1 -Npm Publish` (use `-DryRun` on `publish.ps1` for `npm pack --dry-run`).
-
----
-
-## Test website (`Motely.TestWebsite`)
-
-Vite harness that loads **`motely-wasm`** on `/` and **`motely-wasm-compat`** on `/compat.html` (separate pages so each bundle calls `bootsharp.boot()` once).
-
-```powershell
-dotnet publish Motely.BrowserWasm -c Release
-cd Motely.TestWebsite
-npm install
-npm run dev
-```
-
-Production static output: `npm run build` → `dist/`. Deploy with any static host; ensure `*.wasm` is served with `application/wasm` (Vite preview/dev handles this for local QA).
+**Cancel:** `runSearch` / each `start*` returns **`IMotelySearch`** — call **`cancel()`** on that object. There is no host-level “current search” slot.