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

2.4 KiB

Raw Blame History

name, description

name	description
evolv-mechanical-rotating-equipment	Provide rotating equipment engineering guidance for EVOLV machine and pumping logic. Use when implementing or reviewing `rotatingMachine`, `machineGroupControl`, pump/motor behavior, operating envelopes, efficiency/power curves, surge/choke limits, and physically plausible constraints in node domain logic.

EVOLV Mechanical Rotating Equipment

Mission

Keep rotating equipment behavior physically plausible, safe, and diagnosable in EVOLV JavaScript domain classes.

Harness Execution Contract

Start from equipment assumptions and current curve/sensor sources in repo.
Define invariants before edits:
- physical plausibility constraints remain enforced
- degraded/fail-safe behavior remains explicit
- outputs remain diagnosable for operations teams
Validate with boundary-condition evidence and deterministic test outcomes.

Scope

nodes/rotatingMachine/
nodes/machineGroupControl/
nodes/pumpingStation/
Related shared curve/model datasets in nodes/generalFunctions/datasets/assetData/

Engineering Checklist

Validate units and conversions before algorithm changes.
Enforce operating envelope constraints:

min/max speed
flow/head boundaries
power/torque limits
efficiency range sanity

Prevent impossible states (negative flow where not allowed, non-physical efficiencies, unstable mode transitions).
Define clear degraded behavior for out-of-range inputs.
Preserve interpretability: outputs should map to recognizable mechanical concepts.

Implementation Pattern

Keep mechanics in src/specificClass.js.
Keep Node-RED concerns in src/nodeClass.js.
Use shared helpers from generalFunctions for logging/config assertions.

Test Expectations

Add/adjust tests under node-specific test/ for:

boundary conditions
invalid sensor/input combinations
regression of known machine edge cases
deterministic output under repeated ticks

Deliverables

Return:

assumptions about equipment type and curve source
implemented constraints and rationale
test coverage for boundary cases
remaining mechanical uncertainties requiring field data

Decision interview triggers:

safety envelope changes (speed, power, flow/head boundaries)
curve-source replacement with uncertain field alignment
degraded-mode changes that affect availability vs protection tradeoffs

2.4 KiB Raw Blame History