Both CodeRabbit findings on #427 hold up against the code; one sub-point was
already moot.
1. The compatibility regression test was described as one case (bundled copy
removed on an old core) when it needs four. The case that actually matters
is the one that was missing: an adopted plugin loading *with* its bundled
copy on an old core, which is the entire basis for claiming B5 is safe to
run ahead of the gate. Now a 2x2 table.
The assertion was also wrong. "Fails loudly and specifically" is
aspirational -- PluginManager.load_plugin catches ModuleNotFoundError, so
nothing propagates and it fails into PluginState.ERROR with one log line.
A test expecting a raise would pass for the wrong reason. Specified as
PluginState.ERROR plus the exact missing module path, which is also what
the rest of this document already says the failure looks like.
2. `compatible_versions` -- not `ledmatrix_min_version` -- is the canonical
contract: schema/manifest_schema.json requires it, all 42 published
manifests carry it, and it holds semver ranges ([">=2.0.0"] in 41,
[">=1.0.0"] in 7-segment-clock). The gate as merged reads only the floor.
Harmless today: no manifest uses an upper bound, and the two fields agree
everywhere except 7-segment-clock. But the schema's range syntax permits
upper bounds, so a plugin declaring ["2.0.0 - 2.9.9"] would be installed on
3.2.0 regardless. Recorded as a named gap the gate must close before B6,
and the migration step now has to reconcile both fields across every
manifest the gate can refuse.
Skipped, with reason: the finding also asked to migrate the deprecated
top-level `ledmatrix_version`. No manifest carries it -- verified across
all 42 -- so there is nothing to migrate.
Documentation only.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5
The phase table folded two steps with very different risk profiles into one
B5: adopting core imports (safe by construction -- the guarded import keeps
the bundled fallback) and deleting the bundled copies (removes the fallback,
so the import becomes a hard dependency). They are now B5 and B6.
Reading the enforcement path showed the declared floor protects nobody today:
- PluginLoader._warn_if_incompatible is advisory, and skips entirely when the
parsed core version is below 2.0.0.
- The v3.1.0 release ships __version__ = "1.0.0" -- the tag was cut
2026-05-31 and the string was not bumped until 2026-07-12 -- so the skip
matches exactly the users most likely to be behind.
- Neither StoreManager.install_plugin nor .update_plugin compares the core
version, so a store update delivers a plugin that floors above the core.
Verified against a v3.1.0 worktree: sports_scroll, element_style and the
sports package are absent there, and the import fails with
exc.name == 'src.common.sports_scroll' -- a guard set of {"src"} does not
match it.
B4 therefore grows to include making the version number trustworthy and
adding the install/update gate; B6 waits on that gate having shipped and
reached users. Also adds an ordered "What's next" and the durable lessons
this migration paid for.
Documentation only; no code changes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5
