@apex-inc/mcp-server 0.3.1 → 0.6.1

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

@@ -1,53 +1,31 @@
 ---
 name: apex-integration-cookbook
-description: Recipes for integrating Apex into products — snippet installation, SDK wiring, form tracking, auth/signup events, Stripe lifecycle, communication triggers, connectors, and actuators. Use when the user is adding Apex to their product, connecting a data source, or wiring events to communications or experiments.
+description: Recipes for integrating Apex into products — SDK wiring, form tracking, auth/signup events, Stripe lifecycle, communication triggers, and event naming conventions. Use when the user is adding Apex tracking to their product or wiring events to communications and experiments.
 ---
 
-# Apex integration cookbook
+# Apex integration cookbook (SDK)
 
-Step-by-step recipes for common Apex integration patterns. Each recipe shows what to instrument, which surface to use (snippet, SDK, or API), and what Apex does with the data.
+Step-by-step recipes for integrating Apex via the `@apex-inc/sdk` package. For snippet-only sites or MCP-driven setup, see the full cookbook in `@apex-inc/mcp-server`.
 
-## Surfaces overview
+## SDK setup
 
-| Surface | Best for | Install |
-|---------|----------|---------|
-| **Snippet** (`/api/apex-js`) | Marketing sites, landing pages, lightweight tracking | `<script src="https://your-apex/api/apex-js?key=PROJECT_KEY"></script>` |
-| **SDK** (`@apex-inc/sdk`) | Apps and backends — richer tracking, identity, management | `npm install @apex-inc/sdk` then `init({ projectKey })` |
-| **MCP** (`@apex-inc/mcp-server`) | AI-assisted setup — create experiments, communications, track events from the editor | One-click install from Apex dashboard |
-| **API** (direct HTTP) | Webhooks, server-side events, custom integrations | `POST /api/events` with `x-api-key` header |
-
-## Recipe 1: Marketing site (snippet only)
-
-**Goal:** Track visits, form submissions, and run copy experiments on a marketing site.
-
-```html
-<script src="https://your-apex-url/api/apex-js?key=YOUR_PROJECT_KEY" defer></script>
-```
-
-What you get automatically:
-- `pageview` events with URL, referrer, UTM params
-- `heartbeat` events (engagement time)
-- Visitor identity via `apex_vid` cookie
-- Attribution from UTM parameters and click IDs (gclid, fbclid, etc.)
-
-Add form tracking:
-```javascript
-apex.track("form_submit", {
-  formId: "signup-form",
-  email: formData.email
+```typescript
+import { init, track, identify, trackForm, shutdown } from "@apex-inc/sdk";
+
+init({
+  projectKey: "YOUR_PROJECT_KEY",
+  apiUrl: "https://your-apex-url",  // optional, defaults to relative /api
+  flushInterval: 10000,              // ms between batch sends (default: 10s)
+  flushAt: 20,                       // batch size trigger (default: 20)
+  debug: false                       // log events to console
 });
-apex.identify(formData.email, { source: "form", formId: "signup-form" });
 ```
 
-## Recipe 2: App signup and authentication
+Events are batched and sent to `POST /api/events` automatically. Call `flush()` before page unload if needed, or `shutdown()` to stop tracking.
 
-**Goal:** Track signup, login, and connect anonymous browsing to known users.
+## Recipe 1: Signup and authentication
 
 ```typescript
-import { init, track, identify } from "@apex-inc/sdk";
-
-init({ projectKey: "YOUR_PROJECT_KEY" });
-
 // On signup
 track("signup_completed", { method: "email", plan: "free" });
 identify(user.id, {
@@ -61,154 +39,202 @@ track("login", { method: "google" });
 identify(user.id, { email: user.email });
 ```
 
-The `visitorId` trait is critical — it links the anonymous marketing session to the authenticated user. Without it, Apex creates a disconnected identity.
+The `visitorId` trait links the anonymous marketing session to the authenticated user. Without it, pre-signup attribution is lost.
 
-## Recipe 3: Onboarding funnel
-
-**Goal:** Track onboarding steps to measure activation and trigger communications.
+## Recipe 2: Onboarding funnel
 
 ```typescript
-// Each onboarding step
 track("onboarding_step_completed", { step: "connect_data_source", stepNumber: 2, totalSteps: 5 });
-
-// Onboarding complete — this triggers activation communications
 track("onboarding_completed", { timeToComplete: elapsedMs });
 ```
 
-Events like `onboarding_completed` automatically match to communications in the Apex catalog when tenant communications are active. The communication trigger system matches `triggerEventId` on active `TenantCommunication` records.
+Events like `onboarding_completed` automatically match to active tenant communications when the trigger system is wired.
 
-## Recipe 4: Stripe subscription lifecycle
+## Recipe 3: Stripe subscription lifecycle
+
+```typescript
+// In your Stripe webhook handler
+track("subscription_created", { plan: "pro", amount: 9900, currency: "usd" });
+identify(userId, { plan: "pro", lifecycleStage: "paying" });
 
-**Goal:** Track revenue events from Stripe webhooks.
+// On cancellation
+track("subscription_cancelled", { reason: "too_expensive" });
+identify(userId, { lifecycleStage: "churned" });
+```
 
-Set up the Stripe connector via the dashboard (Settings → Connectors → Stripe), or handle webhooks directly:
+## Recipe 4: Feature usage
 
 ```typescript
-// In your Stripe webhook handler
-switch (event.type) {
-  case "checkout.session.completed":
-    track("subscription_created", {
-      plan: session.metadata.plan,
-      amount: session.amount_total,
-      currency: session.currency
-    });
-    identify(session.client_reference_id, {
-      email: session.customer_email,
-      plan: session.metadata.plan,
-      lifecycleStage: "paying"
-    });
-    break;
-
-  case "invoice.paid":
-    track("invoice_paid", {
-      amount: invoice.amount_paid,
-      plan: invoice.lines.data[0]?.price?.lookup_key
-    });
-    break;
-
-  case "customer.subscription.deleted":
-    track("subscription_cancelled", { reason: subscription.cancellation_details?.reason });
-    identify(customerId, { lifecycleStage: "churned" });
-    break;
-}
+track("feature_used", { feature: "export_report", format: "csv" });
+track("milestone_reached", { milestone: "first_experiment_completed" });
 ```
 
-## Recipe 5: Feature usage tracking
+Use one event name with a `feature` property — not dozens of unique event names.
 
-**Goal:** Measure which features drive retention and activation.
+## Recipe 5: Form tracking (shortcut)
 
 ```typescript
-// Track meaningful feature interactions, not every click
-track("feature_used", { feature: "export_report", format: "csv" });
-track("feature_used", { feature: "invite_teammate" });
-track("feature_used", { feature: "create_experiment" });
+trackForm({
+  email: formData.email,
+  formId: "contact-form",
+  action: "demo_request",
+  fields: { company: formData.company, role: formData.role }
+});
+```
 
-// Track milestone completions
-track("milestone_reached", { milestone: "first_experiment_completed" });
-track("milestone_reached", { milestone: "10_contacts_scored" });
+`trackForm` fires `form_submit` + `identify` in one call.
+
+## Recipe 6: Server-side events (Server Events API)
+
+For backend events (webhooks, cron jobs, CRM milestones), use the **Server Events API**: `sendServerEvent` / `sendServerEvents` from `@apex-inc/sdk`. This is the canonical replacement for raw `fetch()` calls to `/api/events`.
+
+```typescript
+import { sendServerEvent, newIdempotencyKey } from "@apex-inc/sdk";
+
+// Stripe webhook example
+await sendServerEvent(
+  { apiKey: process.env.APEX_API_KEY! }, // apex_sk_…
+  {
+    type: "purchase_completed",
+    email: customer.email,
+    visitorId: cookieJar.get("apex_vid"), // optional but improves stitching
+    data: { value: invoice.amount_paid / 100, currency: "USD", order_id: invoice.id },
+  },
+  { idempotencyKey: stripeEvent.id }, // dedupe on retry
+);
 ```
 
-Prefer one event name (`feature_used`) with a `feature` property over dozens of unique event names. This keeps the event taxonomy clean and makes analysis easier.
+Why prefer the Server Events API over `fetch("/api/events")`:
+
+- **Idempotency-key** — retries don't double-count.
+- **clientType: "server"** — the Conversion Loop dashboard classifies events correctly.
+- **Single endpoint** — `/api/v1/events` is the documented, OpenAPI'd integration surface.
+- **Typed errors** — the wrapper throws on non-2xx with a clear `error.code` from the API.
+
+For batches > 1 event, use `sendServerEvents(config, events, { idempotencyKey })` (max 100 per call).
+
+For agent-driven testing through MCP, use the **`send_server_event`** tool — same endpoint, exposed as a single-call MCP tool with the idempotency key generated for you.
+
+## Event naming conventions
+
+- **snake_case**: `signup_completed`, `feature_used`, `invoice_paid`
+- Context in **properties**: `track("button_clicked", { surface: "pricing", label: "start_trial" })`
+- For experiments, include `experimentId` and `variant` in properties
+- One primary metric per experiment; secondary metrics as properties
+
+## Identity stitching checklist
 
-## Recipe 6: Communication triggers
+1. Call `identify(userId, { email, visitorId })` when the user becomes known
+2. `visitorId` = value of the browser `apex_vid` cookie
+3. Server-side: pass `traits.visitorId` to link to the browser session
+4. Without stitching, pre-signup attribution is lost
 
-**Goal:** Wire custom events to lifecycle communications.
+## Partner Network patterns
 
-Communications trigger automatically when:
-1. A `TenantCommunication` exists with `status: "active"` and a `triggerEventId`
-2. An event matching that `triggerEventId` arrives via `apex.track()`
-3. Multi-channel dispatch sends via the user's preferred channels (email, push, in-app)
+### Credit a partner for a self-serve signup
 
-Common trigger events from the Apex event taxonomy:
+When a visitor arrives from an affiliate link (`?utm_source=affiliate&utm_campaign=<handle>`) and signs up on your site, the Apex snippet automatically stitches the referral to the resulting Contact. The conversion auto-credits on the next purchase event (MMP-096 wiring).
 
-| Event | Communication |
-|-------|--------------|
-| `signup_completed` | Welcome email |
-| `onboarding_completed` | Activation congratulations |
-| `feature_used` (first time) | Feature discovery nudge |
-| `subscription_created` | Payment confirmation |
-| `trial_expiring` | Upgrade prompt |
-| `user_inactive_7d` | Re-engagement email |
+No SDK calls needed for basic attribution. Use `list_partner_program_members(programId)` to see who's actually earning.
 
-Use the MCP tool `get_event_taxonomy` or `GET /api/communications/events?vertical=b2b-saas` to see the full recommended event list for your vertical.
+### Run a manual-approval program + vet applicants in a script
 
-## Recipe 7: Outbound webhooks (actuators)
+```typescript
+import { createManagementClient } from "@apex-inc/sdk/management";
+const apex = createManagementClient({ projectKey, apiKey });
+
+// Create the program
+const program = await apex.createProgram({
+  name: "Vetted Partners",
+  vertical: "saas",
+  commissionStructure: { type: "revshare", percentage: 25, appliesTo: "subscription" },
+  visibility: "public",
+  approvalMode: "manual", // every applicant needs review
+});
 
-**Goal:** Push Apex events to external systems (Slack, CRMs, custom endpoints).
+// ...applicants land in /admin/partners/applications for human review.
+// The SDK doesn't wrap the approval flow — that's an admin-auth path.
+// But merchants can monitor who's joined:
+const members = await apex.listProgramMembers(program.id);
+```
 
-Configure actuators in the dashboard (Settings → Actuators) or via API. Apex sends signed payloads:
+### Batch-approve the weekly payout queue
 
-```json
-{
-  "type": "experiment.completed",
-  "payload": { "experimentId": "...", "winner": "variant_b", "confidence": 0.95 },
-  "timestamp": "2026-04-15T..."
-}
+```typescript
+const queue = await apex.listPendingPayouts();
+const olderThanThirtyDays = queue.buckets["30_60"].concat(queue.buckets["60_plus"]);
+const result = await apex.approvePayouts(olderThanThirtyDays.map(c => c.id));
+console.log(`Approved ${result.approved.length}, skipped ${result.skipped.length}`);
 ```
 
-Verify with `X-Apex-Signature` header (HMAC-SHA256 of the body with your webhook secret).
+**Approving does not fire Stripe transfers.** The next `run-payouts` cron cycle (per your `autoPayoutPolicy`) batches + fires. Design reason: reserve holdback window (90 days for NEW partners) has to elapse before transfer.
+
+### Give an enterprise partner a custom rate
 
-Available trigger events: `experiment.completed`, `experiment.started`, `model.drift`, `sensor.sync_complete`, `sensor.sync_failed`, `budget.threshold`, and more.
+```typescript
+await apex.updateMembershipRate("prof_acme", {
+  commissionStructure: { type: "revshare", percentage: 35, appliesTo: "subscription" },
+  reason: "Enterprise negotiation - Q4 contract",
+});
+```
 
-## Recipe 8: Server-side event ingestion
+Overrides are sticky. Updating the program default later won't overwrite this partner's rate (only `applyProgramDefaultToMembers` can mass-update, and it respects sticky overrides).
 
-**Goal:** Send events from a backend without the browser SDK.
+### Disclose fees accurately in your UI
 
-```bash
-curl -X POST https://your-apex-url/api/events \
-  -H "Content-Type: application/json" \
-  -H "x-api-key: YOUR_API_KEY" \
-  -H "x-apex-project: YOUR_PROJECT_KEY" \
-  -d '{
-    "projectKey": "YOUR_PROJECT_KEY",
-    "userId": "user_123",
-    "events": [{
-      "type": "track",
-      "payload": { "event": "invoice_paid", "amount": 9900, "currency": "usd" },
-      "timestamp": "2026-04-15T12:00:00Z"
-    }]
-  }'
+```typescript
+const { fees } = await apex.getEffectiveFees();
+// Show merchants what they're charged per fee kind.
+// source: "merchant_override" means they have a custom (enterprise) rate.
 ```
 
-## Event naming conventions
+## Recipe — Mobile build sources (TestFlight vs App Store)
 
-- **snake_case** or **dot-separated**: `signup_completed`, `feature_used`, `invoice.paid`
-- Context in **properties**, not event names: `track("button_clicked", { surface: "pricing", label: "start_trial" })` — not `pricing_start_trial_clicked`
-- For experiments, include `experimentId` and `variant` in properties when the event is relevant to exposure
-- One primary metric per experiment; secondary metrics as properties
+Apex auto-detects which build a mobile event came from and routes accordingly. Use the same `projectKey` everywhere — there's no separate sandbox key to provision.
 
-## Identity stitching checklist
+### Detection (no SDK code required)
+
+iOS uses StoreKit 2's `appStoreReceiptURL` to distinguish `app-store`, `testflight`, and `xcode-debug`. Android uses `PackageManager.getInstallSourceInfo()` (API 30+) to distinguish `play-production`, `play-internal`, and `sideloaded`, with `BuildConfig.DEBUG` overriding to `xcode-debug` for local builds.
+
+```typescript
+import { Apex } from "@apex-inc/capacitor-plugin";
+
+await Apex.initialize({ projectKey: "wsk_..." });
+// That's it. The next event includes `releaseChannel` + `releaseChannelSource`.
+```
+
+### Override for Android closed-test tracks
+
+iOS overrides are ignored (the receipt always wins). On Android, `getInstallerPackageName()` can't distinguish Play production from closed-test tracks, so you can supply a hint at init time:
+
+```typescript
+import { Apex } from "@apex-inc/capacitor-plugin";
+import { ApexChannel } from "./build-config"; // BuildConfig.APEX_CHANNEL
+
+await Apex.initialize({
+  projectKey: "wsk_...",
+  releaseChannel: ApexChannel, // "play-internal" for closed-test variant
+});
+```
+
+Use Gradle `buildConfigField` to inject the channel per build variant so the value is wired at compile time, not runtime.
+
+### Billing implications
+
+- **Dev** (Xcode-debug, Gradle-debug, sideloaded): always **free**.
+- **Beta** (TestFlight, Play internal/closed): always **free**.
+- **Production** (App Store, Play production): **billable**.
+- **Unknown** (older SDK without detection): billable, but the dashboard surfaces a fix-it nudge with an SDK upgrade prompt.
+
+No retroactive credits — if you misclassify a build, the fix takes effect for future events.
 
-When a user transitions from anonymous to known:
+### When NOT to recommend a separate project
 
-1. Call `identify(userId, { email, visitorId: apex_vid_cookie_value })`
-2. The `visitorId` trait links anonymous browsing to the authenticated user
-3. Server-side `identify`: pass `traits.visitorId` = browser's `apex_vid` cookie value
-4. Without stitching, Apex creates a disconnected identity — pre-signup attribution is lost
+Some MMP vendors require two project keys (sandbox + live). Apex does not. If a merchant asks "should I use a different project for beta?" or "do I need a sandbox key?", the answer is **no**: point to `/docs/mobile/test-vs-production` and walk them through the **Build environments** card in Settings → Mobile apps.
 
 ## Related
 
-- Event naming and tracking fundamentals: see **apex-growth-tracking** skill
+- Event tracking fundamentals: see **apex-growth-tracking** skill
 - Experiment design: see **apex-experimentation** skill
-- Intelligence and beliefs: see **apex-growth-intelligence** skill
 - Communication setup: see **apex-communications** skill
+- Affiliate / partner programs: see **apex-partner-network** skill

package/skills/apex-journeys/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: apex-journeys
+description: Help users design, audit, and ship Adaptive Journeys — multi-step lifecycle sequences with waits, branches, and exit rules. Use whenever the user mentions journeys, cart abandonment, onboarding sequences, drip campaigns, or asks to add/remove an exit rule. Always run alongside apex-communications for any cart-recovery, lifecycle, or sequence work.
+---
+
+# Apex Journeys (MCP)
+
+Journeys are multi-step communication sequences with waits, branches, and exit rules. A single `send_email` is a Communication; a `send_push → wait 1h → send_email → wait 24h → send_email` is a Journey.
+
+The single hardest thing about journeys is **knowing when to stop**. The vast majority of lifecycle programs that look broken to end users are journeys that fired a "you forgot something" message after the user already came back. This skill makes exit rules a first-class concern.
+
+## When to Activate
+
+- User says "journey", "sequence", "drip", "lifecycle program", "cart abandonment", "abandoned cart recovery"
+- User wants to chain multiple messages with delays between them
+- User is editing or auditing exit rules
+- User mentions branching on subject state (cart contents, plan tier, lifecycle stage)
+- User just created a marketing communication and you sense it should be part of a sequence
+
+## Tool Map
+
+| Tool | When to use |
+|---|---|
+| `list_journeys` | Browse all journeys with their exit-rule counts. Start here for any audit or "what do I have?" question. |
+| `get_journey` | Read full configuration for a specific journey (steps, exit rules, goal). |
+| `list_journey_exits` | Read only the exit rules for one journey. Use when the user asks "what triggers an exit for this?" |
+| `add_journey_exit` | Add an exit rule to a journey draft. Use when the user (or you proactively) decides a journey needs a new exit trigger. |
+| `remove_journey_exit` | Remove an exit rule from a journey draft. |
+| `audit_journey_exits` | Sweep across all published marketing journeys and find ones missing purchase exits. Run this proactively when a user mentions journeys, cart recovery, or marketing programs. |
+| `get_contact_cart` | Inspect a contact's current cart state to debug cart-recovery journeys or branch.condition evaluations. |
+
+## Core Concepts to Convey
+
+### A journey is just steps with edges
+
+Each step is one of: `send_email`, `send_push`, `send_sms`, `wait` (`fixed` or `until_event`), `branch.condition`, `goal`, or `exit`. Edges describe which step runs next. The runtime (a Step Functions state machine per execution) advances pointers and emits events.
+
+### Exit Events are journey-level, not step-level
+
+Exit rules are declared once at the journey level and apply to every in-flight execution. When a matching event fires for the executing subject, the matcher halts the execution **regardless of which step it was on**.
+
+```ts
+journey.exitEvents = [
+  {
+    id: "exit-cart-purchased",
+    eventName: "in_app_purchase",
+    description: "Stop messaging if the user completes a purchase",
+    enabled: true,
+  },
+  {
+    id: "exit-cart-cleared",
+    eventName: "cart_snapshot",
+    guard: { kind: "compare", path: "itemCount", op: "==", value: 0 },
+    description: "Stop messaging if the cart was emptied (not via purchase)",
+    enabled: true,
+  },
+];
+```
+
+When teaching users, this is the mental model:
+
+> "A journey starts because something happened. An exit fires when the reason for the journey no longer exists."
+
+### Send-time gate is authoritative
+
+Even if the stream-based exit matcher misses an event (race conditions are rare but possible), every `send_*` step re-checks exit rules immediately before firing. This is the guarantee Apex makes to its users: **if an exit event has fired by the moment we send, we will not send**.
+
+You can mention this to users; it removes a class of "what if the event arrived 2ms before send?" worries.
+
+### Counters that prove it works
+
+`/api/journeys/[id]/calibrated-impact` exposes:
+
+- `triggered_exposed_exited_before_send` — how many people exited before any message went out. **A healthy cart-recovery journey will have this > 0**: it's the number of customers Apex protected from a stale message.
+- `converted_exposed_messaged` — converted users who received at least one message. This is the honest "did the message contribute?" denominator.
+- `messagedLift` — calibrated lift restricted to messaged subjects.
+
+When discussing journey performance, lead with `messagedLift`, not raw conversion.
+
+## Tool Invocation Order
+
+### "Set up cart abandonment recovery"
+
+This is the canonical journey-skill workflow. **Always involve apex-communications** for the payloads.
+
+```
+1. list_journeys → check if a cart-recovery journey already exists
+2. If not, recommend the mobile-cart-recovery template (it's seeded in Apex)
+3. Ensure communications exist: hand off to apex-communications.recommend_communications + generate_communications for the cart-recovery push and email
+4. Confirm exit rules: add_journey_exit for in_app_purchase, cart_snapshot itemCount==0, and checkout_completed
+5. list_journey_exits to confirm
+6. Walk the user through the apex.trackCart helpers their app needs to call (see apex-growth-tracking for the SDK shape)
+```
+
+### "Audit my journeys for missing exits"
+
+```
+1. audit_journey_exits(active_only=true)
+2. For each missing_purchase_exit row: walk the user through add_journey_exit
+3. Re-run audit_journey_exits to confirm all journeys are green
+```
+
+### "Why didn't this user get my cart-recovery push?"
+
+```
+1. get_contact_cart(contact_id=...) → check current cart state (itemCount, lastEventId)
+2. If cart.itemCount === 0, the exit rule fired — that's correct behavior
+3. If cart still has items, get_journey(journey_id) and verify the wait duration + exit rules
+4. Check calibrated-impact for triggered_exposed_exited_before_send count
+```
+
+### "Add a new exit condition to onboarding"
+
+```
+1. list_journeys → find the onboarding journey id
+2. list_journey_exits(journey_id) → see what already exits
+3. add_journey_exit({journey_id, event_name: "onboarding_completed", description: "User finished setup before wait expired"})
+```
+
+## Proactive Behavior
+
+### When the user creates a marketing or lifecycle communication
+
+After helping a user generate a single communication, ask whether it's part of a sequence:
+
+> "This 'cart abandoned' push is a single send. Most cart-recovery programs are a sequence: push at 30 min → email at 2 hr → final reminder at 24 hr. Want me to wire this as a journey so it doesn't fire for users who already bought?"
+
+### When the user mentions a wait, delay, or "after X hours"
+
+Anything with a wait needs exit rules. Don't ship a journey without them.
+
+> "I set up the journey with a 1-hour wait before the next message. Before we publish, let me add exit rules so we stop messaging anyone whose cart is purchased or cleared during that hour."
+
+### When auditing existing programs
+
+Run `audit_journey_exits` proactively at the start of any conversation about journeys, marketing programs, or cart abandonment. If anything returns missing, surface it before doing anything else.
+
+### When the user asks "should I send this?"
+
+If the answer involves a wait, the real question is "what should stop this from sending?" Reframe the conversation toward exit rules.
+
+## Common Mistakes to Catch
+
+| Mistake | What to say |
+|---|---|
+| Cart-recovery journey with no exit on purchase | "Add an exit on `in_app_purchase`. Without it you'll message buyers after they bought." |
+| `wait.fixed` for cart abandonment | "Use `wait.until_event` with a deadline. That way the wait ends as soon as the user comes back, not on a fixed timer." |
+| Exit rule with no `guard` on `cart_snapshot` | "`cart_snapshot` fires whenever the cart changes, including adds. Add a guard like `itemCount == 0` so you only exit on a cleared cart." |
+| Same exit rule on multiple journeys, hand-managed | "Apex doesn't share exit rules across journeys, but the underlying event matches the same. Each journey gets its own copy — that's fine." |
+| Disabling all exit rules to "always send" | "If you want to always send, remove the wait. Don't disable exits and keep the wait — you'll re-create the original problem." |
+
+## Glossary
+
+- **AdaptiveJourney**: A draft/published journey with steps and exit rules.
+- **ExitEventRule**: One rule on `journey.exitEvents`. Has `eventName`, optional `guard` predicate, `description`, `enabled`.
+- **JourneyExecutionPointer**: Server-side record of an in-flight execution for one contact.
+- **wait.until_event**: A wait step that ends when a named event fires (or a deadline expires).
+- **branch.condition**: A step that routes execution based on a predicate over subject attributes (e.g., `cart.itemCount >= 2`).
+- **Send-time gate**: The authoritative re-check that runs immediately before any send step.
+
+## Resources
+
+- `apex://journeys` — current journeys list with exit-rule counts (if available as an MCP resource)
+
+## See Also
+
+- **apex-communications** — for the per-message payloads (subject, body, channel) the journey fires
+- **apex-growth-tracking** — for the `apex.trackCart` SDK helpers that emit the events journeys consume and exit on
+- **apex-experimentation** — to A/B test variants within a journey step