lifecycle-qa

Lifecycle QA — Trigger Payload Simulator

The hardest part of wiring a designed journey into a CRM is proving the trigger works: someone hand-writes a fake purchase with the right params and posts it at the panel. The engine already knows every journey's entry conditions, branch conditions, and exits — so it writes those payloads itself, including the negative cases a hand-tester forgets.

When NOT to use this

• No generated journey JSONs exist yet — there's nothing to derive triggers, branches, or exits from; run lifecycle-journeys/lifecycle-export first.
• The question is whether a LIVE journey is performing well — that's lifecycle-results. This skill proves triggers fire correctly before launch; it has no view into post-launch outcomes.
• The event a payload would need is already confirmed missing in the tracking plan — don't generate a payload the real instrumentation can't produce; that "passing" test would validate a journey production data can never actually trigger (see Never do below).

Inputs (gate)

1. Generated journey JSONs (from lifecycle-journeys / lifecycle-export) — the source of truth for triggers, entry conditions, branches, exits.
2. The mapped event inventory (which params each event actually carries — payloads must be satisfiable by the real instrumentation, never invent params the tracking plan says don't exist yet).
3. Optional but valuable: a sample request from the user's CRM (one real ingestion payload). With it, generated payloads follow the exact envelope (identifier fields, attribute nesting, timestamp format). Without it, payloads use a generic GA4-style shape and say so plainly — never guess a vendor's envelope from memory.

What gets generated (per journey)

Case class	What	Why
Entry positive	One payload satisfying the trigger + every entry condition	Proves the journey arms
Entry negatives	One payload per entry condition, each violating exactly that condition (wrong event, missing required param, below threshold, excluded segment)	Proves the journey does NOT arm when it shouldn't — the failure a hand-tester never writes
Boundary pair (threshold conditions only)	For a numeric/window condition ("≥ 2 view_item in 30 days"), the value just below the threshold alongside the value just at it (1 vs. 2; day 31 vs. day 30) — not one arbitrary satisfying value	Off-by-one and window-math bugs live at the edge; a single satisfying example can pass while the boundary is wrong
Branch cases	One payload per branch condition, both sides	Proves each split routes correctly
Timeout / no-response branch (wait-gated conditions)	The no-event side of a branch keyed off a step's wait elapsing, not an opposing event	Proves the "nobody responded" path — this can't be proven by posting a payload; the case says whether to advance the sandbox clock or temporarily shorten the wait for the test run
Duplicate delivery	The same trigger event (same id/params) posted twice	Proves the journey doesn't double-enter or double-fire a user on a retried/replayed delivery — the standard webhook-retry failure mode
Degraded payload	The entry-positive event with one real-but-optional param dropped or null, per the mapped inventory's own optionality (never an invented gap)	Proves the trigger config survives the partial data real instrumentation actually sends sometimes — a suite built from one idealized sample payload can still pass while realistic partial traffic silently fails to enter
Exit / suppression	The success-exit event mid-journey; the kill-switch event where the pattern has one (refund, complaint)	Proves exits fire and suppression works — the highest-stakes test in the set
Cap probe (portfolio-level)	The declared audience_overlaps scenario: one user triggering both journeys in the same week	Proves the pause/precedence rule actually holds in the tool, not just in the doc