@womp/mcp-ui 0.1.9 → 0.1.10

package/README.md

@@ -221,6 +221,26 @@ snapped Tinted clear back to Clear on every re-quote), `materialLabel`,
 list with `swatchUrl`, `finishes`, `colorRequired` / `colorOptional`,
 `available` and `contactUrl`.
 
+**The card's knob turns must be published, or the model orders the defaults.**
+A card's own tool calls go host → server → iframe and never enter the
+conversation, so the model's view of the print is frozen at the arguments it
+opened the card with: tune it, ask for the cart in chat, and you get a 10 cm
+white one. So every change (`markDirty()`, which every control already goes
+through) schedules a `syncConfig()` that does two things:
+
+- calls **`sync_print_config`** — an app-ONLY tool (`visibility: ["app"]`, kept
+  out of the model's tool list) that parks the selection server-side, where
+  `add_to_cart` and `prepare_print` read it. This is the load-bearing half.
+  Colour and finish changes do not re-quote, so `estimate_print` could not have
+  been the sync point.
+- calls **`updateModelContext`** via `pushModelContext` (shared/bridge.ts),
+  which is the MCP Apps channel for the same fact and lets the model *talk*
+  about the right print. Host-gated, and Claude web was reported to drop the
+  payload ([claude-ai-mcp#102]), so it is a bonus, never the mechanism. The
+  harness advertises the capability and logs what arrives.
+
+[claude-ai-mcp#102]: https://github.com/anthropics/claude-ai-mcp/issues/102
+
 **Layout trap that cost an hour:** a grid container's implicit `auto` track
 grows to its items' min-content, and a bare `<input type="number">` is ~150px
 wide intrinsically — three of them widened every row past the card's edge while
@@ -231,6 +251,9 @@ flex basis. If a row overflows, look there first.
 The stub takes three switches for the states a default account never shows:
 `FAKE_ENTERPRISE=1` (Enterprise materials orderable), `FAKE_PRO=1` (hollow
 priced as available), `FAKE_REPAIRED=1` (the repaired / non-manifold callouts).
+It also keeps the last `sync_print_config` and merges it into `add_to_cart` /
+`prepare_print` the way the server does — module scope, not inside
+`buildServer()`, which runs per request exactly as swan-backend's does.
 
 ### The upload card sends bytes from inside the iframe
 
@@ -281,6 +304,10 @@ yarn dev              # vite; opens the harness at /dev/host/index.html
 
 Two terminals, then edit `src/` and watch the card hot-reload.
 
+Someone else already on :3001? `node dev/server.mjs 3002`, then open the harness
+with `?mcp=http://127.0.0.1:3002/mcp` — two sessions, one checkout, no fighting
+over the port.
+
 ### The harness (`dev/host/`)
 
 A real MCP Apps host: `AppBridge` from `@modelcontextprotocol/ext-apps`, driving
@@ -296,6 +323,7 @@ It is deliberately faithful where being unfaithful would hide a bug:
 | host style variables sent **only** over the bridge (and a toggle to withhold them) | a `var()` shipped without a fallback |
 | the card's own `get_generation` polling, proxied to a real MCP server | a running state that never resolves |
 | **"built resource" mode** — the exact HTML `resources/read` returns, in a sandboxed opaque-origin iframe | an asset `vite-plugin-singlefile` failed to inline (blank card) |
+| `updateModelContext` advertised and logged, and a stub that remembers `sync_print_config` across requests | a card whose selection never leaves the iframe — press `add_to_cart` (it sends the mesh and nothing else) and read what the stub merged |
 
 `FAKE_DURATION_MS=8000 yarn dev:mcp` lengthens a fake generation, so the
 running → polling → complete transition is worth watching. The print stubs