Undo and redo over StatifierBlocks.Edit.t() commands (ADR-0005 decision 3), and the one funnel every editor command actually goes through: commit/4 runs Edit.check_config/3 before Edit.apply/2, so "invalid config never reaches the document" is a property of this module, not a rule an editor shell has to remember to enforce itself.

The gate runs on undo and redo too

Edit.apply/2 is purely structural; it never asks a block type whether a config is valid. commit/4, undo/3 and redo/3 all route through the same private funnel, and that funnel always calls Edit.check_config/3 first - undo and redo included, not just the initial commit. This is deliberate, not an oversight: one code path means one thing to test, and it is the strict reading of decision 9 ("invalid config never reaches the document" is a property of every path that can produce a document, not only the first one).

It is also sound, not merely convenient. The config an inverse restores was already in the document at some earlier point, which means it already validated - under whatever palette was in effect when it got there. ADR-0005 decision 15 makes the editor single-session: one palette, built once, for the whole session. A host that swapped the palette out from under a live session could in principle see an undo refused by a rule that did not exist when the config was written, but that scenario is exactly what decision 15 puts out of scope. Within a single session the palette never changes underneath the history, so the config an undo or redo restores always validates the same way it did the first time.