Closes #78. My bug from the original G1/G2/G3/G4 ships — I treated __init__.py as docstring + logger metadata and omitted the register(ctx) function that hermes_cli/plugins.py requires.

Per the loader (line 1184-1187):

register_fn = getattr(module, "register", None)
if register_fn is None:
    loaded.error = "no register() function"
    logger.warning("Plugin '%s' has no register() function", manifest.name)

So after #77 fixed packaging, plugins now ship + load — but every devagentic-* plugin registers nothing, because there's nothing to register. The G1 preamble loader is the most painful symptom: preamble.on_pre_llm_call exists but is never wired to the pre_llm_call hook → worker boots with no vertical preamble → polynomial-explorer hallucinates doc_ids.

Fix

The stub register()s exist so the loader doesn't warn no register() and skip the plugin. The MCP-tool wiring is separate (server-side) and unchanged.

Test plan

• 8 tests in tests/test_plugin_register_fns.py:
  • G1 specifically: register() wires pre_llm_call hook to a callback named on_pre_llm_call (the source-truth fix).
  • G2/G3/G4 parametrized: register() is callable, doesn't raise, registers nothing via the loader (MCP-only by design).
  • All 4 parametrized source check: __init__.py literally contains def register(ctx. Catches future regression where the function disappears.
• Loads each plugin via importlib.spec_from_file_location with sibling-module pre-loading so the package's relative import (from . import preamble) resolves without requiring the whole hermes package install.

Deploy chain reminder

For polynomial-explorer to actually work end-to-end, the operator needs ALL of these landed + redeployed in the container:

1. fix(packaging): ship plugin.yaml via package-data + MANIFEST.in (closes #76) #77 packaging (merged) — plugins ship in wheel
2. CRITICAL: G1/G2/G3/G4 plugin __init__.py missing register(ctx) — loader silently skips wiring (hook + tools no-op) #78 register() (this PR) — loader actually wires the hook + reports tools/hooks > 0 per plugin
3. devagentic#222 (merged) — /graphql reachable on port 6071 so the preamble loader's fetch returns the rollup
4. Container rebuild from main + service restart

After all four:

• find .../site-packages/plugins -name plugin.yaml → ~25+ files (fix(packaging): ship plugin.yaml via package-data + MANIFEST.in (closes #76) #77 effect)
• hermes plugin list reports each devagentic-* plugin with 1 hook (G1) or 0 hooks 0 tools (MCP-only) (G2/G3/G4) — but the loader no longer WARNs
• G1 preamble fires on session boot → worker sees the vertical-spec + 70-graft index + worker-guardrails
• Worker can call grafted_context_fetch(graft_id=<real-id>) with actual ids from the index instead of hallucinating

Notes

• I have NOT audited every plugin in the tree for this issue — only the four I shipped. Existing plugins (canvas, docs, etc.) have register() per my earlier inspection. If other plugin authors hit this same bug, that's a separate issue.
• The MCP-only stub pattern for G2/G3/G4 is a deliberate scope choice — making those tools available via the plugin-loader registry (so they appear in agent.tools for the worker's chat completions) would require schema definitions + handler shims per tool, ~50 LOC × 6 tools. Different PR, different scope. Today, those tools serve MCP clients (Claude desktop, hermes-internal MCP-client bridges, etc.) — the worker can still reach them via that path.