Description
Per the Repository Map, backend/ handles "plugin loading" and plugins/ contains "scanner metadata, parser code, and plugin-specific helpers," with PLUGINS.md serving as the "Plugin Catalogue." The README explicitly invites GSSoC contributors to work on "Plugins: metadata fixes, parser improvements, and result normalization" as a "New Contributors Start Here" area — meaning plugin metadata is one of the most likely places for less-experienced, first-time contributors to introduce malformed data (missing required fields, wrong types, typos in scanner command templates).
There's no mention anywhere in the README of a Pydantic schema (despite Pydantic being a core documented backend dependency) validating plugin metadata at load time, meaning a single malformed plugin entry could plausibly crash the entire backend's plugin loader at startup, or fail silently in a way that's hard for a new contributor to debug.
Impact
Directly undermines the exact contribution path ("Plugins") that this README explicitly steers new/beginner GSSoC contributors toward — the easiest area to contribute to is also the easiest area to break the whole app in.
No fast-fail, clear-error validation means a plugin author gets a confusing stack trace instead of "Plugin xyz: missing required field command_template."
Proposed Solution
Define a Pydantic model (e.g., PluginMetadata) representing the required schema for a valid plugin entry (name, category, description, command template, parser reference, safety/consent flags, etc.), matching whatever fields PLUGINS.md already documents as expected.
Validate every plugin's metadata against this model at backend startup / plugin-discovery time, and log a clear, specific error identifying exactly which plugin and which field failed validation, without crashing the entire backend (skip the invalid plugin, keep the rest loaded).
Add a unit test in testing/backend/ that intentionally loads a malformed plugin fixture and asserts the loader handles it gracefully.
Document the expected plugin metadata schema explicitly in PLUGINS.md for future contributors.
Acceptance Criteria
Pydantic schema defined for plugin metadata validation
Malformed plugins are skipped with a clear, specific log message instead of crashing the backend
Unit test covering the malformed-plugin case
PLUGINS.md documents the required schema for contributors adding new plugins
Description
Per the Repository Map, backend/ handles "plugin loading" and plugins/ contains "scanner metadata, parser code, and plugin-specific helpers," with PLUGINS.md serving as the "Plugin Catalogue." The README explicitly invites GSSoC contributors to work on "Plugins: metadata fixes, parser improvements, and result normalization" as a "New Contributors Start Here" area — meaning plugin metadata is one of the most likely places for less-experienced, first-time contributors to introduce malformed data (missing required fields, wrong types, typos in scanner command templates).
There's no mention anywhere in the README of a Pydantic schema (despite Pydantic being a core documented backend dependency) validating plugin metadata at load time, meaning a single malformed plugin entry could plausibly crash the entire backend's plugin loader at startup, or fail silently in a way that's hard for a new contributor to debug.
Impact
Directly undermines the exact contribution path ("Plugins") that this README explicitly steers new/beginner GSSoC contributors toward — the easiest area to contribute to is also the easiest area to break the whole app in.
No fast-fail, clear-error validation means a plugin author gets a confusing stack trace instead of "Plugin xyz: missing required field command_template."
Proposed Solution
Define a Pydantic model (e.g., PluginMetadata) representing the required schema for a valid plugin entry (name, category, description, command template, parser reference, safety/consent flags, etc.), matching whatever fields PLUGINS.md already documents as expected.
Validate every plugin's metadata against this model at backend startup / plugin-discovery time, and log a clear, specific error identifying exactly which plugin and which field failed validation, without crashing the entire backend (skip the invalid plugin, keep the rest loaded).
Add a unit test in testing/backend/ that intentionally loads a malformed plugin fixture and asserts the loader handles it gracefully.
Document the expected plugin metadata schema explicitly in PLUGINS.md for future contributors.
Acceptance Criteria
Pydantic schema defined for plugin metadata validation
Malformed plugins are skipped with a clear, specific log message instead of crashing the backend
Unit test covering the malformed-plugin case
PLUGINS.md documents the required schema for contributors adding new plugins