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>
59 lines
2.4 KiB
Markdown
59 lines
2.4 KiB
Markdown
---
|
|
name: evolv-mechanical-rotating-equipment
|
|
description: 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
|
|
1. Validate units and conversions before algorithm changes.
|
|
2. Enforce operating envelope constraints:
|
|
- min/max speed
|
|
- flow/head boundaries
|
|
- power/torque limits
|
|
- efficiency range sanity
|
|
3. Prevent impossible states (negative flow where not allowed, non-physical efficiencies, unstable mode transitions).
|
|
4. Define clear degraded behavior for out-of-range inputs.
|
|
5. 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
|