EVOLV/.agents/skills/evolv-frontend-node-red/SKILL.md

name, description

name	description
evolv-frontend-node-red	Design and implement Node-RED node editor UI and runtime-facing configuration for EVOLV. Use when editing node HTML editor files, `RED.nodes.registerType(...)` defaults, admin endpoint-driven menus/config scripts, and config mapping into `src/nodeClass.js` in JavaScript/CommonJS nodes.

EVOLV Frontend Node-RED

Mission

Implement robust Node-RED editor experiences that keep UI defaults, runtime config parsing, and behavior in lockstep.

Harness Execution Contract

• Start from impacted files and active runtime/editor contracts.
• Define invariants before editing:
  • .html defaults and runtime parsing parity
  • endpoint path stability (/<nodeName>/menu.js, /<nodeName>/configData.js)
  • released topic/output compatibility unless migration is declared
• Provide evidence for changed behavior (tests or smoke checks).

Repo-Specific Rules

• Use CommonJS patterns in runtime files.
• Keep node names aligned across RED.nodes.registerType('<nodeName>', ...), runtime registration in <nodeName>.js, and package/node mapping.
• Keep admin endpoint paths stable unless editor consumers are updated: /<nodeName>/menu.js and /<nodeName>/configData.js.
• Prefer placeholder-driven UI composition when matching EVOLV patterns.

Node Layout Standard

Use nodes/machineGroupControl/ as the template baseline for new nodes.

• nodes/<nodeName>/<nodeName>.js
  • Keep runtime entry small.
  • Create Node-RED instance and attach this.nodeClass = new nodeClass(...).
  • Register admin endpoints via shared managers.
• nodes/<nodeName>/<nodeName>.html
  • Register defaults in RED.nodes.registerType(...).
  • Load /<nodeName>/menu.js and /<nodeName>/configData.js.
  • Use oneditprepare to call window.EVOLV.nodes.<nodeName>.initEditor(this).
• nodes/<nodeName>/src/nodeClass.js
  • Normalize uiConfig into runtime config.
  • Keep Node-RED concerns here: input routing, tick loop, output formatting, status.
• nodes/<nodeName>/src/specificClass.js
  • Keep domain logic here with minimal/no direct Node-RED coupling.

Implementation Workflow

1. Inspect current node trio: .html, .js, src/nodeClass.js.
2. Define required config properties and defaults.
3. Update .html defaults and form controls.
4. Update runtime config normalization in src/nodeClass.js.
5. Confirm msg.topic command handling is still coherent.
6. Add tests under nodes/<nodeName>/test/ with focus on config defaults/overrides and topic routing.
7. If creating a new node, add entry under root package.json node-red.nodes map.

Quality Gates

• Every UI property has corresponding runtime handling.
• Numeric inputs are validated/coerced consistently.
• Node status and output shape remain predictable.
• No Node-RED runtime dependency required for domain tests.

Deliverables

Return:

• changed config fields and mapping table
• changed files
• tests added and what they prove
• migration notes if backward compatibility changed

Decision interview triggers:

• form or default changes that alter existing deployed behavior
• endpoint contract/path changes
• UI/runtime migration that could break saved Node-RED flows