event-sourcing-state

name	event-sourcing-state
description	Event-sourced application state pattern for TypeScript apps. Prefer bounded event logs plus pure derivation functions over mirrored mutable lifecycle flags. Use when state transitions are driven by events and bugs can be reproduced from a saved event stream.
version	0.2.0

Event-Sourcing State

Use this skill when an app keeps adding mutable fields to track lifecycle, phase, status, or UI state that could instead be derived from an event log.

Core idea

Do not store the answer when you can store the evidence.

Coding agents overproduce state. Every bug looks like it wants one more flag, one more cached answer, one more special case. Every field feels locally justified. Globally you are building a machine nobody can hold in their head.

Every boolean you add:

1. doubles your app's possible states
2. doubles your bugs
3. doubles the coverage you need in the worst case

The fix is not a better set of flags. The fix is deleting the flags.

Stop storing conclusions and store evidence instead. If a decision depends on what actually happened, keep the events and derive the answer from them.

Anti-pattern: mirrored flags

To answer one yes/no UI question ("should the footer show?"), an agent will mirror facts into state:

type ThreadState = {
  wasInterrupted: boolean
  didAssistantFinish: boolean
  didAssistantError: boolean
  : 
}

 ():  {
   state.
    && !state.
    && !state.
    && !state.
}