@koda-sl/baker-cli 0.300.0 → 0.301.0-dev.c73cac21a

package/README.md

@@ -1271,10 +1271,27 @@ baker analytics conversions --remove-name "Lead"
 baker analytics sites                     # the websites the measurement tag is accepted from
 baker analytics sites --add example.com   # and every subdomain of it — applies at once, no publish
 baker analytics website-tag               # the tag for a site Baker does not publish, with the key in it
+baker analytics sends                     # where each system event is sent, and what happened to each upload
+baker analytics sends --set --source-event page:deal_won --platform meta --tag <tagId> --event Purchase   # staged; spends budget once published
+baker analytics sends --set --source-event page:deal_won --platform meta --tag <tagId> --event Purchase --parameter content_name={{properties.plan}}   # with an extra Meta custom_data parameter
+baker analytics sends --uploads s1 --failed   # the uploads Meta refused, each with the event and Meta's own words
+baker analytics sends --remove s1         # stop one, when the chat is published
 baker analytics delivery --page 2         # the next page of a long list
 baker analytics submissions --flow contact  # every attempt at a Form, delivered or not
+baker analytics feed --source Zapier      # the raw event feed, newest first, narrowed to what one source sent
+baker analytics feed --sends failed       # only the uploads a conversion's sends made and the platform refused
+baker analytics sources                   # every source: the addresses the client's tools send events to, and the HubSpot reads
+baker analytics sources --create --name Zapier           # a new address, learning; hand the URL to the user
+baker analytics sources --map --source <id> --field email={{contact.email}} --field value={{deal.amount}} --field currency=EUR
+baker analytics sources --create-hubspot --property lifecyclestage --value customer   # an event HubSpot keeps for Baker each time the property changes
+baker analytics sources --create-hubspot --property deal_value --operator greaterThan --value 1000   # any condition a Form's filter can say
+baker analytics sources --map --source <id> --field email={{work_email}} --field value={{deal_value}} --field currency=EUR   # repoint a HubSpot read
 ```
 
+**Sources: where events reach Baker from a server.** Measure → Sources is three built-in doors — the Baker landings, the website tag, and **the client's own server** — plus the connections Baker reads (HubSpot today). `--server` prints the server's one address: made once, the same for ever, `counting` at once, Baker's own format (`sending-events` is the contract; `X-Baker-Mode: test` rehearses). A HubSpot event is a trigger in HubSpot's own words, kept by HubSpot's journal each time the property changes and counted within a minute. `--create --name <tool>` still makes an address for a tool that cannot be told what to send — its first send is a masked sample counted as nothing until `--map` confirms the rows — but the dashboard no longer offers those; a tool worth reading is a connection, requested from the Sources page. Each `--field` is a **template**: text with `{{path}}` mentions, one thing per mention (`--field currency=EUR` types a value, `--field first_name="{{who.first}} {{who.last}}"` joins two; there is no `{{a|b}}` fallback); a bare path is read as its mention when the sample has it. From then on every arrival is an ordinary event carrying `baker_source: <name>`, listed by `feed --source <name>`, and `--pause`, `--resume` and `--remove` are by `--source <id>`.
+
+**`--preview` then `--create-hubspot --property <name> [--operator <op>] --value <value>… [--name <name>] [--field <field>=<template>…] [--amount-property <n> --currency <c>]`: a HubSpot event.** HubSpot keeps each change to the property for Baker, filtered to the condition — on any plan, nothing to set up in HubSpot, an account of any size — and every contact whose new value satisfies the condition is one event, within a minute, named after the source (default: the trigger's words). The condition is any a Form's filter can say, by the property's kind: `is` / `isNot` (a dropdown, `--value` repeated for several), `contains` / `startsWith` / `endsWith` (text), `greaterThan` / `lessThanOrEqual` … (numbers), `isAfter` / `isBetween` (dates, `YYYY-MM-DD`), `isEmpty` / `isNotEmpty` (any); `--operator` is `is` when unsaid. Names, kinds and operators come from `baker hubspot contacts properties` and row properties from `baker hubspot contacts fields`; `--preview --property … [--operator …] --value … [--field …] [--contact <id or email>]` says how many contacts satisfy it today (NOT counted — only contacts that come to satisfy it from now on are) and returns `preview.contact`, the one most recently there or the one asked for, to check every row against before making anything. `--set-trigger --source <id> --property … [--operator …] --value …` changes what an event watches later: the rows stay and `countingSince` moves to now. The connection must be allowed to read contacts, and a refusal names the reconnect. `counting` at once, no URL; the source carries `hubspot { property, propertyLabel, kind, operator, values, valueLabels }`, `countingSince`, `listening` (whether HubSpot has been told to keep its changes: `listening`, `not_configured` or `failed`, with a `detail`), `lastError` and `mapping` — the same field → template table as an address, over the contact's properties plus `{{id}}`, defaulting to HubSpot's standard ones (email, phone, the contact id, name, address, `hs_google_click_id`, `hs_facebook_click_id`); a `--field` row at creation replaces the default it names, `--map --field` replaces the whole set later, and `--amount-property … --currency …` is the short spelling for the `value` and `currency` rows. `--field properties.<name>=<template>` adds an extra property of the event (`--field properties.plan={{plan_tier}}`): it breaks the event down on Measure → Events and a send reads it back as `{{properties.<name>}}`. A deal is watched the same way with `--object deal`. Where the event is sent on (Meta, Google Ads…) is `sends`, edited on the event's own card on the Sources page.
+
 Shared flags: `--days <n>` (default 30) or `--start-date` / `--end-date` (`YYYY-MM-DD`, end inclusive); `--full`; `--compare` to also return the preceding window of the same length; `--timezone <IANA>` and `--granularity hour|day|week|month` to shape a series. Every call reads live — there is no cache layer, so there is nothing to bypass.
 
 **`--output md` when the numbers are going to be read.** Every report is emitted as compact JSON by default, and `--output md` renders each block as a Markdown table instead — one header rather than the keys repeated on every row, with the identical `warnings` and `hints`. Measured across all sixteen presets against a real deployment, the two changes together take the family from 110 KB to 44 KB — **about 60% smaller overall**, 38% at worst (`ads`, which is dense numeric data with nothing to prune) and 77% at best (`landings`). Three further economies apply to both formats, because the reader is usually an LLM with a context window rather than a browser:
@@ -1298,6 +1315,8 @@ Shared flags: `--days <n>` (default 30) or `--start-date` / `--end-date` (`YYYY-
 
 **`--flow <slug>` reads it from the Form's side**, listing that Form's endings already spelled as event keys with the name each is counted under, built from the Form's own file so it works before a single visitor arrives. With no `--flow`, the answer carries `flows[]` — every Form in the workspace with the step that counts for it, or nothing — which exists nowhere else: on every other report a Form that counts nothing looks exactly like a Form nobody converts on. The list of definitions is read from the store rather than from the reporting mirror, so an outcome named a second ago is in the reply that named it.
 
+**A send belongs to a system's event, and `baker analytics sends` is where it is set.** `page:deal_won` from HubSpot → Meta Purchase means every `deal_won` the client's system reports is uploaded to Meta with who the person is, the click that brought them and the amount forwarded automatically; there is nothing to map. What happens on a page or in a Form is never sent from here — the page's pixels and the Form's own side effects do that — and a send is never set on a funnel step (the step reads the sends of the events behind its ways in back as `sends[]`). With no flags it lists the sends in effect with `sends[].outcome` ("12 sent · 1 failed", `lastError` in the platform's words), `platforms[]` with the tags on Tracking that can send, and `events[]`, the system events that can be sent (a Source's own key, or a name the server posts). `--set --source-event <key> --platform <p> --tag <tagId> --event <e>` **stages** a send: it lands when the chat is published, and from then on it **spends ad budget** on every event under the key — say so plainly; never call a published send a preview. `--tag` is copied from `platforms[].tags[].tagId`, which lists only the tags that hold their server credential — one typed from memory is refused, and a platform with none says what to add on Tracking. A key no system raises is refused too. `--remove <id>` stops one, staged the same way. `--parameter <name>=<template>` (repeatable, with `--set`) adds an extra parameter the platform receives with every upload — Meta's `custom_data`, a GA4 event parameter, a Google Ads custom variable, X's contents; LinkedIn takes none — written from the event: `{{properties.<key>}}` for a property it carries, `{{value}}`, `{{page_path}}`, `{{city}}`… (`templateFields` under `--full`; `parameters[]` says what each platform takes). `--uploads <id> [--failed]` lists the rows behind `sends[].outcome`: which event went, when, its `outcome` and the platform's `error`.
+
 **Campaign parameters are per platform, and so are the numbers.** `baker analytics ads` returns `adPlatformTraffic` (visits, conversions and *tagged* visits for each of the nine platforms), `adParams` for the platform in `--platform` only, and `adParamsUnattributed` for names arriving on visits with no click id and no recognisable source. Read `adPlatformTraffic` first: a platform with visits and zero tagged visits has untagged ad URLs, and no mapping can fix that from Baker's side. `baker analytics map` needs `--platform` for any change, accepts a parameter name **nobody has sent yet** — which is how a tracking template is configured before its campaign runs — and takes an answer back with `--remove`. `--set <name>=ignore` says a parameter is not campaign information at all, so Baker stops storing it and stops listing it.
 
 **Mapping is staged on the chat, not applied.** Answers appear under **Campaign parameters** in the dashboard and take effect when the chat is published; a discard takes them all back, and a report run in the same turn still reads the old vocabulary. Reading the mapping back inside the chat *does* include what it has staged, so a second turn never re-maps the same parameter.
@@ -1331,6 +1350,41 @@ Data is retained for 400 days; a window reaching further back comes back with a
 
 ---
 
+### The company's funnel (`baker funnel`)
+
+The steps a company's business actually has, wired as a graph, each reached by an event Baker already records — and counted in PEOPLE on every read. Every company has one from the day it exists (Visited → Became a lead → Became a customer). It is what makes "how far did the people from this campaign get" answerable: a conversion count can say how many converted on a page, never how many reached Meeting booked and where the rest stopped.
+
+```bash
+baker funnel                                          # the funnel this company has, with 30 days of people per step
+baker funnel --days 90                                # a longer window
+baker funnel --moments                                # everything a way in can name — read before writing any trigger
+baker funnel --step '{"key":"lead","displayName":"Enquiry","stepClass":"lead","after":["visited"],"triggers":[{"id":"t1","kind":"event","eventKey":"submit:contact"}]}'   # one step, added or replaced by key
+baker funnel --remove-step lead                       # one step off; the chain stays joined
+baker funnel --templates                              # the step library and the presets
+baker funnel --preset b2b_sales                       # draw the closest graph over the whole funnel
+baker funnel --steps '[...]'                          # the whole funnel, restated — it replaces
+```
+
+**Every step comes back counted.** `people` reached it, `atLeast` got at least that far (the step or anything after it), `before` got as far as the step before, `share` is `atLeast / before`, and `money` is what its events said they were worth, by currency. `window` says which days, `worstStep` names where the most people are lost, and the hints say it in a sentence. Counted in people across visits and devices — a landing viewed on a phone, a Form completed on a laptop and a deal a CRM posted under its own id are one person when a contact digest joins them — and unordered, so a deal the CRM posted before the site's submit landed still counts. Never quote these as visits.
+
+**The vocabulary is the company's; the stage is closed.** A company invents its own steps and names them whatever it calls them — `displayName` is unconstrained. `key` is the stable identifier (lowercase letters, digits, underscores) and never changes when the name does. Every step also carries one of six stages — `visited`, `lead`, `engaged`, `customer`, `repeat`, `lost` — plain words every business has, used to compare one company's funnel with another's.
+
+**It is a graph, not a ladder.** `after` is a list of predecessors, so two ways into one step is ordinary rather than an anomaly — people arrive by seeing the landing *or* by asking for a demo. An empty `after` means people come in there. A cycle or a predecessor that does not exist is refused with the step named.
+
+**Every write says what it dropped.** `--step` changes one step and leaves the rest as it stands; `--steps` replaces the whole funnel and `--preset` draws over it. Every write returns `removed[]` and a `REMOVED steps:` hint when a step went, so a restatement written from a stale read is caught in the same turn.
+
+**A step says what triggers it, and every trigger is PICKED from `--moments`.** `triggers` is a list and any one of them firing is enough. Three kinds: `{"kind":"event","eventKey":"submit:contact"}` for anything the company's Forms, pages or systems produced (`moments.events`, `moments.sources`), `{"kind":"landing","landingId":"<id>"}` for one landing being viewed (`moments.landings`), and `{"kind":"any_landing"}` for any landing — what the default first step listens for. Nothing has to be named first: the event is used by its own key, and the step shows it by its own words. `moments.events[].origin` tells a page's event (`site`) from one the client's own systems sent (`systems`); `moments.sources` lists the client's systems by the `page:<name>` key each raises, pickable before the first send arrives. A key typed from memory saves, publishes and counts nobody forever — the hint "has a trigger and nobody reached it while N people entered" is that mistake caught after the fact. A step written with `offlineConversions`, a `conversion` trigger or an `analytics` trigger is refused before any round trip, with the shape to use.
+
+**A landing being viewed can be a step** — where most funnels start — and never a conversion: `baker analytics conversions` refuses a `view:` key.
+
+**A step nothing enters advances nobody, silently.** No `triggers` means the report shows zero, nothing errors, and it looks exactly like a stage people never reach. Every response names these in `hints`. **There is no default door either:** a Form is counted only where a trigger names it, and `hints` names every Form no step counts.
+
+**Where a step sends is read here and set on the system's event.** Every step comes back with `sends[]` — one entry per send on a system's event among its triggers (`id`, `eventKey`, `platform`, `event`, and `outcome`: "12 sent · 1 failed", or "Nothing sent yet"). It is read-only: a send belongs to the event, so it is set with `baker analytics sends --set --source-event <key> --platform <p> --tag <tagId> --event <e>`, never on a step. A send that failed is named in the hints (`SEND FAILED on step <key>: …`) with the platform's own error.
+
+**Staged, and published in one piece.** A change becomes the company's funnel when the chat is published; discarding takes it back. The client sees what you staged on the funnel canvas inside the chat and can edit it there — the same canvas, the same publish — so read the funnel back before restating it. The version it replaces is kept, so removing a step does not remove what was measured under it.
+
+---
+
 ### A/B tests (`baker experiment`)
 
 Two versions of one landing page, split 50/50 at the edge, read on one of the conversions the company already counts, and decided by a person on a verdict rather than by two rates somebody reads.
@@ -3479,7 +3533,7 @@ baker history list --category ads --full    # ad writes with raw metadata
 
 ---
 
-### `baker hubspot forms list | view | submissions` · `baker hubspot workflows list | view` · `baker hubspot pipelines list` · `baker hubspot contacts summary | lookup` · `baker hubspot meetings list | view`
+### `baker hubspot forms list | view | submissions` · `baker hubspot workflows list | view` · `baker hubspot pipelines list` · `baker hubspot contacts summary | lookup | properties | fields` · `baker hubspot deals properties | fields` · `baker hubspot meetings list | view`
 
 Read-only view of the company's **connected HubSpot account** — the forms and meeting links (calendars) that live there, the leads those forms received, and the workflows, deal pipelines, and contact records a lead runs through afterwards. Fetched from HubSpot live on every call; nothing is cached and nothing is ever written back.
 
@@ -3500,6 +3554,7 @@ baker hubspot workflows view <workflowId> --full  # + the values each branch com
 baker hubspot pipelines list                    # where a lead lands, and the stages after it
 baker hubspot contacts summary --days 30        # are recent leads being worked? (counts only)
 baker hubspot contacts lookup lead@example.com  # was this one lead picked up?
+baker hubspot contacts properties               # what a HubSpot-read source can watch, with each value
 baker hubspot meetings list                     # every calendar + whether booking redirects
 baker hubspot meetings view <slug>              # booking-form fields for one calendar
 baker hubspot meetings view <slug> --as-node    # the form.external blob for a flow node
@@ -3513,6 +3568,7 @@ baker hubspot meetings view <slug> --as-node    # the form.external blob for a f
 **`pipelines list`:** no flags; stages come back in the order they run in HubSpot.
 **`contacts summary` flags:** `--days <1-365>` (default 30) over contact creation date. Returns counts only — total contacts, how many have an owner, and the lifecycle-stage split — never a name or an email. `truncated: true` means the page budget ran out, so the counts are floors.
 **`contacts lookup`:** positional `<email>`; returns that contact's lifecycle stage, owner, the account (company) it was filed under, and associated deals with their stage. `dealsReadable: false` / `companyReadable: false` mean the connection does not cover deals or accounts, so an empty `deals` or a null `company` is unknown rather than absent. `found: false` means no contact with that email — the lead never reached the CRM, which is a finding rather than an error.
+**`contacts properties`:** no flags; returns every contact property with a closed list of values — `{ name, label, groupName, options: [{ value, label }] }` — the ones a HubSpot-read source can watch. Names are HubSpot's internal ones; hand them to `baker analytics sources --create-hubspot --property <name> --value <value>` as printed. No personal data.
 **`meetings list` flags:** `--search <text>`, `--redirecting-only`.
 **`meetings view`:** positional `<slug>` — the only reliable source for a calendar's booking fields (HubSpot omits `customParams` from the list endpoint, so `fieldCount: null` there means unknown, not zero); `--as-node` as above.
 
@@ -5990,6 +6046,9 @@ This CLI is designed for AI agent consumption. Key patterns:
 - **0.150.0**: `baker landing critique` gains an `agent-washing` rule in the `copy` family — an autonomy claim ("fully autonomous", "while you sleep", "no human intervention") with no signal anywhere on the page about who oversees the agent (approval, review, override, undo/rollback, audit log, escalation) scores a warn. Page-scope, so a hero may defer the trust story to a later section; generic privacy boilerplate does not clear it. `CRITIC_VERSION` bumps to `2`.
 - **0.152.0**: `baker ads linkedin campaigns url-params <ad-set-id>` stages an ad set's URL tracking parameters (LinkedIn's `adTrackingParameters`) — `--param key=value` for fixed values (repeatable or `&`-joined), `--dynamic key=PLACEHOLDER` for values LinkedIn fills in per ad (`CAMPAIGN_NAME`, `CREATIVE_ID`, …), `--clear` to remove them. LinkedIn appends these to the landing URL of every ad in the ad set, including ads already running, so this replaces stamping the same UTM onto each ad's `--landing-url` — which missed later ads and double-appended keys the ad set already set. Account-level parameters remain UI-only (LinkedIn exposes no API for them).
 - **0.153.0**: `baker landing critique` accepts several slugs in one call (`baker landing critique a b c`). `data.landings[]` always carries one entry per slug; a single slug additionally keeps the old top-level `data.slug`/`counts`/`dimensions`/`findings` shape, so existing readers are unaffected. An invalid or missing slug anywhere in the batch still fails the whole call up front. The scaffold's Stop-hook critique gate now emits one batched command instead of one line per stale landing.
+- **0.289.0**: `baker analytics sends --set … --parameter <name>=<template>` (repeatable) adds extra platform parameters to a send — Meta `custom_data`, GA4 event parameters, Google Ads custom variables, X contents — written from the event with `{{properties.<key>}}` and its readable fields; `parameters[]` and `templateFields` (`--full`) describe what each platform takes. `baker analytics sends --uploads <id> [--failed]` lists the rows behind a send's outcome with the platform's own reason per upload, and `baker analytics feed --sends any|failed` shows the same uploads in the raw feed. `baker analytics sources --field properties.<name>=<template>` adds an extra property of a source's events (HubSpot reads and addresses alike). `baker analytics conversions` catalogue rows carry `sources[]`, the doors on Sources that sent each key.
+- **0.291.0**: **HubSpot keeps the changes; the five-minute read of the CRM is gone.** A HubSpot event is read off HubSpot's webhooks journal: Baker's app subscribes the account to the one property the event watches, with the trigger as HubSpot's own value filter where it can be said (never every edit, never a search of the CRM, an account of any size costs nothing to watch), Baker reads the journal forward every half minute, and only a change *to* a value the trigger accepts is an event. `baker analytics sources` answers with `listening` on every HubSpot source — `listening`, or `not_configured` / `failed` with a `detail` — and the hint says so; `lastPolledAt` is gone.
+- **0.290.0**: A HubSpot event can be on a **deal**: `baker hubspot deals properties` / `deals fields` list what a deal can be watched on and read, and `baker analytics sources --create-hubspot --object deal --property dealstage --value closedwon [--contacts first|every]` makes an event about the deal's contact (its first, or every one, each its own event), worth the deal's own amount; rows read the deal bare (`{{amount}}`) and its contact as `{{contact.email}}`; `--preview --object deal` answers with `preview.deal` and its `contacts`. **Inside a chat, `baker analytics sources` stages** — a HubSpot event made, its trigger or rows changed, a source paused, resumed or removed lands at Publish and is drawn under Sources in the chat's change list (`staged[]` in the response); `--server` and `--create` still answer at once. `baker analytics feed --send <id>` keeps one send's uploads and `--uid <event_uid>` one event with every upload made for it, each with the platform's verdict.
 - **0.159.0**: `baker ads google ads update` takes the same content flags as `ads create` (`--format` + `--headlines`/`--descriptions`/image refs/…), and `--format app` becomes a flag-buildable format on both, with `--image-assets` wiring an App campaign ad's images (`AppAdInfo.images`) the same way Responsive Display does. Content flags without `--format` now fail instead of being silently dropped. An ad content update replaces **every field it sends** — a list has to include the entries you want to keep, while an optional asset list you omit is left untouched on the ad — and a partial payload (only the images, or Google's read-shaped `{"appAd":{…}}`) is rejected at stage time with the fields it's missing, instead of staging cleanly and blocking publish later. Content updates also record the staged image assets they consume as dependencies, so discarding an asset no longer leaves the ad pointing at nothing.
 - **0.167.0**: `baker ads google conversions update` stops staging two conversion-action changes Google always rejects. `status: "HIDDEN"` leaves the write contract — Google denies it on every conversion action ("the field's value is on a deny-list for this field"), and offering it made it the obvious pick for retiring an action gently, so a whole cleanup published nothing; the refusal now names the two changes that do work (`--no-primary` to stop bidding toward it while it keeps measuring, `status: "REMOVED"` to stop it counting). `HIDDEN` is unchanged everywhere it is *read* — an action hidden long ago still reads back. And an update against a conversion action **Google owns** — Smart campaign calls/directions, the in-ad lead form's submit, YouTube subscriptions and follow-on views, Floodlight and Search Ads 360 imports, store visits, codeless webpage actions — is refused at stage time, renames included, since Google rejects every write against one and its own interface will not change them either. Both refusals name what to do instead and tell the agent to carry on with the rest of the job.
 - **0.166.0**: `baker ads google conversions` can set a conversion action's primary/secondary role (`ConversionAction.primary_for_goal`) — `update <id> --primary` to have automated bidding optimize toward it, `--no-primary` to demote it to reported-only. Demoting an action was previously manual work in the Google Ads UI. `conversions create` now states the role instead of leaving it to Google, defaulting to **secondary** so a new action can't silently join what a Maximize Conversions / Target CPA campaign bids toward. The staged card gains an "Action optimization" row, and re-staging the role an action already has is reported as a no-op.

package/dist/{chunk-YFQWCJX4.js → chunk-EFETQHTX.js}

@@ -16,9 +16,9 @@ import {
   shouldEscalate
 } from "./chunk-DZUVUGEP.js";
 
-// ../../node_modules/.pnpm/safe-stable-stringify@2.5.0/node_modules/safe-stable-stringify/index.js
+// ../../.pnpm-store/v10/links/@/safe-stable-stringify/2.5.0/810146e81bae4e3a061fe487864f2fde80c4b03b886877dc0f1fffbc6480b67e/node_modules/safe-stable-stringify/index.js
 var require_safe_stable_stringify = __commonJS({
-  "../../node_modules/.pnpm/safe-stable-stringify@2.5.0/node_modules/safe-stable-stringify/index.js"(exports, module) {
+  "../../.pnpm-store/v10/links/@/safe-stable-stringify/2.5.0/810146e81bae4e3a061fe487864f2fde80c4b03b886877dc0f1fffbc6480b67e/node_modules/safe-stable-stringify/index.js"(exports, module) {
     "use strict";
     var { hasOwnProperty } = Object.prototype;
     var stringify = configure2();
@@ -1105,7 +1105,7 @@ function resolveAdaptFormats(params) {
   return params.formats ?? [];
 }
 
-// ../../node_modules/.pnpm/safe-stable-stringify@2.5.0/node_modules/safe-stable-stringify/esm/wrapper.js
+// ../../.pnpm-store/v10/links/@/safe-stable-stringify/2.5.0/810146e81bae4e3a061fe487864f2fde80c4b03b886877dc0f1fffbc6480b67e/node_modules/safe-stable-stringify/esm/wrapper.js
 var import__ = __toESM(require_safe_stable_stringify(), 1);
 var configure = import__.default.configure;
 var wrapper_default = import__.default;
@@ -9212,4 +9212,4 @@ export {
   defaultRegistry,
   createEngineFromEnv
 };
-//# sourceMappingURL=chunk-YFQWCJX4.js.map
+//# sourceMappingURL=chunk-EFETQHTX.js.map