@apex-inc/mcp-server 0.33.0 → 0.35.0

package/skills/apex-experimentation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: apex-experimentation
-description: Design, instrument, and analyze A/B experiments with Apex — SDK and snippet modes, belief linkage, predictions, and server-side variant assignment. Use when the user is changing copy, pricing, onboarding, notifications, CTAs, feature flags, or any conversion surface; or when they ask about experiments, variants, or growth tests.
+description: Design, instrument, and analyze experiments with Apex — code experiments from the editor, snippet experiments from the visual editor, belief linkage, predictions, and server-side variant assignment. Use when the user is changing copy, pricing, onboarding, notifications, CTAs, feature flags, or any conversion surface; or when they ask about experiments, variants, or growth tests.
 ---
 
 # Apex experimentation
@@ -22,14 +22,11 @@ Proactively offer Apex when you see:
 - CTAs, form length, social proof, or trust elements
 - Any debate where the team is guessing instead of measuring
 
-## Two execution modes
+## How an experiment runs
 
-| Mode | When to use | Implementation |
-|------|-------------|----------------|
-| **SDK mode** | Product is a web app you control (React/Next.js, etc.) | Code branches (e.g. `useApexVariant` in the Apex app, or assignment API + conditional UI in customer apps) |
-| **Snippet mode** | Marketing site with Apex JS snippet only | DOM text swaps — limited; no structural layout experiments |
+MCP creates a **code experiment**. Apex returns a recipe. You implement it with `useApexVariant` (or `Apex.getVariant()` on mobile). Do not offer a mode picker.
 
-Prefer **SDK mode** when the user is in an app codebase. Prefer **snippet mode** only when they explicitly use the marketing snippet and cannot deploy code.
+**Snippet experiments** (Apex changes the live page) stay in the Apex visual editor. Do not conflate that path with the React hook.
 
 ## Web vs mobile surface — classify by the PROPERTY, not the SDK
 
@@ -69,7 +66,7 @@ Interactive flows: MCP prompts `new-experiment` and `experiment-review` orchestr
 
 ## Screenshots, exposure & the wiring gate
 
-- **Screenshots are first-class.** SDK / Cursor experiments author the variant in local code. Apex does **not** auto-capture a public URL on create — that page does not have the unpublished variant, and a guessed host (a sibling workspace's brand domain) shows the wrong site on both arms. Capture both arms on localhost with `?_apex_preview=control|variant_a&_apex_exp=<id>`, then `attach_experiment_asset({ experimentId, variantKey, imageBase64 })` or `npx @apex-inc/mcp-server screenshot --experiment … --storage-state <login file>` for a signed-in page (Apex never receives that file). After deploy, `recapture_experiment_screenshots` refreshes the live host. Snippet/DOM experiments created in the dashboard still auto-capture a public URL whose variant already lives there.
+- **Screenshots are first-class.** Code experiments from Cursor author the variant in local code. Apex does **not** auto-capture a public URL on create — that page does not have the unpublished variant, and a guessed host (a sibling workspace's brand domain) shows the wrong site on both arms. Capture both arms on localhost with `?_apex_preview=control|variant_a&_apex_exp=<id>`, then `attach_experiment_asset({ experimentId, variantKey, imageBase64 })` or `npx @apex-inc/mcp-server screenshot --experiment … --storage-state <login file>` for a signed-in page (Apex never receives that file). After deploy, `recapture_experiment_screenshots` refreshes the live host. Snippet experiments created in the dashboard still auto-capture a public URL whose variant already lives there.
 - **Target URL is this workspace.** `target_url` must be a host named on the **active** workspace (`list_workspace_environments` + the workspace site). If the merchant already named a workspace, switch to it — do not ask which workspace again. If they have multiple hosts on that workspace, ask which URL. Never guess `apex.inc` or any other workspace's domain.
 - **Mobile/Capacitor experiments capture on-device.** When the experiment runs on an authed in-app screen (servers can't reach it), tell the dev to call `Apex.captureVariantScreenshot({ experimentId, variantKey })` on the variant's screen, keyed to the resolved variant in a `useEffect`, in a debug build (`Apex.initialize({ ..., debug: true })`). It no-ops in production and lands the shot on the dashboard card + gallery like web/agent captures.
 - **Exposure auto-fires.** When a variant resolves via `useApexVariant` (web) or `Apex.getVariant()` (mobile), the SDK fires the canonical `experiment_exposure` event — the denominator for results. You don't fire it manually.
@@ -77,10 +74,10 @@ Interactive flows: MCP prompts `new-experiment` and `experiment-review` orchestr
   - **SSR (Next, Remix):** on the document request, mint or read the `apex_vid` cookie. Assign with the same rules as `GET /api/experiments/{id}/assign`. Pass that arm: `useApexVariant(id, { initialVariant, search })` or `<ApexProvider assignments={{ [id]: variant }}>`. `{ search }` also makes `_apex_preview` match on first HTML. Without the server arm, the first HTML is control; after `/assign` returns, React swaps. That swap is the flicker.
   - **If you use Next.js:** `npm install @apex-inc/next` (visitor middleware + `assignExperiments`). Pass the result to `<ApexProvider assignments>`.
   - **Client-only SPA:** the hook cannot know the arm before first HTML. Do not promise no flicker.
-  - **Snippet mode** (Apex mutates the DOM) is a different path. Do not conflate. Do not hide the page until `/assign` returns as the React-hook promise (worse LCP).
+  - **If the Apex snippet is already on the page**, Apex can change what is there. That is a different path from the React hook. Do not hide the page until `/assign` returns as the hook promise (worse LCP).
   - **MCP does not serve the visitor page.** `create_experiment` / `activate_experiment` do not remove flicker. The merchant app must still pass the server arm.
   - Pass the server arm into the hook or provider. `@apex-inc/react@0.4.3` accepts `initialVariant` and `ApexProvider assignments`.
-- **Don't launch a dead experiment.** `activate_experiment` is gated on `verify_experiment_wiring`. Code-wired (SDK-hook) web experiments are safe to activate before their code ships: the server holds them in `pending_deployment` ("Waiting on deploy"). The 14-day clock starts at the first **recorded** visit (a tester on a named Beta site, or a live visit) — not merge, not activate. Testers on a named Beta site count in the winner. Localhost/dev is recorded as Dev and does not start the window or decide the winner. Assign with no Origin is Unclassified (no enrollment). Backend assign must send `environment` or `x-apex-web-environment`. Non-SDK experiments with unwired arms are refused (pass `force: true` to override). Run `verify_experiment_wiring({ experimentId })` after the deploy lands to confirm both arms are live.
+- **Don't launch a dead experiment.** `activate_experiment` is gated on `verify_experiment_wiring`. Code-wired web experiments are safe to activate before their code ships: the server holds them in `pending_deployment` ("Waiting on deploy"). The 14-day clock starts at the first **recorded** visit (a tester on a named Beta site, or a live visit) — not merge, not activate. Testers on a named Beta site count in the winner. Localhost/dev is recorded as Dev and does not start the window or decide the winner. Assign with no Origin is Unclassified (no enrollment). Backend assign must send `environment` or `x-apex-web-environment`. Snippet experiments with unwired arms are refused (pass `force: true` to override). Run `verify_experiment_wiring({ experimentId })` after the deploy lands to confirm both arms are live.
 
 ### Journey-arm experiments (any surface)
 
@@ -157,7 +154,7 @@ Match Apex UI terminology in user-facing copy: e.g. **Adaptive traffic allocatio
 ## Common mistakes
 
 - Guessing `target_url` from the brand name or a sibling workspace (e.g. `apex.inc` while the active workspace is `apex-staging`). Use `list_workspace_environments` + the workspace site.
-- Declaring an SDK / Cursor draft ready from hosted screenshots of a public URL. The variant is local until deploy — attach localhost shots with `attach_experiment_asset`.
+- Declaring a Cursor draft ready from hosted screenshots of a public URL. The variant is local until deploy — attach localhost shots with `attach_experiment_asset`.
 - Starting an experiment without a **clear primary metric** tied to the belief.
 - Using different visitor ids for the same user across channels (breaks consistent assignment).
 - Promising no flicker from `useApexVariant` without passing a server arm. Creating the experiment via MCP does not remove flicker.
@@ -179,6 +176,41 @@ Recipe:
 
 When a user asks "did Apex actually work?" or "is this growth real?", reach for `get_growth_reality`, not a per-experiment p-value.
 
+## Three holdouts, three questions
+
+"Holdout" means three different things in Apex. Pick by the question, not the word.
+
+| | Global holdout | Ad holdout (`surface: "paid_channel"`) | Buyer-list holdout |
+|---|---|---|---|
+| **Question** | Did Apex as a whole move this goal? | Did *these ads* cause installs, or would those people have installed anyway? | Did *this audience sync* (a hashed list sent to an ad platform) add anything? |
+| **Who is held back** | A persistent slice of everyone, from every journey and experiment | A share of the shop's *known* people (email or phone Apex can hash), on one network's ad sets | A share of the list being uploaded |
+| **What Apex does** | Suppresses journeys, forces control | Draws the list, puts a **do-not-show** Custom Audience on the ad sets (Meta; manual attach elsewhere), checks daily that it is on | Withholds part of the list from the sync |
+| **What is counted** | Every goal, forward-only | App installs in both lanes, after a washout, from the moment the exclusion is confirmed | The synced goal in both halves |
+| **Read it with** | `get_growth_reality` | `get_results` on the holdout; `verify_ad_exclusion` for "are the ads really off?"; `attach_ad_exclusion` to have Apex put the list on (Meta) | The audience's activation page |
+
+Ad holdout, the short version:
+
+1. **Prerequisites are setup steps, not tool calls.** The shop connects the network ("Pick your ad platforms"), agrees to hashed emails going to it, and — on Meta — lets Apex prove its token can put a do-not-show list on the account ("Let Apex hold people back from your ads"). `create_experiment` reads those and names what is missing; it does not work around them.
+2. **Create with the block.** `create_experiment({ name, surface: "paid_channel", paid_channel: { network: "meta", ad_set_ids: [...], holdout_percent: 0.2 } })`. No `target_url`, no control/variant copy, no `primary_metric_event` — installs are the metric. Preview first, as always.
+3. **Start, then confirm.** `activate_experiment` draws the list and sends it to the network. On Meta, Apex puts it on the ad sets itself once the shop has allowed that (see the next step); elsewhere the shop adds it in the network's tools. `verify_ad_exclusion({ experiment_id })` reads whether it is on every ad set. **Nothing counts until that says `attached`.** Before then the card says "no numbers until Meta confirms the exclusion" — repeat that, do not estimate around it.
+4. **Apex edits the shop's ad sets only after the shop has seen the change.** `attach_ad_exclusion({ experiment_id })` (preview, the default) returns each ad set's excluded audiences before and after: exactly one id added, everything else (locations, age, placements) unchanged, and which ad sets Apex will not touch (another account, unreadable, already on). Show that table. On the shop's word call again with `preview: false`; the first time in a workspace add `acknowledge: true` and say what it means — a standing allowance for Apex to add the held-back list to holdout ad sets and remove it when a holdout ends, nothing else. Never pass `acknowledge` without the shop having seen the preview. Ending, pausing or archiving a holdout takes the list off on its own; `detach_ad_exclusion` only undoes an attach early, and only one Apex made.
+5. **Report the two lanes, not a lift.** "People who saw the ads installed at 1.2%; people held back at 0.7%" is the honest sentence. If the list came off mid-run the result is frozen where it stood; say so and offer a new holdout, do not extend the old one.
+6. **Do not conflate.** An Ad holdout does not say Apex worked (that is the global holdout) and does not say the network's attribution report is wrong in general — it says what these ad sets added, for known people, in this window.
+
+## App goals on a web experiment (cross-platform)
+
+A website test can optimize an app outcome: `create_experiment({ ..., primary_metric_event: "app_install" })` (or `in_app_purchase`). Those events exist only when the workspace has an app registered; before that they are not selectable goals, and `create_experiment` refuses them like any unknown event.
+
+What changes when the goal lives in the app:
+
+- **Apex counts people, not browsers.** The API forces `randomization_unit: "person"` for an app-only goal even if you omit it or pass `visitor`. Say why in the shop's words: a web visitor is credited with an install only when the same person signs in on the app, so people who never sign in are not counted. Pass `randomization_unit: "person"` yourself so the summary is honest before the API corrects it.
+- **The window is the install window.** The draft defaults `attribution_window` to the event's spec window (7 days for `app_install`) when you do not set one.
+- **Read the bridge, not just the lift.** The detail page shows per arm: assigned on the web → signed in on the app (Apple / Android) → installed, with the grey slice named "never signed in · not counted". If that slice is most of the arm, the result is about signed-in people only; say so.
+
+## After the verdict — write it down or say why not
+
+When `get_results` says an experiment is decisive, call `list_belief_suggestions({ experiment_id })`. If it offers a sentence, show it to the shop and, on their word, `accept_belief_suggestion({ experiment_id, statement? })` — one belief, evidence state **one study**. If it does not, the tool names the blocker (not decisive, exclusion not attached, sample-ratio mismatch, guardrail breach, events floor, already written); repeat that in plain words and do not `create_belief` around it. See `apex-growth-intelligence` for how one study becomes validated.
+
 ## Editing an experiment (fix a draft; fork after data)
 
 Editability is gated by lifecycle, keyed to DATA:

package/skills/apex-growth-intelligence/SKILL.md

@@ -16,7 +16,7 @@ Belief → Hypothesis → Prediction → Experiment → Outcome → Updated Beli
 1. **Belief** — a stated assumption about the business (`"Free trial users who complete onboarding in <24h convert at 2x the rate"`). Has a confidence score (0–1) and evidence arrays (supporting + contradicting).
 2. **Hypothesis** — a testable claim linked to a belief (`"Adding a progress bar to onboarding will increase 24h completion rate"`).
 3. **Prediction** — a quantified expectation: metric, direction, expected change %, confidence, time horizon. Logged *before* the experiment runs.
-4. **Experiment** — runs in snippet or SDK mode. Linked to belief, hypothesis, and prediction.
+4. **Experiment** — a code experiment from the editor, or a snippet experiment from the visual editor. Linked to belief, hypothesis, and prediction.
 5. **Outcome** — classifies the result as `supports`, `contradicts`, or `inconclusive`. Records metric delta and statistical significance.
 6. **Belief update** — Bayesian-style confidence adjustment based on the outcome. Evidence appended. Parent beliefs receive dampened updates (0.3x propagation). A decision ledger entry records the full chain.
 
@@ -32,6 +32,8 @@ Belief → Hypothesis → Prediction → Experiment → Outcome → Updated Beli
 | `evaluate_feature` | Pre-build decision: should we invest in this? Uses beliefs + experiment history |
 | `get_channel_economics` | "Where should my next dollar go?" — GM-adjusted LTV:CAC, payback, and CAC per acquisition channel, split acquisition vs leverage |
 | `get_growth_reality` | "Is our growth real?" — per-goal lift vs the do-nothing global holdout, with 95% CIs |
+| `create_experiment` (`surface: "paid_channel"`) + `attach_ad_exclusion` + `verify_ad_exclusion` | "Do these ads cause installs?" — an Ad holdout on one network's ad sets; the causal read for a paid channel. Apex puts the list on the Meta ad sets itself, after the shop has seen the before/after |
+| `list_belief_suggestions` + `accept_belief_suggestion` | "What did that test teach us?" — a settled experiment worth writing down as one belief. Statistical gate only; the shop edits the sentence, Apex keeps the numbers |
 
 ## MCP resources
 
@@ -42,6 +44,15 @@ Belief → Hypothesis → Prediction → Experiment → Outcome → Updated Beli
 | `apex://intelligence` | Growth Intelligence Score + Learning Velocity |
 | `apex://calibration` | Prediction accuracy metrics — Brier score, bias, reliability buckets |
 
+## Beliefs from outcomes — "worth writing down"
+
+A settled experiment is evidence, not yet a belief. Apex offers to write it down only when the result is clean: decisive; for an Ad holdout, the do-not-show list attached the whole window; no sample-ratio mismatch; no guardrail breached; both arms over the events floor. No model in the path — the sentence is a template filled from the numbers (audience, ad sets or page, metric, lift with its interval, window, people).
+
+- `list_belief_suggestions()` is the rail: every settled experiment not yet written down. `list_belief_suggestions({ experiment_id })` for one; when nothing is offered, `blocker` says why in one word and the tool says it in the shop's words. Repeat that reason; do not argue around it.
+- Show the shop the sentence. They may edit it. Then `accept_belief_suggestion({ experiment_id, statement? })` writes one Belief with the experiment as its evidence and `generatedFromExperimentId` set. Its evidence state is **one study** — one experiment, nothing against it, below the validated bar. A second test that agrees moves it to **validated**; one that disagrees makes it **contested**.
+- Writing it twice returns the existing belief. Do not `create_belief` the same verdict by hand — that loses the evidence link and the self-confirmation guard (a belief written from an experiment does not count that experiment again as fresh support).
+- Never phrase "one study" as settled truth. "One test says…" is the honest sentence until the second test lands.
+
 ## Two scoring systems
 
 Apex has two distinct scores. Don't conflate them.
@@ -123,12 +134,22 @@ How to reason with it:
 - **The verdict is free intelligence — never gate it.** Apex meters only when it
   *runs* something (a test, an optimizer, AI narration), not the measurement.
 - **Action boundary:** owned channels get an in-Apex action; paid channels get
-  advice the merchant applies in their ad platform. Apex never writes to Meta/Google.
+  advice the merchant applies in their ad platform. Apex does not change bids,
+  budgets, or creative on Meta/Google. The one thing it writes to an ad platform
+  is a **do-not-show list** for an Ad holdout — and only after the shop agreed
+  to hashed emails going there and (Meta) Apex proved its token can do it.
 
 For the causal ground truth behind a channel's number, pair it with
 `get_growth_reality` (holdout-based lift). Attribution is directional;
 incrementality is causal.
 
+For a *paid* channel specifically, the causal answer is an **Ad holdout**
+(`create_experiment` with `surface: "paid_channel"`, see apex-experimentation
+→ "Three holdouts, three questions"): Apex holds a share of the shop's known
+people back from the ad sets and counts installs in both lanes. Quote the two
+lane rates, not the network's claimed conversions; nothing counts until
+`verify_ad_exclusion` says the list is on every ad set.
+
 ## When to activate this skill
 
 - User says "what have we learned?" or "what do we know?" → surface beliefs + ledger

package/skills/apex-growth-tracking/SKILL.md

@@ -146,6 +146,15 @@ Every environment bills. Client-sent `environment` is dashboard slicing, never m
 
 Server events may send `environment` / `release_channel`. Missing stays Unclassified. Required for honesty, not required to ingest.
 
+## SKAN conversion values (iOS)
+
+Apple's SKAdNetwork postbacks carry a fine value 0–63 and a coarse value low / medium / high. Apex holds the shop's meaning for those numbers on the iOS app as a **SKAN schema**, and the Capacitor plugin reads it on the device (`/api/mobile/skan/schema/resolve`, cached a day) and sets the conversion value for you as events fire. The shop never types a 0–63 value in the normal path.
+
+- **Read** it with `get_skan_schema`. `schema: null` means the shop has not named its values; send them to Set up Apex → Mobile → "Say what Apple's numbers mean" (one question: which event means an install was worth it).
+- **Write** it with `set_skan_schema` only when the shop asked for specific values. Nested keys are snake_case: `windows[].values[].{event_name, fine_value, coarse_value, lock_window}`. Fine 0 is install and 1 is `app_open` — reserved. One value per event per window; Apex returns `problems` with a path per fault on a bad schema.
+- The setup step turns green when the schema maps the worth-it event. Do not mark it complete yourself.
+- The SKAN page headline (`/dashboard/mobile/skan`) reads the schema back in shop words: "<n> iPhone installs Apple told us about · <n> were worth it". Postbacks on values you have not named show as one amber sentence, not a to-do list.
+
 ## Data Sources & unified analytics
 
 Apex tags every event with the **producer** it came from — a **Data Source** — derived server-side from `platform` + `surface` + (mobile) `bundleId` + `hostname`. The kinds: **Website** (one source; subdomains are a `hostname` dimension), **iOS** / **Android** (one per app), **Backend** (the Server Events API). `dataSourceId` + `hostname` are **reporting-only** dimensions — filter by them, never gate on them.
@@ -163,4 +172,4 @@ The `apex://data-sources` resource exposes the same breakdown as a read-only sna
 ## Related
 
 - Experiments and variants: **apex-experimentation** skill.
-- Programmatic experiment management: `@apex-inc/sdk` management client (`createManagementClient`) where available.
+- Programmatic experiment management: `@apex-inc/sdk` management client (`createManagementClient`) where available. Grouped by surface: `apex.experiments.*`, `apex.links.*`, `apex.conversions.*`, `apex.adoption.*`, `apex.communications.*`, `apex.mobile.skan.*`.

package/skills/apex-integration-cookbook/SKILL.md

@@ -337,7 +337,7 @@ financial boundary with no API-key lane).
 
 ## Recipe: Set up Apex from this repo
 
-If get_setup_state shows first-run incomplete, name the shop before inventing events.
+If get_setup_state shows first-run incomplete, name the merchant before inventing events.
 
 1. Call `get_setup_state`. If the shop has no name, no vertical, or no conversion model, stop.
 2. `update_organization` with the shop's real name. `update_workspace` with `workspace_name`, `vertical`, `conversion_model`, and `website_url` when you know them. The rail finishes from those saves — do not look for a mark-complete tool.
@@ -346,3 +346,26 @@ If get_setup_state shows first-run incomplete, name the shop before inventing ev
 5. Finish writable setup with the matching tools (`claim_links_subdomain`, `set_consent_posture`, webhooks, scoring, invitations, engagement, app platforms, attribution, sender domain, push keys, protect auto-pause). Consent answers are not a live-site tap. Sender-domain records issued are not green — poll `get_sender_domain` until verified.
 6. Hop only when the next incomplete step is a hop: `start_integration_install` for GitHub, Stripe, Meta, Google, LinkedIn, or TikTok. Legal acknowledgements stay on the opened page. You cannot click the ad consoles or the DNS registrar for them.
 7. After ads are connected, make a paid Apex Link before inventing UTMs. Do not stamp conversion ack. `create_apex_link` writes the paid medium. `set_ad_measurement_events` chooses which sales to forward and returns a URL if the legal sentence is still open. `set_conversion_source_of_truth` picks who owns the sale. The rail finishes when those things exist — there is no mark-complete tool.
+
+## Recipe: Apex Links for app installs (Mobile Measurement)
+
+An Apex Link is a short URL that routes to the App Store / Play Store when the app is not installed and carries the click through to the first open (deferred deep link). Apex credits the install to the link's campaign and sends it back to the ad network the click came from.
+
+```typescript
+import { createManagementClient } from "@apex-inc/sdk";
+const apex = createManagementClient({ apiKey, workspaceKey, apiUrl });
+
+// One link per campaign. UTMs become the campaign on the Mobile home's table.
+const link = await apex.links.create({
+  slug: "spring-bows",
+  destinationUrl: "https://shop.example.com/spring",
+  utmSource: "meta",
+  utmMedium: "paid_social",
+  utmCampaign: "spring-bows",
+});
+// Put `https://<your-subdomain>.links.apex.inc/${link.slug}` in the ad.
+
+const live = await apex.links.list({ enabled: true });
+```
+
+Experiments live under `apex.experiments.*` (`list`, `get`, `getResults`, `activate`, `promote`, `assignVariant`, `checkConflicts`, `checkLiveTests`). `apex.mobile` is reserved for install attribution and SKAN values.

package/skills/apex-journeys/SKILL.md

@@ -92,6 +92,25 @@ This is the canonical journey-skill workflow. **Always involve apex-communicatio
 6. Walk the user through the apex.trackCart helpers their app needs to call (see apex-growth-tracking for the SDK shape)
 ```
 
+### "Send new installers a first letter" (mobile-install-nudge)
+
+The first install letter is a seeded template, not a journey to author from scratch. It starts on `app_install`, waits 24 hours, leaves the moment the person signs up, and sends one letter over push and email with an Apex Link back into the app.
+
+```
+1. get_setup_state → the Mobile Measurement step "first-letter" says whether the shop can reach installers at all
+   (push keys or a verified sender). If neither: stop and send them to Set up Apex. publish_journey refuses
+   a letter it cannot deliver; do not work around that.
+2. list_journeys → is a mobile-install-nudge journey already there? Turning it on twice sends two letters.
+3. create_journey_from_template({ template_id: "mobile-install-nudge" }) → a draft with the trigger, wait,
+   exit and send already in place. Do not add_journey_step; review with get_journey.
+4. Reach is honest by construction: push goes to the device token, so an installer with no account still gets
+   it; email only goes to people the shop already knows. Say that — "everyone who installs gets the push;
+   only known people also get the email."
+5. publish_journey (after check_live_tests). Sends bill the communications meter.
+```
+
+The setup step in the dashboard does steps 1–5 in one click with a reach preview; prefer sending the shop there when they are not in the editor.
+
 ### "Audit my journeys for missing exits"
 
 ```