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)

Trigger-type awareness

A payload proves an event-type trigger fires. It does not prove the other two trigger types the journey schema allows the same way:

• time (a wait/schedule fires entry, e.g. "3 days after signup with no purchase") — there's no event to post; the test is a state precondition (the qualifying event backdated so the wait has already elapsed) plus an instruction to advance the sandbox clock or temporarily shorten the wait for the run. Say which one the tester should do — don't imply a payload alone proves a time trigger.
• segment_entry — the payload can prove the underlying behavior/attribute changed, but whether the journey actually fires also depends on the CRM's own segment-recomputation cadence (many tools refresh segments hourly or nightly, not on every event). A test that "passes" the instant after posting doesn't rule out a real refresh delay in production. Name the tool's refresh cadence if known; flag it as unverified if not.

Output

output/<project>/qa-payloads.json — machine-facing (CLAUDE.md rule 2 artifact classification), one entry per case:

{
  "journey": "ins-churn-prevention-01",
  "case": "entry-negative: policy_renewal already fired",
  "expect": "journey must NOT arm",
  "payload": { "...": "..." }
}

Every case carries an expect line — a payload without an expected outcome is not a test. Timestamps are relative placeholders (<now>, <now-2d>) the tester fills at run time, never baked dates.

Coverage matrix (user-facing). Alongside the JSON, present a small table — journeys as rows, case classes as columns, a mark per cell where a case exists — so a missing class (no duplicate-delivery case because the pattern carries no retry risk, no timeout branch because the journey has none) reads as a stated gap, not a silent omission. This is a coverage summary of what was generated, not a pass/fail report: lifecycle-qa doesn't execute against a live CRM, so whether a case actually passed is the tester's to report back once they've run the payloads.

Never do

• Never invent a vendor's ingestion envelope — no sample request → generic shape + a clear "adapt the envelope" note.
• Never generate a payload the real instrumentation can't produce (params the tracking plan lists as missing) — that "passing" test would validate a journey the production data can never trigger.
• Never mark the set complete without the negative cases — positive-only QA is how silently-broken entry conditions reach production.
• Never let one golden-path sample payload stand in for the full range real instrumentation produces — an optional param that's sometimes missing or null in production is exactly what the degraded-payload case exists to catch; a set built only from the one idealized shape the user pasted is a contract test with a sample size of one.
• Never present a segment_entry/time case as equivalent proof to an event case — state plainly whether firing was proven directly or depends on a schedule/refresh cadence the payload doesn't control.