Module plugins 

Engine plugins namespace: discovery, custom-operation dispatch, cache keys.

Custom operations (spec 31): a plugin operation like acme.echo is callable through invoke(), RPC, HTTP, SDKs, and FFI with no per-transport code — the fallback arm in invoke routes unknown acme.* ids here. Provenance (spec 25): every plugin output is wrapped with its origin. Failure policy (spec 26): required = hard error, warn/optional = skip with a structured diagnostic. Cache keys (spec 27) include the plugin lock so upgrades invalidate ranking-dependent caches automatically.

Structs

ActivePlugins

ExtensionOrder

Deterministic extension order (§19): priority ascending, plugin id ascending, then before/after DAG edges. Unknown references and cycles are startup errors — never silent misordering.

Functions

active

budget_selection

Budget-optimizer selection (§124 item 27): the single declaring budget-optimizer:* extension replaces budget selection via the plugin’s selection.optimize op (input: ranked ids + budget; output selected: [ids]). Zero declarers = None (caller runs the default). Two+ declarers = hard error (spec §32: no silent last-wins for exclusive policy slots). Unknown ids in the plugin answer fail loudly; an empty answer is honored (select nothing).

cache_key_fragment

call_operation

Dispatch a plugin-provided operation. Returns (output, diagnostic): warn/optional failures yield the engine error + a diagnostic instead of failing the call — the host records what was skipped (spec 26).

commit_contribution

Commit a validated batch: entities, relationships, evidence in order. Validate-then-commit keeps broken plugins from half-writing the model.

context_sections

Context-section contributions (§17 Context): every context-section:* extension renders one markdown section into the task pack.

diversity_selection

Diversity-policy selection (§124 item 24): the single declaring diversity-policy:* extension replaces MMR via the plugin’s selection.diversify op (input: ranked ids + lambda; output selected: [ids], honored verbatim). Zero declarers = None (caller runs default MMR). Two+ declarers = hard error (spec §32: exclusive policy slots never silently last-win). Unknown ids fail loudly; an empty answer is honored (select nothing).

lock_entries

order_extensions

promote_sidecar

Sidecar promotion (§124 item 36): promote selected sidecar findings into canonical relationships through the NORMAL contribution path (validate + atomic commit) — never a side door. Each assertion needs existing subject/object entity ids (no invented endpoints), a CORE ontology predicate (custom semantics stay plugin:<id>/... via plugins.contribute), and a confidence in [0,1]. Provenance stamps plugin:<id>; RESOLVED only on explicit exact: true (spec §43: a plugin may not label guesses RESOLVED), else INFERRED. Evidence ids supplied by the caller are preserved; the plugin extractor tag is added at commit time by the normal path.

quota_overrides

Quota-policy overrides (§124 item 25): every quota-policy:* extension may override per-kind quota fractions via the plugin’s selection.quotas op (input: ranked ids + request quotas; output quotas: [{kind, fraction}]). Returned pairs merge over the request quotas (plugin wins per kind). Failures follow policy: required = hard error, else skipped with a diagnostic. Fractions clamp to [0,1] at apply time (apply_quotas already clamps).

startup_sections

Startup-section contributions (§124 item 29): every startup-section extension renders one markdown section into the startup pack.

validate_contribution

Validate a plugin contribution batch (§24): entity ids and kinds present, relationship endpoints resolve within (batch entities + graph), custom ontology namespaced plugin:<id>/..., evidence ids present.

verify_diagnostics

Verify-diagnostic contributions (§124 item 30): every verify-diagnostic:* extension renders one findings section into the verify pack via the plugin’s verify.diagnostic op (no input). Output diagnostic markdown is spliced verbatim under a provenance header. Failures follow policy: required = hard error text inline, else skipped with a diagnostic note.

viewer_panels

Viewer-panel contributions (§124 item 32): every viewer-panel:* extension contributes one structured data panel to the viewer via the plugin’s viewer.panel op (input: panel id). Output is data the CLI renders into the viewer nav/pages — never arbitrary JS (spec §104). Each panel carries provenance (plugin id + extension); required-panel failure is an inline error panel, else the panel is skipped with a note.