lifecycle-journeys

Lifecycle Journeys — Portfolio Engine

Generate a portfolio of journeys, not one-off ideas. The algorithm below is deterministic — follow it in order; do not freestyle.

When NOT to use this

• No DQS exists yet — hard-blocked by CLAUDE.md rule 1; run lifecycle-connect (and lifecycle-map) first.
• A working journey already exists and the request is to review it, not replace it — that's lifecycle-audit.
• Only copy is needed for a journey that's already designed — invoke lifecycle-copy directly against the existing journey doc; regenerating the journey to get its copy is unnecessary fan-out.

Prerequisites (hard gate)

• DQS + event inventory from lifecycle-connect (or explicit T3 declaration with an industry chosen).
• Stage map from lifecycle-map (T1/T2 only).
• Intake Summary from lifecycle-intake — if goal, existing automations, or channel inventory are unknown, trigger intake NOW, before generating.
• Brand config ${CLAUDE_PLUGIN_ROOT}/knowledge/brands/<brand>.md if it exists (inheritance chain, CLAUDE.md rule 8), plus this brand's output/<brand>/failed-strategies.md and results log if they exist.

The algorithm

1. Eligibility pass

Multi-vertical brands (brand config has verticals set): run this whole algorithm once per vertical — a pattern is eligible only if applicable_industries includes that vertical's own industry, checked against that vertical's own mapped events from lifecycle-map. Steps 1–4 below all run per vertical; step 5's conflict review does not (see its note).

For every pattern in ${CLAUDE_PLUGIN_ROOT}/knowledge/journey-patterns/ whose applicable_industries includes the active sector (that vertical's sector, for multi-vertical brands):

Special case: account-onboarding supersedes welcome-onboarding for B2B accounts when account_id + user_role exist and seats > 1 — the two never both run for the same account.

• Compare its required_events (frontmatter) against the mapped event set (aliases already resolved by lifecycle-map).
• All present → eligible. Any missing → blocked: record the missing events for the tracking plan. Presence means usable, not just named: a required event whose required params are mostly null (a purchase with 90% missing value) does not satisfy the signature — the event-analyst's parameter-completeness finding gates here, and a hollow event goes to the tracking plan as "instrumented but unusable".
• optional_events / optional_attributes present → note which depth upgrades/branches they unlock.
• T3 has no events, so nothing here is data-confirmed — calling it "eligible" the same way T1/T2 do overstates what's actually known. Every pattern the playbook marks P0/P1 is playbook-recommended in its simple form (assumed feasible from sector defaults, not confirmed by data — distinct from T1/T2's data-confirmed eligible); patterns needing live data feeds (back-in-stock, price-drop, replenishment) are blocked with reason "requires data feed". The full state model across tiers: eligible (T1/T2, signature matched against real data) / playbook-recommended (T3, unconfirmed) / blocked (signature missing or feed required) / unknown (classification couldn't be completed, e.g. an unmapped event stage). Downstream (breadth gate, portfolio doc), T3 rows are labeled playbook-recommended, never bare eligible — collapsing these into one shared label is the same honesty gap the DQS activation flag and freshness/consistency caps exist to close elsewhere in this pipeline.