mirror of
https://github.com/logos-co/logos-liblogos.git
synced 2026-08-27 04:41:12 +00:00
Dario Gabriel LipicarandClaude Opus 5
82a17ba13d
The observer and the feed merged in #189, but nothing shipped or loaded the module, so in a normal run the whole thing was inert -- correctly, since the feed arms only when modules_state itself loads. BUNDLE. nix/modules.nix took one hardcoded capability_module; it now takes a list of { name; pkg; version; }. Same generated manifest, same three traps its comments encode (the required "type" field, the explicit extension list that Windows needs, target-vs-build platform keys). AUTO-LOAD. initializeModulesState() runs from logos_core_start() after initializeCapabilityModule(). Optional by construction: absent, it returns false, nothing changes, and the observer keeps early-outing with no sink. LOADING LAST IS FINE, and this is the part that is easy to get wrong. The membership edges from discoverInstalledModules and capability_module's own load happen BEFORE any sink exists, so they are dropped. The snapshot back-fills them. modules_state cannot be first, so it must not need to be -- which is exactly what apply_snapshot is for. MEASURED, stock daemon, no -m flag, no test door, no load-module: module list capability_module state:loaded seq:2 modules_state state:ready seq:4 pid:2515 partial false REFUSED 0 snapshot 249 ms after "Module loaded: modules_state", exactly once capability_module appearing at all is the proof the snapshot ran: it loaded before the feed existed, so only apply_snapshot could have put it there. `state:ready` rather than `loaded` exercises the loaded->ready publish transition end to end. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>