Sequence versioning for in-flight contacts

When a sequence is edited in place — steps added, removed, or reordered on the same mutable record — every active enrollment instantly changes behavior. A contact on step 3 of a 5-step sequence wakes up to find step 3 is now something completely different, or that step 5 was removed and the sequence loops. CWE-440 (Expected Behavior Violation) and iso-25010:2011 reliability.recoverability apply: the system makes no guarantee about what a contact in-flight will experience once a sequence is modified. Beyond the technical defect, this creates unpredictable outreach — contacts who opted into a specific message cadence receive a different one — and debugging post-send complaints becomes impossible without version history.

Snapshot sequence steps into an immutable sequence_versions table on each publish and store the version ID on enrollment records. New enrollments reference the current active version; existing enrollments are unaffected by subsequent edits.

async function publishSequenceVersion(sequenceId: string, steps: SequenceStep[]) {
  const version = await db.sequenceVersion.create({
    data: { sequenceId, steps: JSON.stringify(steps), publishedAt: new Date() }
  })
  await db.sequence.update({ where: { id: sequenceId }, data: { activeVersionId: version.id } })
  return version
}

// Enrollment records the version at enroll time
async function enrollContact(contactId: string, sequenceId: string) {
  const sequence = await db.sequence.findUnique({
    where: { id: sequenceId }, include: { activeVersion: true }
  })
  return db.contactSequence.create({
    data: {
      contactId, sequenceId,
      sequenceVersionId: sequence.activeVersionId,
      currentStepIndex: 0, status: 'active'
    }
  })
}

The sequence_versions table and sequence_version_id FK on contact_sequences are the minimum schema changes required.