VerticalSlices: Skill for Claude Code

Event Type Migrations

Chronicle stores events forever. When an event's schema must change, you write a migration rather than editing the original record — Chronicle auto-discovers migrations and applies them when reading old events.

You only need this once events of the prior shape exist somewhere you can't regenerate (a real environment's event log). Before that — in greenfield development with disposable data — rename event types and change schemas freely; a migration just adds dead code that hides the real schema in git log.

When you need it

• An [EventType] needs a new required property (adding it would break observers reading old events).
• A property is renamed; old events carry the old name.
• The event shape changes structurally.

Never add a nullable value type to an [EventType] to represent "absent on old events" — Chronicle's analyzer warns on nullable event members. Add a migration with a default instead.

Generations

Every [EventType] has a generation (starts at 1). Each schema change increments it. Chronicle routes stored events through the migration chain before delivering them to projections/reducers.

Generation 1 (stored) → Migration 1→2 → Migration 2→3 → Current (Generation 3)

Steps

1. Keep the prior record and bump the generation on the new one

Keep the old shape available to the migration as TPrevious, and mark the current record's generation:

[EventType(generation: 2)]
public record OrderPlaced(OrderId OrderId, Currency Currency);   // generation 2 (current)

2. Write the migration

Implement EventTypeMigration<TUpgrade, TPrevious> — TUpgrade is the current shape, TPrevious the prior. Chronicle extracts the generations, validates they're consecutive, and discovers the migration automatically (no registration).

Upcast and Downcast are both public abstract void and take an IEventMigrationBuilder<TTarget, TSource> — you describe the change declaratively through builder.Properties(...), you do not construct the record by hand: