Update Vendwick

How to install a new Vendwick release on a running site, and what to do after each upgrade. It covers the general update steps, the pnpm release-age hold, MCP re-consent, and the 0.1.0 to 0.2.0 upgrade in detail.

Vendwick is a native EmDash plugin installed from a tarball. A deployed site can’t replace its own code, so an update is always: install the new tarball, rebuild, redeploy.

Update the plugin

1. Download the new release from your account at gauravtiwari.org. If the release lists a SHA-256, check the file against it (shasum -a 256 <file>).
2. Put the tarball in your project (for example vendor/) and install it over the old one:

   pnpm add ./vendor/gatilab-emdash-vendwick-<version>.tgz

3. Read the CHANGELOG entry for the version. Check whether the emdash and astro peer ranges in its package.json still match your site.
4. Build and deploy. Run npx emdash migrate --check first if you also upgraded EmDash (see Deploy to Cloudflare Workers).

Don’t redeploy or change Worker secrets while a migration is running.

0.1.0 to 0.2.0

0.2.0 adds the cart, pay what you want, free-order confirmation, bundles, order bumps, physical goods, refunds and disputes from the admin, outgoing webhooks, PDF invoices, the store importer and a reorganized admin. The CHANGELOG lists everything. Your 0.1.0 data works as it is: there is no migration to run.

Requires EmDash 1.5

0.2.0 needs EmDash ^1.5.0 (0.1.0 accepted ^1.4.0). The new admin relies on EmDash 1.5 behavior and was checked only there. If your site runs EmDash 1.4, upgrade EmDash first, deploy, run npx emdash migrate --check (see Deploy to Cloudflare Workers), then install Vendwick 0.2.0. pnpm reports an unmet peer dependency if you skip this.

Install

Use the same tarball flow as above:

pnpm add ./vendor/gatilab-emdash-vendwick-0.2.0.tgz

Then build and deploy. vendwick() and vendwickSite() take the same options as in 0.1.0, so astro.config.mjs and wrangler.jsonc need no change.

The first request

0.2.0 declares new storage collections (refunds, disputes, order bumps, shipping, webhooks, the importer) and new indexes on existing ones (orders, licenses, the mail queue and client invoices). EmDash creates them the first time the plugin runs after the deploy. On a large store this can take around a minute; the first admin page or request may be slow while it happens. Nothing else runs once: no records are rewritten.

After the upgrade

1. Confirm the new capability. The plugin now asks for network:request:unrestricted (outgoing webhooks to your own servers) and the host api.cloudflare.com (the optional PDF engine). EmDash asks an admin to confirm the changed permissions.
2. Approve the MCP tools again. 0.2.0 adds 34 tools and changes the inputs of list-orders and save-plan, so an agent can’t use Vendwick’s tools until an admin approves them again in EmDash’s plugin manager. See MCP tools need consent again.
3. Enable the new provider webhook events. Refunds made in a provider’s dashboard, refunds the provider fails later, and disputes reach Vendwick only through these events. Add them to the existing webhook in each provider’s test and live dashboards:

   Provider	Add these events
   Stripe	charge.refund.updated, refund.updated, refund.failed, charge.dispute.created, charge.dispute.closed
   PayPal	PAYMENT.CAPTURE.REVERSED, CUSTOMER.DISPUTE.CREATED, CUSTOMER.DISPUTE.RESOLVED
   Razorpay	refund.failed, payment.dispute.created, payment.dispute.won, payment.dispute.lost, payment.dispute.closed
   Polar	refund.created, refund.updated

   
   Keep the events you already have. The full lists are in Payment Gateways: Stripe, PayPal, Razorpay and Polar, and what each event does is in Refunds and Disputes. PayPal sends no event for a refund that fails later, and Polar sends no dispute events.
4. Review the Free orders setting. In 0.1.0 a free plan was delivered as soon as the buyer submitted the checkout. In 0.2.0 the buyer confirms their email first. If you prefer instant delivery, turn off Confirm the email before delivering free orders in the Free orders section of Store settings, General. See Pay What You Want, Free Orders, Bundles and Order Bumps.
5. Turn on the new modules you want under Store settings, Modules. They are off after the upgrade:
   • Physical Goods and Shipping (needs Licensing and Payments) for shipped products. See Physical Products: Shipping, Stock and Shipments.
   • Outgoing Webhooks (needs Licensing) for signed events to your own servers. See Outgoing Webhooks.
   • Store Importer (needs Licensing) to bring in a FluentCart or EDD store. See Import a FluentCart or EDD Store.
6. Pin the store, if you like. The admin pages now sit in two folders, Store and Store settings, at the bottom of the sidebar. The "Show the store at the top of the sidebar" card on the Store overview moves them under Content. See The Admin, the Sidebar and Product Pages.
7. Check the storefront. The checkout, cart drawer and product pages are redesigned, and each Appearance preset now also sets the cart badge, the order bump cards and the drawer side. Open a product page and the checkout in test mode and check them against your brand. The Appearance page has no controls for those three choices yet; pick a preset or override the --vw-* properties (see Components, Blocks and Styling).
8. Refund a test order. Refunds now start from the admin. Make a test-mode purchase and refund it from the order with each provider you use, because no provider’s refund call has been run against a live sandbox yet.

Admins who bookmarked pages: the old sidebar labels changed ("Commerce" is "Store overview", "Store settings" is "General", the order invoice page is "Invoice settings", "License" is "Vendwick license"). The URLs did not change, and Releases and Deliveries are still reachable as tabs of Products and Orders.

Data written by 0.1.0

• Products, plans, orders, licenses, subscriptions, coupons, client invoices, reports and settings keep working unchanged. New record fields are optional; an old record simply doesn’t have them.
• A checkout that was pending when you upgraded settles with the quote it froze under 0.1.0 (a version 1 quote) and is fulfilled normally.
• Orders paid under 0.1.0 can be refunded from the admin, partly or fully. A partial refund recorded under 0.1.0 is kept on the order’s refund ledger.
• Polar: an order paid before 0.2.0 has no Polar order id saved, so refund it in the Polar dashboard. The webhook then records the refund in Vendwick.
• Invoices and credit notes of old orders open as before and download as PDF.

Rolling back to 0.1.0

Rolling back means installing the 0.1.0 tarball and redeploying. It is possible, but 0.1.0 doesn’t know what 0.2.0 wrote:

• Checkouts started under 0.2.0 carry version 2 quotes. 0.1.0 refuses them (quote_tampered), so a payment that arrives for one after the rollback is not fulfilled. Let pending checkouts settle or expire before you roll back.
• New record fields (per-line amounts, refund ledgers, shipping addresses, bundle and bump details) are ignored by 0.1.0. Orders with several items, bundles or shipping show only what 0.1.0 understands.
• New collections (refunds, disputes, order bumps, shipping zones, stock, shipments, webhook endpoints and deliveries, import runs and links) are left in storage, unused. Reinstalling 0.2.0 picks them up again.
• Products of the new types (bundle, physical) and pay-what-you-want plans are unknown to 0.1.0. Archive them first.
• The "Product pages" content type stays in EmDash. Unpin it first if you want the folder back in Plugins.

The pnpm release-age hold

pnpm’s minimumReleaseAge setting refuses registry versions younger than the given number of minutes. Vendwick’s own repo uses 1440 (one day) and exempts EmDash:

# pnpm-workspace.yaml
minimumReleaseAge: 1440
minimumReleaseAgeExclude:
  - emdash
  - "@emdash-cms/*"

If your site sets a hold, an EmDash release that came out today won’t install until the hold passes, unless you exempt it like this. The hold is about registry publish times; a local tarball like Vendwick’s has none, but this hasn’t been tested with every pnpm version.

The same applies to your buyers. If you sell EmDash plugins through Vendwick’s npm registry, a buyer whose project sets minimumReleaseAge must add your scope to minimumReleaseAgeExclude (for example "@vendor/*"), or a fresh release won’t install. See Licenses, Releases and the License API and clients/emdash/README.md.

MCP tools need consent again when they change

EmDash stores each MCP tool’s name, description, route, permission, destructive flag and input schema as part of the admin’s consent. If an update changes any of those, the admin has to approve Vendwick’s tools again before an agent can use them. The CHANGELOG says when a release changes the tool set. Response shapes aren’t part of the consent, so new response fields don’t trigger it. Vendwick 0.2.0 changes the tool set (34 new tools, new inputs on list-orders and save-plan); MCP Tools for AI Agents lists every tool.

Your Vendwick license

Vendwick checks its own license daily against gauravtiwari.org. Enter the key on the admin Vendwick license page (Store settings).

Enforcement is soft. Without a valid license, or after it expires, the store keeps selling, webhooks and the license API keep working, and nothing is turned off. The admin sees a notice, and update information stops. An outage on the license server keeps the last answer for up to 7 days.