The maintainer no longer uses Cursor. .cursorrules, .cursorignore and the .cursor/ tree (rules, plugin templates, a parallel 751-line plugins guide) are removed; measurement showed near-zero literal overlap risk — the canonical content already lives in docs/. Unique guidance worth keeping moved before deletion: - CLAUDE.md gains the dev workflow (dev_plugin_setup.sh, dev_server.py, run.py -e, check_plugin.py), the plugin-secrets namespacing contract, and the no-draw_image()/paste-onto-PIL pitfall. - PLUGIN_DEVELOPMENT_GUIDE.md absorbs the plugin version-management rules (pre-push hook install, SKIP_TAG, version resolution order) that its own text previously linked out to .cursorrules for. - The one completed plan doc (.cursor/plans/) is archived to docs/archive/ per the docs policy rather than deleted. One of the deleted rule files (sports-managers.mdc) targeted src/*_managers.py globs that have matched nothing since the plugin migration. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SXb4mKcAkVaxkeTb3YnAdr
7.5 KiB
Implementation Plan: Fix Config Schema Validation Issues
Based on audit results showing 186 issues across 20 plugins.
Overview
Three priority fixes identified from audit:
- Priority 1 (HIGH): Remove core properties from required array - will fix ~150 issues
- Priority 2 (MEDIUM): Verify default merging logic - will fix remaining required field issues
- Priority 3 (LOW): Calendar plugin schema cleanup - will fix 3 extra field warnings
Priority 1: Remove Core Properties from Required Array
Problem
Core properties (enabled, display_duration, live_priority) are system-managed but listed in schema required arrays. SchemaManager injects them into properties but doesn't remove them from required, causing validation failures.
Solution
File: src/plugin_system/schema_manager.py
Location: validate_config_against_schema() method, after line 295
Implementation Steps
-
Add code to remove core properties from required array:
# After injecting core properties (around line 295), add: # Remove core properties from required array (they're system-managed) if "required" in enhanced_schema: core_prop_names = list(core_properties.keys()) enhanced_schema["required"] = [ field for field in enhanced_schema["required"] if field not in core_prop_names ] -
Add logging for debugging (optional but helpful):
if "required" in enhanced_schema and core_prop_names: removed_from_required = [ field for field in enhanced_schema.get("required", []) if field in core_prop_names ] if removed_from_required and plugin_id: self.logger.debug( f"Removed core properties from required array for {plugin_id}: {removed_from_required}" ) -
Test the fix:
- Run audit script:
python scripts/audit_plugin_configs.py - Expected: Issue count drops from 186 to ~30-40
- All "enabled" related errors should be eliminated
- Run audit script:
Expected Outcome
- All 20 plugins should no longer fail validation due to missing
enabledfield - ~150 issues resolved (all enabled-related validation errors)
Priority 2: Verify Default Merging Logic
Problem
Some plugins have required fields with defaults that should be applied before validation. Need to verify the default merging happens correctly and handles nested objects.
Solution
File: web_interface/blueprints/api_v3.py
Location: save_plugin_config() method, around lines 3218-3221
Implementation Steps
-
Review current default merging logic:
- Check that
merge_with_defaults()is called before validation (line 3220) - Verify it's called after preserving enabled state but before validation
- Check that
-
Verify merge_with_defaults handles nested objects:
- Check
src/plugin_system/schema_manager.py→merge_with_defaults()method - Ensure it recursively merges nested objects (it does use deep_merge)
- Test with plugins that have nested required fields
- Check
-
Check if defaults are applied for nested required fields:
- Review how
generate_default_config()extracts defaults from nested schemas - Verify nested required fields with defaults are included
- Review how
-
Test with problematic plugins:
ledmatrix-weather: required fieldsapi_key,location_city(check if defaults exist)mqtt-notifications: required fieldmqttobject (check if default exists)text-display: required fieldtext(check if default exists)ledmatrix-music: required fieldpreferred_source(check if default exists)
-
If defaults don't exist in schemas:
- Either add defaults to schemas, OR
- Make fields optional in schemas if they're truly optional
Expected Outcome
- Plugins with required fields that have schema defaults should pass validation
- Issue count further reduced from ~30-40 to ~5-10
Priority 3: Calendar Plugin Schema Cleanup
Problem
Calendar plugin config has fields not in schema:
show_all_day(config) but schema hasshow_all_day_events(field name mismatch)date_format(not in schema, not used in manager.py)time_format(not in schema, not used in manager.py)
Investigation Results
- Schema defines:
show_all_day_events(boolean, default: true) - Manager.py uses:
show_all_day_events(line 82:config.get('show_all_day_events', True)) - Config has:
show_all_day(wrong field name - should beshow_all_day_events) date_formatandtime_formatappear to be deprecated (not used in manager.py)
Solution
File: config/config.json → calendar section
Implementation Steps
-
Fix field name mismatch:
- Rename
show_all_day→show_all_day_eventsin config.json - This matches the schema and manager.py code
- Rename
-
Remove deprecated fields:
- Remove
date_formatfrom config (not used in code) - Remove
time_formatfrom config (not used in code)
- Remove
-
Alternative (if fields are needed): Add
date_formatandtime_formatto schema- Only if these fields should be supported
- Check if they're used anywhere else in the codebase
-
Test calendar plugin:
- Run audit for calendar plugin specifically
- Verify no extra field warnings remain
- Test calendar plugin functionality to ensure it still works
Expected Outcome
- Calendar plugin shows 0 extra field warnings
- Final issue count: ~3-5 (only edge cases remain)
Testing Strategy
After Each Priority Fix
-
Run local audit:
python scripts/audit_plugin_configs.py -
Check issue count reduction:
- Priority 1: Should drop from 186 to ~30-40
- Priority 2: Should drop from ~30-40 to ~5-10
- Priority 3: Should drop from ~5-10 to ~3-5
-
Review specific plugin results:
python scripts/audit_plugin_configs.py --plugin <plugin-id>
After All Fixes
-
Full audit run:
python scripts/audit_plugin_configs.py -
Deploy to Pi:
./scripts/deploy_to_pi.sh src/plugin_system/schema_manager.py web_interface/blueprints/api_v3.py -
Run audit on Pi:
./scripts/run_audit_on_pi.sh -
Manual web interface testing:
- Access each problematic plugin's config page
- Try saving configuration
- Verify no validation errors appear
- Check that configs save successfully
Success Criteria
- Priority 1: All "enabled" related validation errors eliminated
- Priority 1: Issue count reduced from 186 to ~30-40
- Priority 2: Plugins with required fields + defaults pass validation
- Priority 2: Issue count reduced to ~5-10
- Priority 3: Calendar plugin extra field warnings resolved
- Priority 3: Final issue count at ~3-5 (only edge cases)
- All fixes work on Pi (not just local)
- Web interface saves configs without validation errors
Files to Modify
src/plugin_system/schema_manager.py- Remove core properties from required arrayplugins/calendar/config_schema.jsonORconfig/config.json- Calendar cleanup (if needed)web_interface/blueprints/api_v3.py- May need minor adjustments for default merging (if needed)
Risk Assessment
Priority 1: Low risk - Only affects validation logic, doesn't change behavior Priority 2: Low risk - Only ensures defaults are applied (already intended behavior) Priority 3: Very low risk - Only affects calendar plugin, cosmetic issue
All changes are backward compatible and improve the system rather than changing core functionality.