@drawbridge/drawbridge-utils 0.0.144 → 0.0.145

package/dist/connections/index.cjs

@@ -4428,9 +4428,18 @@ var shopify_default2 = {
   // there is nothing further to choose. `shop` absent means the install did not
   // finish, which is a credential problem rather than a setup one, so the
   // stored status already says so.
-  // Nothing to add — no setting can make this connection unusable, so the
-  // credential's own verdict stands.
-  status: (data2) => data2 == null ? void 0 : data2.status,
+  //
+  // ONE presentation downgrade: an ACTIVE store whose approval carries no
+  // usage meter (source.metered explicitly null) PRESENTS as error, so the
+  // connections list shows the red state and the merchant knows to click in
+  // — where the Fix-order-billing card and the billing Issue explain the
+  // click. The STORED status stays active on purpose: serving and tracking
+  // gate on it, and the orders recorded while the merchant fixes the plan
+  // are the ones billed afterward.
+  status: (data2) => {
+    var _a;
+    return (data2 == null ? void 0 : data2.status) === "active" && ((_a = data2 == null ? void 0 : data2.source) == null ? void 0 : _a.metered) === null ? "error" : data2 == null ? void 0 : data2.status;
+  },
   // Step types name the CAPABILITY, not this vendor. A second store platform
   // implements the same four commerce steps, and the connection on the step
   // says which store it runs against — so a merchant sees one "Create
@@ -5175,6 +5184,11 @@ var publicConnectionKeys = Object.freeze([
   "settings",
   "shop",
   "slug",
+  // Vendor identity plus the metered billing stamp — domain, id, label,
+  // metered — no credentials live here (those are the encrypted settings
+  // blob). The status and tasks hooks pivot on source.metered, so stripping
+  // it here left the presented status blind to the one state it must show.
+  "source",
   "status",
   "tasks",
   "title",

package/dist/connections/index.d.cts

@@ -5283,9 +5283,19 @@ var shopify = {
 	// there is nothing further to choose. `shop` absent means the install did not
 	// finish, which is a credential problem rather than a setup one, so the
 	// stored status already says so.
-	// Nothing to add — no setting can make this connection unusable, so the
-	// credential's own verdict stands.
-	status : ( data ) => data?.status,
+	//
+	// ONE presentation downgrade: an ACTIVE store whose approval carries no
+	// usage meter (source.metered explicitly null) PRESENTS as error, so the
+	// connections list shows the red state and the merchant knows to click in
+	// — where the Fix-order-billing card and the billing Issue explain the
+	// click. The STORED status stays active on purpose: serving and tracking
+	// gate on it, and the orders recorded while the merchant fixes the plan
+	// are the ones billed afterward.
+	status : ( data ) => (
+		data?.status === 'active' && data?.source?.metered === null
+			? 'error'
+			: data?.status
+	),
 	// Step types name the CAPABILITY, not this vendor. A second store platform
 	// implements the same four commerce steps, and the connection on the step
 	// says which store it runs against — so a merchant sees one "Create
@@ -6454,6 +6464,11 @@ const publicConnectionKeys = Object.freeze([
 	'settings',
 	'shop',
 	'slug',
+	// Vendor identity plus the metered billing stamp — domain, id, label,
+	// metered — no credentials live here (those are the encrypted settings
+	// blob). The status and tasks hooks pivot on source.metered, so stripping
+	// it here left the presented status blind to the one state it must show.
+	'source',
 	'status',
 	'tasks',
 	'title',

package/dist/connections/index.d.ts

@@ -5283,9 +5283,19 @@ var shopify = {
 	// there is nothing further to choose. `shop` absent means the install did not
 	// finish, which is a credential problem rather than a setup one, so the
 	// stored status already says so.
-	// Nothing to add — no setting can make this connection unusable, so the
-	// credential's own verdict stands.
-	status : ( data ) => data?.status,
+	//
+	// ONE presentation downgrade: an ACTIVE store whose approval carries no
+	// usage meter (source.metered explicitly null) PRESENTS as error, so the
+	// connections list shows the red state and the merchant knows to click in
+	// — where the Fix-order-billing card and the billing Issue explain the
+	// click. The STORED status stays active on purpose: serving and tracking
+	// gate on it, and the orders recorded while the merchant fixes the plan
+	// are the ones billed afterward.
+	status : ( data ) => (
+		data?.status === 'active' && data?.source?.metered === null
+			? 'error'
+			: data?.status
+	),
 	// Step types name the CAPABILITY, not this vendor. A second store platform
 	// implements the same four commerce steps, and the connection on the step
 	// says which store it runs against — so a merchant sees one "Create
@@ -6454,6 +6464,11 @@ const publicConnectionKeys = Object.freeze([
 	'settings',
 	'shop',
 	'slug',
+	// Vendor identity plus the metered billing stamp — domain, id, label,
+	// metered — no credentials live here (those are the encrypted settings
+	// blob). The status and tasks hooks pivot on source.metered, so stripping
+	// it here left the presented status blind to the one state it must show.
+	'source',
 	'status',
 	'tasks',
 	'title',

package/dist/connections/index.js

@@ -4354,9 +4354,18 @@ var shopify_default2 = {
   // there is nothing further to choose. `shop` absent means the install did not
   // finish, which is a credential problem rather than a setup one, so the
   // stored status already says so.
-  // Nothing to add — no setting can make this connection unusable, so the
-  // credential's own verdict stands.
-  status: (data2) => data2 == null ? void 0 : data2.status,
+  //
+  // ONE presentation downgrade: an ACTIVE store whose approval carries no
+  // usage meter (source.metered explicitly null) PRESENTS as error, so the
+  // connections list shows the red state and the merchant knows to click in
+  // — where the Fix-order-billing card and the billing Issue explain the
+  // click. The STORED status stays active on purpose: serving and tracking
+  // gate on it, and the orders recorded while the merchant fixes the plan
+  // are the ones billed afterward.
+  status: (data2) => {
+    var _a;
+    return (data2 == null ? void 0 : data2.status) === "active" && ((_a = data2 == null ? void 0 : data2.source) == null ? void 0 : _a.metered) === null ? "error" : data2 == null ? void 0 : data2.status;
+  },
   // Step types name the CAPABILITY, not this vendor. A second store platform
   // implements the same four commerce steps, and the connection on the step
   // says which store it runs against — so a merchant sees one "Create
@@ -5101,6 +5110,11 @@ var publicConnectionKeys = Object.freeze([
   "settings",
   "shop",
   "slug",
+  // Vendor identity plus the metered billing stamp — domain, id, label,
+  // metered — no credentials live here (those are the encrypted settings
+  // blob). The status and tasks hooks pivot on source.metered, so stripping
+  // it here left the presented status blind to the one state it must show.
+  "source",
   "status",
   "tasks",
   "title",

package/dist/providers.cjs

@@ -4353,9 +4353,18 @@ var shopify_default2 = {
   // there is nothing further to choose. `shop` absent means the install did not
   // finish, which is a credential problem rather than a setup one, so the
   // stored status already says so.
-  // Nothing to add — no setting can make this connection unusable, so the
-  // credential's own verdict stands.
-  status: (data2) => data2 == null ? void 0 : data2.status,
+  //
+  // ONE presentation downgrade: an ACTIVE store whose approval carries no
+  // usage meter (source.metered explicitly null) PRESENTS as error, so the
+  // connections list shows the red state and the merchant knows to click in
+  // — where the Fix-order-billing card and the billing Issue explain the
+  // click. The STORED status stays active on purpose: serving and tracking
+  // gate on it, and the orders recorded while the merchant fixes the plan
+  // are the ones billed afterward.
+  status: (data2) => {
+    var _a;
+    return (data2 == null ? void 0 : data2.status) === "active" && ((_a = data2 == null ? void 0 : data2.source) == null ? void 0 : _a.metered) === null ? "error" : data2 == null ? void 0 : data2.status;
+  },
   // Step types name the CAPABILITY, not this vendor. A second store platform
   // implements the same four commerce steps, and the connection on the step
   // says which store it runs against — so a merchant sees one "Create
@@ -5017,6 +5026,11 @@ var publicConnectionKeys = Object.freeze([
   "settings",
   "shop",
   "slug",
+  // Vendor identity plus the metered billing stamp — domain, id, label,
+  // metered — no credentials live here (those are the encrypted settings
+  // blob). The status and tasks hooks pivot on source.metered, so stripping
+  // it here left the presented status blind to the one state it must show.
+  "source",
   "status",
   "tasks",
   "title",

package/dist/providers.js

@@ -4309,9 +4309,18 @@ var shopify_default2 = {
   // there is nothing further to choose. `shop` absent means the install did not
   // finish, which is a credential problem rather than a setup one, so the
   // stored status already says so.
-  // Nothing to add — no setting can make this connection unusable, so the
-  // credential's own verdict stands.
-  status: (data2) => data2 == null ? void 0 : data2.status,
+  //
+  // ONE presentation downgrade: an ACTIVE store whose approval carries no
+  // usage meter (source.metered explicitly null) PRESENTS as error, so the
+  // connections list shows the red state and the merchant knows to click in
+  // — where the Fix-order-billing card and the billing Issue explain the
+  // click. The STORED status stays active on purpose: serving and tracking
+  // gate on it, and the orders recorded while the merchant fixes the plan
+  // are the ones billed afterward.
+  status: (data2) => {
+    var _a;
+    return (data2 == null ? void 0 : data2.status) === "active" && ((_a = data2 == null ? void 0 : data2.source) == null ? void 0 : _a.metered) === null ? "error" : data2 == null ? void 0 : data2.status;
+  },
   // Step types name the CAPABILITY, not this vendor. A second store platform
   // implements the same four commerce steps, and the connection on the step
   // says which store it runs against — so a merchant sees one "Create
@@ -4973,6 +4982,11 @@ var publicConnectionKeys = Object.freeze([
   "settings",
   "shop",
   "slug",
+  // Vendor identity plus the metered billing stamp — domain, id, label,
+  // metered — no credentials live here (those are the encrypted settings
+  // blob). The status and tasks hooks pivot on source.metered, so stripping
+  // it here left the presented status blind to the one state it must show.
+  "source",
   "status",
   "tasks",
   "title",

package/package.json

@@ -216,5 +216,5 @@
     "prepublishOnly": ". \"$HOME/.nvm/nvm.sh\" && nvm use && tsup && node --test"
   },
   "types": "dist/index.d.ts",
-  "version": "0.0.144"
+  "version": "0.0.145"
 }