@nextcommerce/campaigns-os 1.57.0 → 1.59.0

package/CHANGELOG.md

@@ -2,6 +2,66 @@
 
 Notable supported-surface changes are recorded here.
 
+## [1.59.0] - 2026-10-09
+
+### Changed
+
+- Publishes the untagged `1.58.0` change: multi-step checkout frontmatter follows the starter-template `next_step` contract (campaigns-os#641).
+- Publishes `1.58.0+agent.2`: doctor warns `template_contract.select_step_missing` for a two-step family with no select page before checkout, and the phone scan skips comments and `<style>` content (campaigns-os#658, campaigns-os#660).
+- Publishes `1.58.0+agent.3`: a stale build fingerprint names the extra, missing and changed files and flags sync conflict copies (campaigns-os#659).
+- Publishes `1.58.0+agent.4`: QA verdicts separate planned order paths from retry attempts (campaigns-os#661).
+- Publishes `1.58.0+agent.6`: QA cart entry chooses each slot's variant on a select page before Next (campaigns-os#667).
+- Publishes `1.58.0+agent.7`: the starter catalog is re-synced to campaign-cart-starter-templates `d5ff501` (campaign-cart-starter-templates#223, SDK 0.4.42).
+- Bundled skills advance to `1.59.0+skills.1`.
+
+### Added
+
+`record deploy` records a hosted deploy. On a packet whose `deploy.target` is not `local-serve` it takes an https `--base-url` naming the campaign's route root (plain http only on a loopback host), requests every built page there, and requires each to answer HTTP 200. It then requests every script and stylesheet the built pages load from that origin and compares each one's sha256 with the file in the built output, following redirects only within that origin and reading no more bytes than the built file holds; a missing, larger or different asset refuses the record, naming the URL and the built file. A `record build` of other output between the probe and the write refuses the record, on a `local-serve` packet too. A response with no readable body refuses as a transport failure, not as a byte mismatch. HTML is not compared, because hosts inject toolbars and other markup. A passing probe writes what the loopback path writes: `deploy.preview_url` on the packet, and `stages.deploy` completed with the URL in `outputs`, one evidence line per page and per matched asset, and the build fingerprint it probed, so a later `record build` of other output makes deploy owed again. `local-serve` packets keep the loopback-only rules. The hosted all-template preview no longer skips the deploy stage: `next` hands off `record deploy` for the recorded preview URL and then QA, and the hosted deploy prompt names `record deploy` in place of hand-editing `stages.deploy` (campaigns-os#657).
+
+## [1.58.0+agent.7] - 2026-10-09
+
+### Changed
+
+The vendored starter catalog is re-synced to campaign-cart-starter-templates `d5ff501`, which carries the multi-step checkout contract from campaign-cart-starter-templates#223 and the Campaign Cart SDK 0.4.42 pin. Builds made with 1.58.0's `next_step` frontmatter now take templates whose step forms and select links read `next_step` and whose `next-success-url` is the Checkout's post-payment destination. Every certified family records 0.4.42 verification evidence (`sdk-0.4.42-2026-10-09`), and the eight agent CampaignSpec fixtures pin `sdk_version` 0.4.42. The certified-family fixtures are regenerated at the pin, and the payment-chrome asset pin moves to `d5ff501`; the five asset hashes are unchanged.
+
+The SDK attribute index moves to v0.4.42 with the same recipe; it returns the same 149 names as at v0.4.41. 0.4.42 joins the cart-placeholder verified pins: the ten renderer and enhancer files the placeholder lists come from have the same git blob ids at v0.4.38 and v0.4.42. The checkout field-name mapping is unchanged at v0.4.42. The SDK support policy names 0.4.42 as `latest_known_release`; `minimum_supported` and `preferred_minimum` are unchanged.
+
+## [1.58.0+agent.6] - 2026-10-09
+
+### Fixed
+
+On a select page whose bundle slots each need a variant (size, colour) before Next, `qa run --test-order` now chooses one per slot before clicking the checkout control. It does this after revealing the second step and after any bundle card click, one field at a time, over the visible, enabled slot variant selects (`[data-next-variant-selectors] select` or `.next-slot-variant-field select`, counted visible when the field is). When a field shows a dropdown UI (`os-dropdown` with a `.os-card__variant-dropdown-toggle` and `os-dropdown-item` rows, as the olympus-mv-two-step starter renders), the runner clicks the toggle and a row like a shopper, even when the SDK has already filled the select, because a page may count a field as chosen only when a row was clicked. It clicks the row matching the select's current value when that row is in stock, so the cart stays what the SDK chose, and otherwise the first in-stock row. After the toggle click it finds the field again by slot identity and the row again by its value, and waits up to 2 seconds for that row to show. A field with no dropdown UI gets its first in-stock option only when its select is empty, with `input` and `change` dispatched. Each choice is recorded on the `entered_via_landing` evidence as `variant_selections: [{ bundle_id, slot, variant_code, value, via }]`, with `via` set to `dropdown` or `select`, so the ordered variants can be checked against the cart lines. A field with no in-stock row or option, or a row that does not show or cannot be clicked, fails the path before Next with the new code `cart_entry_variant_unfilled`, naming the slot, instead of `cart_entry_no_navigation` after the navigation timeout. It classifies as `not_created` like the other cart-entry codes. A page whose filled selects have no dropdown UI is left untouched and `variant_selections` is omitted. Before this, every path on a page that blocks Next until a variant is picked failed with `cart_entry_no_navigation` (campaigns-os#667).
+## [1.58.0+agent.4] - 2026-10-09
+
+### Fixed
+
+A QA run that re-ran failed order paths no longer reads as more paths than it planned. Each `test_orders[]` entry in the verdict now carries `attempt` (1 for the first try, 2 for the re-run) beside the `plan_id` of the planned path it belongs to, and `qa run` prints a summary line that keeps paths, attempts and created orders apart, such as `Test orders: 5 paths, 10 attempts, 0 orders created`. Before this, a run capped at five paths where every path was re-run once showed ten entries and nothing to say which were retries. The Assembly Report's `stages.qa.purchase_proof` gains `test_order_attempts`, and `order_paths_executed` now counts planned paths rather than attempts. Verdicts written before `attempt` existed count each entry as a path, as they did before. The array keeps one entry per attempt and no existing field changed shape.
+
+## [1.58.0+agent.3] - 2026-10-09
+
+### Fixed
+
+When the built output no longer matches the recorded build fingerprint, doctor's `built_output.fingerprint_stale` and the `polish capture` refusal now name the paths that are extra, missing, or changed, at most 20 per list followed by `(+N more)`. Before, both reported only the recorded and current hashes, so finding the files behind a mismatch took a manual diff of `_site/`. `record build` keeps the path and SHA-256 list behind the fingerprint on `stages.assembly.build_manifest` to make the comparison possible; the field is additive and the fingerprint value is unchanged. A file or folder named like a macOS or iCloud sync conflict copy (`<name> 2.<ext>` beside `<name>.<ext>`) is marked as one, with a hint to remove the copies and rebuild. A build recorded before this change carries no manifest: the refusal is unchanged and says to run `record build` again to record one (campaigns-os#659).
+
+## [1.58.0+agent.2] - 2026-10-09
+
+### Fixed
+
+- Doctor, and so `start` and `build`, warns `template_contract.select_step_missing` before build when the selected template family puts package selection on its own `select` page and its checkout carries no selector, but no enabled `select` page in the Map leads to a Checkout. The certified family affected today is `olympus-mv-two-step`. Without the select page, QA resolves the landing as the entry page, finds no add-to-cart control, and every order path fails after build, polish and deploy. The warning names the Checkout and funnel and the fix: add a Select page between the entry page and checkout in Map Builder. It stays silent when a `select` page routes to that Checkout, when the family's checkout carries its own selector, and for a Checkout pinned to another family through `sdk_hints.template_family`. The family's shape is read from the commerce surface catalog's `selectStep` and `mainSelector` surfaces. The warning does not block intake (campaigns-os#658).
+- `copy.hardcoded_phone` no longer reads digit runs inside HTML comments, `<style>` blocks or CSS comments as phone numbers, such as a design-export frame name like `Group 1000003339`. Visible phone numbers still warn, at their original line numbers (campaigns-os#660).
+
+## [1.58.0] - 2026-10-09
+
+### Changed
+
+Page Kit frontmatter for multi-step checkout paths follows the starter-template contract adopted in NextCommerceCo/campaign-cart-starter-templates#223. On a `select` or `checkout_step` page on a path to a Checkout, `next_url` is now the Checkout's post-payment destination, the meaning `next_url` has on every checkout page; the layouts render it as `next-success-url`, which the SDK reads for express orders. The page's forward link moves to the new `next_step` key, which the templates render as the step form's `data-next-checkout-step` and the select page's checkout link. `step_number` is unchanged. `success_url` is no longer emitted as a frontmatter key; it stays a CampaignSpec field on `checkout` pages, and the Build Context and Build Packet schemas still accept it so packets written by 1.56.0 and 1.57.0 validate. A landing page that feeds a Checkout keeps `next_url` as its call-to-action target, because every certified family's landing call-to-action reads it; it no longer carries `success_url`, and the build prompt takes an express landing page's `next-success-url` from the Checkout's own `next_url`. The build prompt and the `next-campaigns-build` skill describe the new keys. Bundled skills advance to `1.58.0+skills.1` (campaigns-os#641).
+
+## [1.57.0+agent.1] - 2026-10-08
+
+### Fixed
+
+Reading a 4.2 or 4.3 spec no longer turns a `checkout → checkout` chain linked through `success_url` into Checkout Steps with no way forward. A page retyped `checkout_step` keeps the link it followed as a checkout: the resolved forward target is written to `next_page` and `success_url` is dropped, because routing ignores `success_url` on a step. Before this, the upgraded spec failed `CheckoutStepReachesCheckout` and warned `RouteFieldIgnoredForPageType` on every step. A `next_page` the checkout never took (shadowed by `success_url`) is replaced by the followed link. Chains already linked through `next_page`, and 5.x specs, read as before.
+
 ## [1.57.0] - 2026-10-08
 
 ### Changed

package/campaign-spec/dist/checkout-flow.d.ts

@@ -86,5 +86,12 @@ export declare function paymentPagesForFunnel(funnel: Funnel | null | undefined)
  * "this form moves on without taking payment". A supported v4 `schema_version`
  * becomes `5.0`; a missing or unsupported one is left for SchemaVersion to
  * report.
+ *
+ * A retyped page keeps the link it followed as a checkout. A `checkout_step`
+ * moves on through `next_page` only (routing.ts ignores `success_url` on it),
+ * so a v4 chain linked through `success_url` would otherwise upgrade into a
+ * step with no way forward and fail CheckoutStepReachesCheckout. The resolved
+ * forward target is written to `next_page` and `success_url` is dropped; a
+ * `next_page` the checkout shadowed (never taken) is replaced by it.
  */
 export declare function upgradeCampaignSpec<T>(input: T): T;

package/campaign-spec/dist/checkout-flow.js

@@ -189,6 +189,13 @@ export function paymentPagesForFunnel(funnel) {
  * "this form moves on without taking payment". A supported v4 `schema_version`
  * becomes `5.0`; a missing or unsupported one is left for SchemaVersion to
  * report.
+ *
+ * A retyped page keeps the link it followed as a checkout. A `checkout_step`
+ * moves on through `next_page` only (routing.ts ignores `success_url` on it),
+ * so a v4 chain linked through `success_url` would otherwise upgrade into a
+ * step with no way forward and fail CheckoutStepReachesCheckout. The resolved
+ * forward target is written to `next_page` and `success_url` is dropped; a
+ * `next_page` the checkout shadowed (never taken) is replaced by it.
  */
 export function upgradeCampaignSpec(input) {
     if (input == null || typeof input !== 'object' || Array.isArray(input))
@@ -216,7 +223,16 @@ export function upgradeCampaignSpec(input) {
         changed = true;
         return {
             ...funnel,
-            pages: pages.map((page) => (retype.has(page) ? { ...page, type: CHECKOUT_STEP_PAGE_TYPE } : page)),
+            pages: pages.map((page) => {
+                if (!retype.has(page))
+                    return page;
+                const step = { ...page, type: CHECKOUT_STEP_PAGE_TYPE };
+                const forward = forwardRouteTarget(page);
+                if (forward === null)
+                    return step;
+                const { success_url: _ignoredOnStep, ...rest } = step;
+                return forward === page.next_page ? rest : { ...rest, next_page: forward };
+            }),
         };
     });
     const upgradeVersion = version === '4.2' || version === '4.3';

package/compatibility.json

@@ -1,6 +1,6 @@
 {
   "package": "@nextcommerce/campaigns-os",
-  "version": "1.57.0",
+  "version": "1.59.0",
   "status": "developer-preview",
   "contracts": {
     "campaign_spec": "4.2-5.0",

package/contracts/campaign-cart-sdk-support-policy.v0.json

@@ -2,8 +2,8 @@
   "schema_version": "campaign-cart-sdk-support-policy/v0",
   "provenance": {
     "source": "NextCommerceCo/campaign-cart release tags",
-    "latest_known_release": "0.4.41",
-    "captured_at": "2026-10-07"
+    "latest_known_release": "0.4.42",
+    "captured_at": "2026-10-09"
   },
   "source": "contracts/campaign-cart-sdk-support-policy.v0.json",
   "minimum_supported": "0.4.20",

package/contracts/commerce-surface-catalog.json

@@ -848,9 +848,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -1272,9 +1272,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -1583,9 +1583,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -1886,9 +1886,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -2227,9 +2227,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -2666,9 +2666,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -2686,7 +2686,6 @@
       ],
       "canonicalSurfaces": {
         "selectStep": "mv-selection-step",
-        "checkoutSelector": "mv-selected-bundle-review",
         "variantSlots": "bundle-slot-selector",
         "personalization": "per-slot picker (data-next-property per slot, toggled by slot_personalization); order-wide default via personalization-field (ships unwired)",
         "orderSummary": "cart-summary03|cart-summary04",
@@ -3023,9 +3022,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -3313,9 +3312,9 @@
         }
       },
       "verification": {
-        "sdk_version": "0.4.41",
-        "verified_at": "2026-10-06T23:03:41Z",
-        "evidence": "sdk-0.4.41-2026-10-06.5",
+        "sdk_version": "0.4.42",
+        "verified_at": "2026-10-09T01:35:51Z",
+        "evidence": "sdk-0.4.42-2026-10-09",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -3504,6 +3503,6 @@
     }
   },
   "_synced_from_repo": "NextCommerceCo/campaign-cart-starter-templates",
-  "_synced_from_ref": "783329017c6994a94d11e46580c33bd052aabdb0",
-  "_synced_from_sha": "783329017c6994a94d11e46580c33bd052aabdb0"
+  "_synced_from_ref": "main",
+  "_synced_from_sha": "d5ff501ab57aef160a7108341de8a952006a28a4"
 }

package/contracts/effects.v1.json

@@ -6267,8 +6267,8 @@
       "sends": [
         {
           "destination": "{base-url}",
-          "what": "a GET for each built page under the served URL, to prove the local preview answers before it is recorded",
-          "when": "the packet's deploy target is local-serve and --base-url is a loopback origin naming the campaign's route root",
+          "what": "a GET for each built page under the served URL, to prove the preview answers before it is recorded, and on a hosted target a GET for each script and stylesheet the built pages load from that origin, to compare its bytes with the built output",
+          "when": "--base-url names the campaign's route root on a loopback origin (deploy target local-serve) or an https origin (any other deploy target; plain http only on a loopback host)",
           "requires_consent": false,
           "observed_in": [
             "no_session",
@@ -6281,7 +6281,7 @@
       ],
       "effect_test": "effects: record deploy",
       "test_scope": "full",
-      "notes": "Destructive: it replaces stages.deploy, stamped with the build fingerprint it probed, and the packet's deploy.preview_url. The requests stay on this machine: --base-url must be a loopback origin. Refused, writing nothing but the lifecycle entry, when the packet is not local-serve, the URL is not loopback or not the campaign's route root, a built page does not answer 2xx, polish is not recorded, build or Polish is owed again after a brief or CampaignSpec change or its record does not say which content it was made against, the built output changed since build was recorded, or the theme gate is blocked. The Build Context is read, not written."
+      "notes": "Destructive: it replaces stages.deploy, stamped with the build fingerprint it probed, and the packet's deploy.preview_url. On a local-serve packet the requests stay on this machine: --base-url must be a loopback origin. On any other deploy target --base-url is an https origin and the served scripts and stylesheets are compared by sha256 with the built output (HTML is not compared). Refused, writing nothing but the lifecycle entry, when the URL breaks those rules or is not the campaign's route root, a built page does not answer (2xx locally, 200 hosted), a served asset is missing or differs, polish is not recorded, build or Polish is owed again after a brief or CampaignSpec change or its record does not say which content it was made against, the built output changed since build was recorded or a record build of other output lands between the probe and the write (on either deploy target), or the theme gate is blocked. The Build Context is read, not written."
     },
     {
       "command": "record",
@@ -6300,8 +6300,8 @@
       "sends": [
         {
           "destination": "{base-url}",
-          "what": "a GET for each built page under the served URL, to prove the local preview answers before it is recorded",
-          "when": "the packet's deploy target is local-serve and --base-url is a loopback origin naming the campaign's route root",
+          "what": "a GET for each built page under the served URL, to prove the preview answers before it is recorded, and on a hosted target a GET for each script and stylesheet the built pages load from that origin, to compare its bytes with the built output",
+          "when": "--base-url names the campaign's route root on a loopback origin (deploy target local-serve) or an https origin (any other deploy target; plain http only on a loopback host)",
           "requires_consent": false,
           "observed_in": [
             "no_session",