Command library 4.4.0: DroidNet fork brightness

[travisccook]

Minor release 4.4.0: two DroidNet fork boards, each listed right after its stock board.

• RSeriesLogic · DroidNet fork (droidnet-rseries-logic): Brightness, rseries.cfg.brightness,
  #LEBRI{unit}{level}. The unit is none (both displays), F or R; the level is 1-255. Firmware:
  travisccook/DroidNet-RSeriesLogics @ aa45d79.
• FlthyHPs · DroidNet fork (droidnet-flthy-hps): Brightness, flthy.led.brightness, H{unit}B{level}.
  The unit is F R T X Y Z A, default A; the level is 1-255. Firmware: travisccook/DroidNet-FlthyHPs @ 75755de.

Both commands are cosmetic, Lighting and community confidence, with no duration suffix. Stock firmware ignores them,
and the level is RAM-only. The stock boards are unchanged. Boards 22 -> 24, commands 500 -> 502. Every example
parses to its own id and round-trips (test/droidnet-forks.test.js), and a test rejects a placeholder
firmware value.

npm run validate exits 0; npm test 425/425 (the branch also carries the storedcommand safety class, approved
separately and added between Tasks 2 and 3; the brief's template here said 423/423 before that task existed).

Design: droidnet-comlink docs/superpowers/specs/2026-09-22-fork-brightness-and-library-design.md, section 4.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VnqRz7vGF5Xusa3WLbo38J

[github-actions]

Automated review

Checks: ✅ all pass.

• npm ci — clean install (272 packages; pre-existing npm audit advisories only, unrelated to this PR).
• npm run validate — every board file validates (✓ boards/droidnet-flthy-hps.json, ✓ boards/droidnet-rseries-logic.json, plus all pre-existing boards), ✓ cross-file (merged catalog). Only warnings are pre-existing "non-standard category" notices on unrelated boards — none from this PR's files.
• npm test — 13 suites / 425 tests pass, including the new test/droidnet-forks.test.js (round-trip, comment-label, manifest-position, firmware-commit-format checks for the two new boards) and updated assertions in test/wcb-621.test.js, test/engine.test.js, test/library.test.js, test/load-node.test.js.

Safety-class fix (the required item, #3 in review instructions): correctly done and complete. I grepped every board file for ;C{key}, ;SEQ{key}, and ONFIN,{key} templates and confirmed all 9 are now safety:"storedcommand", none missed:

• libraries/boards/wcb-native.json:1599,1618,1637,1656 — wcb.runSeq, wcb.runSeqLong, wcb.runSeqLocal, wcb.runSeqLongLocal (previously config)
• libraries/boards/wcb-dfp.json:39,49,59 — dfp.playCb, dfp.folderCb, dfp.mp3FolderCb (previously cosmetic — this was the more serious mislabel, since these silently ran arbitrary stored content)
• libraries/boards/wcb-mp3.json:20,29 — mp3.playCb, mp3.playFsCb (previously cosmetic)

Commands that only manage stored sequences (save/list/get/clear, timer, ONERR setters) correctly stay config since they don't execute unknown content — verified via test/wcb-621.test.js's new config: guard test.

The new storedcommand class is threaded consistently through schema (schema/library.schema.json:126), docs (CLAUDE.md, CONTRIBUTING.md, docs/BOARD_AUTHORING_GUIDE.md), UI styling (assets/app.css:39), and a good forward-compat note in docs/INTEGRATION_GUIDE.md telling integrators to treat any unrecognized non-cosmetic value as a warning rather than allow-listing known ones.

New boards (libraries/boards/droidnet-flthy-hps.json, libraries/boards/droidnet-rseries-logic.json): single Brightness command each, correctly safety:"cosmetic" (RAM-only brightness level, no movement/power implication) and confidence:"community" (honest — unverified fork firmware). Each new component slots directly after its stock counterpart in libraries/manifest.json, matches CONTRIBUTING's "list right after the stock board" convention, and is exercised end-to-end by test/droidnet-forks.test.js.

Versioning: libraryVersion bumped 4.3.0 → 4.4.0 (minor) in libraries/manifest.json:3 — correct per CLAUDE.md's semver rule (adds boards/commands, no command-id renames/removals, so no stored-value breakage even though safety semantics changed). package.json, package-lock.json, and releases.json are all in sync at 4.4.0, and a new test (test/load-node.test.js) now asserts that invariant going forward — a nice guardrail against future version-file drift.

src/*.js: unchanged in this PR — nothing to review under item 4.

No issues found. This is a clean, well-tested PR that does exactly what the safety-class rule requires, with no missed cases.

[github-actions]

Automated review

1. Checks

• npm ci — OK (272 packages; only pre-existing npm audit warnings, unrelated to this diff).
• npm run validate — PASS. Only pre-existing "non-standard category name" warnings on unrelated boards (e.g. flthy-hps: category 'Servo'), nothing from this PR's files.
• npm test — PASS. 13 suites / 425 tests, including the new test/droidnet-forks.test.js (round-trip, comment-label, manifest-placement, firmware-string checks for both new boards) and the extended test/wcb-621.test.js.

2. Board-contribution rules

• Every new/changed command has an examples entry (libraries/boards/droidnet-flthy-hps.json:34, droidnet-rseries-logic.json:33), and template/param placeholders match both ways (H{unit}B{level} ↔ unit,level; #LEBRI{unit}{level} ↔ unit,level).
• param.enum refs (flthy.designator, rseries.unit) resolve to enums defined in the same file.
• Command ids are new/unique (flthy.led.brightness, rseries.cfg.brightness); validator's cross-file pass confirmed no collisions.
• libraries/manifest.json libraryVersion bumped 4.3.0 → 4.4.0 (minor — two new boards/commands, no renames/removals), consistent with package.json, package-lock.json (both version fields), and releases.json (latest.libraryVersion + libraries[].libraryVersion + releasedAt updated) — all now enforced by a new regression test in test/load-node.test.js:16-25. Good addition.
• confidence: "community" on both new boards — appropriately cautious for unverified fork firmware, per CONTRIBUTING.md.

3. Safety-class check (HIGH SEVERITY item) — no mislabeling found, and this PR fixes a prior one

• The two new commands (flthy.led.brightness, rseries.cfg.brightness, both libraries/boards/droidnet-*-*.json) are RAM-only LED-brightness setters — cosmetic is correct, they don't move anything or touch power.
• The PR introduces a new storedcommand safety class (schema: schema/library.schema.json:126) specifically for commands that run board-stored content, and retroactively re-labels the commands this rule (item 3 of the review instructions itself, updated at .github/workflows/claude-review.yml:90-94) is about:
  • wcb-native.json: wcb.runSeq, wcb.runSeqLong, wcb.runSeqLocal, wcb.runSeqLongLocal (;C<key> / ;SEQ<key> runs) — moved from config → storedcommand. Correct: the library can't see what a saved WCB sequence does.
  • wcb-dfp.json (dfp.playCb, dfp.folderCb, dfp.mp3FolderCb) and wcb-mp3.json (mp3.playCb, mp3.playFsCb) — the ONFIN,{key} callback variants moved from cosmetic → storedcommand, since they trigger a stored key's callback whose effect is unknown. Correct, and previously these actually were mislabeled cosmetic, which this PR fixes.
  • Existing wcb.seqSave/seqNames/seqGet/seqList/seqClear/seqClearAll and timer/ONERR setters correctly stay config (they save/query, they don't execute stored content) — verified by the new test at test/wcb-621.test.js:130-136.
  • Pre-existing Maestro "Run Subroutine" commands (libraries/boards/maestro.json:127 etc.) are left as movement, not reclassified to storedcommand — this is consistent with the new CLAUDE.md guidance ("if the device itself limits what saved content can do … use that limit's class instead"), since a Pololu Maestro subroutine is servo motion, a known effect class.

4. src/*.js

No changes to src/droidnet-command-library.js or src/droidnet-command-library-ui.js in this diff — engine/UI separation and the buildWCBValue(parseWCBValue(v)) === v round-trip invariant are untouched, and are exercised for the two new boards by test/droidnet-forks.test.js ("round-trips byte-identically").

Minor/non-blocking notes

• test/wcb-621.test.js's top-level storedcommand list (storedIds, line ~131) only covers wcb.runSeq* + mp3.playCb/mp3.playFsCb; the dfp.*Cb ids aren't in that list, but they are separately asserted storedcommand a few lines down in the wcb-dfp describe block (test/wcb-621.test.js:317), so coverage is complete — just split across two tests, worth a comment if it's ever confusing to a future reader.
• Both new boards are kind: "device-native" naming a specific fork firmware commit (droidnet-flthy-hps.json:12, droidnet-rseries-logic.json:12) rather than wcb-verb; per CLAUDE.md that's the right kind since the grammar (H{unit}B{level} / #LEBRI{unit}{level}) is the board's own, not an intermediary's.

Overall: clean, well-tested PR. No blocking issues found.