@nextcommerce/campaigns-os 1.50.0 → 1.53.0

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

@@ -39,8 +39,10 @@ the toolkit runs that loop in a fixed order:
 1. **Build in development.** The build stage runs page-kit in the development
    environment — `CPK_ENV=development npx campaign-build --json >
    .campaign-runtime/page-kit-build-summary.json` — into the target's normal
-   `_site/`, and records `stages.assembly.evidence.build_environment:
-   "development"` on the Assembly Report. `next build` names the command as
+   `_site/`, and `campaigns-os record build --packet <packet>
+   --build-environment development` records
+   `stages.assembly.evidence.build_environment: "development"` on the Assembly
+   Report. `next build` names the command as
    the `build_local_proof` action and in the build prompt; doctor warns
    (`local_proof.build_environment`) on a completed build that is not recorded
    as a development render. The starter templates gate every vendor loader on
@@ -368,7 +370,11 @@ Only contract-governed claims are compared, and only against `Exact` normalized
 truth. Proven differences emit warn-severity `pricing` assertions named
 `price-claim-mismatch`, `cadence-disclosure-mismatch`, or
 `voucher-not-applied`. Decorative, ambiguous, stale, unresolved, or malformed
-claims remain silent. The verdict's top-level `commercial` section records
+claims remain silent. A page showing a voucher the normalized plan cannot price
+(no calculated pair for its code, for example a live voucher on an upsell)
+leaves that page's price claims unresolved: the plan's only Exact truth for
+the page is then the list price, which a voucher-priced page is expected to
+differ from. The verdict's top-level `commercial` section records
 coverage, sanitized missing/unmatched/invalid capture evidence, proxy issues,
 and findings; the same findings are serialized deterministically into the flat
 `assertions` array consumed by existing QA tooling. A proven mismatch keeps the
@@ -1600,7 +1606,7 @@ the CampaignSpec instead:
   purchase multipliers (`ref` and `ref:2`). A uniquely referenced catalog
   package with its own `qty: 3` composition is still bought once (`ref`), not
   multiplied by three. **Order-bump rows — `packages[]` entries marked
-  `is_upsell: true` — are add-ons offered beside the selected tier, not tiers**:
+  `is_order_bump: true` or `is_upsell: true` — are add-ons offered beside the selected tier, not tiers**:
   they never become a plan (a three-tier checkout with one bump plans three
   tiers, so `tiers:common` on a two-upsell funnel is 12 orders, not 16), and
   the runner prints a `[qa:test-order]` line naming the bump ref(s) it left
@@ -1859,6 +1865,36 @@ table in [build-packet.md](./build-packet.md#deploy-target) and
 [Local proof mode](#local-proof-mode-deploytarget-local-serve) above for the
 development build, the parity check, and the order they run in.
 
+### Tracking parameters
+
+**Tracking parameters.** During a browser test order, QA adds synthetic tracking values (`utm_*`, `affid`, `sub1`, `subaffiliate2`, and up to eight names from `analytics.params.tracking.preserve`) to the pages it loads before the campaign's own navigation starts. It reports two results:
+
+- **URL preservation:** whether each value is still in the address after each page navigation it observed, through to the navigation after the order. A failing step is named only when QA observed both sides of it. A reload by QA itself, an unobserved step, or an attempt that ended early ends the measurement without a pass.
+- **Order attribution:** whether the matching attribution field reached the request of an order the store accepted.
+
+Values from `<meta name="os-tracking-tag">` tags are checked against order metadata. When page script sets attribution itself, differences are review results. Only synthetic values and equality results are stored, and order URLs in QA evidence are now stored without their query. Click ids and `funnel` are not seeded, even when listed in `tracking.preserve`, and are listed as not tested.
+
+Every string QA stores in its verdict is cut at its first query (a `?`, written literally or percent-encoded), every URL in it is also cut at its fragment, and a string longer than 16 KiB is truncated.
+
+## Content parameters
+
+**Content parameters.** For each `analytics.params.content` entry, QA loads each applicable page twice in separate fresh browser contexts: once without the parameter and once with `?<name>=n`. It waits for the SDK to finish its display pass, then checks that the same elements whose `data-next-hide` or `data-next-show` refers to `param.<name>` are visible without the parameter and hidden with it. A parameter whose only handlers cannot hide anything with `n` is a warning. Compound conditions, conditions the SDK parses unreliably, content already hidden without the parameter, elements that change between the two loads, pages that fail to load, and pages where the SDK did not finish produce review or unexercised results, never a pass. Runs without `--browser` list these checks as not requested. No orders are placed.
+
+## Policy links
+
+**Policy links.** For each configured `store_terms`, `store_privacy`, `store_returns`, `store_shipping`, and `store_contact` URL, QA checks two things:
+
+- **Presence:** whether any visited page links to that exact destination, with trailing slashes and default ports normalized and query parameters kept. Presence is decided only when QA read the links on every page it visits; otherwise it is unexercised.
+- **Availability:** whether the URL reaches an HTML page within 5 redirects, using bounded GET requests that read headers only.
+
+A redirect to the right page is fine. Missing links, links whose query differs, links whose declared footer label points elsewhere, 404s, server errors and redirects to the store's home page are warnings. Authentication, rate limiting, loops, non-HTML responses, unexpected statuses, configured values that are not absolute URLs, and redirects to other destinations are review results. Network failures are unexercised. A 200 response proves only that the page is reachable. `mailto:` contacts are checked for presence only. Runs without `--browser` list these checks as not requested. Link wording is used only as an English review hint.
+
+## Operator accepts (`checkpoint accept`)
+
+**Accepting a warning.** `campaigns-os checkpoint accept` records an operator's decision about a warning that a Campaigns OS check measured. It does not change readiness, does not remove the warning, does not change the status `next` reports, and cannot be used on review, unexercised, or excluded results. The warning must already be on record (in the doctor snapshot `next` writes, the Polish capture, or the full QA verdict) before it can be accepted. The accept is bound to the exact measured state and lapses when that state changes, or when its evidence is stale or cannot be reproduced. An optional expiry or review condition adds a second bound. Run it only with the operator's explicit decision, made after the warning was shown to them. A plausible name is not authorization. The command refuses placeholder and automation identities. Results are re-derived from the package's raw captures on every read, and a result whose capture is missing or does not match is listed as unexercised. These checks are tamper evidence, not proof of authorship: a hand-written record that copies every value and recomputes the checksum, or a hand-written result written together with a matching capture, is not detected.
+
+A readability warning is keyed by its colour pair and text size class on each page and width. The QC handoff lists each pair once with every page and width that uses it. Accepting it, with one `checkpoint accept` naming every listed ref, records the operator's decision for those pages. The accept states whether it covers normal text, large text, or both, by which size-class refs are named. When either colour changes, the pair becomes a new warning, and the old accept no longer matches any result (it is listed as orphaned). An accept lapses when the exact colours, ratio, font size or font weight of any text using the pair on that page change, when its capture is stale — including built output that changed since the build was recorded — or when it cannot be reproduced, including a missing crop. A page that starts using the same pair later is a new warning. An accept never hides review, unexercised or excluded results.
+
 ## Launch Readiness Note
 
 Campaigns OS can prove the campaign build, SDK wiring, browser behavior, and
@@ -1886,6 +1922,13 @@ use the declared topology instead of a single happy path:
 5. Use `full` when you want every actual terminal path, raising the flood cap to
    the exact planned count when necessary.
 
+`next` names step 4 at the QA stage. When the checkout page the default run
+drives declares an order bump (`is_order_bump: true` or `is_upsell: true` rows), it lists a second QA
+command, `qa_run_bump`, beside `qa_run`: the same `--test-order common` run
+with `--cart <base>:1,<bump>:1`, where the base is the first selector tier the
+checkout declares. The QA stage prompt and the human `next` output carry the
+same command.
+
 Record order numbers, `ref_id` values, and expected line-item shapes in the
 handoff. If the browser console shows an SDK module-load error but the SDK
 fallback loads and checkout/order proof passes, keep it as platform warning

package/docs/readback.md

@@ -6,7 +6,9 @@ Packet, the doctor output sidecar, the build context, the assembly report, a QA
 verdict, and a findings export when present. It reads each of those files at
 most once, plus two fixed Git metadata files (the nearest `.git` entry at the
 target or an ancestor, and that Git directory's `logs/HEAD` reflog) for the
-freshness comparison.
+freshness comparison, and the CampaignSpec and normalized Campaign Build Brief
+the Build Packet names, whose current content decides each stage's effective
+status.
 
 The safety contract is the point of the command. The readback **writes nothing**
 under the target — not even a lifecycle journal entry, which every other command
@@ -107,7 +109,7 @@ RUN IDENTITY
   template_family = olympus  [build packet]
   qa run_id = MSRBUNDLEFIXTURE000000000000  [QA verdict]
 
-STAGES  [assembly report; report status: prepared]
+STAGES  [assembly report; report status: prepared; effective: prepared]
   prepare_build  completed
   doctor         pending
   setup          pending
@@ -129,6 +131,21 @@ QA VERDICT  [QA verdict; disposition: ready — Campaigns OS is the verdict auth
   pass  http:checkout  (family funnel-flow)
 ```
 
+### STAGES
+
+The STAGES header prints the status the Assembly Report records and the status recomputed from each stage's effective status. A stage's effective status is the recorded one, except that a stage made owed again by a brief or CampaignSpec change reads `required`, and a stage whose inputs cannot be confirmed reads `unknown`. When the two differ, the stage line adds the recorded status and the reason. Superseded records appear only under "history (not current proof)".
+
+```
+STAGES  [assembly report; report status: completed; effective: prepared]
+  prepare_build  completed
+  doctor         pending
+  setup          completed
+  assembly       required   (recorded: completed; spec_material_changed)
+  polish         required   (recorded: completed; spec_material_changed)
+  deploy         completed
+  qa             required   (recorded: completed; spec_material_changed)
+```
+
 ## The JSON contract
 
 ```json

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.50.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.53.0`.
 
 ## What this is
 

package/docs/sdk-storage-compatibility.md

@@ -10,7 +10,7 @@ Omit `--json` for the concise human report. Exit 0 means source-compatible; exit
 
 The manifest is generated and owned by Campaign Cart, from its storage registry. The scanner has no independent SDK key list and fetches no remote code. Supply `docs/compatibility/storage-migrations.v1.json` from an unmodified checkout of a Campaign Cart release tag, v0.4.40 or later. The report records the full file SHA-256, SDK version, supported target range, registry/extractor/input digest, and Git provenance. When the supplied bytes equal their repository HEAD blob, provenance is `verified-git-blob` with commit and repository path. Proposed, modified, or copied manifests are labeled `unverified-local-file`; the label never certifies a release. Review/pin SDK provenance separately before acting on findings. A release manifest covers the target range it declares, which may end below its own SDK version: the v0.4.40 manifest, for example, covers 0.4.38 only. Targets outside the manifest's supported SDK range report unknown. A manifest whose SDK version is below its supported maximum is invalid.
 
-`--target` must name the Git root. `--scope` is mandatory: comma-separated literal repository-relative directory/file paths; use `.` only when the complete repository is intended. Add shared JavaScript directories explicitly. `--exclude` uses the same syntax and records explicit exclusions. Archives receive no implicit exemption. Only Git-tracked `.html`, `.htm`, `.js`, `.mjs`, and `.cjs` files in the selected scope are scanned, using current working-tree bytes and per-file digests; untracked files and built dependencies are outside this evidence. A selected HTML page's local script outside the selected files reports unknown. Relative scripts affected by an HTML `<base href>` also report unknown; review their actual dependency paths. Remote SDK and third-party scripts are not fetched or analyzed.
+`--target` must name the Git root. `--scope` is mandatory: comma-separated literal repository-relative directory/file paths; use `.` only when the complete repository is intended. Add shared JavaScript directories explicitly. `--exclude` uses the same syntax and records explicit exclusions. Archives receive no implicit exemption. Only Git-tracked `.html`, `.htm`, `.js`, `.mjs`, and `.cjs` files in the selected scope are scanned, using current working-tree bytes and per-file digests; untracked files and built dependencies are outside this evidence. A selected HTML page's local script outside the selected files reports unknown. In a Page Kit campaign (a page under `src/<slug>/`), a script src written `{{ 'js/x.js' | campaign_asset }}` resolves to `src/<slug>/assets/js/x.js`, as Page Kit serves it, and a page's frontmatter `scripts:` entries resolve the same way, since a layout's `{% for script in scripts %}` loop loads them through that filter. Any other `campaign_asset` value, a path that resolves outside the assets folder, and frontmatter that is not valid YAML or whose `scripts` is not a list of paths report unknown. Relative scripts affected by an HTML `<base href>` also report unknown; review their actual dependency paths. Remote SDK and third-party scripts are not fetched or analyzed.
 
 Acorn parses JavaScript ASTs; parse5 identifies executable inline HTML scripts and source offsets. Findings inventory storage area, operation, key, file/line/column, reason, and SDK-owned public replacement when supplied. The scanner recognizes direct `localStorage`/`sessionStorage`, `window`/`globalThis`/`self` properties, simple constant browser-global/storage aliases and storage destructuring, literal `getItem`/`setItem`/`removeItem` calls (including bracket method notation), property access/assignment/deletion, and lexical constant string indirection. Comments, ordinary strings, JSON script blocks and public store calls do not become storage reads. A literal legacy SDK key at or after its manifest migration boundary is incompatible. Guessed prefixes cannot establish compatibility.
 

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.50.0+skills.1"
+"bundle_revision": "1.53.0+skills.2"
 ```
 
 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.50.0+skills.1` is therefore ahead of `1.40.0+skills.7`.
+  with the prefix**. `1.53.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.50.0+skills.1
+Bundle revision: 1.53.0+skills.2
 ```
 
 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.50.0+skills.1
+npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2
 ```
 
 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.50.0+skills.1",
+  "requested": "1.53.0+skills.2",
   "spelling": "bundle",
-  "on_disk": "1.50.0+skills.1",
+  "on_disk": "1.53.0+skills.2",
   "on_disk_skill": null,
-  "message": "match (1.50.0+skills.1)"
+  "message": "match (1.53.0+skills.2)"
 }
 ```
 
 The text view prints one named line, as a header above the rest of the status:
 
 ```
-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)
+Skills revision: match (1.53.0+skills.2)
+Skills revision: mismatch: loaded 1.39.0+skills.1, on disk 1.53.0+skills.2 — start a fresh session
+Skills revision: unchecked (on disk 1.53.0+skills.2)
 ```
 
 `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.50.0",
+  "version": "1.53.0",
   "description": "Toolkit for agent-assisted NEXT campaign builds.",
   "license": "Apache-2.0",
   "repository": {

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

@@ -1,11 +1,11 @@
 ---
 name: campaign-lifecycle-orientation
-version: 1.0.24
+version: 1.0.29
 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.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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.24
+version: 1.0.29
 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.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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.24
+version: 1.0.29
 description: Interpret existing Campaigns OS doctor, QA and proof-depth evidence without claiming more proof than the artifacts contain.
 ---
 
-Bundle revision: 1.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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/contribution-intake/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: contribution-intake
-version: 1.0.24
+version: 1.0.29
 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.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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.29
+version: 1.0.34
 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.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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
@@ -75,6 +75,7 @@ Inputs:
 - prepared HTML/assets source
 - target page-kit repo
 - starter-template commerce catalog
+- Read the normalized Campaign Build Brief at `.campaign-runtime/input/campaign-build-brief.normalized.json` and the recorded decisions (`adapter_decisions`, `decisions` and `theme` in `.campaign-runtime/assembly-report.json`, and `assembly.template_decision_notes` in the Build Packet) before working on the campaign. The campaign intent summary at the top of the setup, build, Polish and QA prompts and in every `next` result is orientation, never a source of prices or commerce behaviour.
 
 Build rules:
 
@@ -106,6 +107,7 @@ Build rules:
 - For `shop-three-step`, shipping methods are dynamic through `window.next.getShippingMethods()`; do not add static Olympus-style `shipping_methods` frontmatter.
 - 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.
+- If `next` reports that the build output is unchanged after a brief or CampaignSpec change, rebuild so the change reaches the pages. Pass `--deviation-reason` to `record build` only when the operator explicitly decides in this conversation that the change needs no change to the built pages, and quote their reason.
 - 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, 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`.
 

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

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-os
-version: 1.0.44
+version: 1.0.49
 description: Coordinate Campaigns OS lifecycle workflows from CampaignSpec, Build Packet, starter-template contracts, stage reports, deploy evidence, and QA proof depth.
 ---
 
-Bundle revision: 1.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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
@@ -95,7 +95,7 @@ Map and run endpoints) with a local CampaignSpec, prepared HTML/assets source, t
    retains each attributed exception as `ready_with_exceptions`, and one
    exception never suppresses another blocker.
 10. Run the package-owned proof path in sequence: ensure `npx --no-install campaigns-os qa install-browser` has completed, run `campaigns-os qa resolve --packet <packet>` (tier `A`: it fetches `--base-url`; `--no-probe` is tier `B` and local), then `campaigns-os qa run --packet <packet> --base-url <url> --browser --test-order common` (tier `C`: it overwrites the stored verdict and assembly report, places real typed-card test orders against the campaign, and posts the verdict and progress; `--no-post-verdict` drops the verdict POST and `--no-remit` the Run Record remit, but both stay tier `C`).
-11. Treat typed-card proof coverage as the control. Global test cards bypass the gateway and create no transactions, so no permission/approval is needed. `common` runs every actual terminal path when they fit under the flood cap (`--max-test-orders`, 6 by default); above the cap it runs checkout, first-offer accept and decline, and a deduplicated shortest real receipt path, then adds one decline path per offer or downsell page not yet declined, up to the cap, and names any page left out. A page counts as covered only when an order clicks its decline; the `browser-test-order:upsell-action-coverage` verdict row warns naming each page whose decline no order clicked. `full` walks every actual terminal path in the selected checkout topology; cycles, missing routes, and reachable nonterminals block exhaustive proof before browser launch. The accidental-flood cap remains `6`, and an overflow names the exact explicit `--max-test-orders` raise. Localhost on any port is a Campaigns App Development domain for SDK QA with analytics suppressed; non-localhost preview/production origins still need SDK origin allowlist confirmation.
+11. Treat typed-card proof coverage as the control: `qa run` has no permission flag. Test orders still land in the store as real orders (global test cards: no charge, no transaction) that someone may have to cancel. Unless the operator has already said test orders are fine for this campaign, ask once, up front in your first turn with your other setup questions, so the answer covers the whole build and QA and neither stops for it later. `common` runs every actual terminal path when they fit under the flood cap (`--max-test-orders`, 6 by default); above the cap it runs checkout, first-offer accept and decline, and a deduplicated shortest real receipt path, then adds one decline path per offer or downsell page not yet declined, up to the cap, and names any page left out. A page counts as covered only when an order clicks its decline; the `browser-test-order:upsell-action-coverage` verdict row warns naming each page whose decline no order clicked. `full` walks every actual terminal path in the selected checkout topology; cycles, missing routes, and reachable nonterminals block exhaustive proof before browser launch. The accidental-flood cap remains `6`, and an overflow names the exact explicit `--max-test-orders` raise. Localhost on any port is a Campaigns App Development domain for SDK QA with analytics suppressed; non-localhost preview/production origins still need SDK origin allowlist confirmation.
 12. Discuss launch only from recorded build, polish, deploy, browser QA, and test-order evidence, or from explicit blockers.
 
 ## Session Intake
@@ -103,31 +103,22 @@ Map and run endpoints) with a local CampaignSpec, prepared HTML/assets source, t
 When a Campaigns OS session starts, classify the starting path before handing
 off to setup, build, polish, QA, or promotion. The operator should separate:
 
-- Intent: build, partial page update, existing campaign update, QA only, repair from verdict, design/source assembly, or promotion.
+- Work: build, partial page update, existing campaign update, QA only, repair from verdict, design/source assembly, or promotion.
 - Source truth: CampaignSpec/Map Builder export, Figma/design file, prepared HTML, existing campaign repo, deployed URL, or target deployment system.
 - Runtime truth: Build Packet, Build Context, Assembly Report, doctor JSON, tested URL, API key source, and SDK origin allowlist state (localhost is already a Development domain; non-localhost origins still need confirmation).
 - Change policy: what may change and what must be preserved, especially checkout, offer logic, routes, legal copy, and live campaign behavior.
-- Proof depth: visual preview, doctor, browser QA, QA portal/local verdict policy, typed-card test-order depth, market coverage, and repair routing.
+- Proof policy: visual preview, doctor, browser QA, QA portal/local verdict policy, typed-card test-order depth, market coverage, and repair routing.
 
-Return a compact brief before acting:
-
-```text
-Mode:
-Intent:
-Source truth:
-Runtime truth:
-Change policy:
-Proof depth:
-Next skill/command:
-Missing inputs:
-```
+Return the compact brief defined in `references/session-intake.md` before acting.
 
 Use `references/session-intake.md` when the mode, allowed changes, or proof
-depth is unclear. Ask only for fields needed by the selected starting path; a
+policy is unclear. Ask only for fields needed by the selected starting path; a
 QA-only session should not require design files, and a partial landing update
 should not force full checkout/test-order depth unless commerce or routing can be
 affected.
 
+Save the operator's brief answers with `campaigns-os record brief --packet <packet>` (tier `C`: when the brief changes it rewrites the Build Packet's brief binding, the normalized brief, the Build Context and the assembly report and stamps the doctor output stale, and a material change makes build, Polish and QA owed again; `--dry-run` is tier `none`). Ask the operator before saving brief answers. Put the answers in the brief file as `docs/campaign-build-brief.md` describes, then run `record brief`; do not re-run `start` or `prepare-build` to save them.
+
 Rules:
 
 - This is contract-backed guidance and preflight, not full automated readiness.
@@ -140,7 +131,7 @@ Rules:
 - Promoted starter-template families must also have `contracts/template-brand-contract.<family>.v0.json` with family inventory, brand/residue, pricing, and exit-pop rules. Missing family contracts are gates, not advisory gaps.
 - Designed source owns visual composition and page-level content.
 - Brand-theme evidence is workflow-order neutral. Do not assume a Figma export came first; consume `context.theme` and `.campaign-runtime/theme/theme-report.json` when present. A truly missing/ungeneratable theme stays a warning, but a generatable-and-unapplied theme on a commerce-page campaign is a gate: apply it or waive it explicitly before polish/deploy/QA.
-- Follow `campaigns-os next` literally. Every `next` response carries its applicable Store Profile, SDK, hidden eager-media, theme, and broad Polish gates plus `next_actions` with exact commands — execute those instead of improvising. With an active run session, pipeline-advancing commands that don't match the last `next` recommendation are recorded to `.campaign-runtime/agent-deviations.jsonl`; declare an intentional detour with `--deviation-reason "<why>"`.
+- Follow `campaigns-os next` literally. Every `next` response carries its applicable Store Profile, SDK, hidden eager-media, theme, and broad Polish gates plus `next_actions` with exact commands — execute those instead of improvising. With an active run session, pipeline-advancing commands that don't match the last `next` recommendation are recorded to `.campaign-runtime/agent-deviations.jsonl`; declare a detour with `--deviation-reason "<the operator's reason>"` only when the operator has decided on that detour in this conversation, and quote their reason; never pass the flag on your own judgement. On `record build` after a brief or CampaignSpec change the flag records that the change needs no change to the built pages, so pass it there only on the operator's explicit decision, as `next-campaigns-build` says.
 - Close the loop: when `next` reports `done` (or QA has published its verdict and the PR is up), finish with `campaigns-os run end` (tier `C`; `--no-write` still clears the session file) so the Run Record is assembled and the run session clears. `campaigns-os run status` (tier `none`: read-only) shows incomplete stages and the exact next command at any point.
 - Do not copy demo refs or unsupported optional surfaces into the target campaign.
 - Use SDK conditionals such as `cart.hasCoupon("CODE")` for code-specific presentation; do not mutate visible prices from campaign-specific JavaScript.

package/skills/next-campaigns-os/references/session-intake.md

@@ -2,7 +2,7 @@
 
 Use this reference when a Campaigns OS session begins without an already-clear
 Build Packet, QA verdict, or promotion task. The goal is to make the operator
-separate intent, source truth, runtime truth, change policy, and proof policy.
+separate the work, source truth, runtime truth, change policy, and proof policy.
 
 ## Intake Envelope
 
@@ -10,27 +10,31 @@ Return this compact brief before running a specialist skill or command:
 
 ```text
 Mode:
-Intent:
+Work:                 (build, update, QA, repair, promote — the session's task; formerly "Intent")
+Campaign:             (paste the "Campaign intent" lines from the latest `next` output; do not write your own)
 Source truth:
 Runtime truth:
 Change policy:
 Proof policy:
 Next skill/command:
-Missing inputs:
+Missing inputs:       (only choices that affect this revision)
 ```
 
 Definitions:
 
-- Intent: what the user wants done, such as build, update, QA, repair, or promote.
+- Work: what the user wants done, such as build, update, QA, repair, or promote.
+- Campaign: the "Campaign intent" lines from the latest `next` output, pasted as printed. They come from the normalized Campaign Build Brief; do not write your own.
 - Source truth: CampaignSpec/Map Builder export, Figma/design file, prepared HTML, existing campaign, target repo, or deployed URL.
 - Runtime truth: Build Packet, Build Context, Assembly Report, optional `context.theme` / `.campaign-runtime/theme/theme-report.json`, doctor JSON, repo state, tested URL, Campaigns API key source, SDK origin state (localhost is a Development domain; non-localhost origins need allowlist confirmation), and test-order depth choice.
 - Change policy: what may change and what must be preserved, especially checkout, offer logic, live campaign routes, and legal/merchant copy.
-- Proof depth: visual preview, doctor, browser QA, QA portal/local verdict policy, typed-card test-order depth, market coverage, and repair routing.
+- Proof policy: visual preview, doctor, browser QA, QA portal/local verdict policy, typed-card test-order depth, market coverage, and repair routing.
 
 Ask only for the fields needed by the selected mode. Do not force a full-funnel
 build prompt when the user only needs QA, a partial page update, or repair from
 an existing verdict.
 
+Save the operator's brief answers with `npx --no-install campaigns-os record brief --packet <packet>` (tier `C`: when the brief changes it rewrites the Build Packet's brief binding, the normalized brief, the Build Context and the assembly report and stamps the doctor output stale, and a material change makes build, Polish and QA owed again; `--dry-run` is tier `none`). Ask the operator before saving brief answers. Put the answers in the brief file as `docs/campaign-build-brief.md` describes, then run `record brief`; do not re-run `start` or `prepare-build` to save them.
+
 ## Starting Paths
 
 ### Full Campaign Build
@@ -45,7 +49,7 @@ Required before build:
 - Source type and source files: Figma, exported HTML, prepared HTML, existing campaign, or other.
 - Pages in scope and any pages to preserve.
 - Template family if known; otherwise infer and ask before locking commerce surfaces.
-- Proof depth, including browser QA and the typed-card test-order depth to run.
+- Proof policy, including browser QA and the typed-card test-order depth to run.
 
 Route to Build Packet preparation, doctor, setup when scaffold is missing,
 build, polish, then QA.
@@ -141,9 +145,13 @@ hand-edit deployed routing config as the primary promotion path.
 
 ## Test-Order Proof Policy
 
-Treat test orders as cheap, repeatable proof: global test cards bypass the
-gateway and create no transactions, so they need no permission or approval. The
-only real choice is coverage. Record:
+Treat test orders as repeatable proof. `qa run` has no permission flag:
+coverage is its only control. Test orders still land in the store as real
+orders (global test cards: no charge, no transaction) that someone may have to
+cancel. Unless the operator has already said test orders are fine for this
+campaign, ask once, up front in your first turn with your other setup questions,
+so the answer covers the whole build and QA and neither stops for it later.
+Record:
 
 - Coverage: `common` (every actual terminal path when they fit under the flood cap; above it, checkout, first-offer accept/decline, a deduplicated shortest real receipt path, and one decline path per offer or downsell page not yet declined, up to the cap), `off`, `checkout`, `decline`, `accept`, `both`, `full`, or explicit paths such as `decline-decline-accept`.
 - Cart matrix: base cart, base plus bump, specific package refs/quantities.

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

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-os-setup
-version: 2.0.27
+version: 2.0.32
 description: Bootstrap or prepare a target page-kit campaign repo from a doctor-cleared Campaigns OS Build Packet before full build wiring. Formerly installed as next-campaigns-setup; renamed 2026-08 to stop colliding with the published NextCommerceCo/skills scaffolder of that name.
 ---
 
-Bundle revision: 1.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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
@@ -52,6 +52,7 @@ Responsibilities:
 - When copying a selected starter template family, copy the family as an atomic page-kit slice: pages plus required `_includes/`, `_layouts/`, `assets/css/`, and `assets/js/`. Do not copy only `checkout.html` and `receipt.html`.
 - Public families resolve from the default `public` starter-templates source. A **private** family (one whose source lives in an access-controlled repo, e.g. a certified family not present in the public picker) is scaffolded via page-kit's template-source mechanism (`next-campaign-page-kit` >= 0.2.0): add a named source to the target repo's `_data/template-sources.json` (a `git` source with the SSH `url` + optional `ref`, or a `local` source `path`), then `campaign-init --source <name> --template <slug>`. The source repo must expose a root `templates.json` catalog + `src/<slug>/` tree. page-kit holds no family→repo mapping; the source config lives in the (private) consuming repo, and this skill (plus the family's certified contract) is where that source is known.
 - Install or reference `.campaign-runtime/agent-context` without overwriting existing root agent files.
+- Read the normalized Campaign Build Brief at `.campaign-runtime/input/campaign-build-brief.normalized.json` and the recorded decisions (`adapter_decisions`, `decisions` and `theme` in `.campaign-runtime/assembly-report.json`, and `assembly.template_decision_notes` in the Build Packet) before working on the campaign. The campaign intent summary at the top of the setup, build, Polish and QA prompts and in every `next` result is orientation, never a source of prices or commerce behaviour.
 - Record setup with `campaigns-os record setup --packet <packet>` once the campaign output directory exists (tier `C`: it overwrites `stages.setup` in `.campaign-runtime/assembly-report.json` and the `scaffold` block of `.campaign-runtime/build-context.json`, and stamps the doctor output stale; `--dry-run` is tier `none`). It sets `scaffold.required` to false and `stages.setup` to completed, validates both files against their schemas, and writes nothing when a check fails. Do not hand-edit either file.
 - Preserve existing Build Context `theme` inspection data and Assembly Report `theme` application data when setup is rerun against an existing campaign directory.
 - Hand off to `next-campaigns-build`.

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

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-polish
-version: 1.1.28
+version: 1.1.33
 description: Run the visual/runtime polish pass after build and before QA for a Campaigns OS campaign.
 ---
 
-Bundle revision: 1.50.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.50.0+skills.1`
+Bundle revision: 1.53.0+skills.2
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.53.0+skills.2`
 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
@@ -59,6 +59,7 @@ Responsibilities:
 - Scan **visible** rendered text inside the family's content/commerce surfaces (the selectors enumerated in `contracts/template-brand-contract.<family>.v0.json`) for placeholder/residue copy the build should have replaced — the *literal starter defaults*: lorem-ipsum, the unmodified starter headings (`Product Name` / `Package Title` / `Your headline`), `[VERIFY …]` author notes, `TODO` markers. Match the literal starter strings, not any authored copy that merely contains those words, and skip `<script>` / `<style>` / JSON-LD / `data-*` attributes. Treat a surviving literal starter default on a content/commerce surface as a polish blocker — replace it from the prepared source / CampaignSpec; do not draft substitute copy (if the design's authored copy is genuinely missing, flag it rather than invent it). This is *copy* residue, complementary to the computed-style / asset residue gated by `next-campaigns-qa` + the brand contract — not a duplicate of it.
 - Flag template *defaults* left where they disagree with the prepared design — e.g. the same benefit icon repeated across a grid *when the design uses distinct icons*, or a guarantee badge/term that disagrees with the design — as polish defects, not just logos. Judge against the prepared source, not taste: copy or imagery the source/CampaignSpec does not supply (e.g. a placeholder testimonial name/quote/role) is residue; "looks generic" on its own is not. Copy the source does supply, including its proof and urgency elements (reviews, "Verified Purchase" labels, recent-purchase popups, stock counters, countdowns, guarantees), is the merchant's content: keep it as designed and do not record it as an issue or an unconfirmed claim.
 - **Brand-bleed (cloned-source de-brand) pass.** When a campaign is cloned from a proven sibling, the sibling's brand defaults ride along. Inspect the built pages and assets for residual cross-brand bleed and clear it before recording: (1) a residual promo/sale banner or coupon code/copy from the source campaign (including a baked-in *fake* code); (2) a prior-campaign / sibling favicon left in place; (3) scaffold or non-design fonts the design did not specify (e.g. starter `Plus Jakarta`); (4) hardcoded non-token colors — any brand color literal that should be a token, such as next-core's `#C670FE` "Most Popular" pill. Clear each from the prepared source / CampaignSpec and brand theme (tokens, not literals); flag — do not invent — anything the design genuinely doesn't supply. Treat surviving bleed as a polish blocker. This complements the favicon/logo and copy-residue checks above; it is the cross-brand contamination angle, not a duplicate.
+- Read the normalized Campaign Build Brief at `.campaign-runtime/input/campaign-build-brief.normalized.json` and the recorded decisions (`adapter_decisions`, `decisions` and `theme` in `.campaign-runtime/assembly-report.json`, and `assembly.template_decision_notes` in the Build Packet) before working on the campaign. The campaign intent summary at the top of the setup, build, Polish and QA prompts and in every `next` result is orientation, never a source of prices or commerce behaviour.
 - Read the assembly report decisions before polishing. Do not reintroduce source-HTML elements that build intentionally dropped because CampaignSpec/API did not support them, such as unavailable payment methods.
 - **Remove or rename a contract-listed payment-chrome asset; never edit one in place.** The assets named in `contracts/template-brand-contract.<family>.v0.json` under `default_residue.payment_chrome.assets` are keyed by QA on the *referenced basename*, not on their contents. Stripping the unsupported marks from inside a shared file such as `upsell-payment-logos.svg` leaves the reference in place, so QA reports residue for an asset that no longer carries any — and on 2026-09-06 the repair loop's remedy for that report deleted a cards-only trust strip that was correct. Delete the asset, or write a new one under a new name and repoint the reference. QA downgrades an edited-in-place asset to `manual_review` rather than a blocker, but that is a safety net for a mistake, not the supported way to do this.
 - Preserve existing `report.theme` data. If polish changes generated theme CSS, load order, commerce-page coverage, theme warnings, or the first repair-loop defect, update the Assembly Report `theme` block rather than leaving stale evidence.
@@ -78,13 +79,14 @@ Responsibilities:
   The package captures every mapped route at fixed desktop/mobile viewports and
   attaches `stages.polish.evidence.visual_review.page_load`. Never hand-author,
   copy, or repair that object directly.
+- When a readability warning appears, report it with its colours, ratio, requirement and pages. Offer the operator options inside the brand palette (a darker or lighter shade of the same hue, the palette's text colour, or a larger, bold label where the design allows). Do not recolour the merchant's design until the operator chooses. Accept a warning only with the refs, reason and name the operator gives you at the QC handoff.
 - Record Polish as `completed`, `skipped`, or `blocked` with
   `campaigns-os record polish --packet <packet> --evidence <polish-evidence.json>`
   (tier `C`: it overwrites `stages.polish` in the assembly report and stamps the
   doctor output stale; `--dry-run` is tier `none`). A nonzero capture result keeps
   Polish blocked until repair and recapture. The
   producer persists bounded incomplete evidence for diagnosis and does not mark
-  the stage complete.
+  the stage complete. Record Polish as `skipped` only when the operator decides in this conversation to skip it, and quote their reason as `skip_reason`.
 - Use `npm run smoke:polish-capture` only as an optional local producer smoke
   after browser installation. It opens a loopback fixture server and is not
   part of `npm run check` or the CI browser lane.
@@ -138,7 +140,7 @@ A Polish that cannot complete is recorded with the same command: a file with
 `"status": "blocked"` and `blockers` (a non-empty array of `{"code", "message"}`
 objects), or `"status": "skipped"` and a `skip_reason` string. `evidence` is
 optional for both; the captured evidence stays. Either keeps `next` at Polish
-and QA blocked until a completed Polish is recorded.
+and QA blocked until a completed Polish is recorded. Record Polish as `skipped` only when the operator decides in this conversation to skip it, and quote their reason as `skip_reason`.
 
 The `polish.hidden_eager_media` checkpoint blocks on nonwaivable missing,
 malformed, stale, integrity-invalid, route-mismatched, or incomplete package