Skip to main content

Module hooks

Module hooks 

Source
Expand description

§6 plugin wiring — the config/plugins.toml [hooks] schedule.

The hook list is config: config/plugins.toml’s [hooks] table on the landing (§2) is the SINGLE source of truth for which plugin runs in which op-phase. A <op>.<phase> key maps to an ORDERED LIST of plugin names — listed = run, list position = run order (the last name runs last). An absent key or empty list = run nothing (the general path with no entries, §4). This retires the filesystem <op>/<phase>/NN-<name> symlink registry: ordering is a list property, not an NN- filename convention faking one.

Names are committed text — portable verbatim, valid in stealth and federation regardless of where the checkout sits. The LOCAL config/plugins/bin/<name> symlink (crate::registry) resolves each name to this machine’s binary; Hooks::resolve stitches the two halves into the PluginRef sets the §8 engine runs, an absent bin/<name> surfacing as a dangling ref (a clean “referenced but not installed here” at dispatch, never a silent skip).

Structs§

Hooks
The parsed [hooks] table: "<op>.<phase>" → its ordered plugin-name list. A BTreeMap so the schedule (and its Hooks::referenced projection) has a deterministic order — the seed re-serializes it after pruning (§12).