mirror of
https://github.com/ChuckBuilds/LEDMatrix.git
synced 2026-10-04 06:15:09 +00:00
claude[bot]andClaude Opus 5
21c8a54f68
* chore: prepare the 3.5.0 release Turns the CHANGELOG's Unreleased section into `## 3.5.0` and bumps `src.__version__`, the value plugin `ledmatrix_min_version` floors compare against. No behaviour change; nothing outside the CHANGELOG, `src/__init__.py` and one docs line is touched. The staged entries are reshaped into the `### ` subsections every released section already uses, and the "new modules a plugin may import via `src.*`" block moves to the top as the plugin-facing summary, the same shape as 3.4.0. Its floor, written as "the release that ships this" while it was staged, is now 3.5.0, and `docs/SPORTS_UNIFICATION.md` says 3.5.0 for `sports_helpers.py` instead of "(unreleased)". Four merged changes had never been written down. They are added under the subsection each belongs to, from the commits and their measurements: - the idle back-off clamped to the next kickoff (#599) - concurrent ESPN date chunks (#596) - the three web routes that consulted plugin manifests before anything had discovered plugins, one of which wrote a plugin API key to config.json in plain text (#594) - the cache permission fix and its systemd unit changes (#593), which get their own subsection No tag and no release: `scripts/check_release_version.py v3.5.0` passes, so tagging is a separate, deliberate step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Rqzd6Nz2bQJp5K7DD5dS4X * ci: let Claude Code Review run on PRs the Claude app opens The review action refuses a workflow whose actor is a GitHub App unless the app is named in `allowed_bots`, which this workflow never set: Actor is a GitHub App: claude[bot] Actor type: Bot Action failed with error: Workflow initiated by non-human actor: claude (type: Bot). Add bot to allowed_bots list or use '*' to allow all bots. It aborts about two seconds in, before the diff is read, so the check is red on every such PR and re-running cannot help: the actor does not change. Until now no PR here had a bot author, so nothing tripped it. `'claude'` rather than `'*'`: the action lowercases each entry and strips a trailing `[bot]` before comparing it to the actor (`isAllowedBot` in `src/github/validation/actor.ts`), so this admits `claude[bot]` and no other app. `'*'` would admit any app that can trigger a workflow here, with a prompt it controls — the action's own docs warn about that on public repositories, and this one is public. The write-permission check already allowed the app; `checkHumanActor` was the only gate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Rqzd6Nz2bQJp5K7DD5dS4X --------- Co-authored-by: Claude <noreply@anthropic.com>
LEDMatrix Documentation
This directory contains guides, references, and architectural notes for the LEDMatrix project. If you are setting up a Pi for the first time, start with the project root README — it covers hardware, OS imaging, and the one-shot installer. The pages here go deeper.
I'm a new user
- GETTING_STARTED.md — first-time setup walkthrough
- WEB_INTERFACE_GUIDE.md — using the web UI
- PLUGIN_STORE_GUIDE.md — installing and managing plugins
- WIFI_NETWORK_SETUP.md — WiFi and AP-mode setup
- TROUBLESHOOTING.md — common issues and fixes
- SSH_UNAVAILABLE_AFTER_INSTALL.md — recovering SSH after install
- CONFIG_DEBUGGING.md — diagnosing config problems
- LOW_MEMORY_BOARDS.md — Pi Zero 2 W / 3B+ / 1GB Pi 4 memory limits
I want to write a plugin
Start here:
- PLUGIN_DEVELOPMENT_GUIDE.md — end-to-end workflow
- PLUGIN_QUICK_REFERENCE.md — cheat sheet
- PLUGIN_API_REFERENCE.md — display, cache, and plugin-manager APIs
- PLUGIN_ERROR_HANDLING.md — error-handling patterns
- DEV_PREVIEW.md — preview plugins on your dev machine without a Pi
- EMULATOR_SETUP_GUIDE.md — running the matrix emulator
Going deeper:
- ADVANCED_PLUGIN_DEVELOPMENT.md — advanced patterns
- PLUGIN_ARCHITECTURE_SPEC.md — original plugin-system design spec (historical; see its banner for what has drifted)
- PLUGIN_DEPENDENCY_GUIDE.md / PLUGIN_DEPENDENCY_TROUBLESHOOTING.md
- PLUGIN_WEB_UI_ACTIONS.md (+ example JSON)
- PLUGIN_CUSTOM_ICONS.md
- PLUGIN_REGISTRY_SETUP_GUIDE.md (+ registry template)
- STARLARK_APPS_GUIDE.md — Starlark-based mini-apps
- widget-guide.md — widget development
- ADAPTIVE_LAYOUT.md — render legibly on any panel size (opt-in font/layout scaling)
- plugin-safety-harness.md — test a plugin across every screen and matrix size
Configuring plugins
- PLUGIN_CONFIG_QUICK_START.md — minimal config you need
- PLUGIN_CONFIGURATION_GUIDE.md — schema design
- PLUGIN_ELEMENT_STYLING.md — let users restyle, move, hide and scale individual elements (per display mode, if you have them)
- PLUGIN_CONFIGURATION_TABS.md — multi-tab UI configs
- PLUGIN_CONFIG_ARCHITECTURE.md — how the config system works
- PLUGIN_CONFIG_CORE_PROPERTIES.md — properties every plugin honors
Advanced features
- ADVANCED_FEATURES.md — Vegas scroll, on-demand display, cache management, background services, permissions
- FONT_MANAGER.md — font system
- SKIN_SYSTEM.md — skin architecture for sports scoreboards (not supported yet: current scoreboards don't render skins)
- CREATING_SKINS.md — writing and validating a skin (same caveat)
Reference
- CONFIG_REFERENCE.md — every key in config.json and config_secrets.json
- REST_API_REFERENCE.md — all web-interface HTTP endpoints
- PLUGIN_API_REFERENCE.md — Python APIs available to plugins
- DEVELOPER_QUICK_REFERENCE.md — common dev tasks
- PLUGIN_IMPLEMENTATION_SUMMARY.md — what the plugin system actually does
Contributing to LEDMatrix itself
- DEVELOPMENT.md — environment setup
- HOW_TO_RUN_TESTS.md — running the test suite
- MULTI_ROOT_WORKSPACE_SETUP.md — multi-repo workspace
- MIGRATION_GUIDE.md — breaking changes between releases
- SPORTS_UNIFICATION.md — how the sports scoreboard base classes are organized
Archive
docs/archive/ holds older guides that have been superseded or describe
features that have been removed. They are kept for historical context and
git history but should not be relied on.
Contributing to the docs
- Markdown only, professional tone, minimal emoji.
- Prefer adding to an existing page over creating a new one. If you add a new page, link it from this index in the section it belongs to.
- If a page becomes obsolete, move it to
docs/archive/rather than deleting it, so links don't rot. - Keep examples runnable — paths, commands, and config keys here should match what's actually in the repo.