RnD/EVOLV

Files

znetsixe d4e72f280e docs: retire repo-mem MCP, migrate skills to .claude/skills, audit fixes

- 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>

2026-05-19 09:30:49 +02:00

3.1 KiB

Raw Blame History

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

Inspect current node trio: .html, .js, src/nodeClass.js.
Define required config properties and defaults.
Update .html defaults and form controls.
Update runtime config normalization in src/nodeClass.js.
Confirm msg.topic command handling is still coherent.
Add tests under nodes/<nodeName>/test/ with focus on config defaults/overrides and topic routing.
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

3.1 KiB Raw Blame History