@nextcommerce/campaigns-os 1.61.0 → 1.63.0

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.3`, validated by `schemas/campaigns-os-runtime-recipe.v1.schema.json` (`Campaigns OS Runtime Recipe v1`). Supported surface at generation time: `1.61.0`.
+Recipe kind `campaigns-os-node-v1`, revision `1.0.3`, validated by `schemas/campaigns-os-runtime-recipe.v1.schema.json` (`Campaigns OS Runtime Recipe v1`). Supported surface at generation time: `1.63.0`.
 
 ## What this is
 
@@ -81,8 +81,9 @@ Not redundant with the install step. Because install runs with lifecycle scripts
 
 The complete input set, enumerated explicitly rather than globbed. The compiler's configured include globs are NOT the input set: two root modules enter the compilation transitively through imports from the entry module and are emitted, so a fingerprint derived from the globs would cover 36 of the 38 compiled sources and miss one of the larger emitted surfaces. Test fixtures and the package's own tests are not inputs; nothing under them is emitted. A checker resolves the compiler's actual file list and asserts it equals this enumeration, so this list cannot rot silently.
 
-Fingerprint algorithm `sha256`, over 47 enumerated files:
+Fingerprint algorithm `sha256`, over 51 enumerated files:
 
+- `campaign-spec/analytics-vendors.ts`
 - `campaign-spec/analytics-vocabulary.ts`
 - `campaign-spec/checkout-flow.ts`
 - `campaign-spec/index.ts`
@@ -91,9 +92,11 @@ Fingerprint algorithm `sha256`, over 47 enumerated files:
 - `campaign-spec/routing.ts`
 - `campaign-spec/rules/analytics-contract-shape.ts`
 - `campaign-spec/rules/assembly-hints-shape.ts`
+- `campaign-spec/rules/campaign-currencies.ts`
 - `campaign-spec/rules/campaign-metadata.ts`
 - `campaign-spec/rules/checkout-forward-target.ts`
 - `campaign-spec/rules/checkout-has-success-url.ts`
+- `campaign-spec/rules/checkout-path-has-packages.ts`
 - `campaign-spec/rules/checkout-step-reaches-checkout.ts`
 - `campaign-spec/rules/cycle-detection.ts`
 - `campaign-spec/rules/design-source-shape.ts`
@@ -106,6 +109,7 @@ Fingerprint algorithm `sha256`, over 47 enumerated files:
 - `campaign-spec/rules/index.ts`
 - `campaign-spec/rules/offer-ref-integrity.ts`
 - `campaign-spec/rules/one-checkout-per-path.ts`
+- `campaign-spec/rules/package-currency-prices.ts`
 - `campaign-spec/rules/package-pricing-sanity.ts`
 - `campaign-spec/rules/page-count.ts`
 - `campaign-spec/rules/page-id-uniqueness.ts`
@@ -137,7 +141,7 @@ The output directory is a build product. It is untracked and git-ignored, no com
 
 Directory `campaign-spec/dist`. Committed: `false`. Type entry `campaign-spec/dist/index.d.ts`.
 
-Expected inventory is derived, never listed twice. For every enumerated input under module_source_root whose path ends in .ts, the build is expected to emit campaign-spec/dist/<path relative to module_source_root, with .ts replaced> once per entry in emitted_extensions. The expected inventory is exactly that set: nothing missing, nothing extra. Emitted extensions: `.js`, `.d.ts`. At this revision that derivation yields 86 files.
+Expected inventory is derived, never listed twice. For every enumerated input under module_source_root whose path ends in .ts, the build is expected to emit campaign-spec/dist/<path relative to module_source_root, with .ts replaced> once per entry in emitted_extensions. The expected inventory is exactly that set: nothing missing, nothing extra. Emitted extensions: `.js`, `.d.ts`. At this revision that derivation yields 94 files.
 
 ### Mandatory checks
 

package/docs/sdk-storage-compatibility.md

@@ -18,7 +18,7 @@ Dynamic storage keys, unresolved storage methods, shadowed storage names, missin
 
 A `dynamic-key`, `unsupported-storage-method` or `storage-object-escape` line inside a loop, or an array callback such as `filter` or `forEach`, that tests a key it read from storage (a `k = sessionStorage.key(i)` variable, a `for…of Object.keys(sessionStorage)` or `for…in sessionStorage` variable, or the element parameter, the second for `reduce`, of a callback chained on `Object.keys(sessionStorage)`) with `k.indexOf('<prefix>') === 0` (or `!== 0`) or `k.startsWith('<prefix>')`, where the prefix is a scoped SDK key from the manifest (`next-cart-state` for `next-cart-state{__scope}`), ends in `[prefix loop: <prefix>]` and carries `prefixScan` in `--json`, when the line is where that key came from or reads that key by name. Other storage use in the loop, such as passing `sessionStorage` to a function, is not marked: the prefix test does not explain it. One note below the findings explains them all. Such a loop finds the SDK key with or without its scope suffix, so scoping alone does not break it. The lines still report unknown: Campaign Cart scopes these keys so campaigns on one origin cannot read each other's copy, and a prefix match reads whichever copy it meets first. Where the manifest names a public store for the key, as it does `useOrderStore` for `next-order`, the note names it too.
 
-Storage `length` property reads are unaffected metadata (`storage-metadata-read`). Storage `key()` enumeration, extracted method references, and mutations of reserved members remain unknown; enumeration cannot prove an SDK key lookup safe. Git discovery failures return one bounded CLI error. Local script diagnostics retain repository-relative spellings from HTML source, including `../` paths; excluded/outside sources are not read. The Git root and operator target are compared by filesystem device/inode identity, so supported case aliases and symlinks can name the same root. Source containment uses realpaths below the Git root without case folding. Extra positional CLI arguments are rejected so an accidental scope or version value cannot silently disappear.
+Storage `length` property reads are unaffected metadata (`storage-metadata-read`). Storage `key()` enumeration, extracted method references, and mutations of reserved members remain unknown; enumeration cannot prove an SDK key lookup safe. Git discovery failures return one bounded CLI error. The tracked-file inventory lists only the paths under `--scope`, so repository size does not limit it; when it fails, the error reads `Cannot inventory tracked Git source files: <reason>` with Git's own first stderr line as the reason, or, when Git printed nothing, how it ended (its exit status, the signal that stopped it, or a spawn error code), or a request to narrow a scope whose list passes 256 MiB. npm 1.61.0 and earlier listed the whole repository and stopped with `Cannot inventory tracked Git source files.` once that list passed 1 MiB (about 25,000 paths); update the install rather than running the check on a copy, which can lose tracked files. Local script diagnostics retain repository-relative spellings from HTML source, including `../` paths; excluded/outside sources are not read. The Git root and operator target are compared by filesystem device/inode identity, so supported case aliases and symlinks can name the same root. Source containment uses realpaths below the Git root without case folding. Extra positional CLI arguments are rejected so an accidental scope or version value cannot silently disappear.
 
 ## Rewriting hardcoded pins in a static repo
 

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.61.0+skills.1"
+"bundle_revision": "1.63.0+skills.1"
 ```
 
 The spelling is `<package version>+skills.<n>`:
@@ -25,7 +25,7 @@ The spelling is `<package version>+skills.<n>`:
   skills ship with (`check-skill-versions.mjs` fails if the two disagree);
 - `<n>` is a plain counter, not a semver component. It says "this is the *n*th
   skill-text revision published against that package version" and it **resets
-  with the prefix**. `1.61.0+skills.1` is therefore ahead of `1.40.0+skills.7`.
+  with the prefix**. `1.63.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.61.0+skills.1
+Bundle revision: 1.63.0+skills.1
 ```
 
 followed by a short paragraph telling the agent to run the check below at the
@@ -48,7 +48,7 @@ text the agent is actually reading, not from a file it would have to go and open
 ## The check
 
 ```bash
-npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1
+npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1
 ```
 
 The value is compared against the bundle revision of the **CLI the command runs
@@ -90,20 +90,20 @@ reports the choice as `skills.scope` (`requested`, `installed_platforms`, or
 "revision_check": "match",
 "skills_revision": {
   "status": "match",
-  "requested": "1.61.0+skills.1",
+  "requested": "1.63.0+skills.1",
   "spelling": "bundle",
-  "on_disk": "1.61.0+skills.1",
+  "on_disk": "1.63.0+skills.1",
   "on_disk_skill": null,
-  "message": "match (1.61.0+skills.1)"
+  "message": "match (1.63.0+skills.1)"
 }
 ```
 
 The text view prints one named line, as a header above the rest of the status:
 
 ```
-Skills revision: match (1.61.0+skills.1)
-Skills revision: mismatch: loaded 1.39.0+skills.1, on disk 1.61.0+skills.1 — start a fresh session
-Skills revision: unchecked (on disk 1.61.0+skills.1)
+Skills revision: match (1.63.0+skills.1)
+Skills revision: mismatch: loaded 1.39.0+skills.1, on disk 1.63.0+skills.1 — start a fresh session
+Skills revision: unchecked (on disk 1.63.0+skills.1)
 ```
 
 `unchecked` is the state when the flag is absent. It is not an error — an

package/package.json

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

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

@@ -77,6 +77,11 @@
           "pattern": "^sha256:[0-9a-f]{64}$",
           "description": "Canonical semantic identity used to correlate QA with the authored spec. hash remains exact raw-byte integrity."
         },
+        "route_masked_material_hash": {
+          "type": "string",
+          "pattern": "^sha256:[0-9a-f]{64}$",
+          "description": "The spec material with every page's page_url left out. record spec compares it to tell a change of routes alone from one that also changed anything else the build reads (#531)."
+        },
         "active_pages": {
           "type": "array",
           "items": {
@@ -164,6 +169,10 @@
             "type": ["string", "null"],
             "description": "Page Kit target file path relative to the target repo. This mirrors page_kit.output_path; source_path remains producer provenance."
           },
+          "origin": {
+            "enum": ["repo"],
+            "description": "Set on a page added from the repo's page tree after handoff (#721): its source is the target page file (page_kit.output_path), not a design source file, so source_path and skip_reason are null."
+          },
           "page_kit": {
             "type": ["object", "null"],
             "properties": {

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

@@ -149,6 +149,10 @@
                 "pattern": "^[0-9a-f]{64}$",
                 "description": "Optional sha256 of the source HTML file at the time the manifest was written. Doctor compares this to the on-disk file's actual hash and warns on mismatch (Slice 6 drift detection)."
               },
+              "origin": {
+                "enum": ["repo"],
+                "description": "Set by record spec on a page added from the repo's page tree after handoff (#721): the page's source is its target page file (page_kit.output_path) in the target repo, not a file under source_html.root, so it carries no path. Doctor counts it as mapped, and as built once that file exists."
+              },
               "page_kit": {
                 "type": "object",
                 "additionalProperties": false,
@@ -332,6 +336,11 @@
           "type": "string",
           "minLength": 1
         },
+        "runtime_dir": {
+          "type": "string",
+          "pattern": "^\\.campaign-runtime(?:/funnels/[A-Za-z0-9_-][A-Za-z0-9._-]*)?$",
+          "description": "Where this funnel's records live, relative to target_repo (and, for the QA verdict sidecar and Run Records, to this packet's directory). prepare-build writes \".campaign-runtime/funnels/<public_route_slug>\" when the project already holds another funnel's records, so one Page Kit project can hold several funnels without one overwriting another's Build Context, Assembly Report, doctor output, theme output, inputs, QA verdict sidecar or Run Records. Absent (every packet before per-funnel records, and a project's first funnel) means the project-level \".campaign-runtime\". Any value other than those two for this packet's public_route_slug is refused."
+        },
         "output_dir": {
           "type": "string",
           "minLength": 1

package/schemas/campaign-spec.v4.schema.json

@@ -73,13 +73,13 @@
         "id": { "type": "string", "description": "Campaign slug-style identifier (28/33 real specs)." },
         "name": { "type": "string" },
         "slug": { "type": "string" },
-        "currency": { "type": "string" },
+        "currency": { "type": "string", "description": "The campaign's default currency: a three-letter upper-case ISO 4217 code such as \"USD\". The CampaignCurrencies rule reports any other value as an error; a lower-case code can make Campaign Cart fall back to a cached USD campaign." },
         "language": { "type": "string" },
         "payment_env_key": { "type": "string" },
         "campaigns_api_key": { "type": ["string", "null"], "description": "Public-by-design, domain-allowlisted Campaigns API key (32/33 real specs)." },
         "available_payment_methods": { "type": "array" },
         "available_express_payment_methods": { "type": "array" },
-        "available_currencies": { "type": "array", "items": { "type": "string" } },
+        "available_currencies": { "type": "array", "items": { "type": "string" }, "description": "Every currency the campaign sells in, the default currency included, as three-letter upper-case ISO 4217 code strings. The Campaigns API returns { code, label } objects here; write the code strings. This is the CampaignSpec field: the Campaigns App API's additional_currencies is the same list without the default and is not part of the spec. The CampaignCurrencies rule reports a malformed entry as an error, and a default currency missing from a non-empty list as a warning." },
         "available_shipping_countries": {
           "description": "Arrives in THREE incompatible shapes in real exports: bare string \"all\" (5 specs), an array of country-code strings incl. [] (22+), and an array of { code, label } objects (5). All three are accepted here; normalization to one canonical shape is deliberately deferred to a later change.",
           "anyOf": [
@@ -254,13 +254,28 @@
         "name": { "type": ["string", "null"] },
         "price": { "type": ["string", "number", "null"] },
         "price_retail": { "type": ["string", "number", "null"] },
+        "prices": {
+          "type": ["array", "null"],
+          "description": "The package's price in each currency the Campaigns App prices it in, one entry per currency, read from the Campaigns API (GET /campaigns/?currency=<code>), which returns only the packages priced in the requested currency. price and price_retail stay the default currency's. Optional: a row without prices (absent or null) says nothing about other currencies. A row with prices should list every currency in campaign.available_currencies and campaign.currency; the PackageCurrencyPrices rule warns when one is missing, since the campaign leaves the package out in that currency.",
+          "items": {
+            "type": "object",
+            "additionalProperties": true,
+            "required": ["currency", "price"],
+            "properties": {
+              "currency": { "type": "string", "description": "Three-letter upper-case ISO 4217 code." },
+              "price": { "type": ["string", "number"] },
+              "price_retail": { "type": ["string", "number", "null"] },
+              "price_recurring": { "type": ["string", "number", "null"] }
+            }
+          }
+        },
         "product_name": { "type": ["string", "null"] },
         "product_sku": { "type": ["string", "null"] },
         "product_variant_name": { "type": ["string", "null"] },
         "product_purchase_availability": { "type": ["string", "null"] },
         "product_inventory_availability": { "type": ["string", "null"] },
         "image": { "type": ["string", "null"] },
-        "is_upsell": { "type": "boolean", "description": "Boolean role flag. There is no 'role' field in real exports — role is expressed by the is_upsell/is_order_bump/default_selected boolean trio." },
+        "is_upsell": { "type": "boolean", "description": "Boolean role flag. There is no 'role' field in real exports — role is expressed by the is_upsell/is_order_bump/default_selected boolean trio. What the flag means depends on the page type. On an upsell or downsell page every package row is that page's post-purchase offer and never an order bump, whatever is_upsell says, so a plain { ref_id, qty } row and one with is_upsell: true are both the page's offer. On any other page (checkout or select), is_upsell: true or is_order_bump: true marks the row as an add-on (an order bump) offered beside the main package; a row with neither flag is a main package." },
         "is_order_bump": { "type": "boolean" },
         "default_selected": { "type": "boolean" },
         "configurable": { "type": "boolean", "description": "Fixture/authoring extension marking quantity-configurable package rows." },
@@ -426,6 +441,22 @@
             }
           }
         },
+        "vendors": {
+          "type": "object",
+          "description": "Starter-template vendor adapters, keyed by vendor key (ga4, axon, taboola, triplewhale, tiktok, northbeam, snap, pinterest), as the Map Builder emits them. Each is switched on by a flat key in the campaign's _data/campaigns.json entry; see AnalyticsVendor in campaign-spec/types.ts.",
+          "additionalProperties": {
+            "type": "object",
+            "additionalProperties": true,
+            "properties": {
+              "enabled": { "type": "boolean" },
+              "id": { "type": "string" },
+              "platform": { "type": "string" },
+              "identityEnabled": { "type": "boolean" },
+              "allowedEvents": { "type": "array", "items": { "type": "string" } },
+              "blockedEvents": { "type": "array", "items": { "type": "string" } }
+            }
+          }
+        },
         "out_of_band_pixels": {
           "type": "array",
           "items": {

package/schemas/campaign-spec.v5.schema.json

@@ -73,13 +73,13 @@
         "id": { "type": "string", "description": "Campaign slug-style identifier (28/33 real specs)." },
         "name": { "type": "string" },
         "slug": { "type": "string" },
-        "currency": { "type": "string" },
+        "currency": { "type": "string", "description": "The campaign's default currency: a three-letter upper-case ISO 4217 code such as \"USD\". The CampaignCurrencies rule reports any other value as an error; a lower-case code can make Campaign Cart fall back to a cached USD campaign." },
         "language": { "type": "string" },
         "payment_env_key": { "type": "string" },
         "campaigns_api_key": { "type": ["string", "null"], "description": "Public-by-design, domain-allowlisted Campaigns API key (32/33 real specs)." },
         "available_payment_methods": { "type": "array" },
         "available_express_payment_methods": { "type": "array" },
-        "available_currencies": { "type": "array", "items": { "type": "string" } },
+        "available_currencies": { "type": "array", "items": { "type": "string" }, "description": "Every currency the campaign sells in, the default currency included, as three-letter upper-case ISO 4217 code strings. The Campaigns API returns { code, label } objects here; write the code strings. This is the CampaignSpec field: the Campaigns App API's additional_currencies is the same list without the default and is not part of the spec. The CampaignCurrencies rule reports a malformed entry as an error, and a default currency missing from a non-empty list as a warning." },
         "available_shipping_countries": {
           "description": "Arrives in THREE incompatible shapes in real exports: bare string \"all\" (5 specs), an array of country-code strings incl. [] (22+), and an array of { code, label } objects (5). All three are accepted here; normalization to one canonical shape is deliberately deferred to a later change.",
           "anyOf": [
@@ -254,13 +254,28 @@
         "name": { "type": ["string", "null"] },
         "price": { "type": ["string", "number", "null"] },
         "price_retail": { "type": ["string", "number", "null"] },
+        "prices": {
+          "type": ["array", "null"],
+          "description": "The package's price in each currency the Campaigns App prices it in, one entry per currency, read from the Campaigns API (GET /campaigns/?currency=<code>), which returns only the packages priced in the requested currency. price and price_retail stay the default currency's. Optional: a row without prices (absent or null) says nothing about other currencies. A row with prices should list every currency in campaign.available_currencies and campaign.currency; the PackageCurrencyPrices rule warns when one is missing, since the campaign leaves the package out in that currency.",
+          "items": {
+            "type": "object",
+            "additionalProperties": true,
+            "required": ["currency", "price"],
+            "properties": {
+              "currency": { "type": "string", "description": "Three-letter upper-case ISO 4217 code." },
+              "price": { "type": ["string", "number"] },
+              "price_retail": { "type": ["string", "number", "null"] },
+              "price_recurring": { "type": ["string", "number", "null"] }
+            }
+          }
+        },
         "product_name": { "type": ["string", "null"] },
         "product_sku": { "type": ["string", "null"] },
         "product_variant_name": { "type": ["string", "null"] },
         "product_purchase_availability": { "type": ["string", "null"] },
         "product_inventory_availability": { "type": ["string", "null"] },
         "image": { "type": ["string", "null"] },
-        "is_upsell": { "type": "boolean", "description": "Boolean role flag. There is no 'role' field in real exports — role is expressed by the is_upsell/is_order_bump/default_selected boolean trio." },
+        "is_upsell": { "type": "boolean", "description": "Boolean role flag. There is no 'role' field in real exports — role is expressed by the is_upsell/is_order_bump/default_selected boolean trio. What the flag means depends on the page type. On an upsell or downsell page every package row is that page's post-purchase offer and never an order bump, whatever is_upsell says, so a plain { ref_id, qty } row and one with is_upsell: true are both the page's offer. On any other page (checkout, checkout_step, select), is_upsell: true or is_order_bump: true marks the row as an add-on (an order bump) offered beside the main package; a row with neither flag is a main package." },
         "is_order_bump": { "type": "boolean" },
         "default_selected": { "type": "boolean" },
         "configurable": { "type": "boolean", "description": "Fixture/authoring extension marking quantity-configurable package rows." },
@@ -426,6 +441,22 @@
             }
           }
         },
+        "vendors": {
+          "type": "object",
+          "description": "Starter-template vendor adapters, keyed by vendor key (ga4, axon, taboola, triplewhale, tiktok, northbeam, snap, pinterest), as the Map Builder emits them. Each is switched on by a flat key in the campaign's _data/campaigns.json entry; see AnalyticsVendor in campaign-spec/types.ts.",
+          "additionalProperties": {
+            "type": "object",
+            "additionalProperties": true,
+            "properties": {
+              "enabled": { "type": "boolean" },
+              "id": { "type": "string" },
+              "platform": { "type": "string" },
+              "identityEnabled": { "type": "boolean" },
+              "allowedEvents": { "type": "array", "items": { "type": "string" } },
+              "blockedEvents": { "type": "array", "items": { "type": "string" } }
+            }
+          }
+        },
         "out_of_band_pixels": {
           "type": "array",
           "items": {

package/schemas/campaigns-os-readback.v2.schema.json

@@ -67,7 +67,7 @@
     },
     "clean": {
       "type": "boolean",
-      "description": "True only when every artifact the readback found is loaded or absent (never unreadable or unrecognized), staleness is computable and NO loaded artifact is stale, staleness.unparseable_keys is empty (no loaded artifact recorded an age the readback could not read), divergences is empty, doctor.error_count is zero, and neither evidence_debt stage is owed (any owed Polish or QA stage makes clean false). Unknown debt alone does not make clean false; consumers must inspect evidence_debt even when clean is true. A readback-integrity flag, not a verdict: a blocked QA verdict whose artifacts all read cleanly is still clean, because the readback saw exactly what Campaigns OS recorded. docs/readback.md states the rule and its limits."
+      "description": "True only when every artifact the readback found is loaded or absent (never unreadable or unrecognized), staleness is computable and NO loaded artifact is stale, staleness.unparseable_keys is empty (no loaded artifact recorded an age the readback could not read), divergences is empty, doctor.error_count is zero, and neither evidence_debt stage is owed (any owed Polish or QA stage makes clean false, except Polish marked advisory for a page-only change). Unknown debt alone does not make clean false; consumers must inspect evidence_debt even when clean is true. A readback-integrity flag, not a verdict: a blocked QA verdict whose artifacts all read cleanly is still clean, because the readback saw exactly what Campaigns OS recorded. docs/readback.md states the rule and its limits."
     }
   },
   "$defs": {
@@ -128,9 +128,62 @@
             "stage_build_fingerprint_missing"
           ],
           "description": "Null for current. Owed names a changed binding or the recorded required_by cause (build, brief, spec, or unspecified). Unknown names the unavailable input or fingerprint."
+        },
+        "change": {
+          "description": "On an owed stage, what changed since the build that stage reviewed: the rebuilds `record build` kept in stages.assembly.build_changes plus the drift on disk. Null when the stage is not owed.",
+          "oneOf": [{ "$ref": "#/$defs/evidence_debt_change" }, { "type": "null" }]
+        },
+        "advisory": {
+          "type": "boolean",
+          "description": "Polish only. True when Polish is owed but the change since it last reviewed the campaign is page-only and no brief or spec change requires it: Polish is reported and not required by next, doctor --ci or the QA gate."
+        },
+        "scope": {
+          "enum": [null, "pages", "full"],
+          "description": "QA only. pages: the change since the build QA reviewed is page-only, so QA is owed on owed_pages and qa run --page pays it. full: the change touches commerce, cannot be classified, or an input change requires QA. Null when QA is not owed."
+        },
+        "owed_pages": {
+          "type": "array",
+          "description": "QA only. The changed pages a page-scoped run must cover when scope is pages; empty otherwise.",
+          "items": { "$ref": "#/$defs/evidence_debt_page" }
         }
       }
     },
+    "evidence_debt_page": {
+      "type": "object",
+      "additionalProperties": true,
+      "required": ["page_id", "built_path"],
+      "properties": {
+        "page_id": { "type": "string", "minLength": 1 },
+        "built_path": { "type": "string", "minLength": 1 }
+      }
+    },
+    "evidence_debt_change_kind": {
+      "enum": ["none", "page_only", "commerce_affecting", "unknown"],
+      "description": "page_only: only pages changed, and none of them is a checkout page or changed its package, offer, shipping, upsell, route or script markup, and the campaign's Page Kit config entry is unchanged. commerce_affecting: anything else that could be read. unknown: the change could not be read (no usable manifest, no commerce signature on an older record, or a rebuild history that does not reach the reviewed build)."
+    },
+    "evidence_debt_reason": {
+      "type": "object",
+      "additionalProperties": true,
+      "required": ["code"],
+      "properties": {
+        "code": {
+          "enum": ["unmapped_file", "page_added", "page_removed", "checkout_page", "commerce_markup_changed", "commerce_signature_unavailable", "campaign_config_changed", "campaign_config_unavailable", "change_history_unavailable"]
+        },
+        "path": { "type": "string", "minLength": 1 }
+      }
+    },
+    "evidence_debt_change": {
+      "type": "object",
+      "additionalProperties": true,
+      "required": ["kind", "since_build_fingerprint", "changed_pages", "unmapped_files", "reasons"],
+      "properties": {
+        "kind": { "$ref": "#/$defs/evidence_debt_change_kind" },
+        "since_build_fingerprint": { "$ref": "#/$defs/build_fingerprint" },
+        "changed_pages": { "type": "array", "items": { "$ref": "#/$defs/evidence_debt_page" } },
+        "unmapped_files": { "type": "array", "items": { "type": "string" }, "description": "At most 20 paths." },
+        "reasons": { "type": "array", "items": { "$ref": "#/$defs/evidence_debt_reason" }, "description": "Why the change counts as commerce-affecting or unknown; at most 20." }
+      }
+    },
     "evidence_debt_changes": {
       "type": "object",
       "additionalProperties": true,
@@ -223,6 +276,14 @@
             "type": "string"
           },
           "description": "Complete sorted paths modified since the retained manifest, relative to the built output root."
+        },
+        "kind": {
+          "$ref": "#/$defs/evidence_debt_change_kind",
+          "description": "This drift from the retained assembly manifest, classified."
+        },
+        "reasons": {
+          "type": "array",
+          "items": { "$ref": "#/$defs/evidence_debt_reason" }
         }
       }
     },

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

@@ -1,11 +1,11 @@
 ---
 name: campaign-lifecycle-orientation
-version: 1.0.46
+version: 1.0.49
 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.61.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1`
+Bundle revision: 1.63.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read

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

@@ -1,11 +1,11 @@
 ---
 name: campaign-readback-classification
-version: 1.0.46
+version: 1.0.49
 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.61.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1`
+Bundle revision: 1.63.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read

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

@@ -1,11 +1,11 @@
 ---
 name: campaign-run-evidence
-version: 1.0.46
+version: 1.0.49
 description: Interpret existing Campaigns OS doctor, QA and proof-depth evidence without claiming more proof than the artifacts contain.
 ---
 
-Bundle revision: 1.61.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1`
+Bundle revision: 1.63.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read

package/skills/contribution-intake/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: contribution-intake
-version: 1.0.46
+version: 1.0.49
 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.61.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1`
+Bundle revision: 1.63.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read

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

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-build
-version: 1.0.51
+version: 1.0.54
 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.61.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1`
+Bundle revision: 1.63.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read
@@ -76,6 +76,7 @@ Inputs:
 - 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.
+- A Page Kit project can hold several funnels. The first one set up uses `campaign-runtime.build.json` and the `.campaign-runtime/` paths named here; each later funnel has `campaign-runtime-<route>.build.json` and keeps the same files under `.campaign-runtime/funnels/<route>/` (the packet's `assembly.runtime_dir`). Read and pass the funnel's own packet and paths; the paths `next` prints are already the right ones.
 
 Build rules:
 

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

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-os
-version: 1.0.66
+version: 1.0.69
 description: Coordinate Campaigns OS lifecycle workflows from CampaignSpec, Build Packet, starter-template contracts, stage reports, deploy evidence, and QA proof depth.
 ---
 
-Bundle revision: 1.61.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1`
+Bundle revision: 1.63.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read
@@ -81,7 +81,7 @@ the target plus a Run Record under the working directory, and they contact the
 Map and run endpoints) with a local CampaignSpec, prepared HTML/assets source, target page-kit repo, and explicit template family. The family must be certified (commerce catalog + brand contract; the CLI lists them on rejection) — an uncertified/custom family requires `--allow-uncertified-template "<reason>"` and forfeits deterministic assembly, residue QA, and pricing contracts. The entry point auto-opens the run session in the target repo; do not skip `campaigns-os run end` (tier `C`: it clears the active run session — a write that discards prior state — while assembling and remitting the Run Record) at the finish. If intake blocks with `DESIGN_SOURCE_PACKAGE_NOT_READY`, the source material carries no desktop/mobile screenshot proof: supply it through `pages[].screenshots[]` in `<source-root>/.campaigns-os/source-html-manifest.json` and follow "Clearing `DESIGN_SOURCE_PACKAGE_NOT_READY`" in `docs/design-source-package.md`, which also gives the recovery for the package a blocked run left behind.
 3. Brand-theme discovery runs in inspect-only mode by default and records `context.theme`. When it proves a brand theme is generatable and the campaign ships commerce pages, the theme gate BLOCKS polish/deploy/QA until the brand layer is applied after `next-core.css` or explicitly waived (`campaigns-os theme waive --packet <p> --reason "<why>" --waived-by "<named human>"` — tier `C`: it overwrites the assembly report and doctor output, the same named-human rule as `checkpoint waive`). Run `campaigns-os theme generate` (tier `B`: writes the theme artifacts and doctor output under the target; `--force` is tier `C` because it overwrites an existing theme) and apply it during build; do not defer the decision.
 4. Run `campaigns-os doctor --packet <packet>` (tier `A`: inspection that writes nothing and is exempt from lifecycle capture, plus one read-only live campaign request once the site is built and a public campaign key resolves; `--write` is tier `A` (the same read, plus it writes doctor output); `--built` and `--built --emit-packet` are tier `B` and write doctor output or the emitted packet under the target).
-5. Resolve the registered **Page Kit** checkpoints before runtime work. The CampaignSpec is the authority for the target's `_data/campaigns.json` entry, and the reconcile is a command, not a hand edit: `campaigns-os page-kit sync --packet <p>` (tier `B`: writes the target's `_data/campaigns.json` entry and doctor output, nothing off the machine; add `--dry-run`, tier `none` and read-only, to see the field-by-field diff first) writes the spec's `campaign.store_*` fields into the entry for the packet's route and seeds the released SDK pin (`global_config.sdk_version` is canonical, `runtime.sdk_version` an accepted alias) while the entry is still in scaffold state or behind the spec; it never moves a configured campaign's pin backwards (on an existing campaign the repo pin moves first and the Map is stale: run `campaigns-os spec derive --packet <p>` (tier `B`: writes the local CampaignSpec and doctor output), which writes the repo pin — and the page routes and analytics ids the repo carries — into the local CampaignSpec with a field-by-field diff, and add `--write-map` (tier `A`: the same local writes plus a read and a write against the Map endpoints) to record the pin in the saved Map's Build hints too (it reads the Map back and moves only the pin, forward or not at all; a Map pin ahead of the repo is refused as a warning), or re-save the Map by hand; a hand edit of the spec is never the answer for a derived field; the `campaign.store_*` fields are derived from the store itself with `spec derive --packet <p> --from-store <subdomain>` (tier `A`: it contacts the store's Admin API through the login gateway), using gateway credentials saved by `campaigns-os login --store <subdomain>` (tier `A`: it contacts the gateway and writes the credential file under your home directory) by default within the admitted owned-store private pilot; existing direct Admin callers must explicitly add `--store-token-source env:<VAR>` naming their existing environment variable (this warned break-glass path bypasses gateway custody; there is no implicit environment lookup or fallback after gateway failure; see `docs/gateway-login.md`), and a field the store cannot state is reported and left as it is, never emptied), and touches nothing else; doctor and `next` print it as the gate's `repair_target` action, and after it `page_kit.store_profile` and `page_kit.sdk_version` pass without a waiver. Starter demo residue (a demo storefront URL or phone) in that entry is never waivable and must be replaced this way. A `PARTIAL` status means a field could not be made spec-authoritative (a spec value of the wrong type or shape, the demo value itself in the spec, demo residue in a field the spec does not carry, a conflicting or non-released pin, or a gate under an active waiver); the warnings name the spec field to fix, then sync again. Missing/malformed Store Profile or SDK evidence, invalid types or semantic versions, and conflicting dual SDK declarations are not waivable. An exact valid mismatch may be accepted with named-human attribution and a bound: `campaigns-os checkpoint waive` (tier `C`: a waiver overwrites the assembly report and doctor output) `--packet <p> --gate <page_kit.store_profile|page_kit.sdk_version> --reason "<why>" --waived-by "<named human>" --review-condition "<trigger>"` (or `--expires-at <future ISO timestamp>`). The package-owned hidden eager-media checkpoint is produced and resolved during Polish in step 9.
+5. Resolve the registered **Page Kit** checkpoints before runtime work. The CampaignSpec is the authority for the target's `_data/campaigns.json` entry, and the reconcile is a command, not a hand edit: `campaigns-os page-kit sync --packet <p>` (tier `B`: writes the target's `_data/campaigns.json` entry and doctor output, nothing off the machine; add `--dry-run`, tier `none` and read-only, to see the field-by-field diff first) writes the spec's `campaign.store_*` fields into the entry for the packet's route and seeds the released SDK pin (`global_config.sdk_version` is canonical, `runtime.sdk_version` an accepted alias) while the entry is still in scaffold state or behind the spec; it never moves a configured campaign's pin backwards (on an existing campaign the repo pin moves first and the Map is stale: run `campaigns-os spec derive --packet <p>` (tier `A`: writes the local CampaignSpec and doctor output, and once the campaign is built makes the one read-only live campaign read doctor makes; `--no-live-refs` keeps it tier `B`), which writes the repo pin — and the page routes and analytics ids the repo carries, after handoff the pages the page tree adds or removes, and the offer and package fields the spec mirrors from the Campaigns App — into the local CampaignSpec with a field-by-field diff (bind it with `campaigns-os record spec --packet <p>`), and add `--write-map` (tier `A`: the same local writes plus a read and a write against the Map endpoints) to record the pin in the saved Map's Build hints too (it reads the Map back and moves only the pin, forward or not at all; a Map pin ahead of the repo is refused as a warning), or re-save the Map by hand; a hand edit of the spec is never the answer for a derived field; the `campaign.store_*` fields are derived from the store itself with `spec derive --packet <p> --from-store <subdomain>` (tier `A`: it contacts the store's Admin API through the login gateway), using gateway credentials saved by `campaigns-os login --store <subdomain>` (tier `A`: it contacts the gateway and writes the credential file under your home directory) by default within the admitted owned-store private pilot; existing direct Admin callers must explicitly add `--store-token-source env:<VAR>` naming their existing environment variable (this warned break-glass path bypasses gateway custody; there is no implicit environment lookup or fallback after gateway failure; see `docs/gateway-login.md`), and a field the store cannot state is reported and left as it is, never emptied), and touches nothing else; doctor and `next` print it as the gate's `repair_target` action, and after it `page_kit.store_profile` and `page_kit.sdk_version` pass without a waiver. Starter demo residue (a demo storefront URL or phone) in that entry is never waivable and must be replaced this way. A `PARTIAL` status means a field could not be made spec-authoritative (a spec value of the wrong type or shape, the demo value itself in the spec, demo residue in a field the spec does not carry, a conflicting or non-released pin, or a gate under an active waiver); the warnings name the spec field to fix, then sync again. Missing/malformed Store Profile or SDK evidence, invalid types or semantic versions, and conflicting dual SDK declarations are not waivable. An exact valid mismatch may be accepted with named-human attribution and a bound: `campaigns-os checkpoint waive` (tier `C`: a waiver overwrites the assembly report and doctor output) `--packet <p> --gate <page_kit.store_profile|page_kit.sdk_version> --reason "<why>" --waived-by "<named human>" --review-condition "<trigger>"` (or `--expires-at <future ISO timestamp>`). The package-owned hidden eager-media checkpoint is produced and resolved during Polish in step 9.
 6. On any doctor run that sees built output, resolve `built_output.upsell_selector_scope`. A `data-next-bundle-selector` on a page whose funnel role is `upsell` or `downsell` writes to the shopper's LIVE CART unless it carries `data-next-upsell-context`; loading the page then adds that package with no click, and it is charged at the next checkout without appearing in that checkout's rendered order summary. Being hidden does not help — the write happens at init. Fix it by adding `data-next-upsell-context` to the named selector, or by deleting a selector that exists only to display a price. This gate runs on EVERY doctor invocation, not only after assembly, because the defect it was written for was introduced by a later review round. If a cart-scoped selector on a post-purchase page is genuinely intended, record it: `campaigns-os checkpoint waive --packet <p> --gate built_output.upsell_selector_scope --reason "<why>" --waived-by "<named human>" --review-condition "<trigger>"`. On the same runs, resolve `built_output.campaign_identity`: every page must name the same campaign — one API key (`next-api-key` meta or the `config.js` / `window.nextConfig` `apiKey`), one `next-funnel`, and any `setAttribution({ funnel })` call agreeing with the tag of the page that makes it. A page copied from another funnel that still carries the other campaign's key, tag, or call binds and renders without complaint and puts the order on the wrong campaign. Each error names the two files and the two values; make the one-line edit it describes. Not waivable — there is no `checkpoint waive` lane for it. Parked `-backup-` / `-old-` copies are skipped and listed, not scanned. Also resolve `built_output.sdk_markup`: its blockers (`SWAP_WITH_ADD_TO_CART`, `CHECKOUT_NOT_FORM`, `WRONG_FIELD_NAME`, `MISSING_SELECTOR_ID_MATCH`) are markup the SDK binds and then silently no-ops or double-writes on — fix the markup the message names (it gives the SDK spelling for a wrong field name); its warnings (`DOUBLE_SELECTED`, `TEMPLATE_DOUBLE_BRACE`) are advisory. Neither is waivable. A `data-next-*` name the SDK does not read shows up as one advisory line naming the attribute index version, not a warning.
 7. If doctor's `next` block says `doctor-blocked` or `prepare-build` (it names the same stage `campaigns-os next` would), stop and resolve the named blockers.
 8. If doctor returns `build`, hand off with `campaigns-os next build --packet <packet>` (tier `A`, like every `next` form: additive writes under `.campaign-runtime/` plus a stage-progress POST once Run Telemetry consent is persisted; `--no-write` and `--no-remit` are each tier `B` and keep the invocation local) and follow `next-campaigns-build`'s recommended **build → independent review → repair → verification** loop. Stage completion is recorded by command, never by hand-editing `.campaign-runtime/` JSON: `campaigns-os record setup`, `record build` (after every page-kit build) and `record polish --evidence <file>` (tier `C` each: they overwrite the stage record they name and stamp the doctor output stale; `--dry-run` is tier `none`).
@@ -96,6 +96,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`).
+   After launch, a rebuild that touches only some pages' HTML is the exception to steps 9 and 10: readback's `evidence_debt` marks Polish advisory and QA scoped to the changed pages, and `campaigns-os next` names `qa run --packet <packet> --page <page_id>`, which places no test orders. Follow `next`.
 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.
 
@@ -133,6 +134,7 @@ Rules:
 - 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 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.
+- A Page Kit project can hold several funnels. The first one set up uses `campaign-runtime.build.json` and the `.campaign-runtime/` paths named here; each later funnel has `campaign-runtime-<route>.build.json` and keeps the same files under `.campaign-runtime/funnels/<route>/` (the packet's `assembly.runtime_dir`). Read and pass the funnel's own packet and paths; the paths `next` prints are already the right ones.
 - 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-setup/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: next-campaigns-os-setup
-version: 2.0.49
+version: 2.0.52
 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.61.0+skills.1
-Run `npx --no-install campaigns-os tooling status --skills-revision 1.61.0+skills.1`
+Bundle revision: 1.63.0+skills.1
+Run `npx --no-install campaigns-os tooling status --skills-revision 1.63.0+skills.1`
 from the campaign's Page Kit folder, where it runs the project's pinned copy and
 never installs one, at the start of each task. Start a fresh session if it
 reports `mismatch`: this text is already in your context and is never re-read
@@ -53,6 +53,8 @@ Responsibilities:
 - 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.
+- A Page Kit project can hold several funnels. The first one set up uses `campaign-runtime.build.json` and the `.campaign-runtime/` paths named here; each later funnel has `campaign-runtime-<route>.build.json` and keeps the same files under `.campaign-runtime/funnels/<route>/` (the packet's `assembly.runtime_dir`). Read and pass the funnel's own packet and paths; the paths `next` prints are already the right ones.
+- When prepare-build prints a `Funnel:` line, it set up a new route as another funnel beside the default packet. If the operator meant to rename the existing funnel's route, follow the steps that line prints (delete the new packet and its directory, then re-run with `--out campaign-runtime.build.json --force`); ask before running it, because `--force` clears that funnel's recorded stage evidence.
 - 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`.