State that enum widening keeps the epoch

The operator ruled on 2026-09-16 that widening a `PipelineKind` enum is
additive. The README's additive rule named only a new field with a serde
default, which is true and stays, but did not cover the case.

The clause says why in the README's own voice: these readers are ours and each
ships with the variants it knows, so a reader that meets a kind it has never
heard of refuses it on the kind, not on the epoch. That is also the answer to
the tension with the wire note two sentences earlier -- the contracts do cross
out of this repo, and the rule holds because the readers on the other side are
still ours. If that stops being true, the rule needs revisiting.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Meta Vens 2026-09-16 12:19:14 +02:00
commit 3ee78e05a4

View file

@ -38,8 +38,11 @@ contracts cross to the Huginn organ and its `eureka-state` client. The files are
derived from the Rust value types and checked byte-for-byte by
`epiphany-pipeline`'s `pipeline_published_schemas_match_derivation`; text bounds are UTF-8 bytes and
enforced by admission, not by the schema. Evolution is additive: a new named
field with a serde default keeps `epiphany.pipeline.epoch.v1`; a breaking change
bumps the epoch, and the new binary refuses the old store.
field with a serde default keeps `epiphany.pipeline.epoch.v1`, and so does
widening an enum such as `PipelineKind`, because these readers are ours and each
ships with the variants it knows -- one that meets a kind it has never heard of
refuses it on the kind, not on the epoch. A breaking change bumps the epoch, and
the new binary refuses the old store.
Provider request contracts are owned by their provider boundary. The shared
Codex contract lives in `GameCult/CodexConnector`; Epiphany's closed durable