Template Plugin Scaffold

The Template plugin is a scaffold for CE plugin development, not an operational runtime target. It collects starter examples for manifest, schema, dashboard, metric catalog, mapping packs, alert rules, and managed collection.

Highlights

• Demonstrates a resource_manager plus managed_metric_collector baseline.
• Includes host-rendered dashboard, monitoring route, metric route, and mapping-pack route skeletons.
• Provides plugin-owned i18n, schema metadata, and conformance test structure.
• Includes canonical live/history Diagnostic Finding examples and a separate operator-triggered refresh action.
• Acts as a starting point for replacing identifiers, module path, manifest data, route payloads, and collector logic.

Before Use

• Do not ship this scaffold as a runtime plugin.
• After copying it, adjust PluginMap and implemented interfaces to match the real plugin.
• Replace template sample metrics with real target-system collection logic.
• Keep the async-job sample only when results are disposable and may disappear on plugin restart; use durable storage for resumable or audit-required work.

Operations Tips

• Prefer schemas and route contributions over plugin-specific Core or frontend branches.
• Metric collection should produce samples; scheduling and remote write remain Core responsibilities.
• When testing Prometheus as the remote write target, run Prometheus with --web.enable-remote-write-receiver.
• Add README and manual source with each new plugin so operators can see the feature boundary immediately.
• Treat diagnostics/summary and diagnostics/history as read-only. Only an explicit operator action may call diagnostics/summary/run.

In-Memory Async Result Example

The scaffold includes two optional bounded background-work shapes. A side-effect job stores only short-lived completion metadata because its real effect belongs to the target system. A result-bearing job retains its payload with sliding idle expiry, an absolute expiry cap, and count/byte limits while keeping lightweight status metadata longer.

Status, result, and delete calls are scoped by both operation ID and resource instance ID. Result payloads can expire before status metadata, in which case result_available=false and result_expired=true explain the state. These records live only in plugin-process memory and are lost on every plugin restart.

What Developers Must Replace

• Replace plugin id, Go module/package path, manifest description, and implemented interface list for the real plugin.
• Redefine configuration schema around the target system connection model and secret fields.
• Rewrite dashboard, diagnostics, and monitoring routes around evidence and workflows that real operators need.
• Build metric catalog and mapping packs from actual exporter or managed-collector metric names and labels.
• Design alert rule packs for plugin-domain risk without duplicating Core availability.

Documentation Guidance

• Use README for developers and operators who need feature boundaries, routes, metrics, alerts, and extension-boundary details.
• Use manual source for end users and operators, explaining what to read in the UI and how to make operational decisions.
• Keep common plugin registration, metric-source linkage, and RBAC procedures in Core documentation; write only plugin-specific differences here.
• When edition-specific extension is needed, document common behavior and extension points separately.