@nextcommerce/campaigns-os 1.59.0 → 1.60.0

package/CHANGELOG.md

@@ -2,6 +2,122 @@
 
 Notable supported-surface changes are recorded here.
 
+## [1.60.0] - 2026-10-20
+
+### Changed
+
+- Publishes `1.59.0+agent.4`: the build-flow doc and quickstart describe the Campaigns App's offer-first setup.
+- Publishes `1.59.0+agent.5`: hosted all-template guidance names `record deploy --base-url <route root>` for both deploy targets.
+- Publishes `1.59.0+agent.6`: the progress snapshot binds QA to its build through `qc_build_fingerprint`, and the polish gate reads the recorded build only from `stages.assembly.build_fingerprint` (campaigns-os#672).
+- Publishes `1.59.0+agent.7`: `run status` always names `next` as the next command (campaigns-os#673).
+- Publishes `1.59.0+agent.8`: Campaigns OS adopts next-campaign-page-kit 0.3.0, keeps 0.2.x targets working, and doctor reports page-kit's `assetWarnings`. The first 0.3.0 build can change the build fingerprint; run `record build` again.
+- Publishes `1.59.0+agent.9`: the starter catalog is re-synced to campaign-cart-starter-templates `3987b18` (build-time promo banner, `next_step` prefetch).
+- Publishes `1.59.0+agent.10` and `1.59.0+agent.11`: the Playwright 1.64.1 / acorn 8.19.0 lockfile bump and repository workflow action bumps (campaigns-os#675, campaigns-os#679).
+- Publishes `1.59.0+agent.12`: `install-skills` installs `next-campaigns-sdk-bump`, the 0.4.x Campaign Cart bump procedure (campaigns-os#677).
+- Publishes `1.59.0+agent.13`: a CampaignSpec-only change keeps the Polish review of the kept output (campaigns-os#668).
+- The `next-campaigns-sdk-bump` skill takes the feedback from its first live bump (campaigns-os#683). When the release range removes a feature the campaign uses, the skill now looks for a documented replacement and stops to ask rather than deleting the call. It guards every `next:initialized` listener for cached reloads, which 0.4.42 no longer replays, and proves them on fresh and cached loads. It judges a legacy page by what drives its cart and checkout, not by the Campaigns analytics script the 0.4.x SDK loads itself, and it explains a storage manifest whose range stops below the target tag. It also names the QA portal post and `--local-only`, keeps `qa-output/` out of commits, mentions `qa install-browser`, and triggers on bump requests in repositories that have their own BUMP.md.
+- Bundled skills advance to `1.60.0+skills.1`.
+
+## [1.59.0+agent.13] - 2026-10-19
+
+### Fixed
+
+A CampaignSpec-only change no longer throws away a Polish review of pages it did not change (campaigns-os#668). Before, `record build --deviation-reason` recorded the build, but Polish stayed owed after the re-intake (or `record spec`). The next `qa run` then stopped on `polish.evidence_missing`, and the agent had to retake the same screenshots and re-record the same findings.
+
+Now `record build --deviation-reason` restores the Polish record that the change moved to history, stamped with the current inputs, when all of the following hold:
+- the build records the exact output that Polish reviewed (same build fingerprint and source package);
+- the record was a completed Polish;
+- only the CampaignSpec changed, not the brief's presentation.
+
+These are unchanged:
+- QA stays owed, because the CampaignSpec changed.
+- A presentation change, a different build, or a build recorded without the deviation reason still owes a new Polish.
+- The build is still recorded with a warning and the operator's reason.
+
+## [1.59.0+agent.12] - 2026-10-19
+
+### Added
+
+`install-skills` now installs `next-campaigns-sdk-bump`, so an agent told "bump this campaign to SDK 0.4.x" has a shipped procedure to follow instead of one written into the ticket (campaigns-os#677). It covers a 0.4.x to later 0.4.x Campaign Cart bump on page-kit and static repos, and it stops at a 0.3.x pin or the legacy Campaigns script, because moving those is migration work. The steps:
+
+- Find every pin: `_data/campaigns.json` and loaders that hard-code their version on page-kit repos, or `sdk repin` scoped to the funnel folder on static repos.
+- Read the release diff against the campaign's own code, including where its purchase event comes from.
+- Run `sdk storage-check` with the target tag's manifest.
+- Run `doctor --built`, or `doctor --packet` when there is a Build Packet.
+- Prove the bump on a preview, with the browser pinned to the store's main market and each test order approved.
+- Hand back what is not proven, on the ticket or the pull request, never in the served tree.
+
+It adds no write, send or order capability. Bundled skills advance to `1.59.0+skills.4`.
+
+## [1.59.0+agent.11] - 2026-10-19
+
+### Changed
+
+Repository workflows move `actions/create-github-app-token` from 3.2.0 to 3.3.0, `actions/upload-artifact` from 7.0.1 to 7.0.2 and `actions/download-artifact` from 8.0.1 to 8.0.2 (campaigns-os#679). This changes repository CI only, and the published package is unchanged.
+
+## [1.59.0+agent.10] - 2026-10-19
+
+### Changed
+
+The lockfile moves Playwright from 1.63.0 to 1.64.1 and acorn from 8.18.0 to 8.19.0 (campaigns-os#675). Both stay within the ranges `package.json` already declares, so an installed toolkit resolves the same versions on a fresh install. Playwright drives `qa run --browser` and polish capture. acorn parses page scripts for doctor's `built_output.script_syntax` check, and 8.19.0 now rejects additional subscripts before the arrow in async arrow functions.
+
+## [1.59.0+agent.9] - 2026-10-19
+
+### Changed
+
+The vendored starter catalog is re-synced to campaign-cart-starter-templates `3987b18` (was `d5ff501`). That range carries:
+- campaign-cart-starter-templates#229: step and select pages prefetch `next_step` rather than the post-payment `next_url`.
+- campaign-cart-starter-templates#234: every family renders the promo banner at build time from `promo_banner` frontmatter. The `<promo-banner>` web component and `promo-banner.js` are gone, along with the layout shift they caused.
+- #228, #230, #235 and #237: the 5.0 multi-step fixture specs and recertified SDK 0.4.42 evidence. Each certified family now records `sdk-0.4.42-2026-10-16.2`.
+
+The certified-family fixtures are regenerated at the pin with page-kit 0.2.0, which is what the starter repository still pins. The payment-chrome `asset_pin` moves to `3987b18`. Its five images have the same bytes there, so no hash changed. The SDK pin (0.4.42), the support policy and the CampaignSpec fixtures do not change.
+
+## [1.59.0+agent.8] - 2026-10-19
+
+### Changed
+
+Campaigns OS adopts next-campaign-page-kit 0.3.0 and keeps 0.2.x targets working. The new-folder installs in `docs/local-setup.md`, the quickstart and the README pin `next-campaign-page-kit@0.3.0`; the quickstart and README installed it unpinned, and `docs/local-setup.md` pinned 0.2.0. The example target declares page-kit as a runtime dependency at that pin.
+
+Doctor's build summary check reads the top-level `assetWarnings` array that page-kit 0.3.0 adds to `campaign-build --json`. 0.3.0 neither builds nor copies `.html` files under a campaign's `assets/`, and lists each one there as `ASSET_IGNORED`, never in `pages[].warnings`. Doctor read only `pages`, so such a build printed "no build errors or shape warnings". Each entry for the campaign is now a non-blocking `built_output.build_asset_warning` naming the file, because a link or iframe to it 404s on the built site, and the ready line prints only when there are neither page nor asset warnings. The build prompt and the Campaign Build skill name `assetWarnings` and `ASSET_IGNORED`.
+
+`spec derive` and doctor's built-page lookup follow the target's installed page-kit, read from `node_modules/next-campaign-page-kit/package.json`, when they discover source pages. On 0.3.0 and later they skip `.html` files under the campaign's top-level `assets/`, so a page is no longer bound to a file page-kit does not build. A target on 0.2.x, or with no readable install, keeps the 0.2.x rule. The stray-file text in `docs/build-packet.md` and in the campaign identity gate's message now says that unpruned `_site/` output and an `assets/` `index.html` built as a page are page-kit 0.2.x behaviour; the `stray_files` gate is unchanged. Bundled skills advance to `1.59.0+skills.3`.
+
+### Migration
+
+The first build on page-kit 0.3.0 can change the build fingerprint with unchanged source: 0.3.0 removes `_site/<slug>/` before it builds, so output left by earlier builds disappears, and it no longer copies `.html` files under `assets/` into `_site/`. Run `record build` again after that build and expect polish, deploy and QA to be owed again. That is the fingerprint doing its job.
+
+## [1.59.0+agent.7] - 2026-10-15
+
+### Fixed
+
+`run status` now always names `next` as the next command: `progress.next_command` is `campaigns-os next --packet <packet> --json`. Before, once every stage status the Assembly Report records read completed or skipped, it named `run end` even when `next` had not reached done: after a CampaignSpec edit with no `record spec` (`next` answers build), on a report written before input stamps existed, and after a rebuild with no `record build`. `next` decides whether the campaign is done, and once it is, with a run session active, it names `run end` as a required action. `run status` stays read-only, and `progress.incomplete_stages` still lists the recorded statuses (campaigns-os#673).
+
+### Changed
+
+`next` returns a blocked or unavailable prepare-build gate's recovery-only answer from one branch, whether the stage was named or picked; `requested_stage` still appears only when a stage was named. Doctor's status, `next`'s status and doctor's `next` block read one readiness ladder (`blocked`, then `ready_with_waivers`, `ready_with_warnings`, `ready`), each over its own errors and warnings. The output of `next` and doctor is unchanged.
+
+## [1.59.0+agent.6] - 2026-10-15
+
+### Fixed
+
+The progress snapshot binds a QA record to its build through the field `next`, the QA gate and the Run Record already read: `stages.qa.evidence.qc_build_fingerprint`, falling back to `source_build_fingerprint`. It used to read only `source_build_fingerprint`, which QA writes only when the placeholder-text gate records an outcome. A `qa run` without `--browser`, or with that gate skipped, therefore showed `qa.binding: "unconfirmed"` and a qa stage row with `build_binding: "unconfirmed"` and no fingerprint, although QA was recorded for the current build. Records that bind no build, or a different one, still read `unconfirmed`.
+
+The polish gate reads the recorded build only from `stages.assembly.build_fingerprint`. It no longer falls back to `stages.assembly.artifact_fingerprint`, a top-level `build_fingerprint` or a top-level `artifact_fingerprint`, which no toolkit version writes. A report carrying only one of those used to make doctor print "Build output fingerprint matches stages.assembly.build_fingerprint" and report `polish.evidence_missing`, while `record polish`, `record theme`, `record deploy` and `polish capture` refused the same report as having no recorded build. Doctor now reports `polish.build_fingerprint_missing` for it, as they do.
+
+`npm run smoke:polish-capture` passes again. It wrote its page outside `_site/<slug>/` with a placeholder build fingerprint, which `polish capture` refuses; it now writes `_site/runtime-packet-demo/landing/` and records that tree's real fingerprint. A failed capture prints the underlying error after the smoke's failure message (campaigns-os#672).
+
+## [1.59.0+agent.5] - 2026-10-15
+
+### Fixed
+
+The hosted all-template guidance now matches what `next` has done since 1.59.0, where a hosted preview records its deploy with `record deploy` before QA. The Campaign Polish skill, `docs/build-packet.md` and the README no longer say that the hosted preview URL satisfies the deploy stage or that `record deploy` takes only a loopback route root; they name `record deploy --base-url <route root>` for both deploy targets and leave the order to `next`. A forced `next deploy` or `next qa` on an all-template hosted packet whose preview URL is loopback or the production page now prompts for `qa policy set --preview-url`, as its next actions and doctor already did and as an unset preview URL already did, instead of the generic deploy prompt or a QA command against that URL; the QA prompt then sends the agent to `next`, which records the deploy before QA. The done prompt names `record deploy` for both deploy targets in place of an instruction to record the hosted URL by hand. Bundled skills advance to `1.59.0+skills.2`.
+
+## [1.59.0+agent.4] - 2026-10-14
+
+### Changed
+
+The build-flow doc and the quickstart describe the Campaigns App's offer-first setup: Create Campaign, then Add Offer on the campaign's Offers tab. Selecting store products in an Offer creates one campaign product (a package in the API) per variant at its store price when the Offer is saved, and later Offers reuse it. The dashboard's Packages tab is now Products. The rule against separate `1x` / `2x` / `3x` packages for tier pricing is unchanged, and campaigns set up over the Admin API still create packages before Offers.
+
 ## [1.59.0] - 2026-10-09
 
 ### Changed

package/README.md

@@ -13,7 +13,7 @@ This toolkit gives campaign developers and AI coding tools a clear path for asse
 7. Hand off to `next-campaigns-build`.
 8. Run build/lint and record the build with `campaigns-os record build`, then install the Campaigns OS Playwright browser once with `campaigns-os qa install-browser`.
 9. Run `next-campaigns-polish`, serve the current build, run the mandatory `campaigns-os polish capture` producer, then record Polish with `campaigns-os record polish --evidence <file>`.
-10. Deploy a preview. For a local preview (`--deploy-target local-serve`), serve the current build and record it with `campaigns-os record deploy --base-url <loopback route root>`; a later `record build` of different output makes the deploy owed again. `record deploy` takes only a loopback route root; for a hosted preview, deploy through your host and follow `next` for what to record.
+10. Deploy a preview and record it with `campaigns-os record deploy --base-url <route root>`: for a local preview (`--deploy-target local-serve`), serve the current build and pass its loopback route root; for a hosted preview, deploy through your host and pass the https route root. A later `record build` of different output makes the deploy owed again.
 11. Run `next-campaigns-qa` against the tested URL.
 12. Record launch blockers and follow-up work.
 
@@ -45,7 +45,7 @@ steps, in this order:
 
 ```bash
 mkdir "<route>" && cd "<route>"
-npm init -y && npm i --save-exact next-campaign-page-kit
+npm init -y && npm i --save-exact next-campaign-page-kit@0.3.0
 npx campaign-init --non-interactive --template <family> --slug "<route>" --name "<campaign name>"
 npm install --save-dev --save-exact @nextcommerce/campaigns-os@<version>
 npx --no-install campaigns-os tooling status --platform claude
@@ -303,7 +303,7 @@ npm run campaigns-os -- next polish --packet <packet.json> --report <assembly-re
 npm run campaigns-os -- polish capture --packet <packet.json> --base-url <served-current-build-url>
 npm run campaigns-os -- record polish --packet <packet.json> --evidence <polish-evidence.json>
 npm run campaigns-os -- record theme --packet <packet.json>
-npm run campaigns-os -- record deploy --packet <packet.json> --base-url <loopback-route-root>
+npm run campaigns-os -- record deploy --packet <packet.json> --base-url <route-root>
 npm run campaigns-os -- record brief --packet <packet.json> --brief <campaign-build-brief.yaml>
 npm run campaigns-os -- record spec --packet <packet.json>
 npm run campaigns-os -- next qa --packet <packet.json> --report <assembly-report.json>
@@ -325,8 +325,9 @@ commands continue to record their own stages.
 
 Record a stage's completion with `record setup`, `record build` (after every
 rebuild), `record polish --evidence <file>`, `record theme` (once the brand layer
-is linked) and, for a local preview, `record deploy --base-url <loopback route
-root>`, rather than hand-editing `.campaign-runtime/build-context.json` or
+is linked) and `record deploy --base-url <route root>` (a loopback URL for a
+local preview, https for a hosted one), rather than hand-editing
+`.campaign-runtime/build-context.json` or
 `.campaign-runtime/assembly-report.json`. A recorded deploy is bound to the
 build it probed, so a later `record build` of different output makes it owed
 again. When the brief or the CampaignSpec changes after stages are recorded, save

package/compatibility.json

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

package/contracts/commerce-surface-catalog.json

@@ -849,8 +849,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -861,7 +861,7 @@
         "id": "template-reference-apollo",
         "family": "apollo",
         "version": "sdk-0.4.38-composable-upsells-2026-09-25",
-        "source_commit": "1a3bf7218e7f10ef5733ceba84d2856eeca2cfbd",
+        "source_commit": "ac529485f0a728cf9c6ac8dbcde81041bd1c6ba8",
         "provenance_url": "https://raw.githubusercontent.com/NextCommerceCo/campaign-cart-starter-templates/main/docs/template-references/apollo/README.md",
         "contract_path": "contracts/commerce-surface-catalog.json",
         "standard_viewport_refs": [
@@ -1273,8 +1273,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -1584,8 +1584,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -1887,8 +1887,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -2228,8 +2228,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -2667,8 +2667,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -3023,8 +3023,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -3313,8 +3313,8 @@
       },
       "verification": {
         "sdk_version": "0.4.42",
-        "verified_at": "2026-10-09T01:35:51Z",
-        "evidence": "sdk-0.4.42-2026-10-09",
+        "verified_at": "2026-10-16T23:13:26Z",
+        "evidence": "sdk-0.4.42-2026-10-16.2",
         "status": "certified",
         "source": "template-verification.json"
       }
@@ -3504,5 +3504,5 @@
   },
   "_synced_from_repo": "NextCommerceCo/campaign-cart-starter-templates",
   "_synced_from_ref": "main",
-  "_synced_from_sha": "d5ff501ab57aef160a7108341de8a952006a28a4"
+  "_synced_from_sha": "3987b18a356cb961b06c94b2035622bafe938316"
 }