Module epoch 

The epoch: one genesis append, the seal it opens under, and the activation that breaks it.

The kernel’s own lifecycle is an aggregate like every other one — kernel/singleton, in project system — which is why no state table stands behind it. Version 1 is genesis and the kernel is SEALED; version 2 is activation and it is ACTIVE. So max(aggregate_version) on that aggregate IS the epoch, read under the same writer lock the append will take. A cached flag or a projection row would be a second place the answer lives, and the log is the one that survives a restore.

Genesis is appended through the fenced store, never beside it: crate::admin::init runs as the admin role and holds neither the writer lock nor the durable epoch, so a genesis written there would be the one event in the log that skipped the path every other event takes.

Constants

ACTIVATION_EVENT_TYPE

GENESIS_EVENT_TYPE

GENESIS_KEY

Genesis carries a fixed key: there is no caller to supply one, and a fixed key makes a second genesis attempt a constraint violation rather than a second event.

KERNEL_AGGREGATE

The aggregate the kernel keeps its own lifecycle in.

KERNEL_SINGLETON

Its only id: there is one kernel per database.

SYSTEM_PROJECT

The project genesis is written under, and therefore — by the ownership rule in crate::submit — the only project that may activate.

Functions

is_public_revision

True iff value is a full lowercase 40-hex git revision.