d4e72f280e
- Delete .mcp.json + .claude/rules/repo-mem.md; drop .repo-mem from .gitignore - Remove repo-mem / substrate_score / repo_search references from all .md - Move 15 EVOLV skills from .agents/skills/ to .claude/skills/ so they are auto-discovered by the Claude Code harness and invokable via the Skill tool - Retire .agents/skills/evolv-orchestrator (duplicate of the subagent at .claude/agents/evolv-orchestrator.md); orchestrator lives as a subagent only - Drop OpenAI-format agent yaml metadata from each skill (not needed for CC) - Update CLAUDE.md, CONTRACTS.md, AGENTS.md to point at the new locations and disambiguate skills (.claude/skills/) vs subagents (.claude/agents/) - Fix CLAUDE.md tick-loop wording (opt-in per-node, not a fixed 1000ms) - Widen .claude/rules/ paths frontmatter so node-architecture and telemetry rules trigger on more relevant files; add frontmatter to flow-layout rule - Bump CONTRACTS.md review date to 2026-05-19; add step 7 to the contract- change workflow (review example flows when topic usage changes) - Bump nodes/generalFunctions pin (Home.md substrate_score reference removed) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
68 lines
3.1 KiB
Markdown
68 lines
3.1 KiB
Markdown
---
|
|
name: evolv-frontend-node-red
|
|
description: 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
|