Plugin compatibility matrix tests

[Hey-Yetunde]

Problem

The plugin manifest declares a compatibility field (PEP 440 style, e.g. >=0.8.0) but there is no compatibility/versioning mechanism, and therefore no tests verifying that compatibility decisions behave correctly. This issue adds a focused test matrix for the compatibility logic once the mechanism exists (#168). It must stay independent enough for a contributor to implement as a follow-up, not a dependency that blocks the mechanism itself.

Context

• app/services/plugins.py::PluginManifest - compatibility field (default >=0.8.0), parsed but not yet enforced.
• plugins/plugin.schema.json - documents compatibility as PEP 440 syntax.
• pyproject.toml - application version (0.1.0).
• The compatibility/versioning mechanism itself is tracked in Plugin version compatibility checks (PEP 440) #168 (Plugin version compatibility checks, PEP 440). This issue assumes Plugin version compatibility checks (PEP 440) #168 (or an equivalent) exists and produces a comparison function.

Scope

A parameterized test matrix for the compatibility mechanism. Do not build the mechanism here; do not require a massive matrix.

Technical requirements

• Assume a compatibility check function (from Plugin version compatibility checks (PEP 440) #168) that answers "does plugin compatibility range accept the given app/plugin API version?". Parameterize tests over combinations of:
  • Plugin version / compatibility specifier (e.g. ==0.1.0, >=0.8.0, ~=0.8.0, !=0.9.0, ranges with spaces/commas).
  • Application / plugin API version being compared against.
  • Supported compatibility range -> compatible.
  • Unsupported versions -> incompatible.
  • Boundary versions (exactly at the edge of a range, e.g. >=0.8.0 with app version 0.8.0 vs 0.7.9).
  • Invalid specifiers (malformed, empty) -> handled safely (rejected or reported, never crash).
• Use pytest.mark.parametrize; keep the matrix compact and readable.
• Document the expected behavior the matrix encodes (the deterministic contract).

Acceptance criteria

• The matrix is deterministic, documented, and passes against the mechanism from Plugin version compatibility checks (PEP 440) #168.
• Boundary and invalid-version cases are covered.
• No application behavior is changed by this issue (tests only).

Testing requirements

• Parameterized tests as above; no integration/network tests required.

Dependencies

• Plugin version compatibility checks (PEP 440) #168 (Plugin version compatibility checks, PEP 440) - the mechanism this issue tests. This issue is independent enough to be written against a defined interface once Plugin version compatibility checks (PEP 440) #168 exists; it must not attempt to implement compatibility logic.

Difficulty

Medium

Priority

Low