Teknium
1a74e7fb43
The @ popover only completed filesystem references; bot handles worked when fully typed (mention middleware parses at submit) but were never offered, so users had to know the exact handle — worse with multi-source @name-device handles. Fixes #88060 (ported from Hermes-Bot-Mode#43). - composer contrib: new 'composer.atCompletions' data area (ComposerAtCompletionSource) — contributed rows merge AHEAD of path results; a throwing source drops its rows, never the popover - use-at-completions: merge contributed entries in all three fetch paths (gateway results, gateway-less, fetch error) - SDK: export the new area + types for plugins - bundled Bot Mode plugin: registers 'mention-completions' — roster handles from the query cache (\u22645s stale), active profile excluded, 'default' offered as @hermes, multi-source @name-device handles via botHandle, display name + connection label in the row meta, capped at 8 - registered early in register(ctx) so vm harnesses reach it before the pane/UI registrations that stubs can't fully model
Bundled plugins
Drop a <name>/plugin.{ts,tsx} here that default-exports a HermesPlugin and
it registers automatically at boot (vite glob in ../contrib/plugins.ts), with
the same inventory + live enable/disable contract as runtime plugins.
Keep this tree for real shipped plugins (and the small authoring fixtures that
dogfood the SDK). One-off demos that rebuild a core chrome piece 1:1 do not
belong here — they double the UI and confuse Settings ▸ Plugins. Publish those
in the companion
hermes-example-plugins
repo instead.
User- and agent-authored plugins load at runtime from
$HERMES_HOME/desktop-plugins/<name>/plugin.js (the disk door) — see the
hermes-desktop-plugins skill.