@nextcommerce/campaigns-os 1.47.0 → 1.50.0

package/contracts/supported-surface.json

@@ -1,6 +1,6 @@
 {
   "_note": "The downstream contract manifest. Everything listed here is SUPPORTED SURFACE: consumers (campaigns-agent, campaign-builder, the private ops repo, page-kit campaign repos) may depend on it, and changing it is a deliberate act — hashed entries require a surface_version bump in the same change (check-supported-surface.mjs --base, mirroring the skills.json bump gate), named entries must keep existing at their path, cli_commands must keep resolving in the CLI dispatch, package_exports must stay exported, and every entry must ship in the npm pack (files[] coverage). Anything NOT listed here — src/** internals, scripts/** checkers, examples/**, prompts/**, contracts/** other than this file and the entries named[] below (the orientation contract, the release ledger, and the consumer-facing orientation fixtures) — is implementation: consumers may read it for context but must not build on it, and it can change without notice. Rationale and the compatibility promise: docs/supported-surface.md.",
-  "surface_version": "1.47.0",
+  "surface_version": "1.50.0",
   "package_exports": [
     "./commercial-journey",
     "./commercial-parity",
@@ -66,7 +66,7 @@
       "sha256": "f310c1b7844d9b1994864d15858ff0c6f17efc1e5285ba193d181bdb2dd4be2f"
     },
     "schemas/campaign-runtime-build-packet.v0.schema.json": {
-      "sha256": "47c2899f409ed5927cf410bddd63e7bb8a9d154eabf7a07455777aed118212e9"
+      "sha256": "5002529c5979c4d8fef7e298de82ebdf625ffbd11f5284ba684d96d173788d62"
     },
     "schemas/campaign-spec.v4.schema.json": {
       "sha256": "af56c3de638d3c4e1fd5df8c2d733754d9ad16caa23b5bec92ce3a6f71bd0271"
@@ -84,7 +84,7 @@
       "sha256": "3c40fd79f218d1b95f0424f9a2b67db140a306329e2ca02793e2740d3afded59"
     },
     "schemas/campaigns-os-qa-verdict.v0.schema.json": {
-      "sha256": "ec4514e81a791a63bc0b358d7977aa823f3c5524e0f5caaba2712e66f262e18a"
+      "sha256": "8c689d29850b2b894c17438ee4411363033bae6f805820af53b7a04a5693d0e0"
     },
     "schemas/campaigns-os-doctor-output.v0.schema.json": {
       "sha256": "87866e619d2a18f01a208a1682cb14a2079f61df51c642f4e1902b6e6bce0ce5"
@@ -120,7 +120,7 @@
       "sha256": "dfc9abed38d456969e47a21f606d308a03bdf036f3466f7d6e47a602747dacf4"
     },
     "contracts/effects.v1.json": {
-      "sha256": "5f8c6f2f88fc9e0c11c09e265640071d3c1d81fd96c6e05283ed5cfed21d1d59"
+      "sha256": "75cdd0bc33788d8d6af10c995f362987725f622bf42700f1b70b39bbd87e6878"
     },
     "schemas/campaigns-os-effects.v1.schema.json": {
       "sha256": "3eadd22169ab98bc7c2f682af2751267605170581182158d96be035b0cfe44dc"

package/contracts/template-brand-contract.shared-commerce.v0.json

@@ -55,7 +55,7 @@
       },
       "asset_pin": {
         "repo": "NextCommerceCo/campaign-cart-starter-templates",
-        "sha": "3793b1de3b77cc31dffe9176f47e8e99ea6134aa",
+        "sha": "37a8d945db4c360739ded98348814cfd632da94f",
         "path": "src/<family>/assets/<asset>",
         "note": "asset_sha256 is the sha256 of each shipped starter asset at this commit (the commerce-surface-catalog _synced_from_sha pin; the bytes are identical across every family). A served asset whose bytes hash to the shipped value is the untouched starter asset and counts as residue even though its markup names no method; different bytes mean it was edited in place. check-template-doctrine verifies these hashes against the pinned checkout."
       },

package/docs/brand-theme-bridge.md

@@ -151,8 +151,9 @@ When `theme inspect` reports `can_generate: true` and the campaign ships
 commerce pages (checkout/upsell/downsell/receipt), the gate **blocks**
 `next polish`, `next deploy`, `next qa`, and `qa run` until one of:
 
-- the brand layer is generated and recorded as applied
-  (`report.theme.status: applied`, `load_order: after-next-core`), or
+- the brand layer is generated, linked and recorded as applied with
+  `campaigns-os record theme --packet <p>` (`report.theme.status: applied`,
+  `load_order: after-next-core`), or
 - an explicit waiver is recorded:
   `campaigns-os theme waive --packet <p> --reason "<why>" --waived-by "<named human>"`
   (optionally `--expires-at <ISO>`; placeholders such as "operator" are refused), or
@@ -197,8 +198,12 @@ If a fresh `brand-theme.css` exists:
 3. Preserve SDK-owned runtime surfaces: `data-next-*`, package selectors,
    payment fields, totals, submit controls, receipt templates, route meta tags,
    and SDK JavaScript.
-4. Record `report.theme.status`, `css_path`, `commerce_pages`, `load_order`,
-   and evidence.
+4. Rebuild, run `campaigns-os record build --packet <p>`, then
+   `campaigns-os record theme --packet <p>`. It reads each built commerce
+   page's stylesheet links and records `report.theme.status`, `css_path`,
+   `commerce_pages`, `load_order` and evidence. It refuses, writing nothing,
+   when a page that loads `next-core.css` does not load the brand layer after
+   it, or when no built commerce page loads `next-core.css`.
 
 ### Where next-core.css belongs
 
@@ -212,8 +217,9 @@ stylesheets off those pages and list them only in the frontmatter styles of
 the pages that render family components, often just checkout.
 
 `report.theme.commerce_pages` is the list of pages where the brand layer was
-applied, recorded by the build. Record the pages you actually scoped, for
-example `commerce_pages: ["checkout"]`. The theme gate does not compare this
+applied. `record theme` writes it from the built pages: every commerce page
+that loads `next-core.css`, for example `commerce_pages: ["checkout"]`. A page
+that loads neither stylesheet is left out and noted in the evidence. The theme gate does not compare this
 list with the funnel. It passes on `report.theme.status: applied` with
 `load_order: after-next-core`. The gate's own `commerce_pages` output is a
 different field: every checkout, upsell, downsell, receipt or thank-you page

package/docs/build-packet.md

@@ -970,8 +970,9 @@ starter palette is acceptable>" --waived-by "<named human>"`, optionally
 (status and severity — never `fail`) and keeps the shipped palette visible in
 the verdict; or hand-author the brand
 layer — write `brand-theme.css`, list it after `next-core.css` in commerce-page
-frontmatter styles, rebuild, and record `report.theme.status: applied` with
-`load_order: after-next-core`. Nothing waives the gate on the operator's
+frontmatter styles, rebuild, `record build`, and `record theme`, which records
+`report.theme.status: applied` with `load_order: after-next-core` from the
+built pages. Nothing waives the gate on the operator's
 behalf. See [Brand Theme Bridge](./brand-theme-bridge.md) for both lanes in
 full.
 
@@ -1237,7 +1238,9 @@ loopback host (`127.0.0.1`, `[::1]`) with a ready line naming the
 `http://localhost:<port>/` fallback, and warns (`deploy.local_serve_url`) when
 the recorded URL is neither.
 `next` at the deploy stage then hands off a serve-locally prompt and action
-instead of a ship-to-host one. The directory to serve is `_site/`; for a
+instead of a ship-to-host one, and the served URL is recorded with
+`campaigns-os record deploy --packet <p> --base-url <url>` (the record command
+table below). The directory to serve is `_site/`; for a
 root-served campaign (`campaign.route_root: "/"`) the handoff adds that pages
 are served at site-root paths while assets keep the `/<public_route_slug>/`
 prefix, so `_site/` needs the same rewrite of root-level page routes onto
@@ -1453,7 +1456,7 @@ Each `manifest.pages[]` entry MAY carry a `source_hash` field — the sha256 hex
 Behavior:
 
 - Optional on the producer side. Producers that don't emit `source_hash` (pre-Slice-6 manifests, template-stock, hand-authored) keep working; doctor's drift check is silent without a hash to compare.
-- Warning severity only. A drift never blocks a build — the operator decides whether to re-run the producer to refresh the manifest or accept the local edits.
+- Warning severity only. A drift never blocks a build. The hash doctor compares is the one intake recorded in the packet, so editing the manifest alone does not clear the warning: re-running `start` or `prepare-build` with `--force` records the current file, and also clears recorded stage evidence. A revision made after build belongs in the page-kit source under `src/<route>/`; the source HTML stays the design provenance.
 - The warning names the file path and includes both hashes (truncated to 12 chars) so the operator can confirm which file diverged without re-running the producer.
 
 ### Reference AI-generated producer
@@ -1609,6 +1612,8 @@ hand-editing `.campaign-runtime/` JSON:
 | `campaigns-os record setup --packet <p>` | Build Context `scaffold.required=false` (`handoff_skill` next-campaigns-build) and `stages.setup` completed | the campaign output directory (`assembly.output_dir`) does not exist, or there is no Build Context or Assembly Report |
 | `campaigns-os record build --packet <p>` | `stages.assembly` completed with `build_fingerprint` = doctor's `derived.build_output_fingerprint.value`, `source_package_material_fingerprint` = the report's Design Source Package material fingerprint when present, and `stages.polish` reset to `required` (`required_by` build, `required_for` qa) unless its evidence is bound to this exact output | doctor cannot compute the fingerprint (no `_site/<public_route_slug>/`), setup is still required, or `stages.setup` is not terminal |
 | `campaigns-os record polish --packet <p> --evidence <file>` | `stages.polish` from the file (`docs/polish-evidence.md` §7: completed, blocked or skipped), bound to doctor's current fingerprint; `report.theme.repair_loop_defect` when the file sets it | build is not recorded for the current output, the file has a shape error (named by field), or, for a completed status, the polish gate doctor evaluates would not pass on the result |
+| `campaigns-os record theme --packet <p>` | `report.theme`: status `applied`, `load_order` `after-next-core`, `css_path`, `commerce_pages` and per-page evidence read from each built commerce page's stylesheet links; any earlier theme waiver is cleared | build is not recorded for the current output, the campaign ships no commerce pages, a built commerce page that loads `next-core.css` does not load `brand-theme.css` (or `checkout-brand.css`) after it or links one missing from the built output, or no built commerce page loads `next-core.css` |
+| `campaigns-os record deploy --packet <p> --base-url <url>` | the packet's `deploy.preview_url` and `stages.deploy` completed with the URL in `outputs` and one evidence line per built page that answered (each page is requested under the URL first) | the packet is not `local-serve`, the URL is not a loopback origin naming the campaign's route root, a built page does not answer 2xx, polish is not recorded, the built output changed since build was recorded, or the theme gate is blocked |
 
 Each command also refuses a stage `next` has not reached: while doctor's
 prepare-build gate is set (`next` answers prepare-build) or while an earlier

package/docs/campaign-build-brief.md

@@ -62,34 +62,31 @@ Doctor warns when generated guided drafts still need answers, a brief allows pay
 
 Existing template residue, theme, pricing, and built-output checks continue to run. The brief gives those checks business intent instead of replacing them.
 
-## Content Claims Are Reviewed, Not Enforced
-
-The doctor scans built output for content residue and raises some of it as
-warnings: every content anti-pattern under the warning code
-`content_residue.anti_pattern` (the finding ids include `invented_counts`
-for invented counts and ratings, `verified_buyer_chrome` for "Verified
-Buyer" and similar review chrome, `byline_persona`, `borrowed_authority`,
-`press_marquee`, and `science_theater`; all of them are warning-only), and
-promo copy claiming a discount above the CampaignSpec maximum (`template_contract.discount_claim_residue`, or
-`template_contract.discount_claim_unverified` when the spec sets no maximum).
-
-These stay warnings on purpose, and nothing downstream reads them. There is no
-blocker, no `blocked_stages` entry, no QA assertion, and no test-order gate
-keyed on any of them. A build carrying all of them can pass doctor, pass QA,
-and deploy.
-
-The toolkit flags the copy; it does not adjudicate it. **Responsibility for
-every claim on the page — proof counts, review chrome, discount percentages,
-and the rest — sits with the operator and the client, not with Campaigns OS.**
-Use the brief to record which claims are approved and which language is
-forbidden (see the high-impact questions above), and treat a content warning as
-a prompt to check the brief, not as a gate that will stop the build if you
-ignore it.
-
-The hard content checks are separate and do block: the needs-merchant-input
-marker (`content_residue.needs_merchant_input`) and countdown chrome rendered
-without verified offer urgency on a brief-backed build
-(`content_residue.unverified_urgency`).
+## The Merchant's Own Claims Are Not Reviewed
+
+Proof and urgency content the merchant supplies is the merchant's
+responsibility, not Campaigns OS's: reviews and testimonials, ratings and
+counts, "Verified Purchase" labels, recent-purchase popups, stock counters,
+countdowns, guarantees and press mentions. The doctor does not scan for it and
+QA does not assert on it. When the prepared source design carries these
+elements, the build reproduces them as designed. The starter templates ship
+without some of them; that is not a reason to drop the source's.
+
+What the doctor does scan built output for is template residue: the starter
+templates' own demo strings and bracket-style stubs
+(`content_residue.demo_residue`, a warning). It also warns on promo copy
+claiming a discount above the CampaignSpec maximum
+(`template_contract.discount_claim_residue`, or
+`template_contract.discount_claim_unverified` when the spec sets no maximum),
+because that copy disagrees with the campaign's own pricing. Nothing downstream
+blocks on either.
+
+Two content checks do block: the needs-merchant-input marker
+(`content_residue.needs_merchant_input`), and, on a brief-backed build only,
+starter countdown chrome the brief payload does not verify
+(`content_residue.unverified_urgency`). Use the brief to record which claims
+are approved and which language is forbidden (see the high-impact questions
+above).
 
 ## QA Policy Scope
 

package/docs/local-setup.md

@@ -1,11 +1,16 @@
 # Local campaign setup
 
-For a new campaign, choose its working folder and run this from that folder:
+For a new campaign, create an empty working folder and run this from it:
 
 ```sh
-npm install --save-exact next-campaign-page-kit@0.2.0 && npm install --save-dev --save-exact @nextcommerce/campaigns-os@1.47.0 && npx --no-install campaigns-os tooling setup --target . --platform claude
+npm init -y && npm install --save-exact next-campaign-page-kit@0.2.0 && npm install --save-dev --save-exact @nextcommerce/campaigns-os@1.50.0 && npx --no-install campaigns-os tooling setup --target . --platform claude
 ```
 
+`npm init -y` gives the folder its own `package.json`. Without one, npm
+installs into the nearest parent folder that has a `package.json` or
+`node_modules`, so a campaign folder created inside another project would add
+page-kit and the toolkit to that project instead.
+
 Review the release source/provenance before installation as described in
 `AGENTS.md`. npm installs the dependencies first; `--no-install` then runs only
 the project's installed CLI. Page-kit stays a runtime dependency and the

package/docs/orientation-contract-reference.md

@@ -26,7 +26,7 @@ Ledger schema id: `campaigns-os-release-ledger/v1`
 Change policy version: `1.0.0`  
 Reason-code vocabulary version: `1.0.0`  
 Limits version: `1.0.0`  
-Supported surface at generation time: `1.47.0`
+Supported surface at generation time: `1.50.0`
 
 ## Forward compatibility
 

package/docs/qa-and-test-orders.md

@@ -55,9 +55,10 @@ the toolkit runs that loop in a fixed order:
    with it locally (the parity step renders it to a temp dir, and the deploy
    host renders it from the committed source).
 2. **Serve and prove.** Serve `_site/` on localhost (the `next deploy` handoff
-   names the directory and any root-route rewrite), record the URL on
-   `deploy.preview_url`, then run `polish capture`, `qa run --browser`, and the
-   typed-card order paths against it.
+   names the directory and any root-route rewrite) and run `polish capture`
+   against it. Once polish is recorded, `record deploy --packet <p> --base-url
+   <url>` records the URL on `deploy.preview_url` and the deploy stage; then run
+   `qa run --browser` and the typed-card order paths against it.
 3. **Prove the pin on the production output.** Before committing, run
 
    ```bash
@@ -96,6 +97,32 @@ recapture. A hosted target (`netlify`, `cloudflare-pages`, …) is unaffected:
 its build stage renders production as before and `page-kit parity` refuses the
 packet (`local_proof.parity.not_local_serve`).
 
+### Missing evidence carried forward on the local preview
+
+On a `local-serve` packet served from a loopback host (`localhost`,
+`127.0.0.1`, `[::1]`, for both `deploy.preview_url` and `--base-url`), some
+missing evidence is carried forward as a warning instead of blocking the
+loop. The campaign must still prove its commerce there: store and campaign
+binding, routes, SDK loading, prices and a typed-card order. Only these
+checks are carried forward:
+
+| Check | When |
+| --- | --- |
+| `polish.evidence_missing`, `polish.report_missing` | Polish was never recorded for this build. |
+| `polish.hidden_eager_media.no_capturable_routes` | Every mapped page is template stock (`skip_reason`), so polish capture has no design route to capture. |
+| `polish.hidden_eager_media.capture_malformed` | Only when no page-load capture was recorded at all. |
+| Template-residue severity | With `theme_gate.nothing_generatable`, the starter template is the design, so residue findings are warnings rather than blockers. |
+
+A carried-forward gate has status `carried_forward`. Doctor reports it as a
+warning starting "Carried forward on the local preview"; `next` moves past
+polish to deploy and QA; QA records it as a `warn` row, so the verdict is at
+best `ready_with_exceptions`. The evidence is reported as missing, never as
+passed. Any other check keeps its meaning. A hosted preview or production
+packet, and a `local-serve` packet served from any other host, gets the strict
+gates. `record polish` and the waiver commands also keep them strict. Progress
+snapshots record a carried-forward gate as `not_applicable`, because their
+schema has no carried-forward state.
+
 ## Resolve
 
 Use resolve before a full run:
@@ -482,7 +509,15 @@ the three checks and each `evidence.checks[]` entry carries `kind`
 (`family_shell` or `sdk_wiring`).
 The upsell and checkout bundle price checks count the SDK's
 `[data-next-bundle-display*='price']` alongside the contract's price rows; a
-hidden, zero-size or empty bundle-display node does not count.
+hidden, zero-size or empty bundle-display node does not count. A checkout that
+shows no price because QA opened it directly, with an empty SDK cart and no
+package selection of its own, is `skipped` rather than failed:
+`pricing.checkout_price_visible` records `cart_count` and
+`checkout_selection_surface` and says so. That checkout's cart is filled on
+an earlier page, for example by a landing link carrying `forcePackageId`, and
+the test order enters it from there. A checkout with its own package
+selection, or a filled cart, still fails when no price shows. If the cart
+probe itself fails, the row stays failed and records `empty_cart_probe_error`.
 Promoted template families must also have
 `contracts/template-brand-contract.<family>.v0.json`; QA emits a blocker if the
 selected family is missing its brand/residue/pricing contract instead of
@@ -1749,6 +1784,17 @@ shared real inbox rather than a synthetic one). When neither is set, the runner
 falls back to a single stable synthetic address — still one reused customer, but
 not deliverable.
 
+Reusing one customer has one cost. The platform refuses an order whose customer,
+items and total match one it accepted or is still processing in the last 30
+minutes ("Duplicate order detected, order not created"). A successful test order
+does not hold that window, so the paths of one run do not collide. Two QA runs
+against the same campaign at once do, and so can a rerun soon after an attempt
+that died mid-submit. QA reports it on the path's `browser-test-order` row as
+`order create rejected: HTTP 400: Duplicate order detected …` followed by
+`duplicate_order` and the remedy: re-run with a different `--test-email-prefix`
+(or `--test-email`), or wait. The shipping address is not part of the match, so
+changing `--test-address1` does not help.
+
 The browser driver intentionally behaves like a user:
 
 - package selection uses rendered `[data-next-package-id]` controls when
@@ -1882,19 +1928,32 @@ expectations, and commerce-ref validation. A doctor-clean non-packet run means
 matches a spec". Treat it as a residue/visual gate, not equivalent to a
 packet-driven QA pass.
 
-### Per-page credential declarations
+### Per-page credential binding
 
 Canonical `qa run` emits `page-binding:<page_id>` in the existing `api-metadata`
 family, with `campaigns-os-page-binding/v0` evidence (typed in the verdict schema).
-`match` means the statically declared credential equals the expected credential;
+`match` means the page's credential equals the expected credential;
 `mismatch` is a blocker. `unknown` requires manual review. All three carry
 `identity: not_verified`: credential equality never proves a unique Campaign App
 ID, and no App ID is inferred from `campaignId` or `next-campaign-id`.
 
 Expected data reuses the commercial QA resolver (packet, then spec, then an
 explicit supported environment source). Conflicting authored values are unknown.
-The SDK loads `window.nextConfig.apiKey` before `next-api-key` at boot, so meta
-wins at runtime; this check deliberately reports differing declarations as a
+
+With `--browser`, the row comes from the key the Campaign Cart SDK actually
+sent. The SDK sends it as `Authorization` on every Campaigns API request, and
+the browser pass reads that header on each page it loads. The values are
+compared in memory and dropped: the evidence records
+`observation: sdk_request`, `source_kinds: ["sdk_request"]`, and `match` when
+every request carried the expected credential or `mismatch` when any carried
+another. This works whatever the
+page's scripts look like. A page that sent no Campaigns API request, or a run
+with no single expected credential, keeps the static row described below.
+
+Without `--browser`, or for such a page, the row is a static read of what the
+page declares (`observation: static_declaration`). The SDK loads
+`window.nextConfig.apiKey` before `next-api-key` at boot, so meta wins at
+runtime; the static read deliberately reports differing declarations as a
 conflict rather than certifying one. It does not observe SDK execution.
 
 The bounded HTML loader is reused. HTML is parsed without execution; JavaScript
@@ -1919,7 +1978,9 @@ ASCII whitespace and compared case-insensitively as the browser does; classic
 `built_output.script_syntax` in [the Build Packet doc](build-packet.md).
 
 External executable scripts other than the recognized jsDelivr Campaign Cart
-loader/index are inspected only on the page's origin. Each page admits at most
+loader or index are inspected only on the page's origin. Three Campaign Cart
+paths count as the SDK and are never fetched: `dist/loader.js` (the one the
+starter templates load), `dist/index.js` and `public/loader.js`. Each page admits at most
 6 such references; each run fetches at most 24 distinct URLs (deduplicated),
 256 KiB per response and 6 MiB aggregate, 5 seconds per request including body
 read (at most 30 seconds of sequential config requests per page). Redirects,

package/docs/runtime-readiness.md

@@ -8,7 +8,7 @@
 
 How a checkout of this repository at one commit becomes a usable installed runtime, and how a consumer decides whether a prepared one is still trustworthy. Everything below is generated from `contracts/runtime-recipe.campaigns-os-node-v1.json`, which is the only authority for these values.
 
-Recipe kind `campaigns-os-node-v1`, revision `1.0.2`, validated by `schemas/campaigns-os-runtime-recipe.v1.schema.json` (`Campaigns OS Runtime Recipe v1`). Supported surface at generation time: `1.47.0`.
+Recipe kind `campaigns-os-node-v1`, revision `1.0.2`, validated by `schemas/campaigns-os-runtime-recipe.v1.schema.json` (`Campaigns OS Runtime Recipe v1`). Supported surface at generation time: `1.50.0`.
 
 ## What this is
 

package/docs/skills-revision.md

@@ -16,7 +16,7 @@ that the copy on disk moved.
 `skills.json` carries one top-level field:
 
 ```json
-"bundle_revision": "1.47.0+skills.1"
+"bundle_revision": "1.50.0+skills.1"
 ```
 
 The spelling is `<package version>+skills.<n>`:
@@ -25,7 +25,7 @@ The spelling is `<package version>+skills.<n>`:
   skills ship with (`check-skill-versions.mjs` fails if the two disagree);
 - `<n>` is a plain counter, not a semver component. It says "this is the *n*th
   skill-text revision published against that package version" and it **resets
-  with the prefix**. `1.47.0+skills.1` is therefore ahead of `1.40.0+skills.7`.
+  with the prefix**. `1.50.0+skills.1` is therefore ahead of `1.40.0+skills.7`.
 
 It is one identity for the bundle as a whole, on purpose. Per-skill versions
 still exist and still gate per-skill changes, but an agent that loaded one skill
@@ -37,7 +37,7 @@ The first body line of every bundled `SKILL.md`, immediately after the
 frontmatter, is exactly:
 
 ```
-Bundle revision: 1.47.0+skills.1
+Bundle revision: 1.50.0+skills.1
 ```
 
 followed by a short paragraph telling the agent to run the check below at the
@@ -48,7 +48,7 @@ text the agent is actually reading, not from a file it would have to go and open
 ## The check
 
 ```bash
-npx --no-install campaigns-os tooling status --skills-revision 1.47.0+skills.1
+npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1
 ```
 
 The value is compared against the bundle revision of the **CLI the command runs
@@ -90,20 +90,20 @@ reports the choice as `skills.scope` (`requested`, `installed_platforms`, or
 "revision_check": "match",
 "skills_revision": {
   "status": "match",
-  "requested": "1.47.0+skills.1",
+  "requested": "1.50.0+skills.1",
   "spelling": "bundle",
-  "on_disk": "1.47.0+skills.1",
+  "on_disk": "1.50.0+skills.1",
   "on_disk_skill": null,
-  "message": "match (1.47.0+skills.1)"
+  "message": "match (1.50.0+skills.1)"
 }
 ```
 
 The text view prints one named line, as a header above the rest of the status:
 
 ```
-Skills revision: match (1.47.0+skills.1)
-Skills revision: mismatch: loaded 1.39.0+skills.1, on disk 1.47.0+skills.1 — start a fresh session
-Skills revision: unchecked (on disk 1.47.0+skills.1)
+Skills revision: match (1.50.0+skills.1)
+Skills revision: mismatch: loaded 1.39.0+skills.1, on disk 1.50.0+skills.1 — start a fresh session
+Skills revision: unchecked (on disk 1.50.0+skills.1)
 ```
 
 `unchecked` is the state when the flag is absent. It is not an error — an

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nextcommerce/campaigns-os",
-  "version": "1.47.0",
+  "version": "1.50.0",
   "description": "Toolkit for agent-assisted NEXT campaign builds.",
   "license": "Apache-2.0",
   "repository": {

package/schemas/campaign-runtime-build-packet.v0.schema.json

@@ -336,6 +336,8 @@
         "template_family": {
           "enum": [
             "undecided",
+            "apollo",
+            "apollo-mv-single-step",
             "olympus",
             "limos",
             "demeter",
@@ -343,6 +345,8 @@
             "olympus-mv-two-step",
             "shop-single-step",
             "shop-three-step",
+            "arjuna",
+            "karna",
             "custom"
           ]
         },

package/schemas/campaigns-os-qa-verdict.v0.schema.json

@@ -146,7 +146,11 @@
           "const": "campaigns-os-page-binding/v0"
         },
         "observation": {
-          "const": "static_declaration"
+          "enum": [
+            "static_declaration",
+            "sdk_request"
+          ],
+          "description": "static_declaration: the key the page's HTML and same-origin config scripts declare. sdk_request: the key the Campaign Cart SDK sent to the Campaigns API in the browser pass (qa run --browser)."
         },
         "outcome": {
           "enum": [
@@ -174,7 +178,8 @@
             "enum": [
               "meta",
               "inline",
-              "config_script"
+              "config_script",
+              "sdk_request"
             ]
           }
         },
@@ -182,7 +187,7 @@
           "const": "not_verified"
         }
       },
-      "description": "Credential-free static declaration comparison, not observed execution or Campaign App identity. No keys, hashes, fragments, source URLs or inferred resource IDs."
+      "description": "Credential-free comparison of the page's key with the expected key: the static declaration, or the key the SDK sent in the browser pass. Not Campaign App identity. No keys, hashes, fragments, source URLs or inferred resource IDs."
     },
     "pageUrlRef": {
       "type": "object",

package/skills/campaign-lifecycle-orientation/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: campaign-lifecycle-orientation
-version: 1.0.19
+version: 1.0.24
 description: Orient a reader to the Campaigns OS lifecycle artifacts a run has already emitted, without advancing any stage or changing any state.
 ---
 
-Bundle revision: 1.47.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.47.0+skills.1`
+Bundle revision: 1.50.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read

package/skills/campaign-readback-classification/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: campaign-readback-classification
-version: 1.0.19
+version: 1.0.24
 description: Classify a selected campaign from the readback projection's v2 fields and write a read-only handoff without turning diagnosis into permission.
 ---
 
-Bundle revision: 1.47.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.47.0+skills.1`
+Bundle revision: 1.50.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read

package/skills/campaign-run-evidence/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: campaign-run-evidence
-version: 1.0.19
+version: 1.0.24
 description: Interpret existing Campaigns OS doctor, QA and proof-depth evidence without claiming more proof than the artifacts contain.
 ---
 
-Bundle revision: 1.47.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.47.0+skills.1`
+Bundle revision: 1.50.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read
@@ -65,7 +65,12 @@ Saved-Map QA may publish it under the existing consent and flag controls; a
 publication failure does not erase the local one. Local-spec packet verdicts
 stay local even with `--post-verdict`, and `qa publish` refuses those packets.
 The readback projects `.campaign-runtime/qa-verdict.json` when
-that sidecar has been copied into the campaign repository. A markdown QA
+that sidecar has been copied into the campaign repository. The sidecar is a
+committable projection: it always empties `test_orders`, `entry_urls`,
+`page_urls` and `tested_urls`, so an empty `test_orders` there says nothing
+about ordering. Its typed-card proof is the `browser-test-order:<path>`
+assertions, each with a `browser-order-total-parity:<path>` row beside it; the
+full verdict under `qa-output/` keeps the order records. A markdown QA
 report, a ledger or a gate script is not a verdict and must not be scanned for
 a disposition, a run id or a blocker. Where two JSON verdicts exist, interpret
 the one the projection loaded; do not walk a report looking for a later rerun.

package/skills/contribution-intake/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: contribution-intake
-version: 1.0.19
+version: 1.0.24
 description: Turn a suggestion about the agent surface into a classified, evidence-checked proposal and, only with attended approval, one issue on this repository's tracker.
 ---
 
-Bundle revision: 1.47.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.47.0+skills.1`
+Bundle revision: 1.50.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read

package/skills/next-campaigns-build/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-build
-version: 1.0.24
+version: 1.0.29
 description: Assemble a NEXT campaign from a doctor-cleared Build Packet, CampaignSpec/API values, prepared HTML/assets, page-kit, and starter-template contracts.
 ---
 
-Bundle revision: 1.47.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.47.0+skills.1`
+Bundle revision: 1.50.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read
@@ -86,6 +86,7 @@ Build rules:
 - Preserve SDK-owned checkout/cart/upsell/receipt/payment/address/totals/submit surfaces.
 - If `doctor` (tier `A`: inspection that writes nothing, plus one read-only live campaign request once the site is built and a public campaign key resolves; `--write` is also tier `A` and writes doctor output; `--built` is tier `B`) reports `derived.scope.mode = "partial"`, build the pages listed in `derived.scope.built_pages` from their prepared source. Keep every out-of-scope route unbuilt by default, including pages marked `template_stock: true`; never publish placeholder presell/landing pages that remain on another host. Materialize a stock page only with explicit per-page operator opt-in (including a required pre-checkout `select` stand-in). For opted-in pages use the locked family's own page for that role with its dependent `_includes/`, `_layouts/`, and assets, wire it from CampaignSpec, and build a required select step first. Do not attest stock screenshots as design source. Built stock pages rejoin preview QA once their HTML exists. Carry remaining `skip_reason` declarations into the report and label the preview route/visual-testable rather than full-funnel launch-ready.
 - For `landing` and `presell` pages, prefer the prepared source HTML when `source_html.pages[].path` points at a real standalone page. Preserve the design/content through a passthrough page-kit layout, inject the SDK loader/config as needed, and repoint CTAs into the CampaignSpec flow. Treat `source_html.pages[].path` and `context.page_map[].source_path` as source provenance. Treat `source_html.pages[].page_kit`, `context.page_map[].page_kit`, and `context.page_map[].output_path` as the Page Kit target file, route, CPK `page_type`, and frontmatter projection.
+- Reproduce the source design's own proof and urgency elements as designed: reviews and testimonials, ratings, "Verified Purchase" labels, recent-purchase popups, stock counters, countdowns and guarantees. They are the merchant's content and the merchant's responsibility; Campaigns OS does not review them, so do not remove, soften or flag them. The starter templates shipping without some of these elements is not a reason to drop the source's.
 - Prepared source HTML means page-kit-ready markup, not a wholesale Liquid rewrite. Standalone HTML mockups that are meant to stay whole (their `source_screenshot` proof is of the full document) keep their document wrappers: the source-html manifest records `wrapper_policy: preserve_document_wrappers` (or `--wrapper-policy preserve_document_wrappers` on `start` / `prepare-build`), and doctor reports the wrappers as a warning. Otherwise, standalone AI/exported HTML should keep page-owned body markup, remove document wrappers, add YAML frontmatter, move shared CSS/assets into the campaign structure, and use Liquid helpers only where page-kit needs campaign-rooted links/assets/includes.
 - For `checkout`, `upsell`, `downsell`, and `receipt` pages, treat the selected starter-template commerce surface as the SDK contract reference: preserve required `data-next-*` controls, hidden fields, payment/address/totals/submit wiring, and `next_dont_touch` regions. The surrounding HTML wrapper, page composition, imagery, copy hierarchy, and brand layer are campaign/source-owned. Do not carry starter visual chrome forward when prepared source design should own that surface. QA checks what the checkout does, not family class names: do not add family shell classes (`.checkout-wrapper`, `.checkout-layout__left/right`) to the campaign's own grid or swap source-owned field markup for family includes to satisfy QA. Keep the checkout working instead: a `<form data-next-checkout="form">`, the contact and shipping fields bound with `data-next-checkout-field` inside it, and a visible cart total. 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 as bound: QA reports it in `fields_bound.missing`.
 - Read `context.theme` and `.campaign-runtime/theme/theme-report.json` when present. If a fresh `brand-theme.css` artifact exists, copy it into the campaign asset tree and load it after `next-core.css` on checkout, upsell, downsell, and receipt pages. If policy is `inspect_only`, either run `campaigns-os theme generate` (tier `B`: writes the theme artifacts and doctor output under the target; `--force` is tier `C`) or record an explicit skipped reason before applying a new brand layer.
@@ -106,6 +107,6 @@ Build rules:
 - Run page-kit build and SDK/template lint available in the target repo.
 - Record build with `campaigns-os record build --packet <packet>` after every page-kit build (tier `C`: it overwrites `stages.assembly` and, when the output changed, resets `stages.polish` to `required` in the assembly report, and stamps the doctor output stale; `--dry-run` is tier `none`). It stamps `stages.assembly.build_fingerprint` with the fingerprint doctor computes from `_site/<slug>/` and the Design Source Package material fingerprint when the report has one. Never type or copy these fields by hand.
 - Capture the machine-readable build summary as an artifact: `npx campaign-build --json > .campaign-runtime/page-kit-build-summary.json` (requires `next-campaign-page-kit` >= 0.1.4). Doctor's `built_output.build_summary` check verifies per-page build status and Page Kit shape warnings (`NESTED_NO_PERMALINK`, `DUPLICATE_OUTPUT`, `MISSING_FRONTMATTER`, `LAYOUT_NOT_FOUND`, `NO_CAMPAIGN`) from this artifact. If the installed page-kit predates `--json`, record that in the assembly report instead of skipping silently.
-- Update the assembly report with commands, evidence, warnings, blockers, and next owner. If a brand theme was applied, record `report.theme.status`, `css_path`, `commerce_pages`, `load_order=after-next-core`, evidence, and any first repair-loop defect.
+- Update the assembly report with commands, evidence, warnings, blockers, and next owner. If a brand theme was applied, run `campaigns-os record theme --packet <p>` (tier `C`) after `record build`: it reads each built commerce page's stylesheet links and records `report.theme` (status applied, `load_order=after-next-core`, `css_path`, `commerce_pages`, evidence). It refuses, writing nothing, when a page that loads `next-core.css` does not load the brand layer after it. Don't hand-edit `report.theme`; a first repair-loop defect goes through `record polish`.
 
 Build does not replace polish or QA. Hand off to `next-campaigns-polish` when the campaign is runnable.

package/skills/next-campaigns-os/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-os
-version: 1.0.39
+version: 1.0.44
 description: Coordinate Campaigns OS lifecycle workflows from CampaignSpec, Build Packet, starter-template contracts, stage reports, deploy evidence, and QA proof depth.
 ---
 
-Bundle revision: 1.47.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.47.0+skills.1`
+Bundle revision: 1.50.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read