@nextcommerce/campaigns-os 1.46.0 → 1.47.0

package/CHANGELOG.md

@@ -2,6 +2,154 @@
 
 Notable supported-surface changes are recorded here.
 
+## [1.47.0] - 2026-10-01
+
+### Changed
+
+- `contracts/effects.v1.json`: the `--force` notes on `start`,
+  `prepare-build` and `build` now say that `--force` also regenerates a stale
+  Design Source Package that the intake synthesized itself (#506). That holds
+  when the previous Assembly Report records origin `"synthesized"` and the
+  package bytes still match it. An adopted or hand-edited package is never
+  replaced. The declared writes already covered this path, so behaviour is
+  unchanged; only the notes were incomplete.
+- `compatibility.json` names the package version again. It still said 1.34.0
+  (#486). A unit test now fails when it differs from `package.json`.
+- Bundled skills carry revision `1.47.0+skills.1`, with each skill version
+  advanced one patch, and the local setup install command pins the 1.47.0
+  package. The skill text is unchanged.
+
+## [1.46.0+agent.11] - 2026-10-01
+
+### Changed
+
+- `doctor`'s `built_output.script_syntax` gate groups missing-script warnings
+  by the URL the browser resolves, not the raw src. Two spellings of one URL,
+  such as `check	out.js` and `checkout.js`, now give one
+  `built_output.script_syntax.missing_script` warning instead of two. One src
+  that names different files on pages in different folders still gives one
+  warning per file.
+- A `<script>` the page ends inside, with no `</script>`, is no longer parsed
+  by doctor or QA: the browser never runs a script element whose end tag never
+  arrives, so it can no longer block either. Doctor warns about it under the
+  new `built_output.script_syntax.unclosed_script` code, one warning per page,
+  because the page output is probably truncated.
+- A script symlink under `_site` is read by following the link only while its
+  real path stays inside the site root. A link whose target is outside the
+  site root is not read. Doctor warns under the new
+  `built_output.script_syntax.symlink_outside_site` code, naming the link, and
+  does not block. The gate lists such links in `scripts_outside_site[]`. The
+  rule is recorded in `docs/build-packet.md`.
+
+## [1.46.0+agent.10] - 2026-10-01
+
+### Fixed
+
+- `qa run --test-order` now follows a redirected order upsell mutation. When
+  the accept's POST to the order-upsells URL answered 307 or 308, the step
+  took the redirect hop as the mutation's response and judged the upsell
+  without the order body. It now waits for the redirect chain's final
+  response and judges from that body. A late body is matched to the step by
+  the request that started its redirect chain, so every hop of one redirected
+  POST counts as the step's request and a body from another request still
+  never does. A redirect whose chain has no final response is reported as no
+  mutation response, not as answered.
+
+## [1.46.0+agent.9] - 2026-10-01
+
+### Fixed
+
+- `qa run` analytics parity no longer blocks on `purchase-present` when the
+  operator did not pass `--analytics-candidate`. The automatic candidate (the
+  campaign root, or the first built entry) is not a receipt page, so a Purchase
+  cannot fire there. When that candidate fires no Purchase, `purchase-present`
+  is now `MANUAL_REVIEW`/`WARN`, and `evidence.page_mismatch` gives the reason
+  (`receipt_baseline_non_receipt_candidate` or `candidate_not_receipt`), the
+  candidate's source and its page type. An explicit `--analytics-candidate`,
+  or a built entry whose topology page type is a receipt, still blocks on a
+  missing Purchase. To compare Purchase, pass the candidate receipt with
+  `--analytics-candidate`.
+
+## [1.46.0+agent.8] - 2026-10-01
+
+### Fixed
+
+- The local setup command in `docs/local-setup.md` installed both the toolkit
+  and `next-campaign-page-kit` with `--save-dev`. In an existing page-kit
+  project that moved page-kit from `dependencies` to `devDependencies`, so
+  builds that run `npm ci --omit=dev` or set `NODE_ENV=production` no longer
+  installed it. The command now installs page-kit with `--save-exact` only and
+  the toolkit with `--save-dev --save-exact`, so a project that declares
+  page-kit under `dependencies` keeps it there. The README and quickstart
+  page-kit installs also pin exactly.
+- `tooling setup` now warns when the project declares page-kit only in
+  `devDependencies`, and prints the command that moves it back. The warning
+  appears in the text output and in a new `warnings` array in the `--json`
+  result; setup still proceeds.
+
+## [1.46.0+agent.7] - 2026-10-01
+
+### Changed
+
+- The vendored starter-template catalog is re-synced to
+  campaign-cart-starter-templates `3793b1d` (was `11352c3`). That brings in the
+  runtime-gated payment logos, the composable upsell pages, the `is_upsell`
+  opt-out on every bump include, and template verification evidence for
+  Campaign Cart SDK 0.4.40. Family certification freshness now reads 0.4.40 as
+  the verified SDK. The SDK support policy (minimum and preferred versions) is
+  unchanged.
+- `fixtures/certified-families` is regenerated at the new pin, and the shared
+  commerce brand contract's payment-chrome `asset_pin` moves with it. The
+  shipped asset bytes are unchanged. The payment-chrome repair text now says
+  to set `payment_flags.show_<method>: false` in the page frontmatter when a
+  logo from the starter `payment-logos.html` row is flagged, instead of
+  deleting markup. `upsell-payment-logos.svg` stays listed because the
+  starter still renders it ungated under `payment_flags.style: flat` and on
+  one select page.
+
+## [1.46.0+agent.6] - 2026-10-01
+
+### Fixed
+
+- `sdk storage-check` accepts a Campaign Cart release manifest whose SDK
+  version is above its supported range. Released manifests stamp their own
+  release version but declare an earlier supported range (v0.4.40 declares
+  0.4.38 only), and the check refused every one of them with "Manifest
+  source SDK version must equal supported maximum". The target SDK is still
+  judged against the declared range, so a target outside it reports unknown
+  (`target-outside-manifest-range`). A manifest whose SDK version is below its
+  supported maximum is still refused, because it cannot vouch for later
+  releases. The report keeps recording the manifest's SDK version and range
+  separately.
+
+## [1.46.0+agent.5] - 2026-10-01
+
+### Removed
+
+- `doctor` no longer warns with `built_output.sdk_markup.checkout_bump_is_upsell`
+  (added in `1.45.0+agent.5`). When a shopper selects an order bump on a
+  checkout page, it is added as a line item on the checkout order. With
+  `data-next-is-upsell="true"` that line is tagged as an upsell, so platform
+  order reports show upsell items apart from the core items. That tagging is
+  the intended default. The warning fired on every canonical starter checkout
+  with a bump and told the user to remove the attribute, which would report
+  the bump as a core item. Leave the attribute in place. A campaign that
+  should not tag a bump as an upsell opts out by passing `is_upsell: false` to
+  the bump include. Doctor reports no finding for the attribute either way.
+
+## [1.46.0+agent.4] - 2026-10-01
+
+### Changed
+
+- The `next-campaigns-qa` and `next-campaigns-build` skills now say which
+  checkout controls count as bound for `browser-commerce-structure`: a
+  required field bound only on a `type="hidden"` input, a disabled control, a
+  read-only input or read-only textarea, or a control with
+  `aria-disabled="true"` does not count, and QA reports it in `fields_bound.missing`. This is the rule QA
+  has applied since #540; the skills had not stated it. Bundled skills carry
+  revision `1.46.0+skills.2`, with each skill version advanced one patch. No
+  change to the CLI.
+
 ## [1.46.0+agent.3] - 2026-09-30
 
 ### Changed
@@ -135,9 +283,11 @@ Notable supported-surface changes are recorded here.
   downsell and receipt pages, and bumps without the flag, get no warning. The
   flag comes from the bump include's markup, and several starter bump includes
   write it unconditionally, so a canonical starter checkout with a bump shows
-  this warning. To clear it, remove `data-next-is-upsell="true"` from the bump
-  include in the campaign, unless the line really should be billed as an
-  upsell. It is a warning, not a blocker.
+  this warning. It was a warning, not a blocker. Its advice to remove
+  `data-next-is-upsell="true"` was wrong: tagging a checkout bump line as an
+  upsell is the intended default, so order reports show upsell items apart
+  from core items, and removing the attribute would report the bump as a core
+  item. The warning is retired in `1.46.0+agent.5`.
 
 ### Fixed
 

package/README.md

@@ -45,7 +45,7 @@ steps, in this order:
 
 ```bash
 mkdir "<route>" && cd "<route>"
-npm init -y && npm i next-campaign-page-kit
+npm init -y && npm i --save-exact next-campaign-page-kit
 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

package/compatibility.json

@@ -1,6 +1,6 @@
 {
   "package": "@nextcommerce/campaigns-os",
-  "version": "1.34.0",
+  "version": "1.47.0",
   "status": "developer-preview",
   "contracts": {
     "campaign_spec": "4.2-4.3",