docs: refresh and correct stale documentation across repo (#306)

* docs: refresh and correct stale documentation across repo

Walked the README and docs/ tree against current code and fixed several
real bugs and many stale references. Highlights:

User-facing
- README.md: web interface install instructions referenced
  install_web_service.sh at the repo root, but it actually lives at
  scripts/install/install_web_service.sh.
- docs/GETTING_STARTED.md: every web UI port reference said 5050, but
  the real server in web_interface/start.py:123 binds 5000. Same bug
  was duplicated in docs/TROUBLESHOOTING.md (17 occurrences). Fixed
  both.
- docs/GETTING_STARTED.md: rewrote tab-by-tab instructions. The doc
  referenced "Plugin Store", "Plugin Management", "Sports Configuration",
  "Durations", and "Font Management" tabs - none of which exist. Real
  tabs (verified in web_interface/templates/v3/base.html) are: Overview,
  General, WiFi, Schedule, Display, Config Editor, Fonts, Logs, Cache,
  Operation History, Plugin Manager (+ per-plugin tabs).
- docs/GETTING_STARTED.md: removed references to a "Test Display"
  button (doesn't exist) and "Show Now" / "Stop" plugin buttons. Real
  controls are "Run On-Demand" / "Stop On-Demand" inside each plugin's
  tab (partials/plugin_config.html:792).
- docs/TROUBLESHOOTING.md: removed dead reference to
  troubleshoot_weather.sh (doesn't exist anywhere in the repo); weather
  is now a plugin in ledmatrix-plugins.

Developer-facing
- docs/PLUGIN_API_REFERENCE.md: documented draw_image() doesn't exist
  on DisplayManager. Real plugins paste onto display_manager.image
  directly (verified in src/base_classes/{baseball,basketball,football,
  hockey}.py). Replaced with the canonical pattern.
- docs/PLUGIN_API_REFERENCE.md: documented cache_manager.delete() doesn't
  exist. Real method is clear_cache(key=None). Updated the section.
- docs/PLUGIN_API_REFERENCE.md: added 10 missing BasePlugin methods that
  the doc never mentioned: dynamic-duration hooks, live-priority hooks,
  and the full Vegas-mode interface.
- docs/PLUGIN_DEVELOPMENT_GUIDE.md: same draw_image fix.
- docs/DEVELOPMENT.md: corrected the "Plugin Submodules" section. Plugins
  are NOT git submodules - .gitmodules only contains
  rpi-rgb-led-matrix-master. Plugins are installed at runtime into the
  plugins directory configured by plugin_system.plugins_directory
  (default plugin-repos/). Both internal links in this doc were also
  broken (missing relative path adjustment).
- docs/HOW_TO_RUN_TESTS.md: removed pytest-timeout from install line
  (not in requirements.txt) and corrected the test/integration/ path
  (real integration tests are at test/web_interface/integration/).
  Replaced the fictional file structure diagram with the real one.
- docs/EMULATOR_SETUP_GUIDE.md: clone URL was a placeholder; default
  pixel_size was documented as 16 but emulator_config.json ships with 5.

Index
- docs/README.md: rewrote. Old index claimed "16-17 files after
  consolidation" but docs/ actually has 38 .md files. Four were missing
  from the index entirely (CONFIG_DEBUGGING, DEV_PREVIEW,
  PLUGIN_ERROR_HANDLING, STARLARK_APPS_GUIDE). Trimmed the navel-gazing
  consolidation/statistics sections.

Out of scope but worth flagging:
- src/plugin_system/resource_monitor.py:343 and src/common/api_helper.py:287
  call cache_manager.delete(key) but no such method exists on
  CacheManager. Both call sites would AttributeError at runtime if hit.
  Not fixed in this docs PR - either add a delete() shim or convert
  callers to clear_cache().

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix WEB_INTERFACE_GUIDE and WIFI_NETWORK_SETUP

WEB_INTERFACE_GUIDE.md
- Web UI port: 5050 -> 5000 (4 occurrences)
- Tab list was almost entirely fictional. Documented tabs:
  General Settings, Display Settings, Durations, Sports Configuration,
  Plugin Management, Plugin Store, Font Management. None of these
  exist. Real tabs (verified in web_interface/templates/v3/base.html:
  935-1000): Overview, General, WiFi, Schedule, Display, Config Editor,
  Fonts, Logs, Cache, Operation History, plus Plugin Manager and
  per-plugin tabs in the second nav row. Rewrote the navigation
  section, the General/Display/Plugin sections, and the Common Tasks
  walkthroughs to match.
- Quick Actions list referenced "Test Display" button (doesn't exist).
  Replaced with the real button list verified in
  partials/overview.html:88-152: Start/Stop Display, Restart Display
  Service, Restart Web Service, Update Code, Reboot, Shutdown.
- API endpoints used /api/* paths. The api_v3 blueprint mounts at
  /api/v3 (web_interface/app.py:144), so the real paths are
  /api/v3/config/main, /api/v3/system/status, etc. Fixed.
- Removed bogus "Sports Configuration tab" walkthrough; sports
  favorites live inside each scoreboard plugin's own tab now.
- Plugin directory listed as /plugins/. Real default is plugin-repos/
  (verified in config/config.template.json:130 and
  display_controller.py:132); plugins/ is a fallback.
- Removed "Swipe navigation between tabs" mobile claim (not implemented).

WIFI_NETWORK_SETUP.md
- 21 occurrences of port 5050 -> 5000.
- All /api/wifi/* curl examples used the wrong path. The real wifi
  API routes are at /api/v3/wifi/* (api_v3.py:6367-6609). Fixed.
- ap_password default was documented as "" (empty/open network) but
  config/wifi_config.json ships with "ledmatrix123". Updated the
  Quick Start, Configuration table, AP Mode Settings section, and
  Security Recommendations to match. Also clarified that setting
  ap_password to "" is the way to make it an open network.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix ADVANCED_FEATURES and REST_API_REFERENCE

REST_API_REFERENCE.md
- Wrong path: /fonts/delete/<font_family> -> /fonts/<font_family>
  (verified the real DELETE route in
  web_interface/blueprints/api_v3.py).
- Diffed the documented routes against the real api_v3 blueprint
  (92 routes vs the 71 documented). Added missing sections:
  - Error tracking (/errors/summary, /errors/plugin/<id>, /errors/clear)
  - Health (/health)
  - Schedule dim/power (/config/dim-schedule GET/POST)
  - Plugin-specific endpoints (calendar/list-calendars,
    of-the-day/json/upload+delete, plugins/<id>/static/<path>)
  - Starlark Apps (12 endpoints: status, install-pixlet, apps CRUD,
    repository browse/install, upload)
  - Font preview (/fonts/preview)
- Updated table of contents with the new sections.
- Added a footer note that the API blueprint mounts at /api/v3
  (app.py:144) and that SSE stream endpoints are defined directly on
  the Flask app at app.py:607-615.

ADVANCED_FEATURES.md
- Vegas Scroll Mode section was actually accurate (verified all
  config keys match src/vegas_mode/config.py:15-30).

- On-Demand Display section had multiple bugs:
  - 5 occurrences of port 5050 -> 5000
  - All API paths missing /v3 (e.g. /api/display/on-demand/start
    should be /api/v3/display/on-demand/start)
  - "Settings -> Plugin Management -> Show Now Button" UI flow doesn't
    exist. Real flow: open the plugin's tab in the second nav row,
    click Run On-Demand / Stop On-Demand.
  - "Python API Methods" section showed
    controller.show_on_demand() / clear_on_demand() /
    is_on_demand_active() / get_on_demand_info() — none of these
    methods exist on DisplayController. The on-demand machinery is
    all internal (_set_on_demand_*, _activate_on_demand, etc) and
    is driven through the cache_manager. Replaced the section with
    a note pointing to the REST API.
  - All Use Case Examples used the same fictional Python calls.
    Replaced with curl examples against the real API.

- Cache Management section claimed "On-demand display uses Redis cache
  keys". LEDMatrix doesn't use Redis — verified with grep that
  src/cache_manager.py has no redis import. The cache is file-based,
  managed by CacheManager (file at /var/cache/ledmatrix/ or fallback
  paths). Rewrote the manual recovery section:
  - Removed redis-cli commands
  - Replaced cache.delete() Python calls with cache.clear_cache()
    (the real public method per the same bug already flagged in
    PLUGIN_API_REFERENCE.md)
  - Replaced "Settings -> Cache Management" with the real Cache tab
  - Documented the actual cache directory candidates

- Background Data Service section:
  - Used "nfl_scoreboard" as the plugin id in the example.
    The real plugin is "football-scoreboard" (handles both NFL and
    NCAA). Fixed.
  - "Implementation Status: Phase 1 NFL only / Phase 2 planned"
    section was severely outdated. The background service is now
    used by all sports scoreboards (football, hockey, baseball,
    basketball, soccer, lacrosse, F1, UFC), the odds ticker, and
    the leaderboard plugin. Replaced with a current "Plugins using
    the background service" note.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix plugin config + store + dependency docs

PLUGIN_STORE_GUIDE.md
- 19 occurrences of port 5050 -> 5000
- All API paths missing /v3 (e.g. /api/plugins/install ->
  /api/v3/plugins/install). Bulk fix.

PLUGIN_REGISTRY_SETUP_GUIDE.md
- Same port + /api/v3 fixes (3 occurrences each)
- "Go to Plugin Store tab" -> "Open the Plugin Manager tab and scroll
  to the Install from GitHub section" (the real flow for registry
  setup is the GitHub install section, not the Plugin Store search)

PLUGIN_CONFIG_QUICK_START.md
- Port 5001 -> 5000 (5001 is the dev_server.py default, not the web UI)
- "Plugin Store tab" install flow -> real Plugin Manager + Plugin Store
  section + per-plugin tab in second nav row
- Removed reference to PLUGIN_CONFIG_TABS_SUMMARY.md (archived doc)

PLUGIN_CONFIGURATION_TABS.md
- "Plugin Management vs Configuration" section confusingly described
  a "Plugins Tab" that doesn't exist as a single thing. Rewrote to
  describe the real two-piece structure: Plugin Manager tab (browse,
  install, toggle) vs per-plugin tabs (configure individual plugins).

PLUGIN_DEPENDENCY_GUIDE.md
- Port 5001 -> 5000

PLUGIN_DEPENDENCY_TROUBLESHOOTING.md
- Wrong port (8080) and wrong UI nav ("Plugin Store or Plugin
  Management"). Fixed to the real flow.

PLUGIN_QUICK_REFERENCE.md
- "Plugin Location: ./plugins/ directory" -> default is plugin-repos/
  (verified in config/config.template.json:130 and
  display_controller.py:132). plugins/ is a fallback.
- File structure diagram showed plugins/ -> plugin-repos/.
- Web UI install flow: "Plugin Store tab" -> "Plugin Manager tab ->
  Plugin Store section". Also fixed Configure ⚙️ button (doesn't
  exist) and "Drag and drop reorder" (not implemented).
- API examples: replaced ad-hoc Python pseudocode with real curl
  examples against /api/v3/plugins/* endpoints. Pointed at
  REST_API_REFERENCE.md for the full list.
- "Migration Path Phase 1-5" was a roadmap written before the plugin
  system shipped. The plugin system is now stable and live. Removed
  the migration phases as they're history, not a roadmap.
- "Quick Migration" section called scripts/migrate_to_plugins.py
  which doesn't exist anywhere in the repo. Removed.
- "Plugin Registry Structure" referenced
  ChuckBuilds/ledmatrix-plugin-registry which doesn't exist. The
  real registry is ChuckBuilds/ledmatrix-plugins. Fixed.
- "Next Steps" / "Questions to Resolve" sections were
  pre-implementation planning notes. Replaced with a "Known
  Limitations" section that documents the actually-real gaps
  (sandboxing, resource limits, ratings, auto-updates).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix misc remaining docs (architecture, dev quickref, sub-dir READMEs)

PLUGIN_ARCHITECTURE_SPEC.md
- Added a banner at the top noting this is a historical design doc
  written before the plugin system shipped. The doc is ~1900 lines
  with 13 stale /api/plugins/* paths (real is /api/v3/plugins/*),
  references to web_interface_v2.py (current is app.py), and a
  Migration Strategy / Implementation Roadmap that's now history.
  Banner points readers at the current docs
  (PLUGIN_DEVELOPMENT_GUIDE, PLUGIN_API_REFERENCE,
  REST_API_REFERENCE) without needing to retrofit every section.

PLUGIN_CONFIG_ARCHITECTURE.md
- 10 occurrences of /api/plugins/* missing /v3 prefix. Bulk fixed.

DEVELOPER_QUICK_REFERENCE.md
- cache_manager.delete("key") -> cache_manager.clear_cache("key")
  with comment noting delete() doesn't exist. Same bug already
  documented in PLUGIN_API_REFERENCE.md.

SSH_UNAVAILABLE_AFTER_INSTALL.md
- 4 occurrences of port 5001 -> 5000 in AP-mode and Ethernet/WiFi
  recovery instructions.

PLUGIN_CUSTOM_ICONS_FEATURE.md
- Port 5001 -> 5000.

CONFIG_DEBUGGING.md
- Documented /api/v3/config/plugin/<id> and /api/v3/config/validate
  endpoints don't exist. Replaced with the real endpoints:
  /api/v3/config/main, /api/v3/plugins/schema?plugin_id=,
  /api/v3/plugins/config?plugin_id=. Added a note that validation
  runs server-side automatically on POST.

STARLARK_APPS_GUIDE.md
- "Plugins -> Starlark Apps" UI navigation path doesn't exist (5
  occurrences). Replaced with the real path: Plugin Manager tab,
  then the per-plugin Starlark Apps tab in the second nav row.
- "Navigate to Plugins" install step -> Plugin Manager tab.

web_interface/README.md
- Documented several endpoints that don't exist in the api_v3
  blueprint:
  - GET /api/v3/plugins (list) -> /api/v3/plugins/installed
  - GET /api/v3/plugins/<id> -> doesn't exist
  - POST /api/v3/plugins/<id>/config -> POST /api/v3/plugins/config
  - GET /api/v3/plugins/<id>/enable + /disable -> POST /api/v3/plugins/toggle
  - GET /api/v3/store/plugins -> /api/v3/plugins/store/list
  - POST /api/v3/store/install/<id> -> POST /api/v3/plugins/install
  - POST /api/v3/store/uninstall/<id> -> POST /api/v3/plugins/uninstall
  - POST /api/v3/store/update/<id> -> POST /api/v3/plugins/update
  - POST /api/v3/display/start/stop/restart -> POST /api/v3/system/action
  - GET /api/v3/display/status -> GET /api/v3/system/status
- Also fixed config/secrets.json -> config/config_secrets.json
- Replaced the per-section endpoint duplication with a current real
  endpoint list and a pointer to docs/REST_API_REFERENCE.md.
- Documented that SSE stream endpoints are defined directly on the
  Flask app at app.py:607-615, not in the api_v3 blueprint.

scripts/install/README.md
- Was missing 3 of the 9 install scripts in the directory:
  one-shot-install.sh, configure_wifi_permissions.sh, and
  debug_install.sh. Added them with brief descriptions.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: clarify plugin paths and fix systemd manual install bug

PLUGIN_DEVELOPMENT_GUIDE.md
- Added a "Plugin directory note" callout near the top explaining
  the plugins/ vs plugin-repos/ split:
  - Dev workflow uses plugins/ (where dev_plugin_setup.sh creates
    symlinks)
  - Production / Plugin Store uses plugin-repos/ (the configurable
    default per config.template.json:130)
  - The plugin loader falls back to plugins/ so dev symlinks are
    picked up automatically (schema_manager.py:77)
  - User can set plugins_directory to "plugins" in the General tab
    if they want both to share a directory

CLAUDE.md
- The Project Structure section had plugins/ and plugin-repos/
  exactly reversed:
  - Old: "plugins/ - Installed plugins directory (gitignored)"
         "plugin-repos/ - Development symlinks to monorepo plugin dirs"
  - Real: plugin-repos/ is the canonical Plugin Store install
    location and is not gitignored. plugins/* IS gitignored
    (verified in .gitignore) and is the legacy/dev location used by
    scripts/dev/dev_plugin_setup.sh.
  Reversed the descriptions and added line refs.

systemd/README.md
- "Manual Installation" section told users to copy the unit file
  directly to /etc/systemd/system/. Verified the unit file in
  systemd/ledmatrix.service contains __PROJECT_ROOT_DIR__
  placeholders that the install scripts substitute at install time.
  A user following the manual steps would get a service that fails
  to start with "WorkingDirectory=__PROJECT_ROOT_DIR__" errors.
  Added a clear warning and a sed snippet that substitutes the
  placeholder before installing.

src/common/README.md
- Was missing 2 of the 11 utility modules in the directory
  (verified with ls): permission_utils.py and cli.py. Added brief
  descriptions for both.

Out-of-scope code bug found while auditing (flagged but not fixed):
- scripts/dev/dev_plugin_setup.sh:9 sets PROJECT_ROOT="$SCRIPT_DIR"
  which resolves to scripts/dev/, not the project root. This means
  the script's PLUGINS_DIR resolves to scripts/dev/plugins/ instead
  of the project's plugins/ — confirmed by the existence of
  scripts/dev/plugins/of-the-day/ from prior runs. Real fix is to
  set PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)". Not fixing in
  this docs PR.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: flag aspirational/regressed features in plugin docs

These docs describe features that exist as documented in the doc but
either never wired up or regressed when v3 shipped. Each gets a clear
status banner so plugin authors don't waste time chasing features that
don't actually work.

FONT_MANAGER.md
- The "For Plugin Developers / Plugin Font Registration" section
  documents adding a "fonts" block to manifest.json that gets
  registered via FontManager.register_plugin_fonts(). The method
  exists at src/font_manager.py:150 but is **never called from
  anywhere** in the codebase (verified: zero callers). A plugin
  shipping a manifest "fonts" block has its fonts silently ignored.
  Added a status warning and a note about how to actually ship plugin
  fonts (regular files in the plugin dir, loaded directly).

PLUGIN_IMPLEMENTATION_SUMMARY.md
- Added a top-level status banner.
- Architecture diagram referenced src/plugin_system/registry_manager.py
  (which doesn't exist) and listed plugins/ as the install location.
  Replaced with the real file list (plugin_loader, schema_manager,
  health_monitor, operation_queue, state_manager) and pointed at
  plugin-repos/ as the default install location.
- "Dependency Management: Virtual Environments" — verified there's no
  per-plugin venv. Removed the bullet and added a note that plugin
  Python deps install into the system Python environment, with no
  conflict resolution.
- "Permission System: File Access Control / Network Access /
  Resource Limits / CPU and memory constraints" — none of these
  exist. There's a resource_monitor.py and health_monitor.py for
  metrics/warnings, but no hard caps or sandboxing. Replaced the
  section with what's actually implemented and a clear note that
  plugins run in the same process with full file/network access.

PLUGIN_CUSTOM_ICONS.md and PLUGIN_CUSTOM_ICONS_FEATURE.md
- The custom-icon feature was implemented in the v2 web interface
  via a getPluginIcon() helper in templates/index_v2.html that read
  the manifest "icon" field. When the v3 web interface was built,
  that helper wasn't ported. Verified in
  web_interface/templates/v3/base.html:515 and :774, plugin tab
  icons are hardcoded to `fas fa-puzzle-piece`. The "icon" field in
  plugin manifests is currently silently ignored (verified with grep
  across web_interface/ and src/plugin_system/ — zero non-action-
  related reads of plugin.icon or manifest.icon).
- Added a status banner to both docs noting the regression so plugin
  authors don't think their custom icons are broken in their own
  plugin code.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix .cursor/ helper docs

The .cursor/ directory holds the dev-side helper docs that Cursor and
contributors using AI tooling rely on to bootstrap plugin development.
Several of them had the same bug patterns as the user-facing docs.

.cursor/plugin_templates/QUICK_START.md
- "Adding Image Rendering" section showed
  display_manager.draw_image(image, x=0, y=0). That method doesn't
  exist on DisplayManager (same bug as PLUGIN_API_REFERENCE.md and
  PLUGIN_DEVELOPMENT_GUIDE.md). Replaced with the canonical
  display_manager.image.paste((x,y)) pattern, including the
  transparency-mask form.

.cursor/plugins_guide.md
- 10 occurrences of ./dev_plugin_setup.sh — the script lives at
  scripts/dev/dev_plugin_setup.sh, so anyone copy-pasting these
  examples gets "command not found". Bulk fixed via sed.
- "Test with emulator: python run.py --emulator" — there's no
  --emulator flag. Replaced with the real options:
  EMULATOR=true python3 run.py for the full display, or
  scripts/dev_server.py for the dev preview.
- Secrets management section showed a fictional
  "config_secrets": { "api_key": "my-plugin.api_key" } reference
  field. Verified in src/config_manager.py:162-172 that secrets are
  loaded by deep-merging config_secrets.json into the main config.
  There is no separate reference field — just put the secret under
  the same plugin namespace and read it from the merged config.
  Rewrote the section with the real pattern.
- "ssh pi@raspberrypi" -> "ssh ledpi@your-pi-ip" (consistent with
  the rest of LEDMatrix docs which use ledpi as the default user)

.cursor/README.md
- Same ./dev_plugin_setup.sh -> ./scripts/dev/dev_plugin_setup.sh
  fix (×6 occurrences via replace_all).
- Same "python run.py --emulator" -> "EMULATOR=true python3 run.py"
  fix. Also added a pointer to scripts/dev_server.py for previewing
  plugins without running the full display.
- "Example Plugins: plugins/hockey-scoreboard/" — the canonical
  source is the ledmatrix-plugins repo. Installed copies land in
  plugin-repos/ or plugins/. Updated the line to point at the
  ledmatrix-plugins repo and explain both local locations.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix .cursorrules — the file Cursor auto-loads to learn the API

This is the file that Cursor reads to learn how plugin development
works. Stale entries here directly mislead AI-assisted plugin authors
on every new plugin. Several of the same bug patterns I've been
fixing in the user-facing docs were here too.

Display Manager section (highest impact)
- "draw_image(image, x, y): Draw PIL Image" — that method doesn't
  exist on DisplayManager. Same bug already fixed in
  PLUGIN_API_REFERENCE.md, PLUGIN_DEVELOPMENT_GUIDE.md,
  ledmatrix-stocks/README.md, and .cursor/plugin_templates/QUICK_START.md.
  Removed the bullet and replaced it with a paragraph explaining the
  real pattern: paste onto display_manager.image directly, then
  update_display(). Includes the transparency-mask form.
- Added the small_font/centered args to draw_text() since they're
  the ones that matter most for new plugin authors
- Added draw_weather_icon since it's commonly used

Cache Manager section
- "delete(key): Remove cached value" — there's no delete() method
  on CacheManager. The real method is clear_cache(key=None) (also
  removes everything when called without args). Same bug as before.
- Added get_cached_data_with_strategy and get_background_cached_data
  since contributors will hit these when working on sports plugins

Plugin System Overview
- "loaded from the plugins/ directory" — clarified that the default
  is plugin-repos/ (per config.template.json:130) with plugins/ as
  the dev fallback used by scripts/dev/dev_plugin_setup.sh

Plugin Development Workflow
- ./dev_plugin_setup.sh -> ./scripts/dev/dev_plugin_setup.sh (×2)
- Manual setup step "Create directory in plugins/<plugin-id>/" ->
  plugin-repos/<plugin-id>/ as the canonical location
- "Use emulator: python run.py --emulator or ./run_emulator.sh"
  — the --emulator flag doesn't exist; ./run_emulator.sh isn't at
  root (it lives at scripts/dev/run_emulator.sh). Replaced with the
  real options: scripts/dev_server.py for dev preview, or
  EMULATOR=true python3 run.py for the full emulator path.

Configuration Management
- "Reference secrets via config_secrets key in main config" — this
  is the same fictional reference syntax I just fixed in
  .cursor/plugins_guide.md. Verified in src/config_manager.py:162-172
  that secrets are deep-merged into the main config; there's no
  separate reference field. Replaced with a clear explanation of
  the deep-merge approach.

Code Organization
- "plugins/<plugin-id>/" -> the canonical location is
  plugin-repos/<plugin-id>/ (or its dev-time symlink in plugins/)
- "see plugins/hockey-scoreboard/ as reference" — the canonical
  source for example plugins is the ledmatrix-plugins repo. Updated
  the pointer.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Add LICENSE (GPL-3.0) and CONTRIBUTING.md

LICENSE
- The repository previously had no LICENSE file. The README and every
  downstream plugin README already reference GPL-3.0 ("same as
  LEDMatrix project"), but the canonical license text was missing —
  contributors had no formal record of what they were contributing
  under, and GitHub couldn't auto-detect the license for the repo
  banner.
- Added the canonical GPL-3.0 text from
  https://www.gnu.org/licenses/gpl-3.0.txt (verbatim, 674 lines).
- Compatibility verified: rpi-rgb-led-matrix is GPL-2.0-or-later
  (per its COPYING file and README; the "or any later version" clause
  in lib/*.h headers makes GPL-3.0 distribution legal).

CONTRIBUTING.md
- The repository had no CONTRIBUTING file. New contributors had to
  reconstruct the dev setup from DEVELOPMENT.md, PLUGIN_DEVELOPMENT_GUIDE.md,
  SUBMISSION.md, and the root README.
- Added a single page covering: dev environment setup (preview
  server, emulator, hardware), running tests, PR submission flow,
  commit message convention, plugin contribution pointer, and the
  license terms contributors are agreeing to.

> Note for the maintainer: I (the AI assistant doing this audit) am
> selecting GPL-3.0 because every reference in the existing
> documentation already says GPL-3.0 — this commit just makes that
> declaration legally binding by adding the actual file. Please
> confirm during PR review that GPL-3.0 is what you want; if you
> prefer a different license, revert this commit before merging.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Add CODE_OF_CONDUCT, SECURITY, PR template; link them from README

Tier 1 organizational files that any open-source project at
LEDMatrix's maturity is expected to have. None of these existed
before. They're additive — no existing content was rewritten.

CODE_OF_CONDUCT.md
- Contributor Covenant 2.1 (the de facto standard for open-source
  projects). Mentions both the Discord and the GitHub Security
  Advisories channel for reporting violations.

SECURITY.md
- Private vulnerability disclosure flow with two channels: GitHub
  Security Advisories (preferred) and Discord DM.
- Documents the project's known security model as intentional
  rather than vulnerabilities: no web UI auth, plugins run
  unsandboxed, display service runs as root for GPIO access,
  config_secrets.json is plaintext. These match the limitations
  already called out in PLUGIN_QUICK_REFERENCE.md and the audit
  flagging from earlier in this PR.
- Out-of-scope section points users at upstream
  (rpi-rgb-led-matrix, third-party plugins) so reports land in the
  right place.

.github/PULL_REQUEST_TEMPLATE.md
- 10-line checklist that prompts for the things that would have
  caught the bugs in this very PR: did you load the changed plugin
  once, did you update docs alongside code, are there any plugin
  compatibility implications.
- Linked from CONTRIBUTING.md for the full flow.

README.md
- Added a License section near the bottom (the README previously
  said nothing about the license despite the project being GPL-3.0).
- Added a Contributing section pointing at CONTRIBUTING.md and
  SECURITY.md.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* Customize bug report template for LEDMatrix hardware

The bug_report.md template was the GitHub default and asked
"Desktop (OS/Browser/Version)" and "Smartphone (Device/OS)" — neither
of which is relevant for a project that runs on a Raspberry Pi with
hardware LED panels. A user filing a bug under the old template was
giving us none of the information we'd actually need to triage it.

Replaced with a LEDMatrix-aware template that prompts for:
- Pi model, OS/kernel, panel type, HAT/Bonnet, PWM jumper status,
  display chain dimensions
- LEDMatrix git commit / release tag
- Plugin id and version (if the bug is plugin-related)
- Relevant config snippet (with redaction reminder for API keys)
- journalctl log excerpt with the exact command to capture it
- Optional photo of the actual display for visual issues

Kept feature_request.md as-is — generic content there is fine.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix bare /api/plugins paths in PLUGIN_CONFIGURATION_TABS

Found 5 more bare /api/plugins/* paths in PLUGIN_CONFIGURATION_TABS.md
that I missed in the round 2 sweep — they're inside data flow diagrams
and prose ("loaded via /api/plugins/installed", etc.) so the earlier
grep over Markdown code blocks didn't catch them. Fixed all 5 to use
/api/v3/plugins/* (the api_v3 blueprint mount path verified at
web_interface/app.py:144).

Also added a status banner noting that the "Implementation Details"
section references the pre-v3 file layout (web_interface_v2.py,
templates/index_v2.html) which no longer exists. The current
implementation is in web_interface/app.py, blueprints/api_v3.py, and
templates/v3/. Same kind of historical drift I flagged in
PLUGIN_ARCHITECTURE_SPEC.md and the PLUGIN_CUSTOM_ICONS_FEATURE doc.
The user-facing parts of the doc (Overview, Features, Form Generation
Process) are still accurate.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs(widgets): list the 20 undocumented built-in widgets

The widget registry README documented 3 widgets (file-upload,
checkbox-group, custom-feeds) but the directory contains 23 registered
widgets total. A plugin author reading this doc would think those 3
were the only built-in options and either reach for a custom widget
unnecessarily or settle for a generic text input.

Verified the actual list with:
  grep -h "register('" web_interface/static/v3/js/widgets/*.js \
    | sed -E "s|.*register\\('([^']+)'.*|\\1|" | sort -u

Added an "Other Built-in Widgets" section after the 3 detailed
sections, listing the remaining 20 with one-line descriptions
organized by category:
- Inputs (6): text-input, textarea, number-input, email-input,
  url-input, password-input
- Selectors (7): select-dropdown, radio-group, toggle-switch,
  slider, color-picker, font-selector, timezone-selector
- Date/time/scheduling (4): date-picker, day-selector, time-range,
  schedule-picker
- Composite/data-source (2): array-table, google-calendar-picker
- Internal (2): notification, base-widget

Pointed at the .js source files as the canonical source for each
widget's exact schema and options — keeps this list low-maintenance
since I'm not duplicating each widget's full options table.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix README_NBA_LOGOS and PLUGIN_CONFIGURATION_GUIDE

scripts/README_NBA_LOGOS.md
- "python download_nba_logos.py" — wrong on two counts. The script
  is at scripts/download_nba_logos.py (not the project root), and
  "python" is Python 2 on most systems. Replaced all 4 occurrences
  with "python3 scripts/download_nba_logos.py".
- The doc framed itself as the way to set up "the NBA leaderboard".
  The basketball/leaderboard functionality is now in the
  basketball-scoreboard and ledmatrix-leaderboard plugins (in the
  ledmatrix-plugins repo), which auto-download logos on first run.
  Reframed the script as a pre-population utility for offline / dev
  use cases.
- Bumped the documented Python minimum from 3.7 to 3.9 to match
  the rest of the project.

docs/PLUGIN_CONFIGURATION_GUIDE.md
- The "Plugin Manifest" example was missing 3 fields the plugin
  loader actually requires: id, entry_point, and class_name. A
  contributor copying this manifest verbatim would get
  PluginError("No class_name in manifest") at load time — the same
  loader bug already found in stock-news. Added all three.
- The same example showed config_schema as an inline object. The
  loader expects config_schema to be a file path string (e.g.
  "config_schema.json") with the actual schema in a separate JSON
  file — verified earlier in this audit. Fixed.
- Added a paragraph explaining the loader's required fields and
  the case-sensitivity rule on class_name (the bug that broke
  hello-world's manifest before this PR fixed it).
- "Plugin Manager Class" example had the wrong constructor
  signature: (config, display_manager, cache_manager, font_manager).
  The real BasePlugin.__init__ at base_plugin.py:53-60 takes
  (plugin_id, config, display_manager, cache_manager, plugin_manager).
  A copy-pasted example would TypeError on instantiation. Fixed,
  including a comment noting which attributes BasePlugin sets up.
- Renamed the example class from MyPluginManager to MyPlugin to
  match the project convention (XxxPlugin / XxxScoreboardPlugin
  in actual plugins).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs(requirements): document optional dependencies (scipy, psutil, Flask-Limiter)

A doc-vs-code crosscheck of every Python import in src/ and
web_interface/ against requirements.txt found 3 packages that the
code uses but requirements.txt doesn't list. Verified with grep that
all 3 are wrapped in try/except blocks with documented fallback
paths, so they're optional features rather than missing required
deps:

- scipy           src/common/scroll_helper.py:26
                  → from scipy.ndimage import shift; HAS_SCIPY flag.
                  Used for sub-pixel interpolation in scrolling.
                  Falls back to a simpler shift algorithm without it.

- psutil          src/plugin_system/resource_monitor.py:15
                  → import psutil; PSUTIL_AVAILABLE flag. Used for
                  per-plugin CPU/memory monitoring. Silently no-ops
                  without it.

- flask-limiter   web_interface/app.py:42-43
                  → from flask_limiter import Limiter; wrapped at the
                  caller. Used for accidental-abuse rate limiting on
                  the web interface (not security). Web interface
                  starts without rate limiting when missing.

These were latent in two ways:
1. A user reading requirements.txt thinks they have the full feature
   set after `pip install -r requirements.txt`, but they don't get
   smoother scrolling, plugin resource monitoring, or rate limiting.
2. A contributor who deletes one of the packages from their dev env
   wouldn't know which feature they just lost — the fallbacks are
   silent.

Added an "Optional dependencies" section at the bottom of
requirements.txt with the version constraint, the file:line where
each is used, the feature it enables, and the install command. The
comment-only format means `pip install -r requirements.txt` still
gives the minimal-feature install (preserving current behavior),
while users who want the full feature set can copy the explicit
pip install commands.

Other findings from the same scan that came back as false positives
or known issues:
- web_interface_v2: dead pattern flagged in earlier iteration
  (still no real implementation; affects 11+ plugins via the same
  try/except dead-fallback pattern)
- urllib3: comes with `requests` transitively
- All 'src.', 'web_interface.', 'rgbmatrix', 'RGBMatrixEmulator'
  imports: internal modules
- base_plugin / plugin_manager / store_manager / mocks /
  visual_display_manager: relative imports to local modules
- freetype: false positive (freetype-py is in requirements.txt
  under the package name)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: fix broken file references found by path-existence crosscheck

Ran a doc-vs-filesystem crosscheck: extracted every backtick-quoted
path with a file extension or known directory prefix from docs/*.md
and verified each exists. After filtering false positives
(placeholder paths, config keys mistaken for paths, paths inside
docs that already have historical-status banners), found 4 real
broken references — 3 fixed in docs, 1 fixed by creating the missing
file:

docs/HOW_TO_RUN_TESTS.md:339
- Claimed ".github/workflows/tests.yml" exists and runs pytest on
  multiple Python versions in CI. There is no such workflow.
  The only GitHub Actions file is security-audit.yml (bandit + semgrep).
- Pytest runs locally but is NOT gated on PRs.
- Replaced the fictional CI section with the actual state and a
  note explaining how someone could contribute a real test workflow.

docs/MIGRATION_GUIDE.md:92
- Referenced scripts/fix_perms/README.md "(if exists)" — the
  hedge betrays that the writer wasn't sure. The README didn't
  exist. The 6 scripts in scripts/fix_perms/ were never documented.
- Created the missing scripts/fix_perms/README.md from scratch
  with one-line descriptions of all 6 scripts (fix_assets,
  fix_cache, fix_plugin, fix_web, fix_nhl_cache, safe_plugin_rm)
  + when-to-use-each guidance + usage examples.
- Updated MIGRATION_GUIDE link to drop the "(if exists)" hedge
  since the file now exists.

docs/FONT_MANAGER.md:376
- "See test/font_manager_example.py for a complete working example"
  — that file does not exist. Verified by listing test/ directory.
- Replaced with a pointer to src/font_manager.py itself and the
  existing scoreboard base classes in src/base_classes/ that
  actually use the font manager API in production.

Path-existence check methodology:
- Walked docs/ recursively, regex-extracted backtick-quoted paths
  matching either /\.(py|sh|json|yml|yaml|md|txt|service|html|js|css|ttf|bdf|png)/
  or paths starting with known directory prefixes (scripts/, src/,
  config/, web_interface/, systemd/, assets/, docs/, test/, etc.)
- Filtered out URLs, absolute paths (placeholders), and paths
  without slashes (likely not relative refs).
- Checked existence relative to project root.
- Out of 80 unique relative paths in docs/, 32 didn't exist on
  disk. Most were false positives (configkeys mistaken for paths,
  example placeholders like 'assets/myfont.ttf', historical
  references inside docs that already have status banners). The 4
  above were genuine broken refs.

This pattern is reusable for future iterations and worth wiring
into CI (link checker like lychee, scoped to fenced code paths
rather than just markdown links, would catch the same class).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* docs: address CodeRabbit review comments on #306

Reviewed all 12 CodeRabbit comments on PR #306, verified each against
the current code, and fixed the 11 valid ones. The 12th finding is a
real code bug (cache_manager.delete() calls in api_helper.py and
resource_monitor.py) that's already in the planned follow-up code-fix
PR, so it stays out of this docs PR.

Fixed:

.cursor/plugins_guide.md, .cursor/README.md, .cursorrules
- I claimed "there is no --emulator flag" in 3 places. Verified in
  run.py:19-20 that the -e/--emulator flag is defined and functional
  (it sets os.environ["EMULATOR"]="true" before the display imports).
  Other docs I didn't touch (.cursor/plugin_templates/QUICK_START.md,
  docs/PLUGIN_DEVELOPMENT_GUIDE.md) already use the flag correctly.
  Replaced all 3 wrong statements with accurate guidance that
  both forms work and explains the CLI flag's relationship to the
  env var.

.cursorrules, docs/GETTING_STARTED.md, docs/WEB_INTERFACE_GUIDE.md,
docs/PLUGIN_DEVELOPMENT_GUIDE.md
- Four places claimed "the plugin loader also falls back to plugins/".
  Verified that PluginManager.discover_plugins()
  (src/plugin_system/plugin_manager.py:154) only scans the
  configured directory — no fallback. The fallback to plugins/
  exists only in two narrower places: store_manager.py:1700-1718
  (store install/update/uninstall operations) and
  schema_manager.py:70-80 (schema lookup for the web UI form
  generator). Rewrote all four mentions with the precise scope.
  Added a recommendation to set plugin_system.plugins_directory
  to "plugins" for the smoothest dev workflow with
  dev_plugin_setup.sh symlinks.

docs/FONT_MANAGER.md
- The "Status" warning told plugin authors to use
  display_manager.font_manager.resolve_font(...) as a workaround for
  loading plugin fonts. Verified in src/font_manager.py that
  resolve_font() takes a family name, not a file path — so the
  workaround as written doesn't actually work. Rewrote to tell
  authors to load the font directly with PIL or freetype-py in their
  plugin.
- The same section said "the user-facing font override system in the
  Fonts tab still works for any element that's been registered via
  register_manager_font()". Verified in
  web_interface/blueprints/api_v3.py:5404-5428 that
  /api/v3/fonts/overrides is a placeholder implementation that
  returns empty arrays and contains "would integrate with the actual
  font system" comments — the Fonts tab does not have functional
  integration with register_manager_font() or the override system.
  Removed the false claim and added an explicit note that the tab
  is a placeholder.

docs/ADVANCED_FEATURES.md:523
- The on-demand section said REST/UI calls write a request "into the
  cache manager (display_on_demand_config key)". Wrong — verified
  via grep that api_v3.py:1622 and :1687 write to
  display_on_demand_request, and display_on_demand_config is only
  written by the controller during activation
  (display_controller.py:1195, cleared at :1221). Corrected the key
  name and added controller file:line references so future readers
  can verify.

docs/ADVANCED_FEATURES.md:803
- "Plugins using the background service" paragraph listed all
  scoreboard plugins but an orphaned "⏳ MLB (baseball)" bullet
  remained below from the old version of the section. Removed the
  orphan and added "baseball/MLB" to the inline list for clarity.

web_interface/README.md
- The POST /api/v3/system/action action list was incomplete. Verified
  in web_interface/app.py:1383,1386 that enable_autostart and
  disable_autostart are valid actions. Added both.
- The Plugin Store section was missing
  GET /api/v3/plugins/store/github-status (verified at
  api_v3.py:3296). Added it.
- The SSE line-range reference was app.py:607-615 but line 619
  contains the "Exempt SSE streams from CSRF and add rate limiting"
  block that's semantically part of the same feature. Extended the
  range to 607-619.

docs/GETTING_STARTED.md
- Rows/Columns step said "Columns: 64 or 96 (match your hardware)".
  The web UI's validation accepts any integer in 16-128. Clarified
  that 64 and 96 are the common bundled-hardware values but the
  valid range is wider.

Not addressed (out of scope for docs PR):

- .cursorrules:184 CodeRabbit comment flagged the non-existent
  cache_manager.delete() calls in src/common/api_helper.py:287 and
  src/plugin_system/resource_monitor.py:343. These are real CODE
  bugs, not doc bugs, and they're the first item in the planned
  post-docs-refresh code-cleanup PR (see
  /home/chuck/.claude/plans/warm-imagining-river.md). The docs in
  this PR correctly state that delete() doesn't exist on
  CacheManager — the fix belongs in the follow-up code PR that
  either adds a delete() shim or updates the two callers.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Chuck <chuck@example.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.cursor/README.md

@@ -0,0 +1,145 @@
+# Cursor Helper Files for LEDMatrix Plugin Development
+
+This directory contains Cursor-specific helper files to assist with plugin development in the LEDMatrix project.
+
+## Files Overview
+
+### `.cursorrules`
+Comprehensive rules file that Cursor uses to understand plugin development patterns, best practices, and workflows. This file is automatically loaded by Cursor and helps guide AI-assisted development.
+
+### `plugins_guide.md`
+Detailed guide covering:
+- Plugin system overview
+- Creating new plugins
+- Running plugins (emulator and hardware)
+- Loading and configuring plugins
+- Development workflow
+- Testing strategies
+- Troubleshooting
+
+### `plugin_templates/`
+Template files for quick plugin creation:
+- `manifest.json.template` - Plugin metadata template
+- `manager.py.template` - Plugin class template
+- `config_schema.json.template` - Configuration schema template
+- `README.md.template` - Plugin documentation template
+- `requirements.txt.template` - Dependencies template
+- `QUICK_START.md` - Quick start guide for using templates
+
+## Quick Reference
+
+### Creating a New Plugin
+
+1. **Using templates** (recommended):
+```bash
+# See QUICK_START.md in plugin_templates/
+cd plugins
+mkdir my-plugin
+cd my-plugin
+cp ../../.cursor/plugin_templates/*.template .
+# Edit files, replacing PLUGIN_ID and other placeholders
+```
+
+2. **Using dev_plugin_setup.sh**:
+```bash
+# Link from GitHub
+./scripts/dev/dev_plugin_setup.sh link-github my-plugin
+
+# Link local repo
+./scripts/dev/dev_plugin_setup.sh link my-plugin /path/to/repo
+```
+
+### Running the Display
+
+```bash
+# Emulator mode (development, no hardware required)
+python3 run.py --emulator
+# (equivalent: EMULATOR=true python3 run.py)
+
+# Hardware (production, requires the rpi-rgb-led-matrix submodule built)
+python3 run.py
+
+# As a systemd service
+sudo systemctl start ledmatrix
+
+# Dev preview server (renders plugins to a browser without running run.py)
+python3 scripts/dev_server.py  # then open http://localhost:5001
+```
+
+The `-e`/`--emulator` CLI flag is defined in `run.py:19-20` and
+sets `os.environ["EMULATOR"] = "true"` before any display imports,
+which `src/display_manager.py:2` then reads to switch between the
+hardware and emulator backends.
+
+### Managing Plugins
+
+```bash
+# List plugins
+./scripts/dev/dev_plugin_setup.sh list
+
+# Check status
+./scripts/dev/dev_plugin_setup.sh status
+
+# Update plugin(s)
+./scripts/dev/dev_plugin_setup.sh update [plugin-name]
+
+# Unlink plugin
+./scripts/dev/dev_plugin_setup.sh unlink <plugin-name>
+```
+
+## Using These Files with Cursor
+
+### `.cursorrules`
+Cursor automatically reads this file to understand:
+- Plugin structure and requirements
+- Development workflows
+- Best practices
+- Common patterns
+- API reference
+
+When asking Cursor to help with plugins, it will use this context to provide better assistance.
+
+### Plugin Templates
+Use templates when creating new plugins:
+1. Copy templates from `.cursor/plugin_templates/`
+2. Replace placeholders (PLUGIN_ID, PluginClassName, etc.)
+3. Customize for your plugin's needs
+4. Follow the guide in `plugins_guide.md`
+
+### Documentation
+Refer to `plugins_guide.md` for:
+- Detailed explanations
+- Troubleshooting steps
+- Best practices
+- Examples and patterns
+
+## Plugin Development Workflow
+
+1. **Plan**: Determine plugin functionality and requirements
+2. **Create**: Use templates or dev_plugin_setup.sh to create plugin structure
+3. **Develop**: Implement plugin logic following BasePlugin interface
+4. **Test**: Test with emulator first, then on hardware
+5. **Configure**: Add plugin config to config/config.json
+6. **Iterate**: Refine based on testing and feedback
+
+## Resources
+
+- **Plugin System**: `src/plugin_system/`
+- **Base Plugin**: `src/plugin_system/base_plugin.py`
+- **Plugin Manager**: `src/plugin_system/plugin_manager.py`
+- **Example Plugins**: see the
+  [`ledmatrix-plugins`](https://github.com/ChuckBuilds/ledmatrix-plugins)
+  repo for canonical sources (e.g. `plugins/hockey-scoreboard/`,
+  `plugins/football-scoreboard/`). Installed plugins land in
+  `plugin-repos/` (default) or `plugins/` (dev fallback).
+- **Architecture Docs**: `docs/PLUGIN_ARCHITECTURE_SPEC.md`
+- **Development Setup**: `scripts/dev/dev_plugin_setup.sh`
+
+## Getting Help
+
+1. Check `plugins_guide.md` for detailed documentation
+2. Review `.cursorrules` for development patterns
+3. Look at existing plugins for examples
+4. Check logs for error messages
+5. Review plugin system code in `src/plugin_system/`
+

.cursor/plans/implement_audit_fixes_plan.md

@@ -0,0 +1,202 @@
+# Implementation Plan: Fix Config Schema Validation Issues
+
+Based on audit results showing 186 issues across 20 plugins.
+
+## Overview
+
+Three priority fixes identified from audit:
+1. **Priority 1 (HIGH)**: Remove core properties from required array - will fix ~150 issues
+2. **Priority 2 (MEDIUM)**: Verify default merging logic - will fix remaining required field issues
+3. **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
+
+1. **Add code to remove core properties from required array**:
+   ```python
+   # 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
+       ]
+   ```
+
+2. **Add logging for debugging** (optional but helpful):
+   ```python
+   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}"
+           )
+   ```
+
+3. **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
+
+### Expected Outcome
+- All 20 plugins should no longer fail validation due to missing `enabled` field
+- ~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
+
+1. **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
+
+2. **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
+
+3. **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
+
+4. **Test with problematic plugins**:
+   - `ledmatrix-weather`: required fields `api_key`, `location_city` (check if defaults exist)
+   - `mqtt-notifications`: required field `mqtt` object (check if default exists)
+   - `text-display`: required field `text` (check if default exists)
+   - `ledmatrix-music`: required field `preferred_source` (check if default exists)
+
+5. **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 has `show_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 be `show_all_day_events`)
+- `date_format` and `time_format` appear to be deprecated (not used in manager.py)
+
+### Solution
+
+**File**: `config/config.json` → `calendar` section
+
+### Implementation Steps
+
+1. **Fix field name mismatch**:
+   - Rename `show_all_day` → `show_all_day_events` in config.json
+   - This matches the schema and manager.py code
+
+2. **Remove deprecated fields**:
+   - Remove `date_format` from config (not used in code)
+   - Remove `time_format` from config (not used in code)
+
+3. **Alternative (if fields are needed)**: Add `date_format` and `time_format` to schema
+   - Only if these fields should be supported
+   - Check if they're used anywhere else in the codebase
+
+4. **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
+
+1. **Run local audit**:
+   ```bash
+   python scripts/audit_plugin_configs.py
+   ```
+
+2. **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
+
+3. **Review specific plugin results**:
+   ```bash
+   python scripts/audit_plugin_configs.py --plugin <plugin-id>
+   ```
+
+### After All Fixes
+
+1. **Full audit run**:
+   ```bash
+   python scripts/audit_plugin_configs.py
+   ```
+
+2. **Deploy to Pi**:
+   ```bash
+   ./scripts/deploy_to_pi.sh src/plugin_system/schema_manager.py web_interface/blueprints/api_v3.py
+   ```
+
+3. **Run audit on Pi**:
+   ```bash
+   ./scripts/run_audit_on_pi.sh
+   ```
+
+4. **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
+
+1. `src/plugin_system/schema_manager.py` - Remove core properties from required array
+2. `plugins/calendar/config_schema.json` OR `config/config.json` - Calendar cleanup (if needed)
+3. `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.
+

.cursor/plugin_templates/QUICK_START.md

@@ -0,0 +1,247 @@
+# Quick Start: Creating a New Plugin
+
+This guide will help you create a new plugin using the templates in `.cursor/plugin_templates/`.
+
+## Step 1: Create Plugin Directory
+
+```bash
+cd /path/to/LEDMatrix
+mkdir -p plugins/my-plugin
+cd plugins/my-plugin
+```
+
+## Step 2: Copy Templates
+
+```bash
+# Copy all template files
+cp ../../.cursor/plugin_templates/manifest.json.template ./manifest.json
+cp ../../.cursor/plugin_templates/manager.py.template ./manager.py
+cp ../../.cursor/plugin_templates/config_schema.json.template ./config_schema.json
+cp ../../.cursor/plugin_templates/README.md.template ./README.md
+cp ../../.cursor/plugin_templates/requirements.txt.template ./requirements.txt
+```
+
+## Step 3: Customize Files
+
+### manifest.json
+
+Replace placeholders:
+- `PLUGIN_ID` → `my-plugin` (lowercase, use hyphens)
+- `Plugin Name` → Your plugin's display name
+- `PluginClassName` → `MyPlugin` (PascalCase)
+- Update description, author, homepage, etc.
+
+### manager.py
+
+Replace placeholders:
+- `PluginClassName` → `MyPlugin` (must match manifest)
+- Implement `_fetch_data()` method
+- Implement `_render_content()` method
+- Add any custom validation in `validate_config()`
+
+### config_schema.json
+
+Customize:
+- Update description
+- Add/remove configuration properties
+- Set default values
+- Add validation rules
+
+### README.md
+
+Replace placeholders:
+- `PLUGIN_ID` → `my-plugin`
+- `Plugin Name` → Your plugin's name
+- Fill in features, installation, configuration sections
+
+### requirements.txt
+
+Add your plugin's dependencies:
+```txt
+requests>=2.28.0
+pillow>=9.0.0
+```
+
+## Step 4: Enable Plugin
+
+Edit `config/config.json`:
+
+```json
+{
+  "my-plugin": {
+    "enabled": true,
+    "display_duration": 15
+  }
+}
+```
+
+## Step 5: Test Plugin
+
+### Test with Emulator
+
+```bash
+cd /path/to/LEDMatrix
+python run.py --emulator
+```
+
+### Check Plugin Loading
+
+Look for logs like:
+```
+[INFO] Discovered 1 plugin(s)
+[INFO] Loaded plugin: my-plugin v1.0.0
+[INFO] Added plugin mode: my-plugin
+```
+
+### Test Plugin Display
+
+The plugin should appear in the display rotation. Check logs for any errors.
+
+## Step 6: Develop and Iterate
+
+1. Edit `manager.py` to implement your plugin logic
+2. Test with emulator: `python run.py --emulator`
+3. Check logs for errors
+4. Iterate until working correctly
+
+## Step 7: Test on Hardware (Optional)
+
+When ready, test on Raspberry Pi:
+
+```bash
+# Deploy to Pi
+rsync -avz plugins/my-plugin/ pi@raspberrypi:/path/to/LEDMatrix/plugins/my-plugin/
+
+# Or if using git
+ssh pi@raspberrypi "cd /path/to/LEDMatrix/plugins/my-plugin && git pull"
+
+# Restart service
+ssh pi@raspberrypi "sudo systemctl restart ledmatrix"
+```
+
+## Common Customizations
+
+### Adding API Integration
+
+1. Add API key to `config_schema.json`:
+```json
+{
+  "api_key": {
+    "type": "string",
+    "description": "API key for service"
+  }
+}
+```
+
+2. Implement API call in `_fetch_data()`:
+```python
+import requests
+
+def _fetch_data(self):
+    response = requests.get(
+        "https://api.example.com/data",
+        headers={"Authorization": f"Bearer {self.api_key}"}
+    )
+    return response.json()
+```
+
+3. Store API key in `config/config_secrets.json`:
+```json
+{
+  "my-plugin": {
+    "api_key": "your-secret-key"
+  }
+}
+```
+
+### Adding Image Rendering
+
+There is no `draw_image()` helper on `DisplayManager`. To render an
+image, paste it directly onto the underlying PIL `Image`
+(`display_manager.image`) and then call `update_display()`:
+
+```python
+def _render_content(self):
+    # Load and paste image onto the display canvas
+    image = Image.open("assets/logo.png").convert("RGB")
+    self.display_manager.image.paste(image, (0, 0))
+
+    # Draw text overlay
+    self.display_manager.draw_text(
+        "Text",
+        x=10, y=20,
+        color=(255, 255, 255)
+    )
+
+    self.display_manager.update_display()
+```
+
+For transparency, paste with a mask:
+
+```python
+icon = Image.open("assets/icon.png").convert("RGBA")
+self.display_manager.image.paste(icon, (5, 5), icon)
+```
+
+
+### Adding Live Priority
+
+1. Enable in config:
+```json
+{
+  "my-plugin": {
+    "live_priority": true
+  }
+}
+```
+
+2. Implement `has_live_content()`:
+```python
+def has_live_content(self) -> bool:
+    return self.data and self.data.get("is_live", False)
+```
+
+3. Override `get_live_modes()` if needed:
+```python
+def get_live_modes(self) -> list:
+    return ["my_plugin_live_mode"]
+```
+
+## Troubleshooting
+
+### Plugin Not Loading
+
+- Check `manifest.json` syntax (must be valid JSON)
+- Verify `entry_point` file exists
+- Ensure `class_name` matches class name in manager.py
+- Check for import errors in logs
+
+### Configuration Errors
+
+- Validate config against `config_schema.json`
+- Check required fields are present
+- Verify data types match schema
+
+### Display Issues
+
+- Check display dimensions: `display_manager.width`, `display_manager.height`
+- Verify coordinates are within bounds
+- Ensure `update_display()` is called
+- Test with emulator first
+
+## Next Steps
+
+- Review existing plugins for patterns:
+  - `plugins/hockey-scoreboard/` - Sports scoreboard example
+  - `plugins/ledmatrix-music/` - Real-time data example
+  - `plugins/ledmatrix-stocks/` - Data display example
+
+- Read full documentation:
+  - `.cursor/plugins_guide.md` - Comprehensive guide
+  - `docs/PLUGIN_ARCHITECTURE_SPEC.md` - Architecture details
+  - `.cursorrules` - Development rules
+
+- Check plugin system code:
+  - `src/plugin_system/base_plugin.py` - Base class
+  - `src/plugin_system/plugin_manager.py` - Plugin manager
+

.cursor/plugin_templates/README.md.template

@@ -0,0 +1,156 @@
+# Plugin Name
+
+Brief description of what this plugin does.
+
+## Features
+
+- Feature 1
+- Feature 2
+- Feature 3
+
+## Installation
+
+1. Link the plugin to your LEDMatrix installation:
+
+```bash
+cd /path/to/LEDMatrix
+./scripts/dev/dev_plugin_setup.sh link-github PLUGIN_ID
+```
+
+Or for local development:
+
+```bash
+./scripts/dev/dev_plugin_setup.sh link PLUGIN_ID /path/to/plugin/repo
+```
+
+2. Install dependencies:
+
+```bash
+pip install -r plugins/PLUGIN_ID/requirements.txt
+```
+
+3. Configure the plugin in `config/config.json`:
+
+```json
+{
+  "PLUGIN_ID": {
+    "enabled": true,
+    "display_duration": 15
+  }
+}
+```
+
+**Note:** API keys and other sensitive credentials must be stored in `config/config_secrets.json`, not in `config/config.json`.
+
+4. Store API keys in `config/config_secrets.json`:
+
+```json
+{
+  "PLUGIN_ID": {
+    "api_key": "your-secret-api-key"
+  }
+}
+```
+
+## Configuration
+
+### Required Settings
+
+- `enabled` (boolean): Enable or disable the plugin
+- `api_key` (string): API key for external service (if required)
+
+### Optional Settings
+
+- `display_duration` (number): How long to display this plugin (default: 15 seconds)
+- `refresh_interval` (integer): How often to refresh data in seconds (default: 60)
+- `live_priority` (boolean): Enable live priority takeover (default: false)
+
+## Display Modes
+
+This plugin provides the following display modes:
+
+- `PLUGIN_ID`: Main display mode
+
+## API Requirements
+
+This plugin requires:
+
+- **API Name**: Description of API requirements
+  - URL: https://api.example.com
+  - Rate Limit: X requests per minute
+  - Authentication: API key required
+
+## Development
+
+### Running Tests
+
+```bash
+cd plugins/PLUGIN_ID
+python test_PLUGIN_ID.py
+```
+
+### Testing with Emulator
+
+```bash
+cd /path/to/LEDMatrix
+python run.py --emulator
+```
+
+### Debugging
+
+Enable debug logging in `config/config.json`:
+
+```json
+{
+  "logging": {
+    "level": "DEBUG"
+  }
+}
+```
+
+Check logs:
+
+```bash
+# On Raspberry Pi (if running as service)
+journalctl -u ledmatrix -f
+
+# Direct execution
+python run.py
+```
+
+## Troubleshooting
+
+### Plugin Not Loading
+
+1. Check that `manifest.json` exists and is valid
+2. Verify `entry_point` file exists
+3. Check that `class_name` matches the class in manager.py
+4. Review logs for import errors
+
+### Configuration Errors
+
+1. Validate config against `config_schema.json`
+2. Check required fields are present
+3. Verify data types match schema
+
+### API Errors
+
+1. Verify API key is correct
+2. Check API rate limits
+3. Review network connectivity
+4. Check API service status
+
+## License
+
+[License information]
+
+## Author
+
+Your Name
+
+## Links
+
+- GitHub: https://github.com/username/ledmatrix-PLUGIN_ID
+- Documentation: [Link to docs]
+- Issues: https://github.com/username/ledmatrix-PLUGIN_ID/issues
+

.cursor/plugin_templates/config_schema.json.template

@@ -0,0 +1,44 @@
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "type": "object",
+  "title": "Plugin Configuration Schema",
+  "description": "Configuration schema for Plugin Name",
+  "properties": {
+    "enabled": {
+      "type": "boolean",
+      "default": true,
+      "description": "Enable or disable this plugin"
+    },
+    "display_duration": {
+      "type": "number",
+      "default": 15,
+      "minimum": 1,
+      "maximum": 300,
+      "description": "How long to display this plugin in seconds"
+    },
+    "live_priority": {
+      "type": "boolean",
+      "default": false,
+      "description": "Enable live priority takeover when plugin has live content"
+    },
+    "refresh_interval": {
+      "type": "integer",
+      "default": 60,
+      "minimum": 1,
+      "description": "How often to refresh data in seconds"
+    },
+    "api_key": {
+      "type": "string",
+      "description": "API key for external service (store in config_secrets.json)",
+      "default": ""
+    },
+    "custom_setting": {
+      "type": "string",
+      "description": "Example custom setting - replace with your plugin's settings",
+      "default": "default_value"
+    }
+  },
+  "required": ["enabled"],
+  "additionalProperties": false
+}
+

.cursor/plugin_templates/manager.py.template

@@ -0,0 +1,226 @@
+"""
+Plugin Name
+
+Brief description of what this plugin does.
+
+API Version: 1.0.0
+"""
+
+from src.plugin_system.base_plugin import BasePlugin
+from PIL import Image
+from typing import Dict, Any, Optional
+import logging
+import time
+
+
+class PluginClassName(BasePlugin):
+    """
+    Plugin class that inherits from BasePlugin.
+    
+    This plugin demonstrates the basic structure and common patterns
+    for LEDMatrix plugins.
+    """
+    
+    def __init__(
+        self,
+        plugin_id: str,
+        config: Dict[str, Any],
+        display_manager,
+        cache_manager,
+        plugin_manager,
+    ):
+        """Initialize the plugin."""
+        super().__init__(plugin_id, config, display_manager, cache_manager, plugin_manager)
+        
+        # Initialize plugin-specific data
+        self.data = None
+        self.last_update_time = None
+        
+        # Load configuration values
+        self.api_key = config.get("api_key", "")
+        self.refresh_interval = config.get("refresh_interval", 60)
+        
+        self.logger.info(f"Plugin {plugin_id} initialized")
+    
+    def update(self) -> None:
+        """
+        Fetch/update data for this plugin.
+        
+        This method is called periodically based on update_interval
+        specified in the manifest. Use cache_manager to avoid
+        excessive API calls.
+        """
+        cache_key = f"{self.plugin_id}_data"
+        
+        # Check cache first
+        cached = self.cache_manager.get(cache_key, max_age=self.refresh_interval)
+        if cached:
+            self.data = cached
+            self.logger.debug("Using cached data")
+            return
+        
+        try:
+            # Fetch new data
+            self.data = self._fetch_data()
+            
+            # Cache the data
+            self.cache_manager.set(cache_key, self.data, ttl=self.refresh_interval)
+            self.last_update_time = time.time()
+            
+            self.logger.info("Data updated successfully")
+            
+        except Exception as e:
+            self.logger.error(f"Failed to update data: {e}")
+            # Use cached data if available, even if expired
+            # Use a very large max_age (1 year) to effectively bypass expiration for fallback
+            expired_cached = self.cache_manager.get(cache_key, max_age=31536000)
+            if expired_cached:
+                self.data = expired_cached
+                self.logger.warning("Using expired cache due to update failure")
+    
+    def display(self, force_clear: bool = False) -> None:
+        """
+        Render this plugin's display.
+        
+        Args:
+            force_clear: If True, clear display before rendering
+        """
+        if force_clear:
+            self.display_manager.clear()
+        
+        # Check if we have data to display
+        if not self.data:
+            self._display_error("No data available")
+            return
+        
+        try:
+            # Render plugin content
+            self._render_content()
+            
+            # Update the display
+            self.display_manager.update_display()
+            
+        except Exception as e:
+            self.logger.error(f"Display error: {e}")
+            self._display_error("Display error")
+    
+    def _fetch_data(self) -> Dict[str, Any]:
+        """
+        Fetch data from external source.
+        
+        Returns:
+            Dictionary containing fetched data
+        """
+        # TODO: Implement data fetching logic
+        # Example:
+        # import requests
+        # response = requests.get("https://api.example.com/data", 
+        #                        headers={"Authorization": f"Bearer {self.api_key}"})
+        # return response.json()
+        
+        # Placeholder
+        return {
+            "message": "Hello, World!",
+            "timestamp": time.time()
+        }
+    
+    def _render_content(self) -> None:
+        """Render the plugin content on the display."""
+        # Get display dimensions
+        width = self.display_manager.width
+        height = self.display_manager.height
+        
+        # Example: Draw text
+        text = self.data.get("message", "No data")
+        x = 5
+        y = height // 2
+        
+        self.display_manager.draw_text(
+            text,
+            x=x,
+            y=y,
+            color=(255, 255, 255)  # White
+        )
+        
+        # Example: Draw image
+        # if hasattr(self, 'logo_image'):
+        #     self.display_manager.draw_image(
+        #         self.logo_image,
+        #         x=0,
+        #         y=0
+        #     )
+    
+    def _display_error(self, message: str) -> None:
+        """Display an error message."""
+        self.display_manager.clear()
+        width = self.display_manager.width
+        height = self.display_manager.height
+        
+        self.display_manager.draw_text(
+            message,
+            x=5,
+            y=height // 2,
+            color=(255, 0, 0)  # Red
+        )
+        self.display_manager.update_display()
+    
+    def validate_config(self) -> bool:
+        """
+        Validate plugin configuration.
+        
+        Returns:
+            True if config is valid, False otherwise
+        """
+        # Call parent validation first
+        if not super().validate_config():
+            return False
+        
+        # Add custom validation
+        # Example: Check for required API key
+        # if self.config.get("require_api_key", True):
+        #     if not self.api_key:
+        #         self.logger.error("API key is required but not provided")
+        #         return False
+        
+        return True
+    
+    def has_live_content(self) -> bool:
+        """
+        Check if plugin has live content to display.
+        
+        Override this method to enable live priority features.
+        
+        Returns:
+            True if plugin has live content, False otherwise
+        """
+        # Example: Check if there's live data
+        # return self.data and self.data.get("is_live", False)
+        return False
+    
+    def get_info(self) -> Dict[str, Any]:
+        """
+        Return plugin info for display in web UI.
+        
+        Returns:
+            Dictionary with plugin information
+        """
+        info = super().get_info()
+        
+        # Add plugin-specific info
+        info.update({
+            "data_available": self.data is not None,
+            "last_update": self.last_update_time,
+            # Add more info as needed
+        })
+        
+        return info
+    
+    def cleanup(self) -> None:
+        """Cleanup resources when plugin is unloaded."""
+        # Clean up any resources (threads, connections, etc.)
+        # Example:
+        # if hasattr(self, 'api_client'):
+        #     self.api_client.close()
+        
+        super().cleanup()
+

.cursor/plugin_templates/manifest.json.template

@@ -0,0 +1,55 @@
+{
+  "id": "PLUGIN_ID",
+  "name": "Plugin Name",
+  "version": "1.0.0",
+  "author": "Your Name",
+  "description": "Brief description of what this plugin does",
+  "homepage": "https://github.com/username/ledmatrix-PLUGIN_ID",
+  "entry_point": "manager.py",
+  "class_name": "PluginClassName",
+  "category": "custom",
+  "tags": ["custom", "example"],
+  "icon": "fas fa-icon-name",
+  "compatible_versions": [">=2.0.0"],
+  "min_ledmatrix_version": "2.0.0",
+  "max_ledmatrix_version": "3.0.0",
+  "requires": {
+    "python": ">=3.9",
+    "display_size": {
+      "min_width": 64,
+      "min_height": 32
+    }
+  },
+  "config_schema": "config_schema.json",
+  "assets": {
+    "logos": "Optional: Description of asset requirements"
+  },
+  "update_interval": 60,
+  "default_duration": 15,
+  "display_modes": [
+    "PLUGIN_ID"
+  ],
+  "api_requirements": [
+    {
+      "name": "API Name",
+      "required": false,
+      "description": "Description of API requirements",
+      "url": "https://api.example.com",
+      "rate_limit": "Rate limit information"
+    }
+  ],
+  "download_url_template": "https://github.com/username/ledmatrix-PLUGIN_ID/archive/refs/tags/v{version}.zip",
+  "versions": [
+    {
+      "released": "2025-01-01",
+      "version": "1.0.0",
+      "ledmatrix_min_version": "2.0.0"
+    }
+  ],
+  "last_updated": "2025-01-01",
+  "stars": 0,
+  "downloads": 0,
+  "verified": false,
+  "screenshot": ""
+}
+

.cursor/plugin_templates/requirements.txt.template

@@ -0,0 +1,13 @@
+# Plugin Dependencies
+# Add your plugin's Python dependencies here
+
+# Example dependencies (uncomment and modify as needed):
+# requests>=2.28.0
+# pillow>=9.0.0
+# python-dateutil>=2.8.0
+
+# Note: Core LEDMatrix dependencies are already available:
+# - PIL/Pillow (for image handling)
+# - Core plugin system classes
+# - Display manager, cache manager, config manager
+

.cursor/plugin_templates/test_manager.py.template

@@ -0,0 +1,136 @@
+"""
+Test file for Plugin Name plugin.
+
+This file provides example unit tests for your plugin.
+Run tests with: python -m pytest test_manager.py
+Or: python test_manager.py
+"""
+
+import unittest
+import sys
+from pathlib import Path
+
+# Add project root to path
+PROJECT_ROOT = Path(__file__).resolve().parent.parent.parent
+if str(PROJECT_ROOT) not in sys.path:
+    sys.path.insert(0, str(PROJECT_ROOT))
+
+from src.plugin_system.testing import PluginTestCase
+from manager import PluginClassName
+
+
+class TestPluginClassName(PluginTestCase):
+    """Test cases for PluginClassName plugin."""
+    
+    def setUp(self):
+        """Set up test fixtures."""
+        super().setUp()
+        
+        # Update plugin_id to match the plugin being tested
+        self.plugin_id = 'PLUGIN_ID'
+        
+        # Create plugin instance
+        self.plugin = self.create_plugin_instance(
+            PluginClassName,
+            plugin_id='PLUGIN_ID',
+            config=self.get_mock_config()
+        )
+    
+    def test_plugin_initialization(self):
+        """Test that plugin initializes correctly."""
+        self.assert_plugin_initialized(self.plugin)
+        self.assertTrue(self.plugin.enabled)
+    
+    def test_config_validation(self):
+        """Test configuration validation."""
+        # Valid config should pass
+        self.assertTrue(self.plugin.validate_config())
+        
+        # Test with invalid config if applicable
+        # invalid_config = self.get_mock_config(enabled='not-a-boolean')
+        # invalid_plugin = self.create_plugin_instance(
+        #     PluginClassName,
+        #     config=invalid_config
+        # )
+        # self.assertFalse(invalid_plugin.validate_config())
+    
+    def test_update_method(self):
+        """Test the update() method."""
+        # Reset mocks
+        self.cache_manager.reset()
+        
+        # Call update
+        self.plugin.update()
+        
+        # Assertions
+        # Example: Check that cache was used
+        # self.assert_cache_get('PLUGIN_ID_data')
+        
+        # Example: Check that data was fetched and cached
+        # self.assert_cache_set('PLUGIN_ID_data')
+    
+    def test_display_method(self):
+        """Test the display() method."""
+        # Ensure plugin has data (call update first if needed)
+        # self.plugin.update()
+        
+        # Call display
+        self.plugin.display(force_clear=True)
+        
+        # Assertions
+        self.assert_display_cleared()
+        self.assert_display_updated()
+        
+        # Example: Check that text was drawn
+        # self.assert_text_drawn("Expected Text")
+        
+        # Example: Check that image was drawn
+        # self.assert_image_drawn()
+    
+    def test_display_without_data(self):
+        """Test display() behavior when no data is available."""
+        # Clear any cached data
+        self.cache_manager.reset()
+        
+        # Call display
+        self.plugin.display()
+        
+        # Should handle gracefully (no exceptions)
+        # May show error message or fallback content
+        self.assert_display_updated()
+    
+    def test_get_display_duration(self):
+        """Test display duration configuration."""
+        duration = self.plugin.get_display_duration()
+        self.assertIsInstance(duration, (int, float))
+        self.assertGreater(duration, 0)
+        
+        # Test with custom duration
+        custom_config = self.get_mock_config(display_duration=30.0)
+        custom_plugin = self.create_plugin_instance(
+            PluginClassName,
+            config=custom_config
+        )
+        self.assertEqual(custom_plugin.get_display_duration(), 30.0)
+    
+    def test_enable_disable(self):
+        """Test plugin enable/disable functionality."""
+        self.assertTrue(self.plugin.enabled)
+        
+        self.plugin.on_disable()
+        self.assertFalse(self.plugin.enabled)
+        
+        self.plugin.on_enable()
+        self.assertTrue(self.plugin.enabled)
+    
+    def test_config_change(self):
+        """Test configuration change handling."""
+        new_config = self.get_mock_config(display_duration=20.0)
+        self.plugin.on_config_change(new_config)
+        
+        self.assertEqual(self.plugin.config.get('display_duration'), 20.0)
+
+
+if __name__ == '__main__':
+    unittest.main()
+

.cursor/plugins_guide.md

@@ -0,0 +1,751 @@
+# LEDMatrix Plugin Development Guide
+
+This guide provides comprehensive instructions for creating, running, and loading plugins in the LEDMatrix project.
+
+## Table of Contents
+
+1. [Plugin System Overview](#plugin-system-overview)
+2. [Creating a New Plugin](#creating-a-new-plugin)
+3. [Running Plugins](#running-plugins)
+4. [Loading Plugins](#loading-plugins)
+5. [Plugin Development Workflow](#plugin-development-workflow)
+6. [Testing Plugins](#testing-plugins)
+7. [Troubleshooting](#troubleshooting)
+
+---
+
+## Plugin System Overview
+
+The LEDMatrix project uses a plugin-based architecture where all display functionality (except core calendar) is implemented as plugins. Plugins are dynamically loaded from the `plugins/` directory and integrated into the display rotation.
+
+### Plugin Architecture
+
+```
+LEDMatrix Core
+├── Plugin Manager (discovers, loads, manages plugins)
+├── Display Manager (handles LED matrix rendering)
+├── Cache Manager (data persistence)
+├── Config Manager (configuration management)
+└── Plugins/ (plugin directory)
+    ├── plugin-1/
+    ├── plugin-2/
+    └── ...
+```
+
+### Plugin Lifecycle
+
+1. **Discovery**: PluginManager scans `plugins/` for directories with `manifest.json`
+2. **Loading**: Plugin module is imported and class is instantiated
+3. **Configuration**: Plugin config is loaded from `config/config.json`
+4. **Validation**: `validate_config()` is called to verify configuration
+5. **Registration**: Plugin is added to available display modes
+6. **Execution**: `update()` is called periodically, `display()` is called during rotation
+
+---
+
+## Creating a New Plugin
+
+### Method 1: Using dev_plugin_setup.sh (Recommended)
+
+This method is best for plugins stored in separate Git repositories.
+
+#### From GitHub Repository
+
+```bash
+# Link a plugin from GitHub (auto-detects URL)
+./scripts/dev/dev_plugin_setup.sh link-github <plugin-name>
+
+# Example: Link hockey-scoreboard plugin
+./scripts/dev/dev_plugin_setup.sh link-github hockey-scoreboard
+
+# With custom URL
+./scripts/dev/dev_plugin_setup.sh link-github <plugin-name> https://github.com/user/repo.git
+```
+
+The script will:
+- Clone the repository to `~/.ledmatrix-dev-plugins/` (or configured directory)
+- Create a symlink in `plugins/<plugin-name>/` pointing to the cloned repo
+- Validate the plugin structure
+
+#### From Local Repository
+
+```bash
+# Link a local plugin repository
+./scripts/dev/dev_plugin_setup.sh link <plugin-name> <path-to-repo>
+
+# Example: Link a local plugin
+./scripts/dev/dev_plugin_setup.sh link my-plugin ../ledmatrix-my-plugin
+```
+
+### Method 2: Manual Plugin Creation
+
+1. **Create Plugin Directory**
+
+```bash
+mkdir -p plugins/my-plugin
+cd plugins/my-plugin
+```
+
+2. **Create manifest.json**
+
+```json
+{
+  "id": "my-plugin",
+  "name": "My Plugin",
+  "version": "1.0.0",
+  "author": "Your Name",
+  "description": "Description of what this plugin does",
+  "entry_point": "manager.py",
+  "class_name": "MyPlugin",
+  "category": "custom",
+  "tags": ["custom", "example"],
+  "display_modes": ["my_plugin"],
+  "update_interval": 60,
+  "default_duration": 15,
+  "requires": {
+    "python": ">=3.9"
+  },
+  "config_schema": "config_schema.json"
+}
+```
+
+3. **Create manager.py**
+
+```python
+from src.plugin_system.base_plugin import BasePlugin
+from PIL import Image
+import logging
+
+class MyPlugin(BasePlugin):
+    """My custom plugin implementation."""
+    
+    def update(self):
+        """Fetch/update data for this plugin."""
+        # Fetch data from API, files, etc.
+        # Use self.cache_manager for caching
+        cache_key = f"{self.plugin_id}_data"
+        cached = self.cache_manager.get(cache_key, max_age=3600)
+        if cached:
+            self.data = cached
+            return
+        
+        # Fetch new data
+        self.data = self._fetch_data()
+        self.cache_manager.set(cache_key, self.data)
+    
+    def display(self, force_clear=False):
+        """Render this plugin's display."""
+        if force_clear:
+            self.display_manager.clear()
+        
+        # Render content using display_manager
+        self.display_manager.draw_text(
+            "Hello, World!",
+            x=10, y=15,
+            color=(255, 255, 255)
+        )
+        
+        self.display_manager.update_display()
+    
+    def _fetch_data(self):
+        """Fetch data from external source."""
+        # Implement your data fetching logic
+        return {"message": "Hello, World!"}
+    
+    def validate_config(self):
+        """Validate plugin configuration."""
+        # Check required config fields
+        if not super().validate_config():
+            return False
+        
+        # Add custom validation
+        required_fields = ['api_key']  # Example
+        for field in required_fields:
+            if field not in self.config:
+                self.logger.error(f"Missing required field: {field}")
+                return False
+        
+        return True
+```
+
+4. **Create config_schema.json**
+
+```json
+{
+  "type": "object",
+  "properties": {
+    "enabled": {
+      "type": "boolean",
+      "default": true,
+      "description": "Enable or disable this plugin"
+    },
+    "display_duration": {
+      "type": "number",
+      "default": 15,
+      "minimum": 1,
+      "description": "How long to display this plugin (seconds)"
+    },
+    "api_key": {
+      "type": "string",
+      "description": "API key for external service"
+    }
+  },
+  "required": ["enabled"]
+}
+```
+
+5. **Create requirements.txt** (if needed)
+
+```
+requests>=2.28.0
+pillow>=9.0.0
+```
+
+6. **Create README.md**
+
+Document your plugin's functionality, configuration options, and usage.
+
+---
+
+## Running Plugins
+
+### Development Mode (Emulator)
+
+Run the LEDMatrix system with emulator for plugin testing:
+
+```bash
+# Using run.py
+python run.py --emulator
+
+# Using emulator script
+./run_emulator.sh
+```
+
+The emulator will:
+- Load all enabled plugins
+- Display plugin content in a window (simulating LED matrix)
+- Show logs for plugin loading and execution
+- Allow testing without Raspberry Pi hardware
+
+### Production Mode (Raspberry Pi)
+
+Run on actual Raspberry Pi hardware:
+
+```bash
+# Direct execution
+python run.py
+
+# As systemd service
+sudo systemctl start ledmatrix
+sudo systemctl status ledmatrix
+sudo journalctl -u ledmatrix -f  # View logs
+```
+
+### Plugin-Specific Testing
+
+Test individual plugin loading:
+
+```python
+# test_my_plugin.py
+from src.plugin_system.plugin_manager import PluginManager
+from src.config_manager import ConfigManager
+from src.display_manager import DisplayManager
+from src.cache_manager import CacheManager
+
+# Initialize managers
+config_manager = ConfigManager()
+config = config_manager.load_config()
+display_manager = DisplayManager(config)
+cache_manager = CacheManager()
+
+# Initialize plugin manager
+plugin_manager = PluginManager(
+    plugins_dir="plugins",
+    config_manager=config_manager,
+    display_manager=display_manager,
+    cache_manager=cache_manager
+)
+
+# Discover and load plugin
+plugins = plugin_manager.discover_plugins()
+print(f"Discovered plugins: {plugins}")
+
+if "my-plugin" in plugins:
+    if plugin_manager.load_plugin("my-plugin"):
+        plugin = plugin_manager.get_plugin("my-plugin")
+        plugin.update()
+        plugin.display()
+        print("Plugin loaded and displayed successfully!")
+    else:
+        print("Failed to load plugin")
+```
+
+---
+
+## Loading Plugins
+
+### Enabling Plugins
+
+Plugins are enabled/disabled in `config/config.json`:
+
+```json
+{
+  "my-plugin": {
+    "enabled": true,
+    "display_duration": 15,
+    "api_key": "your-api-key-here"
+  }
+}
+```
+
+### Plugin Configuration Structure
+
+Each plugin has its own section in `config/config.json`:
+
+```json
+{
+  "<plugin-id>": {
+    "enabled": true,                    // Enable/disable plugin
+    "display_duration": 15,             // Display duration in seconds
+    "live_priority": false,             // Enable live priority takeover
+    "high_performance_transitions": false, // Use 120 FPS transitions
+    "transition": {                     // Transition configuration
+      "type": "redraw",                 // Transition type
+      "speed": 2,                       // Transition speed
+      "enabled": true                   // Enable transitions
+    },
+    // ... plugin-specific configuration
+  }
+}
+```
+
+### Secrets Management
+
+Store sensitive data (API keys, tokens) in `config/config_secrets.json`
+under the same plugin id you use in `config/config.json`:
+
+```json
+{
+  "my-plugin": {
+    "api_key": "secret-api-key-here"
+  }
+}
+```
+
+At load time, the config manager deep-merges `config_secrets.json` into
+the main config (verified at `src/config_manager.py:162-172`). So in
+your plugin's code:
+
+```python
+class MyPlugin(BasePlugin):
+    def __init__(self, plugin_id, config, display_manager, cache_manager, plugin_manager):
+        super().__init__(plugin_id, config, display_manager, cache_manager, plugin_manager)
+        self.api_key = config.get("api_key")  # already merged from secrets
+```
+
+There is no separate `config_secrets` reference field — just put the
+secret value under the same plugin namespace and read it from the
+merged config.
+
+### Plugin Discovery
+
+Plugins are automatically discovered when:
+- Directory exists in `plugins/`
+- Directory contains `manifest.json`
+- Manifest has required fields (`id`, `entry_point`, `class_name`)
+
+Check discovered plugins:
+
+```bash
+# Using dev_plugin_setup.sh
+./scripts/dev/dev_plugin_setup.sh list
+
+# Output shows:
+# ✓ plugin-name (symlink)
+#   → /path/to/repo
+#   ✓ Git repo is clean (branch: main)
+```
+
+### Plugin Status
+
+Check plugin status and git information:
+
+```bash
+./scripts/dev/dev_plugin_setup.sh status
+
+# Output shows:
+# ✓ plugin-name
+#   Path: /path/to/repo
+#   Branch: main
+#   Remote: https://github.com/user/repo.git
+#   Status: Clean and up to date
+```
+
+---
+
+## Plugin Development Workflow
+
+### 1. Initial Setup
+
+```bash
+# Create or clone plugin repository
+git clone https://github.com/user/ledmatrix-my-plugin.git
+cd ledmatrix-my-plugin
+
+# Link to LEDMatrix project
+cd /path/to/LEDMatrix
+./scripts/dev/dev_plugin_setup.sh link my-plugin ../ledmatrix-my-plugin
+```
+
+### 2. Development Cycle
+
+1. **Edit plugin code** in linked repository
+2. **Test with the dev preview server**:
+   `python3 scripts/dev_server.py` (then open `http://localhost:5001`).
+   Or run the full display in emulator mode with
+   `python3 run.py --emulator` (or equivalently
+   `EMULATOR=true python3 run.py`). The `-e`/`--emulator` CLI flag is
+   defined in `run.py:19-20` and sets the same `EMULATOR` environment
+   variable internally.
+3. **Check logs** for errors or warnings
+4. **Update configuration** in `config/config.json` if needed
+5. **Iterate** until plugin works correctly
+
+### 3. Testing on Hardware
+
+```bash
+# Deploy to Raspberry Pi
+rsync -avz plugins/my-plugin/ ledpi@your-pi-ip:/path/to/LEDMatrix/plugins/my-plugin/
+
+# Or if using git, pull on Pi
+ssh ledpi@your-pi-ip "cd /path/to/LEDMatrix/plugins/my-plugin && git pull"
+
+# Restart service
+ssh ledpi@your-pi-ip "sudo systemctl restart ledmatrix"
+```
+
+### 4. Updating Plugins
+
+```bash
+# Update single plugin from git
+./scripts/dev/dev_plugin_setup.sh update my-plugin
+
+# Update all linked plugins
+./scripts/dev/dev_plugin_setup.sh update
+```
+
+### 5. Unlinking Plugins
+
+```bash
+# Remove symlink (preserves repository)
+./scripts/dev/dev_plugin_setup.sh unlink my-plugin
+```
+
+---
+
+## Testing Plugins
+
+### Unit Testing
+
+Create test files in plugin directory:
+
+```python
+# plugins/my-plugin/test_my_plugin.py
+import unittest
+from unittest.mock import Mock, MagicMock
+from manager import MyPlugin
+
+class TestMyPlugin(unittest.TestCase):
+    def setUp(self):
+        self.config = {"enabled": True}
+        self.display_manager = Mock()
+        self.cache_manager = Mock()
+        self.plugin_manager = Mock()
+        
+        self.plugin = MyPlugin(
+            plugin_id="my-plugin",
+            config=self.config,
+            display_manager=self.display_manager,
+            cache_manager=self.cache_manager,
+            plugin_manager=self.plugin_manager
+        )
+    
+    def test_plugin_initialization(self):
+        self.assertEqual(self.plugin.plugin_id, "my-plugin")
+        self.assertTrue(self.plugin.enabled)
+    
+    def test_config_validation(self):
+        self.assertTrue(self.plugin.validate_config())
+    
+    def test_update(self):
+        self.cache_manager.get.return_value = None
+        self.plugin.update()
+        # Assert data was fetched and cached
+    
+    def test_display(self):
+        self.plugin.display()
+        self.display_manager.draw_text.assert_called()
+        self.display_manager.update_display.assert_called()
+
+if __name__ == '__main__':
+    unittest.main()
+```
+
+Run tests:
+
+```bash
+cd plugins/my-plugin
+python -m pytest test_my_plugin.py
+# or
+python test_my_plugin.py
+```
+
+### Integration Testing
+
+Test plugin with actual managers:
+
+```python
+# test_plugin_integration.py
+from src.plugin_system.plugin_manager import PluginManager
+from src.config_manager import ConfigManager
+from src.display_manager import DisplayManager
+from src.cache_manager import CacheManager
+
+def test_plugin_loading():
+    config_manager = ConfigManager()
+    config = config_manager.load_config()
+    display_manager = DisplayManager(config)
+    cache_manager = CacheManager()
+    
+    plugin_manager = PluginManager(
+        plugins_dir="plugins",
+        config_manager=config_manager,
+        display_manager=display_manager,
+        cache_manager=cache_manager
+    )
+    
+    plugins = plugin_manager.discover_plugins()
+    assert "my-plugin" in plugins
+    
+    assert plugin_manager.load_plugin("my-plugin")
+    plugin = plugin_manager.get_plugin("my-plugin")
+    assert plugin is not None
+    assert plugin.enabled
+    
+    plugin.update()
+    plugin.display()
+```
+
+### Emulator Testing
+
+Test plugin rendering visually:
+
+```bash
+# Run with emulator
+python run.py --emulator
+
+# Plugin should appear in display rotation
+# Check logs for plugin loading and execution
+```
+
+### Hardware Testing
+
+1. Deploy plugin to Raspberry Pi
+2. Enable in `config/config.json`
+3. Restart LEDMatrix service
+4. Observe LED matrix display
+5. Check logs: `journalctl -u ledmatrix -f`
+
+---
+
+## Troubleshooting
+
+### Plugin Not Loading
+
+**Symptoms**: Plugin doesn't appear in available modes, no logs about plugin
+
+**Solutions**:
+1. Check plugin directory exists: `ls plugins/my-plugin/`
+2. Verify `manifest.json` exists and is valid JSON
+3. Check manifest has required fields: `id`, `entry_point`, `class_name`
+4. Verify entry_point file exists: `ls plugins/my-plugin/manager.py`
+5. Check class name matches: `grep "class.*Plugin" plugins/my-plugin/manager.py`
+6. Review logs for import errors
+
+### Plugin Loading but Not Displaying
+
+**Symptoms**: Plugin loads successfully but doesn't appear in rotation
+
+**Solutions**:
+1. Check plugin is enabled: `config/config.json` has `"enabled": true`
+2. Verify display_modes in manifest match config
+3. Check plugin is in rotation schedule
+4. Review `display()` method for errors
+5. Check logs for runtime errors
+
+### Configuration Errors
+
+**Symptoms**: Plugin fails to load, validation errors in logs
+
+**Solutions**:
+1. Validate config against `config_schema.json`
+2. Check required fields are present
+3. Verify data types match schema
+4. Check for typos in config keys
+5. Review `validate_config()` method
+
+### Import Errors
+
+**Symptoms**: ModuleNotFoundError or ImportError in logs
+
+**Solutions**:
+1. Install plugin dependencies: `pip install -r plugins/my-plugin/requirements.txt`
+2. Check Python path includes plugin directory
+3. Verify relative imports are correct
+4. Check for circular import issues
+5. Ensure all dependencies are in requirements.txt
+
+### Display Issues
+
+**Symptoms**: Plugin renders incorrectly or not at all
+
+**Solutions**:
+1. Check display dimensions: `display_manager.width`, `display_manager.height`
+2. Verify coordinates are within display bounds
+3. Check color values are valid (0-255)
+4. Ensure `update_display()` is called after rendering
+5. Test with emulator first to debug rendering
+
+### Performance Issues
+
+**Symptoms**: Slow display updates, high CPU usage
+
+**Solutions**:
+1. Use `cache_manager` to avoid excessive API calls
+2. Implement background data fetching
+3. Optimize rendering code
+4. Consider using `high_performance_transitions`
+5. Profile plugin code to identify bottlenecks
+
+### Git/Symlink Issues
+
+**Symptoms**: Plugin changes not appearing, broken symlinks
+
+**Solutions**:
+1. Check symlink: `ls -la plugins/my-plugin`
+2. Verify target exists: `readlink -f plugins/my-plugin`
+3. Update plugin: `./scripts/dev/dev_plugin_setup.sh update my-plugin`
+4. Re-link plugin if needed: `./scripts/dev/dev_plugin_setup.sh unlink my-plugin && ./scripts/dev/dev_plugin_setup.sh link my-plugin <path>`
+5. Check git status: `cd plugins/my-plugin && git status`
+
+---
+
+## Best Practices
+
+### Code Organization
+
+- Keep plugin code in `plugins/<plugin-id>/` directory
+- Use descriptive class and method names
+- Follow existing plugin patterns
+- Place shared utilities in `src/common/` if reusable
+
+### Configuration
+
+- Always use `config_schema.json` for validation
+- Store secrets in `config_secrets.json`
+- Provide sensible defaults
+- Document all configuration options in README
+
+### Error Handling
+
+- Use plugin logger for all logging
+- Handle API failures gracefully
+- Provide fallback displays when data unavailable
+- Cache data to avoid excessive requests
+
+### Performance
+
+- Cache API responses appropriately
+- Use background data fetching for long operations
+- Optimize rendering for Pi's limited resources
+- Test performance on actual hardware
+
+### Testing
+
+- Write unit tests for core logic
+- Test with emulator before hardware
+- Test on Raspberry Pi before deploying
+- Test with other plugins enabled
+
+### Documentation
+
+- Document plugin functionality in README
+- Include configuration examples
+- Document API requirements and rate limits
+- Provide usage examples
+
+---
+
+## Resources
+
+- **Plugin System Documentation**: `docs/PLUGIN_ARCHITECTURE_SPEC.md`
+- **Base Plugin Class**: `src/plugin_system/base_plugin.py`
+- **Plugin Manager**: `src/plugin_system/plugin_manager.py`
+- **Example Plugins**: 
+  - `plugins/hockey-scoreboard/` - Sports scoreboard example
+  - `plugins/football-scoreboard/` - Complex multi-league example
+  - `plugins/ledmatrix-music/` - Real-time data example
+- **Development Setup**: `dev_plugin_setup.sh`
+- **Example Config**: `dev_plugins.json.example`
+
+---
+
+## Quick Reference
+
+### Common Commands
+
+```bash
+# Link plugin from GitHub
+./scripts/dev/dev_plugin_setup.sh link-github <name>
+
+# Link local plugin
+./scripts/dev/dev_plugin_setup.sh link <name> <path>
+
+# List all plugins
+./scripts/dev/dev_plugin_setup.sh list
+
+# Check plugin status
+./scripts/dev/dev_plugin_setup.sh status
+
+# Update plugin(s)
+./scripts/dev/dev_plugin_setup.sh update [name]
+
+# Unlink plugin
+./scripts/dev/dev_plugin_setup.sh unlink <name>
+
+# Run with emulator
+python run.py --emulator
+
+# Run on Pi
+python run.py
+```
+
+### Plugin File Structure
+
+```
+plugins/my-plugin/
+├── manifest.json          # Required: Plugin metadata
+├── manager.py             # Required: Plugin class
+├── config_schema.json     # Required: Config validation
+├── requirements.txt       # Optional: Dependencies
+├── README.md              # Optional: Documentation
+└── ...                    # Plugin-specific files
+```
+
+### Required Manifest Fields
+
+- `id`: Plugin identifier
+- `entry_point`: Python file (usually "manager.py")
+- `class_name`: Plugin class name
+- `display_modes`: Array of mode names
+

.cursor/rules/coding-standards.mdc

@@ -0,0 +1,38 @@
+---
+globs: *.py
+---
+
+# Python Coding Standards
+
+## Code Quality Principles
+- **Simplicity First**: Prefer clear, readable code over clever optimizations
+- **Explicit over Implicit**: Make intentions clear through naming and structure
+- **Fail Fast**: Validate inputs and handle errors early
+- **Documentation**: Use docstrings for classes and complex functions
+
+## Naming Conventions
+- **Classes**: PascalCase (e.g., `NHLRecentManager`)
+- **Functions/Variables**: snake_case (e.g., `fetch_game_data`)
+- **Constants**: UPPER_SNAKE_CASE (e.g., `ESPN_NHL_SCOREBOARD_URL`)
+- **Private methods**: Leading underscore (e.g., `_fetch_data`)
+
+## Error Handling
+- **Logging**: Use structured logging with context (e.g., `[NHL Recent]`)
+- **Exceptions**: Catch specific exceptions, not bare `except:`
+- **User-friendly messages**: Explain what went wrong and potential solutions
+- **Graceful degradation**: Continue operation when non-critical features fail
+
+## Manager Pattern
+All sports managers should follow this structure:
+```python
+class BaseManager:
+    def __init__(self, config, display_manager, cache_manager)
+    def update(self)  # Fetch and process data
+    def display(self, force_clear=False)  # Render to display
+```
+
+## Configuration Management
+- **Type hints**: Use for function parameters and return values
+- **Configuration validation**: Check required fields on initialization
+- **Default values**: Provide sensible defaults in code, not config
+- **Environment awareness**: Handle different deployment contexts

.cursor/rules/configuration-management.mdc

@@ -0,0 +1,42 @@
+---
+globs: config/*.json,src/*.py
+---
+
+# Configuration Management
+
+## Configuration Structure
+- **Main config**: [config/config.json](mdc:config/config.json) - Primary configuration
+- **Secrets**: [config/config_secrets.json](mdc:config/config_secrets.json) - API keys and sensitive data
+- **Templates**: [config/config.template.json](mdc:config/config.template.json) - Default values
+
+## Configuration Principles
+- **Validation**: Check required fields and data types on startup
+- **Defaults**: Provide sensible defaults in code, not just config
+- **Environment awareness**: Handle development vs production differences
+- **Security**: Never commit secrets to version control
+
+## Manager Configuration Pattern
+```python
+def __init__(self, config, display_manager, cache_manager):
+    self.mode_config = config.get("sport_scoreboard", {})
+    self.favorite_teams = self.mode_config.get("favorite_teams", [])
+    self.show_favorite_only = self.mode_config.get("show_favorite_teams_only", False)
+```
+
+## Required Configuration Sections
+- **Display settings**: Update intervals, display durations
+- **API settings**: Timeouts, retry logic, rate limiting
+- **Background service**: Threading, caching, priority settings
+- **Team preferences**: Favorite teams, filtering options
+
+## Configuration Validation
+- **Type checking**: Ensure numeric values are numbers, lists are lists
+- **Range validation**: Check that intervals are reasonable
+- **Dependency checking**: Verify required services are available
+- **Fallback values**: Provide defaults when config is missing or invalid
+
+## Best Practices
+- **Documentation**: Comment complex configuration options
+- **Examples**: Provide working examples in templates
+- **Migration**: Handle configuration changes between versions
+- **Testing**: Validate configuration in test environments

.cursor/rules/error-handling-logging.mdc

@@ -0,0 +1,50 @@
+---
+globs: src/*.py
+---
+
+# Error Handling and Logging
+
+## Logging Standards
+- **Structured prefixes**: Use consistent tags like `[NHL Recent]`, `[NFL Live]`
+- **Context information**: Include relevant details (team names, game status, dates)
+- **Appropriate levels**: 
+  - `info`: Normal operations and status updates
+  - `debug`: Detailed information for troubleshooting
+  - `warning`: Non-critical issues that should be noted
+  - `error`: Problems that need attention
+
+## Error Handling Patterns
+```python
+try:
+    data = self._fetch_data()
+    if not data or 'events' not in data:
+        self.logger.warning("[Manager] No events found in API response")
+        return
+except requests.exceptions.RequestException as e:
+    self.logger.error(f"[Manager] API error: {e}")
+    return None
+```
+
+## User-Friendly Messages
+- **Explain the situation**: "No games available during off-season"
+- **Provide context**: "NHL season typically runs October-June"
+- **Suggest solutions**: "Check back when season starts"
+- **Distinguish issues**: API problems vs no data vs filtering results
+
+## Graceful Degradation
+- **Fallback content**: Show alternative games when favorites unavailable
+- **Cached data**: Use cached data when API fails
+- **Service continuity**: Continue operation when non-critical features fail
+- **Clear communication**: Explain what's happening to users
+
+## Debugging Support
+- **Comprehensive logging**: Log API responses, filtering results, display updates
+- **State tracking**: Log current state and transitions
+- **Performance monitoring**: Track timing and resource usage
+- **Error context**: Include stack traces for debugging
+
+## Off-Season Awareness
+- **Seasonal messaging**: Different messages for different times of year
+- **Helpful context**: Explain why no games are available
+- **Future planning**: Mention when season starts
+- **Realistic expectations**: Set appropriate expectations during off-season

.cursor/rules/git-workflow.mdc

@@ -0,0 +1,51 @@
+---
+alwaysApply: true
+---
+
+# Git Workflow and Branching
+
+## Branch Naming Conventions
+- **Features**: `feature/description-of-feature` (e.g., `feature/weather-forecast-improvements`)
+- **Bug fixes**: `fix/description-of-bug` (e.g., `fix/nhl-manager-improvements`)
+- **Hotfixes**: `hotfix/critical-issue-description`
+- **Refactoring**: `refactor/description-of-refactor`
+
+## Commit Message Format
+```
+type(scope): description
+
+[optional body]
+
+[optional footer]
+```
+
+**Types**: feat, fix, docs, style, refactor, test, chore
+**Examples**:
+- `feat(nhl): Add enhanced logging for data visibility`
+- `fix(display): Resolve rendering performance issue`
+- `docs(api): Update ESPN API integration guide`
+
+## Pull Request Guidelines
+- **Self-review**: Review your own PR before requesting review
+- **Testing**: Test thoroughly on Raspberry Pi hardware
+- **Documentation**: Update relevant documentation if needed
+- **Clean history**: Squash commits if necessary for clean history
+
+## Code Review Checklist
+- **Code Quality**: Proper error handling, logging, type hints
+- **Architecture**: Follows project patterns, doesn't break existing functionality
+- **Performance**: No negative impact on display performance
+- **Testing**: Works on Raspberry Pi hardware
+- **Documentation**: Comments added for complex logic
+
+## Merge Strategies
+- **Squash and Merge**: Preferred for feature branches and bug fixes
+- **Merge Commit**: For complex features with multiple logical commits
+- **Rebase and Merge**: For simple, single-commit changes
+
+## Best Practices
+- **Keep branches small and focused**
+- **Commit frequently with meaningful messages**
+- **Update branch regularly with main**
+- **Test changes incrementally**
+- **Delete feature branches after merge**

.cursor/rules/github-branches-rule.mdc

@@ -0,0 +1,213 @@
+---
+description: GitHub branching and pull request best practices for LEDMatrix project
+globs: ["**/*.py", "**/*.md", "**/*.json", "**/*.sh"]
+alwaysApply: true
+---
+
+# GitHub Branching and Pull Request Guidelines
+
+## Branch Naming Conventions
+
+### Feature Branches
+- **Format**: `feature/description-of-feature`
+- **Examples**: 
+  - `feature/weather-forecast-improvements`
+  - `feature/stock-api-integration`
+  - `feature/nba-live-scores`
+
+### Bug Fix Branches
+- **Format**: `fix/description-of-bug`
+- **Examples**:
+  - `fix/leaderboard-scrolling-performance`
+  - `fix/weather-api-timeout`
+  - `fix/display-rendering-issue`
+
+### Hotfix Branches
+- **Format**: `hotfix/critical-issue-description`
+- **Examples**:
+  - `hotfix/display-crash-fix`
+  - `hotfix/api-rate-limit-fix`
+
+### Refactoring Branches
+- **Format**: `refactor/description-of-refactor`
+- **Examples**:
+  - `refactor/sports-manager-architecture`
+  - `refactor/cache-management-system`
+
+## Branch Management Rules
+
+### Main Branch Protection
+- **`main`** branch is protected and requires PR reviews
+- Never commit directly to `main`
+- All changes must go through pull requests
+
+### Branch Lifecycle
+1. **Create** branch from `main` when starting work
+2. **Keep** branch up-to-date with `main` regularly
+3. **Test** thoroughly before creating PR
+4. **Delete** branch after successful merge
+
+### Branch Updates
+```bash
+# Before starting new work
+git checkout main
+git pull origin main
+
+# Create new branch
+git checkout -b feature/your-feature-name
+
+# Keep branch updated during development
+git checkout main
+git pull origin main
+git checkout feature/your-feature-name
+git merge main
+```
+
+## Pull Request Guidelines
+
+### PR Title Format
+- **Feature**: `feat: Add weather forecast improvements`
+- **Fix**: `fix: Resolve leaderboard scrolling performance issue`
+- **Refactor**: `refactor: Improve sports manager architecture`
+- **Docs**: `docs: Update API integration guide`
+- **Test**: `test: Add unit tests for weather manager`
+
+### PR Description Template
+```markdown
+## Description
+Brief description of changes and motivation.
+
+## Type of Change
+- [ ] Bug fix (non-breaking change)
+- [ ] New feature (non-breaking change)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+- [ ] Documentation update
+- [ ] Performance improvement
+- [ ] Refactoring
+
+## Testing
+- [ ] Tested on Raspberry Pi hardware
+- [ ] Verified display rendering works correctly
+- [ ] Checked API integration functionality
+- [ ] Tested error handling scenarios
+
+## Screenshots/Videos
+(If applicable, add screenshots or videos of the changes)
+
+## Checklist
+- [ ] Code follows project style guidelines
+- [ ] Self-review completed
+- [ ] Comments added for complex logic
+- [ ] No hardcoded values or API keys
+- [ ] Error handling implemented
+- [ ] Logging added where appropriate
+```
+
+### PR Review Requirements
+
+#### For Reviewers
+- **Code Quality**: Check for proper error handling, logging, and type hints
+- **Architecture**: Ensure changes follow project patterns and don't break existing functionality
+- **Performance**: Verify changes don't negatively impact display performance
+- **Testing**: Confirm changes work on Raspberry Pi hardware
+- **Documentation**: Check if documentation needs updates
+
+#### For Authors
+- **Self-Review**: Review your own PR before requesting review
+- **Testing**: Test thoroughly on Pi hardware before submitting
+- **Documentation**: Update relevant documentation if needed
+- **Clean History**: Squash commits if necessary for clean history
+
+## Commit Message Guidelines
+
+### Format
+```
+type(scope): description
+
+[optional body]
+
+[optional footer]
+```
+
+### Types
+- **feat**: New feature
+- **fix**: Bug fix
+- **docs**: Documentation changes
+- **style**: Code style changes (formatting, etc.)
+- **refactor**: Code refactoring
+- **test**: Adding or updating tests
+- **chore**: Maintenance tasks
+
+### Examples
+```
+feat(weather): Add hourly forecast display
+fix(nba): Resolve live score update issue
+docs(api): Update ESPN API integration guide
+refactor(sports): Improve base class architecture
+```
+
+## Merge Strategies
+
+### Squash and Merge (Preferred)
+- Use for feature branches and bug fixes
+- Creates clean, linear history
+- Combines all commits into single commit
+
+### Merge Commit
+- Use for complex features with multiple logical commits
+- Preserves commit history
+- Use when commit messages are meaningful
+
+### Rebase and Merge
+- Use sparingly for simple, single-commit changes
+- Creates linear history without merge commits
+
+## Release Management
+
+### Version Tags
+- Use semantic versioning: `v1.2.3`
+- Tag releases on `main` branch
+- Create release notes with technical details
+
+### Release Branches
+- **Format**: `release/v1.2.3`
+- Use for release preparation
+- Include version bumps and final testing
+
+## Emergency Procedures
+
+### Hotfix Process
+1. Create `hotfix/` branch from `main`
+2. Make minimal fix
+3. Test thoroughly
+4. Create PR with expedited review
+5. Merge to `main` and tag release
+6. Cherry-pick to other branches if needed
+
+### Rollback Process
+1. Identify last known good commit
+2. Create revert PR if possible
+3. Use `git revert` for clean rollback
+4. Tag rollback release
+5. Document issue and resolution
+
+## Best Practices
+
+### Before Creating PR
+- [ ] Run all tests locally
+- [ ] Test on Raspberry Pi hardware
+- [ ] Check for linting errors
+- [ ] Update documentation if needed
+- [ ] Ensure commit messages are clear
+
+### During Development
+- [ ] Keep branches small and focused
+- [ ] Commit frequently with meaningful messages
+- [ ] Update branch regularly with main
+- [ ] Test changes incrementally
+
+### After PR Approval
+- [ ] Delete feature branch after merge
+- [ ] Update local main branch
+- [ ] Verify changes work in production
+- [ ] Update any related documentation

.cursor/rules/project-structure.mdc

@@ -0,0 +1,23 @@
+---
+alwaysApply: true
+---
+
+# LEDMatrix Project Structure
+
+## Core Architecture
+- **Main entry point**: [run.py](mdc:run.py) - Primary application launcher
+- **Configuration**: [config/config.json](mdc:config/config.json) - Main configuration file
+- **Display management**: [src/display_controller.py](mdc:src/display_controller.py) - Core display logic
+- **Web interface**: [web_interface_v2.py](mdc:web_interface_v2.py) - Modern web UI
+
+## Source Code Organization
+- **Managers**: [src/](mdc:src/) - All sports/weather/stock managers
+- **Assets**: [assets/](mdc:assets/) - Logos, fonts, and static resources
+- **Tests**: [test/](mdc:test/) - Unit and integration tests
+- **Documentation**: [LEDMatrix.wiki/](mdc:LEDMatrix.wiki/) - Comprehensive guides
+
+## Key Design Principles
+- **Single Responsibility**: Each manager handles one sport/domain
+- **Consistent Patterns**: All managers follow similar structure
+- **Configuration-Driven**: Behavior controlled via [config/config.json](mdc:config/config.json)
+- **Raspberry Pi Focus**: Optimized for Pi hardware, not Windows development

.cursor/rules/raspberry-pi-development.mdc

@@ -0,0 +1,41 @@
+---
+alwaysApply: true
+---
+
+# Raspberry Pi Development Guidelines
+
+## Hardware Constraints
+- **Pi-only execution**: Code must run on Raspberry Pi, not Windows development machine
+- **LED matrix library**: Uses [rpi-rgb-led-matrix-master/](mdc:rpi-rgb-led-matrix-master/) for hardware control
+- **Memory limitations**: Optimize for Pi's limited RAM
+- **Performance**: Consider Pi's CPU capabilities in design
+
+## Development Workflow
+- **Local development**: Write and test code on Windows
+- **Pi deployment**: Deploy and test on actual Pi hardware
+- **SSH access**: Use SSH for Pi-based testing and debugging
+- **Service management**: Use systemd services for production deployment
+
+## Testing Strategy
+- **Unit tests**: Test logic without hardware dependencies
+- **Integration tests**: Test with mock display managers
+- **Hardware tests**: Validate on actual Pi with LED matrix
+- **Performance tests**: Monitor memory and CPU usage
+
+## Deployment Considerations
+- **Service files**: [ledmatrix.service](mdc:ledmatrix.service), [ledmatrix-web.service](mdc:ledmatrix-web.service)
+- **Installation scripts**: [first_time_install.sh](mdc:first_time_install.sh), [install_service.sh](mdc:install_service.sh)
+- **Dependencies**: [requirements.txt](mdc:requirements.txt) for Pi environment
+- **Permissions**: Handle file permissions for Pi user
+
+## Performance Optimization
+- **Caching**: Use [src/cache_manager.py](mdc:src/cache_manager.py) for data persistence
+- **Background services**: Non-blocking data fetching
+- **Memory management**: Clean up resources regularly
+- **Display optimization**: Minimize unnecessary redraws
+
+## Debugging on Pi
+- **Logging**: Comprehensive logging for remote debugging
+- **Error reporting**: Clear error messages for troubleshooting
+- **Status monitoring**: Health checks and status reporting
+- **Remote access**: Web interface for configuration and monitoring

.cursor/rules/sports-managers.mdc

@@ -0,0 +1,42 @@
+---
+globs: src/*_managers.py
+---
+
+# Sports Manager Development
+
+## Manager Architecture
+All sports managers inherit from base classes and follow consistent patterns:
+- **Base classes**: [src/nhl_managers.py](mdc:src/nhl_managers.py), [src/nfl_managers.py](mdc:src/nfl_managers.py)
+- **Common functionality**: Data fetching, caching, display rendering
+- **Configuration-driven**: Behavior controlled via config sections
+
+## Required Methods
+```python
+def __init__(self, config, display_manager, cache_manager)
+def update(self)  # Fetch fresh data
+def display(self, force_clear=False)  # Render current data
+```
+
+## Data Flow Pattern
+1. **Fetch**: Get data from API (with caching)
+2. **Process**: Extract relevant game information
+3. **Filter**: Apply favorite team preferences
+4. **Display**: Render to LED matrix
+
+## Logging Standards
+- **Structured prefixes**: `[NHL Recent]`, `[NFL Live]`, etc.
+- **Context information**: Include team names, game status, dates
+- **Debug levels**: Use appropriate log levels (info, debug, warning, error)
+- **User-friendly messages**: Explain what's happening and why
+
+## Error Handling
+- **API failures**: Log and continue with cached data if available
+- **No data scenarios**: Distinguish between API issues vs no games available
+- **Off-season awareness**: Provide helpful context during non-active periods
+- **Fallback behavior**: Show alternative content when preferred content unavailable
+
+## Configuration Integration
+- **Required settings**: Validate on initialization
+- **Optional settings**: Provide sensible defaults
+- **Background service**: Use for non-blocking data fetching
+- **Caching strategy**: Implement intelligent cache management

.cursor/rules/testing-standards.mdc

@@ -0,0 +1,51 @@
+---
+globs: test/*.py,src/*.py
+---
+
+# Testing Standards
+
+## Test Organization
+- **Test directory**: [test/](mdc:test/) - All test files
+- **Unit tests**: Test individual components in isolation
+- **Integration tests**: Test component interactions
+- **Hardware tests**: Validate on Raspberry Pi with actual LED matrix
+
+## Testing Principles
+- **Test behavior, not implementation**: Focus on what the code does, not how
+- **Mock external dependencies**: Use mocks for APIs, display managers, cache
+- **Test edge cases**: Empty data, API failures, configuration errors
+- **Pi-specific testing**: Validate hardware integration
+
+## Test Structure
+```python
+def test_manager_initialization():
+    """Test that manager initializes with valid config"""
+    config = {"sport_scoreboard": {"enabled": True}}
+    manager = ManagerClass(config, mock_display, mock_cache)
+    assert manager.enabled == True
+
+def test_api_failure_handling():
+    """Test graceful handling of API failures"""
+    # Test that system continues when API fails
+    # Verify fallback to cached data
+    # Check appropriate error logging
+```
+
+## Mock Patterns
+- **Display Manager**: Mock for testing without hardware
+- **Cache Manager**: Mock for testing data persistence
+- **API responses**: Mock for consistent test data
+- **Configuration**: Use test-specific configs
+
+## Test Categories
+- **Unit tests**: Individual manager methods
+- **Integration tests**: Manager interactions with services
+- **Configuration tests**: Validate config loading and validation
+- **Error handling tests**: API failures, invalid data, edge cases
+
+## Testing Best Practices
+- **Descriptive names**: Test names should explain what they test
+- **Single responsibility**: Each test should verify one thing
+- **Independent tests**: Tests should not depend on each other
+- **Clean setup/teardown**: Reset state between tests
+- **Pi compatibility**: Ensure tests work in Pi environment

.cursorignore

@@ -0,0 +1 @@
+# Add directories or file patterns to ignore during indexing (e.g. foo/ or *.csv)

.cursorrules

@@ -0,0 +1,363 @@
+# LEDMatrix Plugin Development Rules
+
+## Plugin System Overview
+
+The LEDMatrix project uses a plugin-based architecture. All display
+functionality (except core calendar) is implemented as plugins that are
+dynamically loaded from the directory configured by
+`plugin_system.plugins_directory` in `config.json` — the default is
+`plugin-repos/` (per `config/config.template.json:130`).
+
+> **Fallback note (scoped):** `PluginManager.discover_plugins()`
+> (`src/plugin_system/plugin_manager.py:154`) only scans the
+> configured directory — there is no fallback to `plugins/` in the
+> main discovery path. A fallback to `plugins/` does exist in two
+> narrower places:
+> - `store_manager.py:1700-1718` — store operations (install/update/
+>   uninstall) check `plugins/` if the plugin isn't found in the
+>   configured directory, so plugin-store flows work even when your
+>   dev symlinks live in `plugins/`.
+> - `schema_manager.py:70-80` — `get_schema_path()` probes both
+>   `plugins/` and `plugin-repos/` for `config_schema.json` so the
+>   web UI form generation finds the schema regardless of where the
+>   plugin lives.
+>
+> The dev workflow in `scripts/dev/dev_plugin_setup.sh` creates
+> symlinks under `plugins/`, which is why the store and schema
+> fallbacks exist. For day-to-day development, set
+> `plugin_system.plugins_directory` to `plugins` so the main
+> discovery path picks up your symlinks.
+
+## Plugin Structure
+
+### Required Files
+- **manifest.json**: Plugin metadata, entry point, class name, dependencies
+- **manager.py**: Main plugin class (must inherit from `BasePlugin`)
+- **config_schema.json**: JSON schema for plugin configuration validation
+- **requirements.txt**: Python dependencies (if any)
+- **README.md**: Plugin documentation
+
+### Plugin Class Requirements
+- Must inherit from `src.plugin_system.base_plugin.BasePlugin`
+- Must implement `update()` method for data fetching
+- Must implement `display()` method for rendering
+- Should implement `validate_config()` for configuration validation
+- Optional: Override `has_live_content()` for live priority features
+
+## Plugin Development Workflow
+
+### 1. Creating a New Plugin
+
+**Option A: Use dev_plugin_setup.sh (Recommended)**
+```bash
+# Link from GitHub
+./scripts/dev/dev_plugin_setup.sh link-github <plugin-name>
+
+# Link local repository
+./scripts/dev/dev_plugin_setup.sh link <plugin-name> <path-to-repo>
+```
+
+**Option B: Manual Setup**
+1. Create directory in `plugin-repos/<plugin-id>/` (or `plugins/<plugin-id>/`
+   if you're using the dev fallback location)
+2. Add `manifest.json` with required fields
+3. Create `manager.py` with plugin class
+4. Add `config_schema.json` for configuration
+5. Enable plugin in `config/config.json` under `"<plugin-id>": {"enabled": true}`
+
+### 2. Plugin Configuration
+
+Plugins are configured in `config/config.json`:
+```json
+{
+  "<plugin-id>": {
+    "enabled": true,
+    "display_duration": 15,
+    "live_priority": false,
+    "high_performance_transitions": false,
+    "transition": {
+      "type": "redraw",
+      "speed": 2,
+      "enabled": true
+    },
+    // ... plugin-specific config
+  }
+}
+```
+
+### 3. Testing Plugins
+
+**On Development Machine:**
+- Run the dev preview server: `python3 scripts/dev_server.py` (then
+  open `http://localhost:5001`) — renders plugins in the browser
+  without running the full display loop
+- Or run the full display in emulator mode:
+  `python3 run.py --emulator` (or equivalently
+  `EMULATOR=true python3 run.py`, or `./scripts/dev/run_emulator.sh`).
+  The `-e`/`--emulator` CLI flag is defined in `run.py:19-20`.
+- Test plugin loading: Check logs for plugin discovery and loading
+- Validate configuration: Ensure config matches `config_schema.json`
+
+**On Raspberry Pi:**
+- Deploy and test on actual hardware
+- Monitor logs: `journalctl -u ledmatrix -f` (if running as service)
+- Check plugin status in web interface
+
+### 4. Plugin Development Best Practices
+
+**Code Organization:**
+- Keep plugin code in `plugin-repos/<plugin-id>/` (or its dev-time
+  symlink in `plugins/<plugin-id>/`)
+- Use shared assets from `assets/` directory when possible
+- Follow existing plugin patterns — canonical sources live in the
+  [`ledmatrix-plugins`](https://github.com/ChuckBuilds/ledmatrix-plugins)
+  repo (`plugins/hockey-scoreboard/`, `plugins/football-scoreboard/`,
+  `plugins/clock-simple/`, etc.)
+- Place shared utilities in `src/common/` if reusable across plugins
+
+**Configuration Management:**
+- Use `config_schema.json` for validation
+- Store secrets in `config/config_secrets.json` under the same plugin
+  id namespace as the main config — they're deep-merged into the main
+  config at load time (`src/config_manager.py:162-172`), so plugin
+  code reads them directly from `config.get(...)` like any other key
+- There is no separate `config_secrets` reference field
+- Validate all required fields in `validate_config()`
+
+**Error Handling:**
+- Use plugin's logger: `self.logger.info/error/warning()`
+- Handle API failures gracefully
+- Cache data to avoid excessive API calls
+- Provide fallback displays when data unavailable
+
+**Performance:**
+- Use `cache_manager` for API response caching
+- Implement background data fetching if needed
+- Use `high_performance_transitions` for smoother animations
+- Optimize rendering for Pi's limited resources
+
+**Display Rendering:**
+- Use `display_manager` for all drawing operations
+- Support different display sizes (check `display_manager.width/height`)
+- Use `apply_transition()` for smooth transitions between displays
+- Clear display before rendering: `display_manager.clear()`
+- Always call `display_manager.update_display()` after rendering
+
+## Plugin API Reference
+
+### BasePlugin Class
+Located in: `src/plugin_system/base_plugin.py`
+
+**Required Methods:**
+- `update()`: Fetch/update data (called based on `update_interval` in manifest)
+- `display(force_clear=False)`: Render plugin content
+
+**Optional Methods:**
+- `validate_config()`: Validate plugin configuration
+- `has_live_content()`: Return True if plugin has live/urgent content
+- `get_live_modes()`: Return list of modes for live priority
+- `cleanup()`: Clean up resources on unload
+- `on_config_change(new_config)`: Handle config updates
+- `on_enable()`: Called when plugin enabled
+- `on_disable()`: Called when plugin disabled
+
+**Available Properties:**
+- `self.plugin_id`: Plugin identifier
+- `self.config`: Plugin configuration dict
+- `self.display_manager`: Display manager instance
+- `self.cache_manager`: Cache manager instance
+- `self.plugin_manager`: Plugin manager reference
+- `self.logger`: Plugin-specific logger
+- `self.enabled`: Boolean enabled status
+- `self.transition_manager`: Transition system (if available)
+
+### Display Manager
+Located in: `src/display_manager.py`
+
+**Key Methods:**
+- `clear()`: Clear the display
+- `draw_text(text, x, y, color, font, small_font, centered)`: Draw text
+- `update_display()`: Push the buffer to the physical display
+- `draw_weather_icon(condition, x, y, size)`: Draw a weather icon
+- `width`, `height`: Display dimensions
+
+**Image rendering**: there is no `draw_image()` helper. Paste directly
+onto the underlying PIL Image:
+```python
+self.display_manager.image.paste(pil_image, (x, y))
+self.display_manager.update_display()
+```
+For transparency, paste with a mask: `image.paste(rgba, (x, y), rgba)`.
+
+### Cache Manager
+Located in: `src/cache_manager.py`
+
+**Key Methods:**
+- `get(key, max_age=300)`: Get cached value (returns None if missing/stale)
+- `set(key, value, ttl=None)`: Cache a value
+- `clear_cache(key=None)`: Remove a cache entry, or all entries if `key`
+  is omitted. There is no `delete()` method.
+- `get_cached_data_with_strategy(key, data_type)`: Cache get with
+  data-type-aware TTL strategy
+- `get_background_cached_data(key, sport_key)`: Cache get for the
+  background-fetch service path
+
+## Plugin Manifest Schema
+
+Required fields in `manifest.json`:
+- `id`: Unique plugin identifier (matches directory name)
+- `name`: Human-readable plugin name
+- `version`: Semantic version (e.g., "1.0.0")
+- `entry_point`: Python file (usually "manager.py")
+- `class_name`: Plugin class name (must match class in entry_point)
+- `display_modes`: Array of mode names this plugin provides
+
+Common optional fields:
+- `description`: Plugin description
+- `author`: Plugin author
+- `homepage`: Plugin homepage URL
+- `category`: Plugin category (e.g., "sports", "weather")
+- `tags`: Array of tags
+- `update_interval`: Seconds between update() calls (default: 60)
+- `default_duration`: Default display duration (default: 15)
+- `requires`: Python version, display size requirements
+- `config_schema`: Path to config schema file
+- `api_requirements`: API dependencies and rate limits
+
+## Plugin Loading Process
+
+1. **Discovery**: PluginManager scans `plugins/` directory for directories containing `manifest.json`
+2. **Validation**: Validates manifest structure and required fields
+3. **Loading**: Imports plugin module and instantiates plugin class
+4. **Configuration**: Loads plugin config from `config/config.json`
+5. **Validation**: Calls `validate_config()` on plugin instance
+6. **Registration**: Adds plugin to available modes and stores instance
+7. **Enablement**: Calls `on_enable()` if plugin is enabled
+
+## Common Plugin Patterns
+
+### Sports Scoreboard Plugin
+- Use `background_data_service.py` pattern for API fetching
+- Implement live/recent/upcoming game modes
+- Use `scoreboard_renderer.py` for consistent rendering
+- Support team filtering and game filtering
+- Use shared sports logos from `assets/sports/`
+
+### Data Display Plugin
+- Fetch data in `update()` method
+- Cache API responses using `cache_manager`
+- Render in `display()` method
+- Handle API errors gracefully
+- Provide configuration for refresh intervals
+
+### Real-time Content Plugin
+- Implement `has_live_content()` for live priority
+- Use `get_live_modes()` to specify which modes are live
+- Set `live_priority: true` in config to enable live takeover
+- Update data frequently when live content exists
+
+## Debugging Plugins
+
+**Check Plugin Loading:**
+- Review logs for plugin discovery messages
+- Verify manifest.json syntax is valid JSON
+- Check that class_name matches actual class name
+- Ensure entry_point file exists and is importable
+
+**Check Plugin Execution:**
+- Add logging statements in `update()` and `display()`
+- Use `self.logger` for plugin-specific logging
+- Check cache_manager for cached data
+- Verify display_manager is rendering correctly
+
+**Common Issues:**
+- Import errors: Check Python path and dependencies
+- Config errors: Validate against config_schema.json
+- Display issues: Check display dimensions and coordinate calculations
+- Performance: Monitor CPU/memory usage on Pi
+
+## Plugin Testing
+
+**Unit Tests:**
+- Test plugin class instantiation
+- Test `update()` data fetching logic
+- Test `display()` rendering logic
+- Test `validate_config()` with various configs
+- Mock `display_manager` and `cache_manager` for testing
+
+**Integration Tests:**
+- Test plugin loading via PluginManager
+- Test plugin with actual config
+- Test plugin with emulator display
+- Test plugin with cache_manager
+
+**Hardware Tests:**
+- Test on Raspberry Pi with LED matrix
+- Verify display rendering on actual hardware
+- Test performance under load
+- Test with other plugins enabled
+
+## File Organization
+
+```
+plugins/
+  <plugin-id>/
+    manifest.json          # Plugin metadata
+    manager.py             # Main plugin class
+    config_schema.json     # Config validation schema
+    requirements.txt       # Python dependencies
+    README.md             # Plugin documentation
+    # Plugin-specific files
+    data_manager.py
+    renderer.py
+    etc.
+```
+
+## Git Workflow for Plugins
+
+**Plugin Development:**
+- Plugins are typically separate repositories
+- Use `dev_plugin_setup.sh` to link plugins for development
+- Symlinks are used to connect plugin repos to `plugins/` directory
+- Plugin repos follow naming: `ledmatrix-<plugin-name>`
+
+**Branching:**
+- Develop plugins in feature branches
+- Follow project branching conventions
+- Test plugins before merging to main
+
+**Automatic Version Bumping:**
+- **Automatic Version Management**: Version bumping is handled automatically via the pre-push git hook - no manual version bumping is required for normal development workflows
+- **GitHub as Source of Truth**: Plugin store always fetches latest versions from GitHub (releases/tags/manifest/commit)
+- **Pre-Push Hook**: Automatically bumps patch version and creates git tags when pushing code changes
+  - The hook is self-contained (no external dependencies) and works on any dev machine
+  - Installation: Copy the hook from LEDMatrix repo to your plugin repo:
+    ```bash
+    # From your plugin repository directory
+    cp /path/to/LEDMatrix/scripts/git-hooks/pre-push-plugin-version .git/hooks/pre-push
+    chmod +x .git/hooks/pre-push
+    ```
+  - Or use the installer script from the main LEDMatrix repo (one-time setup)
+  - The hook automatically:
+    1. Bumps the patch version (x.y.Z) in manifest.json when code changes are detected
+    2. Creates a git tag (v{version}) for the new version
+    3. Stages manifest.json for commit
+  - Skip auto-tagging: Set `SKIP_TAG=1` environment variable before pushing
+- **Manual Version Bumping (Edge Cases Only)**: Manual version bumps are only needed in rare circumstances:
+  - CI/CD pipelines that bypass git hooks
+  - Forked repositories without the pre-push hook installed
+  - Major/minor version bumps (hook only handles patch versions)
+  - When skipping auto-tagging but still needing a version bump
+  - For manual bumps, use the standalone script: `scripts/bump_plugin_version.py`
+- **Registry**: The plugin registry (plugins.json) stores only metadata (name, description, repo URL) - no versions
+- **Version Priority**: Plugin store checks versions in this order: GitHub Releases → GitHub Tags → Manifest from branch → Git commit hash
+
+## Resources
+
+- Plugin System Docs: `docs/PLUGIN_ARCHITECTURE_SPEC.md`
+- Plugin Examples: `plugins/hockey-scoreboard/`, `plugins/football-scoreboard/`
+- Base Plugin: `src/plugin_system/base_plugin.py`
+- Plugin Manager: `src/plugin_system/plugin_manager.py`
+- Development Setup: `dev_plugin_setup.sh`
+- Example Config: `dev_plugins.json.example`
+

.github/FUNDING.yml

@@ -0,0 +1,4 @@
+github: ChuckBuilds
+buy_me_a_coffee: chuckbuilds
+ko_fi: chuckbuilds
+

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,38 +1,84 @@
 ---
 name: Bug report
-about: Create a report to help us improve
+about: Report a problem with LEDMatrix
 title: ''
-labels: ''
+labels: bug
 assignees: ''
 
 ---
 
-**Describe the bug**
-A clear and concise description of what the bug is.
+<!--
+Before filing: please check existing issues to see if this is already
+reported. For security issues, see SECURITY.md and report privately.
+-->
 
-**To Reproduce**
-Steps to reproduce the behavior:
-1. Go to '...'
-2. Click on '....'
-3. Scroll down to '....'
-4. See error
+## Describe the bug
 
-**Expected behavior**
-A clear and concise description of what you expected to happen.
+<!-- A clear and concise description of what the bug is. -->
 
-**Screenshots**
-If applicable, add screenshots to help explain your problem.
+## Steps to reproduce
 
-**Desktop (please complete the following information):**
- - OS: [e.g. iOS]
- - Browser [e.g. chrome, safari]
- - Version [e.g. 22]
+1.
+2.
+3.
 
-**Smartphone (please complete the following information):**
- - Device: [e.g. iPhone6]
- - OS: [e.g. iOS8.1]
- - Browser [e.g. stock browser, safari]
- - Version [e.g. 22]
+## Expected behavior
 
-**Additional context**
-Add any other context about the problem here.
+<!-- What you expected to happen. -->
+
+## Actual behavior
+
+<!-- What actually happened. Include any error messages. -->
+
+## Hardware
+
+- **Raspberry Pi model**: <!-- e.g. Pi 3B+, Pi 4 8GB, Pi Zero 2W -->
+- **OS / kernel**: <!-- output of `cat /etc/os-release` and `uname -a` -->
+- **LED matrix panels**: <!-- e.g. 2x Adafruit 64x32, 1x Waveshare 96x48 -->
+- **HAT / Bonnet**: <!-- e.g. Adafruit RGB Matrix Bonnet, Electrodragon HAT -->
+- **PWM jumper mod soldered?**: <!-- yes / no -->
+- **Display chain**: <!-- chain_length × parallel, e.g. "2x1" -->
+
+## LEDMatrix version
+
+<!-- Run `git rev-parse HEAD` in the LEDMatrix directory, or paste the
+release tag if you installed from a release. -->
+
+```
+git commit:
+```
+
+## Plugin involved (if any)
+
+- **Plugin id**:
+- **Plugin version** (from `manifest.json`):
+
+## Configuration
+
+<!-- Paste the relevant section from config/config.json. Redact any
+API keys before pasting. For display issues, the `display.hardware`
+block is most relevant. For plugin issues, paste that plugin's section. -->
+
+```json
+```
+
+## Logs
+
+<!-- The first 50 lines of the relevant log are usually enough. Run:
+  sudo journalctl -u ledmatrix -n 100 --no-pager
+or for the web service:
+  sudo journalctl -u ledmatrix-web -n 100 --no-pager
+-->
+
+```
+```
+
+## Screenshots / video (optional)
+
+<!-- A photo of the actual display, or a screenshot of the web UI,
+helps a lot for visual issues. -->
+
+## Additional context
+
+<!-- Anything else that might be relevant: when did this start happening,
+what's different about your setup, what have you already tried, etc. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,62 @@
+# Pull Request
+
+## Summary
+
+<!-- 1-3 sentences describing what this PR does and why. -->
+
+## Type of change
+
+<!-- Check all that apply. -->
+
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Documentation
+- [ ] Refactor (no functional change)
+- [ ] Build / CI
+- [ ] Plugin work (link to the plugin)
+
+## Related issues
+
+<!-- "Fixes #123" or "Refs #123". Use "Fixes" for bug PRs so the issue
+auto-closes when this merges. -->
+
+## Test plan
+
+<!-- How did you test this? Check all that apply. Add details for any
+checked box. -->
+
+- [ ] Ran on a real Raspberry Pi with hardware
+- [ ] Ran in emulator mode (`EMULATOR=true python3 run.py`)
+- [ ] Ran the dev preview server (`scripts/dev_server.py`)
+- [ ] Ran the test suite (`pytest`)
+- [ ] Manually verified the affected code path in the web UI
+- [ ] N/A — documentation-only change
+
+## Documentation
+
+- [ ] I updated `README.md` if user-facing behavior changed
+- [ ] I updated the relevant doc in `docs/` if developer behavior changed
+- [ ] I added/updated docstrings on new public functions
+- [ ] N/A — no docs needed
+
+## Plugin compatibility
+
+<!-- For changes to BasePlugin, the plugin loader, the web UI, or the
+config schema. -->
+
+- [ ] No plugin breakage expected
+- [ ] Some plugins will need updates — listed below
+- [ ] N/A — change doesn't touch the plugin system
+
+## Checklist
+
+- [ ] My commits follow the message convention in `CONTRIBUTING.md`
+- [ ] I read `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md`
+- [ ] I've not committed any secrets or hardcoded API keys
+- [ ] If this adds a new config key, the form in the web UI was
+      verified (the form is generated from `config_schema.json`)
+
+## Notes for reviewer
+
+<!-- Anything reviewers should know — gotchas, things you weren't
+sure about, decisions you'd like a second opinion on. -->

.gitignore

@@ -7,6 +7,7 @@ __pycache__/
 config/config_secrets.json
 config/config.json
 config/config.json.backup
+config/wifi_config.json
 credentials.json
 token.pickle
 
@@ -15,6 +16,7 @@ token.pickle
 .venv
 env/
 venv/
+venv*/
 ENV/
 
 # IDE
@@ -22,6 +24,26 @@ ENV/
 .idea/
 *.swp
 *.swo 
+emulator_config.json
 
-# Cache directory
-cache/
+# Testing
+.pytest_cache/
+.coverage
+htmlcov/
+.mypy_cache/
+
+# Cache directory (root level only, not src/cache which is source code)
+/cache/
+
+# Development plugins directory
+# Plugins are managed as separate repositories via multi-root workspace
+# See docs/MULTI_ROOT_WORKSPACE_SETUP.md for details
+plugins/*
+!plugins/.gitkeep
+
+# Binary files and backups
+bin/pixlet/
+config/backups/
+
+# Starlark apps runtime storage (installed .star files and cached renders)
+/starlark-apps/

.gitmodules

@@ -0,0 +1,3 @@
+[submodule "rpi-rgb-led-matrix-master"]
+	path = rpi-rgb-led-matrix-master
+	url = https://github.com/hzeller/rpi-rgb-led-matrix.git

.pre-commit-config.yaml

@@ -0,0 +1,64 @@
+# Pre-commit hooks for LEDMatrix
+# Install: pip install pre-commit && pre-commit install
+# Run manually: pre-commit run --all-files
+
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.5.0
+    hooks:
+      - id: trailing-whitespace
+      - id: end-of-file-fixer
+      - id: check-yaml
+      - id: check-json
+      - id: check-added-large-files
+        args: ['--maxkb=1000']
+      - id: check-merge-conflict
+
+  - repo: https://github.com/PyCQA/flake8
+    rev: 7.0.0
+    hooks:
+      - id: flake8
+        args: ['--select=E9,F63,F7,F82,B', '--ignore=E501']
+        additional_dependencies: [flake8-bugbear]
+
+  - repo: local
+    hooks:
+      - id: no-bare-except
+        name: Check for bare except clauses
+        entry: bash -c 'if grep -rn "except:\s*pass" src/; then echo "Found bare except:pass - please handle exceptions properly"; exit 1; fi'
+        language: system
+        types: [python]
+        pass_filenames: false
+
+      - id: no-hardcoded-paths
+        name: Check for hardcoded user paths
+        entry: bash -c 'if grep -rn "/home/chuck/" src/; then echo "Found hardcoded user paths - please use relative paths or config"; exit 1; fi'
+        language: system
+        types: [python]
+        pass_filenames: false
+
+  - repo: https://github.com/pre-commit/mirrors-mypy
+    rev: v1.8.0
+    hooks:
+      - id: mypy
+        additional_dependencies: [types-requests, types-pytz]
+        args: [--ignore-missing-imports, --no-error-summary]
+        pass_filenames: false
+        files: ^src/
+
+  - repo: https://github.com/PyCQA/bandit
+    rev: 1.8.3
+    hooks:
+      - id: bandit
+        args:
+          - '-r'
+          - '-ll'
+          - '-c'
+          - 'bandit.yaml'
+          - '-x'
+          - './tests,./test,./venv,./.venv,./scripts/prove_security.py,./rpi-rgb-led-matrix-master'
+
+  - repo: https://github.com/gitleaks/gitleaks
+    rev: v8.24.3
+    hooks:
+      - id: gitleaks

CLAUDE.md

@@ -0,0 +1,37 @@
+# LEDMatrix
+
+## Project Structure
+- `src/plugin_system/` — Plugin loader, manager, store manager, base plugin class
+- `web_interface/` — Flask web UI (blueprints, templates, static JS)
+- `config/config.json` — User plugin configuration (persists across plugin reinstalls)
+- `plugin-repos/` — **Default** plugin install directory used by the
+  Plugin Store, set by `plugin_system.plugins_directory` in
+  `config.json` (default per `config/config.template.json:130`).
+  Not gitignored.
+- `plugins/` — Legacy/dev plugin location. Gitignored (`plugins/*`).
+  Used by `scripts/dev/dev_plugin_setup.sh` for symlinks. The plugin
+  loader falls back to it when something isn't found in `plugin-repos/`
+  (`src/plugin_system/schema_manager.py:77`).
+
+## Plugin System
+- Plugins inherit from `BasePlugin` in `src/plugin_system/base_plugin.py`
+- Required abstract methods: `update()`, `display(force_clear=False)`
+- Each plugin needs: `manifest.json`, `config_schema.json`, `manager.py`, `requirements.txt`
+- Plugin instantiation args: `plugin_id, config, display_manager, cache_manager, plugin_manager`
+- Config schemas use JSON Schema Draft-7
+- Display dimensions: always read dynamically from `self.display_manager.matrix.width/height`
+
+## Plugin Store Architecture
+- Official plugins live in the `ledmatrix-plugins` monorepo (not individual repos)
+- Plugin repo naming convention: `ledmatrix-<plugin-id>` (e.g., `ledmatrix-football-scoreboard`)
+- `plugins.json` registry at `https://raw.githubusercontent.com/ChuckBuilds/ledmatrix-plugins/main/plugins.json`
+- Store manager (`src/plugin_system/store_manager.py`) handles install/update/uninstall
+- Monorepo plugins are installed via ZIP extraction (no `.git` directory)
+- Update detection for monorepo plugins uses version comparison (manifest version vs registry latest_version)
+- Plugin configs stored in `config/config.json`, NOT in plugin directories — safe across reinstalls
+- Third-party plugins can use their own repo URL with empty `plugin_path`
+
+## Common Pitfalls
+- paho-mqtt 2.x needs `callback_api_version=mqtt.CallbackAPIVersion.VERSION1` for v1 compat
+- BasePlugin uses `get_logger()` from `src.logging_config`, not standard `logging.getLogger()`
+- When modifying a plugin in the monorepo, you MUST bump `version` in its `manifest.json` and run `python update_registry.py` — otherwise users won't receive the update

CODE_OF_CONDUCT.md

@@ -0,0 +1,137 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official email address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+This includes the LEDMatrix Discord server, GitHub repositories owned by
+ChuckBuilds, and any other forums hosted by or affiliated with the project.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement on the
+[LEDMatrix Discord](https://discord.gg/uW36dVAtcT) (DM a moderator or
+ChuckBuilds directly) or by opening a private GitHub Security Advisory if
+the issue involves account safety. All complaints will be reviewed and
+investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior, harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
+
+For answers to common questions about this code of conduct, see the FAQ at
+[https://www.contributor-covenant.org/faq][FAQ]. Translations are available
+at [https://www.contributor-covenant.org/translations][translations].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
+[Mozilla CoC]: https://github.com/mozilla/diversity
+[FAQ]: https://www.contributor-covenant.org/faq
+[translations]: https://www.contributor-covenant.org/translations

CONTRIBUTING.md

@@ -0,0 +1,113 @@
+# Contributing to LEDMatrix
+
+Thanks for considering a contribution! LEDMatrix is built with help from
+the community and we welcome bug reports, plugins, documentation
+improvements, and code changes.
+
+## Quick links
+
+- **Bugs / feature requests**: open an issue using one of the templates
+  in [`.github/ISSUE_TEMPLATE/`](.github/ISSUE_TEMPLATE/).
+- **Real-time discussion**: the
+  [LEDMatrix Discord](https://discord.gg/uW36dVAtcT).
+- **Plugin development**:
+  [`docs/PLUGIN_DEVELOPMENT_GUIDE.md`](docs/PLUGIN_DEVELOPMENT_GUIDE.md)
+  and the [`ledmatrix-plugins`](https://github.com/ChuckBuilds/ledmatrix-plugins)
+  repository.
+- **Security issues**: see [`SECURITY.md`](SECURITY.md). Please don't
+  open public issues for vulnerabilities.
+
+## Setting up a development environment
+
+1. Clone with submodules:
+   ```bash
+   git clone --recurse-submodules https://github.com/ChuckBuilds/LEDMatrix.git
+   cd LEDMatrix
+   ```
+2. For development without hardware, run the dev preview server:
+   ```bash
+   python3 scripts/dev_server.py
+   # then open http://localhost:5001
+   ```
+   See [`docs/DEV_PREVIEW.md`](docs/DEV_PREVIEW.md) for details.
+3. To run the full display in emulator mode:
+   ```bash
+   EMULATOR=true python3 run.py
+   ```
+4. To target real hardware on a Raspberry Pi, follow the install
+   instructions in the root [`README.md`](README.md).
+
+## Running the tests
+
+```bash
+pip install -r requirements.txt
+pytest
+```
+
+See [`docs/HOW_TO_RUN_TESTS.md`](docs/HOW_TO_RUN_TESTS.md) for details
+on test markers, the per-plugin tests, and the web-interface
+integration tests.
+
+## Submitting changes
+
+1. **Open an issue first** for non-trivial changes. This avoids
+   wasted work on PRs that don't fit the project direction.
+2. **Create a topic branch** off `main`:
+   `feat/<short-description>`, `fix/<short-description>`,
+   `docs/<short-description>`.
+3. **Keep PRs focused.** One conceptual change per PR. If you find
+   adjacent bugs while working, fix them in a separate PR.
+4. **Follow the existing code style.** Python code uses standard
+   `black`/`ruff` conventions; HTML/JS in `web_interface/` follows the
+   patterns already in `templates/v3/` and `static/v3/`.
+5. **Update documentation** alongside code changes. If you add a
+   config key, document it in the relevant `*.md` file (or, for
+   plugins, in `config_schema.json` so the form is auto-generated).
+6. **Run the tests** locally before opening the PR.
+7. **Use the PR template** — `.github/PULL_REQUEST_TEMPLATE.md` will
+   prompt you for what we need.
+
+## Commit message convention
+
+Conventional Commits is encouraged but not strictly enforced:
+
+- `feat: add NHL playoff bracket display`
+- `fix(plugin-loader): handle missing class_name in manifest`
+- `docs: correct web UI port in TROUBLESHOOTING.md`
+- `refactor(cache): consolidate strategy lookup`
+
+Keep the subject under 72 characters; put the why in the body.
+
+## Contributing a plugin
+
+LEDMatrix plugins live in their own repository:
+[`ledmatrix-plugins`](https://github.com/ChuckBuilds/ledmatrix-plugins).
+Plugin contributions go through that repo's
+[`SUBMISSION.md`](https://github.com/ChuckBuilds/ledmatrix-plugins/blob/main/SUBMISSION.md)
+process. The
+[`hello-world` plugin](https://github.com/ChuckBuilds/ledmatrix-plugins/tree/main/plugins/hello-world)
+is the canonical starter template.
+
+## Reviewing pull requests
+
+Maintainer review is by [@ChuckBuilds](https://github.com/ChuckBuilds).
+Community review is welcome on any open PR — leave constructive
+comments, test on your hardware if applicable, and call out anything
+unclear.
+
+## Code of conduct
+
+This project follows the [Contributor Covenant](CODE_OF_CONDUCT.md). By
+participating you agree to abide by its terms.
+
+## License
+
+LEDMatrix is licensed under the [GNU General Public License v3.0 or
+later](LICENSE). By submitting a contribution you agree to license it
+under the same terms (the standard "inbound = outbound" rule that
+GitHub applies by default).
+
+LEDMatrix builds on
+[`rpi-rgb-led-matrix`](https://github.com/hzeller/rpi-rgb-led-matrix),
+which is GPL-2.0-or-later. The "or later" clause makes it compatible
+with GPL-3.0 distribution.

LEDMatrix.code-workspace

@@ -0,0 +1,19 @@
+{
+	"folders": [
+		{
+			"path": ".",
+			"name": "LEDMatrix (Main)"
+		},
+		{
+			"path": "../ledmatrix-plugins",
+			"name": "Plugins (Monorepo)"
+		}
+	],
+	"settings": {
+		"files.exclude": {
+			"**/.git": true,
+			"**/__pycache__": true,
+			"**/*.pyc": true
+		}
+	}
+}

LICENSE

@@ -0,0 +1,674 @@
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The GNU General Public License is a free, copyleft license for
+software and other kinds of works.
+
+  The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program--to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+  To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+  Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+  For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+  Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+  Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                       TERMS AND CONDITIONS
+
+  0. Definitions.
+
+  "This License" refers to version 3 of the GNU General Public License.
+
+  "Copyright" also means copyright-like laws that apply to other kinds of
+works, such as semiconductor masks.
+
+  "The Program" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as "you".  "Licensees" and
+"recipients" may be individuals or organizations.
+
+  To "modify" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of an
+exact copy.  The resulting work is called a "modified version" of the
+earlier work or a work "based on" the earlier work.
+
+  A "covered work" means either the unmodified Program or a work based
+on the Program.
+
+  To "propagate" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+
+  To "convey" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user through
+a computer network, with no transfer of a copy, is not conveying.
+
+  An interactive user interface displays "Appropriate Legal Notices"
+to the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+
+  1. Source Code.
+
+  The "source code" for a work means the preferred form of the work
+for making modifications to it.  "Object code" means any non-source
+form of a work.
+
+  A "Standard Interface" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+
+  The "System Libraries" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+"Major Component", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+
+  The "Corresponding Source" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+
+  The Corresponding Source need not include anything that users
+can regenerate automatically from other parts of the Corresponding
+Source.
+
+  The Corresponding Source for a work in source code form is that
+same work.
+
+  2. Basic Permissions.
+
+  All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+
+  You may make, run and propagate covered works that you do not
+convey, without conditions so long as your license otherwise remains
+in force.  You may convey covered works to others for the sole purpose
+of having them make modifications exclusively for you, or provide you
+with facilities for running those works, provided that you comply with
+the terms of this License in conveying all material for which you do
+not control copyright.  Those thus making or running the covered works
+for you must do so exclusively on your behalf, under your direction
+and control, on terms that prohibit them from making any copies of
+your copyrighted material outside their relationship with you.
+
+  Conveying under any other circumstances is permitted solely under
+the conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+  No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the WIPO copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+
+  When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such circumvention
+is effected by exercising rights under this License with respect to
+the covered work, and you disclaim any intention to limit operation or
+modification of the work as a means of enforcing, against the work's
+users, your or third parties' legal rights to forbid circumvention of
+technological measures.
+
+  4. Conveying Verbatim Copies.
+
+  You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+
+  You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+  You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these conditions:
+
+    a) The work must carry prominent notices stating that you modified
+    it, and giving a relevant date.
+
+    b) The work must carry prominent notices stating that it is
+    released under this License and any conditions added under section
+    7.  This requirement modifies the requirement in section 4 to
+    "keep intact all notices".
+
+    c) You must license the entire work, as a whole, under this
+    License to anyone who comes into possession of a copy.  This
+    License will therefore apply, along with any applicable section 7
+    additional terms, to the whole of the work, and all its parts,
+    regardless of how they are packaged.  This License gives no
+    permission to license the work in any other way, but it does not
+    invalidate such permission if you have separately received it.
+
+    d) If the work has interactive user interfaces, each must display
+    Appropriate Legal Notices; however, if the Program has interactive
+    interfaces that do not display Appropriate Legal Notices, your
+    work need not make them do so.
+
+  A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+"aggregate" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+  You may convey a covered work in object code form under the terms
+of sections 4 and 5, provided that you also convey the
+machine-readable Corresponding Source under the terms of this License,
+in one of these ways:
+
+    a) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by the
+    Corresponding Source fixed on a durable physical medium
+    customarily used for software interchange.
+
+    b) Convey the object code in, or embodied in, a physical product
+    (including a physical distribution medium), accompanied by a
+    written offer, valid for at least three years and valid for as
+    long as you offer spare parts or customer support for that product
+    model, to give anyone who possesses the object code either (1) a
+    copy of the Corresponding Source for all the software in the
+    product that is covered by this License, on a durable physical
+    medium customarily used for software interchange, for a price no
+    more than your reasonable cost of physically performing this
+    conveying of source, or (2) access to copy the
+    Corresponding Source from a network server at no charge.
+
+    c) Convey individual copies of the object code with a copy of the
+    written offer to provide the Corresponding Source.  This
+    alternative is allowed only occasionally and noncommercially, and
+    only if you received the object code with such an offer, in accord
+    with subsection 6b.
+
+    d) Convey the object code by offering access from a designated
+    place (gratis or for a charge), and offer equivalent access to the
+    Corresponding Source in the same way through the same place at no
+    further charge.  You need not require recipients to copy the
+    Corresponding Source along with the object code.  If the place to
+    copy the object code is a network server, the Corresponding Source
+    may be on a different server (operated by you or a third party)
+    that supports equivalent copying facilities, provided you maintain
+    clear directions next to the object code saying where to find the
+    Corresponding Source.  Regardless of what server hosts the
+    Corresponding Source, you remain obligated to ensure that it is
+    available for as long as needed to satisfy these requirements.
+
+    e) Convey the object code using peer-to-peer transmission, provided
+    you inform other peers where the object code and Corresponding
+    Source of the work are being offered to the general public at no
+    charge under subsection 6d.
+
+  A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+
+  A "User Product" is either (1) a "consumer product", which means any
+tangible personal property which is normally used for personal, family,
+or household purposes, or (2) anything designed or sold for incorporation
+into a dwelling.  In determining whether a product is a consumer product,
+doubtful cases shall be resolved in favor of coverage.  For a particular
+product received by a particular user, "normally used" refers to a
+typical or common use of that class of product, regardless of the status
+of the particular user or of the way in which the particular user
+actually uses, or expects or is expected to use, the product.  A product
+is a consumer product regardless of whether the product has substantial
+commercial, industrial or non-consumer uses, unless such uses represent
+the only significant mode of use of the product.
+
+  "Installation Information" for a User Product means any methods,
+procedures, authorization keys, or other information required to install
+and execute modified versions of a covered work in that User Product from
+a modified version of its Corresponding Source.  The information must
+suffice to ensure that the continued functioning of the modified object
+code is in no case prevented or interfered with solely because
+modification has been made.
+
+  If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in ROM).
+
+  The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or updates
+for a work that has been modified or installed by the recipient, or for
+the User Product in which it has been modified or installed.  Access to a
+network may be denied when the modification itself materially and
+adversely affects the operation of the network or violates the rules and
+protocols for communication across the network.
+
+  Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+
+  7. Additional Terms.
+
+  "Additional permissions" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+
+  When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+
+  Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders of
+that material) supplement the terms of this License with terms:
+
+    a) Disclaiming warranty or limiting liability differently from the
+    terms of sections 15 and 16 of this License; or
+
+    b) Requiring preservation of specified reasonable legal notices or
+    author attributions in that material or in the Appropriate Legal
+    Notices displayed by works containing it; or
+
+    c) Prohibiting misrepresentation of the origin of that material, or
+    requiring that modified versions of such material be marked in
+    reasonable ways as different from the original version; or
+
+    d) Limiting the use for publicity purposes of names of licensors or
+    authors of the material; or
+
+    e) Declining to grant rights under trademark law for use of some
+    trade names, trademarks, or service marks; or
+
+    f) Requiring indemnification of licensors and authors of that
+    material by anyone who conveys the material (or modified versions of
+    it) with contractual assumptions of liability to the recipient, for
+    any liability that these contractual assumptions directly impose on
+    those licensors and authors.
+
+  All other non-permissive additional terms are considered "further
+restrictions" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+
+  If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+
+  Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions;
+the above requirements apply either way.
+
+  8. Termination.
+
+  You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+
+  However, if you cease all violation of this License, then your
+license from a particular copyright holder is reinstated (a)
+provisionally, unless and until the copyright holder explicitly and
+finally terminates your license, and (b) permanently, if the copyright
+holder fails to notify you of the violation by some reasonable means
+prior to 60 days after the cessation.
+
+  Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+
+  Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+  You are not required to accept this License in order to receive or
+run a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+  Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+
+  An "entity transaction" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+
+  You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+
+  11. Patents.
+
+  A "contributor" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's "contributor version".
+
+  A contributor's "essential patent claims" are all patent claims
+owned or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, "control" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+
+  Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+
+  In the following three paragraphs, a "patent license" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To "grant" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+
+  If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  "Knowingly relying" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+
+  If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+
+  A patent license is "discriminatory" if it does not include within
+the scope of its coverage, prohibits the exercise of, or is
+conditioned on the non-exercise of one or more of the rights that are
+specifically granted under this License.  You may not convey a covered
+work if you are a party to an arrangement with a third party that is
+in the business of distributing software, under which you make payment
+to the third party based on the extent of your activity of conveying
+the work, and under which the third party grants, to any of the
+parties who would receive the covered work from you, a discriminatory
+patent license (a) in connection with copies of the covered work
+conveyed by you (or copies made from those copies), or (b) primarily
+for and in connection with specific products or compilations that
+contain the covered work, unless you entered into that arrangement,
+or that patent license was granted, prior to 28 March 2007.
+
+  Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+  If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey a
+covered work so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you may
+not convey it at all.  For example, if you agree to terms that obligate you
+to collect a royalty for further conveying from those to whom you convey
+the Program, the only way you could satisfy both those terms and this
+License would be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+  Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the GNU Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the GNU Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+
+  14. Revised Versions of this License.
+
+  The Free Software Foundation may publish revised and/or new versions of
+the GNU General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+  Each version is given a distinguishing version number.  If the
+Program specifies that a certain numbered version of the GNU General
+Public License "or any later version" applies to it, you have the
+option of following the terms and conditions either of that numbered
+version or of any later version published by the Free Software
+Foundation.  If the Program does not specify a version number of the
+GNU General Public License, you may choose any version ever published
+by the Free Software Foundation.
+
+  If the Program specifies that a proxy can decide which future
+versions of the GNU General Public License can be used, that proxy's
+public statement of acceptance of a version permanently authorizes you
+to choose that version for the Program.
+
+  Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+
+  15. Disclaimer of Warranty.
+
+  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
+OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
+THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
+IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
+ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
+THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
+GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
+USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
+EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
+SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+  If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+
+                     END OF TERMS AND CONDITIONS
+
+            How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, either version 3 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <https://www.gnu.org/licenses/>.
+
+Also add information on how to contact you by electronic and paper mail.
+
+  If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+    <program>  Copyright (C) <year>  <name of author>
+    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, your program's commands
+might be different; for a GUI interface, you would use an "about box".
+
+  You should also get your employer (if you work as a programmer) or school,
+if any, to sign a "copyright disclaimer" for the program, if necessary.
+For more information on this, and how to apply and follow the GNU GPL, see
+<https://www.gnu.org/licenses/>.
+
+  The GNU General Public License does not permit incorporating your program
+into proprietary programs.  If your program is a subroutine library, you
+may consider it more useful to permit linking proprietary applications with
+the library.  If this is what you want to do, use the GNU Lesser General
+Public License instead of this License.  But first, please read
+<https://www.gnu.org/licenses/why-not-lgpl.html>.

Matrix Stand STL/LICENSE.txt

@@ -1 +0,0 @@
-This thing was created by Thingiverse user randomwire, and is licensed under cc.

Matrix Stand STL/README.txt

@@ -1 +0,0 @@
-P4 Matrix Stand by randomwire on Thingiverse: https://www.thingiverse.com/thing:5169867

SECURITY.md

@@ -0,0 +1,86 @@
+# Security Policy
+
+## Reporting a vulnerability
+
+If you've found a security issue in LEDMatrix, **please don't open a
+public GitHub issue**. Disclose it privately so we can fix it before it's
+exploited.
+
+### How to report
+
+Use one of these channels, in order of preference:
+
+1. **GitHub Security Advisories** (preferred). On the LEDMatrix repo,
+   go to **Security → Advisories → Report a vulnerability**. This
+   creates a private discussion thread visible only to you and the
+   maintainer.
+   - Direct link: <https://github.com/ChuckBuilds/LEDMatrix/security/advisories/new>
+2. **Discord DM**. Send a direct message to a moderator on the
+   [LEDMatrix Discord](https://discord.gg/uW36dVAtcT). Don't post in
+   public channels.
+
+Please include:
+
+- A description of the issue
+- The version / commit hash you're testing against
+- Steps to reproduce, ideally a minimal proof of concept
+- The impact you can demonstrate
+- Any suggested mitigation
+
+### What to expect
+
+- An acknowledgement within a few days (this is a hobby project, not
+  a 24/7 ops team).
+- A discussion of the issue's severity and a plan for the fix.
+- Credit in the release notes when the fix ships, unless you'd
+  prefer to remain anonymous.
+- For high-severity issues affecting active deployments, we'll
+  coordinate disclosure timing with you.
+
+## Scope
+
+In scope for this policy:
+
+- The LEDMatrix display controller, web interface, and plugin loader
+  in this repository
+- The official plugins in
+  [`ledmatrix-plugins`](https://github.com/ChuckBuilds/ledmatrix-plugins)
+- Installation scripts and systemd unit files
+
+Out of scope (please report upstream):
+
+- Vulnerabilities in `rpi-rgb-led-matrix` itself —
+  report to <https://github.com/hzeller/rpi-rgb-led-matrix>
+- Vulnerabilities in Python packages we depend on — report to the
+  upstream package maintainer
+- Issues in third-party plugins not in `ledmatrix-plugins` — report
+  to that plugin's repository
+
+## Known security model
+
+LEDMatrix is designed for trusted local networks. Several limitations
+are intentional rather than vulnerabilities:
+
+- **No web UI authentication.** The web interface assumes the network
+  it's running on is trusted. Don't expose port 5000 to the internet.
+- **Plugins run unsandboxed.** Installed plugins execute in the same
+  Python process as the display loop with full file-system and
+  network access. Review plugin code (especially third-party plugins
+  from arbitrary GitHub URLs) before installing. The Plugin Store
+  marks community plugins as **Custom** to highlight this.
+- **The display service runs as root** for hardware GPIO access. This
+  is required by `rpi-rgb-led-matrix`.
+- **`config_secrets.json` is plaintext.** API keys and tokens are
+  stored unencrypted on the Pi. Lock down filesystem permissions on
+  the config directory if this matters for your deployment.
+
+These are documented as known limitations rather than bugs. If you
+have ideas for improving them while keeping the project usable on a
+Pi, open a discussion — we're interested.
+
+## Supported versions
+
+LEDMatrix is rolling-release on `main`. Security fixes land on `main`
+and become available the next time users run **Update Code** from the
+web UI's Overview tab (which does a `git pull`). There are no LTS
+branches.

assets/fonts/README.md

@@ -9,20 +9,20 @@ from the utils/ directory.
 
 Tom-Thumb.bdf is included in this directory under [MIT license](http://vt100.tarunz.org/LICENSE). Tom-thumb.bdf was created by [@robey](http://twitter.com/robey) and originally published at https://robey.lag.net/2010/01/23/tiny-monospace-font.html
 
-The texguire-27.bdf font was created using the [otf2bdf] tool from the TeX Gyre font.
-```
+The texgyre-27.bdf font was created using the [otf2bdf] tool from the TeX Gyre font.
+```bash
 otf2bdf -v -o texgyre-27.bdf -r 72 -p 27 texgyreadventor-regular.otf
 ```
 
 ## Create your own
 
-Fonts are in a human readable and editbable `*.bdf` format, but unless you
+Fonts are in a human-readable and editable `*.bdf` format, but unless you
 like reading and writing pixels in hex, generating them is probably easier :)
 
 You can use any font-editor to generate a BDF font or use the conversion
 tool [otf2bdf] to create one from some other font format.
 
-Here is an example how you could create a 30pixel high BDF font from some
+Here is an example how you could create a 30-pixel high BDF font from some
 TrueType font:
 
 ```bash
@@ -31,9 +31,9 @@ otf2bdf -v -o myfont.bdf -r 72 -p 30 /path/to/font-Bold.ttf
 
 ## Getting otf2bdf
 
-Installing the tool should be fairly straight-foward
+Installing the tool should be fairly straightforward.
 
-```
+```bash
 sudo apt-get install otf2bdf
 ```
 
@@ -43,7 +43,7 @@ If you like to compile otf2bdf, you might notice that the configure script
 uses some old way of getting the freetype configuration. There does not seem
 to be much activity on the mature code, so let's patch that first:
 
-```
+```bash
 sudo apt-get install -y libfreetype6-dev pkg-config autoconf
 git clone https://github.com/jirutka/otf2bdf.git   # check it out
 cd otf2bdf