@nextcommerce/campaigns-os 1.52.0 → 1.53.0

package/docs/polish-evidence.md

@@ -119,6 +119,8 @@ It warns when a video, or an image over 500,000 transfer bytes, comes from the p
 
 The size check covers `<img>` elements in the page, including those inside open and closed shadow roots; images inside an iframe, `<input type=image>`, `<object>`, SVG `<image>` and CSS background images are not checked for size, and only their transfer bytes are weighed.
 
+**Readability.** `polish capture` also measures text contrast on every page under `_site/<slug>/` (up to 128 pages per run), at desktop (1440×1200) and mobile (390×844) widths, device pixel ratio 1, including campaigns whose pages are all template stock: the Polish route plan now covers the mapped pages plus every built page, while the page-load capture keeps its own page set. On a campaign with no mapped pages, `polish capture` measures readability, prints the page-load message as a warning, and exits successfully. The text it reads: purchase, accept and decline controls; submit buttons and submit-type inputs; SDK action controls; bundle cards (names, prices, badges and the card selected at load); order bumps; prices; checkout labels and placeholder hints; and other body text. Ratios follow WCAG 2.x and are compared unrounded: 4.5:1 for normal text, 3:1 for large text (at least 24 CSS px, or at least 18.66 CSS px at weight 700 or more; semibold does not qualify). Colours in any CSS Color 4 form the browser reports are converted to sRGB; values outside sRGB are clipped and marked. Backgrounds are composited through transparent layers. SVG text is measured with its fill colour, and placeholder hints with their own colour, size and weight. Gradients, background images, pseudo-element backgrounds, a `::first-line` or `::first-letter` style that changes the text's colour, background or opacity, overlapping positioned layers or images (and the shapes of an SVG drawing under its text), text clipped to a background, colours that cannot be read (including a text fill colour, and an SVG fill that is not a plain colour or is combined with a stroke), and controls marked disabled only by the SDK's `next-disabled` class produce a review result with a reason and a crop; so do opacity, filters, blend modes and masks on the text or on any element around it. `clip-path` is ignored. Disabled controls (`disabled` or `aria-disabled="true"`) are listed as excluded (inactive control) and are never accepted; `readonly` is not disabled. Polish measures the states present when the page loads — default, selected, active, and open panels — without clicking, scrolling or typing. Text that has not rendered, controls still loading, controls hidden at load, text supplied by CSS `content`, selection states and collapsed panels not present at load, text inside closed shadow roots or cross-origin frames, pages measured before the SDK, stylesheets or fonts were ready, and pages not captured are listed as unexercised. Overlapping layers are detected by box intersection: a layer the page paints over text in another way is not detected. A ratio under the requirement is a warning. Warnings never block Polish or change readiness. The probe reads the page without changing it, and adds at most about five minutes of work per run; pages it could not reach in that time are listed as unexercised. The stored measurements are re-derived on every read, and the page set, widths and campaign are checked against the current build; but the colours the browser reported are tamper-evident only, like other Polish captures. Readability and media weight results read as stale when the built output differs from the recorded build, even before a new `record build`.
+
 ### Collector response records (the producer's wire form)
 
 Inside the producer, the browser adapter's CDP collector emits one

package/docs/progress-snapshots.md

@@ -18,8 +18,7 @@ blocked QA keeps it open. A progress delivery cannot close a run.
 
 The strict v0 object carries its schema, package version, observation timestamp,
 producer (`next` or `qa`), opaque progress stream and sequence, prior snapshot ID,
-content digest, Map ID and separate revision/spec/build hashes. Six independent
-stage records retain observed status and explicit build binding. Continuation
+content digest, Map ID and separate revision/spec/build hashes. Six independent stage records carry each stage's effective status and explicit build binding: the status the Assembly Report records, 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`. Continuation
 retains the canonical stage, blocked/divergent flags, fixed action IDs and gate
 states. Preview carries only presence and a hash of the URL. An optional QA block
 retains the exact verdict ID, disposition (including `ready_with_exceptions`),
@@ -28,8 +27,7 @@ retained verdict; recovery uses `qa publish`, without repeating an order.
 
 No commands, prompts, free text, content, local paths, URLs, query strings,
 credentials, order values or customer payloads enter the wire. Unknown vocabulary
-becomes a fixed `unknown` marker and cannot imply a passing continuation. A
-stage's observed `completed` status is a ledger claim, not independent verification.
+becomes a fixed `unknown` marker and cannot imply a passing continuation. A stage's `completed` status is a ledger claim, checked only against the brief and CampaignSpec content it records; it is not independent verification.
 Only matching fingerprints carry `matching`; absent or unverifiable binding is
 `unconfirmed`. A current local output hash never proves a deployment is current.
 

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

@@ -1893,6 +1893,8 @@ A redirect to the right page is fine. Missing links, links whose query differs,
 
 **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

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.52.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/skills-revision.md

@@ -16,7 +16,7 @@ that the copy on disk moved.
 `skills.json` carries one top-level field:
 
 ```json
-"bundle_revision": "1.52.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.52.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.52.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.52.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.52.0+skills.1",
+  "requested": "1.53.0+skills.2",
   "spelling": "bundle",
-  "on_disk": "1.52.0+skills.1",
+  "on_disk": "1.53.0+skills.2",
   "on_disk_skill": null,
-  "message": "match (1.52.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.52.0+skills.1)
-Skills revision: mismatch: loaded 1.39.0+skills.1, on disk 1.52.0+skills.1 — start a fresh session
-Skills revision: unchecked (on disk 1.52.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.52.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.27
+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.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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.27
+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.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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.27
+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.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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.27
+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.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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.32
+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.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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.47
+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.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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
@@ -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.

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

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-os-setup
-version: 2.0.30
+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.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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.31
+version: 1.1.33
 description: Run the visual/runtime polish pass after build and before QA for a Campaigns OS campaign.
 ---
 
-Bundle revision: 1.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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

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

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-qa
-version: 1.3.31
+version: 1.3.33
 description: Run spec-aware QA from a saved Map or local-spec Build Packet and tested campaign URL after build, polish, and deploy/local evidence exist, including Playwright typed-card test-order proof.
 ---
 
-Bundle revision: 1.52.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.52.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
@@ -70,6 +70,7 @@ Inputs:
 - tested base URL (localhost dev URL, preview URL, or production URL)
 - assembly report
 - Test-order coverage choice (`common` default vs explicit paths vs topology-complete `full`) and SDK origin state (localhost is a Development domain; non-localhost origins need allowlist confirmation so the SDK loads)
+- 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.
 
 Rules:
 
@@ -121,6 +122,7 @@ Rules:
 - For multi-market campaigns, verify at least one non-default currency/country path: currency display, shipping method names/prices, available payment methods, and market-specific copy.
 - Treat missing deploy URL, missing polish status, or unresolved doctor blockers as launch blockers.
 - Report blockers, warnings, and residual risks.
+- 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.
 - At the end of QA, run `next` and present the QC handoff once. Ask the operator which open warnings to accept and why. Run `checkpoint accept` only with the refs, reason, and name the operator gave you in this conversation. Never write `qc_accepts`, `qc_results`, or QA verdict files by hand. The up-front test-order permission does not cover accepts.
 - QA follows build and polish; it does not edit campaign code.
 

package/skills.json

@@ -1,7 +1,7 @@
 {
   "name": "campaigns-os-skills",
   "description": "Skills bundled with Campaigns OS. `skills.sh` installs these into the shared agent skill directories (~/.claude/skills, ~/.codex/skills), so each one is a versioned package: bump the version whenever a package changes. `bundle_revision` identifies the bundle as a whole — `<package version>+skills.<n>`, where the prefix is this package's version and `<n>` counts the skill-text revisions published against it. It advances whenever ANY bundled skill changes, every SKILL.md states it on its first body line, and `campaigns-os tooling status --skills-revision <value>` compares the value an agent read from a skill against the bundle on disk. See docs/skills-revision.md.",
-  "bundle_revision": "1.52.0+skills.1",
+  "bundle_revision": "1.53.0+skills.2",
   "homepage": "https://github.com/NextCommerceCo/campaigns-os",
   "retired_skills": [
     {
@@ -16,7 +16,7 @@
     {
       "id": "next-campaigns-os",
       "name": "Campaigns OS Lifecycle",
-      "version": "1.0.47",
+      "version": "1.0.49",
       "path": "skills/next-campaigns-os/SKILL.md",
       "domain": "campaigns",
       "description": "Coordinate Campaigns OS lifecycle workflows from CampaignSpec, Build Packet, starter-template contracts, stage reports, deploy evidence, and QA proof depth."
@@ -24,7 +24,7 @@
     {
       "id": "next-campaigns-os-setup",
       "name": "Campaigns OS Setup",
-      "version": "2.0.30",
+      "version": "2.0.32",
       "path": "skills/next-campaigns-os-setup/SKILL.md",
       "domain": "campaigns",
       "description": "Bootstrap or prepare a target page-kit campaign repo from a doctor-cleared Campaigns OS Build Packet before full build wiring. Formerly next-campaigns-setup; renamed to release that name to the published NextCommerceCo/skills scaffolder."
@@ -32,7 +32,7 @@
     {
       "id": "next-campaigns-build",
       "name": "Campaign Build",
-      "version": "1.0.32",
+      "version": "1.0.34",
       "path": "skills/next-campaigns-build/SKILL.md",
       "domain": "campaigns",
       "description": "Assemble a NEXT campaign from a doctor-cleared Build Packet, CampaignSpec/API values, prepared HTML/assets, page-kit, and starter-template contracts."
@@ -40,7 +40,7 @@
     {
       "id": "next-campaigns-polish",
       "name": "Campaign Polish",
-      "version": "1.1.31",
+      "version": "1.1.33",
       "path": "skills/next-campaigns-polish/SKILL.md",
       "domain": "campaigns",
       "description": "Run the visual/runtime polish pass after build and before QA for a Campaigns OS campaign."
@@ -48,7 +48,7 @@
     {
       "id": "next-campaigns-qa",
       "name": "Campaign QA",
-      "version": "1.3.31",
+      "version": "1.3.33",
       "path": "skills/next-campaigns-qa/SKILL.md",
       "domain": "campaigns",
       "description": "Run spec-aware QA from a saved Map or local-spec Build Packet and tested campaign URL after build, polish, and deploy/local evidence exist, including Playwright typed-card test-order proof."
@@ -56,7 +56,7 @@
     {
       "id": "campaign-lifecycle-orientation",
       "name": "Campaign Lifecycle Orientation",
-      "version": "1.0.27",
+      "version": "1.0.29",
       "path": "skills/campaign-lifecycle-orientation/SKILL.md",
       "domain": "campaigns",
       "description": "Orient a reader to the Campaigns OS lifecycle artifacts a run has already emitted, without advancing their state: the shared vocabulary, doctor as a gate, the stage record, and the store-theme/Page Kit two-worlds trap."
@@ -64,7 +64,7 @@
     {
       "id": "campaign-run-evidence",
       "name": "Campaign Run Evidence",
-      "version": "1.0.27",
+      "version": "1.0.29",
       "path": "skills/campaign-run-evidence/SKILL.md",
       "domain": "campaigns",
       "description": "Interpret existing doctor, QA verdict and proof-depth evidence without claiming more proof than the artifacts contain, and keep funnel proof apart from merchant launch readiness."
@@ -72,7 +72,7 @@
     {
       "id": "campaign-readback-classification",
       "name": "Campaign Readback Classification",
-      "version": "1.0.27",
+      "version": "1.0.29",
       "path": "skills/campaign-readback-classification/SKILL.md",
       "domain": "campaigns",
       "description": "Classify a selected campaign from the campaigns-os-readback/v2 fields (artifacts, staleness.stale_keys, clean, doctor, divergences, skip_cascades) and write a read-only handoff without turning diagnosis into permission."
@@ -80,7 +80,7 @@
     {
       "id": "contribution-intake",
       "name": "Contribution Intake",
-      "version": "1.0.27",
+      "version": "1.0.29",
       "path": "skills/contribution-intake/SKILL.md",
       "domain": "campaigns",
       "description": "Turn a suggestion about the agent surface into a classified, evidence-checked and redacted proposal, filed on this repository tracker only with attended approval."