[next-devin]

The campaign quickstart assumed a new Page Kit project and left URL intake, existing builds and session handoffs implicit. This extends the guide to cover those entry points, preserve build and hosting choices, and describe the local preview before commerce is connected: a scaffold made without a campaign key runs against the starter templates' demo campaign, which is fine for reviewing layout and flow and is not evidence about the merchant's campaign.

Earlier revisions carried a hand-authored static-concept procedure, a Page Kit release gate, and an empty-key template premise, each a workaround for the demo key. All three went once the harm was named correctly: demo-bound pages must not be accepted as proof, which is tracked in NextCommerceCo/campaigns-os#701.

Validation: production build and documentation checks pass. No merge gate. Companion: NextCommerceCo/skills#88, which merges after this.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	developer-docs	867ec2a	Commit Preview URL Branch Preview URL	Oct 23 2026, 05:28 AM

[kilo-code-bot]

Code Review Summary

Status: 4 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	4
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
content/agent-setup.md	77	The premise rewrite to "demo campaign" deleted the vendor-snippet warning with no replacement. Since the SDK now boots on the demo key, an existing slug's real gtm_id/fb_pixel_id in _data/campaigns.json forward demo-store funnel events into the merchant's live vendor accounts — a risk the paragraph no longer mentions at all.
content/docs/campaigns/index.mdx	51	Same vendor-snippet omission. The callout needed the analytics contradiction removed, but not the vendor caveat; the new demo-key premise turns that silence into real GTM/Pixel pollution on an existing slug.
content/docs/campaigns/page-kit.mdx	75	Same omission as index.mdx:51, and worse for existing-campaign readers: the link to Analytics & Tracking was the only route to providers.*.enabled from this page, and the callout now implies a demo preview is inert.
content/agent-setup.md	39	Carried forward and re-verified: the inspection step still drops --save-exact pinning, the separate-directory install, and --no-install, so a bare npx campaigns-os standardize fetches and runs the registry latest against a merchant's live campaign source. Active inline comment (id 4355814021); author replied "Kept" with reasoning, retained as unresolved.

Files Reviewed (4 files changed since 8746699)

• content/agent-setup.md - 1 new issue (line 77), 1 carried-forward (line 39, targeted verification only)
• content/docs/campaigns/index.mdx - 1 new issue (line 51)
• content/docs/campaigns/page-kit.mdx - 1 new issue (line 75)
• scripts/check-agent-surfaces.mjs - no new issues

Resolved since last review

• content/docs/campaigns/index.mdx:51 and content/docs/campaigns/page-kit.mdx:75 — the "no SDK analytics events" claims are gone from both callouts. The contradiction with each page's own Analytics section (always-on nextCampaign provider in auto mode, line 253 of index.mdx) is fully resolved; neither callout now makes any analytics assertion.
• content/agent-setup.md — the previous preview paragraph's self-contradiction and the "edit an existing slug's vendor keys" instruction are gone.

Notes

• HEAD confirmed as 867ec2a (advanced from 8746699) at time of writing and re-verified immediately before publishing; local worktree is clean and matches headRefOid.
• Scope was the incremental diff 8746699..HEAD (4 changed lines across 3 files, plus the 1-line drift-check needle update), well under the sub-agent tiering thresholds, so the review was done directly with full-file reads for context.
• The three new findings are one defect with three call sites, not three independent defects: the commit correctly fixed the analytics contradiction but over-corrected by deleting the vendor-snippet caveat alongside it. Fixing agent-setup.md:77 and restoring one sentence in each callout resolves all three.
• The check-agent-surfaces.mjs change was verified against its consumer: the needle 'demo campaign' matches content/agent-setup.md:77, and the check at line 130 asserts out/agent-setup/prompt.md equals the canonical source, so the needle can only pass if the generated prompt carries the new text.
• No build or lint command was run; this session is read-only and the repo's drift check requires a full generate plus npm run build. Findings are from static analysis of the diff and full-file reads.
• The demo-key premise itself was taken as given per the commit message (campaign-cart-starter-templates#245 closed on review) and not independently verified against the template repository; the findings above hold under that premise.

Fix these issues in Kilo Cloud

Previous Review Summaries (6 snapshots, latest commit 8746699)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 8746699)

Status: 3 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	3
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
content/agent-setup.md	39	Carried forward: the inspection step still drops --save-exact pinning, the separate-directory install, and --no-install, so a bare npx campaigns-os standardize fetches and runs the registry latest against a merchant's live campaign source. Already has an active inline comment (unresolved).
content/docs/campaigns/index.mdx	51	The rewritten callout fixes the vendor-key half, but the retained "no SDK analytics events" claim still contradicts this page's own Analytics section (line 253: the internal nextCampaign provider is always-on in auto mode, tracks the full funnel, needs no code and no API key). A reader following line 51 and reaching line 253 gets two opposite answers.
content/docs/campaigns/page-kit.mdx	75	Same analytics contradiction, with no local Analytics section to reconcile it. Additionally, providers.*.enabled is documented as living in assets/config.js, but this sentence places it directly after the _data/campaigns.json keys, so a reader grepping the registry finds nothing; and "A new slug has none" has no clear antecedent or named subject for the existing-project case that step 6 creates.

Files Reviewed (2 files changed since 3a7355a)

• content/docs/campaigns/index.mdx - 1 new issue
• content/docs/campaigns/page-kit.mdx - 1 new issue
• content/agent-setup.md - 1 carried-forward issue (targeted verification only, file not in the incremental diff)

Resolved since last review

• content/docs/campaigns/page-kit.mdx:55 — the npx --no-install campaign-init sentence that contradicted the five bare-npx blocks on the page has been dropped; the paragraph now states only project-root and pinned-version, which the command blocks match.
• content/docs/campaigns/index.mdx:51 — "load regardless" is replaced with an accurate statement that the vendor snippets load independently of the SDK key and that providers.*.enabled governs only forwarding. The earlier wrong-trigger and unsafe "leave those empty" problems are gone; the existing-slug case is now covered by "leave an existing slug's keys untouched".
• content/docs/campaigns/page-kit.mdx:75 — the same correction landed here, and the page links to the section that documents the flags.

Notes

• HEAD confirmed as 8746699 at time of writing; the local worktree is clean and matches headRefOid.
• Scope was the incremental diff 3a7355a..HEAD (3 changed lines across 2 files), well under the sub-agent tiering thresholds, so the review was done directly with full-file reads for context.
• No build or lint command was run; this session is read-only and the repo's drift check requires a full generate plus npm run build. Findings are from static analysis of the diff and full-file reads.
• All anchor targets were verified: index.mdx:251 is ## Analytics & Tracking, which generates the #analytics--tracking anchor used by both callouts.
• gh pr diff emits one diff section per commit; the cumulative base→HEAD hunks were used for target-line validation (@@ -48,7 +48,7 for index.mdx, @@ -70,7 +72,7 for page-kit.mdx).

Fix these issues in Kilo Cloud

Previous review (commit 3a7355a)

Status: 4 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	4
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
content/docs/campaigns/page-kit.mdx	55	The paragraph mandates npx --no-install campaign-init while this same commit rewrites all five invocation blocks on the page to bare npx campaign-init. Self-contradictory, and it silently reverts the implicit-download protection an earlier commit in this PR added.
content/agent-setup.md	39	The inspection step drops --save-exact version pinning, the separate-directory install, and --no-install, leaving a bare npx campaigns-os standardize. This fetches and executes the registry latest at run time while reading a merchant's live campaign source, and its output is cited as handoff evidence. This file is served verbatim to agents (check-agent-surfaces.mjs:130 asserts byte-identity with the generated prompt).
content/docs/campaigns/index.mdx	51	"load regardless" names the wrong trigger — this page's own line 269 documents providers.gtm.enabled/providers.facebook.enabled as the actual control, shipped false. "Leave those empty" is also unsafe for the existing-project case campaign-init supports (line 41), where it would blank a live slug's gtm_id/fb_pixel_id.
content/docs/campaigns/page-kit.mdx	75	Same defect as index.mdx:51, compounded because providers.*.enabled appears nowhere on this page — the linked section is the only place in the doc set that documents it. The same "leave those empty" instruction is unsafe against an existing project's registry (step 6, line 70).

Files Reviewed (9 files)

• content/agent-setup.md - 1 issue
• content/capabilities.yaml - 0 issues
• content/docs/campaigns/index.mdx - 1 issue
• content/docs/campaigns/page-kit.mdx - 2 issues
• content/docs/skills/index.mdx - 0 issues
• app/llms.txt/route.ts - 0 issues
• package.json - 0 issues
• scripts/check-agent-surfaces.mjs - 0 issues
• scripts/generate-agent-setup.mjs - 0 issues

Resolved since last review

• The prior content/agent-setup.md finding instructing an unsafe edit of a live campaign's vendor keys is resolved: line 77 now states an existing slug keeps its tracking configuration and tells the agent to treat that preview as live for those vendors rather than editing the registry. It also correctly drops the redundant runtime_mode check and scopes the claim to SDK analytics events.
• scripts/check-agent-surfaces.mjs:143-144 needles were updated to match the new bare-npx commands and are satisfied by content/agent-setup.md:53,59. The --api-key negative assertion still holds.

Notes

• The package.json generate script reorder (moving generate-agent-setup.mjs before generate-capability-map.mjs) is benign: generate-agent-setup.mjs reads only content/agent-setup.md and content/evaluate-next.md, with no dependency on capability-map output.
• content/docs/agent-setup/index.mdx is gitignored and regenerated from content/agent-setup.md, so it is correctly not part of the diff.
• No build or lint command was run; this session is read-only and the repo's checks require a full npm run build plus generate step. Findings above are from static analysis of the diff against the base (dc2d86a) and full-file reads of each changed file.

Fix these issues in Kilo Cloud

Previous review (commit c9ec24a)

Status: 3 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	3
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
content/docs/campaigns/index.mdx	55	"Vendor snippets set through _data/campaigns.json keys ... load regardless, so leave those empty" names the registry IDs as the load trigger, but this page's own Analytics section (line 273) gates forwarding on providers.gtm.enabled / providers.facebook.enabled, shipped false. The instruction omits the flag that actually controls the behavior, so it both overstates the risk and fails to close the check.
content/docs/campaigns/page-kit.mdx	79	Same unqualified "load regardless". Worse on this page: providers appears nowhere in page-kit.mdx, so the enable-flag control that the linked section documents is unavailable to the reader without leaving the page.
content/agent-setup.md	89	"Before npm run dev, confirm ... the slug's vendor keys are empty" cannot be satisfied by inspection for an existing slug (the same sentence says it "keeps whatever it has"), so it amounts to instructing an edit of a live campaign's _data/campaigns.json with no instruction to copy, record the original values, or restore them. Risk of shipping a campaign with tracking silently disabled.

Files Reviewed (4 files)

• content/agent-setup.md - 1 issue
• content/docs/campaigns/index.mdx - 1 issue
• content/docs/campaigns/page-kit.mdx - 1 issue
• scripts/check-agent-surfaces.mjs - 0 issues

Resolved since last review

• The three prior analytics-claim findings on scope ("no SDK analytics events") are addressed: all three sites now scope the claim to SDK analytics and link to the analytics reference.
• The ${CAMPAIGN_API_KEY:?...} guard introduced at index.mdx:301, page-kit.mdx:121 and page-kit.mdx:130 closes the empty-argument path.
• The Page Kit 0.3.0 release gate is replaced by the template-state claim, and scripts/check-agent-surfaces.mjs:139 is updated to the matching needle (ship with an empty \apiKey`), which is present in content/agent-setup.md:89. The --api-key` negative assertion still holds (no literal in the prompt).

Fix these issues in Kilo Cloud

Previous review (commit e910dae)

Status: 3 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	3
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
content/docs/campaigns/index.mdx	55	"Vendor snippets ... load regardless, so leave those empty" names the registry IDs as the load trigger, but this page's own Analytics section (line 273) gates forwarding on providers.gtm.enabled / providers.facebook.enabled, shipped false. The instruction omits the flag that actually controls the behavior, so it both overstates the risk and fails to close the check.
content/docs/campaigns/page-kit.mdx	79	Same unqualified "load regardless". Worse on this page: providers appears nowhere in page-kit.mdx, so the enable-flag control that the linked section documents is unavailable to the reader without leaving the page.
content/agent-setup.md	89	"Before npm run dev, confirm ... the slug's vendor keys are empty" cannot be satisfied by inspection for an existing slug (the same sentence says it "keeps whatever it has"), so it amounts to instructing an edit of a live campaign's _data/campaigns.json with no instruction to copy, record the original values, or restore them. Risk of shipping a campaign with tracking silently disabled.

Files Reviewed (3 files)

• content/agent-setup.md - 1 issue
• content/docs/campaigns/index.mdx - 1 issue
• content/docs/campaigns/page-kit.mdx - 1 issue

Resolved since last review

• The three previous analytics-claim findings are addressed: all three sites now scope the claim to SDK analytics, carry the vendor-key caveat, and link to the analytics reference. index.mdx / page-kit.mdx also now use the ${CAMPAIGN_API_KEY:?...} guard, closing the empty-argument path.

Fix these issues in Kilo Cloud

Previous review (commit 4d77a1b)

Status: 3 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	3
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
content/agent-setup.md	89	The unconditional "npm run dev is safe to open" claim replaces a version-scoped one. The removed text said "Page Kit 0.3.0 may retain demo commerce credentials and enabled tracking" and required inspecting the installed version first. Per the PR body this behavior comes from campaign-page-kit#28 and the PR states "Merge after campaign-page-kit#28 is released" — so it is false for the 0.3.0 pin an existing project may still hold. Same wording at index.mdx:55 and page-kit.mdx:79.
content/agent-setup.md	89	The safety grant is conditional ("safe to open in that state") but nothing tells the agent which state it is in. runtime_mode: "unconfigured" is the only signal, and the guide never instructs reading it before opening the dev server — or re-checking after npm run config binds a live campaign.
content/docs/campaigns/index.mdx	301	--api-key "${CAMPAIGN_API_KEY:?...}" → --api-key "$CAMPAIGN_API_KEY" removes the required-value abort, and the sentence documenting it ("The required-value expansion stops the command if it is missing") was deleted. An unset variable now expands to --api-key "" and the run proceeds; since --non-interactive documents exit 5 for missing required input, a reader expects a clean failure rather than a blank key written into assets/config.js. Same at page-kit.mdx:121,130.

Files Reviewed (4 files)

• content/agent-setup.md - 2 issues
• content/docs/campaigns/index.mdx - 1 issue (shared root cause with page-kit.mdx:121,130)
• content/docs/campaigns/page-kit.mdx - 0 additional (reviewed; mirror sites noted in comments)
• scripts/check-agent-surfaces.mjs - 0 issues

Notes on scope

Incremental commits 7ec6918..4d77a1b are 4 files / 38 insertions / 71 deletions — Small tier, reviewed directly with no sub-agents.

Previously reported findings and their status. The three findings from the prior summary were all resolved in 7ec6918 (the head of the previous review) and are not carried forward: the ${CAMPAIGN_API_KEY:?...} argv/echo tension (4348576696) was resolved by the author arguing the Campaign Cart key is public and --api-key-file does not exist in 0.1.3/0.3.0 — the removal in this increment is therefore a deliberate change, not a regression of that fix, and is flagged on its new merits below; the 0.1.4-floor scope (4348576703) and the unfalsifiable preview gate (4348576709) were both answered and are moot now that 4d77a1b deletes the preview-gate sentence outright. The index.mdx:39 link to #installed-version-compatibility was dropped in this increment while page-kit.mdx:59 retains the section — see below.

Drift checks verified against current source. scripts/check-agent-surfaces.mjs:139 swaps the needles 'Page Kit 0.3.0' / 'Commerce unconfigured' for 'runtime_mode: "unconfigured"'; the replacement literal matches content/agent-setup.md:89 exactly (single-quoted JS string containing runtime_mode: "unconfigured"), so the check still passes. The negative guard at line 154 (!setupPrompt.includes('--template apollo')) is unaffected — --template apollo lives only in index.mdx and page-kit.mdx, which are in the campaigns bundle, not the agent-setup prompt. The negative guard at line 152 (!setupPrompt.includes('--api-key')) is also still satisfied; the incremental diff removed the last prose mention from agent-setup.md, so this guard is now trivially true rather than meaningfully enforced. The version marker is unchanged at version=3 across this increment (bumped 2→3 earlier in the PR); given 4d77a1b deletes an entire procedure section and rewrites the preview-safety guidance, consider whether version=4 is warranted for a published agent prompt.

Cross-page consistency. The --api-key guard was removed consistently across all three invocation sites (index.mdx:301, page-kit.mdx:121, page-kit.mdx:130), and the "do not echo the key" clause was dropped from all three, which is coherent with the author's stated reasoning. The one asymmetry introduced by this increment: index.mdx:39 no longer links to #installed-version-compatibility, but page-kit.mdx:59 keeps the section and now compresses it to a single sentence that states the 0.1.4 JSON floor without the previously present "check the installed release's documentation before using these commands in an older project" instruction. index.mdx is the quick-start page readers reach first and it carries its own campaign-build-free examples, so the orphaned link is low-impact, but the compression does drop the only remaining version-check directive on that page.

Assumptions / validation gaps. next-campaign-page-kit is not present in node_modules or package-lock.json, so the three load-bearing behavioral claims — that init clears the template demo key, that it reports runtime_mode: "unconfigured", that the SDK does not boot without a key — could not be executed or verified from this checkout; they rest on the PR's reference to campaign-page-kit#28. Whether --api-key "" is treated as present-but-blank or triggers exit 5 is likewise unverifiable here, so the third finding is raised as a documentation gap (the guard and its explanation were both removed, leaving no stated failure behavior) rather than as a demonstrated runtime defect. .claude/rules contains only admin-api-docs.md, graphql-docs.md, and webhooks-docs.md — API-reference authoring guidance with no bearing on campaign CLI docs. The build and npm run check were not executed (read-only mode); consistency was verified by source-text search and by reading scripts/check-agent-surfaces.mjs, scripts/generate-agent-setup.mjs, and content/agent-setup.md directly.

Fix these issues in Kilo Cloud

Previous review (commit 7ec6918)

Status: 3 Issues Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	2
SUGGESTION	1

Issue Details (click to expand)

WARNING

File	Line	Issue
content/docs/campaigns/page-kit.mdx	125	--api-key "${CAMPAIGN_API_KEY:?...}" exposes the key in the process argv, defeating the same paragraph's "do not echo the key" instruction. The :? guard prevents an empty value only; it does nothing about ps//proc visibility. Same on line 134 and index.mdx:303.
content/docs/campaigns/page-kit.mdx	61	The 0.1.4 floor is stated only for campaign-build --json, but the examples this section gates also depend on --non-interactive, --template and --ai-context, whose version availability is never qualified. The two distinct --json flags (campaign-init at line 132 vs campaign-build at line 437) are not disambiguated.

SUGGESTION

File	Line	Issue
content/docs/campaigns/page-kit.mdx	86	The "documented inert-preview protection has been verified" disjunct has no defined pass condition and no artifact to check, so it gates nothing in practice.

Files Reviewed (2 files)

• content/docs/campaigns/index.mdx - 1 issue (raised on the shared root cause at page-kit.mdx:125)
• content/docs/campaigns/page-kit.mdx - 2 issues

Notes on scope

Incremental commits c892f1d..7ec6918 are 2 files / 21 insertions / 9 deletions — Tiny tier, reviewed directly with no sub-agents.

All previously reported findings are resolved. The index.mdx WARNING (4348316434) is addressed by 22179bd: line 39 now links to #installed-version-compatibility, and that section at page-kit.mdx:61 names the 0.1.4 JSON floor, a plain-build fallback, and an explicit "do not upgrade the pin" instruction. The page-kit.mdx SUGGESTION (4348316440) is addressed by the same #### Installed version compatibility heading at line 57, which scopes the blanket executable-source claim. Neither is carried forward.

Anchor and link integrity verified. Both new cross-page links resolve: #installed-version-compatibility matches the #### Installed version compatibility heading at page-kit.mdx:57 (validated against scripts/validate-links.mjs, which slugifies headings with github-slugger), and #build-a-local-preview-before-connecting-commerce matches ## Build a local preview before connecting commerce at content/agent-setup.md:71. The new ](/docs/...) links do not violate the relative-link ban enforced at scripts/check-agent-surfaces.mjs:204, because lib/bundles.ts:19 absolutizes every ](/ occurrence during bundle generation — the same pre-existing pattern used at index.mdx:55 and page-kit.mdx:113.

Drift checks unaffected. scripts/check-agent-surfaces.mjs:144,145 needles (npx --no-install campaign-init --help, npx --no-install campaign-init --non-interactive --json) still match content/agent-setup.md:79,87. The guard at line 155 asserts only that the agent-setup prompt omits --template apollo; this commit introduces --template apollo into index.mdx:300 and page-kit.mdx:122,133, which are in the campaigns llms bundle, not the agent-setup prompt. The two are disjoint, so no check regresses. Repo-wide, zero bare npx campaign-* invocations remain.

Previously carried-forward follow-up is now fixed. The hardcoded --template olympus that contradicted the Apollo recommendation at index.mdx:107 has been replaced with apollo at index.mdx:300 and page-kit.mdx:122,133, each now accompanied by a pointer to the current catalog. The residual olympus strings in content/playground/example/cart-summary.html:8 and scripts/build-preview.mjs are illustrative base-path examples for unrelated preview tooling, not template recommendations, and are outside this diff.

Assumptions / validation gaps: .claude/rules contains only admin-api-docs.md, graphql-docs.md, and webhooks-docs.md — API-reference authoring guidance with no bearing on campaign CLI documentation, so AGENTS.md served as the domain contract. next-campaign-page-kit is absent from node_modules and from package-lock.json, so claims that campaign-build is a bin of that package, that --non-interactive/--template/--ai-context exist, and that --api-key is required for non-interactive runs could not be executed or verified from this checkout; they rest on the pages' own pre-existing flag table at page-kit.mdx:138-152. The campaign-build --json 0.1.4 flo

[Snapshot truncated.]

Additional previous summary content was truncated to keep this comment within platform limits.

---

_{Reviewed by minimax-m3 · Input: 48K · Output: 4K · Cached: 377.8K}